Every interesting software-intensive system has an architecture. While some of these architectures are intentional, most appear to be accidental. Philippe Kruchten has observed that "the life of a software architect is a long and rapid succession of suboptimal design decisions taken partly in the dark." The journey between vision and ultimate executable system is complex, and for every interesting software-intensive system that path is marked by myriad decisions, some large and some small, some of which advance progress while others represent vestigial dead ends or trigger points for scrap and rework. As Philippe also observes, the architecture of classical systems comes primarily from theft, whereas the architecture of unprecedented systems comes largely from intuition carried out in the context of a controlled exploratory process. The fact that this is so for software-intensive systems shouldn't come as a surprise, for as Henry Petroski explains in his book To Engineer Is Human (Vintage, 1992), all sound engineering disciplines advance by building on past successes while simultaneously mitigating causes of observable failure.Thus, having an accidental architecture is not necessarily a bad thing, as long as the decisions that make up that architecture are made manifest and the essential ones are made visible as soon as they are instituted and then allowed to remain visible throughout the meaningful life of that system. Insofar as we can then name these architectures after they're formed, we can use these names and their associated semantics to communicate decisions using a common language, just as we can do now with design patterns, and perhaps even reuse these architectural patterns in future systems. In other words, by naming these accidental architectures, we again raise the level of abstraction by which we can describe and reason about a system.