Service Oriented Architecture (SOA)

For years I thought SOA was an architecture and associated methodology that was largely pie in the sky designed by large technology service providers to generate recurring professional services revenue and ensure captive corporate clients.

However now that web standards and open source technologies have made a major impact on the proprietary technology stacks used in most corporates, the world has changed, skills are widely available and technology diversity is an everyday reality (or nightmare might be more accurate).

Personally, I think that not only has the time for SOA arrived but it has crept up and become part of the mainstream without people formally discussing it or agreeing it, sort of like SMS abbreviations were just organically adopted by some people and went mainstream but if a bunch of geeks declared the LOL, ROFL or LMAO standards they would be derided.

So, in the spirit of recognising and building on the shoulders of giants, it is important to mention the SOA Manifesto which, while widely noted was not widely formally adopted. We have adapted and prioritised it slightly here as –

The ‘Business Centric’ or ‘Six Peas’ version of the SOA Manifesto

Paradigm Payback (3 layers)

Service orientation is a paradigm that frames almost every business technology management strategy and implementation decision.  Service-oriented architecture (SOA) is a type of architecture that results from applying this paradigm. Applying service orientation helps organizations consistently deliver sustainable business value, with increased agility and cost effectiveness, in line with changing business needs.

Prioritise Pragmatically (12 items)

Value the items on the right, but value the items on the left more –

  • Business value over technical strategy
  • Strategic goals over project-specific benefits
  • Intrinsic interoperability over custom integration
  • Shared services over specific-purpose implementations
  • Flexibility over optimisation
  • Evolutionary refinement over pursuit of initial perfection

Principled Process (14 points)

  • The scope of SOA adoption can vary. Keep efforts manageable and within meaningful boundaries
  • Verify that services satisfy business requirements and goals
  • Evolve services and their organization in response to real use
  • Separate the different aspects of a system that change at different rates
  • Reduce implicit dependencies and publish all external dependencies to increase robustness and reduce the impact of change
  • At every level of abstraction, organize each service around a cohesive and manageable unit of functionality
  • Respect the social and power structure of the organization
  • Recognise that SOA ultimately demands change on many levels
  • Products and standards alone will neither give you SOA nor apply the service orientation paradigm for you
  • SOA can be realized through a variety of technologies and standards.
  • Establish a uniform set of enterprise standards and policies based on industry, de facto, and community standards.
  • Pursue uniformity on the outside while allowing diversity on the inside.
  • Identify services through collaboration with business and technology stakeholders.
  • Maximize service usage by considering the current and future scope of utilization.

With full credit to the original SOA Manifesto (of which we are a signatory) and the associated team of authors. This declaration is about to celebrate its second birthday in a couple of months and I think the SOAM era is now well under way.