Software Architecture for Developers Technical leadership and the balance with agility (Simon Brown) (Z-Library)

📄 File Format: PDF

💾 File Size: 7.3 MB

📖 Read Online ⬇️ Download

Registered users can read the full content for free

Register as a Gaohf Library member to read the complete e-book online for free and enjoy a better reading experience.

📄 Page 1

(This page has no text content)

📄 Page 2

Software Architecture for Developers Technical leadership and the balance with agility Simon Brown This book is for sale at http://leanpub.com/software-architecture-for-developers This version was published on 2022-05-28 This is a Leanpub book. Leanpub empowers authors and publishers with the Lean Publishing process. Lean Publishing is the act of publishing an in-progress ebook using lightweight tools and many iterations to get reader feedback, pivot until you have the right book and build traction once you do. © 2012 - 2022 Simon Brown

📄 Page 3

Tweet This Book! Please help Simon Brown by spreading the word about this book on Twitter! The suggested hashtag for this book is #sa4d. Find out what other people are saying about the book by clicking on this link to search for this hashtag on Twitter: #sa4d

📄 Page 4

For Kirstie, Matthew and Oliver

📄 Page 5

Contents 1. About the book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Why did I write the book? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 A new approach to software development? . . . . . . . . . . . . . . . . . . . . . . . 2 2. About the author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 I Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. What is “software architecture”? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Architecture as a noun - structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Architecture as a verb - vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Types of architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Towards a definition of “software architecture” . . . . . . . . . . . . . . . . . . . . 11 Enterprise architecture - strategy rather than code . . . . . . . . . . . . . . . . . . . 12 Architecture vs design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Is software architecture important? . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Does every software project need software architecture? . . . . . . . . . . . . . . . 17 5. Architectural drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 1. Functional requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2. Quality Attributes (non-functional requirements) . . . . . . . . . . . . . . . . . . 18 3. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4. Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Understand their influence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

📄 Page 6

CONTENTS II Architects .............................................................................................. 32 6. The software architecture role .............................................................................. 33 1. Architectural drivers ...................................................................................................... 34 2. Designing software ......................................................................................................... 34 3. Technical risks .................................................................................................................. 35 4. Technical leadership ......................................................................................................... 35 5. Quality assurance ............................................................................................................ 36 Software architecture is a role, not a rank . . . . . . . . . . . . . . . . . . . . . . . . 36 Create your own definition of the role . . . . . . . . . . . . . . . . . . . . . . . . . . 37 7. Technical leadership 38 Controlling chaos 38 Collaborative technical leadership is not easy . . . . . . . . . . . . . . . . . . . . . 40 Do agile teams need software architects? . . . . . . . . . . . . . . . . . . . . . . . . 43 Software development is not a relay sport . . . . . . . . . . . . . . . . . . . . . . . . 44 Mind the gap 45 8. Software architects and coding 47 A step back in time 47 Should software architects write code? . . . . . . . . . . . . . . . . . . . . . . . . . 50 The tension between coding and being senior . . . . . . . . . . . . . . . . . . . . . 52 Software as an engineering discipline . . . . . . . . . . . . . . . . . . . . . . . . . . 53 9. The skills and knowledge of a software architect . . . . . . . . . . . . . . . . . . 56 Technology skills 56 Soft skills 58 Domain knowledge 62 From developer to architect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Tips for new software architects ...................................................................................... 67 III Architecting ................................................................................... 70 10. Managing technical risks ...................................................................................... 71 Quantifying and prioritising risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Identifying risks 73 Mitigating risks 76 Risk ownership 77

📄 Page 7

CONTENTS 11. Software architecture in the delivery process . . . . . . . . . . . . . . . . . . . . 78 The conflict between agile and architecture . . . . . . . . . . . . . . . . . . . . . . . 78 Technical vs functional design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Software architecture provides boundaries . . . . . . . . . . . . . . . . . . . . . . . 81 How much up front design should you do? . . . . . . . . . . . . . . . . . . . . . . . 83 Firm foundations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Contextualising just enough up front design . . . . . . . . . . . . . . . . . . . . . . 88 Introducing software architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 The essence of software architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 IV Appendices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 12. Appendix A: Financial Risk System . . . . . . . . . . . . . . . . . . . . . . . . . . 96 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Non-functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

