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.