Fundamentals of Solution Architecture Modeling

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.