The first group of demos on bpmNEXT day 2 had a focus on the links between architecture and process: from architectural modeling, to executable architecture, to loosely-coupled development architecture for process applications.
Trisotech: Digital Enterprise Graph Semantic Layer for Business/IT divide
Denis Gagné kicked off talking about Trisotech’s Digital Enterprise Graph, which is a semantic layer for transforming and combining information and models, allowing information to be shared and enriched for use by both business and IT stakeholders. The issue with current standards is that they only allow for structured exchange of information between different parts of the business, but a graph structure allows for information in widely varying formats to be distilled down to the who, what, when, where and why of the organization, allowing new relationships and interactions to be discovered and explored. Trisotech’s current modeling tools — Discovery Accelerator, BPMN Modeler and CMMN Modeler — can all contribute models to the Digital Enterprise Graph, but it can also accept models from a variety of other enterprise architecture and modeling tools. This brings together business architecture, enterprise architecture and case/process modeling outputs into a consolidated semantic graph, allowing each group to use their own models and terminology. Denis gave a demo of the Discovery Accelerator for capturing/discovering business information, where a text description can be highlighted with the actors, activities and artifacts to iteratively build a conceptual model; a balanced scorecard, W5 or SIPOC board can be used as a starting template; or an accelerator to reference models from Casewise, APQC and others to provide a framework and ontology to begin discovery and modeling. RACI charts can be created from the actors, activities and goals. The resulting information can be exported into BPMN, CMMN, UML, XPDL or GO-BPMN for more detailed modeling in another tool. If an EA reference framework (such as Casewise or Sparx) was used in the Discovery Accelerator, semantic links are maintained from activities to the original framework, even if the activities have been renamed and reorganized. He finished up with a demo of their new Insight Analyzer tool, which is used to explore information in the Digital Enterprise Graph; a node in the graph can be selected to see its origin as well as interrelationships with other nodes that may have come from different modeling tools. New relationships can be inferred from the graph as more information is added, without having to make explicit links, for example, identifying risk points based on their level of interconnectivity with other activities.
[Update to change Trisotech “BPM Graph” to “Digital Enterprise Graph” to match Denis’ presentation materials and current product naming.]
Comindware: Between Architecture and Execution: Tale of 3 Gaps
Anatoly Belaychuk and Konstantin Bredyuk discussed gaps between architecture and execution in terms of process models — the process model round-trip problem; between process, project and case models;and between process-based versus object-based work. They see architecture and architectural maturity as important in an organization’s ability to model and execute processes. In their demo, they showed a different representation of processes by modeling capabilities, resources and inputs/outputs; this is not an execution sequence to replace BPMN, but rather an architectural view of how organizational capabilities link together, more like a value chain diagram with major milestones identified. Drilling down into a capability, we may see a submodel using the same model syntax, or it may link to a BPMN process. This is like a slice through enterprise architecture, with a variety of process-related model types linked into a business architecture capability model, but also creates executable processes and cases, not just models. This “executable architecture” can be used by both architects and process modelers; it also includes data modeling to define record objects and attributes, and a forms modeler to provide a complete application development environment. This provides a link between architects — who are unlikely to learn or even care about BPMN — and executable process models, although there is not a direct link to existing enterprise architecture products or models in order to maintain any sort of semantic links such as we saw in the Trisotech demo earlier.
Bonitasoft: Building Sustainable Process-Based Apps
Miguel Valdés Faura finished this block of demos discussing process-based applications: how it’s still hard to create engaging user interfaces and easily-updated applications in spite of the low-code/no-code promises. He demoed some of their capabilities still in their labs, allowing for more agile applications by separating data, business logic and user interfaces. He started with a procurement application: BPMN process models for the business logic, data object models, and user interfaces defined separately, interacting via JSON contracts and REST APIs. The contract between an activity in the process model and the user interface is defined as inputs and constraints; as long as the contract does not change, the UI can be changed with no impact on the process model. Mobile interfaces can be built independently of desktop interfaces, using the same contracts to interface with the business logic, and REST APIs for access to the data objects. Their page builder provides environments for different form factors, providing standard UI widgets plus allowing for custom widgets; either the page can be deployed directly in their environment, or the page definition can be exported for further hand-coding outside their environment. Page fragments can be created for reusability cross pages. Custom pages built outside their environment, such as with AngularJS, can be imported by an administrator into the runtime environment and immediately deployed. Although a full process application can be built purely in their environment, by loosely coupling the logic, data and UI, they are able to make changes to any of those layers including adding custom components and UIs without impacting the others, as long as they respect the existing contract and APIs. Good example of why we use multi-tier architectures rather than tightly-coupled layers for greater flexibility and agility.