ITPA Defined (The Ongoing Saga)

There is one last thing that ITPA is not. And that is glueware for large management suites.

Every large vendor of IT management solutions has a big problem that has been hounding them without resolution for many years. That is that they grew their portfolio of products through a combination of organic engineering and acquisition (mostly acquisition) and as a result ended up with a collection of products that are not well integrated. Whenever they make an acquisition they always intend to integrate it properly with the rest of their portfolio but it never happens, at least not in any meaningful way. And the reason for that is simple, the economics don't work. The number of integrations increases exponentially (technically factorially) with each new addition to the suite, but revenue associated with solving the problem does not. And so since these companies are businesses the projects do not proceed. However, after years of this both the customers and the analysts have become unruly and demanded true integration. Further, these companies have begun to view the problem more strategically, viewing true integration as a real means to drive adoption of entire suites rather than point products (often referred to as ERP for IT). But with so much catch up work to do what is one to do? Several years ago a number of these vendors embarked on SOA initiatives to solve the problem. None of them got there, largely because the self interest of individual product groups outweighed the architectural ideal but also because it was an imperfect solution. Then along came ITPA. It was an elegant solution to the problem. Build one integration for each of your tools, plug it into a workflow engine, and voila problem solved. But there was a fundamental problem with this approach and my boss, Todd DeLaughter sums it up most eloquently. He likes to say that suite integration is the vendors problem but it's not the customers problem. The customers problem is the need to automate their IT processes across their entire set of tools and unless they buy all of their tools from one vendor (and as much as large vendors would like this to be the case - ERP for IT - it is not nor will it be) they need a solution that operates across heterogeneous multi-vendor environments. They also need the solution to operate across more domains than any one vendor offers - for example across networks, servers, and storage. And so when large vendors build or buy ITPA technology and they use it to glue together their suite they think that they are doing something important, in fact their customers and the analysts have demanded it and they also think it will drive revenue - but in fact they are not solving the problem the market needs solved. When they run up against a customer who demands third party integration they will make a token gesture of support - typically a services delivered script with no more functionality than what will solve the initial use case - but that's a band-aid not a cure.

The situation only gets worse when these same vendors begin to bundle their ITPA technology with everything they sell. Again, they think they are doing good. After all they are adding automation to existing solutions, often at little incremental license cost to the user. But the largest costs in a data center are not license costs. Not even close. The majority of cost in the data center comes from managing complexity. And having little bits of automation peppered throughout each solution does not address the core complexity. The real solution that the market needs is a complete one that automates across the complexity, across the heterogeneous environments. But because the large vendors don't have this nor do they intend to deliver it they put bits of automation everywhere.

So what you can expect to get from the large vendors is a solution that integrates their own tools, delivered in pieces. What you need is a solution that automates across complex heterogeneous environments delivering true end to end automation and driving down complexity and therefore cost. You're only going to get that from an independent vendor who's been investing heavily in their technology for a decade. You will not get it from someone who's only been in the market a couple of years either because it's a hard problem that takes just a lot of time and effort to solve rather than a magic algorithm.