My Solution Design Process

Introduction

When we need to implement change into the Enterprise we can benefit from a structured process.  We need to define the work and what artifacts we need to ensure a successful transition.  In keeping with my primary motto, always is cheap and sometime is expensive, I have built a solution design model that I believe can benefit any team tasked with changing the enterprise.  It helps build a common language and approach on how we establish the solution design process.  Note that the components discussed here are a piece of a much larger Enterprise Architecture model I have been crafting for years.  I am working on formulating how to disseminate that to others.  I believe this solution design process is a good entry point.

There are four main components to my solution design process:

1. Principles
2. Positions
3. Approaches
4. Decisions

Principles

Your organization should have defined principles that guide the company.  These are the architectural principles that guide the solution design process.  These principles help align the organization on what are the concepts that bind and drive the teams to a unified solution set.  They allow design teams to validate their solutions to the core values of the Enterprise.  They also help alleviate any disagreement towards the approach the teams may encounter.  Work to ensure that your organization has a well-defined published set of principles that address the Enterprise Architecture needs of the organization.  These principles should closely align and map back to the Organizational principles that guide the company.

A principle consists of the primary title, for example, Secure by Design, Buy vs Build.  A statement describes in more detail the underlying principle.  A rationale helps define the business need for the principles.  The implications define how the principle will support and empower the business.

Publish the principles to a shared knowledge management system and reference them often. 

For a more in-depth look at architectural principles see the TOGAF documentation:

Link

Example Principle:

Position Paper

A position paper helps the team literally get on the same page for where they are and where they intend to go.  The position paper sets the problem or opportunity statement.  What are we try to establish a position on?  It could be around the need for an organizational change, the introduction of new technology, or the launch of a project.  The scope should be defined so we know what we are focused on and what will not be addressed.  The technology assessment gives an overview of the technology that will be used to address and establish this position.  An internal analysis of where the organization is as well as an external analysis of how the technology is being addressed in the industry.

The position needs to be tightly coupled to business needs. Define the business drivers that are impacted by this position.  Will this position reduce scrap, improve quality, save money?  Key areas are cost, value, quality, and user impact.  Industry analysis helps establish what the marketplace looks like.  Regardless of buy vs build what industry tools and technology trends exist or are emerging.  A financial impact breaks down the cost impact of establishing or not executing on the defined position.  A business value/risk analysis should detail out the potential risk and risk mitigations areas.  Things like not having the right talent or needed organizational structure that could impact the position should be defined and mitigation steps should be documented.

Finally, the position should be defined and recommendations for the next steps to move to implementation.  An executive summary should be created at the top of the document.  Another approach can be the creation of a PowerPoint deck to summarize the position.  Don’t be afraid to take the position that the technology may not be ready yet or perhaps the company is not ready yet to utilize the technology.

Approach Note

With a position established we are now ready to define the solution.  To get the team on the same page we use an approach note.  A high-level plan of how we will execute our solution design.  This is not a project plan but the outline for a project plan.  It can be a feeder into a project initiation.  Establish the problem statement, define any assumptions and set the scope.  Layout a high-level design based on the position paper and decision documents.  Create some uses cases or user stories to help define the business process flow.  Detail out the approach and define any needed design decisions that may spawn more decision documents.  Finally document the expected outcomes the approach should establish.

Depending on the complexity of the solution you may find the need to develop several approach notes.  Use a tracker list to maintain the status and ownership of each approach.  Ensure that there is no contention of blockers in the different approaches.

Decision Document

While developing position papers and approach notes you will encounter the need to make decisions The decision document defines the needed decision and what the current status is.  Detail the options and define the benefits and risks for each option, pros and cons.  The team should set a recommendation and then finally document the decision as well as defining the next steps.  

We make decisions in solution design all the time, but we run the risk of losing the context of why we make a decision as time passes.  The decision document helps to capture at the time of the decision that variable used to make the decision.  You can even mark a date for when the decision needs to review again to ensure the decision keeps current and relevant.

Template Solution Sample Walkthrough

This example is intended to give a practical implementation of the process flow. It is based on some real-world work that can help define the process.

Problem Statement

A Corporate division is generating large image files using a vision system on the production line floor.  Due to the technical architecture, the current storage model is becoming overrun.  We need an alternative on what to do with the large files.  The business process owner proposes deleting the images but others in the organization see potential in keeping the data.  We refer to our principles to see if we have anything that addresses this need.  If we do not perhaps, we propose one.  An example may be Data is an Asset.  This drives the need to retain as much data as possible.  A position paper is created to lay out the current state architecture within the given scope.  The document defines the current state technology barriers.  It defines the business drivers and what potential industry options exist.  Local storage is expensive.  Cloud storage looks promising, but network traffic may be an issue.  It gives a rough order of magnitude assessment on cost options to implement, support, or avoid.  Business value statements defined as potential risks are established.  Is there real value in the older images?  Do we have the right levels of traceability in the data?  A position is established, in this example, to save the data files into a cloud storage provider.  We need to develop a metadata management approach as well.

With the Position established and documented we need to look at options to execute.  Which cloud provider should we use?  How will we overcome the network movement issues?  How will we manage the metadata?  Decision documents are created to select AWS Glacier storage over Microsoft Azure or Google Cloud.  Network movement patterns are also documented.   They may even spawn a POC to test capabilities.  Ultimately the team may decide to use an open-source data movement tool like NiFi.  Metadata models are reviewed and the optimal one is chosen.

Finally, a series of approach notes are defined that lay out the steps needed to implement the data archive strategy.  The approach notes address timings, ownership, costs, and other needed items for a project to implement.  Mechanisms for data retrieval and data validation will be framed up in a high-level design and some design decisions may be documented needing additional decision documents.

With the organization in agreement on the approach and supported by the established position a project initiation sheet it executed to frame up a project.  The project team can utilize the developed artifacts as well as generated conceptual and logical architecture to help build out the development plan.

I hope you can look at my process defined here and see some potential take ways to your specific needs.  I consider this reference material that you can use and then mold and shape to your own needs.  My experience is that when the team embraces this model and starts to develop a solution language around it the entire Enterprise benefits.  The true value is when the whole Enterprise embraces the model. Always is cheap, sometimes is expensive.

Links to Templates

I have included some links to templates that you may get value from as well.

Principles Templates
https://alwaysischeap.com/files/Principles_Template.docx

Position Paper Template
https://alwaysischeap.com/files/Position_Paper_Template.docx

Approach Note Template
https://alwaysischeap.com/files/Approach_Note_Template.docx

Decision Document Template
https://alwaysischeap.com/files/Decision_Document_Template.docx