The Architecture of Transformation
Note: this article was originally published in 2019.
In the previous article in this series - "The Top 5 Characteristics of Successful Transformations," I introduced some high level concepts associated with how IT Transformations are accomplished in real-world scenarios. In that article, I stated that using architecture in generally the best way to get a Transformation project / program off of the ground. Here's the rationale for that statement:
(IT) Architecture provides an opportunity to visualize all of the key concepts associated with any given Transformation; those concepts will include...
A description of the problem or problems that have generated the need to change.
An assessment of current state capability in the context of those challenges.
And an expectation of what future state capability will likely resolve the problem/s.
All of this information can be formal or informal in nature (e.g. the visualizations don't have to follow a specific notation or framework per se), but they all must help to communicate the issues more effectively than could otherwise be done in lengthy reports. The images are "info-graphics" that help to focus attention on the problem and illustrate the path forward. Sometimes this is built into EA Frameworks like DoDAF, where an OV-1 or Operational View 1 illustrates the problem domain at a high level from a conceptual perspective. In commercial environments, sometimes (Business) Context Models are used. Usually though it's a combination of views that are necessary and they can also include considerations relating to the nature of the program itself (example below).
Essentially, different types of IT Architecture will be used at different stages of a Transformation. IT Architecture can be defined as...
A problem-solving approach using one or more methodologies to model and resolve complex business issues in a technology and information-focused context. The resulting visualizations can follow either formal or informal design paradigms or both.
In the diagram below, I've highlighted that there are essentially three types of IT Architecture typically used, these are:
(Strategic) Enterprise Architecture - These are architecture views / info-graphics used to communicate key issues to help determine strategy, planning and obtain stakeholder buy-in. Often times, they are used to help characterize the current environment and the specific challenges so that people will understand the need for undergoing a Transformation.
EA Framework Architecture - In organizations that use TOGAF, DoDAF or other frameworks, this would capture the high-level or (primarily) logical solution design associated with the Transformation. This type of architecture is typically limited to the planning and design phases (although it should be linked to later Physical designs).
Solution Architecture - In many organizations, 2) is skipped and only 1) and 3) are used. Solution Architecture (which is primarily focused on physical designs) can utilize specific notations such as UML but can also use specific views from EA frameworks in some cases. In many cases, simple design "patterns" might be used - for example an interactive AWS or Azure service or container configuration diagram created on a tool like CloudCraft.io (or could be produced using DRAW.io or Microsoft Visio). We might also consider some of the templates associated with the solution to be patterns (for example UI/UX wire frame standards or CloudFormation scripts on AWS)
The most important consideration though in exploiting the use of IT Architecture to facilitate a transformation initiative is continuity. In other words, the same tool/s must be used throughout and maintained in some type of version-controlled environment and most importantly, the top-level conceptual designs must be mapped to lower-level detailed designs and adjusted accordingly. As simple as it may sound, merely aligning the initial high-level design expectations with the project design and development in motion can provide an invaluable oversight mechanism that if used properly can spot risks and issues before they become unmanageable. It's also an excellent way for the DEVOPS teams to help communicate both progress and potential issues.
It's worth noting here that while many architecture purists would state that a specific architecture framework and / or approach had to be used in every transformation, that's simply not the case unless you are in government organization which dictates the approach. For example, the US Department of Defense requires use of the DoDAF framework in combination with the BCAC lifecycle for most transformations (which are defined by the dollar amount associated with the acquisition). In most cases, the manner in which an organization can apply architecture to facilitating their transformations is completely flexible. The types of considerations that would drive how the architecture might be applied include the following:
The size and complexity of the project
The nature of the technology associated with the Transformation
The (anticipated) timeline associated with the Transformation
The anticipated lifecycle management approach (e.g. Agile or Waterfall)
The nature of the organization (especially in situations where the organizations are large and somewhat diverse in nature)
Once the Architecture approach has been determined, it can be applied to the initial Phase of the Transformation - Problem Assessment and Transformation Strategy. I'll cover that in the next article in this series...
Copyright 2019, Stephen Lahanas