Book Review: Principles of Software Architecture Modernization

 One of the more interesting reads in the Software Architecture space right now is Diego Pacheco's and Sam Sgro's 'Principles of Software Architecture Modernization' (published by BPB Publications December 2023).

After introducing some foundational concepts of distributed software architectures, the book dives into a particularly interesting topic: "The Distributed Monolith." This term describes an anti-pattern in architectures attempting micro-services where the functionality is neither isolated nor modular enough to realize the benefits of decomposed micro-services. The idea was popularized by Ben Christensen (author of Hystrix) in his talk, "Don't Build a Distributed Monolith." At its core, the concept highlights a common misconception: distributing a monolithic system will resolve its inherent complexity. In reality, without proper abstractions, boundaries and separation of concerns, complexity not only persists but worsens in a distributed system. Modularity cannot be magically achieved—it requires skill, whether systems are co-located or distributed. This is something I completely agree with. It's both tragic and unfortunate as it is difficult to objectively measure how modular or coupled your system is and is something that just requires a well trained eye.

Sgro and Pacheco identify three key traits of a poorly designed system:

1. Lack of Isolation: Is there excessive sharing of libraries?

2. Lack of Independence: Can components evolve independently?

3. Distributed Complexity: Is there a lack of stable contracts and a clear separation of concerns?

However, the book argues, unless it's a very small company maintaining these principles with an Architect as "design and quality gatekeeper" just doesn't scale. That's certainly on the money. Instead, Pacheco and Sgro suggest that engineers should be "educated with the right principles". This is also on the money. As bringing engineers into the technical vision helps them creates a sense of collaboration and helps them feel more empowered. However, it also relies on engineers being good citizens and shouting for help when it is needed. That part can be easier said than done.

There is a whistle stop tour of many things hot in software right now: AWS Cloud, Sidecars, Container Orchestration, Service Meshes and Chaos engineering. Depending on your background some of it you will know, some of it will be a refresher and some of it will be new.

There are also flying visits to many software tenets that are longer established: Reuse vs. Duplication, Dependency Management, Build vs. Buy, Rewrite vs. Refactor, Backward Compatibility, SOA, Test Pyramid

No good book on Software Architecture is without a tidbit or two on technical debt. The analogy of flavours is used to describe slightly different versions of the same thing which tends to happen in larger code bases without sufficient governance. While the need to do something slightly different (or better) may be valid a better approach is described with another analogy: build another bridge. Imagine a bridge connected two parts of a city. As the population grows, at some point, the bridge won't be big enough anymore. But, don't shut it down. Instead, build one in parallel and gradually move traffic over to the new (the idea sounds very much like parallel contracts, or expand / contract). Key is that a flavour is an unfinished bridge. Instead of the gradual migration, things that are similar just proliferate and become impossible to govern. Yeah, full disclaimer: I've seen that too many times.

One excellent point is regarding embracing new technology: Don't do so without good principles. That seems to be a very common problem. Adopting Spring Boot & Docker led a lot of people to believe that building micro-services is going to be easy - sure doesn't Spring and Docker give you all the principles you need? By the way if you want to have a good laugh on that point, I recommend having a look at David Schmitz hilarious talk: 10 Tips for Failing at microservices

There are several industry anecdotes mentioned which I didn't know and found interesting:

• StackOverflow is a data center-hosted monolith on 9 servers and serves 2B+ monthly page views. They even removed their Redis caching layer without degradation

• Uber reported 5 - 10% overhead by running Cassandra on Containers

• LinkedIn migrated its REST APIs from JSON to Protocol Buffers resulting in a 60% latency reduction and an 8% improvement in resource utilisation

The recurring theme in the book is that things can be more complicated than they appear. Watch out for anti-patterns as much as you watch out for good patterns with many many tips to help you master that complexity and build a great architecture.

