Software architecture essays for developers

This book is a collection of essays that together form a practical and pragmatic guide to software architecture. It's aimed at aspiring software architects and people that are new to the role. The overall goal is that we want to demystify what it means to be a software architect and provide guidance on how to do software architecture effectively.

Chapter 1 | What is software architecture?

Architecture is a widely-used term within software development yet is very hard to define rigorously. Indeed, it changes meaning from domain to domain or with differing levels of seniority. This chapter sets the scene by defining what architecture is all about, aiming to clarify the different levels of architecture and show how they relate

1. What is architecture?
   Towards a definition of architecture
2. Types of architecture
   Treat enterprise architectures with a pinch of salt
3. Strategy rather than code
   Is enterprise architecture the next logical step for software architects?

Chapter 2 | What is the role of a software architect?

Just as your software needs code and someone to develop that code, your software needs architecture and someone to define it. Whether it’s by a dedicated software architect or as a “job share” amongst the development team, the architect role needs to be fulfilled.

This chapter is dedicated to discussing the role of an architect, covering both the technical and the non-technical aspects of the role. In addition to defining the role of an architect, we also make comparisons to some of the other common roles on a software project. All of these roles are important, but the differences and boundaries need to be understood in order for the team to work together effectively. It is understood that the roles are different, but it's not necessarily understood how these differences work in practice. Ultimately, this chapter provides guidance that people can use in defining a terms of reference for their own software architecture role.

1. The role of a hands-on software architect
   What should a hands-on software architect do?
2. Crossing the mythical line or bridging the gaping chasm?
   The divide between software developer and software architect
3. Mind the gap
   Reducing the gap between software developers and software architects

Chapter 3 | How do you define software architecture?

Software development abounds with functional requirements; users will queue up to tell you what they want and point out what they don’t like. Non-functional requirements are far less glamorous, in common with most things described by what they’re not.

However, the non-functional requirements are one of the most important aspects of a software project, particularly from the architect’s perspective, so it’s important that we define exactly what they are and how to work with them. Ask a user how fast they want something to run and they’ll probably say, only half-jokingly, something along the lines of “as fast as possible”. Ask them how much they want to pay for it and you’ll probably get a conflicting requirement. While this isn’t peculiar to non-functional requirements, it is exacerbated by most users’ understandable lack of experience, and interest, of matters outside their own business domain: the “non-functionality”. This chapter discusses the various non-functional requirements that would routinely be considered by software architects, including details on how to capture, express, measure and test them. For completeness, a comprehensive checklist of non-functional requirements is included.

1. Start with the big picture
   Wide angle, telephoto, macro ... every picture should tell a different part of the same story
2. Software architecture is a platform for conversation
   Architectures don't live in isolation
3. You don't need a UML tool
   But they can be useful

Chapter 4 | How do you share software architecture?

Software architects are responsible for conceiving an architecture that meets the requirements but that’s really only half the story – the architecture needs to be captured and conveyed to those tasked with creating the software.

This chapter discusses some of the available options for defining an architecture and drills down into the detail of what you might want to include in that definition. We take the traditional RUP Software Architecture Document approach and build on it to include some of the other aspects that are important for an architect to consider (e.g. security, monitoring & management, a justification of how the architecture meets the non-functional requirements). The final item in this chapter is a checklist that can be used for people writing and reviewing software architecture definitions.

1. The code doesn't tell the whole story
   Why do we need software architecture documentation?
2. Software architecture document guidelines
   A set of guidelines and checklists for creating software architecture documents

Chapter 5 | How do you deliver software architecture?

Even the best architectures can be corrupted during development, be it through subversive developers or, more likely, misunderstanding. Applying the principles and design defined in the architecture not only helps ensure development conforms to the architectural vision, but also serves to keep the architecture evolving with the software.

This chapter looks at how you take the architecture and do something with it, as far as possible, in a development methodology-independent way. The key point is that you need to justify and stand behind the major design decisions.

Chapter 6 | Software Architecture in the Real World

Software exists in the real world; its development is not an academic exercise in analysis, design and typing but is subject to changing requirements, assumptions misunderstandings and personal opinion. Naturally, software architecture suffers from the effects of these too. Rather than trying to engineer all vagaries out, successful architectures recognise where they’re likely to occur and mitigate them.

While a healthy degree of cynicism can help with identifying potential problems, a good dose of optimism can prevent projects being railroaded into analysis paralysis. Architects also have to be a technical authority within the team, represent the business to the developers and the developers to the business. They need to champion what’s important and try to shrug off what’s not. This last chapter is about bringing everything together and placing it within the context of the real world. It shows how software architecture is, despite its rigour and technical content, as much about people as it is about code.