While significant attention has been paid to the benefits offered by service-oriented architecture (SOA), which has led to an increased understanding of the challenges that SOA poses as well, far less consideration has been given to the changes that this approach will impart on the IT organization itself. With the discussions around SOA having recently shifted from "if" and "why" to "when" and "how," three important questions now need to be addressed by organizations embarking on an SOA strategy: How will you manage your SOA, how will you pay for your SOA, and how will you staff your SOA?

As most would agree, using existing services within an SOA to develop and support new applications provides IT with the opportunity to take a quantum leap forward with regard to productivity and efficiency. As a result, enterprises can address a variety of process requirements faster and more completely than otherwise possible. However, this expanded reuse of existing assets is predicated on a consistent adherence to common standards, which requires most IT organizations to demonstrate far more discipline around governance than they've delivered to date. In reality, this approach produces faster development cycles that are running headfirst into the greater scrutiny required within an SOA, which significantly reduces margin of error as it eliminates many of the safety nets upon which enterprises have come to rely.

Consequently, Eric Austvold of AMR Research recently wrote [Service-Oriented Architectures: The Promise and the Challenge (October 6, 2005)], "SOA will expose the gap between the disciplined and undisciplined IT organization, creating the opportunity for fantastic success and spectacular failure." For example, competing SOA fiefdoms are rising in some organizations. At some point, mass confusion will emerge as these systems are unable to reconcile which "get credit" service is which. Instead of using SOA to streamline their operations, these organizations run the risk of adding further complexity as a new layer of middleware - the super SOA - is now needed to coordinate these various initiatives. The end result is that this "hybrid" approach further limits abstraction, cost effectiveness, and enterprise flexibility. What this means is that the approach to developing, deploying, and managing enterprise applications within an SOA needs to change to secure the promised benefits, and this process entails a variety of significant changes that impact the IT organization.

The Rise of the Shared Service Organization
Most IT organizations are already familiar with the concept of a shared service organization, which is often used to support the "common" assets of the enterprise such as mainframe computing, networks, and the corporate database infrastructure. Because applications are now becoming universal enterprise services, there is a need to increasingly view these individual services as a shared corporate asset as well. As such, the rationale of a shared service model as applied to other asset management requirements begins to make sense here as well.

For example, while many application development and deployment functions will remain closely tied to specific business units or operating groups, there is also an overriding need for the enterprise itself to govern the use of these common assets. As a matter of fact, the effectiveness of these governance efforts will be the key determinant of SOA success. Granted, some of these governance issues are technological in nature and can be solved with centralized registries, automated service monitoring, a common metadata repository, or through the use of an enterprise service bus. However, an even more fundamental need exists to simply define the standards that these technologies will use and to monitor and enforce usage requirements across the asset life cycle. To fulfill this requirement, an SOA Center of Excellence is needed.

Depending on the unique parameters of the organization and its culture, the role of the SOA Center of Excellence can range from light oversight or simple coordination through overriding responsibility for the delivery of services. In any of these scenarios, the fundamental goal should be the elimination of any doubt regarding the appropriate usage of a specific asset, and the SOA Center of Excellence should ultimately deliver the discipline and coordination needed to ensure efficient and effective operations.

As such, an SOA Center of Excellence should be entrusted with maintaining a single view of available services via a common registry along with their definitions. This organization would also be responsible for the enforcement of specific standards that govern usage such as metadata models, versioning standards, release protocols, and testing procedures.

Beyond just managing these services, the SOA Center of Excellence can also be used to deliver the necessary training and additional development standards needed to ensure a common SOA development methodology as well. The most forward-looking enterprises will even look to this organization to help prioritize long-term technology investments against existing business and IT requirements with a goal of ensuring that the SOA fully supports all of these requirements.

Another important role for the SOA Center of Excellence is helping to overcome the human factors that can potentially limit service reuse. As anyone who has ever run a development shop can attest, many projects are hampered by user concerns regarding the quality or suitability of "third-party" services, or by an unwillingness to make up-front investments that might only benefit those who are able to subsequently reuse the service as a result. In regard to overcoming this grassroots resistance by developers, a variety of "carrot & stick" approaches can and should be employed, and many of these enforcement tools fall under the existing mandate for service governance. With regard to the carrot, other ways to facilitate greater reuse of existing services include the integration of registry information into the development platform to maximize awareness of available services (this approach is typically supported by other forms of educational outreach). Because the ultimate goal is to create a culture in which service reuse is recognized and appreciated, it's not unreasonable to suggest that organizations tally "reusage" and respond and reward accordingly.

Paying the Piper
Of course, these added development and management steps produce additional up-front costs that the enterprise must address if it is to enjoy the benefit of subsequent reuse. With regard to specific models for addressing development costs, a number of approaches have already begun to emerge. The most simplistic and easy to implement is what I would call the "anti-enterprise" model, in which these additional costs are solely borne by the development group because they're the ones in the most immediate need of the core functionality. The additional cost associated with service enablement simply becomes a mandated requirement for all development efforts. Unfortunately, this approach is often shortsighted because it gives little incentive outside of decree for investing the additional funds needed to ensure widespread reuse of the developed service. As such, organizations are left to pursue the bare minimum as oppose to the optimal.

Likewise, some organizations have taken a "head in the sand" approach that completely ignores the issue of added cost, arguing that service reuse is so new a concept that little data exists for developing a cost model. Therefore, the true cost of service enablement is typically ignored within the overall budget. The challenge that this approach creates is that the IT organization or business group may be subsequently unable to show effective ROI for these projects. Thus, users have an incentive to do the bare minimum possible, including avoiding this requirement altogether.

Arguably, the best approach is to recognize these costs up front because this encourages both accountability and efficiency throughout the development process. For example, the added cost for service enablement can be defined as a fixed percentage of the total project cost and these additional costs are fully borne by a dedicated source of enterprise funding. With regard to specific budget parameters, a recent study by the Aberdeen Group offers some guidance. According to the research firm, a $10 billion company with a $300 million annual IT budget can save $30 million a year in five years by service-enabling 75 percent of their applications. As such, a $2 million fund for service enablement would result in a very favorable ROI.

In addition, enterprise budget models also need to address the costs associated with actual usage. For example, who bears the budgetary impact when a service developed by your group is subsequently employed as the cornerstone of another group's business model? For most organizations, the chargeback mechanisms or other activity-based pricing that they already employ become the model to be used for funding these ongoing costs. Specific mechanisms could include shared service units in which costs are closely tied to consumption, tiered service units that make allowance for each group's business objectives and modify pricing accordingly, or an enterprise pool model that relies upon headcount or other non-usage-based metrics. The important point to remember is that these fees are in lieu of additional development costs, and therefore represent significant savings for the business.