Overall, 'Principles of Software Architecture' is probably broader than it is deeper. The breath of topics covered is very impressive and that's why I would recommend this book. Usually Software Architecture books are a little narrower but go deeper into one aspect of Software Architecture. For example, Domain Driven Design is more about abstracting and decomposing, 50 Rules of Scalability focuses heavily on one NFR and Designing Intensive Database Applications is heavily focused on Persistence. Principles of Software Architecture's wider coverage ensures there's something valuable for nearly everyone—whether you're looking to learn something new or simply refresh your knowledge.

Book Review: RESTful Web Clients

RESTful Web Clients is written by guru Mike Amundsen who amongst other things co-authored RESTful Web APIs with REST guru Leonard Richardson and Sam Ruby.

The book's primary focus is on the hypermedia aspect of REST, particularly from the client's perspective.   As Roy Fielding detailed in this famous blog post "if the engine of application state (and hence the API) is not being driven by hypertext, then it cannot be RESTful and cannot be a REST API"  and let's face it, we have all seen APIs purporting to be REST with no hypermedia whatsoever with lots of coupling between client and server.  Some of this is just down to basic ignorance and some of it probably down to misunderstanding the Richardson Maturity Model

Rather than begin with a summary of Fielding's dissertation like most material on REST, this book  begins with details of a simple web application that uses JSON RPC APIs.  From the simple example Amundsen shows that while the JSON RPC approach functionally works, it results in a lot of coupling between client and server meaning that if the APIs need to change it will be difficult to do that easily as the client(s) with all its hardcoded of contracts will be impacted.  And we know software does need to change from time to time right?

Amundsen distills the coupling with the JSON RPC approach into three distinct types which can be considered and assessed individually:

• Objects - the JSON objects that appear in API responses.  Clients need to be able to understand them to handle a simple a response to a GET request
• Addresses - the URLs clients needs to know to invoke requests
• Actions  - details methods and arguments for all non-trivial operations. Again clients need to know this before invoking requests.  

With the coupling clearly demonstrated, the scene is nicely set to move onto one of key advantages of a REST style archictecture: reducing coupling through hypermedia.

To explain this advantage, Amundsen again uses the approach of specific examples.  Firstly, by detailing the  JSON hypermedia type HAL.   Using this approach reduces the Address coupling and examples of how generic response handling can be written on the client to leverage and take advantage of this decoupling are detailed.  However HAL doesn't solve everything.  Without a custom extension there is still coupling to the JSON Objects and the possible Actions available to the client.  A work around to this is given and I would highly recommend anyone considering using HAL to read Chapter 4.

Next up is another JSON hypermedia type known as Siren.  Kevin Swiber designed Siren and registered it with IANA in 2012.

Siren splits response entities into:

• class  - this is an array, the values of which indicate what the current resource represents e.g. Customer, Person
• properties - set of name-value pairs
• entities - a list of linked and representational sub entities
• actions - contains a set of valid operations of the associated entity and how to invoke those operations including a list of fields which match HTML5 input types (hidden, text, number).  This is something not in HAL that helps reduce client-server coupling further
• links - links to other resources.  Each link has a class, href, rel, title, type property

Siren  reduces coupling to Addresses and Actions, however it does not reduce coupling to Objects.  There is no meta-data specification for the class type meaning the client has to hardcode the structure of the object somewhere.   Like HAL it is possible to create a custom extension but this is not part of the Siren specification.

The third hypermedia type detailed is Collection+JSON format (Cj). Interestingly, this format was designed by the author himself.    The basic elements of a Cj message are:

• Links - Simlar to HAL and Siren links
• Items - Similar to HAL and Siren properties and also includes meta data about the properties
• Queries - Information on how to construct various reads (HTTP GETs)
• Templates - Information on how to construct various writes (HTTP POSTs, PUTs, DELETEs...)
• error - information ref errors

The key point here is that since Cj includes the metadata about the items, it decouples the client from the Objects in the JSON responses something both HAL and Siren could only achieve with custom extensions.

