When shaping an Enterprise Architecture initiative, architects often encounter two similar terms: Solution Context and Solution Concept. Both are typically developed before detailed design begins, but they answer fundamentally different questions.

Solution Context describes the environment and boundaries surrounding a solution, while Solution Concept describes how the organization intends to address that context.

Put simply, Solution Context helps architects understand the problem space and operating environment, whereas Solution Concept provides an initial view of the solution space. This article explains the difference between Solution Context and Solution Concept, what each deliverable should contain, how they relate to TOGAF® and SAP Enterprise Architecture, and how they can be applied in an SAP transformation.

How TOGAF® Positions the Solution Concept

TOGAF® explicitly identifies the Solution Concept Diagram as a diagram used to communicate the Architecture Vision. The Open Group describes its purpose as follows:

“The solution concept diagram provides a high-level orientation of the solution that is envisaged.”

Rather than being a detailed architecture model, it is intended to provide a rough view of the proposed solution during the early stages of an engagement:

“It represents a ‘pencil sketch’ of the expected solution.”

The diagram may also communicate the objectives, requirements, constraints, and areas that require further investigation:

“This diagram may embody key objectives, requirements, and constraints for the engagement.”

By contrast, Solution Context is not necessarily defined as a standard TOGAF® diagram at the same level as the Solution Concept Diagram. In practice, organizations use terms such as Architecture Context, System Context Diagram, and Solution Context View to describe the scope, external actors, external systems, assumptions, and constraints surrounding a solution.

Therefore, when an organization-specific EA method or an SAP program uses “Solution Context” as the name of a deliverable, Enterprise Architects should also check the organization’s own deliverable definition.

What Is a Solution Context?

A Solution Context describes the business, organizational, information, and technology environment in which the target solution will operate.

It answers the following core question:

Who will use the solution, what will it exchange information with, and where do its boundaries begin and end?

Purpose of a Solution Context

The main purposes of developing a Solution Context are to:

• Clarify the scope and boundaries of the solution
• Agree on what is in scope and out of scope
• Identify external actors, including users, organizations, and business partners
• Understand surrounding systems and major inputs and outputs
• Identify constraints such as regulations, security requirements, deadlines, and existing contracts
• Establish a shared understanding on which the Solution Concept can be developed

What a Solution Context Should Contain

Perspective	Information to Identify and Document
Subject	The business, process, organization, or solution under consideration
Boundaries	In-scope and out-of-scope areas and points of responsibility
Stakeholders	Customers, employees, executives, business partners, and regulators
External organizations	Sales companies, plants, logistics providers, suppliers, and OEMs
Surrounding systems	Legacy ERP, MES, WMS, EDI, and data platforms
Information exchanges	Demand, orders, inventory, capacity, production orders, and shipment results
Constraints	Regulations, security requirements, existing contracts, and migration deadlines
Assumptions	Cloud strategy, standardization policy, and continued use of existing assets

At this stage, the primary focus is not product selection or a detailed system configuration. The first task is to establish what belongs to the problem being addressed and what should be treated as part of the external environment.

What Is a Solution Concept?

A Solution Concept builds on the Solution Context, stakeholder concerns, and Architecture Requirements to describe the fundamental structure and guiding approach of the future solution.

It answers the following core question:

What combination of capabilities, processes, data, applications, and technologies will address the problem?

Purpose of a Solution Concept

The main purposes of developing a Solution Concept are to:

• Establish a shared direction for the future solution
• Show the relationships among Business, Data, Application, and Technology at a conceptual level
• Communicate the Architecture Vision to executives and program stakeholders
• Clarify the responsibilities and roles of the major solutions
• Provide a starting point for detailed domain architecture work
• Connect the proposed solution to the expected Business Outcomes

What a Solution Concept Should Contain

Perspective	Information to Identify and Document
Business Outcome	Inventory reduction, improved on-time delivery, and reduced planning effort
Business Capability	Demand planning, supply planning, detailed production planning, and manufacturing execution
Process	The relevant end-to-end processes and their main flows
Data	Key data objects, data ownership, and conceptual data flows
Application	Major solutions and their division of responsibilities
Integration	Key integration relationships between systems
Technology	Fundamental cloud, on-premises, and platform decisions
Principles	Fit-to-Standard, Clean Core, API First, and other guiding principles

A Solution Concept is not a diagram filled with product logos. It must explain what each component is responsible for and how it contributes to the intended Business Outcomes.

Solution Context vs Solution Concept: Key Differences

Comparison	Solution Context	Solution Concept
Core question	What surrounds the solution, and what is within scope?	How will the problem be solved?
Primary purpose	Understand the environment, boundaries, and dependencies	Align stakeholders on the direction of the future solution
Perspective	Outside-in	Future-oriented and inside-out
Main elements	External actors, surrounding systems, inputs, outputs, and constraints	Capabilities, processes, data, applications, and technology
Treatment of SAP products	Kept to a minimum; it can be developed before products are selected	Candidate or selected SAP solutions and their roles may be shown
Level of detail	Sufficient to understand the scope and relationships	A “pencil sketch” of the future solution
Primary audience	Enterprise Architects, Business Architects, Business Analysts, and Project Managers	Sponsors, CIOs, Enterprise Architects, and Solution Architects
Subsequent work	Requirements analysis and scope agreement	Domain architecture, roadmaps, and Transition Architectures

