That old spectre: proprietary systems lock-in

Recently, I’ve been looking at modern approaches to to automating business process by working with high-level abstractions (also called “models”) and wondering why the world switched to writing business systems in C++ back in the nineties—back when we were last at more or less the maturity level we’re at now, as far as systems development goes (I know, “there’ll be letters…”).

Well, there were a lot of reasons why previous very high-level, abstracted, systems development processes hit problems (such as lack of real standards and limits on available computing power) but one I want to focus on is “good ‘ole lock-in”, the vendor’s friend.

Things have changed a bit. It’s unusual for IT vendors to promote totally proprietary interfaces and notations these days and to refuse to support you if another vendor has sullied your installation with its presence. But, even today, is it really reasonable to expect to switch between IT platforms without pain?

YES—that was exactly what we expected 30 years ago with databases, when SQL first arrived (and before a certain database vendor got its hands on it). It’s still an expectation worth working towards. But as an old boss of mine used to say to me: “You may very well be right David, but you must be realistic” (I think that, at the time, I was suggesting teaching programmers overloaded with fire-fighting about “structured testing”).

So, perhaps the real question is whether it’s reasonable to expect vendors to support this strange idea these days. The real answer is probably, “no, not while the likes of Oracle have more power than their customers“. But this might be changing, as the business becomes more IT-savvy, less under the thumb of the IT silo and more focused on business outcomes…

OK, so perhaps I’m being a little naive but the very existence of such things as XMI (XML Metadata Interchange) shows that the expectation is still out there. And it seems plausible to me that businesses—or governments—are becoming fed up with always having to play to vendor’s commercial agendas… And, I suppose I do have the luxury of being allowed to be opinionated…

Even so, I really do think that swapping between platforms should be “feasible” (for some practical value of “feasible”) even if it is “a bit” painful. So, what could this mean in practice?

Mendix, for example, offers a current, SaaS-based and apparently effective approach to very high level systems development “without IT”. It develops automated business systems by modeling business process and executing the models with a Java-based runtime. Mendix uses UML-style notation for domain models and BPMN-style process languages, but these go beyond the standards, as more detail is needed for the models to be executable (this, I think, is also the problem with approaches to executable standards-based UML—the devil, or the proprietary stuff, is in the detail). So the Mendix model isn’t really usable directly by other tools and isn’t really an “open standards” UML/BPMN model. There must therefore be a degree of lock-in, if only because other approaches are less productive and moving to less productive solutions isn’t comfortable.

As Phil Webb of Aptero Solutions points out: “using open standards for modelling notation enables the users to more quickly adapt to and work with a new tool. That doesn’t, necessarily, open up the meta-data to other tools which support those same standards—after all, even full UML tools have failed (perhaps by choice) to properly support model interchange with XMI”.

However, a Mendix model is stored in an RDBMS which can be read by third-party tools; multiple APIs are available for the DB, server, web client, etc.; and Microflows (Mendix’s term for workflows, business rules, data validation, document generation, and countless other operations) can be exposed as web services (which comply with XML, SOAP, WSDL, Acord, and SCA standards). So, given that the customer retains ownership of its data (an important consideration when evaluating any SaaS solution) and that it exposes its logic in its solution design, then, as a Mendix sales engineer points out, “an external system can be built on top of the logic and data to absorb future changes to the application”.

In other words, the model could conceivably be used to help to generate code outside of Mendix even if Mendix disappeared for any reason, although I’d think there could be an issue as to how easy customers would find this in practice (partly because it might need more development skills than are needed for a pure Mendix solution).

Moreover, because the necessary Mendix runtime is delivered as a set of Java libraries, customers aren’t limited to the Mendix SaaS solution anyway; and could run it on any (non-Mendix) platform that supports Java, even without Mendix.

So, in practice, Mendix seems to address the “vendor lock-in question” as well as one could reasonably expect, although there will probably be a degree of “lock-in by kindness”. That is, moving away from Mendix after you’ve started to run your business on it is possible but may not be much fun, as other approaches probably need more resources.

In the end, lock-in is still something you should worry about, I believe, and is something you should address in the selection process for high-level tools such as Mendix. It’s also why the Open Source Software (OSS) movement is interesting (although lock-in to OSS via commercial support agreements and extensions you can’t do without, and OSS licence obligations, might be a subject for another blog).

Nevertheless, although in the words of Serena’s evangelist Kevin Parker (speaking at a BCS CMSG event) lock-in is the software industry’s “dirty little secret”, things are getting better. The use of open standards notations are increasing the usability of proprietary solutions and the availability of open platforms like Eclipse and Java to vendors of proprietary tools are making the lock-in issue less of a possible disaster.

The possibility of future lock-in when adopting a proprietary system is always one risk to consider (tomorrow’s dysfunctional legacy is being built today) but it is only one risk and the use of Java runtimes, for example, might control this risk well enough. To repeat, don’t neglect the lock-in issue; but neither should you neglect the efficiency, integration with business process, and assurance of “business outcomes” sometimes available with proprietary solutions, just because of the, rather ancient, spectre of lock-in.