Common Misconceptions about Software Architecture- Part I

“Architecture is design.”
Yes, architecture is design. It is about making the difficult choices on how the system will be implemented. It is not just the “what.” But not all design is architecture.
Architecture is one aspect of the design, focusing on the major elements — the elements that are structurally important, but also those that have a more lasting impact on the performance, reliability, cost, and adaptability of the system. Architecting is choosing the small set of mechanisms, patterns, and styles that are going to permeate the rest of the design and give it its integrity. Architecture is the tool that allows us to master complexity. It cannot be the whole design. It has to limit itself to a certain level of abstraction but still be concrete enough to draw definite conclusions. It is not just “high-level design.”

What shall the architect focus on, then? There is no universal answer. For any given project, a decision needs to be made about what is architecturally significant so that we can draw that thin and elusive line between architecture and the rest of the design activities.

“Architecture is infrastructure.”
Yes, the infrastructure is an integral and important part of the architecture: It is the foundation. Choices of platform, operating systems, middleware, database, and so on, are major architectural choices.
But there is far more to architecture than just the infrastructure. The architects have to consider the whole system, including all applications; otherwise an overly narrow view of what architecture is may lead to a very nice infrastructure, but the wrong infrastructure for the problem at hand.
Time and time again, I run into this in organizations in which an architecture team is working solely on infrastructure, largely ignorant of the problem domain and the application software — which they consider to be outside of the architecture. “Oh, you mean the application. That’s what the people in the other building do.”

Philippe Kruchten

گزیده:

Projects aren’t dangerous. Risks are dangerous.
John M. Nevison, 13 Risk Rules for New Project Managers