Enterprise Integration Zone is brought to you in partnership with:

Simon lives in Jersey (Channel Islands) and works as an independent consultant, specialising in software architecture, technical leadership and the balance with agility. Simon regularly speaks at international software development conferences and provides consulting/training to software teams at organisations across Europe, ranging from small startups through to global blue chip companies. He is the founder of "Coding the Architecture" (a website about pragmatic, hands-on software architecture) and the author of "Software Architecture for Developers" (an e-book that is being published incrementally through Leanpub). He still likes to write code too, primarily in .NET and Java. Simon is a DZone MVB and is not an employee of DZone and has posted 36 posts at DZone. You can read more from them at their website. View Full User Profile

Software Architecture Introduces Control

  • submit to reddit

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.

Software architecture introduces 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?
  • etc

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.

Published at DZone with permission of Simon Brown, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Lund Wolfe replied on Sun, 2013/06/30 - 3:10am

Ideally, developers can be trusted to maintain the integrity of the original design.  It's always easier and safer to follow the existing pattern.  Hopefully, there isn't any doubt about how the design works and how to follow it.  Even if the design is bad, if it remains consistent then it can at least be refactored more easily as a whole into a better design.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.