Introduction
You are developing a product trying to help your core business grow through technology. The easiest way to start is to design what you need and start coding it as a monolithic blob. The product becomes successful and you start seeing the impact that it has made on your business. The next thought is to make the product commercially available so that other businesses can use it and you can generate money on the product as well. You create one pipeline for one customer, another for the second and so on.
It all seems to be working till the time the bugs fixed for one pipeline are forgotten to be carried over to the others. The features developed for one are not easily transferable to others. The release cycles keep getting longer and longer. The engineering team on-boarding slows down to a pace that a snail seems to be whizzing by. Suddenly you remember that successful organizations talk about building products and platforms.
What is a platform?
A digital platform is a foundation of self-service APIs, tools, services, knowledge and support which are arranged as a compelling internal product. Autonomous delivery teams can make use of the platform to deliver product features at a higher pace, with reduced co-ordination.
Each platform consists of a logical cluster of activities and associated technology that delivers on a specific business goal and can therefore be run as a business, or “as a service. These platforms are each managed individually, can be swapped in and out, and, when “assembled,” form the backbone of a company’s technology capability.
- Platforms focus on business solutions to serve both clients internal and external clients.
- They supply to other platforms.
- They operate as independent entities that bring together business, technology, governance, processes, and people management and are empowered to move quickly.
- They are run by a platform owner, who takes end-to-end responsibility for providing the solution and operating it like a service.
- Platform teams are cross-functional, with business, IT, and anything else that is needed, such as analytics, risk management, and so on. (Some companies call this a “tribe.”)
A platform-based company will have 20 to 40 platforms, each big enough to provide an important and discrete service but small enough to be manageable.
How do we do platforms?
The platforms can be divided into 3 main areas as described in the diagram below
- Infrastructure and Core IT – This is the base of the platform which feeds up to other platforms above it. This layer consists of
- Technology decisions – The base technologies to be used within the organization. You might want to standardize on the languages, tools, licenses etc
- Deployment considerations – All DevOps related consideration on the container strategy, cloud infrastructure, integration with third party products, CI/CD pipelines, continuous delivery etc
- Architectural and design standards are discussed and implemented in conjunction with the architecture office which would be followed by all the layers above
- Alerting and monitoring strategy along with the SRE road-map is defined at this level
- Business Platforms – This the layer where business value related platforms are made available
- Examples would be platforms like Recommendation engine which take a select set of inputs and provide recommendations
- Scoring engine which takes a set of inputs and the functions which need to be used to calculate a score like churn score, readership score etc
- Domain specific service like payment service, insurance decision service etc would be at this level
- SLAs and domain expectations from a service are expected at this level
- Customer Journey – These are all the platforms / applications with which the end user is interacting
- Searching the catalog
- Reading an article and making comments
- Buying from the online store
- Adding a recommendation/feedback on Yelp are examples of what is expected at the customer layer
- Architecture Office – Tying all of these together is the architecture office which defines the
- Enterprise road-map and constraints
- Licensing and sunset decisions
- Governance and security rules
- Making sure that there is no duplication across platforms and there are no issues in all platforms connecting together with a common mandate etc
- Budget and resource allocation for different platform teams
As PagerDuty put it, when they started experimenting with the platform model in which there were tribes responsible for different products,
As the number of product delivery teams grew, an interesting phenomenon developed—we saw an emergence of the so-called “tribes” (hat tip to Spotify’s team model); i.e., groups of teams related to each other by common functionality or common mission. These arrangements have resulted in benefits such as shared ownership, shared knowledge, shared roadmap (separate from individual team backlogs), and shared vision.
Adobe shared a similar notion that by investing in Platform teams, they were able to get more out of their engineering teams. Both in terms of speed and effectiveness
By creating a platform team with 259 people, we can have an organization of 1,000 work with the effectiveness of 1,465 people.
Conclusion
The advantages of breaking down your engineering team into platforms has significant advantages. Of course there are pitfalls on the way and one needs to be wary of them but the benefits outweigh the challenges.
Other significant advantages included
- Ability to reorient quickly
- Ensure architectural integrity across the organization
- Reduced end to end cycle time
- Knowledge retention
- Ability to iterate
- Shared ownership of code and systems
- High team motivation and dynamics
Knoldus is a team of engineers who build high performance AI systems using functional programming. We have 5 offices across 4 geographies and would be happy to assist you in making your business more competitive with technology. Give us a shout and we would be happy to chat. Have a splendid New Year 2020.
