Project Manager's Guide To Middleware

Software Magazine, August, 2001 by Jim Johnson, Karen Boucher, Micheal Hicks

Not all middleware is alike. Project managers must understand the business rules and functional requirements of the project to ensure they are making the best choices.

In A.D. 324 the Roman emperor Constantine moved the empire's capital to Byzantium and renamed it Constantinople. He surrounded his new capital with high walls, built magnificent dwellings, and moved the people with rank and their families into the "New Rome." He erected a large hippodrome, along with great fountains, porticoes, and other beautiful adornments. In 1453 the Ottoman Empire defeated Constantine XI Palaeologos, thus ending the reign of the Byzantine Empire. However, between 324 and 1453, the Byzantine Empire saw hundreds of emperors, wars, and battles, and suffered thousands of generals. During a campaign, the empire's generals coordinated their attacks by sending messengers to the other generals. Initially, they would send only one messenger per general. So, if it took five armies to take a position, the general in charge would send out five messengers. But if only three messengers got through and only three armies attacked, the battle would be lost. The generals who did not attack would lose the ir heads. In this case, two of the original five messengers could have been captured, tortured, or killed for their pass code. Whatever happened to them was out of the general's control.

So they came up with a new scheme. They sent out multiple messengers who each had hidden codes. The messengers also had to return with a message from the other generals indicating that the message was received and understood. This became known as the Byzantine General's Algorithm and is the basis for all modern communication and middleware message systems.

Like the Byzantine generals, today's project managers know that properly applied middleware can have a high impact and a very significant contribution to technology infrastructure. It can be critical to a company's ability to execute and implement successful mergers and acquisitions. It can be key to allowing improved customer and vendor service and enabling a business to more closely manage commercial and supplier relationships. And middleware can play a major role in making IT flexible enough to respond effectively to market and customer demands. In fact, it can be the glue of integration and a distributed infrastructure that enables the "online" enterprise and drives the company value, market share, and profitability.

Still, knowing that middleware can help is not enough. Choosing the right middleware for a project takes careful evaluation. Not all middleware is alike, and there is plenty of confusion around the choices. Middleware providers have not helped this situation with their confusing marketing messages and mixed signals. What's a project manager to do?

Defining Infrastructure

Middleware provides infrastructure services. Infrastructure, though, is a word that gets thrown around quite frequently in the industry.

During Standish Group's annual executive retreat (CHAOS University), one workshop focused on infrastructure management and the surrounding problems and issues.

To define the term "infrastructure management," the groups first had to discuss what "infrastructure" means. Some attendees focused on "software infrastructure," others on "hardware infrastructure." They debated whether humans were part of the equation. What about electricity? Phone systems? The concrete comprising the building's basement? Surely all these things are considered infrastructure--or are they?

Many CHAOS University workgroups debated the management issues right away, but later discovered that the source of numerous arguments had to do with confusion over what exactly they were trying to manage.

However, there is no confusion over these truths: Standish Group research shows that over 70% of IT projects will fail or be seriously challenged. The smaller the project, the greater its chance of success. Through the thorough examination of 100 applications, Standish Group discovered that on average 70% of application code is made up of nonbusiness rules or infrastructure code. This code is difficult to write and is typically wrought with challenges.

By providing infrastructure services, middieware decreases the amount of difficult custom code developers need to write, making projects that use middleware naturally smaller in scope. In fact, research shows that projects that use commercial middleware solutions have a lower project failure rate than those that do not.

This is something to seriously consider. Today only the foolhardy venture to design, build, maintain, and support their own custom application infrastructure. Standish Group research indicates that there is a 0% chance of an organization completing any large transaction or online project on time and on budget using middleware infrastructure created in-house. Life expectancies aren't much better.

The "best practice" solution is, most often, commercial middleware from established, viable, and sustainable independent software vendors. Taking this path significantly reduces application and project risk. The risk of building middleware transfers to the software vendor, which is focused on quality and success in both its customers' companies and the market.