Enterprise Integration Zone is brought to you in partnership with:

As VP of Technology Evangelism at WSO2, Chris Haddad raises awareness of Platform as a Service, Cloud Architecture, Service Oriented Architecture, API Management, and Enterprise Integration. Prior to joining WSO2, Haddad’s experience includes building software development teams, contributing to open source, crafting technology roadmaps, leading Gartner research teams, and delivering Software as a Service and Web applications. Chris is a DZone MVB and is not an employee of DZone and has posted 108 posts at DZone. You can read more from them at their website. View Full User Profile

SOA & API Strategy, Tactics, and Convergence

06.24.2014
| 8392 views |
  • submit to reddit

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[1].  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
    • 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:

[1] The Only Sustainable Edge,  John Hagel III & John Seely Brown, 2005 http://www.johnseelybrown.com/readingTOSE.pdf
Published at DZone with permission of Chris Haddad, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Brian Parkin replied on Tue, 2014/06/24 - 7:28pm

 Great Article Chris!   Many architectures have a great deal of asynchronous messaging in place to share data across an Enterprise.  What are your thoughts on trying to apply SOA practice and application to messaging solutions?

Chris Haddad replied on Wed, 2014/06/25 - 8:33am in response to: Brian Parkin

Thank you for the kudos Brian.   Asynchronous messaging is a interaction style orthogonal to SOA.     When incorporating the asynch interaction style into your solution, continue to apply service-oriented architecture practices.   Document and track pub/sub endpoints, message models, consumer apps, and 'regular service metadata'.    

I once had an interesting experience. While reviewing an IT director's SOA plan, he stated all services would be SOA web services in 90 days.  I was shocked (this is a large insurance company) by the speed of the portfolio transformation.  However, when I asked whether the statement meant their legacy messaging services (for example, their MQ portfolio) was being migrated and MQ turned off, the answer, was , 'NO'.        

MQ messaging endpoints and asynch endpoints should be part of your SOA plan. 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.