A Strategy to Implement Radically Innovative Solution Architecture

Introduction

Implementing radically innovative Solution Architectures is extremely difficult. These projects often start with embracing ambitious and exciting new paradigms in order to drive innovation and return-on-investment, but sooner or later, are met with overwhelming resistance. The resistance to radical technological change usually manifests as significant schedule delays, costly budget overruns, and increasing complexity. Sometimes these Solutions Architectures wither and die, only to be written off as “pipe dreams” or other times these Radically New Solution Architectures survive through grit and perseverance but at a  significant cost, effort, and pain. In either case, these experiences often result in reluctance and risk aversion for similar future endeavors, thus unfortunately crippling future innovation.

Radical New Solution Architecture is most prominent when shifting on-premise enterprise applications to the cloud. Organizations frequently struggle to adopt radically different architectures that leverage all of the new cloud innovations, such as new application, service, data, and infrastructure paradigms. Similarly, many Independent Software Vendors (ISV’s) struggle moving their SaaS solutions to public clouds for the very same reasons. ISV’s also have the added struggles of tens of thousands or even millions of users depending on them daily, thus making their pursuits that much more arduous.

Before we can address one key strategy to implement radically new and innovative Solution Architectures, let’s start with why radical change, and often cloud adoption, is so complicated and strenuous.

Understanding Change

Implementing meaningful change of any kind is generally difficult because of resistance and barriers to change. At the most simplistic level, change is about understanding where you are, implementing change, and arriving at the destination of where you want to be. An oversimplified model for change is shown below:

There are many factors that complicate and impede change, but the most common are:

  1. Fear of change
  2. Reluctance to change due to familiarity with things being done in a certain way
  3. Emotional ties to the current way (often driven by sunken costs)
  4. Competing visions on where to go or how to get there
  5. Impact to current organizational structure and business processes
  6. Need for learning (build new capabilities and skillsets)

Any technology change needs to account for these factors, but all are amplified when adopting Radically New Solution Architectures. In addition to the common hindrances to change, Radically New Solution Architectures are also plagued by:

  1. Complexity with radically changing technology architecture
  2. Frequent unexpected landmines due to unseen technical challenges and other constraints
  3. Difficulty maintaining momentum and ensuring continual progress
  4. Difficulty maintaining commitment of stakeholders through tumultuous change

Typical Approach to Solution Architecture

Let’s start with how traditional Solution Architecture is often approached:

The labels of the phases or related activities may change, but conceptually the above is a tried and proven methodology. The common delivery model does not need to be thrown away, rather it only needs to be refined through additional activities and shifts in mindset. The focus of this article is the addition of one key activity that should occur in both the Concept and Planning phases.

A Missing Link with Radical Change

The missing link is a framework to address the specific challenges that plague adopting Radically New Solution Architectures (i.e. cloud computing). Simply put, Radically New Solution Architecture needs to reflect a plan to overcome or workaround the many unique barriers to significant technological change and ensure continued progress toward adoption of the Radically New Solution Architecture. At the most simplistic level, in addition to the common “Concept → Plan → Build → Deploy → Maintain” model frequently used today, more effort needs to be spent during the Concept and Planning on two areas:

 

Identify any factors that may impede progress by identifying constraints and obstacles for technological change. It is not enough to identify barriers to change or project risks, it is critical to separate constraints from obstacles. Obstacles can be overcome while constraints need to be worked around, accounted for in design, or eliminated through creativity and innovation.
  Breakdown technological changes into two categories to ensure continual progress. This means identifying Momentum Drivers or those components that can be more quickly adopted than the often slower Strategic Drivers (the bigger architectural changes).

Visually, the model often looks similar to the one below:

 

These four quadrants should be a focus in the typical “Concept” and “Plan” phases. There are many benefits of focusing on these four quadrants.

