 |
| Image Source: Amazon.com |
Software Architecture for Busy Developers: Talk and act like a software architect in one weekend
https://www.amazon.com/Software-Architecture-Busy-Developers-architect/dp/1801071594/
- Publication Date: 2021-10-15
- 174 pages
Author: Stéphane Eyskens
- https://www.linkedin.com/in/stephane-eyskens/
- Senior Cloud & Cloud Native Architect (Azure MVP)
- Xpirit
- Amazon Author’s Page
- https://twitter.com/stephaneeyskens
- https://azure-quizzes.silver-it.com/
- https://stephaneeyskens.wordpress.com/
Companion Github repository for the book:
Review Headline: Far Too Ambitious
Link to my review:
- On Amazon: https://www.amazon.com/review/R2YZ7KSVE1HX2F/
- On LinkedIn:https://www.linkedin.com/posts/activity-6855433979785572352-vww6
Caveat: I was provided a PDF of this book by Packt to review.
(caution: Some tough love given)
General Impression:
This book could be much better. There are many mentions of frameworks, standards, tools, organizations – and yet, there is a dearth of links provided when they are *initially* mentioned – and for many, no link is provided.
Overall, the sequencing of information feels haphazard – and
does not weave a cohesive picture in the mind of the reader.[Note: Another reviewer on Amazon wrote: "...at times it feels like you are reading word-salad, with a bunch of software terminology smashed together in a section that doesn't tie together in the end for an `Architectural Design`"]
Additionally, the book leaves as an exercise for the reader – determining how the different architect roles work together.
Given the book’s actual content length (149 pages) – I feel it has tried to tackle too many topics, without sufficient depth in any of them.
The level of breadth attempted by this book – with such limited depth – may make the reader feel like they have purchased half-a-book, not a whole book.
It is difficult to determine what this book wants to be…it swerves and veers – covers some topics by barely a sentence – and spends pages discussing the details of other topics.
While the book recommends TOGAF, ITIL, and ArchiMate – in many organizations – these are rarely actually used – and if used, rarely result in actually being useful – rather, resulting in significant wasted cycles to establish and implement them – rarely producing equivalent value for the effort/cost expended.
After reading this book – and seeing the shallow treatment
of the material – I fear that the book’s goal of “Talk and act like a software
architect in one weekend” - is more likely to create more harm - than good.The proverb, "A little knowledge is a dangerous thing", comes to mind.
What I found Interesting:
The inclusion of a companion github repository for the book, with code examples.
Chapter-3’s coverage of the Architecture Tradeoff AnalysisMethod (ATAM)
Recommendation of the Sparx Enterprise Architect tool.
Chapter-5’s coverage of Design Patterns.
Chapter-6’s Figures 6.5 and 6.6 – illustrating the mapping
of Azure and AWS services to patterns.
Suggestions for the Next Edition:
Add a new chapter to discuss the relationship of software design patterns, within the context of application design patterns, DevOps patterns, enterprise integration patterns, as well as cloud architecture patterns. Illustrating the workflow of how architects at different layers – work together to deliver business value.
The acronym noted on page-7 (“SoAr”) for Solution Architect – is often abbreviated simply as “SA” in many organizations.
On page-9, the numbers used in the table for Figure 1.3 do not seem to tell a coherent story, as intended – with a progression from Data…to…Wisdom.
At the end of every chapter, there should be a final section, “Additional Reading”. For example, for Chapter-1: Provide inks to additional resources/materials (such as TOGAF, ArchiMate,UML, …)
The book should have an additional chapter – to discuss other architecture frameworks – besides heavyweight TOGAF – and the need for “Agile Architecture” – with examples cited. Additionally, the author should introduce resources for exploring some contrary perspectives and views on how architecture might be viewed (i.e., “The Practice of Enterprise Architecture - A Modern Approach to Business and IT Alignment”, by Svyatoslav Kotusev).
Chapter-2’s discussion of EA should include a discussion on the types of Governance activities that are core to the EA role.
As an example of the shallow level of coverage of a given topic, see Page-28 – which briefly mentions NIST – but does not cite any of the excellent NIST publications that would be of keen interest to any number of architect roles. Although the NIST Cyber Security Framework link is provided – there is no concrete example cited from it – of how it might be useful, or its applicability.
Chapter-4 mentions several different architecture styles on page-52 – but does not include a visual to help the reader understand them conceptually – nor is there any discussion of why one might choose one over the other.
Figures 4.1 and 4.2 do nothing to help the reader understand the concept of a software monolith. There are plenty of Open Source projects that could be used as examples (and, since Sparx EA supports importing the source code – and will automatically generate UML diagrams – that would be eminently more meaningful in communicating real-world examples).
Page-60 should include a discussion of the benefits of GraphQL style services (in the book, GraphQL is only mentioned in a single sentence, on page-133).
Page-62 should rephrase “Loss of complete oversight” to “Governance challenges”.
Page-64’s mention of “providing some sort of consistency across the different microservices” – begs the question – and seems like only a partially formed thought.
Page-64’s comment regarding the future of Dapr should be elaborated – and supported by cogent citation of rationale reasons. A table, comparing it to other options – would greatly improve this section’s discussion.
Add a section in Chapter-7 to discuss the continuing rise in the adoption of Low-Code and No-Code platforms – and how they can be leveraged to accelerate the delivery of solutions in the software architecture landscape.
Table of Contents:
- Chapter-1: Introducing Software Architecture
- Chapter-2: Exploring Architecture Frameworks and Methodologies
- Chapter-3: Understanding ATAM and the Software Quality Attributes
- Chapter-4: Reviewing the Historical Architecture Style
- Chapter-5: Design Patterns and Clean Architecture
- Chapter-6: Impact of the Cloud on the Software Architecture Practice
- Chapter-7: Trendy Architectures and Global Summary
No comments:
Post a Comment