Key Architectural Elements for Solution Designers in the AI Era

A simple yet holistic modeling approach for shared understanding

Almost everyone admits that software architecture is hard. However, with the prevailing and increasing power of AI, software architecture has become easy, as AI can generate much of the architectural design work and dramatically reduce the amount and strain of coding work. What is still really hard is solution architecture, especially large and complex enterprise solution architecture (ESA).

If you are a relatively standalone application developer or a small-scale solution designer, you may just focus on your design scope or functionality. However, if you are a medium to large-scale solution designer or developer in fields like scalable data & systems engineering, the challenges often don’t come from the software but from the integrated solution architecture. A good understanding of the whole solution environment and its key elements and their mutual impact will distinguish between a so-so solution designer and an insightful one.

General Issues with the Solution Architecture

Traditionally, related architectures lie in two extremes: enterprise architecture and software design. Enterprise architecture (EA) is generally a good planning tool if used well, but it often falls short of expectations due to its disconnection with the solution realities. Software design, on the other hand, often focuses too much on the application development, losing sight of the big picture of business capabilities, integrated solution context, or operational environment.

In reality, only a handful of developers (or architects in this role) use architectural modeling tools to have a holistic enterprise solution view. The reasons are multifold, including a lack of a proper modeling approach that represents the key (enterprise) solution elements in one specification or place, and a lack of proper tools for simple and sufficient solution architecture (neither the prevailing EA nor UML-like tools do well). Often,

• The simple box and shape views won’t tell the full story
• The one-time shot sketches are just good for initial discussion and brainstorming
• The agile methods or tools, like Jira, don’t promote a clear solution architecture model
• The complex architectural model, either using sophisticated tools or a set of tools (EA/BPM/UML), with a detailed or design mindset, defeats its purpose.
• AI-assisted modeling will not provide a meaningful architecture without a well-formed element specification in the first place.

This makes solution architecture especially hard (beyond the hard software architecture) due to the lack of a simple yet holistic model for shared understanding.

A Simple yet Practical Modeling Approach

In the AI era, we need an architectural model based on the S3 principle: simple, significant, and systematic, that is, a holistic solution model rooted in simplicity and significance. The following table summarizes the simple yet practical modeling elements at an enterprise solution level.

Generally, an architect creates simple yet all-rounded views around the mentioned areas. As a solution developer or designer, you are inherently familiar with the functional views, but you need to be more concerned with the other views that are related to the functional views. The commonly suggested views include case scenario views, operational views, and solution outline views, like solution context, solution building blocks, DevOps view, pattern view, and validation view.

The above table presents a lean mode of enterprise solution elements for quick modeling. The simplicity will promote the adoption and learning. For a more full-scale enterprise modeling, the elements will expand a bit more. For example, the service element will include data, UI, app logic, and tech services for easy division of work and service-level characterization.

Agile ESA modeling approach is simple, yet it covers enterprise architecture, BPM, UML, and many other specifications and tools at the enterprise solution level, so that you can have an architectural model in one place for easy and shared understanding. See Appendix: “Why use Agile ESA over other Modeling Tools?” for a brief comparison.

An Illustrative Agile ESA View

As a modeling specification, the agile ESA is embodied through model views. The following is an example DDD (Domain-Driven Design) architectural style overview (created from the diagram.a-esa.com for illustration purposes), stringing lean mode elements together to minimally represent their usage and relationships.

You may notice the preferred visualization style by the agile ESA, where each element type is clearly seen as a node image. This facilitates the architectural understanding of the typical elements and how they interact.

Of course, you can produce the view using a diagram-as-code approach, as shown in the following example. You can also automatically generate the diagram in your chosen shapes. Caveat: the auto-diagram may not present the layout as you wish.

In a solution landing case, the model views minimally contain case scenario, system context/overview, functional, and operational views, plus capability, metrics, and validation views, etc., based on your solution needs. When a shared understanding of the model deliverable is reached in an agile modeling approach, your enterprise solution architecture becomes clear. Architectural clarity is the very foundation for a viable enterprise solution. You can virtually model any type of enterprise solution architecture using the agile ESA specification for simplicity, significance, and systematics.

For humans, modeling is a good means of visualization for easy understanding, but for AI, it’s a database of information about your architecture. For meaningful architectural modeling through AI-human collaboration, a semantic model, both simple and practical, is the future direction.

Why use Agile ESA Modeling when empowered with AI Tools?

AI is powerful and facilitates architectural thinking and modeling. Apparently, AI dramatically reduces the complex work both in enterprise architecture (planning) and solution design (based on the specification). However, AI is weak in the enterprise solution modeling practice, which requires much of the art, rather than science. Human-driven ESA modeling shines through contextual understanding, innovative or strategic thinking, tradeoff decision making, ethnic compliance, proper level of abstraction, etc.

These critical spaces are skills particularly required of solution designers or developers in an architect’s capacity. They must transition from deterministic ("if X then Y") to architectural ("systematic impact") thinking, and leverage AI to augment core solution architecture modeling. If a solution designer does not have many of these qualifications, many of their capabilities will soon be replaced by AI.

