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.