📄 Page 8

1. About the book This book is a practical, pragmatic and lightweight guide to software architecture, specifically aimed at developers, and focussed around the software architecture role and process. Why did I write the book? Like many people, I started my career as a software developer, taking instruction from my seniors and working with teams to deliver software systems. Over time, I started designing smaller pieces of software systems and eventually evolved into a position where I was performing what I now consider to be the software architecture role. I’ve worked for IT consulting organisations for the majority of my career, and this means that most of the projects that I’ve been involved with have resulted in software systems being built either for or with our customers. In order to scale an IT consulting organisation, you need more people and more teams. And to create more teams, you need more software architects. And this leads me to why I wrote this book: 1. Software architecture needs to be more accessible: Despite having some fantastic mentors, I didn’t find it easy to understand what was expected of me when I was moving into my first software architecture roles. Sure, there are lots of software architecture books out there, but they seem to be written from a different perspective. I found most of them very research oriented or academic in nature, yet I was a software developer looking for real-world advice. I wanted to write the type of book that I would have found useful at that stage in my career - a book about software architecture aimed at software developers. 2. All software projects need software architecture: I like agile approaches, I really do, but the lack of explicit regard for software architecture in many of the approaches doesn’t sit well with me. Agile approaches don’t say that you shouldn’t do any up front design, but they often don’t explicitly talk about it either. I’ve found that this causes people to jump to the wrong conclusion and I’ve seen the consequences that a lack of any up front thinking can have. I also fully appreciate that big design up front isn’t the answer either. I’ve always felt that there’s a happy medium to be found where some up front thinking is done, particularly when working with a team that has a mix of

📄 Page 9

About the book 2 experiences and backgrounds. I favour a lightweight approach to software architecture that allows me to put some building blocks in place as early as possible, to stack the odds of success in my favour. 3. Lightweight software architecture practices: I’ve learnt and evolved a number of practices over the years, which I’ve always felt have helped me to perform the software architecture role. These relate to the software design process and identifying technical risks through to communicating and documenting software architecture. I’ve always assumed that these practices are just common sense, but I’ve discovered that this isn’t the case. I’ve taught these practices to thousands of people over the past few years and I’ve seen the difference they can make. A book helps me to spread these ideas further, with the hope that other people will find them useful too. A new approach to software development? This book isn’t about creating a new approach to software development, but it does seek to find a happy mid-point between the excessive up front thinking typical of traditional methods and the lack of any architecture thinking that often happens in software teams who are new to agile approaches. There is room for up front design and evolutionary architecture to coexist.

📄 Page 10

2. About the author I’m an independent software development consultant specialising in software architecture; specifically technical leadership, communication and lightweight, pragmatic approaches to software architecture. In addition to being the author of Software Architecture for Developers, I’m the creator of the C4 model and I built Structurizr, which is a collection of tooling to help software teams visualise, document and explore their software architecture. I regularly speak at software development conferences, meetups and organisations around the world; delivering keynotes, presentations and workshops about software architecture. In 2013, I won the IEEE Software sponsored SATURN 2013 “Architecture in Practice” Presentation Award for my presentation about the conflict between agile and architecture. I’ve spoken at events and/or have clients in over thirty countries around the world. You can find my website at simonbrown.je and I can be found on Twitter at @simonbrown.

📄 Page 11

3. Acknowledgements Although this book has my name on the front, writing a book is never a solo activity. It’s really the product of a culmination of ideas that have evolved and discussions that have taken place over a number of years. For this reason, there are a number of people to thank. First up are Kevin Seal, Robert Annett and Sam Dalton for lots of stuff; ranging from blog posts on Coding the Architecture and joint conference talks through to the software architecture user group that we used to run at Skills Matter (London) and for the many tech chats over a beer. Kevin also helped put together the first version of the training course that, I think, we initially ran at the QCon Conference in London, which then morphed into a 2-day training course that we have today. I’ve had discussions about software architecture with many great friends and colleagues over the years, both at the consulting companies where I’ve worked (Synamic, Concise, Evolution and Detica) and the customers that we’ve built software for. There are too many people to name, but you know who you are. I’d also like to thank everybody who has attended one of my talks or workshops over the past few years, as those discussions also helped shape what you find in the book. You’ve all helped; from evolving ideas to simply helping me to explain them better. Thanks also to Junilu Lacar and Pablo Guardiola for providing feedback, spotting typos, etc. And I should finally thank my family for allowing me to do all of this, especially when a hectic travel schedule sometimes sees me jumping from one international consulting gig, workshop or conference to the next. Thank you.

📄 Page 12

I Architecture In this part of the book we’ll look at what software architecture is about, the difference between architecture and design, and why thinking about software architecture is important.

📄 Page 13

4. What is “software architecture”? Let’s start with the basics. The word “architecture” means many different things to many different people, and there are many different definitions published on the Internet. I’ve asked thousands of software developers what “architecture” means to them and, in no particular order, a summary of their responses is as follows. • Modules, connections, dependencies and interfaces • The big picture • The things that are expensive to change • The things that are difficult to change • Design with the bigger picture in mind • Interfaces rather than implementation • Aesthetics (e.g. as an art form, clean code) • A conceptual model • Satisfying non-functional requirements/quality attributes • Everything has an “architecture” • Ability to communicate (abstractions, language, vocabulary) • A plan • A degree of rigidity and solidity • A blueprint • Systems, subsystems, interactions and interfaces • Governance • The outcome of strategic decisions • Necessary constraints • Structure (components and interactions) • Technical direction • Strategy and vision • Building blocks • The process to achieve a goal • Standards and guidelines • The system as a whole • Tools and methods

📄 Page 14

What is “software architecture”? 7 • A path from requirements to the end-product • Guiding principles • Technical leadership • The relationship between the elements that make up the product • Awareness of environmental constraints and restrictions • Foundations • An abstract view • The decomposition of the problem into smaller implementable elements • The skeleton/backbone of the product No wonder it’s hard to find a single definition! Thankfully there are two common themes here: architecture as a noun and architecture as a verb. Architecture as a noun - structure As a noun, architecture can be summarised as being about structure. It’s about the decomposition of a product into a collection of smaller building blocks¹ and the interac- tions/relationships between these building blocks. This needs to take into account the whole of the product; including the foundations and the infrastructure services that deal with cross- cutting concerns such as security, configuration, error handling, etc. To quote Bass, Clements, and Kazman: The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relations among them. Architecture as a verb - vision As a verb, architecture (i.e. the process of creating architecture, or “architecting”) is about translating the architectural drivers (functional requirements, quality attributes, constraints, and principles) into a technical solution, thereby creating a technical roadmap or vision. Crucially, it’s also about communicating that vision to a number of stakeholders both inside ¹We don’t tend to use the term “building blocks” when describing the structure of a software system. Instead we use terms such as “component”, “module”, “service”, “microservice”, “layer”, etc. Unfortunately some of these terms are ambiguous. As you’ll see in volume 2 of “Software Architecture for Developers”, this causes a number of problems when diagramming and documenting software architecture.

📄 Page 15

What is “software architecture”? 8 and outside of the immediate software development team, so that everybody has a consistent view of what is being (or has been) built. The process of architecting is additionally about introducing technical leadership so that everybody involved with the construction of the software system is able to contribute in a positive and consistent way. Types of architecture What we have so far is a very generic definition of the word “architecture” but, of course, there are many different types of architecture and people who call themselves “architects” within the IT industry. Here, in no particular order, is a list of types of architecture that people most commonly identify when asked. • Infrastructure • Security • Technical • Solution • Network • Data • Hardware • Enterprise • Application • System • Integration • IT • Database • Information • Process • Business • Software The unfortunate thing about this list is that some of the terms are easier to define than others, particularly those that refer to or depend upon each other for their definition. For example, what does “solution architecture” actually mean? For some organisations “solution architect” is simply a synonym for “software architect”, whereas other organisations have a specific role that focusses on designing an overall “solution” to a problem, stopping before

📄 Page 16

What is “software architecture”? 9 the level at which implementation details are discussed. Similarly, “technical architecture” is vague enough to refer to software, hardware or a combination of the two². What do all of these terms have in common? Well, aside from being able to suffix each of the terms with “architecture” or “architect”, all of these types of architecture have structure and vision in common. Let’s take “infrastructure architecture” as an example. Imagine that you need to create a network between two offices located at different ends of the country. One option is to find the largest reel of network cable that you can, plug it in at one office, and start heading to the other in a straight line. Assuming that you had enough cable, this could potentially work. In reality though, there are a number of environmental constraints (real-world obstacles such as rivers, lakes, roads, cities, etc) and service-level agreements (performance, bandwidth, security, etc) that you need to consider in order to actually deliver something that satisfies the original goal. This is where the process of architecting is important. One single long piece of cable is certainly one approach, but it’s not a very good one because of the real- world constraints. For this reason, networks are typically much more complicated, requiring a collection of smaller building blocks that collaborate together in order to satisfy the goal. From an infrastructure perspective then, we can talk about structure in terms of the common building blocks that youwould expect to see within this domain; things like routers, firewalls, packet shapers, switches, etc. Regardless of whether you’re building a software system, a network or a database; a successful solution requires you to understand the problem and create a vision that can be communicated to everybody involved with the construction of the end-product. In order to move towards a definition of “software architecture”, let’s look at a couple of types of architecture in the IT domain that are relatively well defined. Application architecture Application architecture is what we as software developers are probably the most familiar with. In this context, I’m going to define an application as being a single deployable unit, written in a single technology; such as a single-page JavaScript/Angular application, an iOS or Android mobile app, a Java server-side Spring MVC web application, a .NET desktop application, etc. Application architecture is about looking inside the application to understand how it’s designed and built. This includes how the application has been decomposed into building ²My own job title for a number of years was “Technical Architect”. With hindsight, this was not very descriptive or accurate, since my day-to-day focus was primarily software architecture rather than anything else.

📄 Page 17

What is “software architecture”? 10 blocks (e.g. components, layers, packages, namespaces, etc) as well as understanding the patterns, frameworks and libraries in use. In essence, it’s predominantly about code, and the organisation of that code. System architecture I like to think of system architecture as one step up in scale from application architecture. If you look at most software systems, they’re actually composed of multiple deployable units (e.g. applications or datastores), each of which might be built using different technologies. As an example, you might have a software system comprising of a client-side iOS mobile app communicating via JSON/HTTPS to a Java server-side Spring MVC web application, which itself consumes data from a MySQL database. Since each of these three deployable units (the mobile app, the web app and the database) is built using a different technology, each of them will have their own internal application architecture. However, for the software system to function as a whole, thought needs to be put into bringing all of those separate deployable units together. In other words, you also need to consider the overall structure of the software system at a high-level, and the integration of the various parts. For example, if I make a request from the mobile app, how is that request processed by the entire software system? Additionally, software systems typically don’t live in isolation, so system architecture also includes the concerns around interoperability and integration with other systems within the environment. Where application architecture tends to focus primarily on software (e.g. programming languages, frameworks, libraries, etc), system architecture is about understanding both software and hardware. Admittedly, much of the hardware that we deal with nowadays is virtualised or completely hidden³, but it’s an important concern nonetheless. The reason that most definitions of system architecture include references to software and hardware (whether it’s the target deployment platform or supporting infrastructure) is that you can’t have a successful software system without it. After all, software needs to be deployed somewhere in order to run! Additionally, infrastructure typically provides constraints that must be taken into account when designing software. Examples of this range from the processing power and memory of embedded devices limiting what your software can do, through to cloud providers limiting how your applications are deployed in order to facilite better high availability and scaling. ³Platform as a Service (PaaS) and Function as a Service (FaaS) environments typically hide the underlying hardware completely, and instead provide higher-level abstractions on which to build and deploy software systems. Understanding the constraints of these environments is still important if you want to build software that “works”.

📄 Page 18

