[ | smalltalk dot org ].
Community and industry meet inventing the future.
Achilles Heal? Tower of Babel? How about Communication?
written by Peter William Lount
version 1, 20041203 13:25pm PDT

Birdman's Land writes about what he calls "OO Programming's achilles heal":
"When everyone defines their own objects, then all [Object Oriented programming] does is bog you down trying to convert between two mismatched items."

He goes on to give the following illustrative example:
... when adding to a menu in Visual studio, an item is of type Microsoft.Office.Core.CommandBarControl Which is different than System.Windows.Forms.MenuItem.

This isn't an example of any Achilles Heal of Object Oriented Programming. It's clearly an example of a large complex and convoluted system that has more than one way to represent something, in this above case a menu item. Obviously if these two objects are identical in behaviour and information stored and the context they operate in then the programmers who devised the system need to go back and understand their existing libraries before adding new components into it.

If this is an Achilles Heal then it's in general about programming as it is possible for it to occur with any style of programming (procedural, object oriented, functional, etc...). You can make a mess in any programming system!

However, I don't that that this issue it's an Achilles Heal of programming as it's not something that's going to stop programming from progressing forward. How can this be?

Central to this issue is that there are multiple ways to represent information and this is especially true in very large information systems regardless of the field. For example, while I was consulting at Fannie Mae thirty plus teams attempted to find out if there was a common definition of a "loan" (Fannie Mae provides loans to Banks and other financial institutions in the USA). What you'd think would be a simple "business domain object" couldn't be more complicated. While a few of the groups could have possibly merged their object definitions the vast majority of the groups were in sufficiently different "domain" areas that a common definition of a "loan" was practically impossible. Even if it was remotely possbile for a powerful domain object that would be flexible enough to represent all of the different "meanings" of "loan" the practical realities of their business and timelines for producing results meant that it wasn't likely to happen then or now.

As much as many may hate to hear it, Microsoft is in the same boat as Fannie Mae due to the ever increasing size of their systems and the variety of application domains and contexts that they must operate in.

However, the problem remains for Fannie Mae that the different "applications" groups systems need, on occasion, to interoperate with each other in the processing of loans. Since the definitions of their "loan objects" is quite different they have some challenging "semantic" problems to work through. Essentially what a loan is changes even during many all flow through steps of a single homeowner mortgage application through completion ( one way or another).

For example, there is a business rule that states that loans can't be assigned a unique loan number before a certain processing step has occurred. This makes that loan difficult to process through software that expects a loan that has a unique loan number assigned.

Actually the above business rule example illustrates that one of the major differences the groups at Fannie Mae have in their "loan objects" is not just in the information they need to represent but also in the varied and often conflicting business rules that are applied to the "loan objects". It's also important to note that many of the information repsentation differences between the various groups actually derive from the differences in business rules, loan processing policies and analysis that need to be applied to the loan applications. Change a business rule and your information representation and programming needs to change in, potentially, multiple places as well. Do this for over thirty domain groups within a large (and heavily regulated) organization and the fun really starts to fly. Now add in all the Banks and financial instutions that Fannie Mae needs to interoperate with and a real party is happening.

