New paper just out - Web Services Architecture & Web Services Specifications related

Dave Welsh — Fri, 17 Sep 2004 17:46:00 GMT

There's a new Web Services Architecture paper just up on on MSDN and its a good introduction to some of the higher level architectural concepts behind the many Web Service specifications which are becoming open standards right now. The nice thing about this paper is that it is largely co-authored by many of the actual Microsoft Indigo developers, so you're getting a first hand account at a high level of what's behind some of the design ideas around the new Web Service specs.

It's a bit of a long paper, but it is a good read.

I've also gotten some comments that there is also a need for more papers to go with this one, but more focused to the business modeler type of audience (who aren't programmers) on how vertical industry business processes fit around the technical web services architecture. Things more to the business standards person like showing how legally binding business transactions relate to technical based web service transaction compositions.

If you have any comments about what you'd like to see in any more papers we produce, that might go along with with this one, please drop me a comment and I'll see what I can do.

Enjoy the read.

Business Physics 101

Dave Welsh — Fri, 20 Aug 2004 00:25:00 GMT

Perhaps the title should be ‘business architecture 101’, with a subtitle of ‘business architecture is not the same as technical architecture’; but some people seem to not see the difference between the two. The laws of nature which determine the success (survival and possible failure) for a business objective, might not be the same laws when applying technical infrastructures to meet a technical objective; but more importantly applying technology laws to business may need some additional thought.

For example … in posting to a SQL table, it might be the case that a business user wants to ‘cancel out’ a business transaction; the ‘oops, I didn’t mean that’ scenario. A technical architecture needs to be aligned with (constrained by) the business reality so if the business context (like dispatch of a delivery truck from a production plant to a distributor warehouse has happened and the truck is driving down the road) isn’t observed then the technical architecture will not be ‘reifying’ (faithfully rendering) the business reality. Technically in this example it would be easy to ‘rollback’ a SQL transaction, but how do you ‘rollback a truck going down the road at 60 mph (110 km/hr)’. Because of general accounting principals you may have to consider extra business transactions that have nothing to do with ‘the truck’.

The general operative word is ‘context’ and in the example above there are certain accounting rules which all company auditors are expecting to see practiced, which tie back to the tax level a company gets charged at, about how inventory records are handled; else someone can get into legal problems of keeping taxable inventory off the company books.

It’s the context of business collaborations (like running an auction, or shipping finished goods direct from the factory to a consumer) where business models are defining business operating success (and business failure) of business transactions; and in turn it is the context of business transactions which define the success of basic business interaction patterns around success (and failure) of sending a business event notification (like a message or document) between one party and another. Unfortunately, some technical architectural designs tend to ‘flatten’ some business models and thus leave out the ability to evaluate ‘business context’; making business process execution in-deterministic.

For businesses, the ‘laws of gravity’ are in the legal and accounting regulations and the general market theories that exist. These business laws strongly have an influence on how one should practice applying technical architecture.

The good news is many business practices have been around for decades, some of them centuries, and they are fairly slow to sudden dramatic change. Technical architectures though are rapidly evolving and allowing for some exciting new realities for business opportunities. Just look at Amazon.com and its $6 Billion revenue today. Technology will continue to change, so maybe the secret to landing the full potential of new technical architectures is more appreciation of the context of new business architectures (models); if we dare think out side the box.

Dave Welsh's WebLog : Business Process Standards

New paper just out - Web Services Architecture & Web Services Specifications related

Business Physics 101