Book Review: Just Enough Software Architecture by George Fairbanks

Software architecture tends to be so hard to define which makes it extraordinarily hard to read and even harder to write about. Thank goodness this is improving and the George Fairbanks new book Just Enough Software Architecture is a great improvement on software architecture books I have read in the past. Many of the books I have read in the past have taken tremendous discipline to get through – not so with this one!

The book focus “just enough” is a prevalent theme which makes it different from many other architecture books that are often written to promote a particular set of tools or methodology. Here Fairbanks lays out many ideas from the field and elaborates on the ones he finds most useful. He tends to have an agile slant which I appreciate. His main thesis is that architecture work should be risk driven, and he a chapter an on example that he actually worked on (it wasn’t invented for the book).

The area of the book I found most useful was on models, which is over the half the book. My favorite chapter of the book was “Using Architectural Models”. This was full of real world recommendations that I will be able to put to use immediately. I create “mini-models” almost daily as we try to sort through various issues. He also had a great section on informal and formal analysis techniques, the informal techniques being especially useful.

I think this book will be a valuable book for a college level course but also to software practitioners both architects and developers. There are not many textbooks that are useful to software architects practicing in the field. But this book is useful and it will provide material for many blog posts to come.

Abstraction Amplifies

One of the important uses of abstraction in software architecture is the ability to isolate a problem into its essence without cluttering it with details. In Just Enough Software Architecture, George Fairbanks says that abstraction provides insight and leverage. Mary Shaw created this diagram (from George Fairbanks book and reproduced here)

When a problem is complex we software architectures abstract the problem, abstract the solution, and then apply the abstraction to the real world. Less complex problems can be solved directly from the real world problem to the real world solution.

In my day to day work, I often have problems that I need to bring to a larger group. Without abstracting the problem, the multi-disciplinary team would collapse. Some of the business minded people would glaze over with programming details and some of the developers would dive deep into the details without looking at all the options.

Different abstractions can be made for different groups. This is related to views of the system. I was once asked to derive an architecture of an existing system. I started with all the inputs and outputs of the system, based on the hardware ports. This abstraction worked for many problems but some problems it did not. I needed another abstraction for how data flowed through the system. These two models would have been overwhelming if I looked at them together but by focusing on the problem at hand, I could create simple yet orthogonal abstractions of the same system.

A good rule of thumb when modeling from Fairbanks book is “question first and model second”. Otherwise you will not have the right abstraction as I discovered. And when others can read my model, this increases common understanding.

My designs are based in a process “The Universal Principles of Design” call Design By Committee. It is based on consensus building, group decision making, and extensive iteration. It works best when there are diverse members on the committee – like business people, managers, testers, and developers. To me this is an ideal committee – one that can vet out any issues in the design.

Everyone is a Software Architect

When I first starting working in the field of software I don’t remember the job title “Software Architect”. We did have managers, who were very technical – still writing code, and leaders, who we vetted design with. These people also set technical direction but they weren’t called architects. I worked in a large open lab area, in 1985, and looking back we were practicing XP. We worked in pairs and I have no idea how the work was organized. My manager would give me a project /problem and off I would go either with my office mate or someone else.

In that job, we were building a very large CAD/CAM system that never saw the light of day unfortunately. It was a project that could have benefitted from a software architect. In this case, the product was dealing with some fierce market forces that should have been understood and managed by a business team and an architect.

Another project I worked for was with a brand new manager who was eager to make his mark. He picked a new technology and went with it boldly. I remember thinking how fearless he was. It did not pay off. The project failed disastrously with this new technology not delivering the performance to be competitive. And then I thought, too late, shouldn’t we have challenged the manager? If we did, we may have saved his job, the project, and the company a boatload of money.

When I became an architect myself, I realized that many people wanted me to tell them what to do. That doesn’t work well for me. First of all, I do not know all the answers. Second, I rely on other people to give me data so that we can make an informed decision.

In Just Enough Software Architecture, George Fairbanks talks about distributed architecture skills. If developers don’t have architectural skills, they give the architect poor data for their models. This is true for me in my daily work. I rely on developers to give me information about the system they implement on. But beyond this, I also believe that architects should be experiencing development. I don’t think they can be doing as much development as a pure developer/software engineer/programmer, but I do think it’s important for me to experience the environment we have to deliver to. Although architecture is a big picture activity, it can be greatly influenced and also affect the minutia of the system.

I believe having someone responsible for architecture is an effective organizational model. But that person must make sure the entire team has a mind for architecture because otherwise the architect may not have influence. Architectural principles are not easy tested and if broken by implementers, the result is not found until it is causing problems.

So why wasn’t I an architect in those early projects? I truly was not; I was just trying to do the day to day work assigned to me. But I was starting to develop an architect’s mind and if I had spoken up in either of those early projects, the results of those disastrous projects may have ended differently. I only hope the developers I work with will do the same for me.

More Defining of Software Architecture

I’ve been reading a lot of books on software architecture recently and I’m amazed at how many definitions there are of “Software Architecture”. This blog post will look at the ones I’ve come across and critique them.

First is from the IEEE that I’ve been using a lot and had assumed it was being used every where (no it is not):

• Software architecture is the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.
  (IEEE 1471-2000)

I use this one a lot but this one doesn’t mention dynamic behavior although “relationships” although that could be interpreted in different ways. The elaboration of this definition defines various qualities of the system like performance which is related to dynamic behavior. Perhaps dynamic behavior is too closely related to functionality where the architecture is not?

From Wikipedia:

• ^· The software architecture of a system is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both. ^[1] The term also refers to documentation of a system's software architecture. Documenting software architecture facilitates communication between stakeholders, documents early decisions about high-level design, and allows reuse of design components and patterns between projects.^[2]

