More than five years ago my former colleague Driek Desmet and myself published and article about platform architectures. In the meantime I had the pleasure to implement these principles at different companies and in a loose series I would like to share some of the learnings from these projects. Before we go there we have to define the term “platform architecture” as it is used in a variety of different meanings – from Ecosystems down to cloud implementations.
The Oxford dictionary defines a platform as “a raised level surface, for example one that equipment stands on or is operated from”. On the same page there is also a definition in the computer context but as we are talking about Enterprise Architecture we should take this more generic definition and as we will see later it is merely impossible to define a platform only in technical terms.
A platform is raised – which means that you have a starting point closer to your target. It is level, which provides a kind a standard to build on and you can utilize it in different ways. The term platform itself does not tell you if the platform is build from wood, concrete or other materials.
Building on this quite broad definition I would describe a platform as
- a standardized way
- to develop, operate and maintain something
- in a way that is better than managing each thing individually
The typical building blocks of a platform are
- Organization and Governance
- Processes and Decision Making
- Tools and Technology
Let’s apply these principles to practical problems in order to bring them to life.
Customer (or employee) journey platforms
A company can only work if customers and employees are doing stuff – what we usually call a process or a journey. A customer is looking for a product, our company is in the product-production business and our goal is to enable the journey of the customer having a product in the basket to pay it – the customer checkout.
The Organization and Governance element of this platform is really important. There has to be a “Mini CEO” in charge of the customer’s experience in this journey. This person has to have a team working together towards a joint goal. And this goal should be measurable and the people in the team should be incentivized to reach the goal (e.g. by having monetary incentives and personal ratings tied to the objective).
If you make someone accountable for an outcome it is from my point of view important to also give them the means to influence the outcome. So in terms of decision making a lot of power has to be delegated into this customer journey platform team.
When it comes to tools and technologies these can be consumed by the customer journey team but they can’t be owned by them as these are often used by several teams. There might be another journey where the customer wants to get his product repaired or return the product. All these other journeys need also access to the customer authentication, his master data and the data of the underlying product.
Business capability platforms
This is where business capability platforms come into play. We need a platform that provides these building blocks to each team so that they can work towards their goals:
Again this platform has a strong organizational component as we have to have everybody working on for example Pricing in a single team. Unless there is a conscious strategic decision to have a business capability twice (e.g., managing wholesale and retail inventory differently) each business capability should exist only once.
These teams are having one decision maker (the product owner) and they are end-to-end responsible for their capability. They build it, they run it and they ensure that it is secure and meets the required non-functional requirements. They are measured based on objective criteria, such as the NPS from the customer journey platforms, the cycle time or the consumabiltiy of their services.
When it comes to technology and tools these teams need a lot of tooling – starting from the development tech stack, to API management, the means to create a CI/CD pipeline and many other things. If they would build these on their own this would not be efficient. This brings us to the third platform layer.
IT4IT platforms
IT4IT platforms are for the business capabilities what the business capabilities are for the customer journeys. They build a standardized foundation for the business capability teams to get started quickly and work in a very efficient way towards their targets.
The IT4IT platform teams are in charge of running their respective platform, and are measured against e.g., NPS of the business capability platform teams, costs to run the platform and service levels. They are the ones to decide about technical upgrades, changes to the tech stack and efficiency measures.
While these three levels of platforms offer a great modularization they also lead to a lot of interfaces that we as architects have to manage. More on the right management approach, the benefits and the challenges will come in future articles.