The last couple of weeks I've been discussing the stages of adoption for web services and Service Oriented Architectures on different hierarchical levels - from developer to project managers to CTO's - in several companies. Interesting enough, it looks like the “SOA-hype” is fading out and the “SOA-solution” comes in – and is considered – as a "number 1" solution for a large number of the problems these enterprises are actually facing. However, during the talks we always came to the same topic: how to adopt a Service Oriented Architecture or where to start?
After explaining my thoughts and listing the stages of adoption a couple of times I thought … why not share them?
Probably there’s no one right answer in how to adopt SOA, but at least we could expect that most organisations will follow a similar path.
Before starting, an organisation should define the “service” concept: what are services in my company today? An answer could be: web services are the set of protocols by which services can be published, discovered and used in a technology neutral, standard form. And from a business perspective: which services are driving my business?
No matter what the “service” definition looks like - we all could agree that the existing forms of integration become simpler through the adoption of web services - most enterprises will start experimenting with web services in a development environment to become familiar with. This experimentation is most of the time adding an (external or newly created) web service to an existing application, creating a web services façade to a server application, creating an XML message router or adapting two existing applications to exchange data using web services. After this, all people involved will have a better understanding of the concepts of web services, the used development tools, the effectiveness of training needs and the overall benefits of web services.
The second step on the adoption path is to adapt existing systems to use web services. This will make it easier to use web services to “plug into” existing (legacy) systems. This kind of connectivity could be achieved by the use of adapters. Extend the adapters created in the experimentation phase, write new ones and start routing messages. Also, start connecting your application components to web services. Remember to start small!
The third step is to remove intersystem dependencies. This can be done by starting a refactoring process to factor out shared data and make each service responsible for its own state. This way one could say that an application is responsible for maintaining its own state by updating the data it is responsible for. By connecting to message routers and connecting the applications to web services adapters you can disentangle the intersystem dependencies. These dependencies restrict the flexibility of a service-oriented architecture. It’s worth mentioning that it’s perfectly possible that some applications should be separate systems!
When successfully gone through the previous steps on adopting web services and a service oriented architecture, all people involved should be able to start establishing an internal service-oriented architecture. At this point it is important to make some design considerations like determining the appropriate boundaries of each service in your architecture, will I opt for specific data-centric architecture or a unique distributed process architecture or – even better – a combination of both…
Once successfully achieved step four you can finally start extending your internal service oriented architecture to include external services. You should now be ready to start weaving together services from other systems or organisations into your system. Extending your system with an external service should be as simple as plugging it in into your system.
Besides all the technical issues you will have to solve, an excellent communication with all involved people in all stages of adoption is a key factor for success.
As a wrap-up I think that the adoption of web services and – web services as building blocks of service-oriented architectures - is useful in many cases and should be part of the most (forward-looking) enterprise software projects. Over time, the lack of SOA experience will become a competitive disadvantage for many enterprises. Whether you’re discussing with developers, project managers or CTO’s, they all must understand the essence of SOA and web services as well as their strengths and limitations in order to be able to identify their roles in modern application architectures and business solutions.
Meanwhile I’m looking forward to Indigo’s service-oriented programming model and how it will unify a broad array of distributed systems capabilities in a composable and extensible architecture, spanning transports, security systems, messaging patterns, encodings, network topologies and hosting models.