Tag: OpenText

OpenText Acquires Cordys And Assure Platform For Cloud-Based Smart Process Apps

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.

OpenText EIMDay Toronto, Financial Services Session

After lunch at the Toronto OpenText EIM Day, Catharine MacKenzie of the Mutual Fund Dealers Association talked about how they’re using OpenText MBPM (from the Metastorm acquisition). She spoke on an OpenText webinar last year, and I was interested in how they’ve progressed since then.

The MFDA is very process-based, since they’re a regulatory body, and although their policies don’t change that often, the processes used to deal with members and policies are constantly being improved. There was no packaged solution for their regulatory processes, and the need to have process flexibility without a full-on custom solution (which was beyond their budget and IT capabilities) led them to BPM. As I described in the post about the webinar (linked above), they started with four processes including compliance and enforcement, and sped through the implementation of several other processes through 2012. Although during the webinar, she stated that they would be implementing five new processes in 2012, most of that has been pushed to 2013, in part (it appears) because of a platform upgrade to MBPM 9.

She pointed out that everyone in MFDA is using BPM for internal administrative processes, such as booking time off, as well as for the member-facing processes; for many of these processes, the users don’t even know that they’re using BPM. They’re also an OpenText eDocs customer, so can present content within processes, although apparently they have had to do a lot of that integration work themselves.

As for benefits, they’re seeing a huge decrease in development and deployment time compared to custom applications that they build in Visual Studio, with process versioning and auditing built in. They’ve had challenges around having the business own the processes, rather than IT, while maintaining good process design and disciplined testing; the MBPM upgrade and migration is also taking longer than expected, hence is delaying some of their planned process implementations. This is an interesting result, against the backdrop of this morning’s customer keynote talking about major system upgrades: an upgrade that requires data migration and custom application refactoring is almost always going to cause delays in a previously-defined schedule of roll-outs, but very necessary for setting the stage for future functionality.

I’m skipping out for the rest of the afternoon to get back to my desk, but this has been a good opportunity to get caught up on the entire OpenText product suite and talk to some of their local customers.

Disclosure: OpenText is a customer, for whom I recently did a webinar and related white paper, but I am not paid to be here today, nor for writing any of these blog posts.