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

Intelligent Solutions:
What's an Architecture, Anyway?

  Column published in DM Review Magazine
December 2004 Issue
  By Claudia Imhoff

Claudia wishes to thank Colin White of BI Research, Rick Robinson of IBM and Frank Cullen of Blackstone and Cullen for their insight and useful input into this column.

In the IT world, we thrive on buzzwords and acronyms. You can bet that when a term or acronym becomes popular, everyone will jump on it - from the industry pundits hoping to make their name to the vendor community hoping to boost sales, to the columnists trying to understand it. And they'll "adapt" it to suit their needs, interests or offerings.

So it is with SOA or service-oriented architecture. I don't know about you, but I was confused at first by the vast array of definitions and implementations surrounding this term. Thus, I asked some trusted friends to see if they could make sense of it all for me. Here's the scoop.

First, don't be confused. SOA is just an architecture. An architecture, whether it's the Corporate Information Factory (CIF) or SOA, is only a logical or conceptual view of something. In the case of the CIF, it is a view of a business intelligence environment showing all the logical components such as a data warehouse, operational data store, data marts and ETL (extract transform and load) processing. For SOA, Rick Robinson says that it is a view of the business in which the business rules or delivery of services are "decoupled" from the applications or systems that provide these services. The key to the architecture is the physical separation of the business services or rules from the transport layer or plumbing that delivers them. The application or business process itself becomes a coordinated set of services as well (e.g., processing a customer order, allocating inventory, managing data quality and so on).

How you physically implement either of these architectures is, of course, up to you. You must decide what technologies or plumbing must be in place to deliver either business intelligence or business services. Will you have virtual or physical marts and operational data stores (ODSs) in your CIF? Will you have bundled services called by multiple applications or separate services called independently by the various applications in your SOA?

Secondly, SOA is still in its infancy, and many people continue to confuse the architecture with a technology. SOA is not a technology like Web services. Web services is one of several technologies that can be used in the physical implementation of your SOA. Just as the CIF is not one particular database or platform, the SOA will be made up of many interoperable components. Therefore, separate the logical or conceptual architecture from the physical or technical one - you'll need both.

Third, SOA is not a particular standard. It certainly requires that standards be used in the interface between business service and business applications. This is, after all, the "glue" that makes the entire architecture work. However, the final list of the standards to be used is still being fought over and developed. According to Colin White, the goal of SOA is to interconnect the loosely coupled SOA components using common and open standards. The question, however, remains - whose standards? COBRA, SOAP, XML, WSDL or some other alphabet soup yet to be developed?

Finally, continuing with this standards theme, the whole concept or architecture should be based on the idea of interchangeable parts in uniform layers. Frank Cullen gives an SOA example of a JAVA programmer and a .NET programmer both programming for Web services but deploying their applications in a fashion that allows them to pass through a vendor-independent gateway or layer. This is where an enterprise generates its benefits such as enabling "best-of-class," assumed lower costs and higher effectiveness.

Getting Started

Today, most of our business rules are "hard-wired" into the various applications used throughout our enterprises. This makes them difficult to understand and, more importantly, to manage. Changing a business rule means going into the guts of an application and changing its code. Not pretty. Separating the business rules from the processes that use them is a key step in starting to migrate to a SOA environment. It is this separation that gives the architecture its flexibility and reusability. But how do you get started and where?

Colin White had good suggestions:

  1. First and foremost, understand what SOA is and what this architecture can do for your organization. Read about the architecture and then develop your own customized version of it for your company. This definition must include what it will mean to your enterprise, what benefits, what improvement, etc.
  2. Once you can define SOA in your environment, you now need to create a strategic plan. Which parts of the organization are ripe for this type of architecture? Which department or set of processes will benefit the most from the migration? And so on.
  3. Identify which systems are the first ones to undergo the transformation. You can then determine the proper technology to use. Perhaps your first project will be to implement "wrappers" around your older technologies to buffer the business rules from the underlying applications.

As a final thought, all my friends stated that the architecture and ensuing technologies are very new and have not yet reached their full potential. You need to understand that SOA today could be called "jello-ware" in that SOA is certainly a real architecture, but the current definitions lack a lot of structure. The full nature and benefits of implementing an SOA environment are not yet known, but we are on the cusp of learning them. Some companies are charging ahead full-bore with their migrations; others are hanging back to see what happens with the front-runners. Time will tell whether this jello-ware firms up into a solid, sustainable environment.


For more information on related topics visit the following related portals...
Business Intelligence, DW Administration, Mgmt., Performance and Enterprise Achitecture.

Claudia Imhoff, Ph.D., is the president and founder of Intelligent Solutions (www.intelsols.com), a leading consultancy on CRM and business intelligence technologies and strategies. She is a popular speaker and internationally recognized expert and serves as an advisor to many corporations, universities and leading technology companies. She has coauthored five books and more than 50 articles on these topics. Imhoff may be reached at cimhoff@intelsols.com.

View Full Issue View Full Magazine Issue
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.