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.
Chargeback
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:
But, how you allocate can also depend on factors such as:
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.