Achilles Heal? Tower of Babel? How about Communication?
written by Peter William Lount
version 1, 20041203 13:25pm PDT
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
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
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.
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
). 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
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.
1999-2010 by Smalltalk.org, All Rights Reserved.