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.

The implication for SOA is that the same fate can befall SOA service registries. Whether is it reusing code or adopting a service, there are a lot questions that potential users want to have answered before making a commitment. Obvious questions are: What's planned on the roadmap? Who is supporting the service? What are the known bugs and limitations? Who else is using it?

The final decision is really about mitigating the risk of adoption. The consumer might feel more comfortable if, through the interaction with a service's associated COI, they can get a sense for the service, its user base, and possibly even the consumer's own desire to become a contributing member of the project. The probability of adoption and the actual utilization of a service can be enhanced by enabling a discovery registry to provide easy access to the COI that is supporting the Web service.

Application Lifecycle Management
While SOA's impact on culture might be intuitive, what is not so obvious is its critical impact on application lifecycle management (ALM). Existing tools and software development processes may not be well aligned to support the move to SOA. At a macro level, an organization needs to understand that is it essentially migrating from insular LAN-centric development with a captive group of resources to a more open WAN-centric development environment with a diverse ecosystem of stakeholders.

In a recent interview on the importance of ALM, Gartner analyst Theresa Lanowitz commented that "As we start to bring forward this idea of a services-oriented architecture, and as we start to see services exist in a business-to-business environment, the services exist from two separate companies, and those services possibly are federated together in a loosely coupled environment. So we find the idea of the application ecosystem, the idea of a development ecosystem, is crucial as well, because there are going to be two different organizations creating a service that will have to be used together."

Many organizations are not prepared to address the need to support across the firewall software development with smaller agile teams from either a technology or process perspective. Figure 1 shows the ALM perspective of the potential impact of moving from monolithic IT applications to granular Web services.

From an open source project perspective, the right side of Figure 1 represents "business as usual" for many open source projects (i.e., smaller and geographically distributed individuals and teams employing agile development processes, working on some modularize software function or component, and using the Internet as the backbone for a software development platform). Project governance is often consensus driven and the project home becomes a focal point for code, context, and community.