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.
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 .
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.
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.
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).
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.