So which format? Well two good points to make here:

1. That can be a practical decision and not just a technical one.  You may prefer Cj because out of the box it achieves most decoupling, but your customer may be used to and prefer HAL.
2. Rather than trying to support every possible format, think about architecting so it possible to support extra formats if you need to.  The approach suggested is described in the Amundsen's Representor pattern - which is inspired from the Message Translator  Pattern

So in summary, this is another great REST book from O'Reilly.  The style of the book in general is pragmatic rather than academic.  It really emphasizes and demostrates the importance of hypermedia in REST APIs and is backed up with practical examples.  The central argument in the book is that Cj achieves the most decoupling.  Even if it was written by the author, the argument is well made and I don't think it would be fair to make accusations of any selection bias since he does detail how you can extend Siren and HAL to achieve the same level of decoupling.

Bottom line - if you want to understand the hypermedia aspects of REST, read this book.

Book Review: Building Microservices

The architectural idea of microservices was inspired - in part - by Unix's philosophy of code being short, simple, clear, modular, extendable and that it could be repurposed by developers. The term is currently up there with Internet of Things, Big Data and the Cloud, in contemporary technical lexicon.

Author Sam Newman is an industry expert on the subject. He has:
written for Infoq, presented at Javazone and various other events regarding microservices.

His book 'Building Microservices' does an excellent job introducing the key concepts of microservices:

• services are autonomous, live on their machines
• resilience - one service fails, it doesn't impact other services
• scaling - because services are independent they can be independently scaled
• deployment - deployment should be easy. A change to a service means that's all that's deployed.

It is worth pointing out it isn't just a book about microservices. Many of the ideas and best practises detailed (for example HATOES in your ReST approach and to check OWASP for security references) are equally applicable to non - microservices architectures. But, that said, what I really like about this book is anytime a general architectural or software engineer concept (and there are a lot) is explained it is explained very well.  Some examples:

• Reactive extensions (running operations as a result of multiple calls not caring if they were blocking / non blocking. For ref: see here and here). 
• Catastrophic Failover 
• Postel's law 
• Tolerant Readers 

There are - of course - many tips regarding how you approach microservices. For example:

• Don't get too hung up on DRY. It may make it harder to keep your services independent.
• Consider using CDC's for your testing approach
• Canary releasing / Blue, Green testing for releasing.
• Using bulkhead and circuit breaker patterns to make services ore resilient.

As an overview to microservices, it's a great book. However, the reader must bear in mind there is no one size fits all approach to microservices. The finer details will depend on your project, your team and even a bit of trial and error. It's difficult to critique this book. So instead, I'll just flag some concerns not about the actual book but about microservices in general and how the industry and developers are reacting to them.

My first concern with microservices is more a practical than a technical one. Doing modular design for everything from your schema, service layer, end points, configuration isn't as easy as some people might think. Especially in teams of varied skill level, varied backgrounds and inevitable commercial pressure that happens in every project. It requires a lot of technical aptitude, leadership and discipline. If a project is not good at achieving modular design in a monolith - for whatever reason - I think it will really struggle at modular design in microservices when the complexity of the network has to be also considered.

The second concern I'd have is that when explaining the principle ideas of microservices, it is often compared with a monolith to the point the word monolith is a pejorative term.  The two approaches: monolith and microservices are presented as if it's either one or the other.  I think this a false dichotomy fallacy. There are other approaches available.

Thirdly, microservices are no doubt,  a clever idea.  But that doesn't mean there are a panacea. In some projects they will be a good fit, in others they will not be worth it. One obvious factor to bear in mind is your non-functional requirements.  One useful point of reference,  that is worth considering is the project James Lewis (another Thoughtworks guru) described in his talk about microservices in 2012.  In this presentation, three non-functional requirements for the project caught my attention:

• One component had to handle 1,000 TPS
• Another had to support a user base of 100 million users
• Another had to support batch loads of 30 - 90 million records

While I am not saying you should be in this ballpark before considering microservices, I am just trying to suggest that most projects don't have these sort of demands and there's a lot of merit of considering something like a very well structured modular monolith first using DDD principles and then to migrate towards microservices should the benefits justify it. This strategy is well explained by Martin Fowler in his Monolith first article.

Some other references:

• Microservices Anti-Patterns
• Martin Fowler, Microservices
• James Lewis microservices talk at Infoq 
• James Lewis microservices Software Engineering Radio podcast
• James Lewis 33 Degree conference http://2012.33degree.org/talk/show/67

Until the next time enjoy yourselves.

Book Review: Cloud Based Architectures

Migrating to Cloud-Native Application Architectures, Matt Stine.

In the last few years, it can be very easy to believe marketing departments simply aren’t paid unless they use the word "Cloud" as often as possible.  Its usage has become so ubiquitous that is has inevitably become ambiguous so one very astute thing author Matt Stine does is outline what he means by "Cloud" (in particular cloud architectures) in the opening pages of this book.  Essentially, cloud architectures can be summarised by the three S’s. 

• Speed: ability to provision and release resources (computing, networking and storage) with ease thereby achieving faster project development time
• Safety: making software architectures more resilient (fault tolerance, fault isolation etc) 
• Scalability: One the many non-functional characteristics that has become even more important with proliferation of mobile computing.  More mobile devices mean more application usage mean more back ends APIs getting hit.  Architectures must be able to respond to this demand otherwise applications fail. 

Twelve Factor App

Throughout the book approaches and patterns for achieving cloud based architectures are introduced. Now, if you have worked on anything distributed which was well architected, you will definitely experience a little bit of deja vu.  For example, the Twelve Factor App is a collection of patterns developed by engineers at Heroku containing twelve (you guessed it) principles to guide a good architecture fit for cloud.  You are sure to have used codebase (make deployable units have their own code base), dependencies (use proper tooling for managing dependencies), config (externalise configuration), backing services (databases, caches etc should be consumed identically by all resources) before but patterns are supposed to be common solutions to common problems and good architecture is good architecture, so it is not unexpected some of the described approaches won’t always sound completely new. 

Microservices

How do Microservices help enable the 3 S’s?

• Speed: Deployment is much simpler and faster with independent code chunks.
• Security: Not too much here, but it is fairly intuitive that if you break something large into small chunks it is much easier to access control sensitive parts. 
• Scale:  Much easier to only have to scale the parts of an architecture you need to scale as opposed to having to scale the entire architecture - which is what happens in a Monolithic application.

Cloud Migration

For organisations to move to Cloud based architectures, several changes are needed:

• DevOps rather than Silos: this is to facilitate speed of delivery.
• Continuous Delivery:  one way to be to sure the problems of long release cycles are guaranteed to be avoided 
• Decentralise autonomy:  yes, it is a nice idea to give everyone more power and influence. It will certainly speed things up. But, in my own view some things (core APIs, major technical architectural decisions) should only be handled by people of a certain technical background who are prepared to be fully accountable for them.  Would you let every person working on the design of a bridge or in a heart transplant have the exact same say? 
• Inverse conway manoeuvre: Software companies should do their architecture first and then re-align their organisations to fit that so that they avoid the anti-pattern of making architectures to resemble an existing organisational structure.   This sounds nice in theory but it may not be so easy to achieve (possibly easier to do in very small companies that never have a strict organisational structure anyway).

Break up the Monolith

So if you have bought into the cloud based approach and since it’s unlikely your project is green field, you need to figure out how to break up the Monolith.  Some ideas include:

• Bounded Contexts: This allows inconsistent definitions of concepts as long as they are consistent inside a well defined context which makes it much easier to decompose data models. For example, in the Security context a User may always refer to something that can be authenticated and has particular roles but in a Management context it would be something that has an image, an address and some application capabilities (checking out a shopping cart).
• Identifying bounded contexts in the monolith and making them micro services.
• Containerisation: Using something like Docker can provide many advantages to using VM's
• Writing new features as micro services
• Making the Monolith look like micro services by using anti-corruption layers

Spring cloud and Netflix

By the sounds of it Spring cloud's and the Netflix OSS project sound like an absolute must to checkout. Amongst other things, they help:

• Achieve dynamic configuration
• Implement sophisticated service discovery
• provide alternative to load balancing which involve client side more.  

In addition, Netflix's Hystrix library (which provides some very useful metrices) employs some clever fault tolerance patterns:

• circuit breakers - if a system notices that another system is broken it stops calling it.
• bulkheads -  failure is limited by strict partitioning

Any negatives?

So lots of positives about this book.  Plenty of well explained information in a short number of pages. That is a major achievement.   I have alluded to a few minor points above, but they are very minor.  It would be very difficult to criticise this book in any substantial manner especially when it is free.    

However, it is important for the reader to bear a few considerations.

• Business realities: Approaches such as Continuous Delivery just may not fit your business plan.  Why would you want to provide a feature someone hasn’t paid for?  (In fairness, the author does make this very point, but it really is worth re-iterating)
• Technical realities:  One problem I have with many software approaches is that they assume that everyone is at a given skill level. In an ideal world the only people who work in software engineering would be very good engineers but the reality is there is always a very wide range of skill levels on any project.  From super meticulous to complete spoofers.  This means that some things that can sound very elegant in theory but a lot more difficult to achieve in practise.  When considering moving to things like DevOps, there will definitely be benefits. But are organisations going to find it easier or harder to make engineers accountable? I would imagine there would be serious risks of it being latter if it is not properly thought through.
• Some concepts e.g. Client Side load balancing sound very interesting. But, they are only introduced rather than critically analysed.  Much more research and thought would be required (for me anyway) before considering adopting.  

Book Review: REST API Design Rulebook (Mark Masse)

RESTful style architectures are becoming more and more ubiquitous. There are many reasons for this:

• Web Tiers are full of JavaScript yearning to make nice simple AJAX requests
• The obvious shortcomings of SOAP style strong contracts 
• They are a nice alternative to ESB's for integrating heterogeneous architectures

However, like the MVC design pattern or the Agile Software Methodology, while many projects may be claiming to be using the RESTful architectural approach everyone is doing it differently.

In 2010, Martin Fowler - in his excellent blog - discussed the Richardson Maturity Model. This model provided a very good categorisation technique to assess the degree of RESTfullness based on how many core REST principles were being used.  Although, that same model gets a reference in Mark Masse's REST API Design Rulebook, Masse's book goes much more into low level detail about various REST best practises.

For example:

• Negative caching: adding cache headers not just for positive responses but to 3xx and 4xx responses.  This is something that may not be obvious, but could be a good performance / scalability boost depending on the nature of your application and user usage patterns etc.
• How to version your URIs, your representational forms and your resource objects
• Using a consistent forms to represent link relations 

In addition, there is a abundance of other ideas and guidelines, some pretty simple but nonetheless important:

• Don't end URI's with a slash
• Don't use underscores in URI paths
• Put "api" in the domain part of your rest resource path, e.g. 

https://api.dropbox.com/1/oauth/request_token

The main reason why I think it is good to have a book like this is because when a development team are trying to use a REST style architecture, disagreements, misunderstanding will inevitably happen. For example, the proverbial: 'Should a URI end in a plural or singular noun?'
It is always good to be able to reference a respected industry resource to prevent rabbit holes appearing and eating into your valuable project time.

Furthermore, there are some really quick and easy things you can do to make a much a better REST API that are discussed in the book. For example:

• Adding an ETag HTTP header to that shopping cart resource as items go in and out of it.
• Using query fields to generate partial responses and using the ! for an excludes option.

