One way to ensure the success of these programs is through the use of a common fund for supplemental funding. For example, consumption-based pricing typically reflects a pro-rated portion of the overall cost. Therefore, what happens when projected usage falls 50 percent short - do you double your per-usage costs? Not if you hope to encourage long-term support for these services by various business units. As such, the shortfall could be addressed through the use of an enterprise fund for SOA, which would minimize cost fluctuations that would otherwise deter adoption by covering this gap. Likewise, in cases of over-subscription in which usage and therefore fees are higher than projected, this overage should be returned to this common fund.

Prepare to Change Your Relationship with the Business
A key topic of late has been the interrelationship between SOA and business process management (BPM). Depending upon where you sit within the organization - IT or line-of-business - you are probably hearing that BPM is a key component of SOA or vice versa. In reality, both perspectives are accurate because the process of decoupling business logic from the application itself is the basis for an SOA, but it is the building block for a successful BPM strategy as well.

What this means is that your shift to a more process-driven approach to IT is poised to accelerate. For example, because a library of services is now readily available, you can move beyond your need to solve underlying integration and development challenges to focus more extensively on stringing together entire business processes. While this is a potentially overused concept, the real payoff is closer alignment between business and IT in which business requirements can now be more quickly, accurately, and fully addressed by IT.

While this closer collaboration with the line-of-business is obviously a positive development, it also needs to be handled with care. Specifically, shorter development times make it harder to shield the business from the real-world hiccups that plague all development efforts because the potential to make up time no longer exists. Likewise, this tighter relationship also creates the potential for more ad hoc development, which can quickly expand the scope of projects to such a degree that timeline and other objectives are no longer being met consistently.

As such, IT must strive to create even stronger bonds and understanding of its line-of-business counterparts. Specifically, with the line-of-business more directly embedded in the development process, they need to secure a better understanding of what's possible in the near term and what's needed in the long term so that projects can be undertaken in the most efficient and effective manner possible. All people within the IT organization must be prepared to evolve their role beyond simply fulfilling requests on a reactive basis so that they can become relationship managers who support and enable a collaborative partnership with the line-of-business.

Who Owns the SOA?
Over time, a fairly consistent model for the application development team has emerged. The following roles are most common:

• Business/IT Strategy: Nominally, the CIO or other senior official who is charged with defining long-term IT strategy in alignment with specific business objectives
• Business Development: Typically, a business analyst or similar role that helps to define the specific business parameters and reporting outputs of an application
• IT Organizational Governance: Most frequently, a centralized group that creates and enforces both standards and processes that govern application usage
• Enterprise Architecture: The architect is responsible for creating the necessary framework for delivering asset functionality with a specific focus on minimizing implementation, runtime, and evolution costs along with complexity, downtime, and technology risk
• Enterprise Integration: Project teams that support and enable business processes by connecting together various applications and systems
• Application Delivery: Developers that create and implement both packaged applications and customized development

In the first scenario, which often represents a highly decentralized organization, the enterprise architects typically serve as "technicians" tasked with supporting the underlying resource teams as they add new functionality to the existing enterprise architecture. As these organizations evolve toward a more centralized and hierarchical approach - the top-down model - the architect often assumes greater responsibility for enterprise governance and standards and the existing IT governance organization becomes more of an enforcement arm as a result. However, even in this model, they fail to assume significant responsibility for the business success of these IT initiatives.

With the rise of SOA, the line-of-business alignment model is most likely to dominate due to the architect's fundamental role in ensuring that services are structured to encourage the most widespread reuse possible. In many ways, the abstraction of business logic as a service means that architects begin to fulfill many of the functions of the business analyst, which enables their ascension up the stack. For many organizations, this is a fairly progressive model in which the architects play a role that is fully integrated with the business objectives of the enterprise because they are charged with proactively creating the most efficient and effective model for addressing these requirements over the long term.

With this evolution, one can expect SOA adoption to specifically impact each of these roles as follows:

• Business/IT Strategy: Managing ongoing relationships with the line-of-business becomes even more critical as the boundary between these two disciplines begins to disappear. Coupled with the shift toward more process-driven approaches to IT, IT leaders need to develop an even deeper understanding of the business so they can proactively plan and provision for requirements that are currently too often met on an ad hoc basis. They should also strive to push this philosophy downstream, eliminating the silos that exist within the IT organization and ultimately ensuring that their staff can be more closely integrated with business requirements.
• Enterprise Architecture: As noted earlier, the fundamental role that the architect plays in enabling an SOA means greater accountability because they're now playing a more direct and hands-on role in the successful delivery of services. As a result, instead of a technology-first mindset, they'll be increasingly called upon to take a business-first approach. At the same time, they'll also need to play a greater operational role as architecture decisions become real time and thus, have a more direct and immediate impact on the business.
• Business Development: In addition to their existing responsibilities for defining requirements and analyzing results, these business analysts are now poised to become process architects entrusted with designing, implementing, and monitoring these processes. With this change comes the need for an even greater understanding of business semantics as a requirement for defining process. Their analytical skills will also be increasingly tested by the expanded use of real-time monitoring within an SOA environment, and strict adherence to process improvement disciplines around their use of Key Performance Indicators (KPIs) are an absolute must.
• IT Organizational Governance: This role will have the greatest day-to-day impact in determining the scalability of the SOA strategy since they're responsible for enforcing discipline around governance. As such, a relatively minor organization today is likely to increase in importance within an SOA due to their ownership of the underlying registry. That said, they also face the risk of being subsumed by an expanded office of the chief architect. In either case, one of the key roles that they're likely to play is akin to a traffic cop as they prioritize the implementation of various projects in accordance with line-of-business requirements. Because the invocation of services is fundamental to business process management, they'll also be called upon to develop a greater understanding of process parameters with regard to how they impact specific asset management, change management, and configuration management requirements.
• Enterprise Integration: Based on their experience in managing Integration Competency Centers, which is one model for an SOA Center of Excellence, these project teams have the potential to expand their influence throughout the enterprise by assuming this complementary function. Of course, this is predicated upon their ability to move beyond a project-based mentality to embrace a more long-term and strategic perspective in which they serve as the protector of these critical assets. What this entails is an even greater focus on Web services management because this brings forth the required discipline needed to best manage the entire asset life cycle.
• Application Delivery: SOA heralds the further industrialization of IT, which challenges these traditional craftsmen. Successful developers will need to take a broader view of the business and look to create and implement applications that address both immediate, tactical requirements as well as more long-term, strategic objectives. These efforts will see their greatest impact within the expanded use of metadata to capture key information, such as policy requirements, service definition, and the abstraction of business rules, within a reusable and independent business container.