For many years , software designers have had the strong feeling that software architecture was an important concept. But this concept was not very well exploited, for a number of reasons:
The purpose of an architecture was not always well articulated .
The concept remained fuzzy, trapped somewhere between top-level design, system concept, and requirements.
There was no accepted way to represent an architecture.
The process by which an architecture came into life was not described and always seemed to be some kind of art form or black magic.
Architecture ended up taking the form of an unmaintained document of a few diagrams made of boxes and arrows reflecting imprecise semantics that could be interpreted only by its authors. But because many software systems weren't complex, the architecture could remain an implicit understanding among software developers.
However, as systems evolve and grow to accommodate new requirements, things break in a strange fashion, and the systems do not scale up. Integrating new technologies requires that we completely rebuild the systems. Systems, in other words, are not very resilient in response to changes. Moreover, the designers lack the intellectual tools to reason about the parts of the system. It is little wonder that poor architectures (together with immature processes) are often listed as reasons for project failures. Not having an architecture, or using a poor architecture, is a major technical risk for software projects.
Now that all the simple systems have been built, managing the complexity of large systems has become the number one concern of software development organizations. They want their systems to evolve rapidly , and they want to achieve large-scale reuse across families of systems, building systems from ready-made components . Software has become a major asset, and organizations need conceptual tools to manage it.
The word architecture is now used everywhere, reflecting a growing concern and attention, but the variety of contexts in which the word is used suggests that it has not necessarily become a well-mastered concept.
For an organization to adopt an architecture focus, three things are required:
An understanding of the purpose
Why is architecture important? What benefits can we gain from it? How can we exploit it?
An architectural representation
The best way to make the concept of architecture less fuzzy is to agree on a way to represent it so that it becomes something concrete that can be communicated, reviewed, commented on, and improved systematically.
An architectural process
How do you create and validate an architecture that satisfies the needs of a project? Who does it? What are the artifacts and the quality attributes of this task?
The Rational Unified Process contains some answers to all three points. But let's start by defining more precisely what we mean by software architecture, or rather, by the architecture of a software- intensive system.