Solution Description
Once business goals are clear, current capabilities are known, and the desired future state of the organization is outlined, the next step is to find a solution to the identified business problem.
A solution is a set of changes an organization must undergo to satisfy a need. This includes major enhancements to existing systems, new application development, business process changes, policy updates, or organizational structure modifications. A solution description typically outlines which enterprise components or parts need to change and how—whether they will be added, removed, or modified. The goal is not to provide a detailed technical specification, but rather to outline an overall picture of the solution, which may differ slightly depending on the size of the change. For larger changes, the solution description is high-level and focuses on the scope of the solution, defining its boundaries and major component changes. On the other hand, if the solution consists of a single system or a change to a single system, the description is usually more detailed. For example, it could include what the software should do and how it fits into the current organizational architecture, using a set of features, integrations, or main data flows.
Apart from describing individual components, the solution overview must also explain why this specific option was preferred over others and how it realizes the business goals.
Selecting a Solution
In most cases, there is more than one possible solution, so all alternative approaches need to be assessed. Evaluating solution options and selecting the best one can be a lengthy process that involves considering the feasibility of each option and assessing its impact on the organization. Very often, solution costs are the main deciding factor, meaning the decision process is primarily driven by a business case. However, other criteria should also be taken into account. For example, the timeline to implement the change, alignment with business objectives, resource availability, and the overall readiness of the organization for the change.
Basic Structure
1. Vision of the Solution
A high-level statement outlining the solution, its main parts, why it was selected, and how it helps meet business goals. This section may include a high-level diagram depicting the main parts of the solution within the context of the enterprise environment.
2. Solution Components
A list of enterprise components or parts that are supposed to be added, modified, or removed as part of the solution.
Business Processes
Newly introduced business processes, changes to existing processes, and processes that will no longer be needed. Processes can be grouped by domains, products, etc. Listing process changes is necessary but may not be enough for readers to quickly understand how those changes connect. To provide context, it is helpful to create a diagram showing a high-level picture of how the affected processes relate to each other.
- High-level process diagram showing the affected processes
- Detail on which processes or parts will be introduced, modified, or replaced
- Explanation of how process changes affect other components, such as systems or roles
IT Systems and Infrastructure
This section covers changes to IT systems in terms of creating, modifying, or replacing systems or their components. It can list only the general nature of the system changes—leaving the details to individual system specifications—or it can specify particular modifications like changes to functions, screens, or interfaces (from a business perspective). Additionally, the solution can involve infrastructure changes, such as networks, security, or hardware, which should be mentioned here as well.
As with business processes, it is good practice to describe the rationale behind each change, giving readers a clear idea of why IT modifications are needed. Visualizing these changes is also beneficial, for example, by using a context diagram or by linking IT changes to corresponding business process modifications.
- Context diagram, data flows, integrations, etc.
- Details on which legacy systems will be involved and whether new systems or applications must be developed
- Summary of new, modified, or removed systems or components
- Main features and functions of the new and modified systems or applications
Policies and Rules
Necessary policy changes if current policies are insufficient to meet the business need.
Organizational Structure
Changes to the organizational structure, to formal and informal working relationships within the organization, or to reporting lines.
3. Release Planning
If the solution is not planned for deployment in a single release, this section describes which changes will roll out when. It defines the scope of the initial release and subsequent releases.
4. Migration and Deployment Considerations
Decisions related to rolling out the solution:
- Is the new solution replacing the old one, or will there be a parallel run?
- What is needed to migrate to the new solution, and how and by whom will the migration be performed?
Note that this section is not meant to include technical details, such as which data field will be migrated to which database table. The purpose is simply to outline the strategy and provide a high-level overview.

