Building Digital Twins of Enterprise (Application) Architectures with the Architecture Workbench

Digital Twins | Architecture Workbench

adminMay 23, 2022

2 439 7 minutes read

The Architecture Workbench is an environment designed 
to help people design architectures, evolving architectures,
observe architectures, and effectively use the high-quality
tools that architectures require, such as interactive architecture 
development and analysis.

In the previous article ” Architecture as Code: Coding the Next-Generation Enterprise (Application) Architecture System “, we introduced the idea of architecture as code, which is how to combine architectural elements, and features, present, and tightly integrate architectural decisions with design principles into the system.

In order to implement and implement the concept of architecture as code, we also need to build a platform to run these codes, which we call the architecture workbench. But why are we building an architecture workbench? Just for fun.

Why Build Architecture Workbench?

In ArchGuard, we want to manage three forms of architecture: design state, development state, and running state. corresponds to:

Design a new enterprise (application) architecture. Such as describing and designing the current architecture of the system.
Understand and manage the current state of the system. Such as displaying the status quo of the system through visual means and managing the system with rules.
Observe the operation of the system <=> architecture.

Similarly, the departments related to the structure of many medium and large organizers, also have the above problems. And, I believe they faced the same dilemma that we built ArchGuard:

Architecture is multi-dimensional. Including technology, data, security, operation and maintenance, systems, etc.
Lack of a unified architectural language. Human language for communication, such as what is a component?
The system’s architecture is rather unusual. Architectural style or pattern differences, such as microservice architecture, plug-in architecture, etc.
Lack of business context. Being an external architect lacks some context to help with governance.
Details are the devil. The world of architecture is rich and colorful, and there is no way to show them all, such as a small interface, which may reverse our assumptions about understanding.
Our (ArchGuard team) current architecture capabilities are limited (\~\~this will not be written out\~\~) – too few senior architects.

So, before implementing such a standardized system of architectural patterns, it is better to try to build a more flexible form: the Architecture Workbench. It can help us better explore the system and is more in line with our initial experience.

What is Architecture Workbench

For the concept of the workbench, as an active DSL creator, I am more familiar with Martin Fowler’s definition of language workbench in Domain-Specific Languages:

The Language Workbench is an environment designed from
the ground up to help people build new DSLs and the 
high-quality tools they need to use those DSLs effectively.

Therefore, in terms of definition, we refer to the definition of the old horse, and draw on the modern workbench concept, mainly including RStudio’s code documentation, and Jupyter’s interactive analysis. So, our definition is:

The Architecture Workbench is an environment
 designed to help people design architectures, 
evolving architectures, observe architectures, 
and effectively use the high-quality tools that 
architectures require, such as interactive architecture
development and analysis.

Code documentation is used to help us better manage architecture code and integrate it into the software development life cycle, such as architecture documentation, user stories, continuous integration, etc. The interactive analysis is used to help us effectively reduce the customized code, and then evolve it into an API interface and customized code.

For Architecture Workbench, its application includes the following core functions and features:

Design Architecture, Evolution Architecture, and Observation Architecture.
Build a digital twin of your architecture
Descriptive Programming vs. Explicit Design

Among these features, we believe that the digital twin of the building architecture is the most important part of this workbench, and the basic blocks are: design architecture, evolution architecture, and observation architecture.

Fundamentals: Design Architecture, Evolution Architecture, and Observation Architecture

When governance architecture, we usually focus on how to design, how to evolve and observe the state of the architecture at runtime.

Design architecture. Such a function cannot be understood. The difficulty is, how to provide an efficient design mechanism. Using UI drag and drop, or DSL, there are various games. Generally speaking, it will be more friendly to use the code. In order to visually display the design of the architecture, we will represent it through the architecture diagram, which is the core of the system.
Evolution Architecture. Its core is to build an architecture governance model and design a fitness function of the architecture to guide the system to make orderly changes. From the implementation level, it is to analyze the implemented software architecture (ie code, etc.), and design metrics, and provide high-quality tools to guide the architecture back to a reasonable state.
Observation Architecture. That is, observing the running status of the application of the architecture, mainly depends on various APM (application performance management, application performance monitoring) tools. In the cloud-native era, related tools are also very popular, such as Skywalking.

