During the SOA craze days in the past, proponents pitched SOA’s lofty benefits from both business and technical perspectives. The benefits are real, yet sometimes very difficult to obtain. Surprisingly, today’s API proponents target similar benefits, but with an execution twist.
While everyone acknowledges API and Service Oriented Architecture (SOA) are best practice approaches to solution and platform development, the learning curve and adoption curve can be steep. To gain significant business benefits, teams must understand their IT business goals, define an appropriate SOA & API mindset, describe how to implement shared services and popular APIs, and tune governance practices.
SOA business perspective and API Economy echo
SOA can be a strategy to align IT assets with business capabilities, business resources, and business processes. SOA’s strong focus on sharing and re-use can optimize IT asset utilization. Most intriguingly, SOA was promised to re-invent business-to-business interactions, enable better partner relationships, and support process networks. External services were seen as a mechanism to extend an enterprise’s economic reach by reducing interaction costs, incorporating external business capabilities, enabling business specialization, and creating higher-value solutions that extend business processes across a partner network.
The current API economy buzz co-opts the SOA business value proposition, injects lessons learns, and rides popular industry trends (i.e. REST, Internet of Everything, mobile, Cloud services).
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
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.
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: