Tuesday, July 18, 2006

Thoughts on Service Oriented Architecture (SOA)

The concept of services within a business context are not new. We are all used to the following being thought of as a “service” provided to the business:

  • Shipping
  • Storage
  • Marketing
  • Payroll
  • Catering
  • Product technical support (Call centres)

And the list goes on. Interestingly, these services have lots in common:

  • They are managed and used in direct support of the business. They have a function to perform with a clear path showing how the service contributes to the success (or otherwise) of the business.
  • They can be “easily” swapped or replaced for an equivalent service from an alternative provider
  • They can be delivered by an internal group/division or by an external service provider
  • The product of the service and any input from the business that the service consumes is clearly defined and clearly understood by both the service provider and the consumer
  • They are often governed by well defined service level agreements
  • They support the ability for consumers (and providers) to measure (using service metrics or KPIs) the use of the service and the ability for it to deliver
  • They often support a fine-grained and open cost structure (audit trail, pay-per-use)
  • Without them a business would grind to a halt – but they are only normally a part of the business, not the whole!
  • They form part of the processes that define how the business works (sometimes a small part, sometimes a large part).

So service’s are not new: what is new is the view of software systems as another kind of service to the business. Before we look at what that means lets take a look back at how software (and to some extent IT in general) has been viewed in the past:

  • software as technology” – In “the beginning” (60s/70s) software was really just a technology, a science if you like. New developments were occurring at a rapid pace, and problems were being solved for the first time. In this era software was centrally deployed and managed (think thin-clients) – as hardware was still expensive. But software too was expensive : it was complex and expensive to build for vendors, but equally expensive to administer and support for consumers. Software and hardware were often bound together tightly.
  • software as product” – The view of software in the 1980s changed. With the advent of cheaper hardware the PC was born. And with it came shrink wrapped products aimed at the “owners” (users) of those PCs. Software was created by development houses, packaged and shipped to customers who installed it on their hardware. Support was provided as long as the customer had a licensed copy of the software.
  • software as project” – As software and IT became integral components to how a business operated, there was a shift in the 1990s towards custom software. Large projects were commissioned to create central software systems for use by the business. These projects were performed by internal IT groups or external software vendors. Sometimes the systems were customised (pick & mix) instances of large complex products (e.g. SAP, Axapta), others were technology-led and developed from the ground up. In recent times these projects have been categorised by late delivery or complete failure to deliver.

SOA is about the next step in this evolution towards “software as a service”, just like any other business service - with the same attributes discussed above.

This view of software really applies to software that makes up some key part of a business process. It does not apply to a calculator type application (personal tool). It applies to software that is central to the operation of the business and used by multiple people in order to communicate some kind of information between them. Typical examples are:

  • CRM and contact management tools
  • Electronic calendars
  • Travel booking systems
  • Time tracking
  • Etc.

But it is not just software within the business that can be modelled as a service, the interface between companies can be modelled as software services. This allows the service provider and it’s customers to conduct more business electronically: ”e-Business”. For example the primary interface to an external travel agent could be a set services for booking travel and managing preferences etc. This is not to say that other human interfaces are not required, just that the more business that can be conducted electronically the better since it is significantly cheaper. The ultimate vision of SOA is that every business function (internal and external) can be called as a service.

No comments: