On 03/07/07, Rob Eamon <[EMAIL PROTECTED]> wrote: > > > > > > > --- 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.
Which is where (to me) most of the time architecture doesn't apply. If its just about the software then its pretty much design rather than architecture. > > > 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." I'm hoping that wasn't me :) I don't think the term "within" the SOA makes sense, its more that instead of applications capabilities will be presented to consumers in the form of business services. The quote above majors on implementation technologies which is pure plumbing (and hence not that interesting to the business). > The follow-on question asked is "what do we call > this collective set of capabilities?" Technologies :) > > Do we now get customer information from "the SOA?" We get it from the customer management service, which is part of the Enterprise SOA (I prefer to say Service Architecture or Business Service Architecture). > > This strikes me as patently absurd, but if we "implement the > architecture" isn't this what we should call it? Nope. If we have a Business Service Architecture that specifies there should be a Customer management Service then we should get the customer information from the customer management service as specified by the BSA. Saying "getting from the SOA" is like saying that we get oil from the universe, its sort of correct but you need to be more precise for it to be useful. > > > 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)? Architecture is the conceptual framework, it represents the big picture and the outline of what will be delivered, design takes that and creates a logical model which details the specifics of operation, and implementation takes that logical model and creates the physical code. Architecture says "what" should be done, design says "how" you will do it, and code is you then doing it. > > 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? Architecture is a rough blueprint, the high level 30,000 foot view. The sketch of the gerkin and the principles by which it will be built. Design then fills in the sketch adding more detail. There isn't a quantum state dividing line where architecture becomes design, in the same way as there isn't really a firm dividing line between design and implementation. > > Historically, I've leaned toward architecture being > principles/decisions only and thus cannot be "implemented" per se, > but only followed when designing something. But would you design a business model? To me that sounds a little bit abstract for "design". > > -Rob > >
