The Economic, Cultural and Governance Issues of SOA

By Marcia Gulesian

(Back to article)

Service-oriented architecture (SOA) provides a way of aligning the business strategy and imperatives of an enterprise with its IT initiatives. Thus, SOA governance is as much about organizational issues and how people work together to achieve business goals as it is about technology.

Governance is about getting approval for changes, about power, about who wields that decision-making power and how long such decisions take, given the speed of business change. SOA can reduce the need for IT governance dramatically by reducing the incidence of decision-making. However, in order to derive this benefit, your enterprise must first adopt SOA.

Other Articles by Marcia Gulesian

SaaS: Financial, Legal & Negotiation Issues

Achieving Enterprise Xen

SOX, SOA and Executive Behavior

IT Forecasts, Budgets and Post Audits

Yet Another Business Case For Proactive IT Capacity Planning
FREE IT Management Newsletters

The SOA Evolution

SOA adoption does not provide a quick ROI, but requires strategic investments, including investments in governance and a cultural change to align IT and business. Nonetheless, according to Gartner, it is not a question of whether an SOA will supplant today’s architectures, but rather, how long it will take to complete this evolution.

A huge roadblock for many organizations wanting to adopt SOA is their current IT cost allocation models. Many companies associate project development and support costs one-for-one to the line of business or department that has authorized the project. In SOA, where the services are often shared between multiple applications and lines of business, this can mean a project participating within your SOA strategy is actually billed for everyone who comes after.

A better approach is to create a shared allocation structure for SOA application assets, and even to offset SOA development costs that may be above and beyond what stand-alone development would cost in a non-SOA way.

Because reuse benefits come only after there are multiple consumers of a service, there must be an incentive to ensure services are published and designed for reuse. Similarly, there must be incentives to promote taking advantage of existing enterprise services. This is especially difficult to accomplish when you are outsourcing projects, which is something you should actively manage.

Organizations seem to overlook governance and enforcement activities more easily when dealing with their implementation partners. This happens for many reasons. For one, the decision to outsource certain projects is often made by individual business units outside the scope of IT. Even within IT, the focus on approved vendor lists and procurement is often disconnected from internal governance processes and decision-making.

Governance and Adoption

One of the challenges of SOA is it is not implemented all at once. Rather, it is achieved through many discrete projects across both space and time. This spatial and temporal distribution of SOA projects makes governance all the more critical to SOA success. SOA governance and enforceable policies are the keys to managing conformance to the SOA across geographic and time horizons.

The spatial distribution, the proliferation of services that need to be maintained by different organizations both within and outside the enterprise, and temporal distribution, where the services themselves or their combinations change continuously as the business processes they support change, makes governance especially challenging.

On a large scale, this distribution of services across organizational boundaries can function properly and efficiently if, and only if, the services comply with requirements dictated by a service level agreement (SLA) for factors such as security, reliability, performance, cost and so on.

Identifying, specifying, creating, and then deploying enterprise-level services to achieve SOA governance is best achieved by forming a compliance office that has enterprise-wide oversight and is staffed with business analysts, software developers, and so on.

It is very easy to get caught up in the technical details of implementing an SOA plan. Fortunately, SOA governance brings the focus back to the importance of the partnership between business and technology. In the end, what matters is not technology, it’s customer adoption. End users will adopt and use SOA-based applications if they believe they create an economic benefit.

Traditional vs. Federated Governance Approaches

Traditionally, there have been two approaches to IT governance: centralized and decentralized.

In the former, the IT department retains control over development budgets and adoption of technical standards. This relationship between business and IT has at times been tense. Business wants agility to implement new strategies quickly. Requirements are handed off to IT and not only does it seem to take a long time to implement the required functionality, but often much is lost in the translation from requirements document to executable system.

In the latter, a certain amount of power over budgets and technical matters is shifted to business units and even to individual departments within those units. With less central oversight, these disparate groups of users can easily end up creating systems that, over the long term, do not work together particularly well.

Having only these two approaches to IT governance, IT organizations face this tradeoff: suffer in response times now — with power concentrated in a central IT department — or face the consequences of a sprawling, out-of-control environment later.

However, SOA promises a middle ground. It is a standards- and service-based approach, where the repository and platform can stand in for the central authority while modeling and application development by the consumers of the services can grant considerable latitude to business analysts and other distributed tactical users.

This decoupling of tactical use and strategic oversight also creates an opportunity to apply governance on an ad hoc basis.

Within such a federated architecture, SOA decouples the IT side from the business side and giving each what it has always sought. For the first time, enterprises can reap the benefits of a uniform IT architecture while also enjoying a new level of flexibility in IT that is sufficient to meet business needs.

A fundamental principle of SOA is the separation of business logic from application logic. Business analysts gain the ability to define, change, and adapt business processes, supported by SOA services.

IT’s responsibility is equally clear: it must manage the stack from the application logic down to the physical infrastructure. IT is in charge of the underlying platform for SOA: the repository.

This does not mean that IT and business never negotiate again, but by empowering business with agility to work with critical business processes and to compose applications from existing enterprise services, the need for an interface becomes narrower and the questions become smaller.

Instead of approaching IT with a major change to a monolithic application, business gains the ability to make strategic changes without endangering the application ecosystem; again, giving each side what it always wanted.

Of course, this federated architecture creates its own organizational challenges. In addition to the traditional governance committee, overseeing service and platform integrity, the company and the CIO must now address the issue of how much authority to cede to business analysts and their superiors, the size and boundaries of governance domains, and who is entitled within each domain to influence, consult upon, and ultimately make the final decision on governance.