Now for some constructive criticism.  Firstly, I don't there will ever be complete consistency in REST approaches. Some of the so called best practises could be argued to be just subjective or nice-to-haves. They are not something that are going to make a big difference to either functional or non-functional aspects of your architecture. Some of the industry leaders not only take different approaches in their REST APIs, but they are also sometimes doing the opposite of what Massé suggests. For example, Massé suggests not to include a file extension type in your REST URLs (see Chapter 2), but  (at the time of writing) Twitter do just that (the URI is: https://api.twitter.com/1.1/statuses/mentions_timeline.json)

Furthermore, in a lot of projects you will be writing a REST API purely to serve JSON back to a Web client.   This is quite different to a public facing API on the scale of Twitter, Amazon etc.   Therefore you need to ask yourself if you really need to put the time investment in so that you are adhering to every single REST best practise instead of just doing what makes sense for your project.  Some obviously make sense, some could be argued to be overkill. For example making sure you are sending back the correct HTTP code when you know the client never even checks if it is a 403 or 405.

I do think this book is written more as if you were designing a public facing API.  If you find yourself in that situation you should definitely, definitely, definitely be considering everything Massé is saying in the book.  But note, the emphasis is on considering which doesn't always mean adhering or adopting.

The book does a very good job in covering best practises that a lot of developers just wouldn't think of (setting response headers such as content-length, setting the location header in responses for newly created resources, how to support HTTP 1.0 when you are trying to discourage caching) and is definitely worth a read but you really have to think about what makes sense for your project. As stated, some of the suggestions are quick wins others you have to assess the cost and the benefit. Following the core basic REST principles (statelessness, a good resource model, uniform interface etc.) is what is really important after that the challenge is figuring out what works best for each specific project and how to make the most of your time. That will vary from project to project and will depend on project scope, scale etc.   A good architectural decision should always consider the various options but make the appropriate decision for the appropriate project.

Until the next time, take care of yourselves.

Book Review: Beginning Scala (David Pollak)

Firstly, sorry it has been so long since last blog post.  Life is busy when you have two children.  I decided to try and learn Scala in 2013 and I am currently still pluggin' away.  This blog post is a review of David Pollack's Beginning Scala.

David Pollack has been writing software since 1977.  He wrote diagnostic software for the Commodore 64, the first real-time spreadsheet and founded the Lift Web Framework in 2007.   He describes his experience with Scala as an epiphany that changed the way he approach software; he certainly writes with enthusiasm and passion and in this book we even get a forward from the Godfather himself Martin Odersky.

'Beginning Scala' focusses very much on the core fundamentals of Scala.  The book in length is just under 300 pages. This is quite short in comparison to say Martin Odersky's excellent 'Programming in Scala' which is well over twice the length.  Where I see the sweet spot for Beginning Scala is for someone who wants to dip their toe into the water and is curious about the language feels and wants to get a good overview of the language quickly.  For more a detailed and substantial take on the language something like Odersky's book is necessary.

Areas covered include:

• Scala traits and Scala's type system
• Call-by-name
• Scala collections and their immutable nature
• Functional characteristics (passing functions, returning functions)
• Pattern matching
• Actors and concurrency

