Beautiful Architecture - First 4 Chapters

I am new to blogging, so I thought I would wait for a week to watch and learn and also do little experiment of seeing how much I can learn just by reading all your blogs. So I did. I was able to grasp first 4 chapters of Beautiful Architecture (by Diomidis Spinellis & Georgios Gousios) by just reading your blogs. I started reading actual book this week. Here is my take on it –

Introduction of the Beautiful Architecture:

This book is compilation of papers written by other authors but each of these chapters has nice co-ordination with others. This book describes different architectures like Enterprise Application Architecture, Resource – Oriented Architecture, End-User Application Architectures etc. Looks like this is a good book suggestion to software Architects who like to read! (I will give my full review at the end of this semesterJ)

Chapter 1: What is Architecture

What is Architecture? Well, definition may depend on what field are we talking about. But besides the any differences, there are many items that are common among the different disciplines. Particularly, architecture can help build the system that meets the needs of its stakeholders, and it can help to manage the complexity of system that needs to be build, planning, building, and maintaining the system. Architecture helps to assure that the building, bridge, or system has the desired properties and behaviors, when it has been built.
Architecture helps teams to focus on functional and non-functional requirements and keeps all on the same page with respect to the system’s building and provides a conceptual integrity of the system.
Principles gathered from “Foreword” by Stephen J. Mellor –
These are universal principles which make an architect beautiful.

One fact in one place: avoid duplicity; common functionality should be factored out into separated modules. Be aware of changes.

Automatic propagation: maintain consistency and correctness; propagation must be carried out automatically at construction time.

Architecture includes construction: architecture must include not only the runtime system but also how it is constructed.

Minimize mechanisms: less code to write, verify, maintain and occupy memory.
Construct engines: extensible systems rely on the construction of engines that are “programmed” by data provided by higher layers and that implement multiple application functions at a time.

O(G), the order of growth: consider the direction of likely growth and account for it.
Resist entropy: beautiful architecture are preserved over time. Changes will be consistent with it and not increase system entropy.

Whenever we are evaluating or designing architecture we should consider these principles to tell if the architecture in question is beautiful or not.

Chapter 2: A Tale of 2 systems

Author presents 2 software systems like a city. One is called Messy Metropolis which is not build based on any structure or order as name says very messy one. Other one is called design town which is structured very carefully.
I feel like this chapter showed extremes of both good and bad systems. But none the less, I also have seen similar to messy metropolis style and design town style. In my view, A system will end up as a Messy metropolis style if it is build to save the money or to meet aggressive dead line or let novice developers develop the system (believe or not , these days, In a software development teams software engineers are out numbered to others). There is this other category where legacy systems started long back as small project and with those old software platforms, but have grown over the years into messy systems. I agree with the author that it was very brave for the organization to take the step of rewriting the application.
Design town system shows how little efforts of planning and foreseeing the system in the long run help to build a beautiful system. The author mentioned great points to consider for making a good architecture. This is very important and useful when building a new system.

Chapter 3: Architecting for Scale

So far in my career, I mostly developed enterprise applications, this chapter is very interesting one for me. It talks about flexibility in scaling the system according to current and future needs. Nice reading of the chapter, find few contradiction with respect to Latency but can’t really comment on it. Gaming is not my schedule in near or far future…

Chapter 4: Making Memories

This chapter talks about the architecture used for photography labs, where pictures are taken in a studio, enhanced and ordered at the studio. They are then sent to a processing center where they are rendered and printed, then sent back to the studio for pickup by the customer.
In designing the new software, the architects solved many problems, including concurrency issues at the studios, compiling the software, making the GUI easy to use and making the most use of the bottleneck - the rendering pipeline. They also recognized the need to make everything easy to upgrade since there are hundreds of distributed sites.
Most of the ideas presented in this chapter like incremental design, code reviews, unit testing etc. seems to be very common to me but reminded me to keep learning them and applying them while I develop applications.