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

Structure and Guidelines, Consistency and Clarity

07.07.2013
| 2292 views |
  • submit to reddit

A couple of days upfront can really make a big difference to the big picture

One of my key points about software architecture is that it introduces structure and guidelines into a software system, which in turn leads to consistency and clarity of the overall design. Basically, I'm saying that there are some real benefits from thinking about your design upfront. This isn't a particularly groundbreaking statement, but you'd be surprised how few teams spend some quality time to do this. As I mentioned in Estimating a software system, this thinking doesn't need to take very long at all.

A design workshop can introduce software architecture

If you take a simple lightweight approach, you can map out the major functional requirements and come up with a design down to the major components in a couple of days. Then, you can do some high-level estimating off the back of this design. There are a number of ways that you can map out the functional requirements, although I find that user stories are a good way to summarise the key requirements.

Thinking about your software design on your own is great, but making it a collaborative exercise is even better and comes highly recommended. We're doing this at the moment for another project where each of us on the team has specialisms in different technology aspects of the overall solution. The benefit of this is that we all know how the technology in our own areas works, but the details of how those technologies collaborate is often unknown. Also, we sometimes tend to assume what responsibilities each technology will take on and it's only by discussing the overall solution as a group that we realise we've either doubled up on something or assumed that somebody else was looking after it. Essentially, software design as a collaborative exercise allows everybody's vision to meet so that the end-result is consistent and clear. As I've written before, often some of the basic foundations are missed.

Software architecture introduces structure and guidelines into a software system, leading to consistency and clarity

For me, explicitly thinking about the components that make up the software system introduces structure, which in turn can be used as a template for building that system. From this, you get a consistent approach to solving common problems and a thought out design with a clear architectural vision. A couple of days upfront can really make a big difference to the big picture.

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.)