Portals eNewsletters Web Seminars dataWarehouse.com DM Review Magazine
DM Review | Covering Business Intelligence, Integration & Analytics
   Covering Business Intelligence, Integration & Analytics Advanced Search

View all Portals

Scheduled Events

White Paper Library
Research Papers

View Job Listings
Post a job


DM Review Home
Current Magazine Issue
Magazine Archives
Online Columnists
Ask the Experts
Industry News
Search DM Review

Buyer's Guide
Industry Events Calendar
Monthly Product Guides
Software Demo Lab
Vendor Listings

About Us
Press Releases
Advertising/Media Kit
Magazine Subscriptions
Editorial Calendar
Contact Us
Customer Service

Enterprise Architecture: The Holistic View:
Abstraction Leads to Simplicity

online columnist JP Morgenthal     Column published in DMReview.com
June 23, 2005
  By JP Morgenthal

Abstraction is an amazing process once you master the concepts behind it. As Einstein said, "Things should be as simple as possible and no simpler." Through abstraction we reach simplification. In developing information technology solutions, we often use abstraction as a means to gain reuse and limit duplicative investments. For example, creating an abstraction layer over our data allows us greater freedom to use that data in many processes.

Other examples of abstractions that demonstrate simplicity as a result include database views, modular coding and object-oriented architecture and design (OOAD). OOAD is all about simplification through the creation of a taxonomic structure that defines the interactions between classes in the taxonomy leaving the rest of the behavior to the classes themselves. Through this technique new classes can be added into the taxonomy at anytime allowing classes to be defined on an as-needed basis, but not limiting the possibilities of new types of classes and interactions at a later time.

Some might even consider OOAD to embody the concept of loose coupling - a concept widely touted around service-oriented architecture (SOA). OOAD shares other concepts with SOA, such as contract-based design, in which the item being designed is represented by a well-defined interface. Other shared concepts are data hiding and polymorphic behavior. The concept of data hiding means that the entity will hide the implementation specifics and polymorphic behavior is a fancy way of stating that two entities with the same interface, but that provide different implementations - and functions - can be used interchangeably.

In fact, the only real difference between these two philosophies is the concept of inheritance. SOA proscribes to a philosophy of composition rather than inheritance. With composition, an entity is completely consumed by the composite item, where the consumer will use the parts of the original entity that it requires. Inheritance states that the new entity inherits all the characteristics of the parent, except where specifically overridden.

With all this overlap, why does it seem the SOA community rejects and rebuts many of the comparisons between SOA and OOAD? There are plenty of reasons why this occurs, but answers would merely be speculative. For example, it could be because OOAD has an associated history of requiring expensive resources in order to use effectively or simply because others may not deem SOA as a big enough innovation to warrant investment.

Regardless of the reason for the dissonance between these approaches in the community, there is a need for understanding of the common abstraction that is required to be successful with either one. Hence, the skills required to deliver a good SOA are the same skills required to design a robust object-oriented application. This is a key point that the dissonance usually drowns out that the IT community needs to understand.

In my book, Enterprise Information Integration: A Pragmatic Approach, I focus part of the chapter on modeling on the discussion of various modeling techniques. When it comes to discussing the differences between entity-relationship modeling and OOAD modeling, there was very little that I could point out that was different about these approaches, with one exception - OOAD models have implied behavior. This showed me that all common information technology modeling techniques are relatively similar in reach and scope; especially those that deal with modeling complex relationships. Thus, both OOAD and SOA modeling share many common attributes. After all, how many different ways can you show an "is-a" or "has-a" relationship?

Ultimately, my review of modeling techniques also demonstrated to me that abstraction is fractal by design. That is, abstractions on a larger scope are comprised of smaller, but identical abstractions on a smaller scope. Thus, the entire universe must ultimately share one common root abstraction. So, one could say that it is inevitable to find a commonality between SOA and OOAD. True, but the shared abstraction for SOA and OOAD is perhaps one, maximum two, degrees apart. Indeed, the taxonomic structure of classes found in OOAD is now, in part, now being defined in the Description, Discovery and Integration (UDDI) registry - a core component of many SOA implementations.

I believe that the key lesson to be learned from the relationship between OOAD and SOA is that abstraction of behavior and data are good things. Additionally, OOAD and SOA are not so far apart if we view them from a perspective of achieving abstraction and definition of business semantics. They are both components of a much larger picture that started with leaving behind procedural programming for OOAD - which is abstraction making things easier to absorb and utilize.


For more information on related topics visit the following related portals...
Enterprise Achitecture.

JP Morgenthal is managing partner for Avorcor, an IT consultancy that focuses on integration and legacy modernization. He is also author of Enterprise Information Integration: A Pragmatic Approach. Questions or comments regarding this article can be directed to JP via e-mail at morgenthaljp@avorcor.com. Do you have and idea for a future Enterprise Architecture column? Send it to JP; and if it is used, you will win a free copy of his book.

E-mail This Column E-Mail This Column
Printer Friendly Version Printer-Friendly Version
Related Content Related Content
Request Reprints Request Reprints
Site Map Terms of Use Privacy Policy
SourceMedia (c) 2006 DM Review and SourceMedia, Inc. All rights reserved.
SourceMedia is an Investcorp company.
Use, duplication, or sale of this service, or data contained herein, is strictly prohibited.