As numerous organizations are planning to embark on their first endeavors in service-oriented architecture (SOA), it is important to recognize that the necessary organizational transformation has as much to do with cultural transformation, as it has to do with open, Internet standards-based design. In fact, the very nature of how business and IT view each other's role and how the enterprise views its relationships with its marketplace partners and customers is being altered. Such cultural change has never come easily and represents a significant organizational dilemma.

At the heart of an enterprise SOA transformation is also the need to "think differently" about how an enterprise acquires and manages IT systems. Albert Einstein might well have been talking about the challenges of SOA rollout when he said, "No problem can be solved by the same level of consciousness that created it." Building service-based systems involves a shift in thinking from large-scale, centrally planned IT systems to smaller, modular development that requires collaboration and consensus building among all of the stakeholders of an end-to-end IT process.

These aspects of SOA transformation alone represent a large impediment to success for most organizations. Some simple questions that can highlight the importance are: How well do your business and IT stakeholders collaborate in the fielding of new business functions? How well do you execute globally distributed software development - not only within your enterprise, but also in the extended enterprise that includes partners, suppliers, and clients? Do you have a successful culture of component-based design and software reuse? Do you consider the elimination of silos within your enterprise to be a major goal? How well aligned are your operations infrastructure and capabilities with the role of IT service provider?

The aforementioned questions lead to a few aspects of open source principles and characteristics that may mitigate or address some of the significant challenges of SOA transformation. Table 1 lists SOA challenges matched with associated open source characteristics. The list is by no means comprehensive, but it is thorough enough to show the potential relationship in applying open source principles to the business problem of implementing SOA.

Given the success of open source software, the overall premise is that at a minimum there is something that can be learned from the open source development model, which enables organizations to become service-oriented enterprises (SOE).

Problem Illustration
The starting point for many SOA transformations is the desire of the enterprise to define an overall enterprise architecture (EA). EA is often employed as the tool of business modernization. In any EA initiative, the first step is usually an evaluation of the current state of affairs by means of assessment. The EA assessment usually reveals a map of redundancies across business processes and systems. These redundancies become the "low hanging fruit" for the first areas to be targeted for migration to enterprise services.

An oversimplified example might be an organization with multiple business systems, all of which require a software process to calculate loan risk or interest rate. Upon such a discovery, a natural inclination might be to fund a project to create a common shared service that could be leveraged by all such business systems. Although this approach is logical and has an obvious supporting ROI, the actual implementation will require more consideration and effort.

The first problem is the cultural bias of the existing business systems owners. Some will seek exemptions to not participate, usually based upon some notion that their requirements are somehow unique (i.e., somehow the financial aspects of the math are different for them). The real underlying reasons can run the gambit of NIH, concerns over support, or a reluctance to develop dependencies on other organizations or departments. These are some of the cultural dynamics that are often at work, which tend undermine efforts to create reusable SOA components.

A second problem is very tangible in the sense that building a shared service for this calculation may not be the right thing to do in all cases. Assume we deploy an enterprise service and institute a governance model where we instruct engineers to invoke this service directly rather than running their own copy of the software on their own systems. Well, that might work for some applications that only need to invoke that service a couple of times a minute, but what about other applications that need to invoke it hundreds of times per second, or are in latency-critical situations, such as rendering a Web page? In this case we might option for building the software process as both an "open standard" by giving it a Web services interface and as "open code" by publishing the source and allowing it to be run locally.

This example hopefully provides an appreciation for the application of open source principles in an attempt to address a complex issue. In addressing the cultural problem, we could adopt a community-based development approach in which business systems owners collaboratively participate in the development of a new solution. Such a shared development model could mitigate perceived risks of support and inflexible organizational dependencies. In the performance-based design problem, having easy access to source code and a supporting community of interest (COI) might enable the best solution to be applied. This would still be in general alignment with the goals of reducing development redundancy and having consistent enterprise architecture.

Some Focus Areas
According to the Yankee Group's "2004 Enterprise Web Service Study," 75 percent of the more than 400 US IT organizations surveyed are planning to invest in SOA approaches over the next 12 months. This seems reasonable because in any large-scale organization, the concept of enterprise shared services that employ component-based design is not new and is easily understood for its cost benefits. Often, "where to begin" is the harder problem and reflects where open source processes might be applied.

Driving Adoption and Utilization
In the end, what makes for a successful Web service is fundamentally a case based on whether or not anyone cares. Success is really a proof point based on actual adoption and utilization levels. Successful open source projects understand this point and invest some significant percentage of effort to support and grow the COI around the project. There is a strong correlation between how open source COIs grow and how to succeed in creating highly successful SOA components.

A case in point is discovery. The question is whether or not discovery via UDDI registry or other means is sufficient by itself to drive a service's adoption rate? This problem is analogous to the push to develop reusable software assets based upon traditional component-based design. Many enterprises implemented so called "component repositories" where they encouraged the developers to register their components after development was complete to make them easy to discover.

The theory was that engineering leads and project managers would occasionally search this library of components and reuse them if possible. Given the amount of serious and sustained attempts by qualified organizations and smart people, the fact seems to remain that software reuse initiatives are rarely as successful as has been hoped. Many of these repositories ended up looking like a kitchen junk drawer.