My Solution Design Process

Introduction

We can benefit from a structured process when implementing change in the Enterprise.  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 sometimes is expensive, I have built a solution design model that can benefit any team tasked with changing the enterprise.  It helps build a common language and approach to establishing the solution design process.  Note that the components discussed here comprise 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 with the concepts that bind and drive the teams to a unified solution.  They allow design teams to validate their solutions to the core values of the Enterprise.  They also help alleviate any disagreement regarding 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 agree on where they are and where they intend to go.  The position paper sets the problem or opportunity statement.  What are we trying to establish a position on?  It could be around the need for an organizational change, introducing new technology, or launching 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 and 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, and save money?  Key areas are cost, value, quality, and user impact.  Industry analysis helps establish what the marketplace looks like and what industry tools and technology trends exist or are emerging.  A financial impact breaks down the cost of establishing or not executing the defined position.  A business value/risk analysis should detail the potential risk and mitigation areas.  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 delivery model can be the creation of a PowerPoint deck to summarize the position.  Don’t be afraid to assume that the technology may not be ready yet or the company is not ready yet to utilize the technology.

Approach Note

With a position established, we are now ready to define the solution.  We use an approach note to get the team on the same page.  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 use cases or user stories to help define the business process flow.  Detail 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 solution’s complexity, you may 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 or blockers in the different approaches.

Decision Document

You will need to make decisions while developing position papers and approach notes. The decision document defines the needed decision and the current status.  Detail the options, define the benefits and risks for each option, and the pros and cons.  The team should set a recommendation, document the decision, and define the next steps.  

We always make decisions in solution design, but we risk losing the context of why we decide as time passes.  The decision document helps to capture the time of the decision and the variables used to make the decision.  You can even mark a date when the decision must be reviewed again to ensure the decision remains 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 uses a vision system to generate large image files 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 outline the current state architecture within the given scope.  The document defines the current state of 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 of 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 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 outlines the steps 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 with the approach and supported by the established position, a project initiation sheet is executed to frame a project; the project team can utilize the developed artifacts and generate conceptual and logical architecture to help build the development plan.

I hope you can look at my process and see potential ways to meet your needs.  I consider this reference material that you can use and mold and shape to your 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 it is expensive.

Links to Templates

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

Principles Template
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