A basic architecture workbench should consider the above three elements.

Advanced: Building a Digital Twin of the Architecture

The ideal architecture workbench should provide an interactive mapped version of the architecture. What it means: It’s a virtual representation of a system or object throughout its life cycle that we can update based on real-time data and use simulation, machine learning, and inference to help decision-making.

Conceptually, it offers a very good future, the difficulty is how to implement such a system.

We are designing a digital twin version of ArchGuard around these three architectural forms (from an implementation perspective):

design state. Focus on boundaries, concepts, and interactions.
development state. Focus on hierarchies, dependencies, and modules.
running state. Focus on performance, link level, and resource usage.

This version is equivalent to the design state. When implemented, it will also be restricted by development capabilities and data. In the future, should we also have a two-way binding of code and its architectural twin?

Core: Descriptive Programming vs Explicit Design

The specifications related to various architectures that we are familiar with have many problems, such as the specifications are not intuitive, the specifications are not automated, and so on. For an effective evolutionary architecture, we need to effectively combine specification, code, and design, that is, explicit programming and explicit design, which are all concepts from PL (programming language) / DSL (domain-specific language).

Illustrative programming is used to enhance the interpretability of execution results, such as in the context of architecture governance, by generating architecture diagrams to understand the results of DSL writing. Another type of visual ways, such as tables and charts in Excel. For details, see Martin Fowler’s related articles at the end of the article.
explicit design. Explicit is the manual method of accomplishing the desired changes by explicitly writing the instructions to be accomplished. Explicit design is a description language that guides us on how to build a good system, such as a DSL in ADL (Architecture Description Language). In addition to using the language pasted into the architecture description, there is also tool support for supporting the DSL, such as the editor IntelliSense.

These two features are improved around the idea of architecture as code, and Diagrams as code such as PlantUML and Graphviz also have this feature.

other traits

Of course, in order for this system to work well, we need a series of other features:

Simulation verification of architecture evolution. After building the digital twin of architecture, we can
Easily extendable functionality. That is, the microkernel architecture is adopted, that is, plug-in, micro-front-end, etc.

There’s still a lot to explore, and we’ll talk about it after we’ve built the first version.

How should we design and implement it?

We’re now implementing such a system in ArchGuard, and it’s pretty exciting. As an early version it barely worked, here are some ideas for how we built the system.

The Big Data Workbench as Inspiration

Since the system is a system similar to data analysis, much of our flu comes from the field of big data. On the workbench, initially, the idea was to build an RStudio-like compilable report and provide a Jupyter-like interactive experience.

But because Jupyter’s interactive experience is too poor, and the get files are not readable, they cannot be easily edited + run. Therefore, we use Markdown as the data format, which is convenient for developers to write documents and can also be opened and edited in any IDE. On the UI, the main editor of ProseMirror, that is, the editor of Markdown is used, and the Monaco Editor is used as the sub-editor, that is, the editor of the code.

Building REPL-based abstractions

With IDE support in mind, we adopted Kotlin to build the internal DSL so that no external DSL needs to be built with editor support. Then, Kotlin Scripting Compiler is used as the underlying REPL (read-eval-print loop, also known as an interactive top-level component ), which is simply the command line mode of the Kotlin language. In terms of form, it is similar to the form of MySQL Workbench, or the CLI mode of Python.

Then, there is the abstract system (ArchGuard), the design-state architecture, and the DSL of the architecture fitness function.

Operation of request and responder programs

With the support of the compiler backend and the Kotlin DSL IDE, we need to build a bridge between the two. Therefore, we use WebSocket as the communication method, and the returned results are processed according to different types. such as:

The result of running the integrated backend API.
Graphical results. Mermaid, D3.js, and Echart.js are for different graphic displays.
Perform the corresponding scan.

It is no different from the usual C/S structure development. Graphical results to support our declarative programming and explicit design.