Why Software Architecture Matters

Software architecture matters because a good one is a key element of your long- term success. Here are some of the ways that architecture influences success. Not all of them are equally important, but all are related to your architecture.

Longevity

Most architectures live far longer than the teams who created them. Estimates of system or architectural longevity range from 12 to 30 or more years, whereas developer longevity (the time a developer is actively working on the same system) ranges from 2 to 4 years .

Stability

Many benefits accrue from the longevity of a well-designed architecture. One of the biggest is stability. Architectural stability helps ensure a minimum of fundamental rework as the system's functionality is extended over multiple release cycles, thus reducing total implementation costs. It provides an important foundation for the development team. Instead of working on something that is constantly changing, the team can concentrate on making changes that provide the greatest value.

Degree and Nature of Change

Architecture determines the nature of change within the system. Some changes are perceived as easy; others are perceived as hard. When easy correlates strongly with the desired set of changes that improve customer satisfaction or allow us to add features that attract new customers, we usually refer to the architecture as "good."

In one application I worked on, the development team had created a plug-in architecture that would extend the analytic tools that manipulated various data managed by the system. Adding a new tool was relatively easy, which was a good thing because it was a major goal of product management to add as many tools as possible.

Profitability

A good architecture is a profitable one. By "profitable," I mean that the company that created the architecture can sustain it with an acceptable cost structure. If the costs of sustaining the architecture become too great, it will be abandoned .

This does not mean that a profitable architecture must be considered elegant or beautiful. One of the most profitable architectures of all time is the Microsoft Windows family of operating systemseven though many people have decried it as inelegant.

It is important to recognize that the profitability of a given technical architecture often has little to do with the architecture itself. Take Microsoft, which has enjoyed tremendous advantages over its competitors in marketing, distribution, branding, and so forth. All of these things have contributed to Windows' extraordinary profitability.

This is not an argument for poorly created, inelegant architectures that cost more money than necessary to create and sustain! Over the long run, simple and elegant architectures tend to be the foundation of profitable solutions.

Social Structure

A good architecture works for the team that created it. It leverages their strengths and can, at times, minimize their weaknesses. For example, many development teams are simply not skilled enough to properly use C or C++. The most common mistake is mismanaging memory, resulting in applications that fail for no apparent reason. For teams that do not require the unique capabilities of C or C++, a better choice would be a safer language such as Java, Visual Basic, Perl, or C#, which manage memory on the developer's behalf .

Once created, the architecture in turn exhibits a strong influence on the team. No matter what language you've chosen , you have to mold the development team around it because it affects such as things as your hiring and training policies. Because architectures outlast their teams, these effects can last for decades (consider the incredible spike in demand in 19971999 for COBOL programmers as the industry retrofitted COBOL applications to handle the Y2K crisis).

How Many People Will It Cost to Replace This Thing?

One of the most difficult decisions faced by senior members of any product development team is when to replace an existing architecture with a new one.

Many factors play into this decision, including the costs associated with sustaining the old architecture, the demands of existing customers, your ability to support these demands, and the moves of your competitors. Creating a formal set of rules for knowing when to replace an architecture is impossible , because there are so many factors to consider, and each of these factors is hard to quantify. The following rules of thumb have served me well.

If you feel that your current architecture could be replaced by a development team of roughly half the size of the existing team in one year or less, you should seriously consider replacing your current architecture with a new one. In very general terms, this rule allows you to split your team, putting half of your resources to work on sustaining the old system and half of your resources on creating the new system, with minimal increases in your cost structure.

The resources assigned to create your architecture may not all come from your current team. Bluntly, creating a new architecture with fewer people often requires radically different development approaches. Your current team may not have the required skills, and may be unwilling or unable to acquire them. Thus, every manager must be ready to substantially change the composition of his or her team before undertaking an architectural replacement.

While replacing one or two people is often required, it is lunacy to try to replace everyone. The older and more complex the system, the more likely you'll need the services of one or two trusted veterans of its development to make certain that the new system is faithfully implementing the functionality of the old. There will be skeletons, and you're going to need these veterans to know where these skeletons are buried.

All of the traditional adages of "being careful" and "it is harder and will take longer than you think" apply here. You should be careful, and it probably will be harder and take longer than you estimate. People usually forget to estimate the total cost of replacement, including development, QA, technical publications , training, and upgrades. Economically, a good rule of thumb is that it costs at least 20 percent of the total investment in the old architecture to create a functionally equivalent new one if you are using experienced people, with no interruptions, and a radically improved development process. If you're on your fourth iteration of a system that has been created over five years with a total investment of $23 million, you're probably fooling yourself if you think that you can create the first version of the new system for less than $3$5 million. More commonly, the cost of creating a functionally equivalent new architecture is usually between 40 and 60 percent of the total investment in the original architecture, depending heavily on the size of the team and the complexity of the system they are replacing.

Boundaries Defined

During the architectural design process the team makes numerous decisions about what is "in" or "out of" the system. These boundaries, and the manner in which they are created and managed, are vital to the architecture's ultimate success. Boundary questions are innumerable: Should the team write its own database access layer or license one? Should the team use an open -source Web server or license one? Which subteam should be responsible for the user interface? Winning solutions create technical boundaries that support the specific needs of the business. This doesn't always happen, especially in emerging markets where there is often little support for what the team wants to accomplish and it has to create much of the architecture from scratch; poor choices often lead the development team down "rat holes" from which it will never recover.

Sustainable, Unfair Advantage

This point, which summarizes the previous points, is clearly the most important. A great architecture provides a technically sophisticated, hard to duplicate, sustainable competitive advantage. If the technical aspects of your architecture are easy to duplicate, you'll have to find other ways to compete (better service, superior distribution, and so forth). Architecture still has an important role: A good architecture may still help you gain an advantage in such things as usability or performance.