So, you’ve decided you’d like to look at what the metric “Total Cost to Own and Operate” (TCOO) can do for you. Good!
Here’s how to get started, if you’re an enterprise architect:
Define all your existing platforms. A platform consists of one of two kinds of thing: it is either a hardware base + an operating base (hypervisor and operating system) + a middleware stack (database, message handler, security, etc.) + possibly a platform-like package (e.g. SAP, which deploys multiple applications within its framework) — or it is a service that your procure, whether from a business process outsourcer, or from an -as-a-service vendor. (A platform run for you by your outsourcer should usually be dealt with as a platform would be if you ran your own facilities, unless your contract allows you to make platform changes at will and without financial penalties, in which case treat it as a service.)
Don’t get too detailed here: you’ll notice we left applications out of this. If you use (for instance) a message handler and a database manager with some application on your platform that has Windows as its operating system, just treat that as a part of that platform, period. (Only if you run major blocks of workload using separate stacks — these servers have the middleware, these other ones don’t — and you’re dealing with hundreds of items in each class, should you separate them.)
Figure out, for each of these, what it costs you. Depreciation, maintenance, licences, staff time (including all support teams to maintain the stack), again excluding application support itself. This is your actual TCOO for each platform/service you have.
Each of these, in turn, has an industry curve associated with it (modified by the availability of required skills in your market). The IBM z/OS platform, for instance, has a lower bound: below a certain total workload, the cost of the platform makes a single z/System implementation “too expensive to run”. The Windows servers, on the upper hand (while they also have a lower bound) have an obvious upper bound, beyond which server proliferation to handle the workload and inter-machine communication starts to make that platform “too expensive to run”. Mapping workload (horizontal) by cost to provide (vertical) will give you a U-shaped curve, with the lowest possible TCOO at the bottom of the U, and the breakpoints (where this platform becomes “too expensive”) crossing the left and right sides of the U.
Optimizing TCOO for an enterprise, then, is simply a matter of making changes to (a) match workloads to their appropriate curves and (b) ensuring you manage your purchases to drive closer to the optimal “bottom of the U”.
Notice, please, that this approach to building a “technology roadmap” (a common strategy-level planning tool delivered by enterprise architects) does not pay attention to vendors and their market share — quite deliberately. The only two places market share for vendors matters are in its impact upon the local labour market (for skills) and if the vendor exits the market (goes out of business, or is acquired and the platform terminated by the buyer). Even under those circumstances, you generally have a half-decade or so to handle that situation — the crisis that can occur when a service provider closes (outsourcer or -as-a-service, it matters not) is far more critical than that a major platform component vendor’s life is ended.
Your architectural goal is constantly to be lowering the enterprise-wide TCOO over the life of your roadmap.
To do this, you need to build TCOO curves for platforms you don’t use today, but might logically add. This is the one and only time you start with vendor health questions: it makes no sense to take on a new vendor who is unlikely to survive! Again, though, the question is financial. If, for instance, you wanted to use Amazon’s EC2/S3 cloud offering as a platform component, you’d have to look at Amazon’s total business to determine how “healthy” the platform is.
Don’t — when planning your future — think of hardware and system software as a unit. An IBM z/System purchased to run z/OS three years ago isn’t useless simply because you’ve determined to migrate all remaining workload from z/OS (as its TCOO is moving higher on the left side of the U). That same z/System could run Linux for years, creating a new platform (z/System Linux) in your model, that may have a much more attractive TCOO than many of your other platforms in use. Always examine all the options before making a decision as to longevity!
The TCOO approach takes a lot of the battles away from technology decisions. Since the goal is a steady drop in enterprise TCOO — constantly lowering unit costs — application decisions that would raise TCOO can be challenged, not as a battle over technologies or “we like this package”, but “why should the enterprise bear more cost than it needs to?” (If there’s a solid business reason to do so, then fine — but it’s been thought through.)
Likewise, TCOO allows outsourcing and -as-a-service proposals to be stacked against your own assets and your own operations — not just at the decision point, but over time, to ensure that a falling TCOO accrues to the enterprise, not to the vendor alone.
In all cases, TCOO serves the long-term needs of the enterprise well.