Planning your middleware strategy Architecting the software that moves information around in your network By Jason May

April  1998

So which architecture is better? Two-tier, three-tier, n-tier? This month's columnist, Jason May, calls this debate "ridiculous." According to him, architects should be thinking of greater things as they chart their middleware strategy for the 21st century.

Be sure to check out Jason's middleware taxonomy to get the big picture of what the various types of middleware -- from ftp to to DCE to object transaction monitors -- are really good for. (2,000 words)

Mail this article to a friend

Foreword
Thanks to all of you who wrote in with comments on last month's column. There is obviously a great deal of interest in IT architecture out there, and it may take us a while to cover all the issues raised.

In last month's column, I mentioned the "band-aids" that are often deployed to glue together various application architectures within the enterprise. This month, Jason May expands on this idea, with an introduction to that oft-misunderstood technology known as middleware.

Different types of middleware can affect the design of an individual application, provide an infrastructure for groups of applications, or allow for enterprise integration between disparate technologies. All IT professionals work with applications and data, but architects are the ones who must make it all work together.

--Kara Kapczynski

electing the right middleware for your applications is a major decision for any enterprise. In fact, middleware is so important that people often mistakenly use it as a synonym for architecture.

Now, middleware is very important, but it isn't the same as architecture. I define middleware as follows:

Middleware is software that moves information from one place to another.

This definition covers a lot of ground. It includes message-oriented middleware (MOM), remote procedure calls (RPCs), transaction monitors, object request brokers (ORBs), replication technology, publish & subscribe, push technology, and all sorts of hybrid solutions.

Architecture, on the other hand, covers even more ground. Besides ensuring that your clients can talk to your servers, architecture encompasses many other issues, including data storage architecture, systems management architecture, fault tolerance architecture, security architecture and so forth. There's a lot more to the "A" word than defining your corporate MOM/RPC/DCE/CORBA/DCOM/whatever strategy.

A thorough discussion of all the available middleware options and when to use them would take up more space than is available for this column. But I have put together a few rules of thumb, based on my experience, that should help you decide which middleware options are most appropriate in a variety of situations. I call it my middleware taxonomy.

Tiered architectures
When client/server technology first started making inroads into corporate computing environments, your middleware architecture decisions pretty much ended once you had chosen between two-tier or three-tier middleware for your application.

This was a major decision because it was typically one of several firsts for the organization: first Unix server, first relational database, first graphical user interface, first line of code in a language other than Cobol. As we'll discuss later, this simplistic view of architecture no longer suffices in today's enterprise.

The majority of business applications today are implemented in either a two-tier or three-tier configuration, using a wide variety of software alternatives for the communications glue. A ridiculous debate has continued on and off for several years regarding the merits of two-tier "versus" three-tier, as if there was clearly a benefit to one over the other. Experienced architects realize that every middleware option has strengths and weaknesses and that neither one of these configurations is appropriate in every single situation.

Perhaps the most common client/server middleware architecture for business applications today is the two-tier architecture illustrated below.

Two-tier architectures are great for a wide range of business applications. Most reporting applications are two-tier. Most transactional applications (e.g., reservations, customer service, order entry, inventory management) can be adequately implemented in this manner, provided they don't need to support more than a hundred or so concurrent users.

Another common configuration is a three-tier architecture.

For applications that have extensive or sophisticated internal functionality, or business logic that is not tied directly to the user interface, the three-tier option is usually preferred. For example, it would work well in a procurement system for a large aerospace firm, where there are numerous rules to be checked before a purchase requisition can be approved.

Often a two-tier application that works fine for a smaller firm won't scale up to handle more concurrent users and larger transactional loads. Three-tiered architectures typically suffer less from such scalability problems.

Spaghetti anyone?
For those organizations that are experienced at developing client/server applications, there is a dark side to the middleware selection process. Just as happened in the Bad Old Days of icky legacy mainframe Cobol code, many firms have found themselves in an environment where their strategic client/server applications are not integrated and don't share infrastructure.

Some large enterprises find themselves facing forests of applications developed using incompatible middleware software, much of which is gradually becoming obsolete. And as the need for increased communication between these applications evolves, additional back-end spaghetti is added making the whole mess even more confused, and causing support costs to go through the roof.

Question for the class: How many tiers does the following architecture have?

When might you have something like this? Here's a possible scenario: Conglomerated Widgets (CW) has been in business for many years. Their widget manufacturing and inventory systems all run on the mainframe. Order entry has been developed in Oracle on Unix. It checks inventory at order time via the DB2 gateway. Now CW wants to allow their customers to place orders via the Web.

Presto! Middleware spaghetti.

While there might not be many applications that look like this today, this sort of configuration is perfectly reasonable for sophisticated business applications in today's complex technology environment. Development along these lines is underway within many large IT organizations.

The HTML front end can run with zero install on minimal end-user hardware, which means low maintenance costs on the desktop. You can provide sophisticated functionality through use of rich data types that can be supported by most browsers, and you can get satisfactory transaction throughput and latency if you design carefully and make the necessary investments in hardware and network infrastructure.

Note that two-tier and three-tier applications can nest comfortably within this larger middleware environment. A reporting application might run directly off the central database server. Customer service representatives might use a Windows GUI (graphical user interface) application that communicates via a transaction monitor to the same database. With careful design, all these applications should be able to share resources like databases, business logic, and security rules.

A sea change
Take a careful look. This type of middleware environment will be the norm for most large enterprises within five years. The sophistication of the corporate software portfolio -- including packaged enterprise applications such as SAP and PeopleSoft, custom business applications, data warehouses, internal and external Web services, and so forth -- will demand such a configuration.

Take another look. The technical skills required to design and administer this environment are different from those that most of us have on staff today. You can't just whip together something like this overnight; serious architectural planning and design is required.

It's not necessary to scrap your existing infrastructure and build a new architecture from scratch. Organic development from an existing base is a valid approach, but planning is critical.

But why would you build this sort of architecture? Well, it offers a host of benefits:

• A common infrastructure allowing applications to share data or function (e.g., all applications should be able to invoke the same product-number validation function)
• A more efficient use of technology resources (e.g., pooling of database connections)
• Looser coupling of distributed software components allows for greater rate of change (so you could change your product-number validation function without rebuilding all the front-end applications)
• More points of control for monitoring and administration (e.g., track concurrent user sessions or database transactions)
• It is scalable to support new application front ends (think Web)
• Reuse of technical knowledge within the enterprise through adherence to common middleware standards

If you fail to think through your middleware environment from an enterprise standpoint, a dire future awaits you: IT budgets consumed by support costs for isolated applications linked by mazes of batch extracts and file transfers, risky dependence on the few individuals who actually know how the pieces hold together, and the inability to release new applications in a timely fashion because of the effort required to hook new systems into the existing environment.

Asking the right questions
We need to get past this "how many tiers" business, and focus developing a quality architecture for the business enterprise. The design process for a comprehensive middleware architecture should not be rushed. It requires input from all affected parties, and must be driven strongly from a clear business case.

Here are some questions to ask:

• For which applications is rapid user response time (low application latency) most critical? For these, you want to streamline the data path between the data source and client presentation.
• How quickly must data flow from operational sources through to a warehouse environment for reporting and analysis? What is the business impact of any blockage in the flow of data? These answers help you to schedule batch jobs appropriately.
• Is it necessary for all applications to have an up-to-the-minute view of all corporate data, or are out-of-date business views acceptable in certain cases? How much discontinuity between applications is tolerable? Here you need to make decisions between providing access to live data sources or implementing tape-delay replication strategies.
• What is the capacity -- in terms of users, transactions, data volumes, calculation complexity, and other metrics -- that can be handled by each element of the architecture? Which components are likely to be stressed most heavily? With this information, coupled with metrics for your applications, you can determine where to focus investment in physical technology resources like disk space, CPU power, and network capacity.
• What degree of management infrastructure is needed for your environment? How quickly must support staff be able to recognize and respond to events and alerts?
• How much downtime can be tolerated at each component of the infrastructure? This drives requirements for fault-tolerance and failure recovery solutions.

• Can my support organization handle this beast? What will it cost to expand and train my IT staff to support this?

When you have thorough, quantitative answers to these questions, business priorities become clear. Appropriate middleware configurations for individual application requirements should be driven by these business considerations. With this level of understanding, applications can be built to mesh with an overall enterprise design.

Middleware technology must be managed as a corporate IT asset, just like hardware, networks, and databases. Individual applications have a life cycle -- introduction, revision, maturity, obsolescence, and retirement -- but careful attention to enterprise architecture can allow applications to die quietly without leaving software litter throughout your systems.

Resources

• Last month's IT Architect column, "The world of the technical architect" http://www.sun.com/sunworldonline/swol-03-1998/swol-03-itarchitect.html

About the author
Jason May is a principal architect at Cambridge Technology Partners. Reach Jason at jason.may@sunworld.com.

If you have technical problems with this magazine, contact webmaster@sunworld.com

URL: http://www.sunworld.com/swol-04-1998/swol-04-itarchitect.html
Last modified:

A brief middleware taxonomy