Continue in 2 seconds

What's an Architecture, Anyway?

  • December 01 2004, 1:00am EST

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.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access