From Abstract Concepts to Tangible Value: Solution Architecture in Modern IT Systems

1. Overview

Systems architecture involves designing, planning, and structuring a complex system’s organization and functionality. It is a critical engineering component that is vital in ensuring that a system functions effectively and efficiently.

Since the early days of software engineering, the concept of systems architecture has undergone significant evolution. Initially, systems were relatively simple, and their architecture was ad-hoc and informal. However, as technology and systems grew more complex, architects realised the importance of designing modular, scalable, and easy-to-maintain systems.

One of the earliest approaches to systems architecture was the Structured Programming paradigm, which emphasized using control structures such as loops and conditional statements to manage program flow. This approach was later refined with the Modular Programming paradigm, which advocated using modular code blocks to increase reusability and maintainability.

In the 1980s, Object-Oriented Programming (OOP) became popular, introducing the concept of classes and objects, which encapsulate data and methods and communicate with one another through well-defined interfaces. This approach was highly effective for developing large, complex systems and remains a popular approach to systems architecture today.

Recently, the industry has seen a shift towards microservices architecture. In this approach, a large system is broken down into smaller, independently deployable services that can communicate with each other through APIs. This approach allows for greater scalability and flexibility, as each service can be developed and deployed independently.

Today, systems architecture continues to evolve, with new approaches and paradigms being developed to meet the needs of modern systems. Regardless of the specific approach, the fundamental principles of systems architecture remain the same: to create a high-level design that meets the system’s requirements, is modular, scalable, and easy to maintain.

This article will discuss the fundamental principles of software systems architecture. The ideas presented here are based on excellent lectures from the MIT OpenCourseWare channel on Youtube. We have dedicated a separate five-part series on solution design, which we highly recommend you read.

2. Architecture vs Design — Which Term to Use?

Here are the key differences between the concepts of “architecture” and “design” in software systems:

1. Scope: Software architecture refers to a software system’s structure and organization. It includes high-level decisions about the system’s components, interfaces, and behaviour and the relationships between them. In contrast, software design focuses on the detailed design of individual components and their interactions.
2. Abstraction level: Software architecture concerns abstract concepts and high-level decisions, while software design concerns concrete implementations and low-level details.
3. Timeframe: Software architecture decisions are typically made early in the development process before any significant coding has been done. They are intended to provide a framework for the rest of the development process. In contrast, software design decisions are made later in the process as the system details are fleshed out.
4. Stakeholders: Software architecture decisions often involve input from stakeholders outside the development team, such as business analysts, project managers, and customers. Software architecture decisions significantly impact the organisation’s business strategy and long-term goals. On the other hand, software design decisions are typically made by the development team alone.
5. Flexibility: Software architecture decisions are harder to change later in development than software design decisions. This is because architecture decisions have a wider impact on the system and its stakeholders, and changing them can be more costly and time-consuming. Software design decisions, while still important, are typically easier to change later in the process.
6. Scale: Software architecture concerns the overall system and how its components fit together. As a result, architecture decisions tend to have a bigger impact on the system as a whole than design decisions. Software design, in contrast, is concerned with the individual components themselves.

In summary, while both software architecture and design are essential aspects of software development, they focus on different levels of abstraction, have different stakeholders, are carried out at different times, and have different levels of flexibility and impact on the system as a whole. Understanding these differences is crucial for effective software development and project management.

3. Creating Business Value

3.1 Business and Product Value for Organisations

In software, business or product value refers to the benefits a software product or solution provides to a business or organization. These benefits can include the following:

1. Increased efficiency
2. Customer satisfaction
3. Cost savings
4. Revenue.

Business value is a key consideration in software development, as it drives the decision-making process for software projects.

Business value is not just limited to the initial implementation of a software solution. As the software solution is used and evolves, it should continue to provide ongoing business value. This can include regular updates and enhancements that improve the software’s functionality or address new business needs.

3.2 Business and Product Value for Society

Product value should be measured not only in terms of its benefits to businesses or organizations but also in terms of its impact on societies or communities. In today’s world, there is a growing awareness of the importance of social responsibility and sustainability in business practices, which also extends to software development.

Software solutions can significantly impact society, both positively and negatively. For example, a software solution that improves access to healthcare or education can positively impact society. In contrast, a solution that perpetuates biases or discrimination can have a negative impact.

As such, it is essential for software development teams to consider the potential social impact of their solutions. This can include conducting a social impact assessment to identify potential positive or negative impacts on communities or societies.

Measuring the social impact of software solutions can be challenging, but it is essential for ensuring that software development is socially responsible and sustainable. This can involve working closely with stakeholders, including community groups, to understand their needs and concerns and incorporating their feedback into the development process.

3.3 The Creation of Business Value

The below diagram illustrates the value creation process.

Value creation in software occurs through a process that involves identifying and delivering value to customers or end-users. This process can be broken down into three key components: value identification, value proposition, and value delivery.

3.3.1 Value Identification

Value identification involves understanding the needs and desires of customers or end-users and identifying opportunities to create value through software solutions. This can involve: conducting market research, engaging with customers and end-users, and analyzing data to identify areas where software can provide value.

3.3.2 Value Proposition

Once the business value has been identified, developing a value proposition is next. This involves creating a clear and compelling statement of a software solution’s value to customers or end-users. The value proposition should communicate the solution’s benefits, how it addresses customer needs or pain points, and how it is superior to alternative solutions.

3.3.3 Value Delivery

Finally, value delivery involves delivering the software solution and ensuring it provides the promised value to customers or end-users. This involves designing and developing the software solution, testing and validating it to ensure that it meets user needs and expectations, and deploying it to users.

3.4 Continuous Value Monitoring and Regeneration

Throughout the value creation process, it is essential to continually monitor and measure the value the software solution provides. This can involve collecting and analyzing user engagement and satisfaction data, measuring the impact on key business metrics, and soliciting user feedback to identify improvement areas.

In summary, value creation in software involves identifying opportunities to create value, developing a clear and compelling value proposition, and delivering a software solution that provides the promised value to customers or end-users. Software development teams can create solutions that deliver real user value and drive business success by focusing on these key components.

4. Case Study: Architecting a Communications System

4.1 Problem Definition

Are you ready to take on the challenge of solving the age-old information transmission problem across large distances? This task requires your expertise and creativity as a solution architect or systems engineer.

Imagine this scenario: a centrally-located command and control centre needs to receive near-real-time intelligence from geographically remote monitoring outposts. The information must be transmitted quickly, reliably, and securely across long distances.

As the solution architect or systems engineer, you have been tasked with designing a communications system that can meet these demands within a two-year timeline and a budget of just a few million dollars.

To begin, you will need to carefully analyze the system’s requirements. What are the specific needs of the command and control centre and the remote monitoring outposts? What type of information will be transmitted, and how frequently? Once you clearly understand the requirements, you can begin designing a system that meets those needs.

Next, you will need to consider the technical aspects of the system. What type of communication technology will you use? How will the system be secured to prevent unauthorized access? What type of backup systems will be in place in case of a failure? These are just a few technical questions you must answer as you design your communications system.

As you work on your design, don’t forget to consider the budget and timeline constraints. With a few million dollars and two years, you may need to make some strategic choices to ensure the system is completed on time and within budget. This may require you to prioritize certain features or make trade-offs in certain areas.

4.2 Business Value Creation

Below is an executive summary of the task at hand.

• What is the business’s need?
  • An organization must implement a fast, secure, and reliable intelligence transmission system from outposts in remote areas to a central server in headquarters.
• Who are our stakeholders?
  • The organisation’s clients, competitors, suppliers, owners, and employees can influence its progress and be considered stakeholders.
• What are the project constraints?
  • A two-year timeframe to launch
  • A total budget of $5M

• What are the main business requirements?
  • The communication channels between the monitoring stations and the headquarters provide near-real-time, encrypted, and reliable transfer of valuable data.
  • Adding new monitoring stations does not result in system changes in other stations or headquarters.
  • The system operates reliably under different weather conditions with 99.99% data accuracy.
  • The operations team requires no more than basic IT engineering skills to operate the system.
  • The accuracy of the information relayed to the centre should be at least 90%.

• Value generation and delivery occur when:
  • The system satisfies the stakeholders’ needs.
  • The system is high quality, low cost, safe and easy to operate and maintain.

4.3 Building an Architectural Model

Having established some key requirements of the communications system we want to design, we can now model the system (using systems modelling language like OPM) as follows:

The diagram contains entities, states, functions, and forms, which we describe below:

4.3.1 Entities

Entities are objects that constitute the system’s building blocks. The first entity we are concerned with is Valuable Information or Intelligence. The second entity is a property of the Valuable Information object, which is its Availability to the headquarters.

4.3.2 Entity States

States are specific configurations in which a property of an entity can take. Intelligence can be in two states: 1) unknown, unavailable, or 2) available.

4.3.3 Functions

Functions applied to entities can transform them from one state to another.

1. Information Availing is a function that transfers intelligence between the two states mentioned above. We can identify three instances of this function: transport, mirroring, and forecasting.
2. Transport is the traditional method of communication where data is physically transported via a medium like radio waves.
3. Mirroring or transportation of entangled quantum bits (or qubits) forms quantum communication networks.
4. Forecasting is another method for “transporting” information from the future rather than other locations using mathematical models and historical data.

4.3.4 Forms

Forms are a particular type of entity, differing from the ones mentioned earlier in that these are concrete systems while the main ones (Valuable Information and Availability) are abstractions. Forms are physical systems that deliver the functionality in question.

1. Traditional communication systems are based on radio links (wires, antennas, and satellite links). The most mature and well-known of the three options.
2. Quantum networks involve quantum processors and qubits. However, their feasibility can be questioned at the time of writing as practical solutions that can be deployed and operated in the field.
3. Mathematical models use machine learning or statistical models to predict and forecast future events. Depending on the model’s prediction power, this solution can be viable.

Entities, states, functions, and forms allow us to conceptually represent what the system should do and how it would do it. In the next paragraphs, we will use this example to explain how architecture is created.

5. Principles of Building a Solution Architecture

Melvin Conway presented a five-stage approach to large system design. The following quote from his article How Do Committees Invent presents those stages:

In the following paragraphs, we will focus extensively on points 1 and 2, the rest (points 3-5) being a particular work method proposed by Conway for consultancy organisations engaging in designing large systems.

5.1 The Two Stages of Architecture

Solution architecture is a critical aspect of any project, as it defines the overall structure and functionality of the solution. It is a multi-stage process that involves both concept creation and concept selection.

Concept creation is the first stage in solution architecture, focusing on determining what works and what doesn’t. This stage involves brainstorming and ideation to come up with various possible solutions. It also includes the creation of architectural models, which provide a visual representation of the proposed solutions. The outcome of the concept creation activity is an architectural model representing the most promising solution.

Concept selection is the second stage in solution architecture, where the focus is on choosing the best solution from among the various possibilities. When selecting a solution, there are several things to consider, including:

Considering these factors, the best solution can be identified and implemented. The concept selection stage is critical to the success of any project, as it ensures that the solution meets the requirements and constraints. With a robust solution architecture in place, project teams can ensure that their solutions are reliable, scalable, and capable of meeting the needs of the end users.

5.2 What Is Concept Creation in Architecture?

If we look closer at the case study above on the communications system, every function, major and specialized form is a potential distinct solution to our problem. Let’s review these options:

1. Solutions 1: Classical transport, radio and satellite Links
2. Solutions 2: Statistical prediction, mathematical models, and AI–driven solutions

These combinations of function, form, and specialization are called concepts.

The process that generates solutions is known as Concept Creation and involves several steps, as illustrated in the communications system case study:

Logical decomposition is a critical topic we explored in greater detail in the article on Complex Problem Solving.

5.3 Form-Function Mapping

Function-form mapping is an essential step in any design exercise. Here are its fundamentals ideas:

The below diagram takes us back to the communications system case study.

On the left-hand side, we can see how the main Information Availing function can be decomposed into a primary part responsible for generating forecasts while secondary supporting functions are responsible for the admin part of the system, such as user setup and maintenance, data collection, processing, and storage, and reporting functionalities.

On the right-hand side, we have the submodules of the system. At its core is the statistical model responsible for generating forecasts, while other modules, such as Active Directory, provide user access and security functions.

5.6 Concept Selection

Concept selection is the application of decision analysis to select an optimal solution from a candidate list. Below are some of its key ideas:

Any selection method you use should satisfy the following constraints to be usable:

6. Concept Creation and Software Solutions Architectures

NASA Systems Engineering Handbook describes an interesting process for approaching design problems. The process is very systems engineering-oriented and must be adapted to suit software design problems. The essence, however, is the same.

On a high level, the process consists of two major stages that are iteratively applied to produce an optimal solution. A high-level requirement is established in the first stage, off of which a high-level design is produced. In the next stage, specific technical choices are made, requiring gathering additional, albeit low-level, requirements. This time, a low-level design is produced on these requirements.

The low-level design is validated to ensure it satisfies both levels of requirements.

The details of each step are as follows:

