As an architect it is not feasible to solely concern yourself with the design of the system, you have to also apply the same principles to the delivery teams who produce it. When you apply Agile and SOA principles to these teams, you are aiming to create Product Teams.
What's a Product?
Loosely Products are capabilities, or groups of capabilities, that the organisation wishes to have. When defining a product, SOA principles are helpful in identifying how your systems should be organised. Products share many of the attributes sought in services.
Products are Autonomous
Products don't rely on long chains of dependencies to facilitate the work they are responsible for. Business logic is self contained within the product.
Products Change Independently
Products are releasible on their own without needing to be staged with other physically separate systems.
Products have Identifiable Discrete Business Accountability
You can identify a single responsible person who is accountable for the product's function within the business. In a number of cases, if the product was not automated this person would run the team of people that did the job instead.
If multiple people are sharing accountability for the requirements you have grouped into your "product" then you don't have autonomy or clear business accountability.
Why Product Teams Anyway?
The main driver for moving to Product Teams within an Agile environment is efficiency. Product Teams are generally accepted to be a very efficient approach to delivering change due to three attributes that they exhibit:
- Domain Knowledge
- Limiting Hand-offs
As explored in my last post, Teams are stable and therefore have time to bond which increases their efficiency. Secondarily they are able to build up significant domain knowledge in the problem space they are working within. This domain knowledge reduces the amount of specification that is required for new or changed features and also allows the team to identify further opportunities for the product. Finally as the product itself is autonomous the team has reduced or removed the need to rely on other groups to provide output which will allow new features to function. Hand-offs are inefficient as they generally require a knowledge transfer to facilitate the work, a reprioritisation for one of the groups involved and often a co-ordination of multiple releases.
Product Teams are great mechanisms for encouraging ownership both within the business and within the change team itself. An accountable team cares about the product they are responsible for and is more likely to take decisions that are in the best interest of the team and not the individual. Further to this, the team members become accountable not only to the product but to each other as they are responsible for success or failure, not someone higher up.
Using a Service Catalogue to Identify Products
If you are fortunate to have a service catalogue to refer to already, you will likely find some variation on the below:
|Business Capability||Home Loans|
|Capability Description||Mortgage products for retail clients.|
|Business Owner||Head of Lending|
|Other Key Stakeholders||
Lending Operations Manager
|Service Level Objectives||
24/7 Uptime for Home Loan Applications
Home Loan Application
Basic Variable Rate Loan
Specifies Home Loan Product features, applies fees, interest, statement schedules, amortisation schedules to an Account.
If you are not fortunate enough to have something like the above, then you're really going to want to be doing some prep work. Without having an understanding of the business you're supporting your teams will be lacking in direction.
Service catalogues at their core try to quantify the business capabilities that you are supporting, which is fundamental to being successful with Agile.
Once you have defined the service you are trying to offer you need to decide whether it is the right size to be maintained by a single team.
Up next, putting it all together.