It ensures the constraints (whether technical, legal, financial, regulatory, organizational, political, or otherwise) are clearly identified upfront and not discovered later in the journey. Early identification of constraints with potential impact the adoption of new technology enables workarounds to be implemented and assures that the Solution Architecture and plans accurately reflect the complexities of the constraints.
  It identifies areas where creativity and innovation need to be applied to move constraints to obstacles (enabling them to be overcome) or to find ways to eliminate them all together. An effective architect/leader should artfully look for ways to remove the constraints that drive complexity and cripple adoption of Radically New Solution Architectures.
  It continually builds forward momentum, thus driving organizations toward the desired destination (“Radically New Solution Architecture”). Crucial to successful Radically New Solution Architecture is maintaining commitment of the Stakeholders, or else the “New Solution” ends up in the dustbins of failed Solution Architecture despite the brilliance, coolness, or modernness of the design.
  It promotes a multi-prong strategy where momentum drivers and strategic drivers are pursued in parallel, rather than a singular “big bang” focused strategy. It is the fundamental reason four-or-more-lane highways are often more efficient than two-lane roads when travelling to a destination. Two lane roads are often plagued by delays and traffic jams while highways allow for more continual traffic movement and planned detours if there are known obstacles and constraints to avoid.

 

In short, this change management model enables you to avoid “bridge out situations”, plan for detours, and avoid traffic jams that impede radical technical change and it promotes building a roadmap that reflects incremental change rather than the often ill-conceived “big bang” Solution Architecture. No one would argue that it is better to build wealth by buying a lottery ticket than continually making smart and incremental planned investments every month to build wealth. Despite this, “single-lane” or “big bang strategies” are surprisingly pursued,  wrongfully assuming incremental architecture change is more expensive and complicated. The exact opposite is almost always true, as innovation and boldness takes time.

Additional Considerations

Deep-Dive into Not Only Current Architecture but also Current Implementation: It is critical when identifying constraints and obstacles to perform a technical deep-dives into the current solution(s) and any related external interfaces. This means extensively analyzing current data and code for the current systems and any external interfaces. It is not enough to just look at current and proposed architectures, as ‘the devil is in the details’. Too often the focus is on the vision and what is possible with embracing new technologies, without consideration for what it takes to move applications there. More specifically, the new Solution Architecture is often designed around the promise of innovative technologies while overlooking the unique constraints and obstacles of the current applications.

Think Iteratively: Just as iterative design and development is often used for new system implementations, iterative design and development techniques should be employed to evolve and modernize Solution Architectures. Those who pursue “Big Bang” approach often run into one unexpected constraint or obstacle after another when migrating the code base, data, and infrastructure to the new solution. The bottom line is evolutionary change is often cheaper and easier than revolutionary change despite the common preconceived notion otherwise.

The bottom line is evolutionary change is often cheaper and easier than revolutionary change despite the common preconceived notion otherwise.

Let the Application Drive the Solution not the Technology: Although it is understandable to look at specific innovative technology and its advantages, application-driven architecture is often more palatable and advantageous. Technology-driven Architecture may be the ultimate vision and end-state if the objective is to leverage a specific technology, but not all applications are easily migrated to new software paradigms and technologies.

 

Do Not Be Afraid to Change Lanes: Just as constraints may be moved to obstacles or vice-versa, it is perfectly reasonable to move Momentum Drivers or Strategic Drivers into different lanes as new information is discovered, new opportunities arise, or new challenges are encountered. It is best to have flexibility and agility when implementing radical and incremental change, as lane changes enables you to speed up change that can be reasonably accelerated and slow down change that requires further analysis or planning.

Conclusion

Organizations frequently spent countless effort and time discussing and planning for new Solution Architecture. Although the planning is essential, implementers rush into building solution and implementing change only to be plagued by unexpected and increased complexity, schedule delays, budget overruns, and ultimately stalled projects. It’s great to be grandiose with Vision and Solution Architecture but building an evolutionary roadmap with incremental architectural change ensures you arrive at your desired “Radically New Solution Architecture” more efficiently. This is the important shift in mindset when pursuing significant technological change and new paradigms.

Radically New Solution Architecture is possible and, more specifically, adoption of Cloud Computing does not need to be feared and resisted, but the tools in the tool chest need to be refined. One such refinement is the integration of the Change Management Model discussed in this article.  It is crucial to employ a framework to systematically identify all constraints and obstacles that will complicate substantial technological change. Further, when pursuing the radical change, it is critical to maintain momentum by identifying incremental steps to ensure continual progress, maintain momentum and commitment, and advance toward the vision. Never be less bold with vision, but always be more methodical with managing radical technological change.

 

Never be less bold with vision, but always be more methodical with managing radical technological change.