Solution Concept Diagram

Draw a high-level representation of your solution

This guide shows how you can create a Solution Concept Diagram, the first artifact providing a more technical view of your architecture. The goal is to define architecture building blocks on the basis of the solution context and arrange them into a first architectural concept. The business capabilities expressed in the solution context are transformed to architecture building blocks (ABBs) in the solution concept. The solution concept structures the building blocks and shows their relationships in a diagram.

GOAL

Define a high-level representation of your solution.

PARTICIPANTS

Enterprise Architect

TIME NEEDED

Depends on complexity of the solution (30 minutes to multiple days)

PHASE

Design

Before You Start

Collect Innovation Opportunities
It can be particularly useful to evaluate and prioritize use case ideas based on value and effort. In this case, a previous session is required to compile a list of possible use case ideas. See the method:

Collection of Innovation Opportunities

Solution Context
Get a high-level overview about which organizational units and business roles are using the solution.

Materials you will need

Templates for Download

Steps

  • Depends on solution complexity

Identify Architecture Building Blocks

Starting from the identified capabilities in your Solution Context Diagram and the information from the Use Case Blueprint Diagram define Architecture Building Blocks (ABB) for each capability.

These building blocks represent functional components of your architecture.

The innovation opportunities you got from the Use Case Blueprint Diagram are a good starting point to find out which ABBs you need.

The translation of the capabilities into ABBs is a refinement of the Solution Context. These building blocks mark the transition from a business view to a technical view of the architecture. As the building blocks of the Solution Concept Diagram relate to the business capabilities from the Solution Context Diagram their titles might be the same.

Taking the “Requesting project budget” and “Get status of budget request” business capabilities from our example, you can translate these capabilities into one ABB “Request / Status Application” providing both capabilities.

Completed Example

When defining ABBs keep in mind that some capabilities from the Solution Context Diagram need to be split into several building blocks.

Be aware that this diagram is read by technical- and business people and therefore should be understood by both.

  • Depends on solution complexity

Draw your defined building blocks

. Draw your defined building blocks and their relationships into a diagram.

The relationships between the building blocks describe the request/response relationship. These relationships can be displayed with arrows pointing from the requesting building block to the respondent.

Furthermore, think about the existing IT systems which are related to your solution and add them to the diagram with the respective relationships to the ABBs.

Formally the relationships can be split into “Request-Response” and “Information flows” but from our experience and to avoid confussion, it is good enough to work with “Request-Response” only.

  • Depends on solution complexity

Add business units to your diagram

To complete your diagram, add the respective users interacting with the ABBs.

Map the users from the Solution Context Diagram to your Building Blocks.

Use the “Request-Response” relationship to outline which business users are interacting with which building block(s).

This step can alternatively be combined with step 2.

  • 10 minutes

Verify your Solution Concept Diagram

Informing your stakeholders (e.g. project managers or other architects) and verifying the Solution Concept Diagram is very important to ensure the assumptions made during the creation of your Solution Concept Diagram are correct.

If you created a stakeholder matrix and communication plan consult it to check how this verification should be done. (e.g. by email or as part of regular stakeholder meetings).

You are done!

Make sure to take the Solution Concept Diagram into account whenever discussing the high-level technical view of your solution.

Follow the next methods in the Recommended Path to continue setting up your innovation project.