One of the main challenges in architecture design is to break down complex systems into clearly defined, modular components depending on the functional and non-functional requirements. Generally speaking, LLMs can act as intelligent assistants by helping to analyse textual descriptions, structure requirements and provide suggestions for the modularization and structuring of the architecture. In this way, LLMs can help to outline the initial architecture and create architecture documents efficiently.

>> Read parts 1 to 5 of the article series "ChatGPT in the industry"

A particular challenge is that, in addition to the textual description, diagrams are usually also used for the architectural representation and documentation. However, since the LLMs available today cannot generate these directly and no usable results can be expected from the AI image generators available to date apart from pretty pictures, a little trick has to help: By using text-based diagrams such as 'PlantUML', 'Mermaid' or similar, LLMs are able to provide support in this respect as well. They are therefore not only dependent on pure text information.

General prompt engineering rules

In order for the use of generative AI for conceptualization and architectural design to be successful, the rules for prompt engineering described in the previous articles also apply here. To summarize:

• Use generally good prompt wording: clear and specific instructions, separators and structured output formats.
• Use prompt techniques that help to increase the "depth of thought" and "reasoning" of LLMs: For example, chain-of-thought, tree-of-thought or step-back prompt techniques.
• Using prompting techniques with format templates and content examples such as the few-shot prompting technique.
• Compiling the decisive local contexts either manually or with the support of an intelligent local search system called RAG (Retrieval Augmented Generation), which is also frequently used with chatbots.

Proven architectural design processes

There are many ways to achieve a good software architecture. Two well-known and proven approaches are the 'arc42' and 'C4' methods for documenting and visualizing software architectures, which we can also use for support with generative AIs.

arc42 is a freely available, very well-structured template and is therefore not a pure method in the true sense of the word. This template is a framework for documenting software architectures, which is divided into twelve sections to cover as many architecture-relevant aspects as possible. It begins with an introduction and objectives, followed by boundary conditions and a context definition. Sections such as the building block view, runtime view and distribution view enable developers to describe the architecture comprehensively and make it comprehensible. The perspective on risks and technical debt as well as a glossary conclude the template.

>> Read parts 1 to 5 of the article series "ChatGPT in the industry"

Thanks to the good structure and the various well-described predefined views, arc42 offers an excellent starting point for using generative AI to pre-formulate the individual sections in conjunction with your own given information and intentions.
In contrast to arc42, the C4 modelling method is not a document template, but an approach to representing the architecture of software systems based on the visualization of different levels of abstraction. It comprises four levels, each of which looks at a specific aspect of the software architecture in more detail: Context, Container, Components and Code. Starting at the highest level (Context), the system is shown in relation to external systems and users, followed by a more detailed representation of the main applications and data storage in the Containers diagram. The third level (Components) further breaks down the containers into their main components and their interactions, while the Code level finally shows the implementation details, such as classes or interfaces.

Figure 1: The ChatGPT task: to create a retrofit-capable IIoT kit for temperature monitoring of production facilities. This involves additional sensors, data loggers, a transmission unit and a PLC-capable independent dashboard.

© talsen team

The systematic decomposition of larger problems into the respective different levels of abstraction is a proven tactic for working productively with generative AIs. As described in the previous article, the principle of "coarse to fine" has also proven to be very useful in supporting the formulation of requirements according to the abstraction levels from behavior-driven software development (BDD). This makes it easy to regulate the required depth of thought of the LLMs. If the results become too fuzzy and the formulations of the LLMs are no longer useful, this is a strong indication of either the lack of relevant context or too large a jump between abstraction levels, resulting in too many unseen and unknown assumptions on the LLM side. This in turn most likely results in a higher manual correction effort of the LLM answers.

Using the example of the current top model gpt-4o from OpenAI (accessible via the paid account of ChatGPT), we take a concrete look at how useful the tactic of "coarse to fine" or "divide and conquer" is for the use of generative AI using the architectural description of a simple IIoT example(Figure 1):

The example of interlinked production plants can be approached with two architecture descriptions:

• Variant 1: The creation of an architectural image or diagram using a simple text and image description.
• Variant 2: The systematic creation with C4 using a simple text and image description.

Variant 1 - a method that is too simple

The use case demonstrates that LLMs can generate very different result qualities depending on the prompt. If we use the image of the IIoT example - which can be inserted using drag&drop or copy&paste - with the prompt "Create the component diagram of the required application based on the given description", this is literally too short-sighted for the LLM. The results will be disappointing and unusable in most cases without further specifications.