Articles

Empowering Business with a Platform Architecture Approach

Posted by Graeme Perrins on 26 October 2018

Deloitte Platform Engineering has built experience and knowledge of delivering complex solutions that span organisational domains. These large scale, cross domain solutions bring added complexities to delivery. Our experience shows that by taking a different view to the problem you can deliver more than just a technology outcome.

Applying a platform architecture approach not only changes the way that these large solutions are architected but also changes the way the organisation views and manages the technology. A platform architecture approach can provide benefits across the solution architecture and also enable improved business agility and IT economics.

Before we delve into how a platform approach enables this, we must first answer two key questions: What do we mean by a platform and What is a platform architecture?

The word platform has several meanings, from traditional:

“a flat, raised area or structure”, but in the context of a business, platform means: “A set of services and functions that deliver to the part of a business value chain”

A platform architecture aligns the business and technology architectures to business domain platforms. Under this model, platform architecture means:

“Structuring the business into domain owned technology platforms that deliver business value across and beyond the domain via domain owned and managed platform services.”

Here is an example of how a platform architecture can be structured:

Platform Architecture Example

There are several important benefits that are enabled by taking a platform architecture approach.

The business domains can take ownership of the IT applications and systems they use allowing the domain to directly manage their technology investment roadmap without traditional constraints that come from a central IT function.

The platform approach help enables domains to clearly define key “platform services” that can then be exposed via service integration patterns for use by other parts of the business and potentially to external 3rd parties as well. This can also enable commercialisation of key services by enabled 3rd parties to leverage them for added value. e.g. Amazon, Paypal, etc.

For example in the diagram above, the Warehouse & Delivery platform services might be used by 3rd parties to form a marketplace where logistic and courier companies could bid for deliveries via the platform services. Even the T services the company uses can be structured into a supporting IT platform.

Separating the business into platforms also provides both structural and change independence. The implementation of the platform functions can independently evolve from the other business platforms. This requires that the platform services are provided through a service layer decoupling the service interface from the implementation.

Whilst there are a number of benefits of this platform model, it does not come for free and there are a number of considerations to make.

Each business platform will require the skills and expertise to manage, operate and develop their owned technology applications. This requires changes to the business & IT budget process. The business domain budget now needs to include the platform IT costs. This too is an enabler as the IT budget is becomes a responsibility of each business domain rather than a central IT budget that is owned and allocated separately from the business.

Another key change that comes with the domain ownership of their platform is the new responsibilities of operating and supporting the platform as it is now acting as a service provider to other parts of the business and potentially other 3rd parties as well.

Considering these aspects requires a view and understanding of the overall economics of changing to a platform architecture. On the surface this looks like establishing bespoke IT functions within each business domain with duplicating costs and expenses. But if you consider this from the view of moving from a central resourced model to a platform resoucre model then this can provide a better resource balance. Typically a central model requires the need to carry excess resources to cover peak or concurrent demands.

A platform architecture delivers benefits through domain autonomy and independence to evolve, adapt and provide new services to the market. Implementing a platform architecture and delivering platform services requires skills across architecture, technology integration and engineering disciplines. Without such experience and insight, the different platforms can devolve into dysfunctional technology domains hampering the outcome rather than empowering it.

You might also enjoy: