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.