dev@cloudburo

On Martin Fowlers blog Evan Bottcher published an excellent article about digital platforms, called “ What I Talk About When I Talk About Platforms”.

In his article, he provide insights out of different “going to the cloud” projects of big companies and their failure and success criterias.

As for example “The half arsed superficial private cloud”, which is a re-labelling existing virtualisation platforms for use by delivery teams in a very constrained way, with no real intent to reduce the amount of centralised control.

It’s a consequence of

“The BigCo infrastructure and operations group was not ready at that time to break down it’s own organisational silos, and shift significant responsibility (and therefore access) to delivery teams. And even if the intent was good, the sheer amount of effort required to incrementally build that API to the required richness was not viable.”

A pattern which I’m confronted in my daily work as well, big enterprises are not ready to really shift control out of their infrastructure and operations towers.

He introduces the concept of backlog coupling

"Digital teams are generally constrained in three main areas: slow-moving core transactional systems of record, access to high-quality data and analytics, and shared infrastructure and operations. It’s a simple concept - if a large number of items in the backlog of a digital product team require a corresponding backlog item to be raised in another team, then productivity and responsiveness suffer enormously. Backlogs get chained across the organisation, each being prioritised according to a different system. ”

Therefore

"The platform should provide a team with self-service access. Specifically it should allow for self-service provisioning, self-service configuration, and self-service management and operation of the platform capabilities and assets. ”

So where to start:

• Firstly you will probably already be on your journey to move away from ‘project’ as the primary mechanism for funding and staffing delivery of technology. Platform is a product, and needs a long-lived and stable product team tasked with both build and run.
• Secondly you must be willing to shift some or all of the run responsibility for applications into the application teams and away from centralised operations and support.
• Thirdly you must be willing to trade off strict consistency of implementation against the freedom and responsibilities that you’re handing to the autonomous application teams.