-- Rational Unified Process
“Software architecture encompasses the significant decisions about the organization of a
software system. The selection of the structural elements and their interfaces by which
the system is composed together with their behavior as specified in the collaboration
among those elements. The composition of the structural and behavioral elements into
progressively larger subsystems, the architectural style that guides this organization, these
elements, and their interfaces, their collaborations, and their composition. Software
architecture is concerned not only with structure and behavior but also with usage,
functionality, performance, resilience, reuse, comprehensibility, economic and
technology constraints and trade-offs, and aesthetic issues.”
-- SunTone Architecture Methodology:
Architecture is a set of structuring principles that enables a system to be comprised of a
set of simpler systems each with its own local context that is independent of but not
inconsistent with the context of the larger system as a whole.
--Vitruvius, circa 25 BC:
“The ideal architect should be a person of letters, a mathematician, familiar with
historical studies, a diligent student of philosophy, acquainted with music, not ignorant of
medicine, learned in the responses of jurisconsults, familiar with astronomy and
astronomical calculations.”
-- Mark Cade, Simon Roberts, Sun Certified Enterprise Architect for J2EE™
"[..] What does the architect do? What is the difference between an architect compared with a
senior developer? These are some of the common questions asked. The designer is
concerned with what happens when a user presses a button and the architect is concerned
with what happens when ten thousand users press a button. An architect mitigates the
technical risks associated with a system. A technical risk is something that is unknown,
unproven, or untested. Risks are usually associated with the service-level requirements
and can occasionally be associated with a business requirement. Regardless of the type of
risk, it is easier to address the risks early in the project while creating an architecture,
then to wait until construction when you have a large developer base that could
potentially be waiting while risks are solved[..]"
-- Becoming an Architect, A Conversation with Luke Hohmann, Part IV
[..] Most people think of architecture as technical, and the architect as a technical person. And absolutely, the architect must be technical. But there's also a social aspect of the architect role that I think is not well communicated or understood. The architect is the person who will say, "This is the way we do things."
An architecture is like a dirt road. The first time a car drives over it, the road looks about the same. By the time the 10,000th car drives over it, though, there will be grooves in the road. As an architecture mature, it gets grooves.
For example, one kind of groove that is common in architecture is error handling strategy. Whether you handle errors by returning error codes or throwing exceptions is part of your architecture. In practice, most teams will choose one error handling mechanism as the dominant approach, the other as the subordinate approach, because you often need to use both. Among the roles of the architect is choosing the dominant approach to error handling, keeping the flame of the dominant approach, and educating the team on when the subordinate approach is an acceptable alternative. That's one aspect of the architect's job, and that's a social role.
Conversely, you can tell when a system hasn't had an architect, because it lacks consistency in things like error handling, naming, and so on. In a system I'm working on right now, for example, I noticed that some of the database tables have a unique identifier column named id, other tables have a unique identifier column named table id, and other tables do something completely different. So table foo would have a fooid column, and table bar would have an id column. I finally went to the development team and said, "Let me guess. You've had more than one DBA [Database Administrator] in your time here." And they said, "Oh yeah, we've had five of them." Every DBA had their own way of naming columns. They didn't have an architect to ensure a technical consistency in column naming. There wasn't a notion of conceptual integrity from a technical perspective[..]
-- Tarchitects and Marketects, A Conversation with Luke Hohmann, Part V
Envisioning the future on behalf of customers, even when they can't articulate what they want, is the world-class marketect's key distinguishing feature
--Martin Fowler, Patterns of Enterprise Application Architectues
[..] Architecture is a terms that a lots of people try to define, with little agreement. There are two common elements: One is the highest-level breakdowm of a system into its parts; the other, decisions that are hard to change. It's also increasingly realized that there isn't just one way to state a system architecture; rather, there are multiple architectures in a system, and the view of what is architecturally significant is one that can change over a system's lifetime [...] architecture is a subjective thing, a shared understanding of a system's design by the experts developers on a project. Commonly this shared understanding is in the form of major components of the system and they interact. It's also about decisions that developers wish they could get rigth early on because there're perceived as hard to change. The subjectivity comes in here as well because, if you find that something is easier to change than once thought, then it's no longer architectural. In the end architecture boils down to the important stuff -- whatever that is.
