Are platforms the key to enterprise agility?

It's no secret that many enterprises have adopted Agile methods as part of their digital transformation efforts. Scrum, SAFe and similar frameworks provide ways to organize for agility by implementing a feedback-driven iterative approach to software development. This is a good start. However, if an organization doesn’t have a clear roadmap, they may still struggle to achieve greater levels of agility. Creating this kind of roadmap involves organizational, process, and technological changes to be planned and managed in an agile fashion.

In my seven plus years at Capital One, I have played many roles in our Agile, DevOps, and technology transformations including as a coach both on agile processes and technical practices & tools. At the beginning of the transformation, when I first saw large application teams being broken down to smaller teams and assigned to different business units, I wondered how the new structure would work. Would this model be a recipe for chaos compared to the structure that traditional project management provided?  From my experience as a Software Engineer, these new processes felt like a natural way of developing software; but would existing technology systems make it difficult to scale across the enterprise and provide incremental value in short sprints? I looked to see if there were any organizations that had successfully transitioned to operating in this manner. I came across a few models I liked (including  Spotify model, Holacracy etc), I observed how Capital One approached  building its software ecosystem, and combining all the above I made a mental map of where Agile could take us as an organization. And the rest is history.

For Agile to realize its full potential in enterprises, the systems have to be organized and managed to allow federated teams to work together without stepping on each other's toes. As our Agile transformation evolved, I was able to develop some insights on how technology can be organized in a modern enterprise. I would like to share some of my thoughts about the same here.

First, let us see how a modern enterprise engages with its customers and how this drives product life cycles.

The below diagram shows one version of the modern business customer life cycle. It starts with raising awareness of the product with prospective customers, getting them to explore their product, getting them to love it and make it part of their daily life, and eventually to become strong advocates of the product. In the modern life cycle most of these steps happen primarily through digital channels - i.e. by engaging customers through their computer or mobile devices.

In this life cycle diagram, a business may want to continuously engage with their customers to better understand factors such as customer behaviour, customer needs, their feedback on product, and insights from different suppliers. Some of the questions that they may need answered could be:

1. Are we offering the right products?
2. Which supplier's product is liked by the customer?
3. I have a new product idea, is that what the customer really wants?

The old way to answer these questions is to do detailed market research on the customer’s needs, and then build a new product hoping that the customer will embrace it. However, in a digital world, product insights can be gathered from customer behavior by building prototypes and introducing them to the customer digitally. Customer behaviors can then be captured simply through interests, sign-ups, likes/dislikes, reviews, etc. Based on this feedback, these prototypes can be improved iteratively until a product roadmap evolves.

Often, this was primarily done by customer facing teams within an enterprise such as marketing, operations etc. They would do research and once they had a clear idea about the customer’s needs, a full implementation of the solution would begin; but it still would take some time to build. In the modern life cycle our goal is to shorten this to the greatest extent possible so that the customer doesn't have to wait too long for the products and features that they want.

David L Rogers  defines platforms in ‘The Digital Transformation Playbook’ as “a business that creates direct interactions between two or more distinct types of Customers.” A classic example of a platform is UBER. It brings different kinds of customers - drivers and riders - together to provide a ride sharing service. Another classic platform example would be Airbnb. It brings different kinds of customers - rental space owners and prospective renters - together to provide a short term rental service.

Both of these examples have external customers. A platform within an enterprise may have lots of potential customer configurations - including external customers, internal customers, and a mixture of both. Let’s look at two examples of enterprise platforms.

Enterprise platform example #1

Let’s focus on a generic enterprise platform example of a manufacturing company. In this example a supplier management platform would allow internal departments to advertise their needs, and for prospective suppliers to maybe bid for supply, provide a delivery schedule, tracking, reviews, etc.

In the above case, each of the platform’s internal customers use common features, as well as having their own specific features provided by the platform. The common features might be basic supply management, whereas each customer may have specific requirements around how the items have to be packaged and stored.

In the traditional approach, if the grocery department needs to build a new feature, they would need to engage the supplier management team, have them prioritize and coordinate delivery, as well as any of their other dependencies in order to get the feature delivered. However, to improve time to market it would be beneficial if the grocery department could build the required feature themselves.

Enterprise platform example #2

Let’s take another example of a food delivery service. Let us say there are two divisions, a driver management division and a restaurant management division. Assume that the driver management division wants to send an end of day summary of deliveries to the drivers. At the same time, the restaurant management division wants to send a summary of food delivered from each restaurant. In the traditional model, both the requests need to go to the same team for prioritization and implementation. In the new model, both the divisions should be able to work simultaneously and respond to their corresponding market needs.

