Software Architecture Introduces Control
The Integration Zone is brought to you in partnership with Red Hat. Download the IDC Report: The Business Value of Red Hat Integration Products to learn more about Red hat Integration.
Only you can decide how much is right
A while back I wrote about how software architecture introduces structure and guidelines, consistency and clarity into software projects. When discussing this on the training course over the past few months, it's become clear to me that software architecture is also, in reality, about introducing control.
I interviewed a team leader today and when the conversation turned towards quality and specifically quality assurance, I was told that he was fortunate to work with a team that were very competent. It's a fair answer, but my follow-up was "how do you know that your team members are competent?".
For me, software architecture is about reducing the number of assumptions that are typically made on software projects, thereby reducing the number of ugly surprises that bite you further down the line. For most projects, benefits can probably be realised by introducing control and restraint, for example, to stop team members going off on tangents. Scrum does this through the introduction of sprint backlogs so that the team has focus on what they need to deliver during any given iteration. Likewise with software architecture; you need some degree of control in order to introduce structure and guidelines, consistency and clarity. For example, you can't have people writing database access code in your view components if you've designed an n-tier application in order to support some of your key non-functionals. Ditto things like ensuring that all of your components are stateless so that they can be scaled-out to cope with additional load. It's also about simply having a clear and consistent structure to your codebase; appropriately organising your code into packages, namespaces, components, layers, etc.
How much control do you need?
The real question that needs to be answered on any given software project is how much control needs to be introduced? At one end of the scale you have the dictatorial approach where nobody can make a decision for themselves versus the other end of the scale where nobody is getting any guidance whatsoever. I've seen both in real-world software projects and I've taken over projects where everybody on the team was basically left to their own devices. Introducing control on this sort of project is really really hard work but it needs to be done if the team are to have any chance of delivering a coherent piece of software that satisifies all of the original drivers.
So how much control do you introduce? My own answer is that it depends on a number of things...
- Are the team experienced?
- Have they worked together before?
- Are the project requirements complex?
- Are there major constraints that need to be taken into account?
- What sort of discussions are happening on a daily basis?
I've also noticed that different countries and cultures place different values on control. Some value control and the restraint that it brings whereas others value empowerment and motivation. There's no universally correct answer, but it is worth thinking about how much control is right for your own software project.