CTO Articles
IT World
E-Business in the Enterprise – March 30, 2004
The fallacy of business objects
By Sean Mc Grath
In the next three paragraphs, you will encounter a strong reality distortion field. Keep your wits about you as you travel through it. Suspend all judgement and sit on your hands if necessary. Normal service will resume in paragraph five. Ready? Take a deep breath. Here we go.
Enterprise computing is simple really. All business data processing can be analyzed and decomposed into a set of so-called "business objects". These are the fundamental real world concepts that make up your business e.g. customer, account, product and so on.
For each class of business object identified, we can create a so-called "interface". That is to say, we parcel up all the stuff required to implement any given class of business object and we hide it all behind a crisp set of "exposed" controls called "methods".
This encapsulation of complexity behind a simple interface makes it easy for developers to use business objects in their applications. Moreover, it allows the developers of the business objects to change the implementation of the objects as business needs change *without* modifying all the programs that use the objects. This provides great flexibility.
Now doesn't that sound just great? Doesn't it make you want to rush out and buy something right now? What a great idea!
Unfortunately, it doesn't work so well in practice in my experience. It's like a slick used car salesman's patter. Each little step in the argument sounds entirely reasonable and you end up parting with your money. It is only when you take your purchase home, leaving the reality distortion field of the sales arena behind you, that the engine starts to rattle and the breaks begin to screech.
The distortion of reality happens at the split between the interface (or API of you like) and the implementation of a class of business objects. The plausible sounding thesis is that the interface will be stable over time but the implementation may change. By separating the interface from the implementation, you can change the implementation as much as you like without affecting any programs that use the business objects.
The trouble with this argument is that in the real world, it is often the interface that needs to change to take account of changing business requirements, not the implementation. To take a simple example, you have the concept of a customer. Your customers can open Series-A accounts or Series-B accounts. (It does not matter what Series-A and Series-B are here.)
Time moves on, legislation changes, mergers/de-mergers happen, new competitors arrive in the market. Things change. Now, which of these scenarios is more likely? A) you need to modify the way the existing Series-B accounts work or B) you need to introduce a new class of account Series-C, with completely different behavior and business logic to the existing account types?
My experience has been that modifications of the latter variety dominate in the evolution of commercial IT systems. Now it can be argued that a good systems analyst would ensure that the system is designed to allow new account types to be created gracefully. The trouble with this argument is that it requires a crystal ball. Sometimes in system design you get lucky by double-guessing the future when you create business object interfaces. More often than not in my experience, you get burned. Your interface needs to change and when that happens, the dollar cost of modifying existing systems rises dramatically.
The solution to this problem in my opinion lies in rowing back from the intellectually pleasing but detrimental distinction between data and interface[1]. By way of illustration, here are three more paragraphs for you to read with your reality distortion field sensors raised. Normal service is resumed in the last paragraph.
Enterprise computing is simple really. All business data processing can be analyzed and decomposed into a set of so-called "resources". These are the fundamental real world concepts that make up your business (e.g. a customer, an account, a product and so on).
For each class of resources identified, we can create a set of documents (messages) that go in to and come out of the resources to perform business functions. We then further analyze the messages in terms of their overall effect on resources. Some messages will simply inquire about the state of a resource ("get outstanding invoices" message to a customer resource for example). Others will update the resource ("Add new machine" message to an assembly line resource for example.). Still others will delete the resource ("clear all" message to a shopping basket resource for example).
We then map these message classes onto an application protocol - HTTP. Essentially, this gives us standard plumbing - a standard interface -supported by all resources for the exchange of messages.
This encapsulation of complexity behind a simple message exchange pattern layered on top of a standard application protocol, makes it easy for developers to use business resources in their applications. Moreover, it allows the developers of the business resources to add extra message types as business needs change. By following some simple design rules[2], existing resources can be made forward compatible with this sort of change so that nothing breaks as the system evolves. Moreover, the loose coupling implied by the message exchange approach allows developers to use intermediating resources to gracefully "broker" complex modifications over time to minimize system changes.
Now doesn't that sound just great? I think so. Why is it a distortion of reality? Well, it is a distortion of reality because systems are not currently - by and large - architected this way. I suspect that will change though. Somewhere in the terminological soup of web services, REST, SOA, SOI, SOBA, ESB, MOM and Indigo, a new conceptualization of "business object" is taking shape and will incorporates at least some of the ideas presented here.
[1] Objects Have Failed
[2] Web Service and XML Extensibility and Versioning [pdf]