I tend to operate with the same definition as you, Rob. I emphasize
defining all of the components that will have an independent lifecycle.
-tb
Todd Biske
http://www.biske.com/blog/
Sent from my iPhone
On Jun 2, 2009, at 2:01 PM, Rob Eamon <[email protected]> wrote:
The definition of architecture that I tend to follow: the components
of a system and the relationship between them. I also generally add
that the architecture includes the principles used to identify and
segment the responsibilities of the components. I also include the
principles/characteristics that implementations following the
architecture must follow/exhibit. The "-ilities" that are chosen,
though it should be more than "the system must exhibit agility"--it
should describe to some degree how agility is to be pursued.
The challenge, which you allude to, is that this applies to all
levels of scope. The software/hardware of a system might be
considered an architecture but when looking at things at a BA or EA
level, the software/hardware is well below that. Thus we get
mismatch of expectations when the scope or level of abstraction of
an architecture is not well communicated.
-Rob
--- In [email protected], "htshozawa"
<htshoz...@...> wrote:
>
> I do agree that many projects are still stuck in trying to define a
> proper service, but I still think there is a need of an
> architecture to define how these services may interact with each
> other.
> I was talking with a potential client yesterday and he asked me
> what an architecture was. Some IT people think of it just as a
> combination of which hardware and software to use, but it's really
> more than just defining the structure of a system.
> Even if we don't call it "SOA", I do hope that people do not forget
> about creating a guideline to define how services may interact with
> each other. (Installing an ESB and plugging all service consumers
> and service providers with no rules may not work out too well. :-) )
>
> H.Ozawa