A tradeoff still must be made, this time between flexibility and organizational complexity.


Distributed business units and departments must be cost-effective in their use of IT. At the same time, IT must be seen to deliver value for money. Bringing these together is a challenge. That is where chargeback comes in.

Chargeback for IT services is used to modify behavior in the use of IT services by recovering costs. It reveals to users the cost of the IT services they consume. However, it can also lead to arguments over how chargebacks are calculated, political tensions and devolve into a debate about IT services being bought cheaper elsewhere.

Chargeback is just one of the tools an enterprise can use to get the behaviors it desires in the use of IT services. To be effective, chargeback has to be seen in the context of IT governance.

To implement a chargeback system, it needs to be broken out into three steps. The first step is identifying IT service costs, followed by cost allocation, and the third step is cost recovery. The identification of service costs can be very complicated and is beyond the scope of this article.

Allocation Criteria

The subject of cost allocation is complex, and the process of getting it right is usually an iterative one. Criteria for cost allocation decisions can include, but are not limited to:

  • Cause and effect – allocate costs in proportion to the service provided.
  • Benefit received – allocate costs in proportion to the benefits received.
  • Ability to bear – allocate costs to the cost-objective’s ability to bear.
  • But, how you allocate can also depend on factors such as:

  • Whether you want to punish (charge) or reward (pay) for use of service.
  • Whether or not your system is operating at capacity.
  • The architecture of your system.
  • The size (S, M, L, XL) of your SOA investment.
  • Cost allocation is yet another area where the CIO and the CFO need to collaborate to set policy.

    Behavioral Issues

    Allocation policy is by nature a behavioral issue. Given the allocation policy, its administration, and the charged amounts, will managers act in a way that maximizes the profits (minimizes the costs) of the company? Will managers perceive the cost allocation system to be fair?

    Because the basic problem is behavioral, there are no uniformly applicable solutions. Each company must come to a solution that works for the managers in that company. However, there are guidelines that help in resolving this difficult area.By allocating fixed costs based on actual usage, fluctuation in usage in one department can affect the fixed costs allocated to another department. When actual volume is the allocation base, user departments will not know their allocated costs until the end of the budget year.

    On the other hand, when budgeted volume is the allocation base, user departments will know their allocated costs in advance. This information helps both short-run and long-run planning by user departments.

    The main justification given for the use of budgeted volume to allocate fixed costs is related to long-term planning. Firms make decisions on committed costs (such as the fixed cost of a service department) using a long-run planning horizon. The use of budgeted volume to allocate these fixed costs is consistent with this long-run horizon.

    If fixed costs are allocated based on long-run commitments or plans, some managers will be tempted to underestimate their planned usage. In this way, they will bear a lower fraction of the total costs. Top management can counteract these tendencies by systematically comparing actual usage with planned usage.

    In some organizations, there may be clear-cut rewards in the forms of salary increases and promotions for managers who are accurate forecasters. In addition, some cost allocation methods include penalties for under predictions of budget usage. For instance, a higher variable rate may be charged after a department exceeds its budgeted usage.

    Finally, for the successful adoption of SOA, the behavior of rank-and-file employees also needs to be considered. Ease of use and an intuitive interface are essential when digitizing IT governance processes. However, the software must also have "teeth": an enforcement mechanism with such features as automatic escalation of issues and notifications to superiors when tasks aren't completed in the allotted time, for example. This "carrot and stick" approach can drive desirable behavior by employees.

    Cost Recovery and SLAs

    IT is a business that sells products and services to clients throughout the corporation; its market. In this context, chargebacks are simply prices for its products and services.

    Cost recovery (as indicated above, the third step in a chargeback system) actually moves money between budgets. This is bound to get the attention of business unit managers who are focused on their bottom line.

    To move to cost recovery you are going to have to set up a chargeback committee within the compliance office, with business unit representation and chaired by the CFO. This committee sets up and runs the chargeback. The CIO sits on the committee, but only in an advisory role.

    Service level agreements (SLAs) and performance agreements are key to effective management of IT services and good customer relationships. Good SLAs balance customer needs with the IT department’s capabilities, and customer expectations with the IT department’s commitments.


    Effective collaboration between the CIO and the CFO is an important factor in determining the success or failure of the launch of SOA-based applications. The CFO needs to set a policy, one that maximizes benefits to the company as a whole, for the distribution of the costs of creating, operating and maintaining the SOA applications.

    At the same time, the CIO and/or CTO must create and manage an ecosystem in which both short- and long-term costs for SOA are minimized. An important part of this assignment is picking and choosing which applications to create using SOA and then choosing the architecture for accomplishing the job. That’s where project portfolio management (PPM) comes in. (See my article on Developer.com.)

    While the IT benefits of SOA adoption can often justify the program by itself, the more important metric to publicize is the benefit to the business. You must work with the business to value SOA-based projects in the same ways you always have in managing the IT portfolio.

    It is especially important that any new IT governance be adaptable to a company's culture to ease the transition from the old system. There is natural resistance to change in almost every organization, and many employees will look for excuses to avoid technologies that disrupt their comfort level.

    Culture is not just one aspect of the game. It is the game. What does the culture reward and punish?

    Marcia Gulesian has served as software developer, project manager, CTO, and CIO. She is author of well more than 100 feature articles on IT, its economics and its management, many of which appear on CIO Update.