--- In [email protected], "Steve Jones" <[EMAIL PROTECTED]> wrote: > > I'd disagree with this definition as it limits architecture to > software, which means that hardware, people, practice, process and > operations are excluded.
I left out a key word from my intro to the quote: "software". Brass, Clements and Kazman were explicitly referring to software architecture, not just architecture. My error. > I've always tried to say "Service Oriented Delivery", as in the > architecture provides the bounds, constraints and vision and then > the SOD is about delivering the IT that matches to the architecture. Makes sense. Following the next logical step along this line of thinking, I've read blogs from a couple of people that ponder the notion that following SOA principles will lead us to a scenario where "...applications will give way to functionality that is embedded within the SOA in the form of inter-linked services and assemblies, orchestrations, business rules, and policies involving those services." The follow-on question asked is "what do we call this collective set of capabilities?" Do we now get customer information from "the SOA?" This strikes me as patently absurd, but if we "implement the architecture" isn't this what we should call it? > Mine is that if architecture can't be implemented then it is > pointless. Relatedly, what's your view of the difference between architecture and design (as Anne poses in her post in this thread)? I'm personally struggling with what's the "right" view. When do we cross over from architecture to design? Should an architecture specify components or just guiding principles? Is an architecture a blueprint or is a blueprint a result of design? Historically, I've leaned toward architecture being principles/decisions only and thus cannot be "implemented" per se, but only followed when designing something. -Rob
