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?

MIT Systems Thinking Webinar

Please use the attached link to view a playback of the webinar I presented at MIT on Systems Architecture:

Systems Architecture Webinar at MIT

This series is open to the public and they have many intersting topics for architects. The next one is on System Interaction and Complexity Metrics.

Book Review: Universal Principles of Design

I’ve always thought of Software Design and Software Architecture as different from other design disciplines. After all, building a house is way different then constructing software. And I also read a lot of books on Software Architecture, and in these books, the authors often point out the differences, such as:

- We have only been building software for fifty years but we have been building houses for several thousands of years.

- Software is more malleable and can be modified easier than a building.

- Design patterns for software don’t look much like design patterns in other disciplines.

And yet I have discovered a book about design that applies to software in a big way. It is title Universal Principles of Design, by Lidwell, Holden, and Butler. This book contains 216 design principles, with each described on a few pages or less, with diagrams and quotes from other sources for each principle. The book is brilliant.

Here are some of my favorite principles that I use in my work:

The 80/20 Rule

“A high percentage of effects in any large system are caused by a low percentage of variables”.

There are many examples you probably heard about with this rule. Some listed in the book are:

- 80 percent of the town’s traffic is on 20 percent of its roads

- 80 percent of a company’s revenue comes from 20 percent of its products

And my favorite:

- 80 percent of a product’s usage comes from 20 percent of its features.

What if we could focus our efforts only on that 20 percent of the features? Productivity and success will follow.

Another favorite:

Mental Model

“People understand and interact with systems and environments based on mental representations developed from experience”.

A great example of this given in the book is the interaction with ABS brakes. With a conventional braking system, the drier should pump brakes on a wet slick surface, but with ABS brakes, the car will properly stop and make a turn when slamming or steering while braking. If you are a driving used to conventional brakes, you may not understand this when using ABS brakes.

The book says that designers often have accurate system models but inaccurate user interaction models. Users have accurate user interaction models but inaccurate systems models. Designers need to obtain user interaction models to create designs. They can obtain this by testing and interacting with their designs as users. One of my goals in the next year is to be a tester for all my designs.

And my favorite so far is:

Ockam’s Razor

“Given a choice between functionality equivalent designs, the simplest design should be selected.”

A great example of this is the Google search interface. Nothing could be simpler and it continues as the main interface to the search engine.

Another application is with interfaces. When I design interfaces I strive to make the fewest methods possible. It is a struggle to do this but each method is carefully evaluated.

I plan to read and reflect on a principle a day with this book and will blog on other principles in the future. I feel like I found a treasure cove of ideas for my daily work.

Less Is More

I discovered this web site completely dedicated to Agile Software Architecture. In fact, when I search the web I can’t find anyone that thinks that Software Architecture is dead or gone with the Agile Software movement. For once, the world agrees with me.

The web site outlines what we would like to achieve with Agile Software Architecture:

1. Deliver working solutions
2. Maximize stakeholder value
3. Find solutions which meet the goals of all stakeholders
4. Enable the next effort
5. Manage change and complexity

In my experience the first objective is the most important. I have always wanted to deliver a working solution as soon as possible to test out the ideas of the architecture. In fact, I often work on the implementation before the architecture is completely documented or modeled.

The web site also lays out a set of principles that align with the Agile Manifesto but are specific to architecture:

1. Value People
2. Communicate!
3. Less is More
4. Embrace Change: Plan It, Manage It!
5. Choose the Right Solution for the Enterprise
6. Deliver Quality
7. Model and Document in an Agile Fashion

My favorite of these is #3, Less is More. In my work, I consider the expense of everything. I once had a colleague who was a master requirements writer. She wrote hundreds of requirements for each feature where I would write about a dozen or two for similarly sized features. From my experience, each requirement had a high cost. A test was created for each requirement on each of our product platforms. If that requirement failed, error reports would be generated. If the requirement was truly necessary, then these things (tests, error reports) were indeed necessary. But what I found was when there were too many requirements, very few people would read them and thus their usefulness went downhill.

With documentation and requirements, I like to use advice that Robert C. Martin gave at a seminar I attended: “Rip content out until it hurts!”. After all, you can always put it back in.

Long Projects

I recently found out that a project I started years ago was just cancelled. I was devastated. How could this happen? We did everything right with this project! It even had a code name that indicated it would be a success.

This was a technology disruptive project. It would change the way we do our work and work with our business partners. It had strong backing from many management tiers. These managers were committed. They knew the perils of supporting a multi-year project like this and also meeting their commitments to deliver a steady stream of new products in the meantime.

From the beginning there were constant challenges because we could not get enough engineers on the project. I was moved off the project in a cascade of reorganizations. But as I watched from afar, many talented engineers were moved on the project.

And yet, I smelled the trouble from afar. The project communications were stellar. I was impressed with the progress. They were creating deliverable systems and getting all the key stakeholders involved. More and more of a working system was delivered. But every time I asked how much time before it would be delivered I was gold “two years”. Another year passed and I asked the questioned again and got “two years”.

That “two years” is kiss of death. In fact “two” of anything is the kiss of death. We have an engineer in another organization who we have been waiting months on for a design. Every month he tells us it will be done in “two weeks”.

After six months we gave up and now we did the design ourselves. It’s not as solid a design because he is an expert in this area but we are learning. We’ll have to build the design expertise ourselves.

Long projects notoriously fail. Here is some research from objectmentor.com:

The project I started on was about four years old.

I recalled when we made the key decision. We were going to do something that was more malleable and could be done slowly over time or something disruptive, which was ultimately chosen. At the time, it appeared the disruptive technology would be more robust and indeed that is still the case. But ultimately, the business could not sustain the investment to make this disruptive change.

What does this all mean for architecture? Architects have to make decisions that the organization can follow through on. I had my doubts seeing our organization not follow through on other disruptive changes. And yet I felt at the time, that this environment was different. In the end, however, business needs usually win. And software architecture may have to work with business demands versus the most elegant architecture.