I had a briefing two weeks ago with OpenText about their acquisition of Cordys, an interesting move considering their acquisition just a few weeks before that of ICCM, a partner company that created the Assure platform on top of OpenText’s MBPM (hat tip to Neil Ward-Dutton for tying together these two acquisitions). This provides them with two important pillars in their strategy:
- A robust cloud platform. Although OpenText Cloud existed, it wasn’t what you’d call industrial strength and it was more of an infrastructure platform: it wasn’t fully multi-tenant, and it’s not clear that they had the skills internally to build out the functionality into a competitive solution-oriented platform as a service (PaaS). Cordys, in spite of being a relative unknown, has a strong cloud and PaaS heritage. They also bring other parts of the infrastructure that are missing or deficient in OpenText – including a rapid application development framework, ESB, rules, analytics and MDM – which should accelerate their time to market for a full cloud offering, as well as benefit the on-premise platform.
- A “Smart Process Application factory” for creating vertical process-centric applications. OpenText first announced Assure almost a year ago as a development platform, plus their initial Assure HR application built on the platform, and have since released (or at least announced on their product pages) customer service, ITSM and insurance client management apps on Assure as well. Now, presumably, they own all of the underlying intellectual property so are free to port it to other platforms.
They have immediate plans (for release near the beginning of 2014) for bringing things together, at least on the surface: they are porting Assure to Cordys so that the same development platform and vertical applications are available there as on MBPM, which gives them greatly improved cloud functionality, and will create additional smart process applications along the way. Effectively, they are using Assure as a technology abstraction layer: not only will the user experience be the same regardless of the underlying BPM platform, the Assure application developer experience will also be the same across platforms, although obviously there’s completely different technology under the covers.
There are some obvious issues with this. In spite of OpenText CEO’s claim that this is a “single platform”, it’s not. OpenText was still working out the Metastorm/Global360 picture from earlier acquisitions, and now have the Cordys platform thrown into the mix. In 2011, when IBM pulled Lombardi, WPS and a few other bits and pieces into IBM BPM, some of us called them out for the fact that although it was presented as a single platform, there were still multiple engines with some degree of overlapping functionality. IBM’s response, and I’m sure OpenText would line up behind this, is that it doesn’t matter as long as it’s integrated “at the glass”, that is, there’s a common user interface for business users and potentially some more technical functions. As someone who has designed and written a lot of code in the past, I see a fundamental flaw with that logic: in general, more engines means more code, which means more maintenance, which means less innovation. Hence, I consider refactoring redundant engines into a single back-end as well as a common UI to be critical for growth. Getting Assure in place quickly as a technology abstraction layer will definitely help OpenText along this route, although primarily for existing Assure customers and new customers for whom Assure will be the primary OpenText application development environment; existing MBPM and OpenText customers will likely need to consider porting their applications to the Assure platform at some point in order to get on the main upgrade bandwagon.
Following the Cordys announcement, Gartner released their analysis that casts doubts on whether OpenText can bring together the acquisitions into a coherently unified strategy. Aside from the stunningly obvious point in the summary, “If OpenText’s BPM suites do not fully meet your needs, evaluate other providers” (when is that not true for any vendor/product?), they see that this just makes the OpenText landscape more complex, and goes so far as to wave off prospective customers. As one person who passed on this link said: ouch.
.
Disclosure: OpenText has been a customer in the past for which I have created white papers, the most recent of which was “Thinking Beyond Traditional BPM” (and a related webinar). I was not compensated in any way for my recent briefing nor for writing this blog post.
By the way, I first reviewed Cordys in 2007 (!), although saw it only a few times since then. It was pretty forward-thinking back then.
It’s an interesting opportunity to get some disruption into the BPM marketplace… because I believe the business models of both OpenText and Cordys are incomplete when it comes to BPM and digesting the acquisition will be tough. I think someone else will do it in a few years.
Bogdan, I agree: this is going to be a tough road for OpenText in absorbing another acquisition before they had really sorted out the previous ones. As for business models, what gaps do you see in what OpenText and Coryds are offering, as opposed to any other vendor?
Thanks Sandy for your comment!
As a matter of fact, I am working on defining my very own BPaaS start-up based on what I believe is a massive gap in the current vision of the incumbent players in the BPM space. They have started to sniff around Smart Process Apps, but even that is an incomplete vision – there has to be a smarter way.
I am not yet ready to talk about that because, through our start-up, we want to first prove (to ourselves) the benefit of such a compelling vision, so we will attempt to do something probably unique: before we invent the product, we will first invent our own customers 🙂
In the content management space, it seems like OpenText had a very straightforward roll-up strategy (scooping up Vignette among others). In the BPM space, the acquisitions have some of the same characteristics – but I have to wonder if it won’t be a lot harder to merge BPM tools and assets than it was to merge content management systems (maybe I have that backwards, who knows!)
But regardless of the technical complexity, I don’t know the company well enough to understand if their goal is consolidation and organic growth, or growth through acquiring struggling companies’ customers and merging well enough to build a moat around their customers (and then managing the assets and maintenance streams). Open to ideas as to other goals.
But if the goal is to capture the maintenance revenue, it may not even matter how well they sort it out. At least, to them it may not matter- it’ll matter to their customers.