Introduction to Some Ingredients for Architectural Transformation Projects
To Consider Before You Start “Questioning Your Life”
Many enterprises are transforming their architecture to the next generation or at least considering transforming. One can list a few motives for such a transformation: to have an agile technology machine, respond to business needs promptly, address customer demands at light speed, and so on. While the goal is nice and indeed reachable, I am observing that many organizations are still struggling.
The very first mistake done is assuming the transformation program as a sole technology activity that is composed of microservices, cloud adoption, and new cool UI designs. Soon enterprises realize that the whole picture is not so simple. There are many business stakeholders, multiple domains, different teams, and product priorities that you cannot solve without strong business involvement and sponsorship. Secondly, IT team gradually starts focusing on enabling the technology for the platform but neglects the business goal. The business objective of the transformation program needs to be reminded to them frequently. Thirdly, companies do not form the right structures and environment for the teams, which degrades the performance and hinders the transformation activities. This list can be extended further, but in this article, I would like to focus on team topologies and try to introduce some ideas which might help you plan and scale your transformation program. This way, I hope that you will not fall into some of the common traps.
For a transformation program to be successful, I believe there should be three different types of teams. The first one is the Platform (Architecture) Team. You can consider them as the workers preparing the railways for the train to pass. As a result, they are the first team to onboard. The second team(s) is the value team, or the Business Transformation Team. These are the ones building the functionalities on top of an existing platform. In other words, they build the wagons, wheels, or locomotive that goes over the railways built by the platform team. Finally, you have the sub-system team, which owns some complicated legacy capabilities (e.g., payment gateway, billing algorithm, etc.). As their know-how is scarce and cannot be reproduced easily, you keep this team isolated and focused. Naturally, during the execution of the program, you will also need some governance capabilities like transformation office, steering committees, and so on.
In the picture below, you can observe all these entities. This article will go over the main entities shortly and in the upcoming articles, we will talk about each team’s structures, processes, communications, and pain points. Transformation Governance Team, Platform Team, Business Transformation Team, Sub-System Team, Progress Tracking Board and Architecture Board which was shown in the picture below are explained next.
Transformation Governance Team: This is a diverse team of Technical Program Managers (TPM), Solution Architects, and Analysts. These people track the progress of the transformation program. Their main responsibility is to make sure transformation delivers the intended business outcome (i.e., the value) that has been defined beforehand. They interact with the platform team and business team to follow the status of KPIs, create content for Progress Tracking Board and report ongoing status for Executive Committee, Steering Committee, and Executive Sponsors. They also interact with these entities to understand the expectations and drive the rest of the teams towards them. Two entities are defined for them to interact with technical perspective of the transformation and keep track of the status of domains:
Progress Tracking Board: This is the medium we gather weekly/bi-weekly to discuss the overall status of the transformation, act on any deviations, and discuss on major bugs or issues. This is a board governed by Transformation Governance Team. Participants also include Business Domains, Platform Front office.
Architectural Board: Here we discuss more technical topics, such as solution models, design patterns, or application architectures of business products or the platform itself. Participants include solution architects, domain architects, and Front Office.
Platform (or a.k.a, Architecture) Team: Platform team includes the front office (we will talk about it), platform program management, platform architects, and platform developers for all layers of the architecture (Front End to Backend End, Data, DevOps, Infrastructure, Security, etc.). Their main objective is to expose all these platform capabilities “as a Service”. In other words, they let the developers focus solely on development and delivering features. Front Office is one of the entities inside the Platform Team formed by a technical program manager, technical analysts, and developers. The main duty of the team is constant communication with the transformation governance team, business units, and platform teams. They are the first point of contact to the Platform Team. They follow all the platform-related bugs and requirements coming from business transformation teams, plan it with platform teams and make sure business transformation and platform teams are aligned on the target.
Business Transformation (or a.k.a, Value) Team: This is where the action and result take place for the business and customers. We have a legacy that is required to be transformed and last long. We have our Platform Team creating the necessary technical features and environment for enabling transformation. Business Transformation Team offloads this legacy, coexists it with the new, and re-architects & re-platforms all the enterprise. They are responsible for the products, application performances, and creating value for the end-users. They report status on the transformational progress to the Transformation Governance Team and let them track the program objectives with the relevant KPIs and metrics. They also provide feedback and insights to the Platform Team in order to let them develop and enhance the architecture.
Sub-System Team: An important team that will be living with our new platform till an unforeseeable future. There will be capabilities provided to business teams to create applications that can interact with both new platform and sub-system team. So sub-system team needs to be a part of our transformation and constantly be aligned with governance communication. They are one of the secret heroes assisting the change from shadows, meanwhile they are keeping their systems alive which supports the
Today we have made a very brief introduction to some entities for architectural transformation in an enterprise. Setting the correct organization and communicational structure is extremely crucial for a peaceful state of your mind during our transformation.
Involving the right people in the right teams, creating a clear transformation operating model, defining the roles & responsibilities of teams in advance, establishing well thought processes and procedures will determine your destiny. Some recommendations and tweaks that I can make in that regard are:
- Create a governance structure to your transformation including a transformation governance office, platform team, business transformation (value) team. Do not underestimate the importance of sub-system teams.
- Form a front office in your platform team to create a single point of contact towards the governance team and business domains. Having a program manager, technical analysts, and developers (frontend, backend, full stack) inside this team will boost the outcome.
- Have several boards for progress tracking and architectural topics. Constant tracking and communication will minimize the misunderstandings, and let you have a brighter picture of the whole. This will also help everyone on getting aligned on the priorities of the transformation and its domains.
- Constant reporting of the status and priorities to the executive committee and steering committee. This not only helps the leadership see the progress but also let the most powerful persons of the enterprise take immediate actions and put back the program on track if there are any deviations.
- Create a training program and always update/evolve it from the platform and business perspective. There is a need to train employees with the right technologies and the processes created. They need to be educated not just technical-wise but also around the business change and procedures inside this transformation.
- Create developer guides, design patterns, code templates, reference applications, hands on videos for developers onboarded to the transformation.
A transformation program can be a huge nightmare or a constant joy; it all depends on how much you are prepared to it. It can also be educative; helping to grow our talent with newer technologies and processes. The difference comes from how we set our structure and communication before the transformation, and how we execute it during the transformation. An IT oriented mindset solely focusing on delivering technology results or a business mindset approaching to see immediate results can be equally destructive. We need a balance during the journey. To find the balance, I have introduced some of the key entities. In the upcoming articles, we will dive deeper into each one of them and start explaining the processes, procedures and daily work routine of the team. Meanwhile, we will be talking about application migration and DevOps transformation in more detail. Especially on principles, strategy, transformation roadmap, and some conclusions. Hopefully, the following article series will give you more insight into it.
Alperen Yavuz, Principal @TeamDefineX
alperen.yavuz@teamdefinex.com
