top of page

Transformation Canvas

Anyone who has had the privilege of facilitating a solution exercise has either learned, tweaked or developed a process on how they ultimately produce a winning solution.  Methodologies are endless in how information is gathered, but in every case these methods are grouped into three functional activities:


  1. Define the As-Is state of the target area

  2. Define the To-Be state of the target area

  3. What enables the transformation process from As-Is to the To-Be state?

Working within this three-step framework and in the above order typically produces a solid technical approach.  Formalized data points from your Program Intelligence, Hot Buttons, Ghosting, Win Strategies and Themes, Value Proposition and Risk Assessment exercises will begin to populate the Transformation Canvas.  Depending on the complexities of your offer design, you may find this exercise iterative.  Iteration will happen internally within the exercise itself and externally if you get the opportunity to validate your solution with the customer.


As-Is – Documenting and diagraming the current environment will be the foundation of establishing the As-Is state.  Strengths and deficiencies within the system, application, toolsets, processes, documentation, culture; everything should be completely identified, inventoried and annotated.  You will find that those pain points and hot buttons will surface what the customer perceives as a deficiency within their world.  Pay attention to everything; everything is important.  You may also identify features and components that still bring value and will be welcome in the To-Be architecture.  Annotate it all and be exhaustive in your discovery process.


To-Be – The To-Be architecture should include all attributes of a winning solution from the exercise above. Whatever deficiencies identified in the As-Is state, it is here that we show how the efficiencies of our new architecture remove systemic weaknesses.  Include all the win strategies and themes; design strategies and discriminators.  This is our target state. 


Transformation – Not to burst the Solution Architect’s bubble, but, the To-Be is not the solution.  The value of your solution is in your Transformation Process; how you transform their business, technology and culture.  This is what the customer is paying for; the activity of transforming their legacy operation into the modernized version.  The key to a successful transformation is clearly defined Enablers that support a thorough transformation of the service area.  For the sake of this discussion, let’s use the following characterizations:


  • Enablers are those mechanisms in our process that transform an As-Is service area to its To-Be state. Enablers can be defined as any object, component, person, information, training, tool, process, policy, etc.; it is the “how I get from here to there” 

  • Constraints are limitations or restrictions in transformation and are external in nature.  A constraint could be defined with the same criteria as above as any object, component, person, information …; it hinders “how I get from here to there”.  To successfully transform, it is imperative that we discover or develop a mitigating enabler to every constraint. 


  • Enablers are not necessarily aligned with a corresponding Constraint.  They can stand on their own as a valuable asset to the transformation process. 


  • Restraints can be self-imposed limitations usually by choice to control or restrict progress and internal by nature.  The best Enabler for a Restraint is to remove the person from the activity.


Now that Transformation Canvas is populated, begin to transform from left to right, ensuring that every deficiency in the As-Is has been satisfied in the To-Be.  Also, make sure that all positive features in the As-Is survive the transformation process.  I want to “reiterate the iteration”.  New constraints may surface requiring corresponding enablers.  Better enablers may also reveal themselves during the process; document and discuss. Keep your participants in their swim lanes. Our goal is a winning offer design that we can express in our proposal.    As a facilitator, I ask the tough questions and let the geniuses hammer out the answers; my goal is to get the best technical solution possible.  One last thought before we move forward.  During this exercise, our themes and value proposition may shift a bit.  That is ok.  We are always refining our messages; the better the solution, the better the message.

Excerpt - "In Pursuit" (c) 2018, 2019

Mike Rice

bottom of page