Organisation structure vs System Architecture
When there is a defect or problem, we try to do some ‘root cause analysis’ work out where the defect or problem is stemming from and try to fix the cause (hopefully) and not the symptoms of the defect. The same can be done (but is often not) for improving the architecture, rather than just […]
Delivery teams are a system – what should own business logic and decision making?
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 […]
Delivery teams are a system – Is asynchronous development is an anti-pattern?
Those of you who know me know that I am opinionated about maximising return on investment and maximising the speed of delivery. The more I’ve discussed concepts around software delivery the more I see delivery teams as a system. So I’ve decided to put together a series of Blog posts to explore this further, I’d […]
Where’s the WHY in ‘good’ architecture?
So many people say it’s important to design a system well, but few people discuss why this is important. When we’re working on a new piece of functionality, we try to find out what is it that we are trying to achieve and (more importantly) why we are trying to introduce this new functionality. These […]
Organising teams for a good architecture (part 2)
Team structure and ownership has a big impact on delivery (from both a quality perspective and velocity perspective) and the architecture of systems and sub-systems. Getting the optimal division of ownership is unfortunately both really important and really difficult to achieve. Worse still there is no fixed formula to make the job any easier. However, it is possible to […]
Organising teams for a good architecture (Part 1)
Having codebases owned by specific teams results in better productivity, and can result in a better architecture (if done properly). The worst case alternative of this is having the system not divided up but having a number of teams working on any codebase they feel they need to make a change in depending on the […]