Role Of Architecture

I've participated in my fill of forums trying to define the software architect's role. It always seems to go to two or three places:

someone who can do requirements, when almost no one else can
someone who can design effective information structures (my vote)
any form of expertise in software at all

If software architect is indeed a leveraged role, then it goes without saying that it is accompanied by the usual risks that attend extraordinary power. In my own precious case, it breeds laziness like you wouldn't believe. -- WaldenMathews

The above describes the role of an architect, not that of architecture.

Humbly submitted for your consideration : that the role of software architecture is to address, in software systems, a problem analogous to that known as PeterPrinciple as applied to individuals.

You mean that successful systems are always being used for something that's just beyond their capability? And that architecture helps with that?

Maybe, but the concept of a system getting a promotion doesn't quite work for me. When you get a promotion (in Peter terms), you don't do your old job anymore. Are systems treated like that? (Did I miss the point entirely?) -- WaldenMathews

I submit some experience and some conclusions reached in discussion with other software architects. ArchitectureAlwaysFails

What is Architecture for? It is for minimizing the cost and risk of future change, and maintaining ConceptualIntegrity. EveryoneIsAnArchitect to some extent.

Apart from the Functional requirements (provided by the customers), and the Operational requirements (provided by the people who have to keep the system running, manage upgrades etc), there are architectural requirements all related to lowering cost/risk of change. Great teams are aware of these requirements, and deliver them seemingly without conscious thought. A software application with good separation of concerns, loose coupling between distinct layers, which is built using agile processes which ensure software can be delivered regularly, is an application which has been built by people thinking architecturally. On a specific team, EveryoneIsAnArchitect to one degree or another. Outside the context of individual projects, there are architectural roles which are necessary in order to feed architectural requirements into projects. To try to establish a sensible target data infrastructure (customers are HERE, products are HERE, orders are HERE etc) for a corporation is an architectural role. Keeping an eye on the entire suite of projects a corporation has under way in order to EliminateDuplication and maintain ConceptualIntegrity, is an architectural role. These architectural roles which span a large number of systems appear to be called EnterpriseArchitecture roles. Am I making sense yet? -- GaryCasey

Architects interpret the functional requirements and fully clarify them, and then translate these into roles, structures and arrangements which will efficiently and effectively perform and fulfill the requirements when the modifying influences (input, data and flow) fall within prescribed and specified limits. Architects do not operate in vacuum and programmers shouldn't be required to operate there either. The definitions and environments for both reside in TheContract?. --DonaldNoyes