Service-Orientation, Service Oriented Architecture, web services, if you're not using the word service you're just not cool!! :-)

As explained in my previous post I'm currently preparing to get SOA certified and so it might be a good exercise for me to talk about service-orientation and SOA in my own words. To keep it readable this will be done in a series of articles, each focused on a specific topic.

Before I start the first article I want explain a naming convention. In a lot of articles and books the term "SOA" is used while they are actually talking about Service-Orientation (SO), SOA is actually part of SO. Mainly I'll be talking about SO but to keep things simple I will also use "SOA" for both definitions.

Introduction to SO(A)

SOA ≠ web services and you're not obliged to use web services to implement SOA. Are web services the best way to technically implement SOA? I'm confident to say yes but I do want to stress that web services are only the technical implementation of a service-oriented design. To make it short, it's not because you're using web services that you are doing SOA. Think of services as a collection of capabilities focused on a certain topic, this topic could be a business entity, a business process... (Invoice, Accounts Payable,...). In the next article(s) I will talk in more detail about services, their design and principles.

SOA is also not a pure technical idea, it doesn't only concern developers or architects. It concerns the business of the enterprise, short (tactical) and long (strategic) term goals, SOA can define how a WSDL will look like but it also defines who has access to technical documentation of the service, SLA's are also part of SOA.  Don't think of a SOA implementation as a single project within the company, each project should strive towards and contribute to a global SOA within the enterprise.

SOA is about centralizing "logic", making it available through standardized interfaces, managed by a centralized governance and has as purpose to deliver strategic goals and benefits to the company.

Standardized interfaces are very important as it can lighten the integration burden that exists in enterprises that use different development environments (.net, java...) and different application vendors (SAP, Microsoft...). In the case of web services these standardized interfaces will be WSDL for the service contract, XML and XSD for type declaration and WS-* standards (policy, reliability...).

The governance is responsible for how services are designed, developed, published, versioned and for standardizing the internal process to deliver those activities

Reaching SOA "utopia" is an evolution, most of the time you will start by using web services to connect or integrate with different applications, then service contracts will be more formally standardized, as the service inventory grows the need for governance over this will become mandatory to successfully maintain, evolve and version the inventory. But it's not necessarily a natural evolution, planning and preparation, such as an inventory blueprint, are needed for a successful evolution.

Let's have a look at some of the goals of SOA...

  • Increased Interoperability

    By consistently applying service principles and design standards (standardized contracts...) services are automatically interoperable. Because of the interoperability, integration processes start to fade. Services can be used and composed more naturally even if they were created by other teams/projects or if they were created in the past.

  • Increased Federation

    This means that applications and resources are united/composed but still maintain their autonomy and self governance. As with interoperability, the application of principles and standards is needed to achieve this unity.

  • Increased Vendor Diversification

    By designing a neutral service oriented architecture (i.e. web services) an organization has the possibility to choose the best products from different vendors. This gives the options to extend, change or replace vendor implementations without "destroying" the global architecture.

  • Increased Business and Technology Alignment

    To create the correct levels of abstraction and to determine service candidates the deep involvement of business experts is mandatory to create services that can withstand change and that can be recomposed if needed to follow the business changes.

...and now the benefits...

  • Increased Return on Investment

    As isolated applications need to grow and evolve over time so does the complexity and cost of managing the application. SOA advocates creating agnostic services that can be (re-)used and composed for different purposes. The initial creation of this piece of logic will have a greater cost compared to the creation of a classic application but it will be better positioned as an IT asset that will reduce the cost of change and evolution over time.

  • Increased Agility

    As the  service inventory grows over time with more and more agnostic services that don't belong to a certain application but are a real IT asset, IT can adapt more quickly to changing or new business requirements.

  • Reduced IT Burden

    As the SOA infrastructure grows and matures IT can focus more on adding value to the business and less on plumbing and integration. This will also reduce redundancy, overhead, size and the operational cost of IT withing the company and it increases efficiency and agility.

This was a little introduction into the what and why of SOA, the next articles will go deeper into the design and principles of services.