| Continuous Architecture In Practice (Addison-Wesley) |
|
Author: Murat Erder, Pierre Pureur and Eoin Woods This book sets out the case for why software architecture is more important than ever, and in particular why continuous architecture is important. The introductory chapter of the book defines continuous architecture as being a way of bridging the gap between the agile developer (let's start building), and the enterprise architect (let's create a five-year plan). It then lays out the six principles that the authors say continuous architecture follows. 
These are to create products not projects; focus on quality attributes as well as functional requirements; delay design decisions till they're absolutely necessary; design for change and make use of the power of 'small'; design for more than just building the software; and model the organization of your teams on the system you are working on. The book sets out to show how those principles can be used in the design and implementation of software architecture, with examples organized around a case study of a fictional trade finance system called Trade Finance eXchange. Inattention at this stage did cause me some confusion later in the book as I was puzzled as to why the authors were so concerned with scalability for TensorFlow eXtended machine learning systems, aka TFX. Chapter 2 lays out the essential activities of software architecture in practice - quality attributes, common themes and technical debt - the way short term decisions can cause long term challenges. A chapter on data architecture comes next, in which the authors lay out their view that SQL is losing dominance to NoSQL and Polyglot. They also look at considerations including data ownership and metadata, and data integration. Security as an architectural concern is the next topic. The authors look at how to design for security, and architectural tactics for migration and for maintaining security. This chapter is typical for illustrating both the strengths and weaknesses of the book. The ideas covered are sound, but many of the headings look like you'd encounter them in a seminar you attend because your pointy headed boss tells you to - 'Moving Security from No to Yes', and 'Shifting Security Left'. Scalability as an architectural concern is covered in the next chapter, with sections on scalability requirements, database scalability and using asynchronous communications for scalability. Performance and resilience similar treatment, with the authors first laying out what they mean in an architectural context, then consider ways to design with that topic in mind. A chapter on emerging technologies and how they affect software architecture looks at artificial intelligence, machine learning and deep learning, and the book ends with a conclusions chapter looking at the key quality attributes - security, scalability, performance and resilience. I had mixed feelings about this book. There wasn't any advice I disagreed with, but I felt a lot of what was being said was pretty obvious. It is also expressed in a certain sort of motivational management-speak that your average C programmer would refer to as Zen twaddle (according to a small sample of available C programmers round the office). If you find statements such as 'Architect for change and leverage the "power of small"' inspiring, then this is a good book. If not, you need to read past the slogans to find the useful bits. To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.
|
|||
| Last Updated ( Friday, 07 October 2022 ) |