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

In the previous article "Architecture as Code: Coding Next Generation Enterprise (Application) Architecture Systems", we introduced architecture as code The idea is how to combine and present architectural elements and features around a series of patterns of architecture, and closely integrate architectural decisions and design principles with the system.

In order to implement and implement the concept of architecture as code, it is also necessary 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.

Here is screenshots:

Why build Architecture Workbench?

In ArchGuard, we want to manage three forms of architecture: design state, development state and operation 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, for the departments related to the structure of many medium and large organizers, they also have the above problems. And, I believe they face the same dilemma that we built ArchGuard:

1. Architecture is multidimensional. Including technology, data, security, operation and maintenance and systems, etc.
2. Lack of a unified architecture language. Human language for communication, such as what is a component?
3. The architecture of the system is very strange. Architectural style or pattern differences, such as microservice architecture, plug-in architecture, etc.
4. Lack of business context. Being an external architect lacks some context to help with governance.
5. 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.
6. Our (ArchGuard team) current architecture capabilities are limited - 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 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, Jupyter's interactive analysis. So, our definition is:

The Architecture Workbench is an environment designed to help people design architectures, evolve architectures, observe architectures, and effectively use the high-quality tools required for architectures, 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 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 the architecture
• Descriptive programming and explicit design

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

Basics: 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.

Evolving Architecture. Its core is building an architecture governance model and designing 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.), design metrics, and provide high-quality tools to guide the architecture back to a reasonable state.

Observation Architecture. That is, to observe the running status of the application of the architecture, it 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 boundary, concept and interaction.
• Development state. Focus on levels, 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 two-way binding of code and its architectural twin?

Core: Descriptive Programming vs Explicit Design

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

Illustrative programming (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 way, such as tables and charts in Excel. For details, see Martin Fowler's related article 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 done. 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 editor intellisense.

These two features are improved around the concept of architecture as code, such as PlantUML, Graphviz and other diagrams as code (Diagrams as code) also have such characteristics.

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 the architecture, we can
• Easy to extend 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 are now implementing such a system in ArchGuard and it is quite exciting. As an early version it barely worked, here are some ideas for how we built the system.

1. Big data workbench as inspiration

Since the system is a system similar to data analysis, many of our flus come from the field of big data. On the workbench, at first, the idea was to build a compilable report that takes RStudio-like and provides a Jupyter-like interactive experience.

However, due to the poor interactive experience of Jupyter, the downloaded files are not readable and 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 is used, that is, the editor of Markdown, and the Monaco Editor is used as the secondary editor, that is, the editor of code.

2. 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 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 DSL of the abstract system (ArchGuard), the architecture of the design state, and the architecture fitness function.

3. Request and responder operation

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:

• Integrate the running result of the backend API.
• Graphical results. Mermaid, D3.js, 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 Descriptive Programming and Explicit Design.

other

We are still designing and building such a workbench, feel free to hook us up: https://github.com/archguard/archguard.

Reference content:

• "Domain specific language"
• "Evolutionary Architecture"
• "Data Analysis with Python"
• "IllustrativeProgramming"