Some people see SOA as just another IT trend, it’s more than that SOA is here and is working.  Many enterprises have launched SOA initiatives, the end goal being a more agile architecture allowing for quick response to business needs and requirement changes in relatively real-time.  SOA supplies a mechanism for resolving issues with systems that have floundered in a state of dysfunction for years.  According to analysts, SOA software spending will surpass the $15 billion mark by 2009.

            By having an SOA established, organizations can utilize existing systems and functionality in a organic environment, extracting the essence of applications into services that can be quickly reassemble resulting in new solutions.  A common question seems to “How do I get there from here?”  Similar to the human body, an SOA has a plethora of moving parts, causing difficulty in the ability to separate out the guiding principles that keep an initiative on track.

                 Fortunately, there has been such a large amount of SOA activity resulting in a bounty of best practices and lessons learned.  You can list the most critical of these on one hand: comprehend the anguish, establish the value-add, understand the “As-Is”, remember the Titans, focus on the “To-Be”.

Comprehend the anguish

                 In many enterprises the enterprise architecture actually impedes the agility of the business.  A recent survey discovered that about 10% of executives say that they are able to respond to changes in automated processes, and around half (50%) of those processes require IT consideration.

                To make matter even worse, CIO Magazine conducted a poll in which 36% of the respondents stated that their IT staffs were have significant issue maintaining  (27%) or could not maintain pace (9%) with the change business landscape.

                Over the years, IT organizations have suffered various levels of latency in supporting the agility of the business.  Executives twinge when IT organizations talk about years rather than months to accommodate new product and system suites, customers, or merger and acquisitions.  In many organizations IT is a leading factor is the organization’s success and it can eliminate the business all together if not rectified.

This is a real problem, that if resolved will be a tremendous advantage to many organizations.  Organizations can never forget that responsiveness is a main driver, and principle, of SOA.

Establish the value-add

               SOA is generally implemented for two main reasons.  The first reason is to reduce development cost through the reuse of services.  The ability to reuse services, developed internal or external, in multiple engagements increases ROI. The second reason is to be able to quickly change the IT infrastructure and accommodate the shift in business needs and requirements, provides a strategic advantage and can provide organizations the chance to survive long-term.

              When quantifying the value of reuse organizations should consider several factors 1) the number of reusable services, 2) the complexity of those services, and 3) the degree of reuse in multiple efforts.  Service complexity is a key to assessing value; this can be defined as the number of operations or interfaces that make up the service.  Another important key is the number of instances organizations expect to reuse a particular service.

              The ROI of agility is hard to determine but not impossible.  Several things must be ascertained about the business, including the degree of modifications over time, the ability to adapt to change, and the relative value of change.

              The degree of change is the number of times an organization reinvents itself, over a given period of time, in order to adapt to a marketplace.  For instance, a paper company may only experience a change of 5% over a five year time frame whereas a high-tech company may experience an 80% degree of change over the same period.

              Organizations must accurately describe its current ability to adapt to change, when estimating the value of an SOA, and project to what degree that ability will increase once an SOA has been implemented.

              The relative degree of change is the level of money made as a direct result of changing the business.  For instance, if a retailer wanted to institute a buyer loyalty program, the shorter time to market fostered by an SOA will provide an outcome of higher revenue at reduced cost.  In some cases it might not even be practical to institute such a program without having implemented an SOA.

Understand the “As-Is”

              Many people seem to have some sense of what an SOA is, but few have clear vision on how to achieve an SOA.  Sense every situation is unique there is not a single authoritative set of rules, however there are some common themes that are beginning to emerge which could assist organizations in understanding the journey ahead.

1)     IT organizations should understand business objectives and define success.  IT organizations should be assisting in the daily business operations and the technology they add to the organization must affect the bottom line in a positive manner.  It is essential for organizations to articulate objectives early on, this includes defining success criteria.

2)     Any project will have stakeholder and participants, SOA projects are no different.  It is critical for organizations to identify those stakeholders in order to garner requirements, support, and measures of success.

3)     The problem domain and scope must be defined.  Some organizations have attempted to “boil the ocean” which has only lead to failure of those SOA efforts.  SOA implementation is best performed in evolutionary cycles, small steps.  For instance, transforming a business unit, or portion of a business unit, to an SOA.  These small SOA successes will lead to larger, more strategic, successes over time.

