How much change in software is required for “digital transformation?” Do you need to redo everything to cloud-native form? There’s a school of thought, now represented by at least one startup, that thinks there’s a better way. According to Venture Beat, Camunda raised a hundred million dollars for cloud-native process automation software, and their approach might offer us a new option for transformation, even in networking.
I’ve talked in past blogs about the possibility of orchestrating project workflows, both the pieces that are already represented by applications and those represented by manual processes. To do this, you need a process model that represents how work (both responsibility and data) move through a complex flow to completion. There are a variety of tools that could be brought to bear on this problem, but there’s also an opportunity for someone to come up with a custom approach.
Camunda bills itself as “Automate Any Process, Anywhere”, a claim that’s nothing if not ambitious. It’s never easy to dig out an approach from a company’s public material, but Camunda seems to have created something like a super-enhanced version of an Enterprise Service Bus, an ESB, that steers work to applications using a business language, this making the workflow itself programmable.
The languages Camunda uses are BPMN (Business Process Model and Notation) and DMN (Decision Model Notation), and the two combine to allow process flow rules and decisions to be expressed and implemented, in the case of Camunda, in cloud-native form. There are seven components to Camunda’s solution, divided into the areas of design, automate, and improve. The first phase uses two tools to design business processes, creating the models. These are passed to the automate phase, which has four components to execute the process automation. The improve phase then has one component, which is really designed to manage the overall process and produce reports.
The interesting thing here, particularly from a network perspective, is that this is really process automation. The model created is used to sequence and direct work items, and it can be applied to applications or human processes (via a “work order” and a “completed” event). Thus, you could model anything and then automate its execution, even if the component tasks were old-line monolithic applications or human processes. Could this then be a way to describe service lifecycle automation?
I think the answer is that it could, and better yet, Camunda’s use of BPMN and DMN shows that these languages could be the basis for describing process automation, period. The questions would then be how these could be used in service lifecycle automation, and how the result would compare with things like the TMF NGOSS Contract approach I’m always citing, or ONAP.
In the TMF NGOSS Contract approach, there was a service data model (expressed in the TMF’s SID data model structure). This model defined a service as a series of components, each of which was represented to include a state/event table that related current state and incoming events to the process that was designed to handle them. The service data model would hold all the service parameters and data, and so any instance of a process could, with reference to the service data model, handle an event. That facilitates the use of stateless components, meaning that it would be naturally cloud-native.
While the TMF invented this, they never really implemented it, and the current “ODA Contract” doesn’t appear to include the concept at all. Thus, while this approach has always been the gold standard to me, it doesn’t appear to be supported, and we can discount it except as the iconic reference.
ONAP is the current implementation of the AT&T-originated operations automation tool. I had high hopes for this early on, but unfortunately it didn’t build from the NGOSS Contract approach of a data-model-driven event steering process. Instead it took a largely monolithic management view, not unlike that adopted by NFV’s MANO and VNFM. After a couple of releases where no model or model-driven approach was introduced, I told the ONAP people I would no longer take briefings on ONAP until it became model-driven, and they’ve not briefed me since. We can thus discount this approach too.
Which, of course, means we have nothing that we can really compare the Camunda model to, except in abstract. However, it appears to me from the documentation on their website and from the BPMN and DMN documentation that the languages would support the same capabilities as the TMF NGOSS Contract would have, though not in exactly the same way. I think that wrapping event-handling into a language rather than representing it as a table makes sense from a modeling and maintenance perspective; state/event tables aren’t naturally the language of humans, where BPMN and DMN are (with practice) human-readable.
I think that the approach Camunda is taking, and the use of BPMN/DMN in general to express process models for automation, would allow true service lifecycle automation to develop. It’s not yet fully clear to me whether Camunda’s implementation would preserve full scalability and even whether it’s truly cloud-native overall, but it looks promising, and clearly you could implement the models and the engines that interpreted them in a cloud-native way.
Which means, I think, that since the TMF is apparently not going to develop its own NGOSS Contract concept, this may be the way that service lifecycle automation should be heading. In fact, the approach has benefits that could be uniquely helpful in the telco world.
The first benefit is that process automation is functionally an outsider in the telco world. It doesn’t evolve from OSS/BSS, NMS, or any of the other “S’s” (no pun intended!), and so it’s a neutral play in an organization whose internal politics can confound everyone inside the company and out. In fact, since process automation is about model-based invoking of processes and applications, it could even be seen as providing integration across various operator business and management systems.
A related “outsider” benefit is that process automation is going to advance based on its broad-market value, not on its adoption by operators. In the world of open-source software, you can’t beat breadth of interest and support. Process automation tools are likely to advance faster than specialized telco tools would, and because they’re designed to support a wide variety of applications and manual processes, they’re more likely to adapt to a given operator’s situation.
It’s also true that process automation, at least the form that Camunda is offering, is model-based, as the venerable TMF NGOSS Contract was. It appears to me that it would be possible to build service models in the BPMN and DMN languages, populate them with order-specific stuff, and turn them into the closest thing to an ideal operations automation tool that we’ve been offered so far.
None of the operator planners I talked with about this were even aware of the company, though one was in fact a user of the technology in a narrow application. I don’t think the potential of the approach has been realized yet, and I hope that changes, and changes quickly.