Taking an organization through a service oriented architecture implementation is an evolving process which needs the right approach to succeed. These six critical steps will put you on a sound footing.
Within the span of a few years service oriented architecture (SOA) has evolved from an esoteric technology niche, known only to a small group of technology cognoscenti, to a critical IT and business strategy discussed by virtually everyone within the IT executive ranks. Most companies today are either investigating SOA or have launched SOA-related initiatives during the past 18 months. However a major area of concern and frustration seems to be focused on execution. As with many past technology trends, the potential of SOA could remain largely unrealized unless organizations are able to execute successfully on both the technology and business levels.
Having been involved with numerous SOA projects, we have learned a number of important lessons. By adopting the lessons learned we have been able to dramatically mitigate the risks in subsequent SOA initiatives.
So let’s take a look at six of the most crucial steps a CIO can take when planning and building an SOA vision.
> Step 1:
Map SOA to your business
To be successful, organizations must approach SOA from outside the traditional technology boundaries. Rather than trying to map your business goals and requirements onto your SOA vision, try focusing on the key business drivers and map your SOA requirements so that they become an extension of the business goals. Use this as a mechanism to establish cooperation and co-ownership between IT and the business community.
A practical way to achieve this is by identifying key pain points, usually something like a broken business process or a requirement to get a single coherent view of customer information. These examples often require the integration and coordination of data that may span multiple applications and business processes and can be good use cases for the principles of SOA.
By involving the business users in the process you inspire their support and active participation, which can lead to the development of solid business cases for SOA.
> Step 2:
Take a long view and implement incrementally
SOA does not represent a quick fix to long-standing IT and business challenges. It is a long-term strategy, the impact and benefits of which cannot be realized over the short term. This may be one of the most important messages to convey upfront to stakeholders.
In order to plan for and accommodate the long-term nature of SOA, one should start out in a gradual fashion. We recommend starting on a smaller scale by first building the core infrastructure, skills and fundamental knowledge before starting with the larger and more critical phases. This not only allows for the tight management of risks associated with SOA, but it also enables one to learn from the experience and to improve the approach over time.
Most of the value and benefits of SOA will manifest over time (these must be measured over a period of years). Reuse, for example, will not happen overnight. But the momentum will slowly grow as developers get more used to the notion of developing and reusing services, which in turn will lead to services becoming ubiquitous within the enterprise.
> Step 3:
Plot your course by creating an SOA Plan
Many companies are taking the right approach here by creating a comprehensive SOA reference architecture and execution plan. This is an indication of the maturity level of SOA within these organizations. However, it is important to remember that SOA should be viewed as a long-term strategy and the planning should therefore reflect that reality. In order to follow the step-wise approach, it’s important to model SOA initiatives into manageable pieces that can be implemented over time.
> Step 4:
Gather your talent
With the introduction of SOA, IT is presented with new techniques and new opportunities. We are being challenged to rethink the approach we take to the integration of diverse applications, most of which have been designed in a very monolithic fashion. Most of our education, training and experience revolve around application design and very little thought has been given to inter-application integration.
A good analogy is the difference in perspective between an architect and a city planner. Both have very different backgrounds and education, as well as different priorities. Whereas the architect is focused on designing a new building, the city planner is focused on the larger context in which the new building will fit, namely the city. Likewise we are faced with a similar situation within IT. Developers are focused on application design, and usually don’t consider how the applications they are building will integrate with the surrounding business applications. The IT architect is more concerned with the integration issue and looks at the larger IT context.
It is important to acknowledge the fact that we have to adjust our attitude and approach to basic application design. It is also important to realize that the IT architect (city planner) has an important role to play to ensure that new or existing applications can be integrated into the SOA fabric.
To do SOA successfully, managers must cultivate their talent. Assemble a core team of people who understand SOA (or provide them the appropriate SOA training) and who can spread the initiative within the organization.
This core team will be crucial to driving the success and adoption of SOA. This team should consist of people experienced and knowledgeable in technology and application design. It should also include members who are conversant in the business aspects. As IT evolves into more of a consulting partner to business, IT professionals must become more business savvy.
Some of the roles that should form a key part of the SOA Team include:
- SOA Steering Board (CTO, Business Stakeholder, CIO, VP Architecture and VP Development)
- SOA Architecture Authority (VP Architecture, Enterprise Security Architect, Enterprise Integration Architect, Enterprise Data Architect, Service Librarian)
- Services Portfolio Management (Business Sponsor, Portfolio Lead, Development Team)
- SOA Enablement Group (SOA Architect, Key Services Developers, Key Domain Experts)
- Services Infrastructure Team (Operations Lead, Key Architects) This is by no means an exhaustive list, but it gives a glimpse into the type of roles that should be involved, and the functional part they must play in the overall SOA initiative.
> Step 5:
Reuse, Reuse, Reuse
Reuse is a driving force behind the adoption of SOA. What few companies have done well is to measure the levels of services and infrastructure reuse.
One way to address this issue is to define the metrics that will be used to measure reuse. Do this early in the life cycle, before you go live with your SOA project. Also establish mechanisms to measure the real levels of reuse. There are a number of ways this can be accomplished.
For example, you can implement an SOA management framework so that you can monitor real-time runtime behavior. This will enable you not only to track which services are available, but also how they are being used and how often they are being called. As a result you should be able to track performance and quality of services available.
You can also gather and track the Enterprise Service Bus (ESB) usage statistics. Many SOA initiatives use an ESB as an integral part of the infrastructure, especially when reliability is a consideration or you need to switch between protocols. With the ESB as a central part of the SOA architecture, one is able to track with a high degree of accuracy the levels of reuse of the services and infrastructure.
> Step 6:
Measure the results
And impact
The final crucial step to the overall success of your SOA initiative is measuring the impact and results of the SOA implementation. Step one referred to the need to build a strong business case, but at some point IT has to prove to the business that doing SOA has had a positive impact. The CFO usually will look at the ROI and TCO numbers to determine whether the effort was worth the investment. Business users will measure the impact of SOA through the impact (both positive and negative) it has had on their domain. They will measure success in terms of improved processes and productivity, cost savings and increased revenue; they may even measure success in terms of their ability to respond to new customers.
These are very different metrics than have traditionally been used by IT. It is therefore critical that IT define criteria and metrics that can be used to track and measure the impact of the SOA initiative on IT as well as business. To do this in a credible fashion the business stakeholders have to contribute to the performance models. In many instances we advise customers to get their CFO or someone from the CFO’s office involved in building the ROI model. This usually lends a lot of credibility to the ROI figures since the number will reflect reality. Some customers who have done this were quite surprised by the outcome, since the ROI models were far more positive and the business impact of SOA was felt far wider within the organization than anticipated. As they say, “success breeds success”, so use this to your advantage in building continual support for the ongoing SOA efforts.
Consider this a brief introduction to some of the steps you may take to put your SOA initiative on the right track. The golden rule is to start small; remember it is not necessary to build the entire infrastructure in the first iteration of your SOA project and it is also not necessary to convert every application or business function into a service. Take incremental steps while building organizational support from within the business community as well as from within IT.
SOA ultimately is a transformational instrument for business, and organizations that embrace it well have the potential to create substantial cost savings and competitive advantage.
QuickLink: 064420
Theo Beack is the Deputy Chief Technology Officer at BEA Systems. He has more than 15 years experience in software development, Web development, database administration, application integration and software architecture & design.