Software architecture: Five things every developer should know
Learn five things every developer should know about software architecture for present-day technologies.
The software development industry is either taking giant leaps ahead or in deep turmoil. On the one hand, we're pushing forward, reinventing the way that we build software and striving for craftsmanship at every turn. On the other, we're continually forgetting the good of the past, and software teams are still failing on an alarmingly regular basis.
Software architecture plays a pivotal role in the delivery of successful software, yet it's frustratingly neglected by many teams. Whether performed by one person or shared amongst the team, the architecture role exists on even the most Agile of teams, yet the balance of up-front and evolutionary thinking often reflects aspiration rather than reality. The big problem is that software architecture has fallen out of favor over the past decade or so. Here are five things that every software developer should know about it.
1. Software architecture isn't about big design upfront
Software architecture has traditionally been associated with big design upfront and Waterfall-style projects, where a team would ensure that every last element of the software design was considered before any code was written. Software architecture is basically about the high-level structure of a software system and how you get to an understanding of it. This tip is about making the significant decisions that influence the shape of a software system rather than understanding how long every column in the database should be.
2. Every software project needs to consider software architecture
Regardless of size and complexity, every software project needs to consider software architecture. Why? Put simply, bad things tend to happen if they don't. If software architecture is about structure and vision, not thinking about it tends to lead to poorly structured, internally inconsistent software systems that are hard to understand; hard to maintain; and potentially don't satisfy one or more important nonfunctional requirements, such as performance, scalability or security. Explicitly thinking about software architecture provides you with a way to introduce technical leadership, and stacks the odds of a successful delivery in your favor.
3. The software architecture role is about coding, coaching and collaboration
The image that many people have of software architects is of traditional, "ivory tower" software architects dictating instructions to an unsuspecting development team. It doesn't need to be like this though, with modern software architects preferring an approach that favors coding, coaching and collaborative design. The software architecture role doesn't necessarily need to be undertaken by a single person, plus coding is a great way to understand whether the resulting architecture is actually going to work.
4. You don't need to use UML
Again, traditional views of software architecture often conjure up images of huge Unified Modeling Language (UML) models that attempt to capture every last drop of detail. While creating and communicating a common vision is important, you don't need to use UML. In fact, you could argue that UML isn't a great method for communicating software architecture anyway. If you keep a few simple guidelines in mind, lightweight "boxes and lines" sketches are an effective way to communicate a software architecture.
5. A good software architecture enables agility
There's a common misconception that architecture and Agile are competing forces, there being a conflict between them. This simply isn't the case, however. On the contrary, a good software architecture enables agility, helping you embrace and implement change. Good software architectures aren't created by themselves, though, and some conscious effort is needed.
If you'd like to discuss these or other questions, please join me in the Design forum over at CodeRanch, where I'll be discussing software architecture and my new book, Software Architecture for Developers.
