Platform for Enterprise Transformation | 3- How we Enabled Transformation

Published in

Garanti BBVA Teknoloji

14 min readApr 29, 2022

In this article I would like to talk about how we enabled the transformation onto the Platform here in Garanti BBVA. In the previous two articles you may find 1- Why we Built the Platform and 2- How we Built the Platform.

Platform for Enterprise Transformation | 3- How we Enabled Transformation (Shutterstock)

At the time of writing this article, we are 2.5 years since our we onboarded our first project on the Platform, 1.5 years into the Full Transformation(See “Platform Phase 2 Waves” in Waves below) and the platform is handling 180 million API calls per day and growing.

This is a multi-year transformation journey. In this journey the Platform would form the base of the transformation. Before we started we identified further changes and defined them as paradigm shifts. We started preparing for these early in the journey during the Phase 1 of the platform (2- How we Built the Platform).

Paradigm Shift

Owning and delivering products for the long-term instead of developing projects
Designing and governing product architectures to have solid architectures
Building knowledge and not just concentrating on delivering projects/products
Cross-functional product owning Agile Teams developing all the components in their architecture

I will start from the top level our Transformation Roadmap, going down to the Building Blocks and the Key Elements. Each of the items are a topic for an article on their own. Therefore in this article I will give an overview of each of these items, describe what our aim was and what we could have done better.

Our Transformation Journey has the following 4 steps and 7 Building Blocks.

Transformation Roadmap and Building Blocks

1. Transformation Strategy

This is the initial step where we determined the strategy objectives and selected the transformation strategies that are suitable for our transformation.

Transformation Strategy — Leaders and Key Elements

1.1. Strategy Objectives

Set Strategy Objectives

The “Strategy Objectives” are a list of statements of the transformation objective. They define what the organization wants to achieve with the transformation onto the platform. The following are some of the points that are answered in the strategy objectives;

set short and long term objectives of what the transformation is expected to achieve
evaluate and prioritize applications by the following criteria;
- Business Value; applications with new business requirements or high business impact
- Modernization; applications with obsolete technologies or modernization requirements
- Application Lifecycle; new applications
- Interdependencies; core or common business component applications
determine resources that will be trained on the platform

Transformation Strategies

These are the 6 R’s of application migration strategies.

We have selected the following 2 R’s;

Re-imagine — All applications selected to be developed on the platform will use this option. The important point being that the re-imagining is for the business as well as the architecture. i.e. re-architecting the platform is not sufficient, change in how the business operates is also required.
Re-host — All 3rd party products new or existing that meet a predetermined set of platform criteria will be moved on to the platform.

2. Plan

This is the step where we determine the roadmap of the transformation.

2.1. Roadmap

Assessment

The projects that will be developed on the platform are prioritized. The aim is to create a list of projects for the next 12–18 months. We started the assessment early therefore spread the activity over 18 weeks, where 10–12 weeks is the recommended duration for the assessment. The plan is then revisited before the start of each quarter.

Preparation — The data sources (i.e. application portfolio, project demands), data gathering templates, wave priorities are identified and prepared
Data Gathering — the domains gather and provide details of their applications and projects
Validation — the projects are validated and those that are identified as “re-imagine” and “re-host” are accepted
Roadmap — the projects are added to waves

Waves

Waves are a collection of projects.

In the Phase 1 of the platform (2- How we Built the Platform) the waves contained a controlled set of projects. Projects were assessed before being selected to determine if the platform is ready to handle the project requirements.
In the Phase 2 of the platform (2- How we Built the Platform), full transformation started and the projects were prioritized into waves. These waves are started every quarter and aligned with the platform releases. This enables the platform to gather and deliver requirements in alignment with the domain projects.

The aim of the waves is to have a managed start to the projects as they need to be aligned to the platform releases, training plans and project dependencies.

Platform Phase 1 Waves — Ramping up Projects

Platform Phase 2 Waves — Full Domain Projects Initiated Every Quarter

3. Execution

This is step, where the projects identified in the waves are developed by the Domain Teams.

3.1. Governance

The “Governance” aims to;

enable an effective and productive communication between all the participant teams.
manage issues, risks and requirements between projects and between projects and the platform
deliver projects with solid architectures
ensure the transformation progressing as expected

Transformation Governance

There are 5 main teams that take part in the transformation;

Transformation Office — the overall transformation governance is the responsibility of the Transformation Office. They lead the Steering and Executive Committees and Progress Tracking Session with participation from Domains, Solution Architecture, Enterprise Architecture and Platform teams
Solution Architecture — all the solutions are governed by the Solution Architecture and they lead the Architecture Board with participation from Transformation Office, Domains, Enterprise Architecture and Platform teams
Enterprise Architecture — all architecture processes and architecture models are owned by the Enterprise Architecture
Platform — the Build and operation of the Platform is the responsibility of the Platform teams
Domains — the development and delivery of the the business products on the platform is the responsibility of the Domain teams. There are 150+ domain teams working on transformation.

Issues, Risk and Requirements Management

The Transformation Office manages all the issues, risks and requirements between Domain Teams and between Domain Teams and Platform Teams.

The aim is to ensure that platform gathers their requirements and the issues are resolved in a timely manner and the risks are managed.

Application Architecture Model

The “Application Architecture Model” owned by the Enterprise Architecture, is the map of the applications our organizations (i.e Garanti BBVA Bank and Subsidiaries) provides. It is a multi-layer map and is key to;

the Platform — it forms the base of the Platform standards
the Domain Teams — are agile teams formed based on the products defined in the model and they will own for the long-term
the Solution Architecture — base their governance and their artifacts on the model

Architecture Technical Debt Management

The Domain Teams start a project with the creation of their product’s architecture. They make architectural decisions. At the time of making these decisions they may have to make some workaround decisions. There may be several reasons for this, for example; the platform service or feature may not be ready, capacity requirement of a platform service may not be sufficient. These decisions are captured as “Architecture Technical Debts”.

The “Architecture Technical Debts” are owned by the Enterprise Architecture and ensure these debts are resolved at a specified date.

Architectural technical debt is a metaphor used to describe sub-optimal architectural design and implementation choices that bring short-term benefits to the cost of the long-term gradual deterioration of the quality of software. (https://ieeexplore.ieee.org/document/8432173)

The aim is to ensure the business product architectures always conform with the platform principles and reference architectures.

Solution Governance

The “Solution Governance” defines the process and artifacts that are created by the domain teams.

The aim with the “Solution Governance” is to ensure the domain teams create their solutions to;

meet the strategy objectives
conform to the platform architecture principles and reference architectures
ensure design patterns are used to simplify the architecture

Solution Preparation & Development

The domain teams prepare the solutions by using the process and artifacts defined by the “Solution Governance”. The key artifact they create is the “Application Architecture” which is the architecture of their product. (product and application are used as the same in our architecture context)

The aim is for the Domain Teams to own their solutions and the Solution Architects support these teams during the preparation.

The concern we face is that preparation of the architecture documentation is slowing teams down. However since the products are defined as the “Application Architecture Model” the initial document creation is a large effort, but this effort diminishes in subsequent projects on the products. It also enables the architectures to be reviewed and available for future projects.

“If someone claims that writing their thoughts down is too much effort, I routinely challenge them that this is likely because they haven’t really understood things in the first place.” — The Software Architect Elevator by Gregor Hohpe

3.2. Build Knowledge

Reference Architectures & Design Patterns

We are a large organization and therefore the transformation scope is large. We have to create solutions with high quality and with speed. Therefore we decided to create a set of Reference Architectures and Design Patterns.

The task of creating Reference Architectures and Design Patterns becomes the responsibility of the Solution Architects. However this task usually falls down the priority list.

We created a set of workgroups with the support of the sponsors to build these artifacts. These workgroups are formed from architects from Solution Architecture, Domain Teams and Platform Teams. They concentrate on use cases brought by the Domains and as an outcome create/update the Reference Architectures and Design Patterns. The outcome can also be a set of requirements to the Platform in the form of a new Platform Service or Feature.

We created the following workgroups;

Service Design Pattern & Reference Architecture Workgroup
Data and Data Consistency Design Pattern & Reference Architecture Workgroup
Resilience Design Pattern & Reference Architecture Workgroup

3.3. Learning

Onboarding

The “Onboarding” is a comprehensive set of trainings aimed at Developers, Analysts and Managers. These trainings are provided at three levels;

Level 1 — Online Trainings on the basic technologies and skills of the Platform
Level 2 — Virtual Class Trainings (or videos) on technologies in the platform
Level 3 — Hands-on Workshops where you can build examples of running reference applications.

Change Enablers

The “Change Enablers” are roles in the Platform teams. They have the following responsibilities;

prepare Developer Guides for the Platform Services
prepare content for the Onboarding training including creating Reference Applications as examples
give hands-on workshops on reference application

The aim of the “Change Enablers” is to;

help Domain Teams startup their initial platform projects
get feedback from the Domain Teams to identify areas of enhancements on the platform

The aim of the “Change Enablers” is to prepare the platform for the transformation.

Platform Portal

The “Platform Portal” is the single point of contact for all the information about the platform. It contains information on;

news
services
catalogs
release and delivery notes
standards and policies
developer guides
architectures

The aim is to have a single point of contact for all platform information.

Q&A Portal

The “Q&A Portal” is Question and Answer platform for collaboration & knowledge sharing. All teams are encouraged to ask and reply to questions to improve the knowledge database.

The aim is to improve knowledge on the Platform.

Agile Teams

The “Agile Teams” are the Domain Teams developing on the Platform. There are two points we have considered;

The first point is that they are formed around products. They own products and not projects. The products they own are defined in the “Application Architecture Model”. The aim for teams to own products and be long-termed.
The second point is that the teams must accumulate knowledge of the platform. This requires the teams to work on issues together, support each other and only when they can not move on to contact the “Change Enablers”. We found out that vendors do a better job than us and the reason was that the vendors formed their teams with a hierarchy (ex: Team Lead, Senior and Junior members). The Team Leads took the responsibility to support the team. This is an improvement area we are working on.

Networking

We are working remotely. Even though we are switching to a hybrid model, it is not making working collaboratively any easier. People that were naturally working together in the office are not communicating that well in remote and hybrid models.

We are looking into using our Confluence tool to encourage networking, where people share their skills and experiences, search for people with certain skills, network with them and start working together.

The aim is for individuals to promote themselves to provide even greater value to the organization by collaborating with their domain and cross-domain teams.

Communities of Practice (“CoP”)

The “CoP’s” were formed by the Domain Teams with participation from Platform Teams to share knowledge of the Platform. They were formed based on specific topics, for example; development of a platform services, automation testing development, UI development etc.

The participation of these CoPs have decreased over time and eventually closed. We are working on a more structured approach as we still think they will provide a valuable way in sharing knowledge in the organization.

3.4. Productivity

Developer Studio

The Developer Studio is a tool initially developed by a Domain Team and a new version being developed by the Platform to help the developers develop applications starting from an architecture as defined in the “Application Architect” artifact. It provides the following features;

generate source and test code with templates
integrates with source code repositories, catalogs, CI/CD tools, logging and monitoring systems, data modeling tools and ticketing system eliminating manual steps
checks health of the application (security, standard and policy violations, ticket status, health in environments)

The aim is to improve developer productivity by moving all manual and non value adding code generation to the tool and enabling the developer to concentrate on design and business logic development.

Platform Console

The self-services provided by each of the Platform Services are accessed by the developers over a single point of contact Platform Console.

The aim is to enable developers, SREs to run design, develop, build, deploy and operation time self-services from a single point.

Catalogs

One of the main ways to improve productivity and simplify the architecture is to reuse well thought out components. The platform provides a number of catalogs for the architects, analysts and developers to view and use these components. These catalogs are;

Web components
API definitions
Service definitions
Event definitions
Business Process definitions

Standard and Policy Enforcement Validation

The platform is designed with standards and policies. These are embedded into the platform and therefore validated and enforced by full automation.

This aims to ensure that the developers do not deliver code that is not meeting the standards or is validating the policies.

Architecture Diagram Standards

We have created a set of platform services, resources, group and connector icons.

The aim is;

to have the Domain Team Architects to draw commonly understood diagrams
and these diagrams are then provided as input to the Developer Studio, therefore improving developer productivity and ensuring the designed architecture is also the delivered architecture.

4. Measure Progress

Measure Progress — Leaders and Key Elements

4.1. Metrics & KPIs

There are two levels of measuring progress;

Transformation progress
Platform progress

Transformation Metrics & KPIs

This is where we measure the progress of the transformation based on the strategy objectives;

Application Transformation
People Transformation

Application Transformation Metrics & KPIs:

These metrics give an overview of the percentage of the applications running on the Platform, a sample of them are;

“Number of Platform API Calls” compared to “Number of Existing Environment Transactions”
“Number of Platform DB Tables” compared to “Number of Existing Environment DB Tables”

People Transformation Metrics & KPIs:

These metrics give a percentage of the people trained and working on projects on the Platform, a sample of them are;

“Number of Developers Trained and Working on Projects on the Platform” compared to “Total Number of Developers”
“Number of Analysts Trained and Working on Projects on the Platform” compared to “Total Number of Analysts”

Platform Metrics & KPIs

This is where we measure the progress of the platform, and these are explained in 2- How we Built the Platform.

Conclusion

In numbers, this is how we enabled the transformation;

4 Steps in Transformation Roadmap
7 Building Blocks
25 Key Elements

These have helped us during the transformation. However preparing and executing all the key elements is a major effort. We have achieved a majority of them, but there are still some we are working on to get it right.

The transformation is still continuing, but we have run a number of waves to gather several insights. The following are the key ones:

Key Insights

Change of Mindset — The platform and the transformation has changed the way teams worked. Instead of developing business products in their teams using defined procedures, they have had to be part of a larger organization, a new platform and new governance processes. The change of mindset required continuous mentoring and leadership support.
Prepare Key Elements — The preparation Key Elements needs to be completed before you start your Execution. In execution, the only time you have is to inform, mentor, align the teams with these Key Elements and ensure the transformation is moving forwards.
Change Enablers — The “Change Enablers” that were preparing necessary documentation and training and starting up domain teams on the Platform have been one of the most busy teams during the transformation. Their initial responsibilities were extended to become the single point of contact for the domain teams. This enabled quick response to the domain team issues and support requests, performed root-cause analysis to determine points to improve on the platform and reduced distraction on the platform teams.
Time to Learn — A new platform and a new governance processes with emphasis on strong architecture requires a lot of learning. The teams need to be given time to learn. The teams that were given the time to learn and experiment have done better than other teams.
Ramp-up — We had 3 waves of projects with gradual ramp-up on the Platform before we started full transformation. This enabled the platform and the Key Elements to be prepared and matured during these during these waves.
Build Knowledge — Garanti BBVA Bank and its Subsidiaries is a large business. Creating and validating individual solutions is not a viable solution. Therefore we ensured architects from all the teams came together to build knowledge in the form of Reference Architectures and Design Patterns.

Transformation is like a large container ship, you initially set your course, be prepared for the change in the weather, change your course temporarily to avoid bad weather, always check and correct your course throughout the journey to reach your destination and deliver the goods.