What is “software architecture”? 11 Towards a definition of “software architecture” Unlike application architecture and system architecture, which are relatively well under- stood, the term “software architecture” isn’t. Rather than getting tied up in the complexities and nuances of the many definitions of software architecture that exist on the Internet, I like to keep the definition as simple as possible. For me, software architecture is simply the combination of application architecture and system architecture, again in relation to structure and vision. In other words, it’s anything and everything related to the design of a software system; from the structure of the code and understanding how the whole software system works at a high level, through to how that software system is deployed onto infrastructure. But that’s not the whole story. When we’re thinking about software development as software developers, most of our focus is placed on the code. Here, we’re thinking about things like object oriented principles, func- tional programming principles, classes, interfaces, modules, inversion of control, refactoring, automated testing, clean code and the countless other technical practices that help us build better software. If your team consists of people who are only thinking about this, then who is thinking about the other things such as: • Cross-cutting concerns; including logging, exception handling, etc. • Security; including authentication, authorisation and confidentiality of sensitive data. • Performance, scalability, availability and other quality attributes. • Audit and other regulatory requirements. • Real-world constraints of the environment. • Interoperability/integration with other software systems. • Operational, support and maintenance requirements. • Structural consistency and integrity. • Consistency of approaches to solving problems and implementing features across the codebase. • Evaluating that the foundations you’re building will allow you to deliver what you set out to deliver. • Keeping an eye on the future, and changes in the environment. In order to think about these things, you need to step back, away from the code and your development tools. Working software is ultimately about delivering working code, so the detail is crucially important. But software architecture is about having a holistic view across your software system, to ensure that your code is working toward your overall vision rather than against it.

📄 Page 19

What is “software architecture”? 12 Enterprise architecture - strategy rather than code Although this book isn’t about “enterprise architecture”, it’s worth including a short definition so that we understand how it differs from software architecture. Enterprise architecture generally refers to the sort of work that happens centrally and across an organisation. It looks at how to organise and utilise people, process and technology to make an organisation work effectively and efficiently. In other words, it’s about how an enterprise is broken up into groups/departments, how business processes are layered on top of those groups/departments, and how technology is used to support the goals of the enterprise. This is in very stark contrast to software architecture because it doesn’t necessarily look at technology in any detail. Instead, enterprise architecture might look at how best to use technology across the organisation, without actually getting into detail about how that technology works. While some developers and software architects do see enterprise architecture as the next logical step up the career ladder, most probably don’t. The mindset required to undertake enterprise architecture is very different to software architecture, taking a very different view of technology and its use across an organisation. Enterprise architecture requires a higher level of abstraction, and a different focus. It’s about breadth rather than depth, and strategy rather than code. Central architecture groups As a quick aside, if you’ve ever worked in a large organisation, the definition I’ve just given for enterprise architecture might be different to what you were expecting. Often, large organisations will have a “central architecture group” that might be referred to as “the enterprise architects”. Such groups typically manage lists of the approved technologies that you can (or must!) use when building software, and will often have some involvement in reviewing/guiding the output from software development teams to ensure consistency across the organisation. Although a useful role, this isn’t really what I deem to be “enterprise architecture”. Architecture vs design One of the words that people use to describe architecture is “design”, and this raises the question of whether we should use the words “architecture” and “design” interchangeably.

📄 Page 20

What is “software architecture”? 13 Grady Booch has a well cited definition of the difference between architecture and design that really helps to answer this question. In On Design, Grady says that: As a noun, design is the named (although sometimes unnameable) structure or behavior of a system whose presence resolves or contributes to the resolution of a force or forces on that system. A design thus represents one point in a potential decision space. If you think about any problem that you’ve needed to solve, there are probably a hundred and one ways in which you could have solved it. Take your current software project/product for example. There are probably a number of different technologies, deployment platforms, and design approaches that are also viable options for achieving the same goal. In designing your software system though, your team chose just one of the many points (options) in the potential decision space. That’s the essence of design. It’s about narrowing down the solution space to find an option that works given the context in which you are working. Grady then goes on to say that: All architecture is design but not all design is architecture. This makes sense, because creating a solution, and “architecting”, is essentially a design exercise. It’s about narrowing down options, and making decisions. However, for some reason, there’s a distinction being made about not all design being “architecture”, which Grady clarifies with the following statement: Architecture represents the significant design decisions that shape a system, where significance is measured by cost of change. Essentially, Grady is saying that the significant decisions are “architecture”, and that everything else is “design”. In the real world, the distinction between architecture and design isn’t clear-cut, but this definition does provide us with a basis to think about what might be significant (i.e. “architectural”) in our own software systems. For example, this could include: • The overall shape of the software system (e.g. client-server, web-based, native mobile, distributed, microservices, asynchronous vs synchronous, etc). • The structure of the code inside the various parts of the software system (e.g. whether the code is structured as components, layers, features, ports and adapters, etc).