How Software Architecture Learns

Christine Miyachi, Principle Systems Engineer and Architect,Xerox Corporation

http://home.comcast.net/~cmiyachi, Blog: http://abstractsoftware.blogspot.com/

Introduction

"All models are wrong, some are useful" - generally attributed to the statistician George Box

"All buildings are predictions, and all buildings are wrong"
- Stewart Brand "How Buildings Learn" video

But maybe some buildings are useful. And if we replaced the word buildings with software, we come to the deduction that all software is wrong but some software is useful.

In the field of software design and software architecture, analogies are often made to building architecture. And these analogies are often criticized [1]. However, building architecture has been in practice for many hundreds of years where software architecture has only been around for less than fifty and only recently recognized by some as discipline. Software architects rarely go back and look at their work and how it has fared over time. (An exception to this is Grady Booch's work creating the "Handbook of Software Architecture" [2]) Stewart Brand says in his book "How Buildings Learn"[3], that this is very true also with building architects. They build grand facades meant to stand out as monuments and almost never go back and study how their work has changed over time. And as Brand shows in his book, buildings change radically over time.

Software architects do not work like building architects. They don't design blue prints and then hand them off to builders. They typically work with an interdisciplinary team of software developers and business people. They interpret requirements into functional systems. They often still write code. In the past, they often got to see their working systems in the field and were then responsible for the rework and bug-fixing. Currently, much of the bug-fixing and changes requested by customers are delegated to off-shore teams leaving the original designers free to work on new projects but unable to learn how their original architecture changes over time and what could be done to make it better.

When studying building architecture, three things come to the surface:

1. Software designers can learn a lot from building designers
2. Software designers and building designers make the same mistakes
3. Building designers can learn a lot from software designers

In this paper we will examine all three learning opportunities to pave a way for better buildings and better software.

Defining Architecture

Software Architecture has a several definitions. The standard on software architecture - IEEE 1471-2000 says:

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.

In "A Taxonomy of Decomposition Strategies Based on Structures, Behaviors, and Goals" [4] , Koopman describes architecture as containing structures, behaviors, and goals along with a variety of decomposition strategies.

In relation to buildings, architecture is defined as [5] :

The planning, designing and constructing form, space and ambience that reflect functional, technical, social, environmental, and aesthetic considerations. It requires the creative manipulation and coordination of material, technology, light and shadow. Architecture also encompasses the pragmatic aspects of realizing buildings and structures, including scheduling, cost estimating and construction administration. As documentation produced by architects, typically drawings, plans and technical specifications, architecture defines the structure and/or behavior of a building or any other kind of system that is to be or has been constructed.

The Software Development Process

The software development process started out much like a building development process. This was dubbed "The Waterfall Method":

Figure 1 - The Waterfall Process

In this methodology, all requirement analysis, design, and architecture are done up front. As with building architecture, the blueprints are defined at the beginning of the process. But as Stewart Brand points out in his book "How Buildings Learn", what happens to buildings and software over time is that significant change occurs. Software designers have noticed this and have been working with a various software processes such as Scrum or Extreme Programming inspired by the "The Agile Manifesto"[6]. In these processes the change is embraced. Brand also points out projects where buildings are made with the requirement to be changeable by the owners. In both these processes, change is done incrementally and a working system/building is produced. This approach to software development is called iterative:

Figure 2 - The Iterative Process

In this process, requirements analysis, design, and architecture are done at each iteration. A final system is complete after several cycles.

Flow

"Flow, continual flow, continual change, continual transformation"

--Rina Swentzel, Peublo Indian architectural historian

"Responding to change over following a plan - focus on quick responses to change and continuous development. [6]

--The Agile Manifesto

When humans architect something, it is designed often not to adapt. After all, if the architecture is correct, it will meet all needs, now and in the future. It will serve as a monument, and work of art, and meet all the functional requirements.

Unfortunately, with both buildings and with software this is often not the case. Buildings, as Stewart Brand points out in his book How Buildings Learn are often made as works of art and sometimes don't even consider function. Software, while it is often designed with function in mind, does not take into account future considerations.

As an example, Brand points to the MIT Media Lab.

Figure 3 - MIT Media Lab

This has a shared atrium and shared entrances but people are completely cut off from each other. Moreover, the building had a slew of problems when it was first opened. There was a terrible stench in the corridors, and doorknobs fell off, among other things. This building was a striking new monument on campus but according to Brand, did little serve its inhabitants (As an MIT alumnus, I knew nothing of these problems and the media lab was always regarded as a revered building on campus. I never talked to the inhabitants though.) In time, the media lab was fixed and a new space was added that was significantly different.

Figure 4 - The new wing of the MIT Media Lab

In this building, the spaces were open, the building was open to sunlight and spaces were shared.

In software, I once created an interface to allow a user to configure changes in security. However over time, users wanted to configure more than just security items, so the interface changed to allow users to configure other aspects of the system. The name of the interface was still "Configure Security" and this may be a bit confusing to the user, because the function had changed. However, the interface and its underlying functionality had to change over time.

In 1896, Louis Sullivan, a Chicago high rise designer, wrote "Form ever follows function". However, architects can rarely anticipate function both in buildings and software. Brand says "Function reforms form, perpetually." [7] In software design, continuous change has become the standard as most software use Agile or Iterative process. Three of the principles of Agile development are focused on change:

• Customer satisfaction by rapid delivery of useful software
• Welcome changing requirements, even late in development
• Working software is delivered frequently (weeks rather than months)

The engineers behind the Agile Manifesto noticed that much of the software being developed did not meet customer needs. A study done of DOD projects showed many of the features implemented were rarely used or never used:

Figure 5 - Requirements that didn't meet the needs of the user

Brand also noticed that buildings were built to look impressive and that many elements were not thought through for functionality. The architects looked at the building from the outside first, and considered the inhabitants too late or never. To rectify this, the Agile creators advocated for bringing in the user early on in the development process. By delivering incremental changes to the user, the user can see if the software meets their needs. They may even change the requirements during this time. The Agile creators felt this change should be embraced rather than trying to freeze requirements. Changing requirements after all are part of the business world and if not embraced, the software will be more useful and thus more successful.

The best buildings, Brand says in his book, are buildings that could be changed over time. Winston Churchill said "We shape our buildings, and afterwards our buildings shape us."[9] But Brand then says this process goes on: "First we shape our buildings, then they shape us, then we shape then again, ad infinitum". Working on an Agile process is much the same. We deliver a software function, the user tries it, and changes it, we rework it and deliver it again. At some point we do have to deliver that functionality, but it incrementally changes until it satisfies the customer need, which may in fact change over this process.

Building for Change

Despite the Agile Manifesto call for continuous improvement, in practice, once a feature is delivered it is considered "done". Because the functionality to be delivered is the main focus of an Agile team, does the designer / architect consider how the software will need to change in the future? Does he or she have time for that? What about future maintenance?

Brand discusses in his book that buildings are rarely built for maintenance. Buildings will decay if not cared for. Software, also will have architectural decay or turn into spaghetti code, if not cleaned out from time to time. When a building decays, Brand says it can either be reworked or torn down. Software also can be rewritten from scratch or reworked. In large software projects, despite software's malleability, managers are often reticent to wipe out an entire software module and rewrite it. Similarly, some buildings are hard to wipe out completely, particularly if they are in a crowded area.

Neglecting maintenance in buildings or maintainability in software has enormous costs. Brand says that if building designers just spent 5% of building design on maintenance issues, cost savings could be achieved. Theoretically in software, if maintainability was considered in the architecture, maintenance problems could be also reduced.

But one of the common practices when doing Agile development is: do not work on future requirements. The idea is to work on required functionality now and if future requirements need a reworked architecture, then architects must have the courage and fortitude to do it. This is easier said than done in an environment clouded with tight schedules and market pressure. Designing software with future change in mind is happening less and less in the industry as Agile processes become more wide spread.

One tradeoff in software would be to look at what areas rapidly change and design an architecture that can handle high change in that area of the system. In large software systems, this can be in areas where a new input is required or a new output is required. It tends to be around interfaces. Sometimes infrastructure changes with technology updates. For example, in the networking area of the software, the design could be made to handle changes for new protocols. In buildings says change happens from slowest to fastest with the following concepts: Site, structure, skin, services, space plan, and stuff. Site changes the slowest and stuff inside the building changes the fastest. In software, this corresponds to the location of the software in the larger system, the structure of the software modules, the interfaces, what service the software provides, the layout of the interfaces, and then the data that flows in and out of the software module. All these areas can change, but designers can focus on the areas of most rapid change to have an impact on making a system adapt to change.

The Facade: A Building / Software Comparison

Design patterns in software architecture define particular structure and behavior commonly used. One such pattern is The Facade. The facade pattern is a software engineering design pattern commonly used with Object-oriented programming. The name is by analogy to an architectural facade.

A facade is an object that provides a simplified interface to a larger body of code, such as a class library. A facade can:

• make code that uses the library more readable, for the same reason;
• reduce dependencies of outside code on the inner workings of a library, since most code uses the facade, thus allowing more flexibility in developing the system; [8]

Buildings also have facades and although the facade does not change, the building inside changes drastically. An example is the Boston Athenaeum. These two pictures show the front of the building in 1896 and then in modern times. The exterior of the building is virtually unchanged. The facade becomes loved over time and is a secure point. The building is cherished as unchanging despite the huge changes going on inside the building. Similarly in software the facade protects the user from the underlying churn of the implementation.

 

Figure 6 - The Boston Athenaeum

Conclusion

Brand says "Buildings live in time. In time we learn." He points out that buildings change dramatically with fashion. Software design and processes also follow certain trends. Waterfall was popular in the early days of software development and Agile process are the common trend today. But are we building software that can change over time? Building designers can learn from Agile techniques. Brand points out buildings that are made as a shell, where the occupants are brought in and allowed to mold the interiors to their needs. Software developers can learn about how buildings change over time that software should be designed for change and for specific functionality. Both disciplines can learn that doing some upfront work on maintainability and extensibility will pay big dividends in the future of the building or product.

References

1. (http://bexhuff.com/software-architecture-is-not-building-architecture , http://triebert.nl/downloads/072005_swarm_concluding_paper.pdf)
2. (http://www.handbookofsoftwarearchitecture.com/index.jsp?page=Main ) where he creates a reference to the design of software intensive systems.
3. Brand, Stewart, How Buildings Learn: What happens after they're built, Penguin Books, 1994
4. (DE-Vol. 83, 1995 Design Engineering Technical Conferences, Volume 2, ASME 1995)
5. http://en.wikipedia.org/wiki/Architecture
6. http://Agilemanifesto.org/principles.html
7. Why Buildings Fail, p. 3
8. http://en.wikipedia.org/wiki/Facade_pattern
9. How Buildings Learn, Chapter 1

---

Related Software Architecture Articles

Strategic Modeling for Rapid Delivery of Enterprise Architecture

When Good Architecture Goes Bad

Related Software Architecture Books

Documenting Software Architectures

The Process of Software Architecting

---

Click here to view the complete list of archived articles

This article was originally published in the Winter 2011 issue of Methods & Tools