top of page

Digital Transformation - Types, Stages and Architecture

Digital Transformation refers to the use of digital technology to materially evolve or create new business processes. It is also know as the process of analyzing customer needs and leveraging technology to improve the end-user experience. End users could be customer or employee and many enterprises need to consider the opinions of both.

Types of Digital Transformation

There are basically three types of Digital Transformation:

  1. Customer Experience: working to understand customers in more detail, using technology to fuel customer growth, and creating more customer touchpoints

  2. Operational Processes: improving internal processes by leveraging digitization and automation, enabling employees with digital tools, and collecting data to monitor performance and make more strategic business decisions

  3. Business Models: transforming the business by augmenting physical offerings with digital tools and services, introducing digital products, and using technology to provide global shared services

Stages of Digital Transformation

Below are the different stages of the Digital Transformation:

  1. Business as usual, status quo — The current state of your organization

  2. Present and active — A time of experimentation throughout the organization when you encourage creativity and improved digital literacy skills

  3. Formalized — When experimentation becomes more intentional, initiatives become clearer, and you start looking for leadership buy-in

  4. Strategic — The point when groups start collaborating and sharing their research in order to create strategic plans for the transformation

  5. Converged — The formulation of a dedicated digital transformation team that will guide the strategy, establish goals, and put systems in place to support the transformation

  6. Innovative and adaptive — When digital transformation becomes a part of the business and leadership establishes a system for monitoring technology and market trends so that the company can continue to evolve


let’s consider a generic architecture for building an IT platform for such digital transformation initiatives (Figure 1).

Figure 1: Architecture for digital transformation platform

Let’s consider main components of this platform:

Integration layer

This layer performs all integration activities among on-premise backend systems, file-based systems, data stores and SaaS systems. It can perform protocol bridging, message transformations, message enrichment, content validation, service orchestration, etc in order to implement integration flows among backend systems.

This layer is deployed within the internal network and secure connections (e.g. VPN, protected endpoints, etc) should be available for it to integrate systems that are not deployed within the data center. Usually components of the integration layer can be scaled as necessary to match the load (e.g. auto-scale by utilizing the capabilities provided by infrastructure such as Kubernetes pod auto-scaling and AWS auto scaling groups). Furthermore, it is also possible to deploy more than one integration clusters depending on the requirements for segregating business services and load.

API gateway clusters

API Gateways intercept incoming traffic to the deployment in order to enforce security and other policies as well as to capture API usage statistics. It is possible to deploy one or more API gateway clusters as necessary in order to isolate API traffic based on different client parties (e.g. general users and partners) and enforce relevant network security policies (e.g. limit partner API gateway to IP ranges of partners).

API Gateways are usually deployed within the internal network and incoming traffic is routed to API gateways via a load balancer placed within the DMZ. However, it is also possible to deploy external facing API gateways in DMZ depending on the organization’s policies. Similar to the integration layer, API gateway clusters can also be auto-scaled by utilizing auto-scaling capabilities provided by the infrastructure.

API management layer

API management plane facilitates API publishing, policy definition, application registration, API subscription and API life cycle management activities. This layer interacts with API gateway clusters in order to publish API definitions and to exchange API authorization information. As the API management layer usually provides web portals for API creators, API users and administrators, it may be necessary to facilitate access via a load balancer placed within DMZ (e.g. if external users need to subscribe for APIs).

Identity and Access Management (IAM)

IAM layer provides user management, authentication and authorization (policy evaluation) functions to the whole deployment. Below are some of the specific features an IAM layer can provide related to above areas:

  • Support for OpenID Connect and SAML2 for authentication and exchanging user information

  • Support for authorizations based on OAuth2 / XACML

  • Single Sign-On (SSO) to enable multiple services to be accessed without having to authenticate with each services (typically implemented using OpenID Connect or SAML2)

  • Multi-Factor Authentication (MFA) to enhance the authentication process (e.g. password and SMS OTP based authentication).

  • Conditional or context based authentication (e.g. users in store-admin role are allowed to authenticate only during office hours and if connecting using a certain IP address range).

  • Support for connecting with multiple user stores such as LDAP/Active Directory and RDBMS

  • Connecting / federation with external identity providers to authenticate users who are not registered in the organization’s IAM systems (e.g. sign-in using Google, Facebook, etc or external IAM systems).

  • Web portals, mobile apps or other interfaces for users to perform self sign-up, profile management, password recovery, etc.

Usually, IAM layer is also deployed within the internal network and clustered as necessary to meet scalability and high-availability requirements. As IAM layer provides portals/interfaces for users, it may be required to provide external access to it via a load balancer placed within the DMZ.

Business Process Management (BPM)

Some business operations require many interactions with users at multiple steps. Examples would be selecting suppliers, approving large orders, handling customer complaints, etc. These operations may have one or more approval steps or steps that require user input. Such business operations (or parts of those operations) may have to be implemented as workflows modeled in standard workflow languages such as BPMN or BPEL.

BPM systems support deployment, execution, administration and analysis of such human oriented workflows. Once a BPM system is deployed, it can be integrated with other business systems and user portals via the integration layer. Furthermore, similar to any other business system, BPM systems can also utilize SSO and other IAM features provided by the IAM layer (e.g. for assigning users to workflow tasks).

Observability layer

All systems in the deployment, including the API layer, integration layer, IAM layer, BPM systems as well as backend systems, should provide mechanisms to monitor their behaviors. This includes collecting and analyzing logs, collecting and summarizing operational metrics and tracing message flows across multiple systems. Observability layer performs these tasks by collecting logs, metrics and traces from all systems and providing a unified view of the deployment. Therefore, if something goes wrong in the deployment, administrators don’t have to inspect each and every system individually, as they can obtain all information by just logging into the observability layer.

Providing business services across multiple locations

Organizations may have user bases distributed across multiple geographical locations (e.g. in multiple states or countries). In such cases it may be necessary deploy business services in multiple data centers or cloud regions closer to client locations in order to satisfy performance and regularity requirements. Architecture discussed here can be extended in such scenarios to support multiple data centers/cloud regions as shown in figure 2. In this case, usually only the API gateway clusters and integration layer clusters have to be deployed in additional data centers. API management plane, IAM layer, BPM systems and the observability layer deployed in the main data center can be used by all additional data centers.

Figure 2: Extending the deployment across multiple data centers

As API gateways and integration components handle the main runtime load of the deployment, having a single deployment of other components does not affect the performance in most cases. Furthermore, having a single management and monitoring layer naturally supports such tasks to be carried out centrally.

Resources: Whatfix, medium

The Tech Platform



bottom of page