Core Architecture Of Digital Transformation

How to address the rapid technological changes and growing demands of consumers for digital products and services

Many prominent business organisations face enormous challenges to respond to the rapid technological changes and growing demands of consumers for digital products and services globally. There is a constant search to find optimal solutions to growing business problems.

From my experience, the most optimal solution to address these problems is to architect digital transformation requirements, goals, and objectives at an enterprise level.

This article shares my experience for an innovative model, framework, and approach formulated and described with technology and business architecture fundamentals.

Photo by ThisisEngineering RAEng on Unsplash

Vision

The new initiative starts with a vision. As a top-down approach, architectural thinking mandates setting the vision first. Vision is thinking about the future with creative imagination and human wisdom based on desired goals.

Vision sets the scene and shows us where we want to be in the future.

Even though everyone has a vision, a productive and strategic vision is a leadership capability and requires a substantial amount of intelligence, knowledge, skills, and experience.

Strategy

Once we have a compelling vision for the digital world, it is an opportune time to set the strategy clearly.

We know where we are now on the digital journey and strive for where we want to go. Our destination needs to be marked. Our digital strategy helps us reach our destination using a master plan.

The master plan can be a high-level roadmap to take us to the destination we set. We need to proceed with a clear strategic roadmap; otherwise, we can get lost in the details and the constant noise.

Current Situation

Understanding and accepting our current situation is crucial. It doesn’t matter how good or bad, but we need to accept the reality at this initial stage.

The current state is our baseline and starting point. Knowing where we are can help us set our vision. The current state for a legacy enterprise can be complex and difficult to compile.

Everything is related to everything else, and we may even get surprised that some old systems or solutions are not documented adequately or even not at all. Therefore, we may need to conduct a gap analysis and take appropriate actions to address the gaps.

Despite all, we need to start from somewhere to identify our current environment and collect as much information as possible by taking all measures. This can be one of the most painful exercises in the transformation lifecycle; hence we shouldn’t be discouraged. It is a necessary step and pays dividends in the long run.

Requirements

Digital transformation initiatives can pose many requirements from many angles. Requirements of digital transformation can be interrelated and have multiple facets. Most of the time, requirements can be seen as simple from the outside; however, they are not easy to manage inside.

Therefore, we need to make a concerted effort to understand the requirements from all angles in a structured way. Requirements involve multiple processes and stakeholders. These stakeholders can be from different parts of the organisation with varying goals, roles and responsibilities. We need to identify them.

Both users and systems have their unique and standard requirements. There are different requirements for different kinds of users — for example, internal and external users, technical, executive, and management users can pose different requirements. Systems also can have their unique requirements.

Use Cases

Understanding the use cases for digital transformation solutions are an essential architectural duty. Dealing with use cases requires different thinking modes, such as looking at things from the user’s perspective. Observing and being an observer at the same time is a critical mental capability.

More specifically, a use case is a specific situation depicting the use of a product or service of a solution by the consumers. We develop use cases from the users’ perspective. We need to understand how the consumers are intended to be using a particular component or aspect of the solution.

Usually, the functional requirements can help us to formulate the use cases. Alternatively, in some circumstances, use cases help formulate the functional requirements. Use cases and requirements are interrelated. We need to analyse them together, not in isolation.

Transition From Current to Future State

After understanding the requirements and clarifying the solution's use cases, we need to apply them to the current state. The current state shows us where we are now. By understanding the current state and its requirements to transform, we set a future state and develop a roadmap to reach the target transformation goals.

The future state requires a substantial amount of analysis and predictions. In this phase, we can consult multiple subject matter experts to ensure the future state reflects our vision, mission, and solution strategy; and ensure that it meets identified requirements.

This architectural approach for understanding the current environment and setting the future state applies to any digital solution that we engage on a daily basis. This structured approach is instrumental for the success of our digital transformation initiatives.

Once we set the future state, the next critical step is to assess the feasibility of the construct, deployment, and consumption goals.

Solution Feasibility

An architectural method can guide us to think about the feasibility of our transformation solution roadmap by looking at the risks, dependencies, and constraints on the way.

A solution's feasibility is practised using a viability assessment work-product, which is a template covering all aspects of our solution from an operability perspective. We can either use a viability work-product template from an established method such as TOGAF or our organisation’s proprietary method.

Beware that the viability assessment can be categorised under different names. To ensure, we may check which work product is used in our proprietary method to capture risks, issues, assumptions and dependencies.

Developing a comprehensive viability assessment can help us mitigate critical risks, resolve existing issues, capture assumptions, address challenging dependencies and possible interdependencies. Missing this crucial step in our digital solution approach can result in dire consequences in the long run. Therefore, this is a mandatory step in the solution lifecycle.

Most of the time, assessing viability also requires making a considerable number of trade-offs to reach optimal solution outcomes. Let’s understand what an architectural trade-off for a solution is.

Architectural Trade-offs

When architecting digital transformation solutions, we make substantial amounts of trade-offs. When making trade-offs, we need to consider critical factors, such as cost, quality, functionality, usability, and several other non-functional items such as capacity, scalability, performance, usability, and security.

We make trade-offs to create a balance between two required yet incompatible items. In other words, a trade-off is a compromise between two options. For example, it is possible to make a trade-off between quality and cost for particular items.