In a nutshell, the simple yet holistic set of architectural elements forces you to consider important issues, tradeoffs, abstraction, and coupling on top of the detailed structural architecture, which is left to AI for design work.

Follow-ups

This article is a brief introduction to the lean mode of enterprise solution modeling. The architectural modeling will not be complete without a hands-on practice. You can now try to create your effective architectural model(s), assisted by AI prompts that center around these elements for your enterprise solution(s). Here is the agile ESA diagram tool (lean mode) for free use.

Note that it’s not merely a matter of a modeling tool. The key here is the set of architectural element notations that are simplified, practical, and consistently applicable across different projects at the enterprise solution architecture level. The model is for architectural thinking, rather than more detailed architectural design.

Thank you for your interest. I can be reached at [e-mail] for comments, suggestions, or help.

Reference

• Mastering Enterprise Solution Modeling/Gu, Sean (Chunhong). APRESS, 2024

APPENDIX: FAQs & Discussions

In our solution projects, we have use-case diagrams, software application diagrams, deployment diagrams, and architecture overview diagrams. What differs from this approach?
Having architecture diagrams is one thing; having a succinct yet meaningful model view is another. A good modeling is generally judged by: 1) correlated views (beyond diagram level without consistency check), 2) architecturally significant elements (either missing key elements or fluffy/detailed elements hardly provides a holistic model), 3) containing both decisional and structural elements (as shown in this approach), 4) clear mapping between different architectural layers (for example, the deployment unit/package mapping between functional services and deployment environment), and 5) right level of abstraction (note that design views are not architecture views). Of course, more elaboration will be based on the substance of your architectural views.

Why are some common infrastructure elements, such as storage and network, not included?
The infrastructural level is easier to handle as it’s generic and application-agnostic. In a cloud environment, it’s taken care of by the vendor. In the lean mode, the storage system can be represented by a data store or loosely by a database, network by node or domain. The standard version of enterprise modeling includes more elements, such as the network or device element for design guidance. For a specific group of stakeholders, a model view can consist of assistive elements (peel off from its base element), for example, more detailed middleware elements such as a message broker, edge interface, etc. But be cautious not to use too many elements to complicate the solution architecture. In practice, to distinguish a specific element from another, you can 1) use a different iconic notation or image, or 2) use a different prefix while keeping the core architectural elements consistent and straightforward.

Why are some application-specific elements, such as class and object, not included?
The mentioned approach targets architectural model thinking. Including detailed elements would require delving into the design or implementation level. The architectural model provides design guidance more from a governance perspective. For DDD (domain-driven design) architectural design, for example, you can use the grouping element for a bounded context as a logical boundary concept, use a domain element that’s already in there, and use a service component for aggregates to represent a group of entities and value objects as a single unit for data changes. Even in a lean mode, you can use a prefix to distinguish aggregates, entities, and value objects when modelling significant cases for walk-through validations.

How to include decisional architecture into the model?
You can specify decisional elements, such as principles and key choice elements, and associate them with the related view(s) or element(s). You can also include pattern guidance, governance functions, etc., as part of the description or parameters of the related element, as seen in the service component example in the above table.

How to express architectural abstraction in the model?
Without architectural abstraction, the model is virtually a design or implementation model. The abstraction can be expressed using domain, grouping (logical), and service elements. A domain can be denoted as a physical grouping for transactional boundary, etc., and service is more generic to express solution building blocks at a proper level of abstraction. You can use more abstraction elements in the standard mode for scalable solution modeling.

What are the key skills for high-level solution developers in the AI Era?
In an AI-driven environment, solution developers’ skills naturally include familiarity with AI frameworks (TensorFlow, PyTorch) and understanding of ML concepts (neural networks, supervised/unsupervised learning). Beyond those technical skills, solution developers need to have an architect’s mindset:

• Simplify representation of complex solutions with leading practices, patterns, and architectural styles.
• Understand the solution(s) from a multiple view of all stakeholders
• Make better trade-off decisions
• Have good modeling skills at the enterprise solution level to ensure requirement mapping, deployment mapping, and enterprise capability mapping All these can be better achieved or facilitated when using a set of practical and straightforward modeling elements.

Why use Agile ESA over other Modeling Tools?
A-ESA is both an architectural approach and a modeling language. Its scope and impact can be better understood by comparing it to the prevailing modeling tools:

• ArchiMate — It is an enterprise architecture specification. In contrast, A-ESA is IT-service-based, bridging enterprise architecture to solution architecture. It emphasizes solution building blocks, non-functional characteristics, and key architecture decisions. A-ESA is also more concise, and its lean mode comprises only 12 essential elements.
• UML (Unified Modeling Language) — It is primarily aimed at software architecture and design, or software engineering.
• C4 Model — It is based on hierarchical abstractions (software systems, containers, components, and code). However, the C4 model often requires incorporating other models (such as UML/BPMN), metric elements, or additional notations to achieve correlated, systematic architectural conformance.