Determining Your IT Funding Requirements, Part 2

In Part 1 of this column, we introduced tools to help IT executives develop a baseline assessment of where and how their IT money gets spent. In Part 2, we'll explore a method for determining how your organization funds what it buys, as well as which part of your organization logically should bear the cost of funding IT projects.

Table 2 suggests what the landscape should look like. It identifies the funding mechanisms and responsibilities that make the most sense in decentralized organizations.

Categories                              Mechanism         Enterprise    Line of Business
                                                        Responsibility   Responsibility

APPLICATIONS

Apps Software Packages               Fee-for-Service                           X
Apps Development                     Fee-for-Service                           X
(Integration & Deployment) 
Apps Support                         Fee-for-Service                           X
Apps Architecture Design                 Taxation              X               X
Apps Architecture Services, Support  Fee-for-Service           X
Modernization & Migration            Fee-for-Service                           X

INFRASTRUCTURE

Messaging Environment                   Allocation             X
Network & Comm. Architecture Design      Taxation              X
Network & Systems Management            Allocation             X
Voice & Data Services & Support         Allocation             X
Infrastructure Engineering              Allocation             X
  Services & Support
Data Center Hardware                    Allocation             X
Desktop Hardware                     Fee-for-Service                           X
Laptop Hardware                      Fee-for-Service                           X
Other Access Devices                 Fee-for-Service                           X

OVERHEAD

Staff (Human Resources, Benefits, etc.)  Taxation                              X
Training Services & Support              Taxation                              X
General Support (Admin. Assts., etc.)    Taxation                              X

Table 2: Funding Governance Recommendations
_________________________________________________________________________________

Take a look at your organization with reference to Table 2. How does it look?

Infrastructure Funding

As Table 2 suggests, infrastructure funding is largely the responsibility of the enterprise. Infrastructure design and construction is funded via taxation and allocation. The design of the infrastructure benefits everyone, so it's taxable. But use of the infrastructure will vary from business unit to business unit and should therefore be funded by usage allocation.

The arguments to watch out for include:

"Business unit 'A' is deploying a lot more eBusiness applications than 'we' (business unit 'B') ... so why should we pay for distributed security at the same rate as them? Maybe the costs should be spread across taxation, fee-for-service and allocation funding mechanisms ..."

"I am not willing to pay for remote access infrastructure. I don't use it today and don't expect to use it tomorrow ... make business unit 'Y' pay for it ... they're the ones sending everyone home to work!"

"Tell me again why I must be taxed at the same rate as business unit 'P' that requires 10 times the training I require?"

You get the idea. The key to the successful implementation of mixed funding mechanisms is - you guessed it - serious leadership that expresses itself in a well-defined governance policy. If arguments such as the ones listed above are allowed to infect your organization, you'll be spending as much time on resolving the arguments as you will on building and supporting your infrastructure and applications.

The simple rules should be:

Allocation = If you use it you pay for it

Taxation = There are some things good for everyone and therefore everyone's going to pay for them - no questions, no debates and no returns

Fee-for-Service = There are IT decisions that the lines of business can make, decisions about applications, about desktop upgrades, and the like that they can certainly make on their own ... and they have the right to look internally or externally to implement those decisions ... if they decide they want, they pay for it.

Is all this simple? No. Here's why. Much of what we're talking about in what appear to be clearly defined terms are, in practice, quite fuzzy.

For example, when does the purchase of new laptops move from fee-for-service to allocation? If the central infrastructure organization runs the data center that houses mostly mainframe applications, but not some of the important distributed applications that reside on servers in the lines of business, where should the line be drawn between fee-for-service, allocation and even taxation, if either the mainframe or distributed applications team used a common applications architecture (developed by the enterprise group via taxes)?

What about sourcing? If the lines of business decide that they'd like to shop a bid for services internally and externally and select an external vendor, who manages that vendor if the vendor's work requires them (as it will inevitably) to interface with existing internal policies, procedures, hardware and software? If the enterprise organization hires an outside vendor to help it perform infrastructure support for the lines of business, does the outsourcer report to the enterprise group or the line of business?

Disputes should be handled via some form of published grievance procedure. If a line of business feels it has a legitimate gripe, there should be a process that helps resolve the dispute. If you want the arbitration process to work you will have to use external judges.

Applications Funding

Applications are the lifeblood of the lines of business - and they should pay the freight here as well (as suggested in Table 2). But there are some major issues surrounding applications funding that you should be aware of as you develop a funding strategy. Here are several of the most important ones:

Applications that were initially intended to support local users who become remote users will have to be re-engineered; if remote access performance is sub-standard it's often assumed that the infrastructure is to blame when more often than not it's the application.

Applications should be reviewed by the infrastructure support team before they're built to make sure that support requirements are not prohibitively expensive ... end-to-end applications planning should become a best practice.

Applications integration often involves integration to back-end legacy data bases, data bases that are often maintained by enterprise data base administrators ... make sure that the infrastructure support team is synchronized with applications integration efforts.

Web-to-legacy connectivity is a common way to rapidly deploy eBusiness applications, but in order to design, develop, deploy and support such applications both infrastructure and applications professionals will be necessary ... make sure they are well coordinated.

The most cost-effective way to develop applications is via an enterprise applications architecture (the specification of platforms, tools, development environments, data bases, browsers, and the like) ... if your organization does not have a common architecture then you'll re-invent the wheel over and over again ... the cost of a single architectural specification will be much, much lower than the costs of repetition ... of course, without a governance policy that sees that the architecture gets used (and re-used) the investment will be wasted.

Since much of the applications work will involve the implementation and integration of off-the-shelf packages the applications architecture must evolve to accommodate these applications acquisitions practices ... make sure that the number and nature of the packaged applications coming into your environment is well understood and part of the end-to-end planning process.

In order to avoid conflicts and surprises, it's a good idea to hold "integrated planning" meetings between the enterprise infrastructure team and the applications development teams in the lines of business ... these meetings should be mandatory and occur at least quarterly.

Future Modeling

All of this needs to be monitored closely because change is inevitable. One that should be especially tracked is the new movement toward applications hosting by third-party vendors.

It's now possible, for example, to "rent" ERP and CRM applications from the major software vendors - and others - who have evolved into "application service providers" or "ASPs." Other trends such as component architectures will also significantly affect the applications development process. Infrastructure outsourcing is also likely to continue at an aggressive pace.

Steve Andriole is the founder and CTO of TechVestCo, a new-economy consortium that focuses on optimizing investments in information technology. He is the former senior vice president and CTO of Safeguard Scientifics, Inc. and CTO and senior vice president for Technology Strategy at CIGNA Corp. He can be reached at steve@techvestco.com.