Discover our blogs

Companies like Spotify are often referred to as examples of modern IT organizations.  Unfortunately modernizing a large, complex enterprise is not as simple as just copying models like these.  The basic idea however is the same: how does an IT organization provide more value to the business by bringing technology closer to the customer? Cloud technology in this case offers a lot of potential advantages.  It’s, however, not the golden bullet by itself.  Cloud technology adoption in a traditional IT operating model is not an ideal scenario.  Quite the opposite, cloud adoption will most likely fail if the operating model is not changed. In this last part of our blog series on the subject we will dive deeper into the operation model to make this digital journey successful. 

What is a product team?

Let’s start with the end in mind.  The goal is to deliver business value.  Business is generated by customers. So let’s get the IT teams close to the customer.  No matter what it’s called, no matter how it’s exactly defined, adopting some form or shape of (agile) product teams is a good starting point to do so.  Product teams are small, collaborative and cross-functional teams that work to achieve the common outcome of creating an exceptional digital product.  The debate of what a product team exactly looks like in a specific organization is beyond the scope of this article.  What we see at our enterprise customers is they have very different definitions of product teams.  And even within one organization, different product teams might have different ambitions.  Or call it maturity aspirations.  Often not just driven by ambition as such, but by simple financial realities.  As such we see a spectrum of product teams, going from rather traditional application engineering teams, all the way to full blown autonomous decentralized DevOps teams.  With everything in between.

How autonomous is autonomous?

Even in the most ‘mature’ scenarios, there’s a need for guardrails.  The obvious example we use is security.  You don’t want every product team to have their own twist on security.  There has to be a centrally constructed security reference architecture, managed by a central platform team.  This is just one example.  When we talk about guardrails, a key exercise each customer has to go through is to define what these common platform services will be. On a conceptual level, this means you will end up with a centrally managed team.  Often called a platform team.  We prefer to call it ‘the enabling team’.

What functions are in the enabling team?

The details of what services an enabling team delivers is something that needs to be discussed between the product teams and the enabling teams.  In general we see the following functions are required or we see them on a regular base with enterprise customers:

• Platform enabling services: from a landing zone definition to more complex reference architectures.
• Automation enabling services: making sure product teams can deploy services fast (and by themselves) is one of the key features of a modern IT organization.
• Application Engineers enabling services: application development is done in the product teams, but you want to make sure you get some form of standardization in the way coding is done. E.g. If teams want to make use of application monitoring services, they need to make sure the necessary code hooks are in their code.
• Operations services: most likely not application operations, but for infrastructure operations there’s often still a central (escalation) team.
• Architecture or Integration architecture cloud services: this is a really interesting discussion topic.  Product teams are customer oriented, not technology oriented. Do they need their own architect(s), or do they use architects from a central team?  And if they have their own architects, do they have the full platform overview or do you need a function of integration architecture in a central team?
• …

How to make this enabling teams work smoothly?

All enabling teams have their own specific tasks and accountabilities.  It might even be a good idea to organize these teams in … small product teams.  They are often referred to as ‘platform product teams’, but that would take us too far to further elaborate on that.  A key challenge is how the orchestration between these teams is going to happen.  This enabling machine is not going to work without putting oil between its components. This oil is provided by a central governance function.

What about the transition timeframe?

While there’s a whole series of steps that need to be taken on the ‘product side’ to get to such a modern operating model, there’s a reality where you have gaps in skill sets, tools and technologies, new architectures, new ways of working,…  To facilitate this transition phase, we often have a ‘product enablement team’ being put in place.  As a temporary setup with subject matter experts of all sorts that will have the product teams on their journey.

How do you make this all work together?

Everything mentioned above are logical building blocks of a modern IT organization.  To make it work, something extra is needed.  We call it the ‘cloud service catalogue concept’.  All enabling teams are putting cloud services in the catalogue.  Services defined in the most broad sense of the word.  These can be technical building blocks, architecture descriptions, SLA based services, shared skill offered as a subject matter expert.  Some of these cloud services are mandatory (think of the security stuff), some are optional for the product teams to use. During the transition phase, a product team can consume these services directly themselves, or they can use the product enablement team to facilitate the adoption of some of the cloud services.

 This concept allows for a transparent alignment between the IT enablement team (the central team) and the respective product teams. 

Last but not least: innovation and continuous modernization

One of the opportunities of cloud technology is that the technology changes on an almost daily basis.  This gives new opportunities for business growth.  The model we are exploring in this article puts an organization in a perfect situation to make sure you take advantage of this innovation.  Product teams are close to the customers.  So they catch new opportunities.   Adding a specific innovation and continuous optimisation team to the mix makes the story complete.  This team needs to inspire the product teams and also serves as the entry point for all product team requests.  They will then run a proof of concept if that’s appropriate and link with the governance team of the IT enablement team if changes to the standard services are needed.  In some companies, product teams can innovate on their own as well.  That’s actually the ‘standard setup’ in this agile product team design.  But we see that this is often ‘one bridge too far’ in large enterprises.

Putting it all together …

If we now put all of this together in 1 image, this is how we get to the overview of what we call a ‘modern service oriented organization’.  We use this model with several customers.  For each enterprise it ends up being customized to their reality.  What it offers is a good starting point for some of the key decisions that need to be taken.