Facilitating Software Architecture

Preface

If delivery of software were simply a matter of typing out lines of code, then unconnected individuals could achieve the same ends as teams of individuals of equal number and similar skills. This is not the case. Teams can and do build better software.

In sports, it is expected that abilities and experience will be diverse and that everyone will play their part. When a team combines their skills and focuses on a shared goal, they stand the greatest chance of winning.¹ The same dynamics apply in software development teams, where our goal is the sustainable delivery and evolution of a quality end product.

As a consultant, developer, and software/systems architect, I have been incredibly lucky to work closely with some brilliant software delivery teams. I have seen them in action, working within many different styles of architecture, using a broad range of programming languages, tools, and technology stacks, deploying a variety of approaches and practices, running on a cornucopia of runtimes, and supported by an abundance of cultures and organizations. I’ve learned an incredible amount from seeing them at work. They have been exemplars of the concept of “high-performing” teams.

I’ve also been lucky enough to have known, learned from, and—when I was very lucky—worked with some brilliant software architects. I’ve seen them think, create, deploy wisdom, and problem solve. But this was not what made them brilliant. What made them brilliant was how they listened, communicated, ...