Although SOA is hardly a new concept, very few organizations have yet developed and rolled out a complete Service Oriented Architecture. There are many reasons for this, but I have found that in many cases there has not been a sound foundation built to ensure that the right architecture is used at the right time for the right problems. Also, business cases for SOA have been notoriously difficult to construct and sell to the purse string holders.
I believe that unless you view SOA as a journey not a single project, you are unlikely to achieve the full potential benefits of this architecture. For this journey you will need a roadmap that takes your organisation through a number of stages to gain value from SOA concepts and delivered systems. So here is my guide to developing your own SOA Roadmap.
Step One: Education, Education, Education
It is easy to make assumptions that business people and IT techies are familiar with SOA concepts and benefits. In most cases this is dangerous as, beyond knowing what the acronym stands for, few people really understand the value and impact of SOA on them or their business. Your shared vision of a process-driven, service-delivered enterprise needs an awful lot of education and training to get all of the necessary stakeholders across the business and IT to buy into the concept. So:
- Run internal education briefings, seminars and workshops to introduce anyone and everyone you can who will exposed to SOA projects in the early days.
- Ensure a standard vocabulary or taxonomy is created, agreed and used to communicate the basic concepts (what is a process, service, task, etc?)
- Continue these throughout the journey as people forget, new people join and the message will need refining over time.
Step Two: Enterprise SOA Strategy
The trick here is to think big, but take small steps. The three main components of this strategy are:
- An SOA Business Demand Assessment – linking SOA to business goals
- An SOA Sourcing Strategy – detailing how services will be delivered and funded
- An SOA Governance Strategy – organisational, development and implementation standards and best practices.
Step Three: SOA Reference SpecificationThis provides the high level conceptual and logical reference architectures for the services and components to deliver the service infrastructure. This should include:
- SOA Reference Architecture (Conceptual and Logical)
- Services Repository/Catalog (Business Services, Components, etc.)
- Taxonomy and Dictionary for shared understanding of service terminology.
Step Four: SOA Transition Planning
Moving from traditional “Buy or Build” to “Assemble and Re-use” is quite a culture shock for most organisations. You need to work out the best timelines and capabilities for the core business functions, and structure future programs and projects to take into account the demands that the new architecture could have on both business and IT. Outputs include:
- SOA Sequencing Plans and Roadmaps
- SOA Program and Project Profiles
- SOA Investment Plan
Step Five: SOA Transition Management
This is where many organisations have the greatest challenge. Even though everyone is vaguely aware of the impact of this change in approach, the shock of the planning hitting real business-critical projects can be too great for either the method or the project, leading to forced compromises or failures that taint the SOA message. The key to success here is strong governance and oversight of the projects across the whole lifecycle, coupled with ongoing education and training in the techniques and tools necessary to deliver true service-oriented systems. Structures required include:
- SOA Governance Framework, preferable supported by an SOA Centre of Excellence.
- SOA Development Lifecycle Management Methodology
- Service Registry for runtime invocation and management of services.
Step Six: Expectation Management
Many SOA projects fail not because they did not deliver value, but because they did not deliver the expected or promised benefits that were used to justify the initial investment. We have about ten years of disappointment that the reality of SOA has not matched the hype, particularly from the vendors. It is worth remembering that SOA is more a philosophy that a product, and should be part of an overall transformation programme of increased business flexibility and change. Make sure you keep everyone’s expectations in line with what is achievable. Bear in mind:
- Your organisation’s capacity for change and the speed at which change will need to happen to be successful.
- Get your Vision and Reference Architecture in place before buying any tools. The architecture must fit both your business and also your IT capabilities.
- Keep selling the benefits, and keep them aligned with (ever-changing) business demands. The world won’t stand still while you are struggling to deploy services.
So there you are. SOA has great value, but is not easy to do. So plan properly and enjoy the journey!
