SOA technical perspective and API specialization

From a technical perspective, a SOA must exhibit three key design principles; service orientation, clean separation of concerns, and loose coupling.  Service orientation is gauged by service reusability, granularity, and architecture simplification.  Clean separation of concerns is gauged by testing separation of business logic from infrastructure, interface from implementation, and interface from capability.  Loose coupling is gauged by measuring interoperability, transaction control, and mediated interactions.

On the surface, RESTful APIs are simply a specialized version of web services, and provide similar technical benefits.  Both REST API design and SOA service design intend to expose discrete functionality via a well-defined interface.  The API endpoint and the service endpoint both serve as a core design unit, and teams deliver technical solutions by accessing, aggregating, composing, and orchestrating endpoint interactions.  Successful and scalable API and service-based solutions both require Internet messaging infrastructure, service level management, and security.

Schism between API and SOA, and Pragmatic Reconciliation

While both API and SOA proponents have similar business and technical goals, a large execution schism exists between the two camps.  The schism between pragmatic REST API and pragmatic SOA is caused by differences in strategic focus.

Teams ‘doing REST’ and ‘building APIs’ commonly focus on overcoming technical and business adoption barriers by pursuing incremental build-outs and demonstrating concrete, core-business use cases without introducing complex technology.  SOA teams commonly focus on obtaining efficiencies at scale, achieving enterprise standardization, centralizing decisions, and satisfying complex non-functional requirements.

Pragmatic REST API focus

REST is an architectural style of system development imposing a series of constraints on service interactions. Taken together, the constraints allow beneficial properties to emerge, namely simplicity, scalability, modifiability, reliability, visibility, performance, and portability. Systems that satisfy these constraints are RESTful. A RESTful design approach can foster many benefits:

• Make data and services maximally accessible
  • Low barrier to entry
  • Extend reach towards the largest possible audience
  • Make API/service consumable by the largest number of user agents
• Make data and services evolvable
  • Extend the system at runtime
  • Alter resources without impacting clients
  • Direct client behavior dynamically
• Make systems scalable, reliable, and high performing
  • Simple
  • Cacheable
  • Atomic

While RESTful design benefits support SOA goals, the strategic focus of Pragmatic REST differs from many SOA initiatives.  Pragmatic REST API design teams focus on bottoms-up adoption scenarios, approachable protocols/formats (e.g. HTTP, JSON, DNS), permissive interface definitions, and simpler interaction models (i.e. retry over guaranteed delivery).

Pragmatic SOA focus

Pragmatic SOA focuses on service-oriented patterns that increase software asset value. The fundamental service-oriented patterns are:

• Share and reuse assets
• Consolidate redundant functionality into fewer moving parts
• Conform projects to common standards and best practices

Applying these three patterns will reduce complexity within an IT environment and lead to greater agility, i.e., the ability to build applications faster and modify them quickly to address changing requirements. The service-oriented patterns force development teams to evaluate how software asset capabilities meet the needs of business stakeholders.

Pragmatic SOA teams don’t force common (yet complicated) standards. Pragmatic SOA teams offer useful business capabilities, reduce adoption friction, and deliver exceptional service values.

Pragmatic SOA teams don’t preach difficult best practices. Pragmatic SOA teams simplify best practice adoption by mentoring teams and delivering automated governance that makes the right thing to do the easy team to do.

Pragmatic SOA teams are mindful of skill gaps and adoption hurdles.  Pragmatic teams offer accelerator packs (i.e. infrastructure, tooling, frameworks, and API/service building blocks) that reduce training, increase self-service adoption, and accelerate project delivery.

Pragmatic SOA teams balance enterprise governance with project autonomy.  Instead of erecting development and registration barriers, successful teams foster service development, service sharing, and service adoption by introducing mechanisms to promote services, mediate interactions, harden service levels, and facilitate self-service adoption.  You may recognize these mechanisms as being the core of API management.

Pragmatic Reconciliation

REST is different from—although not incompatible with—SOA. Services can be RESTful, and RESTful resources can be services. Like SOA, REST is an architectural discipline defined by a set of design principles, and REST also imposes a set of architectural constraints. REST uses a resource-centric model, which is the inverse of an object-centric model (i.e., behaviors are encapsulated by resources). In REST, every “thing” of interest is a resource. When modeling a RESTful service (aka APIs), the service’s capabilities are encapsulated and exposed as a set of resources.

Because SOA presents an architectural goal state at odds with a long-lived legacy IT portfolio, SOA is a long-term architectural journey, and not a short-term implementation initiative.  Because APIs interconnect business capabilities inside and outside the organization, APIs can provide a platform for business stakeholders sponsoring enterprise IT renewal and pragmatic business execution.

Jumpstart your Strategy and Execution

The SOA & API Convergence strategy and tactics white paper describes how to define a SOA & API mindset.  The presentation below highlights API strategy and  tactics: