Enterprise SOA Roadmaps - Shrink Wrapped Architecture

[OwenPettiford]

When you are first shown the Enterprise SOA Adoption Program and drill down into the ESA Roadmap Method and its associated "accelerators" it can appear complex and difficult.   Having used it over the past year (creating 20+ roadmaps) I have come to the conclusion that the Enterprise SOA Roadmap Method is a powerful tool for Business Process Experts, Enterprise Architects, Solution Architects and Technology Architect, when explaining an end to end solutions to business and IT....even if it does take a bit of getting to know 🙂  It gives these groups a process and benefits centric way of working that can be used to articulate business solutions in a common format that can be viewed by different stakeholders to understand the proposed solution. For those readers who are familiar with the TOGAF methodology, the Enterprise SOA Roadmap represents a Shrink Wrapped Architecture Statement of Work. In fact I have worked with one client where we mapped one method to the other to show how close the overlap is.  Enterprise SOA Roadmaps create the following views on the candidate process :-   •     Business Architecture (Linkage to strategy, areas to improve, key steps required) •     Services Architecture (Functionality required to enable the process) •     Technology Architecture (Infrastructure required to enable the process/services) •     Implementation Timelines (how it all needs to fit together)  In my experience being able to create these views on a process (at the same time) can be of great value in getting organisations aligned to a solution.   Read on if you want to understand how this is done and the key steps involved……….. Step 1 – Create The Rules (Official Title - Create Strategy-to-ESA Mapping)  In this step we discover the design rules (architecture principles for the TOGAF heads) we will need later in the method to create a solution. Before we can create a suitable solution for the process to be Enterpise SOA’d we need to understand how the organisation wants to use flexibility, agility and consolidation. It is no good suggesting we migrate to a single system using a standardised process worldwide if the company has a strategy to divest divisions in the future or drives competitive advantage by providing country specific services !!!! This step also assesses the organisations maturity to adopt Enterprise SOA which we will use when we assess the sanity of the proposed solution. Step 2 – Understand The Process (Official Title - Transparency of Business and IT Landscape)    In this step we work on understanding the current process or most specifically the problems with the process. At this stage we focus on understanding the issues we will seek to fix in step 4 NOT on the solution to these problems. Also during this step we start to identify the business objects that are used in each step of the process. These are used to identify the candidate enterprise services. One key tip for this step is to keep the number of process steps to 7 +/- 2 or the deliverable will become too difficult to present. If more detail is required then further roadmaps can be created for sub-processes. Remember at this stage we are create a document which is about communicating ideas to different stakeholders NOT creating the final design….this can be done later.    Step 3 – Can Enterprise SOA Help ? (Official Title - Enterprise Services Architecture (ESA) Potential Analysis)  This step looks at each of the steps in the process and seeks to understand if we believe that Enterprise SOA can design out the process issues that have been identified and documents the magnitude of change required by the business to achieve the improvements. This is a really powerful tool to start making the stakeholders aware of the changes that are required to make the improvements stick. Without this understanding a successful change plan cannot be created for the proposed solution. Step 4 – Is It Practical ? (Official Title - Enterprise Services Architecture (ESA) Design)  With the preparation from the previous steps we are now in a position to analyse if our candidate services could be created for this organisation. We look at this from a number of different angle :- •     Strategic - Does the Enterprise Service and associated standardisation fit strategically ? •     Organisation - Does the organisation support the standardisation required to optimise the Enterprise Service ? •     Process - Are the process steps and master data in place to support the Enterprise Service ? •     Technical - Are the technology component in place to enable and manage the Enterprise Service ? •     Effort - Does the effort associated with the Enterprise Service make it feasible ?  Assuming we conclude that the Enterprise Service candidates are feasible we can now document the new process steps (again 7 +/- 2) articulating how they support the Business Architecture, the standardisation required to enable the services and the technology required to enable them…….Business-Services-Technology. Step 5 – Create The Roadmap (Official Title - ESA Strategy and Roadmap Definition)  So now we are in the final step of the process where we bring it all together….  Building up from the technology architecture we plot out the deployment and/or upgrade strategy required to create the enabling technology platform. With this in place we can map out the functional components that are required to render the services identified, together with any upgrades or configuration required. Finally we show how the functional and technical components are used to enable the Business Architecture.  Finally this does not have to take weeks to create….if you work with organisations that understand their processes, Enterprise SOA roadmaps can be created in a handful of days.