Object Reuse, David Chappell, and the Rule of the Least Common Denominator

David Chappell is speaking at next week's Toronto BizTalk User Group gathering. David is what you call an "industry luminary" with several well-read books and articles over the years, keynotes everywhere, and popular regular articles. His focus in recent times is on service-oriented architectures, principally Indigo, BPEL, and the Microsoft implementations, but the nice thing about David is that he's just as conversant with the J2EE / LAMP camp.

Recently, David wrote about "SOA and the Realities of Reuse." Most of the responses chimed along with the tune that object reuse is dead at most companies, and never worked well to begin with. The article begins:

Not too long ago, I spoke at a Gartner event where the keynote speaker posed a question to the audience. "How many of you work for a company that once had a large-scale object reuse program?" he asked. In a room with several hundred IT managers from the largest American firms, nearly every hand went up. He then made a follow-up request: "Please keep your hand up if your firm still has a large-scale object reuse program".

Only one hand remained in the air.

You can't deny observation, but I'd like to dissect David's conclusion that the "the barriers to pervasive reuse of business logic remain high." Just what are the barriers? Is it the extra time spent on design and construction? Is it the cost of an SOA engine like BizTalk? Is it the short-term laziness of developers who would rather write from scratch than understand what already exists? Is it because emphasis on reuse of business objects is misguided?

Like all industry-wide issues, the failure of object reuse is a mix of these conditions. From the design side: few architects are capable of implementing the provider design pattern, and fewer business objects fit it. The ASP.Net providers are the doorknobs, windows, taps and sockets of smart sites. Whenever there are three or more ways of implementing an object, the provider model might be useful. How often are there three or more ways of facilitating a business process? Unless your company is merged with two or three others, it's just not common and the effort is likely not necessary.

What about cost? Up-front enterprise-wide architecture is expensive and few managers can justify what appears to be a research project. BizTalk is an expensive platform. Rewriting or remodelling existing code is expensive.  And if the anecdotal response is "object reuse is a myth," then well, that would be the real nut to crack. When SOA is well-designed and applied appropriately, the cost can always be justified. But because so many team have screwed up in the past, perceived cost is now a barier to entry.

Does object reuse fall apart simply because developers don't have the discpline to sustain it? For sure. See any of Kent Beck's refactoring books; maintaining discipline is an ongoing process and few industries or IT shops demand it. Like Agile development, object reuse needs to be championed within the team or the least-common-denominator rule kicks in. Actually I'm not sure there's an actual "Rule of the LCD" so let's state it:

The Rule of the Least Common Denominator: When left to their own devices, people will do as they damn well please, despite (an often in opposition to) whatever artificial structures, guidelines or rules they have agreed to in the past.

The fact is that good design and development practices can seem arbitrary. Like kindness to strangers and empathy, there are some things people need to practice whether they mean it or not, before they can internalize why they would do these things naturally and for their own sake. If a developer is using an object for the first time in order to implement a new business capability, does he take the time to understand what is already there, or just look for the properties to be manipulated and add a method to make it happen?

Now on the table is the possibility that object reuse might be an arbitrary and misguided goal with a better alternative. It's what I believe to be the case, and further that it's the root of the other symptoms. Business people did not spend 3000 years thinking about "business objects" before computers, data set theory, and object theory came along. It's a square peg in a round hole.

Business-people think about doing business. And whatever your business is, is what your company is capable of. Describing a business function as a business capability doesn't add to, remove from, or abstract the function performed. It is thinking of a capability as an "object method" that blurs the link from the function to its implementation. And this is why well-intentioned object reuse and related SOA projects fail again and again. A flawed approach results in flawed design, and most objects are not freely swappable. Business capabilities rarely change, and their fulfillment can be swapped. By definition. It's an approach worth consideration.

What are typical capabilities? "Hire an employee." "Pay employee." "Take an order." "Ship a product." "Process a return." "Authenticate identity." The object is secondary, or at the least, closer to the database than developers should be living from day-to-day. Let's get back to business.

The success, for example, of providers in ASP.Net is not because of the objects. The objects are simply natural packages for the capabilities. The ASP.Net team chose to implement web-specific capabilities where there are three or more ways to implement the capabilities, and to which projects typically allocate half or more of their build-time (note these aren't the actual criteria used by the team, just my approximation).

There isn't an ASP.Net "sales order provider model" (how much do orders have in common between companies or industries?) or even a "base business object" class (where would you begin, and how is that diferent from Object?). Wisely, ASP.Net objects and providers address common capabilities for web sites, and only common capabilities for web sites.

The lesson: figure out your business capabilities. Group them into packages where it is natural to do so. When you feel like you're talking about objects and OOP rather than business, back off. If there are three or more ways your company fulfills a business function (and unifying these is not reasonable), consider the provider model.

This isn't new. If you want to learn more about a capabilities-oriented methodology, it's called Motion. Microsoft has a variant called Motion Lite which makes a reasonable introduction. Like most MSFT products, they didn't invent it, but they are doing a lot to bring it to the masses.

Back to David's original question. Do "the barriers to pervasive reuse of business logic" remain high? No. While the barriers to efficient object reuse may be high, the efficient mapping and implementation of business capabilites is achievable. Get to it.