a.       As part of decomposing the domain, organizations must understand all of the application semantics for the given domain.  Organizations must understand information, including information associated with behavior (services), in order to handle it.  It is critical for organizations to identify all application semantics, metadata, for the domain in order to handle that data.  Having a coherent framework for application semantics provides insight into how specific applications relate to the activities of business processes and in what form.

4)     Organizations must understand all the processes in the domain.  All the business processes that exist within the domain should be defined and documented.  These processes may be completely, or partially, manual processes.  This step can be aided by developing use case scenarios of daily business operations, “a day in the life of”. Once organizations have defined all of the high-level, mid-level, and low-level processes they need to identify candidate services that could perform the tasks in those processes and inventory the available services that assist in realizing those processes.

5)     It is essential that organizations understand all the available services in the domain.  A best practice here is to establish an enterprise catalog, registry repository.  This catalog provides access to information about the available services, as well as supporting documentation for each service — including a description of the service’s purpose, the message exchanges of the service, and so forth.  This catalog, in conjunction with application semantics, is used to define the integration points of all the systems in the domain

6)     Organizations now must select a set of technology.  Many organizations want to begin with this step, not a good idea prone to failure.  The appropriate SOA technologies can not be selected without understanding the requirements.  A pilot project is often required to prove the technology will work this marries the criteria with product.  The time required to select the appropriate technologies may equal the time required to construct the SOA, but the investment is worthwhile because selecting inappropriate technology practically ensures failure of the SOA.

7)     Finally develop a certification and accreditation approach.  An approach to testing, certifying, and accrediting is essential due to the difficulty in testing SOA solutions.  Service orientation adds dependencies, and an SOA by its very nature should be extensible beyond the current purpose, and SOAs have many moving parts.  Many of the sources in an SOA are business critical applications that can not be taken offline and testing of such systems must be comprehensive eventhough it may be difficult.

    Steps 3a through 5 should to be performed iteratively in order to develop use cases for all the business processes, identify candidate services, and inventory available services.  Some of the services may require composition in order to satisfy the requirements of the business processes.

Remember the Titans

              Many organizations seem to neglect the most important aspect of SOA, the people.  When considering the impact of SOA on an organization, we can not simply consider the enterprise architecture but also must consider SOA impact on the people.  There are two areas of people that need attention: the SOA-competency of those who are tasked with constructing the SOA and the skill levels of those who will be using the services and interfaces of the SOA.

              Not only do those tasked with constructing the SOA need to have a firm grasp of the concepts, approaches, and technology of SOA but also of traditional enterprise architecture.  Many organizations will struggle with this issue and external resources may need to be required for mentoring in the early stages of adoption.  Internal training on approaches, tactics, and ecosystem technology should be an ongoing effort.

              Not having this support will lead to failure of the people and the SOA itself.  Organizations have one of two choices in this matter 1) hire external consultancy services in order to plant the seeds of SOA knowledge in the organization or 2) hire new people who are better suited for the execution of an SOA project.  This is a difficult decision but could save the SOA project.

              Organizations must also consider those who will be using the services, processes, and data abstractions in new visual applications.  There are a few questions that must be considered and answered, sooner than later:

• How with this change the way they perform their jobs?

• How will organizations train them?

• How will organizations capture their suggestions for improvements?

• How will organizations support them?

Focus on the “To-Be”

               An SOA is not a quick fix but rather a long-term solution.  Organizations should not expect and significant ROI in the short term.  Most organizations will realize understand value in years rather than months.

              This can be a hard pill to swallow for most American organizations when they operate on a quarter by quarter basis, and budgets and objectives change month to month.  Some organizations have difficulty in maintaining long-term projects, which are complex and systemic, such as SOA across the organization.

              A key piece of advice is to garner executive level investment and commitment, which will provide the political weight to protect projects, and the bully pulpit to sway people of the long-term value and importance of SOA to the business.  If there is no executive sponsorship then the SOA effort is doomed to failure.  If organizations try to use SOA as a quick fix, it will simply layer more complexity onto the enterprise technology infrastructure.  Even the simplest SOA project is doomed to failure without long-term organizational commitment.