Home

Collaborating and Creating Shared Accountability for the Successful Implementation of SOA

Leo Barella, VP-Enterprise IT Data Intelligence Office, BCBSM

Leo Barella, VP-Enterprise IT Data Intelligence Office, BCBSM

With several years of experience both as an IT Executive and Consultant for Fortune 100 companies in leading Enterprise Architecture teams I have collected several practices in the implementation of Service Oriented Architecture that I will share with you. These recommendations have been refined throughout the years and they represent a summary of my “Rules of the Road” to successfully execute an enterprise implementation of SOA.

A comes after B: The success of implementing a Service Oriented Architecture is closely related to the definition of a Service Oriented Business or at least a business that fully understands the benefits of a SOA. Invest as much time as you can in educating the business executives of the organization on the SOA theory but make your examples applicable to some of the most pressing problems your organization is trying to solve. Use examples of solutions implementation without SOA and with SOA and make sure you do not just show them two pictures and let them figure out the difference. I find that walking them through a business process and showing them how different architecture components are impacted leads to a better understanding of the benefits. My simple way of narrating the difference is to use a process with five or six steps, use different colors to identify the different steps in the process and then paint the solution design with the process colors to highlight the differences between the solution with and without SOA. If you picked the right process candidate you should be able to notice a remarkable difference.

It’s a matter of Principles: One of the best recommendations I have to successfully implement a SOA Strategy is to define a set of Enterprise Integration Principles that are agreed upon by both the Business and IT. The principles should explain the Benefits to the business, the Rationale to implement the principle and the Implications to the Business in terms of impact to existing processes. In my experience this is a great way to communicate to the Business how projects will be governed moving forward. The shared definition of principle enables collaboration andcreates shared accountability for the successful implementation of SOA.

Data First: If you are starting a brand new Enterprise IT Architecture you might be able to connect your enterprise services to

your Core applications as they are most likely (hopefully) a short list of systems that enable your core processes and value streams. Most likely you are not in this ideal situation and you are starting with an application portfolio of dozens and perhaps hundreds of applications. If that is the case my recommendation is to tie your Enterprise Services to your data architecture Operational Data Store(s) rather than connecting them to your application architecture.

Form over Function: Spend time early in your SOA journey documenting and defining the design patterns that you, your team, other teams and the people that will come after you will use. For best implementations you should institute a peer review process that verifies that the design patterns that you defined are being followed. The good news is that there is a wealth of SOA design patterns available for you to choose from. The bad news is that you need to decide what design patterns are best for you and your organization. Another very useful exercise to improve the SOA understanding by the business is the definition of the enterprise data models.

“SOA is not about Technology, it’s about redefining how you will achieve process speed by leveraging a common integration foundation”

Often IT defines the data models based projects but to implement SOA successfully you must engage the business in the definition of all the enterprise attributes necessary to describe the different data domains that make up your enterprise data model. You can definitely start from industry data models available through third party organizations that have worked on these models for other companies in your same line of business but it is fundamental that these data models are customized to your own needs and most importantly that they are understood and agreed upon by the business.

People, Process, Technology: That is the correct order of implementation of SOA not the reverse order. Communication is possibly the most important factor in the successful implementation of the program and you need to have a clearly defined Communication and Education strategy as part of your overall SOA strategy. You can have the best SOA strategy and technology but with poor communication you will certainly fail. The communication needs to focus on the Why, before focusing on the what and the How. Think also to structure your communication plan Top Down (how will you communicate to the Business Executives and your Business Customers) and Bottom Up (how will you communicate to the Project Managers, Portfolio Owners and IT). Training is also very important and I recommend you invest in the development of an internal training program for IT Staff that you will make available to all the resources involved in the development of solutions including consultants and contractors.

Show me the Money: Most SOA implementations fail based on how SOA is being funded. Typically organizations address a SOA deployment as another IT project or program and they rely on project funding to build the entire architecture. That is a good plan but it often fails because of the omission of one or all the points I made above and most likely because a portfolio owner does not want to pay nor wait for IT to build an asset that will delay the implementation of their specific project. You must be able to clearly communicate how SOA will improve the speed of business while reducing cost for all business units of the company. To ease the business into the overall investment you can propose to centrally fund a pilot project and build only a minor subset of your overall architecture. Another suggestion to ease the business into centralized funding is to institute a SOA Governance Council made up of business representatives that will govern the dispensation of the funds from the SOA budget while value is being proven by your incremental progress and successes.

In conclusion: SOA is not about Technology, it’s about redefining how you will achieve process speed by leveraging a common integration foundation. To succeed you need to communicate the why before what and how. Think big and document your target state, start small to prove the value and scale fast by documenting your patterns and defining an effective and efficient training plan.