• Step 1: The process starts with stakeholder requirements turning into concrete objectives. A Business Requirements Document (or BRD) typically documents these needs.
• Step 2: A High-level Solution Design (or HLD) is generated based on the BRD for the stakeholders to review and sign off. At this stage, the business requirements and the design are still high-level, and there is a considerable challenge in providing lower-level detailed requirements without making further design decisions.
• Step 3: Logical Decomposition is now performed. The functions and forms of the High-level Solution Design are decomposed on one of the following bases into smaller, more specialized components and subfunctions:
  • Logical Flow
  • Functional Flow
  • Data Flow
  • Behavioural
  • States and modes
  • Depending on the system’s complexity, there may be one or more decomposition levels.
• Step 4: Now that technical design choices have been made, the second round of requirements gathering needs to be completed. Here, the requirements are low-level and delve into the specific details of the subfunctions and specialised forms.
• Step 5: A Low-Level Solution Design (or LLD) is produced off of the detailed requirements. The detailed design is now assessed for technical feasibility and quality assurance. If it’s deemed unfeasible, an alternative low-level design is produced.
• Step 6: A failure to produce a working design might trigger a revision of the low-level requirements. Perhaps they need to be relaxed or even fundamentally changed.
• Step 7: The design is then assessed on a functional basis. It is adopted if it satisfies all stakeholder requirements, follows industry best practices, and passes regulatory mandates. Otherwise, the high-level design is altered, and the cycle starts again.
• Step 8: A failure to produce a working design that passes functional tests might prompt a revision of the high-level requirements. A new concept might be tried.

The central theme of this approach is the iterative process that cycles through the alternative solutions to produce an optimal solution. It is also acceptable to simultaneously test out variations of the low-level design (through simulations, for example, or POCs) to identify the best combination.

Before we end this section, a few words on the decomposition process itself (Step 3 above), why it is needed, and what would be an appropriate depth and breadth of its levels.

Decomposition is a method for dealing with the limits of our cognitive abilities. In a famous article published in 1956 by George A. Miller, he stated that our minds could faithfully retain seven chunks of data on average and make correct absolute judgments on problems with around seven elements (like estimating the number of beans on a floor).

If you have a system composed of many components, you can organize them logically or functionally in a hierarchy where any level in this hierarchy contains around seven elements.

Another straightforward application that I find very useful is maintaining no more than seven lines in a single PowerPoint slide and where each sentence is around seven words.

7. Architecture and Complexity

In today’s market, a product must offer rich functionality to remain competitive. To achieve this, the subfunctions and secondary forms of the product must be numerous. If not, the product will only offer the bare essentials, which is unlikely sufficient in today’s sophisticated market.

Client tastes have evolved with time, becoming increasingly sophisticated. Decision-making has also shifted from technical experts to business people. As a result, products must offer a wide range of supporting functionality to compete effectively. This, however, means that products are becoming more complex and more challenging to design.

Complex systems with numerous parts and plenty of functionality can be costly. Design optimization is crucial to keep costs down, but this exercise has its price. Design optimization results in high interconnectivity between functions and forms, increasing the overall number of parts and using existing functionality best by leveraging reusable components and processes.

However, a complicated technology stack combined with users who only know what they want once they start using the systems complexifies the process substantially. These new system properties make predicting the system’s evolution and the user’s requirements challenging. Optimization brings complexity, which, in turn, leads to fragility. The system architecture’s job is to manage that complexity.

In summary, the forces of complex system design are many. User preferences evolve with time, and the need to remain competitive and user interaction with the system are just a few. Design optimization is necessary to keep costs down, but it brings about complexity, leading to fragility. The system architecture’s job is to manage this complexity to ensure the product remains robust and reliable. Ultimately, the relationship between complexity, optimization, and a highly-connected system with many parts is critical in software systems, the global economy, and the political system.

8. Final Words

A few decades ago, architecture was simple enough. Solutions consisted of a few applications, and these were faithfully modelled in the traditional Model-View-Control blueprint.

This architecture can now be considered severely outdated; any modern solution has to make place for single-sign-on, analytics, automated testing, and continuous delivery at a minimum. Modern architecture needs to allow for that.

Architecture also involves intensive decision-making activities and can significantly impact influential players, making it more crucial to have a decision-making framework that helps avoid emotionally-driven choices with adverse strategic consequences.

Making the right decisions early on can avoid significant redesign efforts later in the implementation. It is sometimes tempting to give in to management pressure to reduce design efforts for cost or time. Pressure can likewise be applied to force specific views by influential experts in the organization.

Therefore, sound architecture also balances what’s practical and what works. We hope the ideas in this article help you find that balance.

9. FAQ

10. References

• Nasa Systems Engineering Handbook
• MIT OpenCourseWare lecture on System Architecture: