Platform for Enterprise Transformation | 1- Why we Built the Platform
Organizations have been building their own platforms and these platforms have driven their digital transformation. We have also gone down this route and built our own platform that is being used by our Bank and Subsidiaries. At the time of writing this article we were working on the 4th release of the platform, 8th wave of the transformation with 40+ platform services and growing, handling 180 million API calls per day and also growing.
During this journey in Garanti BBVA, I have had the chance to work with some extraordinary people and a visionary vendor that had a huge impact on the outcome. I would like to share my experiences in the following four articles:
1. Why we built the platform — the organization’s challenges and the benefits of the platform
2. How we built the platform — the platform’s roadmap, governance model, operating model, the success factors and challenges
3. How we enabled transformation — the approaches used for platform enablement, governance between Transformation Office, Solution Architecture, Enterprise Architecture and the Platform
4. The Platform — the platform’s architecture principles, layers, services provided and key decisions and technologies
Platform Overview
In Garanti BBVA, we named our platform “ARK” and defined it as;
“The platform is multi-tenant, cloud ready, using open source technologies, technical, service based platform on container architecture for Business Domain Development Teams to design, develop, build, deploy and monitor their application by providing services in Channel (front-end), iPaaS ( integration), aPaaS ( back-end/application), DaaS ( data), Security, DevOps, Logging and Monitoring, IaaS ( infrastructure) layers.”
Organization Challenges
There are a number of challenges in an organization. The platform’s objective is to provide solutions to these challenges.
“Organization Challenges come from Business, Talent, Architecture, Operation, Technology & Trends and Regulations”
The following are the list of our challenges that has led us to build the platform;
1. Business Challenge
- New business products needs to be delivered quicker
2. Talent Challenges
- Attract and retain talent in the organization
- Enable new talent to become productive in shorter amount of time
- Improve talent productivity (architects, developers, SREs)
3. Technology and Trend Challenges
- Accelerate innovation in the organization
- Modernize the core and manage obsolete technologies on legacy systems
4. Architecture Challenges
- Be ready for the Public Cloud (our regulations do not allow us to be on the cloud)
- Evolve architecture continuously
5. Operation Challenges
- Reduce legacy systems complexity
- Reduce cost using distributed open environment
- Improve business operations through modern technology
6. Regulation Challenge
- Compliance to changes in regulations with minimum effort and time
Benefits provided by the Platform
The platform addresses these challenges by providing the following benefits;
1. Platform Services
The platform provides 40+ services and is growing. These services provide business domain development teams, to develop a wide range of business products faster by enabling them to concentrate on their business needs.
“Platform Service is a platform product provided in any one of the Channel (front-end), iPaaS ( integration), aPaaS ( back-end/application), DaaS ( data), Security, DevOps, Logging and Monitoring, IaaS ( infrastructure) layers.”
2. Multi Tenant
This is one of the main differentiating points of the platform. The Bank and the Subsidiaries use the same platform. The platform is built once and used by all. The platform can be used as shared or dedicated depending on the regulations.
This reduces the system complexity and improves operations.
3. Productivity
The aim of productivity is to enable the business domain development teams developing on the platform to concentrate on developing their business products. In order to provide productivity to developers, architects and SREs, it provides a set of tools, self-services, automations, runtime services, libraries, catalogs, design patterns and more.
a) Developer Productivity
- Developer Studio tool to generate code, raise tickets, commit code, build, test, deploy and checks health of the applications. The studio takes all its input from the application architecture. This enables a smooth flow in the application development starting from architecture design.
- Self-Services enable developers to perform all the operation through a console.
- Reusable components enables developers to reuse Web Components, API, Service and Event definitions from the platform’s catalogs.
- Platform Portal a single point of contact for all documentation, including developer guides, standards, policies, service definitions, release notes and much more.
b) Architect Productivity
- Reference Architectures and Design Patterns demonstrating the usage of the platform services, solving common domain problems.
- Service Definitions are well documented platform services containing benefits, use cases, standards, release plans & notes, SLAs, certifications, etc.
- Platform Icons to standardize architecture diagrams, providing easy to understand architectures that are then used as input into the Developer Studio.
c) SRE Productivity
- Logging & Monitoring tools provided for each platform service to identify and resolve issues on their applications or on the platform.
- Self-Services enable users to perform actions on the system (ex: manage capacity).
4. Cloud Ready Architecture
The platform is built on Cloud Ready Architecture Principle. The current Banking Regulation prohibits usage of the Public Cloud. These regulations can change in the future, therefore the platform must be ready.
The platform is built on container based architecture and available in our Data Center (Private Cloud). and it can be deployed onto Public Cloud with no change to the platform and the applications developed on it. Once a cluster for the platform is created on the platform, the only change to an application is to change the deployment configuration to point to the Public Cloud.
5. Open Source
The platform is built on Open Source Architecture Principle, to maximize open source usage with decoupling to avoid vendor lock-in.
This enables the platform to use modern open source technologies and modern agile delivery methods.
6. Full Automation
The platform is built on Automation Architecture Principle. It provides automations at;
- Application development lifecycle (CI/CD and Test Automations)
- Software installation, configuration, upgrade automations
- Application development platform self-services
7. Continuously Evolving Modern Platform
The platform strategy is to continuously evolve by;
- Working closely with the domain teams, solution architects to gather requirements to deliver new platform services and features
- Researches new technologies to extend the platform services and features, further reduce platform costs, make the platform services lighter and faster
8. Abstract Changes
There is constant change, coming from new and obsolete technologies and from regulations. These changes can require a significant amount of effort in an organization of our size to re-develop. The platform provides an abstraction to these changes and minimizes the effort required on the business domain development teams.
9. Deep Security
The platform is built on Deep Security Architecture Principle. Security is one of the most complex areas of any system and if it is designed and developed incorrectly can have massive consequences.
The platform embeds security into the platform, therefore the developer does not need to develop security, bypass or switch off security which also improves their productivity.
10. Built in Standards and Policies
The platform services provide all the standards and policies. These standards and policies are enforced on the platform by the platform self-services and automations. Therefore the developer is prevented from incorrectly delivering projects.
- For standards, validations are added to self-services and automations, example: API standards are validated at design time by platform self-services.
- For policies, the platform enforces at deployment time.
In both standard validations and policy enforcement we are working to adopt the shift-left approach to ensure they are done as early as possible in the software development lifecycle.
How to avoid the downsides of a platform
The platform also comes with its downsides. These can cause resistance in the acceptance of the platform. Therefore we have addressed these concerns.
1. Developers think they are not using new technologies
The developers say that the platform is limiting the usage and learning of new technologies.
Action: We have opened all the platform source code (except for the security layer) and documentation to the organization. They are able to contribute to the platform. And we publish all the contributors to encourage further contributions.
2. Adding new technology to the platform is slow
New technologies require effort to research, try and adapt to the organization and may require expertise in the area. The platform has a large core team, but usually has a large backlog and commitments to be met, therefore may not be able to handle the new technology in the required time.
Action: The organization can create a new team to build the platform service. The new team is governed by the platform to ensure the platform service meets the platform definition standards defined by the platform.
Conclusion
We found that the platform for our multi-business (i.e. bank and subsidiaries), large organization has been successful for handling the organization’s challenges.
In an environment where technologies become obsolete, vulnerabilities found in frameworks you have to react quickly. Without a platform it can become a logistical nightmare to locate these technologies in all the applications, find solution, develop, test and deploy them. When business is trying to bring out new business products, time is of essence and spending huge efforts in this area does not bring value to the organization.
The no vendor lock-in usage of technologies and centralized DevOps capability of the platform provides the abstraction you need to handle these changes effectively.
We are continuing to evolve the platform and it is one of the main locations of driving innovation in the organization. The platform can achieve this with high quality as it has all the necessary teams in the platform to work independently, with strong governance, defined product definition standards and delivery model.
I will be providing my experience on how we achieved to deliver the platform (“2- How we built the platform”) and how we enabled the transformation (See “3- How we enabled transformation”) in the next articles.
Articles
- Platform Overview
- Organization Challenges
- Benefits provided by the Platform
- How to avoid the downsides of a platform
- Building Blocks
- Success Factors
3. How we enabled Transformation
- Transformation Strategy
- Plan
- Execution
- Measure Progress
4. The Platform
- Architecture Principles
- Services
- Architecture Overview
- Technologies
- Productivity Products
