We have a lot of data points at my shop. I’m sure you do too. On their own, they’re basically meaningless. They need to be tied together to drive decisions. As I’ve written many times, FYIs are worthless to running the org. So with all the data, what is the problem you are trying to solve?
At most places I’ve worked, the application stack is mixed.
You have your dinosaurs; which are likely your most stable/reliable beasts. They certainly don’t perform any cutting edge functions. They’ve been modified over the years to do a hundred different things and each one of those things has little to do with the others. Maybe they perform a regulatory function. Maybe the technology is so old you have a hard time finding people to work on it any more. But do you try to take something like this out (and replace) or just let sleeping dogs lie?
The middle tier of applications are mostly forgettable. You probably have a few people who developed them originally. Those people, like the apps, are also probably forgettable. But they are steady, and needed. Again, like the application. The priorities here are boring. “Make the green button blue”. You have a feeling these are cheap apps. Maybe you can backup that feeling with facts. Maybe not. You will almost certainly never be asked about these apps. You have a hunch that a better solution is out there but you have many other fires to fight and these aren’t your first priority.
Your top tier apps should be your competitive advantage. Your best people work here… you hope. The applications are probably costing you a fortune. The priorities are revenue generating. You have a nagging suspicion that you could buy something similar and customize it for a cheaper investment but everyone in tech tells you you’re crazy. The business only cares about the cost of these applications when you aren’t making money. When times are good, it’s a blank check. Because of that, huge dollars have been spent here. Because of the specific nature of this product, benchmarks are tough.
In all of these scenarios, you need to understand your total cost of ownership. As I mentioned in the tag line, it’s really the holy grail of information in TBM.
So what goes into TCO?
Manpower for starters. This includes your development, and support (level 1,2,3). To have an accurate view on this, you’ll need to have a time tracking system and a commitment to accurate time booking. You’ll also need to have detailed rate bands to generate a cost profile.
Infrastructure is the most commonly misrepresented part of TCO. It’s comprised of the pipes, plumbing, and compute needed to run the application. But it’s also the folks that support those functions and the licensing and small components (middleware, etc). For the first group, your CMDB needs to be accurate and updated. For the second, you’ll need to allocate these costs to specific applications. If you’re using the cloud, please note that this includes more than the bill from your cloud provider. For both areas to work, you’ll need a “model”. For more on this, see my TBM tooling section.
Once you have the view, what can you do with it? For starters, is the system generating enough use/revenue to justify its existence? Do you have other options readily available? Trust me, there will be plenty of vendors in the market willing to help you tackle this problem. What are your competitors doing in this space? To get a quick view on that, talk to your most recent hires.
Going back to the three types of applications, you should review your application profile on a regular basis. Notice I said regular and not constant. These types of reviews take time when done properly. For your dinosaurs, this can be done every couple of years. For your middle tier, annual seems right. For your thoroughbreds, this should be done as business needs change.