Below I will explain how platforms would enable such a way of execution.

A large organization could comprise multiple platforms as shown in the highly simplified example below of a retail enterprise.

How is this different from how enterprises are traditionally organized? It looks very similar, however, the key difference is how the platform is built and how that transforms the way an enterprise operates.

Traditional enterprises typically have layers and layers of components with teams responsible for each layer. Generally, the business is operating at the top layer, with limited-to-no ability to make system changes; they can mostly do configuration changes only.

A platform model also has layers - maybe more than what traditional organizations have - however, the ownership to make changes is federated to allow for the business to respond to market needs in a timely manner.

A platform will be worked on by two types of teams - business focused teams and technology focused teams.

Business focused teams

Work through rapid experimentation and prototyping to look for opportunities to better engage with customers so as to gain insights on their needs, behaviours, etc. This data is then used to better serve them, which in turn should help increase engagement and eventually revenue. These are generally cross functional teams that may include software engineers, data and business analysts, as well as people focused on marketing, operations, and social media experts. The business focused team would leverage the platform to evolve the business.

Technology focused teams 

Would work on enabling the platform to evolve based on business and technology needs. They ensure that the platform is stable and has the right checks and balances so that many teams can work together while minimizing disruptions. The technology focused teams will also work on concrete implementation of the experimental capabilities built by the business focused teams. There may be different types of such teams with very different roles to play.

This is very similar to the concept of bi-modality by Gartner. However, I want to say here that both the teams continuously innovate; one in the business domain and the other in the technology domain.

What are the building blocks of a platform? Let us take a look. A platform at its core will have the following three components:

1. Capabilities – Capabilities use multiple applications and frameworks to accomplish a business function. For example, an order placement capability may leverage an order management system, payment processing system, alerting system, and API framework to build that capability end to end. The concept of microservices aligns with capabilities.
2. Applications – Applications are built for meeting certain specific needs. An example would be a letter generating system, customer information system, etc.
3. Frameworks – These are internal frameworks that can be leveraged by teams in building applications. An example would be an API framework, DevOps framework, testing frameworks, etc.

Let us now look at the different possible types of technology teams:

• Capabilities teams: Such teams will primarily own a capability end to end and work on enhancing it further. They mainly work on key organizational initiatives or develop concrete implementations of concepts tested out by customer facing teams. Will often include full stack software engineers, and a business representative (referred to as product owner in Scrum).
• Application core teams: These teams will own individual applications, primarily focusing on application infrastructure, architecture, guidelines, and testing strategy. They will make key decisions on the application roadmap. This team primarily includes software engineers and a product owner (either from business or technology).
• Platform core teams: These teams are very similar to the application core team. However, they own the platform. They also primarily focus on infrastructure, architecture, guidelines, and test strategy. They will make key decisions on the platform roadmap.
• Framework and tools teams: Mainly exist in the enterprise level, creating frameworks and tools needed by the rest of the teams. Can include, software engineers, system integrators, and the technical product owner.

As I mentioned above, the goal of a platform is to allow the business to be agile by allowing each of the teams to independently  perform their work, with the dependency on other teams being minimal. This creates an organization where multiple teams can work on common components. Working agreements, as well as checks and balances, need to be developed at different levels to reduce impacts and collision between teams. Here are some key ingredients and best practices for a successful platformL

• Having a delivery pipeline with automated tests at each level (unit, integration, functional).
• Effective monitoring and visualization of your software and infrastructure performance.
• Scalable code management strategy.
• Expressive design - Code needs to be built with a mindset of making it easy to understand and change.
• “Shifting left” of security and performance.
• Quality needs to be built in rather than managed as a separate activity at the end (eXtreme Programming practices provide a great way for teams to have built in quality).

When you have multiple teams working on the same set of components, the code should be built with all the quality aspects when it is deployed. The application of good software engineering practices needs to become a habit so that teams can continue to apply them even when facing tight deadlines.

The digital transformation of enterprises starts with adopting Agile methods for software delivery and continues along the path of reorganizing technology systems to allow for greater and greater agility. With the platform approach, technology moves closer to the business and allows for distributed governance of technology, thereby enabling businesses to take products to market really fast and evolve the underlying systems to cater to ever-changing customer needs. 

Through this journey, organizations will need coaching focused on technical practices at a team level while also working on evolving organization level practices to enable teams to work well together.