If we can think of delivery teams as a system, there are certain things that we would try to do with this system. If the system is composed of many sub-systems/applications/services, we’d try to make sure that if there is an issue in one sub-system/application/service, that any impact to other sub-systems/applications/services are minimised.

If we were creating a system from scratch we would never even consider having the logic managed externally from the application that will be delivering a process, this would mean that we break abstraction and encapsulation, and it would mean that the performance is reduced as the application has to make a request to some sort of centralised logic owner. When there are a number of applications this would mean that any changes in whatever owns centralised logic could end up causing issues in a number of applications. In addition, you probably wouldn’t separate out the validation from the application, as validation is required to make sure that nothing unexpected has occurred.

I don’t think many people would argue with the previous paragraph, other than to phrase it more eloquently or to be a bit more specific. But as a general statement I expect most people would agree with it. So, if we think of an organisation as a system, we can replace a few words from the previous paragraph to reflect an organisation.

“If we were creating an organisation from, scratch we would never even consider having the decisions managed externally from the teams that will be delivering some work, this would mean that we break abstraction and encapsulation, and it would mean that the performance is reduced as the team has to make a request to some sort of centralised decision owner. When there are a number of teams this would mean that any changes in whoever owns centralised decisions could end up causing issues in a number of teams. In addition, you probably wouldn’t separate out the testing from the team, as testing is required to make sure that nothing unexpected has occurred.”

The process of coming to technical decisions within an organisation work much the same way business logic works within an application. Business logic is the process for coming to a decision or an action, in our software we want the business logic alongside processing. Our teams should be modelled the same. As a general rule, those making technical decisions should also be affected by them in the longer term. This isn’t to say decisions should be free for all, obviously technical decisions should be made by based on sound reasoning, this can only come with adequate expertise. Making sure that the team includes people who have adequate expertise means the team as a unit doesn’t need to turn to an external unit to process business logic that the team should own. After all, we want our code to be both effective and efficient, our decision-making should be too.