There are also some tips on how to introduce Scala to your team and some best practise advice.  My favourite parts were the explanation of Scala traits and the demonstration of the classic GoF Visitor Pattern made so simple using pattern matching (I'll cover this in a separate post). The one criticism I'd have is that I think what really sets Scala apart from Java is not that has lots of syntactic sugar but that it offers a functional programming approach.  This doesn't just mean you can pass functions to function, return them functions and so on but that you have to approach problems in a very different way.  In functional programming recursion is favoured over iteration.   There are many problems that developers could solve using iteration with one arm tied behind their back but to solve them using recursion is trickier.  One of Scala's features is that it facilitates both approaches but I think if you are going to embrace the functional paradigm properly you need to ditch iteration and embrace recursion.  This isn't really covered in the book - in fairness it is not really covered in detail Odersky's book either. However, if you look at the Scala course on coursera it is a massive massive massive massive massive massive massive massive part of it.

So overall, a very good book and well worth a dabble for someone that wants a dabble in Scala but if you want more you'll need more.

Book Review: Even Faster Websites (Steve Souders)

Author Steve Souders (Head Performance Engineer at Google, previously Chief Performance at Yahoo) grew to fame with the YSlow Firefox plugin - a super little gizmo which gave web developers all sorts of ideas for how to speed up their web sites. The book 'High Performance Web Sites: Essential Knowledge for Front-End Engineers book' elaborated on everything the YSlow plugin was telling you. That book effectively serves a forerunner to 'Even Faster Web Sites'. In fact there is an assumption the reader has already read it, is already familiar with all the points it made and is now prepared to dig deeper.  Anyone with an interest in performance is in for a treat with this little gem.



I thought 'Even Faster Web Sites' detailed many clever techiques to boost performance. Amongst some of my favourites:

Steve Sounders

• Create a <script> element and set its src attribute to a JavaScript file you want to download asychronously.
• Use the script onload's event - which will only be called when the script has finished downloading - to avoid race conditions.
• Succint explainations on how deep scope chains in JavaScript can degrade performance
• Tips on when to use if statements, switch statements and arrays for flow control.
• A good overview of the Comet Architectural approach and how it can be achieved.
• Domain sharding tips: split based on resource type e.g put CSS and images on one domain, everything else on another domain.

There are also timely reminders, including:

• That IFrames make it easy for the UserAgent to print part of a page and are a mechanism to split part of your document giving it independent characteristics.
• IFrames are more expensive to download.
• That a browser's busy indicator stops once the Window.onLoad event is fired.
• Some browsers have limits on how long the JavaScript engine can run
• Web proxies and security software can mangle the Accept-Encoding header of request so that they speed up their screening of the response from the web server in a process Souders refers to as Turle Tapping.
• Browsers enforce their maximum connections per server rule based on the hostname in the URL not the IP address it resolves to.
• That CSS selectors work in a "rightmost first" fashion.

It is a super book. Not just to get ideas to boost web performance but because it helps deepen architectural understanding of the web. There are many important parts in the Web tier: all the different resource types, sychronous / asychronous processing, the various ways blocking can happen, a very sophisticated object model, a funny old language by the name of JavaScript and of course the endless list of quirks from different browsers. There was a time when everything revolved around the database but now a deep understanding web is probably more important. This book most definetly helps deepen understanding of the Web Tier.

Book Review: Essential Software Architecture (2011 edition)

This book begins by defining what software architecture is - a term that can be mean different things to different people and different organisations. It then explains all the various non-functional requirements (performance, scalability, security etc) things that I think everyone would agree are very important in software architecture. It then explains various architectural approaches used in enterprise systems. This includes web services, message orientated systems, model driven architecture, aspect orientated architectures. There is also a case study which shows how some of concepts described can be applied.

My favourie part was on message orientated architectures. All the fundamental and sophisticated aspects are very explained. These include: the asychronous nature of message systems, the way you can cluster message ques and brokers, the hierachial naming formats in publish subscribe message topics and the different approaches to reliability (best effort, persistent and transactional). There was also some really good discussion regarding the background and importance of message brokers.

As well as technical concepts there are also some interesting sections on architectural processes, documentation and even my old favourite UML!

This book serves as a very good reminder to the importance of software architecture - especially in enterprise systems. Architectural approaches don't just need to be properly understood, they need to be compared with other approaches especially with respect to the non-functional requirements that are important to your system.

Ian Gortan

Ian Gortan is a super writer. His style is very succint, concise  and erudite.  It would be very interesting to hear his opinions on various Big Data / NoSql options, the return of the fat client and explosion of JavaScript usage and what the key points are in all this are for software architects.  I would recommend this book to any developer, architect or anybody with an interest in the key concepts of enterprise systems.