The one objection I have to this definition because software architecture designs are often not early in my experience. Some decisions must be made early but others need feedback from implementation before they can be made.

From the book Software Architecture in Practice (2nd edition), Bass, Clements, Kazman; Addison-Wesley 2003:

• The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.

Again – we’re missing the dynamic behavior of the system.

In Just Enough Software Architecture, George Fairbanks says that “Architecture is mostly orthogonal to functionality”. He compares architectures to skeletons and points out that some architectures are more suited to certain functionality than others. Perhaps this is why the dynamic functional behavior is often left out.

One of my favorite definition isn’t from software domains , but is from A Taxonomy of Decomposition Based on Structures, Behaviors, and Goals, Koopman, Design Theory and Methodology ’95:

• ·System Architecture should contain goals /requirements artifacts, and structure and behavior artifacts based on those goals

This has more to do with documenting software architecture but it covers my main three points that I like to see. It doesn’t say anything about a set of rules like the IEEE definitions does. Rules governing the architecture are very useful in my experience and can evolve over time. The rules govern the teams design decisions and given meaning to any assumptions and constraints. If those constraints change, often the rules can change.

The Software Engineering Institute comprised this web site to answer the question: http://www.sei.cmu.edu/architecture/start/definition-form.cfm. I’ll be adding this last definition.

How Software Architecture Reduces Complexity

In the systems I have worked on in my career, none have been more complex than the software systems I see in the market now. There is constant pressure to add new features and new features get added at a dizzying rate. Some features are so complex that I can barely understand how they are to be used. And it’s not just one company that produces this complexity, software systems seem to be becoming more feature loaded. The systems are just plain bigger with more lines of code than when I started in the industry 25 years ago.

I’m reading a book right now titled “Just Enough Software Architecture and I’ll have a review in a few weeks. But in the first chapter, George Fairbanks discusses ways to deal with software complexity:

Partitioning: This is what the book Universal Principles of Design refers to as Modularity – A method of managing complexity that involves dividing large systems into multiple, smaller self contained systems. My experience with making systems modular is that I often can’t modularize completely in the first iteration of the system. I need to gain knowledge of that system and I tend to break it down into smaller pieces once I learn more. This approach works well when using an iterative process.

Knowledge: This is applying experience of prior problems to the current one. This reminds me of using design patterns. Although this may not be what Fairbanks had in mind, but I liken this to “Design by Committee” as described in the book Universal Principles of Design. This is a group process based on consensus building, group decision making, and extensive iteration. Recently I was involved in an architecture decision we had made that was found to be incorrect. But we weren’t sure. We took an iteration to do some tests, do some research, and then we all reconvened. We applied our group knowledge with our different perspectives to solve the issue, along with iterative research. We came to a final answer that I feel a lot more confident about than if I had done it myself.

Abstraction: Abstraction allows software designers to hide the lower level details when working with the architecture. The definition in Thefreedictionary.com says it means “a concept or idea not associated with any specific instance”. We use abstraction all the time when discussing our design and architecture. It is the only we can talk about the complex systems we work with and is key to communicating software architecture to all the stakeholders involved.

I’m not sure how I would add another category but I find communication to be just as important as the others. Architecture is about communicating what the structure and behavior of the system is, and how the structure and behavior meets the goals. That message must be evangelized to the developers and the business people.

Software Architecture is everyone’s business. The developers often don’t want to get involved with abstractions and the business people often don’t want to or can’t understand the partitioning, but the knowledge of that group, with a software architects guidance, can produce the strongest architecture with the least complexity. This is not easy to do and to get a diverse group to agree but it pays off when problems arise - the group owns the architecture.

Architecture: A Competitive Advantage

I recently attended a seminar with James Utterback, an MIT Sloan professor who wrote the book Design Inspired Innovation. He started the talk by something that was clear to me but I never noticed: that today many companies have access to the same technology but it is the design that distinguishes them and makes their products different. He also points out that great products can enhance our lives and he points to the Applie Ipod, an innovative wheel chair, and a new saddle that protects a horses back and makes the rider more comfortable.

Design and architecture is starting to be seen as a commodity and also collaboration between customers, suppliers, manufacturing, national labs, universities, and other open sources of knowledge. An example of how this works was presented by a speaker of the seminar, the founder of Vigix This company has only a handful of employees and contracted out the design of their product to IDEO, the manufacturing to Flextronic, and had a number of other agreements to other specialty companies. Typically these resources were only available to larger companies, but this knowledge is becoming more open and the expertise available for purchase.

His talk and his papers also emphasized the need for simplicity in design. An example is the Google search interface versus the Yahoo search interface. The Google interface remains amazingly simple and the theory is that it became more useful because of that simplicity (I contend it also had superior search functionality to the other engines and that was a big part of its success). He also talked about how companies make simple products complex over time (I’m a witness and shamefully a contributor to that in the products I’ve worked on).

Systems, he says, are greater than the individual components that make them up. Simple ideas may create new combination of component interaction and may not even require new technology. This is architecture. An example of how a system is greater than the sum of its parts: An Olympic skier who won the overall event but doing well in each of the individual events but not winning any of them.

He defines product architecture as a map in the abstract of subsystems and their interface or connections. Products today must be built modularly so that they can be integrated easily but adapted to individual tastes. This is how product platforms are born. The Black and Decker power tools, built around a singular battery power supply are an example. The book states that the interfaces these days should be open rather than proprietary as it gives the customer more flexibility (although it does leave the firm wide open to the competition).

After attending this talk, I give even more importance to the job of the Software Architect. I also see the trend for more contracting out of this. Perhaps we need a Software-only IDEO. Start-up anyone?