Software architecture training
Learn about software architecture and become more architecturally aware with our two day training course ... book now.

Essays for hands-on software architects

Overview

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.

See the essays that have been published so far.

Chapter 1 | What is 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

  • Towards a definition of architecture
  • Different types of architecture
    • Technical Architecture
    • System Architecture
    • Application Architecture
    • Enterprise Architecture

Chapter 2 | About the Architect Role

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.

  • What is the role of an architect?
    • Functional requirements
    • Non-functional requirements
    • Structure and design
    • Fitness for purpose
    • Quality assurance
    • Mentoring and best practice
    • Estimating and planning
    • Technical authority
    • Development process
    • Reference architecture
    • Proof of concepts and prototypes
    • Testing plan
    • Quality plan
  • The architect in the project team
    • Architect as team leader
    • Architect and project manager as peers
    • A flat team structure, where everybody is the architect
  • How do you move into a software architecture role?
  • Experiences of new architects
  • A collaborative approach to architecture
    • Build motivation
    • Maintain momentum
    • Delegate where appropriate
  • An evolutionary approach to architecture
  • Challenges of the role
    • You can’t be 100% hands-on
    • How do you keep up to date?

Chapter 3 | Non-functional Requirements

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.

  • What are non-functional requirements?
  • How do you capture the non-functional requirements?
  • Is it important that they are all quantifiable?
  • Which non-functional requirements should you capture?
    • Performance (latency and throughput)
    • Scalability (data and traffic volumes)
    • Security
    • Extensibility
    • Flexibility
    • Auditability
    • Monitoring and management
    • Reliability
    • Availability
    • Failover/disaster recovery targets
    • Legal and regulatory requirements
    • Internationalisation and localisation

Chapter 4 | Technology Selection

Technology selection is one of the most fun parts of being a software architect, allowing you the freedom to explore new products and programming languages. Tread carefully, however, as most projects are typically working within a set of constraints that can both restrict and open up the number of technologies that can be used to solve the problem. Make the right technology choice and your project can mitigate its major risks in one fell swoop. Choose wrong and your project might feel like pushing a car up Mount Everest.

This chapter talks about how to approach technology selection using some case studies to illustrate the points being made.

  • How do you go about choosing technologies?
  • What constraints are you working within?
  • Leading edge vs. bleeding edge

Chapter 5 | Defining and Sharing an 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.

  • Options for defining an architecture
    • Formal vs. informal
    • UML vs. PowerPoint
    • Document- vs. model-based
    • Tool Choices
    • How Much Detail do you Include?
  • A Software Architecture Document
    • Functional View
    • Non-Functional View
    • Constraints
    • Architectural Principles
    • Logical View
    • Process View
    • Interfaces
    • Design View
    • Security View
    • Physical View
    • Deployment View
    • Monitoring, management and administration view
    • Data View
    • Technology Selection
    • Justification of non-functional requirements
  • A checklist for the Software Architecture Document

Chapter 6 | Applying the 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.

  • Reference architecture
  • Getting involved in feature development?
  • Evolving the architecture
  • Fitness for purpose
    • How do you assess the non-functional requirements?
    • How do you test the non-functional requirements?
    • When should you test the non-functional requirements?
  • Quality assurance
    • Quality at the process level
    • Quality at the architecture level
    • Quality at the design level
    • Quality at the code level

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

  • Questions from Architects
  • Interviewing "Architects"
    • Are we Talking the Same Language?
    • Crayons, not Pens
    • Abstract, not abstract
    • It's not me You've got to Convince...
    • Role Profile for Software Architects
  • Tips for Architects
    • In at the Deep End
  • Warnings for Architects
    • Software Projects Fail
    • Not Invented Here