January 22, 2020

How to Deliver a Solution Blueprint for Digital Transformation

Why Do I Need a Solution Blueprint?

Digital transformation is no longer a way to get ahead of your competitors. It’s become a requirement to stay in the game. But for many organizations, digital transformation remains an intimidating challenge. The amount of detail required to overhaul your information technology (IT) can overwhelm even seasoned teams. A comprehensive Solution Blueprint allows for everything to be captured in a concise and structured manner. This ensures that important details of your transformation are not left out and sets you up to adapt as you go. The competitive landscape inevitably changes during an extended transformation initiative. The Solution Blueprint keeps track of why and how you did something. When things change you can easily identify which parts of your solution are affected and where they need to be tweaked.

How Do I Create a Solution Blueprint?

Solution Blueprints will look very different depending on the size and complexity of the initiative. A Solution Blueprint is simply a collection of artifacts that, together, exhaustively define a future state. Which individual artifacts are included will depend on the organization’s standards. The number and type of artifacts will also increase in relation to size and complexity. However, there are common elements required for every Solution Blueprint. The following general steps and activities will guide you in creating a Solution Blueprint, no matter the situation.

The first challenge, and the trickiest, is to clearly define the desired outcome of the solution. “Implement Cloud” will not help you to know whether your initiative has been beneficial to your organization after the fact. Clearly articulating the ideal outcome informs both your scope and success metrics. It will also guide you in dividing the initiative into independent projects with incremental ROI. A better outcome statement would be: “Redesign non-legacy products for faster speed-to-market, leveraging modular architecture, automation, and continuous integration and continuous deployment (CI/CD”. Look to the business, client, stakeholder, or systems needs to accurately define the outcome.
A prudent next step is to investigate the current state of your organization. You’ll want to assess what can be kept and reused, what needs an overhaul, and what has to be completely replaced. If you have an Enterprise Architecture (EA) function, your EA Repository will already contain an overview of what you do and don’t have. Regardless of what you have on hand, it’s good practice to validate and revise before a major initiative. An enterprise is a vibrant organism that is constantly evolving, sometimes without an architect’s knowledge!
Using what you’ve found, the next step is to draft the potential future state based on the desired outcome. This will be an iterative process as you validate and rethink aspects based on a more detailed understanding of the current state.
The Solution Blueprint should follow a standard outline. This outline describes the difference between the current and future state for each domain area:
- Business – Capability, Function, and Service
- Data – Conceptual, Logical, and Physical architectures
- Application – Application Component Model
- Technology – Infrastructure and Deployment Models

Note: Security Architecture requirements are not solution-specific. These should be included as Non-Functional Requirements within applicable design artifacts. However, depending on the scope of your initiative, existing standards may not apply. In this case, there must be a parallel activity to update security standards.

At a minimum, the following architecture artifacts must be created to cover all domains. These items, as well as the areas of knowledge above, are stored within your organization’s EA Repository and intranet.

Process Flow
Use Cases
Business Footprint
Components Model
Context Model
System Sequence Diagram

Ok, Now What Do I Do With This?

You should be reviewing portions with the relevant business and IT stakeholders as you go. You should have full stakeholder support before seeking final executive approval. You will present the Solution Blueprint to the Architecture Review Board (ARB) for approval. If you don’t have a standing ARB or another approval mechanism, you can arrange an ad hoc ARB. The ARB consists of executive decision-makers representing each domain. For example the head of the line of business, head of development, chief data officer, head of IT infrastructure, and chief information security officer. The individuals should be empowered to make a decision on behalf of corporate leadership.

Be prepared to present specific recommendations, concerns, optimal ideas, and best options. (This context should be included in its own section in the final Solution Blueprint package submitted to the ARB.) These will likely be revised and will definitely be solidified following the ARB.

After the solution is approved, representatives of each domain should be designated. These individuals or groups should raise changes to the environment that affect the approved solution. At a minimum, they should inform the architecture team and initiative steering committee. If the situation warrants major changes to the Solution Blueprint, you should consider holding a follow-on ARB.

Want to learn more about our ideas and thought leadership, please read the following. If there are any areas of interest from your organization, please feel free to reach out to us.