On 03/07/07, Anne Thomas Manes <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
>
> My perspective:
> You use architectural principles to design a system, and you implement the 
> design.

This makes a big assumption that architecture is _just_ about
principles.  In my view this is often the problem in that architecture
is so abstract that it doesn't really deliver value.  When I look at
the Business Service Architecture for a business (100% not a design
thing) then I can clearly see elements (e.g. Sales, Finance,
Procurement, "report sales" on Finance, "buy" on Sales) that are part
of the overall architecture of the system and which can be directly
traced down to the final implementation.  These things are not simply
principles but are, to use a phrase from Fred Brooks, the conceptual
framework.

> You don't implement the architecture.

I agree that you don't implement principles, but you should be
implementing the business architecture, otherwise how will the IT
estate resemble and support the business effectively?

>
> Anne
>
>
>
> On 7/2/07,  Steve Jones <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> >
> >
> >
> > On 02/07/07, Rob Eamon <[EMAIL PROTECTED]> wrote:
> >  >
> >  >
> >  >
> >  >
> >  >
> >  >
> >  > I wanted to get the various views that folks have on a phrase that
> >  >  gives me pause: "implement an SOA" or "SOA implementation." IMO, this
> >  >  phrase is off since an architecture (SOA or otherwise) isn't
> >  >  something one implements. I wonder about the validity of my POV,
> >  >  however.
> >
> >  I'm on the other side of the fence.  If you can't implement the
> >  architecture then its not architecture is just a liberal arts major.
> >
> >  >
> >  >  The reasons I think that support my POV:
> >  >
> >  >  * While there is no single definition of "architecture" Booch,
> >  >  Rumbaugh and Jacobson state that architecture "is the set of
> >  >  significant decisions about the organization of a software system."
> >  >  Architectural principles are decisions--"when faced with this set of
> >  >  circumstances/needs, this architecture states that the approach shall
> >  >  be X."
> >
> >  Agreed, but I've not seen somewhere that has suggested that
> >  architecture should be divorced from delivery (except in certain
> >  toga-wearing architecture groups).
> >
> >  >
> >  >  * Many posts on this forum, as well as various articles and blogs,
> >  >  state that SOA is something you do, not something you buy or build.
> >  >  It follows, then, that it cannot be implemented either.
> >
> >  I'd disagree here "do" means achieving something.  Implementing
> >  doesn't just mean in software however, its about how you organise,
> >  govern and act as well.  This is similar to building architecture
> >  where the putting bricks on top of each other is just one part of the
> >  overall vision, and the vision extends after the building has been
> >  constructed.
> >
> >  >
> >  >  * When used as a term in building construction, architecture seems to
> >  >  be invariably used to describe the attributes or characteristics of
> >  >  the structure. The building itself isn't called "the architecture"
> >  >  nor is it considered an "architectural implementation."
> >
> >  I'd have to go against this again, when an architect defines the plans
> >  and architecture of the building (e.g. the Gerkin in London) then its
> >  hard to see how the building isn't the implementation of that
> >  architecture.
> >
> >  I'd agree that it isn't architectural implementation however (as in
> >  implementation isn't architecture) but it _is_ the implementation OF
> >  the architecture.
> >
> >  >
> >  >  * Service orientation is but one of many sets of principles applied
> >  >  to a given system. This is probably a poor analogy but: A car has an
> >  >  engine but I don't refer to the entire car as "the engine" nor as
> >  >  an "engine implementation." :)
> >
> >  Not sure to go with that analogy.... :)
> >  >
> >  >  The reasons that I question the position:
> >  >
> >  >  * Brass, Clements and Kazman define architecture as "...comprise[d]
> >  >  [of] software elements, the externally visible properties of those
> >  >  elements, and the relationships among them." Clearly one can
> >  >  implement/instantiate the elements of the architecture so "implement
> >  >  the architecture" doesn't seem completely far fetched.
> >
> >  I'd disagree with this definition as it limits architecture to
> >  software, which means that hardware, people, practice, process and
> >  operations are excluded.
> >
> >  >
> >  >  * Many, many people whose opinions I respect often say "SOA
> >  >  implementation." I have a long held belief that architectures
> >  >  aren't "implemented." But perhaps I need to let that view go.
> >
> >  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.
> >
> >  >
> >  >  I'm quite interested in hearing other points of view.
> >
> >  Mine is that if architecture can't be implemented then it is pointless.
> >
> >  >
> >  >  -Rob
> >  >
> >  >
> >
>
>
>
>                   

Reply via email to