These are not competing deliverables. They are complementary: the Solution Concept should be developed from an agreed Solution Context.

Example: An SAP Supply Chain Transformation

Consider an automotive component manufacturer seeking to respond more effectively to demand volatility, reduce inventory, and improve on-time delivery by using SAP IBP, SAP S/4HANA, PP/DS, EWM, and SAP Digital Manufacturing.

What to Capture in the Solution Context

• The company receives forecasts and firm orders from OEMs through EDI
• Domestic and overseas sales companies submit demand forecasts
• Multiple plants provide capacity, inventory, and production results
• Suppliers provide component supply information
• Different legacy ERP systems operate across regions
• Existing MES and EDI platforms will remain in use for the time being
• The organization runs monthly S&OP, weekly supply planning, and daily detailed planning
• Planning and execution integration is in scope, while product design is out of scope

The objective here is to clarify the enterprise environment and boundaries of responsibility surrounding the planning and execution solution.

What to Capture in the Solution Concept

• SAP IBP for Demand supports statistical forecasting and demand consensus
• SAP IBP for Supply supports medium- and long-term constrained supply planning
• SAP S/4HANA and PP/DS support detailed planning that leads to production orders
• SAP EWM manages internal logistics, component staging, and inbound and outbound processes
• SAP Digital Manufacturing captures production, quality, and equipment data
• SAP Integration Suite connects the solution with existing ERP, MES, and EDI platforms
• Integrated plan and actual data enables exception-based decision-making

This view shows how SAP solutions can be combined to deliver value within the agreed Solution Context.

A Seven-Step Method for Enterprise Architects

1. Confirm the Business Outcomes

Start by clarifying the outcomes the transformation is expected to deliver—for example, a 20% reduction in inventory, improved OTIF, shorter planning cycles, or lower premium freight costs.

2. Identify Stakeholders and Their Concerns

Identify the concerns and decisions of executives, demand and supply planners, plants, sales organizations, IT teams, suppliers, and other relevant stakeholders.

3. Develop the Solution Context

Place the subject at the center and position external actors, external organizations, surrounding systems, and major information exchanges around it. Draw an explicit boundary and identify what is in scope and out of scope.

4. Derive the Architecture Requirements

Use the context and stakeholder concerns to identify functional, data, integration, security, and non-functional requirements.

5. Develop the Solution Concept

Bring together the Business Outcomes, capabilities, major solutions, and high-level data and process flows in a single view. Detailed APIs, tables, and infrastructure configurations are not required at this point.

6. Elaborate the Domain Architectures

Decompose the agreed concept into Business, Data, Application, and Technology Architectures, and define the Baseline, Target, and Gaps in greater detail.

7. Develop the Roadmap and Transition Architectures

If the target cannot be implemented in a single step, define phased implementation increments, dependencies, and intermediate transition states.

Three Common Mistakes

1. Adding Too Much Solution Detail to the Context Diagram

When products, APIs, communication methods, and server configurations are added to a Context diagram, its purpose becomes unclear. Keep the focus on boundaries, external relationships, inputs and outputs, assumptions, and constraints.

2. Turning the Concept Diagram into a Product Catalog

Placing the logos of SAP S/4HANA, SAP IBP, and SAP BTP on a page does not create a Solution Concept. The diagram must show which capabilities each product supports, which problems it addresses, and how it contributes to business value.

3. Turning the Concept Diagram into a Detailed Design

A Solution Concept is a “pencil sketch.” API names, IDoc types, table names, network configurations, and detailed authorization roles should be addressed later in the Application, Integration, Technology, and Security Architectures.

How the Deliverables Connect in the Architecture Vision

Deliverable	Question It Answers
Business Strategy Map	Why are we undertaking the transformation?
Stakeholder Map	Who is involved, and what are their concerns?
Business Capability Map	Which capabilities must be strengthened or changed?
Solution Context	What is the operating environment, and what is within scope?
Architecture Requirements	What conditions must the architecture satisfy?
Solution Concept	What solution approach will address the need?
Architecture Roadmap	In what sequence will the target be realized?

Viewed as part of this sequence, the Solution Concept does not appear out of nowhere. It can be logically derived from the Strategy, stakeholder concerns, Context, and Requirements.

Conclusion

The essential difference between Solution Context and Solution Concept is whether the deliverable is intended to understand the environment or envision the solution.

• Solution Context describes boundaries, external actors, surrounding systems, information exchanges, assumptions, and constraints
• Solution Concept describes the fundamental structure and responsibilities of the future solution needed to deliver the Business Outcomes
• TOGAF® explicitly identifies the Solution Concept Diagram
• Because the term Solution Context may be organization-specific, Enterprise Architects should confirm the relevant deliverable definition
• In practice, architects should clarify the problem space through the Context before shaping the solution space through the Concept

For an Enterprise Architect, the goal is not simply to produce an attractive diagram. The real responsibility is to connect the transformation objectives, scope, stakeholder concerns, Architecture Requirements, and solution direction in one coherent story.

---

Disclaimer

Parts of this article were developed with reference to generative AI suggestions and were reviewed, refined, and supplemented based on the author’s professional expertise and judgment.

---

Back to Top