Sometimes, dealing with trade-offs can pose a dilemma. We may tear ourselves between two competing and compelling options. In these circumstances, we must revisit our priorities. Re-examining our priorities, especially set by the key stakeholders for the solution objectives, can provide us useful clues and necessary guidance. In addition, we can also revisit our approved vision, mission, and solution strategy as sometimes our memories may fail to remember exact details in the rapid-paced transforming environments.

There may also be times that we make some of the architectural trade-offs to deal with uncertainties and ambiguities. To deal with these types of trade-offs, we can use techniques such as comparing and contrasting situations and taking calculated risks. It is not possible to develop an architectural solution without taking risks. It is also possible that these risks can be turned into opportunities; hence we need to mitigate them methodically and measurably. Now let’s discuss the next critical point covering architectural decisions.

Architectural Decisions

Each trade-off requires it’s supported by some architectural decisions. These crucial decisions can have substantial implications for the success or failure of our digital solutions.

We need to make architectural decisions very carefully and measurably. Each decision can have a severe impact and multiple implications on the solution outcomes. It may be costly to change the architectural decisions at later phases of the solution lifecycle.

Some implications can be cost-related or compliance constraints, while others can relate to non-functional aspects such as performance, scalability, capacity, availability, security or usability.

In addition, our architectural decisions must be validated with subject matter experts and communicated with multiple stakeholders for their acceptance and approval to reach the optimal consensus on the validity of the decision.

Architectural Context

After making the architectural decisions and obtaining the necessary approvals, the next challenging task is to provide a representative picture of the solution on a single page. This illustrated representation is usually called the solution context showing the critical dependencies. The Solution context is a work-product template that can be found in many established methods as a sample.

Creating a solution context requires abstracting skills. We need to represent a large volume of information in small pictures by setting concise relationships amongst the components. We can apply the proverbial principle of one thousand words in a single image.

This abstract thinking skill is an example of architectural intelligence that adds to the digital transformation solution process. Setting the context for any solution can help us communicate it to relevant stakeholders in an understandable manner. Context adds clarity to understanding the overall solution.

Architectural Models

We need to develop multiple models for digital transformation solutions. Models are essential work-products in architectural solutions. A model is the proposed structure typically on a smaller scale than its original.

Once we draft a specific solution at an abstract level and our stakeholders understand it, the next important step in the architectural thinking process is to represent the abstract level in further details by describing each component and the relationships.

Describing abstract representations in concrete details also requires a great deal of mental exercise, including dealing with multiple patterns, stimulating our thinking abilities.

Some of the vital Architectural models which we can apply to the potential modernisation solutions are Component Model, Operational Model, Performance Model, Security Model, Availability Model, Services Model and Cost Model.

High-Level Designs

Once the architectural models are developed, we need to create fundamental high-level designs. Digital transformation initiatives require the development of multiple work-products covering high-level designs based on the solution context.

The use of fundamental high-level designs to see the big picture for each solution building block can be instrumental in digital transformation solutions. The high-level design needs to be well understood, accepted and approved by all stakeholders.

Let’s be mindful that it can be challenging and costly to change these designs at the later stages of the solution life cycle. To this end, we ensure that the high-level designs are produced using our strategy and roadmap and fully aligned to reach the optimal solution's goals.

Detailed Designs and Specifications

Like any other enterprise IT system, modernisation and transformation solutions are expected to correctly deliver all their detailed designs and specifications. Applying a comprehensive configuration management practice for solutions components can be practical and helpful when dealing with specifications.

In digital transformation solutions, a specification can be defined as the act of precisely identifying the enterprise ecosystem items. Since specifications require precision, delivering the right specification is an essential requirement for enterprise applications and their associated critical business and emergency responses.

System specifications need to be accurate, reliable and fast when collecting data, communicating information, sharing data and making accurate decisions. Unreliable communication of the specifications by various silos, wrong decisions made by those specifications, their cumbersome layout can lead to disastrous results when attempting to detail the digital transformation solutions.

Finding inaccurate detailed designs or wrong specifications during the implementation and production support phase can be very cost-prohibitive due to massive re-work requirements. These unexpected errors shatter the whole solution from every angle, and as digital transformation architects, we are the first ones who are responsible for the consequences.

Dynamic and Flexible Governance

Technical governance is a core requirement of digital transformation initiatives. These transformation programs require a particular governance model due to their nature. A dynamic and flexible governance model is essential for transformation initiatives.

The traditional stringent and extreme rule-based or oppressive governance models can be roadblocks to progress. From my experience, agile principles best suit the dynamic governance models.

Governance committees in digital transformation programs can be complicated and sophisticated at multiple levels. There are many roles and responsibilities for governance committees. For example, transformation architects can run the architecture review boards or design authority forums established for complex digital transformation programs.

We can use several governance frameworks based on our solution domains. One of the common frameworks for technical governance in the industry is COBIT (Control Objectives for Information and related Technology). The use of frameworks like COBIT can help organisations gain optimal value from their IT investments by maintaining a balance between gaining benefits and optimising risk levels and resource use. There can be other governance models based on the industry to which the enterprise belongs and adheres.

Conclusion

A systematic approach, as described in this article, to digital transformation initiatives is mandatory. Architectural and design thinking skills can guide the governance of initiatives. While following a top-down strategic approach, many initiatives also require a bottom-up tactical approach.

Thank you for reading my perspectives.

Follow me to see more articles like this.

...

Follow

Reference: Architecting Digital Transformation