A handful of publications, some first published in my early career, have significantly shaped my approach to architecture.
In this post, I’d like to tell you why and how – hoping you might become inspired to read some or all of them yourself.
While I find them extremely worthwhile for architects, several of them are also very helpful to people in adjacent disciplines like project managers, developers, test managers, product owners etc.
However, let me first start with the earliest literature about architecture, De architectura, written by the Roman architect Vitruvius in the early 1st century AD. He wisely proclaimed that architecture should satisfy the three principles of firmitas, utilitas, venustas, which translate to:
- Solid
IT systems must be designed to be robust. Focusing on like security, integrity, non-repudiation, concurrency, capacity, performance, scalability, availability and recoverability all contribute to designing a solid solution.
- Useful
IT systems must provide exactly the necessary functionality needed to enable efficient and value-adding processes. This is best accomplished by methodical business analysis based on an understanding of the business model and resulting in process specifications and use case specifications.
- Elegant
IT systems must be assembled from well-devised components based on wise design principles, leading to a high-level design that is easy to understand, build and document.
Being particularly keen on documenting architecture, I also strive to meet these three criteria in my documentation.
The Rational Unified Process: An Introduction (3rd Edition)
by Philippe Kruchten
The Rational Unified Process (RUP) is in my opinion the only sensible software development process ever conceived. It’s carefully engineered to overcome all the drawbacks of the catastrophically unrealistic waterfall approach, and it offers guidelines and templates for all disciplines involved in the collaborative effort to design, build and implement complex software systems.
RUP grew out of the 90’s and was adopted by many large organizations, but unfortunately RUP lost its footing after IBM acquired Rational and made RUP an expensively licensed product.
While RUP prescribed solid software engineering practices, it took documentation too far (for example suggesting that a project should even document its tailoring of RUP itself), leaving the playing field wide open to the agile movement, which prefers code over documentation.
While I certainly agree that developers should write code rather than documents, agile doesn’t mean the no documentation should be created at all, just that it should be left to business analysts and architects.
The Process of Software Architecting
by Peter Eeles and Peter Cripps
This is the book I most often recommend to project managers who show an interest in learning more about the solution architect role. Back when books were still printed, I actually gave several copies away to project managers.
In addition to describing the architect’s process really well, it also explains the importance of first developing good requirements, which of course is the primary input to the architecting work.
The book also gives good advice on how to properly document the architecture, which is something I consider fundamental for maintaining the solution long-term.
One of the authors, Peter Cripps, also blogs about architecture over at Software Architecture Zen, which I highly recommend visiting.
Object-Oriented Analysis and Design with Applications (3rd Edition)
by Grady Booch, Robert A. Maksimchuk, Michael W. Engle, Bobbi J. Young, Jim Conallen and Kelli A. Houston
This was the first book about software design I ever acquired. It came out in 1993 at a time when I was keen to better understand the principles of object-oriented design – I actually started toying with object-oriented programming in C++ before I fully understand OO concepts.
I still adhere to the fundamental design principles thoroughly explained in this book, and it still helps me build solid software that is easy to operate and maintain.
While the book naturally focuses on utilizing object-oriented programming techniques in the design and coding of a single application, the same design principles can be applied on a larger scale when designing a distributed service-oriented architecture across an entire enterprise.
Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives (2nd Edition)
by Nick Rozanski and Eóin Woods
RUP was the first standard I came across to offer a comprehensive selection of document templates, including a template for the solution architecture document.
Both RUP and many other published works favor the so-called 4+1 views for conveying the architecture. Two of these views are the logical and physical views, which don’t make sense to me, because I don’t understand which exact concerns they are supposed to address.
This book introduces a practical set of views that each address various stakeholders’ concerns more appropriately. My own preferred template for documenting solution architecture is heavily inspired by this book and RUP.
I highly recommend that you visit Nick’s and Eoin’s website to explorer their ideas about viewpoints and perspectives.
Clean Architecture: A Craftsman’s Guide to Software Structure and Design
by Robert C. Martin
This book thoroughly explains key concepts of elegant and maintainable architecture, specifically the SOLID principles.
The obvious audience is architects and lead designers but I have also recommended it to a few project managers who have shown interest in understanding the rationale behind some of my design choices that sometimes collide with what they hear from other projects in their organization (either run without an architect or with one who hasn’t read this book).
Be sure to also visit the author’s blog, The Clean Coder Blog.
Clean Agile: Back to Basics
by Robert C. Martin
Agile is perhaps the most misunderstood idea in modern time. Everyone I work with in projects call everything agile.
To them, agile means no planning, no engineering, no testing, no business analysis, no requirements specification – you just run a series of workshops that scratch the surface of an idea, and then ask different teams to start building various components.
Everyone, regardless of their role in a project or line management, should read this book.
Be sure to also visit the author’s blog, The Clean Coder Blog.
How to Measure Anything: Finding the Value of Intangibles in Business
by Douglas W. Hubbard
I found this book when trying to learn more about how to develop solid business cases. After 35 years in the business I have at most been in perhaps three projects that were actually based on a business case. Either no one asks for it, or they’re convinced it’s redundant because “it’s a compliance project”, or they just don’t know how to develop a business case.
This books teaches you how to measure everything, which is the prerequisite for developing a proper business case. As an architect, I build on that to derive the KPIs, which in turn tells me which metrics my software design needs to gather and store to support monitoring the KPIs.
So, this is why this book is also relevant to architects – generating metrics requires functionality and technology, and has a significant impact on our architecture.
In my current project, half the code we’ve written gathers and emits metrics, which no-one (from the ‘business’ asked for), but is essential to measure the solution’s performance and capacity in relation to the corresponding design goals.
Use-Case 2.0
by Dr. Ivar Jacobson, Ian Spence and Kurt Bittner
Unfortunately, user stories have replaced use cases in ‘agile’ development – probably because people are too lazy to learn how to write use cases.
This guide offers a really smart way of using user stories to cover slices of more comprehensive and formal use case specifications as a way of controlling which parts are implemented in which iteration of a project.
OpenUP
by the Eclipse Process Framework Project (closed in 2023).
With RUP being ‘locked away’ under IBM’s commercial license I suggest you browse the open-source and more lightweight OpenUP.
Browse it online or download and browse it locally. And the method authoring tool, which has been used to develop it is also available. So, you can tailor and publish your customized development process, integrating it with whatever else you already have in place – including branding the document templated to align them with your organization’s graphical profile.
The Difficult Process of Identifying Processes
by Fred Nickols
In this brilliant article, Fred Nickols describes a very practical approach to the otherwise very mystical challenge of identifying processes.
In short, he reminds us that processes are of course sequences of activities, and suggest meaningful criteria for identifying boundaries, which help us decide when one activity should be the last in one process and the next activity should be the first in another process.
Modern Software Engineering
by David Farley
David makes a solid argument for injecting solid engineering practices into development process, which is alarmingly ignores by popular so-called agile frameworks like SAFe.
Key practices described are:
- Work iteratively
- Establish and utilize feedback
- Work incrementally
- Experiment
- Be empirical
- Favor modularity
- Ensure cohesion
- Separate concerns
- Hide information
- Favor loose coupling
Some of these practices trace back to the original agile manifesto and long-forgotten processes like RUP. It’s easy to think they should primarily be applied in code design, but I feel many of these practices can be elevated to the highest levels of enterprise architecture as well.
Fundamentals of Software Architecture
by Mark Richards & Neal Ford
I’m currently reading it…