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 ca
