Who’s in Charge of your SOA?
As forward-looking enterprises move beyond the Service-Oriented Architecture (SOA) pilot stage and plan their cross-departmental SOA initiatives, they quickly come to the realization that the technology challenges they face are actually the easy part of their SOA rollout. Far more challenging are the organizational and management issues they must overcome to successfully meet their business goals for the initiative. Of these, the critical management issue (and here we mean management by humans, not systems management) is that of control. Who is in charge of defining, managing, and running the shared Services the SOA offers? How must a company organize itself to manage the dynamic business processes that people across the organization can now create by composing Services and other processes? And of course, how should a company pay for the whole mess — Services, processes, and the architecture itself?
The management and control issues that SOA introduce result from the fact that to maximize the business value of the architecture, a company should produce Services that diverse parts of the organization can share and reuse, as ZapThink explored in our last ZapFlash. As people across different departments build and manage composite applications, consisting of Service-Oriented processes that orchestrate such shared Services, it no longer makes sense to produce and manage those Services through today’s siloed IT org chart. Before, different parts of the IT organization were responsible for developing and managing specific applications, the network, the portal, the Web site, the call center, and other IT initiatives. With SOA, however, such a siloed organization can actually impede a company’s progress with SOA.
The necessary reorganization is nothing new to the world of IT. A decade ago, new corporate Web sites led to the development and creation of enterprise portals and online trading communities — and all of these new eBusiness initiatives also required a rethink of IT management and control. Who can forget the battles between IT and marketing over control of the Web site? Or how about trying to get each line-of-business (LOB) to pay for their part of the intranet portal? SOA raises such issues to an even higher and more urgent level, because with SOA, the Services represent a wide range of composable IT functionality that can come from any part of the company, its partners, or its customers for use within any of its processes.
Extending the Applicability of the Service Domain
The best way to get a handle on the SOA management and control issues is to follow the money. Customers drive the business, and the respective LOBs drive IT. SOA puts the power over business processes into the hands of the LOB users, and so, the lines of management and control should follow this pattern as well. As detailed in an earlier ZapFlash, Service domains — managed sets of Services sharing some common business context — provide a mechanism for the IT governance necessary for SOA management and control. However, while ZapThink explored the technical aspects of SOA governance in that article, in this ZapFlash we’re extending the role of Service domains to the business, and exploring how businesses can control and budget for those Service domains.
To make this leap, we can divide the Services available to the organization into Services or processes specific to particular LOBs, vs. those that different LOBs or other groups within the organization share in common. We’re using “Service” and “process” interchangeably here, because after all, in SOA, all processes are themselves exposed and consumed as Services. In the case of LOB-specific shared Services, the lines of budget and management should then flow directly from LOB executives to the LOB-specific Service domains, while in the case of cross-departmental shared Services, the organization must develop a shared budget and control mechanism for shared Service domains.
This delineation between LOB-specific and cross-organizational IT capabilities isn’t entirely new to many organizations. Recall once more the example of the corporate portal. Companies have generally solved the control and budget issues for these portals through a combination of chargebacks and “dotted line” management, where one IT group serves the needs of multiple LOBs, while reporting up through the IT organization to the CIO. LOB users produce requests for IT functionality as though the IT organization were itself a third-party service provider, with the costs allocated to various LOBs through charge-back mechanisms. Companies should thus handle the general responsibility for the running and maintenance of Service functionality through Service Level Agreements (SLAs) and contracts between the IT organization and the parties that it serves, while the office of the CIO should continue to handle operational management centrally.
With SOA, this matrix approach to IT management will run more deeply throughout the IT organization than before. As a company identifies and builds shared Services of an ever-growing variety, it will be increasingly important for the company to have a separate organization responsible for the management of those Services, where that organization reports up through (and receives budget from) all the LOBs its Services touch. In essence, companies should handle all Service-Oriented application development through the IT-as-a-third-party metaphor, even going so far as to offer enterprise architecture itself as a centralized capability that the company provides through SLAs and chargebacks.
The Human Cost of Change
This shift from siloed control over IT capabilities to matrixed, domain-based control represents the single most difficult aspect of moving to SOA. Compared to the human change management issues, the technology challenges are a piece of cake! Furthermore, the brunt of the change effort falls on the shoulders of those individuals who have been responsible for the various IT divisions that existed before the architectural shift. In other words, IT middle management has the most difficult time with SOA. Technical staff — developers, admins, and the like — are usually comfortable with the changes needed in the move to SOA, because SOA represents the opportunity to learn and use new techniques and technologies, and fundamentally extends existing investments in technology and infrastructure. Likewise, senior IT executive management often drives SOA based upon the business advantages that this new architectural approach offers, and thus can easily buy into the agility, cost-reduction, and governance benefits that SOA can offer the organization. Middle managers, however, face a loss of control over their hitherto protected areas of responsibility — and often cannot see how they might reap either the business or technical benefits that SOA offers.
The good news for such managers is that the reorganization that SOA should bring to the IT department will align IT capabilities with business needs more effectively than in the past. Where before, maintaining a particular legacy app, say, served the needs of a single LOB, now that application might provide functionality to one or more shared Services that several LOBs can now leverage. After all, providing clear value to the business is the most straightforward form of job security, and SOA can improve that value for many managers over time. Middle managers that might have once been responsible for a single, siloed application should expect to use their management skills in conjunction with the central enterprise architecture team, and leverage them on behalf of the business as a whole — improving IT’s responsiveness to business needs, and helping the business to realize the potential benefits of SOA in the process.
The ZapThink Take
ZapThink frequently makes the distinction between SOA and Service Orientation (SO), where SO represents the broader business transformation that the architectural shift to SOA enables. SO is not an IT-specific movement, but rather an overarching philosophy that identifies improved business techniques that better leverage IT resources for the business. As companies move to SOA and therefore begin to represent diverse IT functionality as discoverable, composable business Services, they will gradually be able to achieve the agility benefits that ZapThink frequently espouses. To obtain these benefits, however, it is essential that companies understand that the changes they must undergo are more business-oriented than technical.
Humans are by nature resistant to change, and this resistance manifests itself in the workplace, especially at large organizations where each individual represents a small cog in a very big wheel. Such organizations, however, still have a mandate to achieve the agility necessary to respond to customer needs, remain competitive, comply with ever-changing regulations, and keep their costs down in the process. Service Orientation promises dramatic increases in such agility, but the inherent inertia that organizations face impedes the act of adopting SOA itself. As a result, companies face the tantalizing Catch-22 of “we could be so much more agile if we were only a bit more agile,” keeping the benefits of SOA just out of reach. Today’s challenge, therefore, centers squarely on breaking this vicious cycle, and making the difficult changes necessary today to realize the much greater benefits of SOA tomorrow.