In the future, business solutions are going to be built as a mesh of interconnected apps, services and APIs to provide unrivalled flexibility and speed.
While service-oriented operating models (SOA) are not new and have been around for at least a couple of decades, it is now, with the availability of cloud computing capabilities, no-code integration and API management they found a new life.
Those who have ever tried to simplify the whole concept of digital transformation for senior stakeholders know how difficult this could be. Indeed, many fundamental concepts of digital transformation do exist within Disciplined Agile methodology, so the intuitive approach is to state - "You need to do it in an agile way".
The particular challenge starts, however, with the fact that many companies already had some experience in executing projects with some elements of agile methodology like sprints, scrums, etc. So in my discussions about principles of service-oriented business architecture, I always hear the response - "What that extra we need to do?".
Seeing a clear gap, I have created an EXTRA framework that is not only aimed to explain the significant differences of the service-oriented operating model but also could be used to test the proposed approach against the "red lines".
So what does EXTRA stands for?
E is for End-to-end ownership.
When we are talking about adopting a service-oriented business model, it is critical for the entire Product team and especially for Product Owner to share the End-to-End collective responsibility for the result. The whole team is either winning together or loosing together against their service contract with their customers. All members of the product team are accommodating each other; involved in finding and then resolving issues at the source without much need to get outside of their service boundary. Failing this test creates hyper-specialised and highly dependent silos and very well-known lack of ownership.
X is for cross-functional teams.
Cross-functional teams have all the necessary skills to fulfil their end-to-end purpose. All these skills create an increased efficiency that comes from the reduction in management overhead due to a flatter org structure.
T is for long-lasting, empowered Teams
Continuity and knowledge retention have been among the key issues coming from the temporary nature of projects. Adopting the principle, "you build it - you run it" combined with empowering teams to make the decisions within pre-agreed guidelines changes the behaviour of the team members towards ensuring better quality outcomes and developing the right internal capabilities.
R is for Re-usability mindset
It has to be the incentive for the product owner and product team to drive the scalability, adoption and further use of their product. Single-use solutions have to give space to multiple applications across the organisation via well-thought-through interoperability and integration.
Failing this important test will inevitably lead to the creation of pointless and expensive duplications.
A is for Agile-driven methodology
Agile has a special place in this set of test. It has been around enough time for the majority of people to either have direct experience from projects run in an agile way or at least have heard about such projects.
More often than not, the knowledge about Agile methodology is restricted to ceremonies only. Companies are entirely overlooking the fact that the main focus of the service-oriented operating model is to delight customers and users with solutions that "do WHAT they want" and "HOW they want it done."
