> a. define the business problem that I am trying to solve
> b. research the business context
> c. extract requirements
> d. build a virtual or model solution using some random classical technique or tools to hand

I think the definition is one coined too much from the perspective of a particular example if you are proposing a general definition. In particular, I think you need to drop the word 'business' from a. and b, or qualify the particular type of architecture you are talking about. Otherwise you are excluding a lot of amateur or academic practitioners with no interest in commercial application.

Personally, I would define an architect as someone who defines the architecture of a construction, which is probably more comprehensive although admittedly not very useful.

"Indeed, I wanted a messaging system that could support arbitrary messages, and payments were just a trivial example of a message, within the full set of possible messages"

Sounds a lot like SWIFT...

> Sounds a lot like SWIFT...

In short, yes. However there is missing detail on both sides that makes the story a bit different.

Your solution - instant messages some of which can contain money, offloads too much of the job to the human, creating the opportunity for scams at the gap between human and computer.

If payments are not strongly coupled to contracts, all sorts of scams become possible. Scammer tells customer he is the seller, and seller that he is the buyer.

I suggest

1 Instant message with no money

2a Instant message that is bill for services rendered.

2b Instant message that is a payment for that bill, acceptance of which generates record of bill payment.

3a Instant message that is an offer to render services for money paid in advance

3b Instant message that is payment on that offer, acceptance of which generates a contract to be fulfilled.

Ian,

Part of your problem is complexity...

Now old fashioned engineers have solutions for dealing with complexity one of which is "sizing a sub problem".

The process is to identify a generalised sub process and then look for a good "choke point" to put a standard interface.

when you examin things esspecialy those that have a history that pre-dates generalised use of computers you see that there are standard choke points in what humans do. For instance invoices, it does not matter what comes before or overly much what comes after the invoice is the natural choke point in many purchase models.

Looking at many many different models appears initialy to increase complexity, but they all have comanalities that naturally sugest choke points and thus defines the heads and tails of sub processes that align naturally with the generalised choke points. If more than a small percentage dont align then you have picked the wrong place for a choke point.

Thus the more choke points you can identify the easier the task becomes. These standard interface points enable you to develop a framework (yeah I know you don't like such things) by which the complexity can be broken down into logicaly separate sub blocks of more managable proportions.

Thus you "iteration" loop becomes hierarchical in nature and produces the initial framework then the process overviews within the layers.

Yes it produces what appears to be inefficient design practices and code, BUT it has the advantage (if done properly) of producing great flexability with easy testing, maintanence, upgrade and yes "reusability". Oh and also alows fairly easy movment onto a parallel processing environment such as "the cloud" (hawk hawk spit).

Oh and no objects required 8)

So the three keywords are,

1, Frameworks
2, Interfaces
3, Iteration

To handle complexity...