Developing for the Mutable Enterprise - is "NoCode", with tools such as Metavine Genesis, the way forward?
Published:
Content Copyright © 2016 Bloor. All Rights Reserved.
Also posted on: The Norfolk Punt
So, you want to be a “Mutable Enterprise”, one in a constant state of change and evolution? But, what’s your IT development environment going to look like? Well, I think it is going to be “NoCode” and belong to the business users – because there is no time to deal with the latency involved in writing code and passing code from an IT silo to an operational silo to a business silo. Even conventional DevOps (which does help) may not be agile enough to deliver the agility needed by a truly Mutable Enterprise.
However, there will still be development, test and production environments, I think. You can’t be Agile in business if you can’t rely on your automation. Changing production without controls is a recipe for disaster. No Mutable Enterprise will stay Mutable (or even stay in business) if inexperienced business analysts are allowed to prototype apps in production which can (for example) handle “personally identifiable data” in ways that attract the attention of the regulators and the huge fines they can now impose.
I think that rule-based approaches (providing that rules management over time and rules QA is addressed) will become ever more popular (because business analysts intuitively understand business rules). This will aid the segregation of data from business logic and from the user interface, that are necessary for safe Agility.
I am describing a business automation platform something like Metavine Genesis, perhaps, which I’ve just met in a briefing with Craig Sproule, Metavine’s CEO. Although, the general characteristics I’ve just outlined might equally apply to something like Uniface or Mendix or Bizagi too.
What makes Genesis different? Well, it claims to be genuinely zero code (unlike, say, Salesforce1), and it comes out of an organisation with huge experience in manually automating businesses, which is able to re-use this application automation experience to automate the production of new applications. Mostly, for now, in the CRM space – but its application is potentially much wider – and it features support from its skilled business analysts and from the active involvement of the Metavine community.
I particularly like the idea of community-based development, which seems especially appropriate to automation of the “mutable Enterprise” (you can’t afford to wait on a vendor’s own schedules). What Metavine now needs (and I believe that it is now developing) is a partner channel – global partners, with local knowledge, using Genesis to develop automation solutions for their own customers, with the help of the Community and without competition from Metavine direct sales.
This is not a unique approach, as I’ve already implied – it’s been used for years by Uniface and Progress, for example – but the edge will come from how well Metavine can manage its community. The signs are good: Denis Pombriant (who is not entirely disinterested, as he advises Metavine) describes Metavine as “a non-procedural application automation environment with a community of like-minded people involved in supporting each other. Metavine’s community resembles the community culture growing up around 3D printing. In that world, people trade specifications, tweak them for specific needs and generate one-off products”.
The other thing that makes the Genesis platform effective today is that it has few enough well-chosen customers to let it mentor the introduction of Genesis in a very hands-on way. This won’t scale – hence the importance of the community and developing a channel partner program already mentioned. It is also in at the start of something very big and disruptive – Metavine doesn’t meet potential competitors like Mendix much, Sproule maintains, which says to me that the NoCode space (especially if you include LowCode) is huge and developing – there is still plenty of room for everyone with a good story to sell.
I do have one concern. Metavine’s Genesis isn’t built around standards-based models such as BPMN (Business Process Model and Notation) or DMN (Decision Model And Notation). Some people will see this as an advantage – you don’t waste time and resources building anything that won’t be immediately used by the business. But I am not sure I agree, and not just because I see standards-based models as protecting “organisational memory” over time.
The models can extend outside of the automation (and automation tools) to model the manual processes in which the automation is embedded – they let you model the man-machine boundary. This is important, especially to the Mutable Enterprise, because the man-machine boundary changes with evolving technology, and the Mutable Enterprise is all about changing in something like real time to take advantage of new technology and new business opportunities. If you don’t model the man-machine boundary, you risk carrying the overheads of processes needed by old technology even after you’ve got rid of it. Of course, a skilled citizen developer will refactor the system to get rid of such baggage as technology changes – but some don’t.
Putting this in a business rules context, James Taylor, CEO of Decision Management Solutions and one of the submitters to the DMN decision modelling standard (as well as the claimed originator of the phrase Decision Management and a DMN tool vendor) says that people think that a decision model “relates only to [automated] business rules when it can (and should) also be used for modelling manual decisions and framing analytic requirements”.
Taylor continues: “We have used decision models to frame predictive analytic projects, design dashboards, improve manual decision-making and much more. Sure, modelling decisions so you can manage the rules effectively is a great use case but it’s not the only one. Trying to write rules for every decision in the model means that the model tends to exclude all other kinds of decisions and treat the result of precursor analytic or manual decisions as data when they should be modelled as decisions”.
Overall, nevertheless, I’m impressed by Metavine Genesis, so far, even if, as Sproule says, “Genesis is no panacea for stupidity, although if you do screw up, you do it fast and can back it out fast”. It is firmly based on defining a data ontology (roughly, a data model) before you start; and it firmly separates data “packages” (think data virtualisation) from rule-based “behaviours”, both described declaratively, and visually, without coding.
It supports strong integration with other products (through REST, SOAP and Web Services) dynamically constructs HTML5 for mobile apps, and has a strong security model, that safely supports external legacy applications in a hybrid approach (sometimes required by regulations). It supports workflow applications and event management; and, importantly, hybrid transactional management (automatic management of transactions and data integrity after transaction failure) across a hybrid on-premise and cloud app portfolio. There isn’t room here to go into the way it provides impact analysis, release management, application monitoring and support for enterprise-class applications, but I was quite impressed.
A use case that could be particularly appropriate to emerging Mutable Enterprises, perhaps, is the use of Genesis to provide a business-friendly front-end to powerful but technically daunting Cloud platforms. IoT (Internet of Things) platforms perhaps, as IoT is something that a Mutable Enterprise will have to cope with at the business level.
Genesis is a very practical tool (as I’ve said, it makes use of the past practical experience of the Metavine organisation, in building systems by hand). Most importantly, unlike some of the older case tools, it leverages the experience of above-average “citizen developers” – it doesn’t reduce everyone to the productivity level of the lowest common denominator. This does mean that you need to employ good people (Genesis isn’t intended to make cheap superprogrammers out of school-leavers) but that’s common to Agile development generally (it’s “people over process”, which rather implies that the people know what they are doing, and not all business users do).