AKF Partners

Abbott, Keeven & Fisher PartnersPartners In Hyper Growth

Tag » Software architecture

Enterprise Cloud Computing – Book Review

A topic of particular interest to us is cloud computing so I picked up a copy of Gautum Shroff’s Enterprise Cloud Computing: Technology, Architecture, Applications published in 2010 by Cambridge University Press. Overall I enjoyed the book and thought it covered some great topics but there were a few topics that I wanted the author to cover in more depth.

Enterprise Cloud Computing Book Cover

The publisher states that the book is “intended primarily for practicing software architects who need to assess the impact of such a transformation.” I would recommend this book for architects, engineers, and managers who are not currently well versed with cloud computing. For individuals who already possess a familiarity on these subject this will not be in depth enough nor will it have enough practical advice on when to consider the different applications.

Of minor issue to me is that this book spends a good deal of time upfront covering the evolution of the internet into a cloud computing platform. A bigger issue to me is that coverage of topics is done very well at an academic or theoretical level but doesn’t follow through enough on the practical side. For example, Shroff’s coverage of topics such as MapReduce in Chapter 11 are thorough in describing how the internal functionality but fall short on when, how, or why to actually implement them in an enterprise architecture. In this 13 page chapter, he unfortunately only gives one page to the practical application of batch processing using MapReduce. He revisits this topic in other chapters such as Chapter 16 “Enterprise analytics and search” and does an excellent job explaining how it works but his coverage of the when, how, or why this should be implemented is not given enough attention.

He picks up the practical advice in the final Chapter 18 “Roadmap for enterprise cloud computing”. Here he suggests several ways companies should consider using cloud and Dev 2.0 (Force.com and TCS InstantApps). I would like to have seen this practical side implemented throughout the book.

I really enjoyed Shroff”s coverage of the economics of cloud computing in Chapter 6. He addresses the issue by showing how he compares the in-house (collocation center) vs cloud. Readers can adopt his approach using their own numbers to produce a similar comparison.

The book does a great job covering the fundamentals of enterprise computing, including a technical introduction to enterprise architecture. It will of interest to programmers and software architects who are not yet familiar with these topics. It is suggested by the publisher that this book could serve as a reference for a graduate-level course in software architecture or software engineering, I agree.

1 comment

Evolving Architecture And Software

Is your software and architecture aligned? Ensuring that they are aligned is one of the key elements in managing complex software systems.

When asked by a team what they should prepare for an engagement with us, we usually tell them to not prepare anything. Instead of PowerPoint slides showing the architecture, network, etc we prefer for people to jump to the white board and draw. One of the primary reasons is that we often find people debating how the architecture actually exists. How does your architecture diagrams or institutional knowledge reflect reality of the software?

In the May issue of Computer, there is an article, “Evolving Software Architecture Descriptions of Critical Systems”, by Tom Mens, Jeff Magee, and Bernhard Rumpe, in which the authors’ state:

An explicit architecture description is important but not sufficient to manage the complexity of developing, maintaining, and evolving a critical software-intensive system.

The authors continue explaining that the architecture description must be accurate and traceably linked to the actual implementation in software so that changes in the architecture are reflected in implementation and vice versa.

If your team has spent a bunch of time creating an architecture that will scale, all that effort is wasted when the software implementation doesn’t abide by the architecture. Because of the ever evolving nature of complex software systems it is admittedly difficult to keep the architecture description and software artifacts aligned.  The authors of the article suggest that evolving architecture descriptions requires co-evolution of different viewpoints such as the structural and behavioral. To this I completely agree but they address the solution to this issue from the aspect of Architecture Description Languages (ADLs). The problem with this approach is that I don’t know of many, if any, SaaS companies using ADLs. Therefore, in order to accomplish this co-eveolution of software artifacts and architecture descriptions we have to seek a different solution.

To ensure that architectural changes are reflected in the software we typically suggest that companies rely on architecture principles. We’ve dedicated an entire chapter in The Art of Scalability to this subject but I’ll try to summarize it here. Architectural principles are a set of ideas that the team has determined when used as guidelines during the design and development of the software will yield a scalable, available, and cost effective system. Principles should help influence the behavior and the culture of the team. We often use the SMART acronym to describe good principles as being Specific, Measurable, Achievable, Realistic, and Testable.

So how about the other direction, how do we ensure the architecture description accurately reflects the software? By using JAD and ARB processes, which we’ve covered in detail before on this blog as well as in the book, we can help ensure that software artifacts that deviate from the established architecture are discussed and noted by the appropriate individuals and teams.

Remember that the co-evolution of the software as well as the architecture design is critical in order to manage the development and maintenance of complex, critical software systems. Implement simple but efficient processes to ensure these remain synchronized.

1 comment

The Enterprise Service Bus

The Enterprise Service Bus is a great addition to your toolbox, but you should avoid these common pitfalls in implementation.

It seems like everyone’s architecture diagrams has a big “Enterprise Service Bus” drawn down the middle of it these days.   It’s as if you get a prize for just including the notion of an ESB and indicating that everything is loosely coupled.   The problem is that an unmanaged, misused or overused service bus can become one big Enterprise Cesspool.

Don’t get me wrong – ESBs are a great addition for many companies if used properly.   If you are publishing a message for which there are many subscribers and if you can lose some messages without causing problems then by all means implement an ESB.  Centralized logging of messages, trickle loading of data warehouses and even updates to prices or inventory in search nodes are all examples of ESB activities.  Just ensure that your application is either resilient to or can recover from intermittent message loss.

Don’t fall into the trap of thinking that message buses are the only solution for communications.  Asynchronous communication is preferable where possible, but there are many options beyond message buses.  You can implement asynchronous point to point communication methods (we often differentiate these from bus architectures and call them queue architectures).  You can also implement async-sync point to point methods that allow a busy application to “fire and forget” into a queue while another application works through the queue and synchronously communicates to another consumer process or to multiple data stores where necessary.  And sometimes, when it absolutely positively has to be there overnight, it is best just to communicate synchronously.  Be a wise craftsman/engineer and choose the right tool for the job.  After all, it’s rare that a carpenter chooses to cut a board with a hammer.

Service buses can easily also become cesspools.  Someone needs to ensure that the bus is built with an appropriate number of independent channels so that communications paths don’t become congested.  Treat buses as you would any other piece of infrastructure and scale them horizontally with multiple channels, routing services, etc.  Monitor them aggressively to include message latency, age of the oldest message, number of undelivered messages, etc.

1 comment