ITPA Defined (Part Two)

BPM (Business Process Management) is another thing that is not ITPA.

Many of the BPM vendors, having long saturated their primary market, are looking for new markets in which to apply their technology and for a lot of reasons ITPA seems to look like the promised land. First of all it's a new market so it's nowhere near saturated (current estimates are that less than 10% of those who will buy ITPA in the next 5 years have already bought). Second while there are several early leaders there is not yet a $100M gorilla in this market
(not even HP or BMC who are rolling a copy of their ITPA products into everything they sell - but more on this later). Third predicted growth for this market is explosive (as far as corporate IT goes) with revenue growing from less than $100M to more than $700M in the next 5 years. Finally, the technology is nearly the same so it will take very little incremental time and money to enter the market. I was with them until that last point.

At first glance you might think that it is a small leap from BPM to ITPA.

Workflow engine - check.
Graphical designer - check.
Operations console - sort of. close enough. sure why not. check.
Integrations - supports SOA so integrates with everything. check.

Wrong. Way wrong.

I love the idea of SOA. I believe in the potential of SOA. I even think that many new applications built on SOA standards fulfill the promise of the architecture. But I am at the end of the day a pragmatist and I realize that when it comes to integrating with the highly complex and heterogeneous infrastructure found in a large datacenter it has a long way to go. In a typical datacenter we're dealing with a mix of operating systems, application stacks, management tools, etc... that defies description. This is the single largest reason why IT costs so much and why effective service delivery is so hard. It's also the primary raison d'etre for IT Process Automation tools. Mainframes are naturally very highly automated systems because they are by definition homogenous (one operating system, one console, one log, etc...). But distributed systems broke this paradigm. No single tool is capable of automating across every technology in your data center. And no suite of tools from a single vendor can do it either (they are either not broad enough or not deep enough or more likely both). Instead the only workable solution is to take the point tools that you are using to automate within each domain today and orchestrate them into end to end processes. This is the fundamental innovation in ITPA. And in order to get there you need more than a workflow engine. You need a complete set of integrations, both broad AND deep, into everything you use to manage your datacenter. And (finally getting back to my original point) not everything in your data center is SOA enabled. Not now, not in the next 5 years, which is eternity in IT. The simple truth is that the vast majority of the tools you have in your datacenter pre-date SOA and so they either lack web services interfaces entirely or they had them added on afterwards. Even those with web services interfaces will often find those interfaces less complete than the traditional APIs or lacking in some other way such as performance or reliability. How do I know this with such certainty? The team at Opalis has built over 40 integrations to data center tools and we know this stuff better than anybody else. I would estimate that less than 25% of our integrations use pure web services to do their job for mostly the reasons I listed above. So SOA is not the magic bullet for data center integrations in 2009 and probably won't be for some time. So all the BPM vendors have to do is build some integrations, right? Wrong. First of all building a comprehensive suite of meaningful integrations is one of the biggest barriers to entry in this market. I don't mean a bunch of scripts carried around by services teams and customized for every customer and left for them to maintain. I mean productized integrations that have advanced features like configuration discovery and integrated data handling. Second, in it's most usual form BPM/SOA implementations force a level of abstraction between the workflow and the integrations that fundamentally break the cardinal rule of ITPA - don't force the users to write code! Frankly I have yet to see a BPM-based ITPA contendor who has effectively solved the challenge of integration. I'm sure they will eventually but by then the customers will take integration for granted and the true ITPA innovators will have moved on to the next thing (at Opalis we're already several next things beyond this problem).

But let them try. Competition drives innovation. And innovation is good for everyone.