DEV Community: Sean

Fundamentals of Solution Architecture Modeling

Sean — Fri, 02 Oct 2026 07:34:39 +0000

In this post, I provide a brief introduction to solution architecture elements, the key elements that matter for most solutions.

We see various solution architectures using different elements. Each cloud architecture, for example, can have hundreds of representative elements from each vendor. For complex solutions, however, we need to focus on architectural elements at the solution architecture abstraction level. These elements are critical for focused architectural thinking because each represents a unique set of architectural characteristics or architectural techniques.

Very briefly, this paper presents the commonly used solution architecture elements applicable to most solutions and illustrates how these elements can support architectural thinking.

Solution architecture also involves solution architecture management (budget, resource, timeline, deliverable phase), which serves as a context for the solution architecture. This paper focuses on the content or the core of the solution architecture.

Solution Architecture Elements

Solution architecture includes a high-level view of software engineering and systems engineering, together with requirements considerations. The elements are divided into three groups that provide coverage of the solution architecture.

Instead of a long narrative, I list the solution elements in an easy-to-understand visual view.

Figure 1 shows the intent and metrics layer elements. The yellowish color represents the user end, white represents business considerations and design decisions, and the light purple color represents the key metrics, including quality attributes, architectural decisions, and governance controls.

Figure 1. User Intent Elements

Figure 2 shows a list of application-level elements. These are the critical functional service-level elements, each of which needs to be carefully considered. For AI solutions, AI-specific elements should also be included. The components are also related to software design and are either high-level or used for walkthroughs for validation purposes. The microservice elements are partially operational considerations.

Figure 2. Functional/Application Elements

Figure 3 shows a list of operational/middleware elements. The bluish elements represent middleware, whereas the gray elements represent the operational infrastructure level.

Figure 3. Operational/Middleware Elements

Key Architectural Concerns

With a well-defined set of solution architecture elements, we can facilitate architectural modeling by thinking through these elements to see how they are considered, mapped, and guided.

For a sound architecture, we need to look beyond technical details or specifications and focus on the architectural concerns that are significant to the solution. Let’s look at this through the picture in Figure 4.

Figure 4. Thinking on Architectural Characteristics

User Intent

In most cases, user intent is the basis for our solution needs. It can come from users, enterprise planning, or solution design, and it determines what the solution will perform and how it will behave. This includes use cases, business processes/tasks, functional requirements and non-functional requirements (mostly implicit), user environment, and enterprise principles and capabilities.

Metrics

For the intent to be realizable, we need a set of metrics, including risk assessment, measurable non-functional requirements, key architectural considerations, and governance measures and controls. This metrics layer is critical for guiding and governing the whole solution, and it is often missing from solution architecture diagrams.

Architectural Techniques

Next, we consider the architectural techniques that matter most to the solution. These are often overlooked in thoughtful architectural considerations.

In general, layering is a key factoring technique that impacts the shape of the solution architecture. Whether it is vertical slicing or top-down layering, it determines the granularity of the solution.
Granularity is commonly considered one of the toughest parts of software architecture. The appropriate degree of granularity depends on the needs of each solution, and there are no universally applicable rules for all solutions, although we can follow some general principles. For a complex solution, changing granularity later can prove difficult or even impossible. The application or functional-level elements help identify and clarify granularity decisions.
Strongly associated with granularity are cohesion and coupling. As we know, loose coupling is a good architectural practice. In most cases, coupling is inherently determined by module cohesion. We need to balance key trade-offs, such as maintainability versus performance, when making cohesion and coupling decisions.
Isolation seems obvious, yet it is often ignored during implementation. For a scalable solution, isolation is a key consideration. Deployment unit mapping is the key link between the software architecture and the operational environment. Incorrect mapping can create significant architectural debt in real solutions.
For an AI-assisted solution, autonomy plays a much more important role in intelligent automation and dynamic processes. The AI’s role and the human loop need to be clearly defined. Think carefully about what needs to be automated, semi-automated, autonomous, or semi-autonomous.

Non-functional Qualities

The focus of architectural modeling is to consider the non-functional qualities determined by both software architectural design and the operational environment. Middleware/platform choice is also a key architectural decision for solution architects. There are many middleware options to choose from. Select them based on a balanced consideration of performance, availability, security, maintainability, and cost.

In particular, the cost of change is an ultimate consideration in most architectural decisions. Maintainability results more from software architectural design and deployment strategies than from the operational environment, so architectural techniques have a significant impact on non-functional qualities.

Conclusion

Architectural modeling is not just about diagramming; it is a thinking process. Think through all the core solution elements, place them in your view to apply architectural techniques and identify their correlations. Through iteration and regular review, reach and maintain an architectural model that is holistic and rooted in simplicity and significance.

A solution typically covers both intent and architectural concerns, both software and system architectures, and both implicit enterprise input and explicit design guidance output. As part of ESA (enterprise solution architecture), it plays an increasingly important role in the AI era, when enterprise planning and solution design details are increasingly handled by AI.

Reference Sources

GitHub Link (Including Iconic Notations)
Agile Enterprise Solution Architecture/Gu, Sean. Vernal Press, 2021/2026.
Mastering Enterprise Solution Modeling/Gu, Sean. APRESS, 2024

Key Architectural Elements for Solution Designers in the AI Era

Sean — Thu, 14 Aug 2025 15:18:51 +0000

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 seangu@a-esa.com 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.