A handful of publications, some initially published in my early career, have significantly shaped my approach to solution and enterprise 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.
Several of them are also extremely relevant for people in related professions, like project mangers, developers, test managers, product owners etc.
The Rational Unified Process is in my opinion the only sensible software development process ever conceived. It’s carefully engineered to overcome all the drawbacks of the catastrophically poor waterfall approach, and it offers guidelines and templates for all professions involved in the collaborative effort required to design, build and implement complex software systems in any business.
Grew out of the 90’s, it gathers all the still widely recognized best practices, but unfortunately lost its footing in the mid-20’s. Still commercially available from IBM, but I don’t know anyone who’s still using it in their business.
So why mention it? Because using it, after helping big organizations adopt it in the 90’s, teaching it to their employees, and practicing in my own work ever since, I haven’t seen any better alternatives.
Everyone is rushing to adopt SAFe, which I generally applaud – but SAFe just dones’t offer any guidance on the actual engineering aspects of building complex software. SAFe suggests how to organize and manage the work, but not how each profession should actually carry out their technical tasks.
RUP is only available under commercial license from IBM, but they have at least published all the document templates. If you’re interested in an introduction to RUP, read their white paper Rational Unified Process, Best Practices for Software Development Teams.
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, and bought new copies!
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 see as 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.
This was the first book about software design I ever acquired. It came out in 1993 at a time where 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.
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.
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.
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.
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.
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.
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.