RE: Where do we find software architecture?

My $0.02c ...

What comes first - an architecture or a solution?

I always think that an architecture comes first which describes the
features, functionality and organization of what you are going to build.

You then do more detailed design work and eventually build a solution, and
in doing so, you refine and adapt the archtiecture to fix the problems you
find.

So where are we now? 

Right now we have some solutions built (e.g. SOAP 1.1. largely RPC based web
services), so we can examine them to determine their architecture then
analyze them to work out what works well and what does not.

However we **know** that the current architecture doesn't do everything we
need it to (e.g. security, reliability) therefore we should extend the
architecture to specify how these additional features should be constructed.
This is where the "harvesting" activity will provide useful input.

We then end up with an architecture which is partly developed from the best
parts of current practice and partly based on what we know we need to do and
the thoughts and ideas that other groups have put into this. This is the
"blueprint" for construction.

Finally we can build solutions that are based on the architecture and, in
doing so, refine the architecture to resolve the problems we discover on the
way.

Does this make sense?

David

-----Original Message-----
From: Mark Baker [mailto:distobj@acm.org]
Sent: Wednesday, July 24, 2002 6:39 PM
To: David Orchard
Cc: www-ws-arch@w3.org
Subject: Re: Where do we find software architecture?



Dave,

On Wed, Jul 24, 2002 at 03:50:28PM -0700, David Orchard wrote:
> By your argument, we can't talk about architectures until they are
> deployed - which means extensible architectures like SOAP 1.2 can't be
> talked about.

Your definition of architecture is unlike anything I'm familiar with.
Architecture can only be extracted from running code.  You don't need
lots.  The architecture could be extracted from Google's SOAP API, for
example.  The Web had an architecture the moment Tim ran his first Web
server and browser.  That Roy waited until 2000 to write it down isn't
relevant.  What's relevant is that there are running Web services out
there, and that you have to look there in order to find the
architecture.

> My concern is that you are trying to set the bar too high for newer
> specifications like SOAP 1.2.  Given that you don't think there is an
> architecture in SOAP or WSDL [1], I understand why you are taking this
tact.

I'm not setting a bar at all.  I'm just want us to observe running Web
services, and write down what we see in the architecture document.

> I find your quote from Roy baffling.  I think I understand Roy's quote.
In
> the editors version of the ws-arch document that I'm working on, I
suggested
> following the identifiers/formats/protocols style of the TAG doc in our
doc.
> I *really* want the ws arch document to naturally flow from the TAG
document
> (my own personal success factor and requirement).

Once again, your odd definition of architecture has me baffled.  The TAG
architecture document is documenting architectural *principles*.  We are
tasked with defining a reference architecture, as Mike just so eloquently
described.  These are *very* different things.

>  From this, we can define
> additional formats and protocols for newer web services standards, like
> security.  So I want to talk about data elements and I'm prepared to
propose
> or talk about them in whatever forum is expeditious and appropriate.  I
fail
> to find logic in why you quoted Roy's thesis as I do not believe I am
> suggesting anything that contradicts it.

You contradict it when you suggest that we can harvest an architecture
without looking at running code.

> Like I've said before, I would rather focus on writing and talking about
web
> services architecture documents rather than wrangling over process of
> getting to those documents.  I have volunteered to contribute to such
> writing efforts.  Perhaps we should terminate this conversation and simply
> ask for a vote in the group.

I'm not talking about process, I'm talking about definitions.  The
definition of "architecture" in our glossary, and my definition, are
at odds with yours.  I suggest we address this, since, as an editor of
the architecture document, it's important that you be in synch with
the group and the industry at large.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@acm.org
http://www.markbaker.ca        http://www.idokorro.com