This is an interesting article in this area. It helps clarify the different ways of looking at architecting, or for that matter modelling, your design. It also fits, I think, with the frameworks (e.g. Zachman) that Phil was discussing last year.
http://www.2xsundblad.com/en/FreeContent/Articles/Business_Improvement_through_Better_Software_Architecture.pdf
I'd welcome comments.
Murray
I finally got a chance to run through this last night. They make some reasonable points here and there, but I have a number of problems with the paper as a whole and with individual pieces.
First, it doesn't seem to me that the paper has a lot to do with better architected software ... more about how to categorize architects and what their characteristics might be.
The list of "three ways in which business software can support a business and its activities" on page one:
has 5 items;
is very limited in terms of scope;
and is very slanted
On the aspect of IT people not knowing enough about business, I not only agree but have to say that there are a lot of business people who don't know a lot about business too. No small amount of my consulting over the years has been figuring out the business problem before we ever got to the question of how to automate.
I don't quite agree with the breakdown of architect versus engineer. One certainly needs to include framework in the infrastructure coverage and I think that there are many cases where individual services are complex enough to require architectural guidance, not mere engineering fulfillment.
Whether or not the level of competency estimates are reasonable, they are made up out of whole cloth with no background or substance.
In the figure 4 on page 13 I couldn't help but ask "where's the bus?"
I also don't agree as it indicates later on that page that architecture is only about external form any more than this is true of a building architect. The building architect needs to consider structure and materials in order to know whether the building will stand. A software architect needs to consider how the application will be constructed in order to know that the application will function and perform.
I loved the "As seen in " pieces ... it is always so embarrassing when these crop up in a piece on software!
They seem to have the idea that one designs each service in isolation, but in an ESB environment with a workflow engine, multiple services are likely to be involved in fulfilling a single business process.
I have started a new thread over in the OERA forum that relates to an article referenced by this article and an article referenced by that article.