In the construction industry I performed research into the "semantic meaning of data" for the National Research Council of Canada and a construction company that had four decades of experience with this issue ( the senior member of the construction company began programming computers for civil engineering in the mid 1950's)! The two years of research was, in part, focused on how to build converters between different file formats, object definitions, record definitions, etc.. so that disparate systems can be "joined" together into a larger system.

Half of the problem is in simply being able to read the data from other systems. This is easily solvable with systems like CORBA and XML.

Tackling the other half of the problem is much harder since it's a least ten times more difficult and basically comes down to what does the information mean? Does a "length" in system "A" really mean the same as a "length" in system "B"? Maybe "side length" in system A is what "length" in system "B" means. Maybe system "B" doesn't have a means of representing the "length" that you are speaking of, maybe it does but if it uses a different "precision" and you may be out of luck, or if it uses different units and you must convert (from inches to centimeters for example). Maybe it uses a different form of math to represent the information.

Recently Nasa learned this first hand the hard way when it slammed an otherwise perfectly good multi-million dollar space probe into the surface of Mars due to confusion of metric and imperial units. Pancaking a probe into another planet, now that's a hard lesson to take.

While having a "unit based numbers" in your programming language, libraries, and environment might have helped Nasa with their case, unit tagged numbers won't solve the "representation mismatch problem".

One of the most well known of information mismatch problems in computer science is the "Relational Database" to "Object" problem that numerous programmers have attempted to solve over the last few decades. At the core of this problem is a mismatch of how the information is represented. Basically relational tables use "foreign key fields" to link or "relate" information in one table to another while objects use direct (memory) pointers from one object to the next. Converting tables to objects and back again rarely works well especially in real world business applications. Putting objects into a relational tables is kind of like taking your car completely apart into all of it's separate pieces just to park it into your garage at night. You garage (the relational database) has neat compartments for all the parts even those that don't fit well. Imagine the trouble and time it takes to correctly go through this process every time. Imagine putting the car back to gether again!

In the construction field it may be desired to have a "structual bridge stress" calculation system link it's road alignment data to a "bridge design" program (for an example of the final results of a real Smalltalk based bridge system see MetamericBridge). However, since there are many such programs in the constuction industry (and new ones being created all the time) in most cases these systems will only be connected together for one or a handfull of projects.

Essentially when linking systems there will be information you are not interested in, information that overlaps, that might also be redundant or possibly even contradictory, and there will be information gaps that need to be filled in either by on the fly calculations, manually by a domain expert, or the sysetms will need to be upgraded to include the missing information so that it's appropriately dealt with in it's proper domain contexts.

The attempts to create "domain specific XML defintions" for various industries is laudable and is a step in the right direction. However, as with a single organization like Fannie Mae the challenges of actually defining an XML Domain Specific Schema that meets all the needs is not likely. Even if it were, would people understand the subtlties and neuances of all of the complex features and capabilies that rich domain schemas provide such that they won't make mistakes?

Which brings us back to the original "Achilles Heal" accusation made of Object Oriented Programming. The best way to resolve these issues is clear communication (including well written and upto date documentation) within your team, projects, organization and between your organizations that must interoperate.

In the case of the complexity of Microsoft's systems, I don't know the specifics of those two "menu item" objects (maybe there is a valid technial reason for the two similar components, maybe now), but either deal with it or get Microsoft to clean up their systems! What other choice of solutions do we have? A primary skill of anyone designing or implementing information systems must learn is working with "knowledge representation" in it's various forms. Flexible and finely tuned knowledge representation and represetnational transformation skills, experience and expertise provides our clients value that they won't find elsewhere. Some might say that this problem isn't an "Achilles Heal" but a "Tower of Babel" of different and conflicting information representations. I'd say it's neither. I'd say it's part of the job of systems designers and implmentors to work with people to link their systems together in ways that work. I'd say the solution is communication. I'd say that's a huge part of the value we can bring to a venture or project! Oh, by the way this issue is independent of the programming language that you use although interoperation between programming langauges is often mistaken as the cause of complexity in systems integration work.
Copyright 1999-2010 by Smalltalk.org™, All Rights Reserved.
Tuesday
July 29 2014
Travel Adventure

Costa Rica

El Salvador

Guatemala

Honduras

Panama

Enjoy a tropical vacation in the sun, surf, in the jungle for adventure, yoga and massage for relaxation or learn the culture, history and langauge. Visit, live, work, play, retire. Enjoy.

Central America
Interoperate.org, the place to find out how to interoperate.
Google
Web
Smalltalk.org

64bits.net AMD64, Intel Pentium EM64T, Intel Itanium
Meet other Smalltalk people, contribute, learn, earn.
lingoize.me
On speaking languages
naturally with ease
aiming for fluid fluency.