28. Epilogue

You’ve arrived at the end of the journey. Nice work.

We hope you can find some valuable takeaways from this book. We suggest the list should include the following:

1. What architecture is, why it’s important, what influences it, and what it influences.

2. The role that architecture plays in a business, technical, project, and professional context.

3. The critically important symbiosis between architecture and quality attributes, how to specify quality attribute requirements, and the quick immersion you’ve had into the dozen or so of the most important QAs.

4. How to capture the architecturally significant requirements for an architecture.

5. How to design an architecture, document it, guide an implementation with it, evaluate it to see if it’s a good one for your needs, reverse-engineer it, and manage a project around it.

6. How to evaluate an architecture’s cost and benefit, what it means to be architecturally competent, and how to use architecture as the basis for an entire software product line.

7. Architectural concepts and patterns for systems on the current technological frontier: edge applications and the cloud.

Fine. Now what?

It’s very tempting to end the book with a cheery imperative to go forth and architect great systems. But the truth is, life isn’t that simple.

The authors of this book have, collectively, an embarrassingly large number of years of experience in teaching software architecture. We teach it through books like this one, in the classroom to students, and in industrial short courses to practicing software architects of all stripes, from “aspiring” to “old hand.” And often, much too often, we know that after our students conscientiously learn what we have to offer, they walk into an organization that is not as architecturally savvy as the students now are, and our students have no practical way to put what they have learned into practice.

Most of you will not be able to dictate an architecture-based philosophy to the projects to which you’ll be assigned, if it’s not already present. You won’t be able to say, “This Agile project needs a lead software architect!” and make it stick if the team leaders think that Agile methods won’t permit any overarching design. You won’t be able to say, “We’re going to include an explicit architecture evaluation in our project schedule” and have everyone comply. You won’t be able to say, “We’re going to use the Views and Beyond approach and templates for our architecture documentation” and have your directive obeyed.

Lest you feel that all your time absorbing the material in this book was time spent for a lost cause, we want to close the book with some advice for carrying what you’ve learned into your professional setting:

1. Speak the right language. You know by now that architecture is the means to an end, and not an end in itself. The decision makers in your organization typically care about the ends, not the means. They care about products, not the architectures of those products. They care about ensuring that the products are competitive in the marketplace. And they care about executing the organization’s marketing and business strategy. They may not express their concerns in architecturally significant terms, but rather in market terms that you’ll have to translate.

2. Speak the right language, part 2. Project managers care about reduction of technical risk, reliable and realistic scheduling and budgeting, and planning the production of those products. To the extent that you can justify a focus on architecture in those terms, you’ll more likely be successful in gaining the freedom to carry out some of the practices espoused in this book. And you really can justify this focus: A sound architecture is an unparalleled risk reduction strategy, a reliable work estimator, and a good predictor of production methods.

3. Get involved. One of the best ways to insert architectural concerns into a project is to show its value to stakeholders who don’t often get a chance to see it. Requirements engineers are a case in point. Most often, they meet with customers and users, capture their concerns, write them up, and toss the requirements over the fence (usually a very tall fence) to the designers. Challenge this segregation! Try to get involved in the requirements capture activity. Invite yourself to meetings. Say that, as an architect, you want to understand the problem by hearing the concerns straight from the horse’s mouth. This will give you critical exposure to the very stakeholders you’ll need to help with your design, evaluation, and documentation chores. Furthermore it will give you a chance to add value to the requirements capture process. Because you may have a design approach in mind, you may be able to offer better quality attribute responses than the customer has in mind, and that might make our marketers very happy. Or you may be able to spot troublesome requirements early on, and help nudge the customer to a perfectly adequate but more architecturally palatable QA response. Also, you can take it upon yourself to contact your organization’s marketers. They are often the ones who come up with product concepts. You would do well to learn how they do that, and eventually you could help them by pointing out useful variations on existing products that could use the same architecture.

4. It’s the economy, stupid. Think in, and couch your arguments in, economic terms. If you think an architectural trade study, or an architecture document, or an architecture evaluation, or ensuring code compliance with the architecture is a good idea for your project, make a business case for it. Pointy-haired bosses in comic strips notwithstanding, managers are really—trust us here—rational people. But their goals are broad and almost always have to do with economics. You should be able to argue, using back-of-the-envelope arithmetic, that (for example) producing an updated version of the architecture document is a worthwhile activity when the system undergoes a major change. You should be able to argue that activities undertaken with the new architecture documentation will be much less error-prone (and therefore less expensive) than those same activities undertaken without a guiding architecture. And the effort to keep the documentation up to date is much less than the expected savings. You can plug some numbers in a spreadsheet to make this argument. The numbers don’t have to be accurate, just reasonable, and they’ll still make your case.

5. Start a guerrilla movement. Find like-minded people in your organization and nurture their interest in architecture. Start a brown-bag lunchtime reading and discussion group that covers books or book chapters or papers or even blogs about architecture. For example, your group could read the chapter in this book about architecture competence, and discuss what practices you’d like to see your organization adopt, and what it would take to adopt them. Or the group could agree on a joint documentation template for architecture, or come up with a set of quality attribute scenarios that apply across your collective projects. Especially appealing is to come up with a set of patterns that apply to the systems you’re building. Or bring a vexing design problem from your individual project, and let the group work on a written solution to it. Or have the group offer its services as a roving architecture evaluation team to other projects. Your group should meet regularly and often, and adopt a specific set of tangible goals. The importance of an enthusiastic and dedicated leader—you?—who is keen to mature the organization’s architecture practices cannot be overstated. Advertise your meetings, advertise your results, and keep asking more members to join your group.

6. Relish small victories. You don’t have to change the world overnight. Every improvement you make will put you and your organization in a better place than it would have been otherwise.

The practice and discipline of architecture for software systems has come of age. You can be proud of joining a profession that has always strived, and is still striving, to be more disciplined, more reliable, more productive, and more efficient, to produce systems that improve the lives of their stakeholders.

With that thought, now it’s time for the cheery book-ending imperative: Go forth and architect great systems. Your predecessors have designed systems that have changed the world. It’s your turn.