Guiding Organizational Design With SOA Principles
A couple of years ago, Mike Cottmeyer wrote a blog post on How to Structure Your Agile Enterprise. He contended at scale we need to organize teams around capabilities. He referenced refactoring legacy architecture into a Service Oriented Architecture (SOA).
We have proven this with many of our clients over the last couple of years. We want to organize around products and their capabilities. A capability is an outcome-based view of what the product does. In other words, products, features, or services can be capabilities. As you design your organization, you can use SOA principles to structure around these capabilities.
According to Thomas Erl’s book, “SOA Principles of Service Design,” there are 8 main SOA principles. Below are ways you can use these principles as you transform your enterprise:
Standardized Service Contract
“Services within the same service inventory are in compliance with the same contract design standards.”
Individual parts of an engine each have detailed specifications so they will fit together consistently when assembled. As we design an organization, we want our teams to be highly cohesive and well understood. We want to have a governance model that defines the inputs/outputs for each stage. This ensures consistency and predictability of value flowing through the System of Delivery. Understood definitions of ready/done for Epics, Features, and Stories between Portfolio, Program, and Delivery teams provide the contract for work to flow through the system.
Service Loose Coupling
“Service contracts impose low consumer coupling requirements and are themselves decoupled from their surrounding environment.”
Think about an electrical outlet. You can plug in a lamp, radio, television, or even a toaster because the interface is standardized. You wouldn’t connect your television directly to the underlying electrical wires. This is analogous to loose coupling of teams. Teams agree to contracts across different capabilities in an organization to sequence or orchestrate work in parallel. Back-end services and front end UI teams can develop capabilities simultaneously with a standardized and agreed upon interface. When decomposing work, keeping this in mind allows for better efficiency.
Service Abstraction
“Service contracts only contain essential information and information about services is limited to what is published in service contracts.”
As we design organizations around capabilities, we want to bring together cross-functional teams of experts in that capability. We want to define the interface for teams to interact and exchange work, but allow each team to decompose and refine their own work. Teams require autonomy to self-organize and determine the best way to accomplish their work. Other parties don’t need to know how they do their work, just that it returns the expected result every time.
Service Reusability
“Services contain and express agnostic logic and can be positioned as reusable enterprise resources.”
As we look across the organization, we want to identify areas of reuse. For example, many different products utilize the services layer to localize business logic. Forming teams around such capabilities allows for optimized expertise of the platform and eliminates the need to spread this knowledge across every team. While small team Scrum may advocate full cross functional teams, as you scale in larger organizations, this becomes impossible due to size, complexity, and sheer number of different technologies and domains. As in SOA, we monitor for bottlenecks and can optimize flow based on demand.
Service Autonomy
“Services exercise a high level of control over their underlying runtime execution environment.”
Teams need to be stable and have local autonomy to make decisions and do the work requested. We want to decouple systems and environments to allow continuous delivery and break dependencies to allow these teams to be successful. Over time, independent funding of teams is possible, allowing for true agility.
Service Statelessness
“Services minimize resource consumption by deferring the management of state information when necessary.”
In SOA, statelessness means that a service doesn’t need to know or care about previous calls. It can do the work it needs to do with the information provided. Applied to organizational design, we want teams to be autonomous and have knowledge of their own work. Build your team structure to eliminate or minimize dependencies. Require well-defined requests as input to the team so they have the clarity required to take it and run. This means no dependencies or reliance on other teams.
Service Discoverability
“Services are supplemented with communicative metadata by which they can be effectively discovered and interpreted.”
Defining a clear end state vision for your organization is crucial for reaching organizational agility. It ensures everyone is on the same page and working towards the same goals. Defining the structure, governance, and metrics to measure progress is step one in any transformation. A transparent roadmap and plan ensures teams understand the organizational design and how work needs to flow through the system.
Service Composability
“Services are effective composition participants, regardless of the size and complexity of the composition.”
The concept of service composability is taking a large problem and breaking it into smaller, more manageable chunks. In organizational design, this speaks to organizing in vertical structures that progressively decompose business value. Use a multi-tiered governance model to refine work into smaller pieces so the appropriate team can carry out the work (e.g., Epic to Feature to Story to Task). This also allows for adaptability and flexibility as your market or organization changes.
Organizational design is complex and one size definitely does not fit all. It requires working with the client and understanding their unique end state. These ideas are by no means comprehensive, but can help guide towards the path of Organizational Agility.