Infrastructure SuperhighwayThe U.S. interstate highway system is a helpful analogy for expressing the strategic value of investing in information infrastructureBy Paul Timberlake
Few would argue against the propositionthat the United States interstate highway system has made the country stronger and more competitive. The ability to move goods among cities, towns, or states in hours or days as opposed to weeks is as important to the economy as the goods themselves. It’s hard to imagine life without the interstate highway system; however, 50 to 60 years ago, people could scarcely imagine life with that system. At the time, two-lane, meandering state roads connected isolated cities and towns. There was agreement on the need for better roads, but making that need a national priority and achieving the necessary consensus to address it was a long and difficult process. The infrastructure connecting today’s enterprise business systems — a mix of point-to-point, file-based interface techniques connecting diverse, standalone application systems in batch mode — is in many ways analogous to U.S. roadways in the 1940s. Most of these interfaces were built as sideline activities to other projects. The result is a set of short-term, tactical integration solutions. This approach to integration slows business-process responsiveness, is difficult to manage, and is inflexible. In effect, it reduces a company’s ability to respond to and adapt quickly to business demands. The goal of supporting new and evolving initiatives is making the need for a better enterprise “system of roads” clear; enterprise application integration (EAI) is the contemporary term for this idea. However, selling an organization on the need to invest strategically in the integration infrastructure EAI embodies can prove as difficult as selling Congress and state governments on the need to invest in an interstate highway system. History is our best teacher, so the story of the interstate highway system is an interesting lesson in the importance of building infrastructure and how difficult such investments can be for organizations to make.
The Road Less TraveledEAI and the interstate highway system share many traits. First, they are both about infrastructure; they are the means to an end and not ends in themselves. They cost time and money to build, and they’re often taken for granted. Second, both are about improving connectivity on a broad scope. Just as an interstate highway system ties cities, towns, and states together and is national in scope, EAI is about connecting many application systems together across entire enterprises. Finally, in the process of acceptance and implementation, they cross similar organizational, political, technical, and geographical boundaries. From its inception, the interstate highway system was designed to improve transportation efficiency for commerce and, to a greater extent, to support military needs. As early as 1939, President Roosevelt recommended a system of direct interregional highways to support national defense and growing peacetime traffic. The contemporary road system was indirect and unable to accommodate military vehicles. World War II and, later, the Korean War inspired a new sense of urgency to complete a national highway system. Dwight D. Eisenhower, a major proponent of the interstate highway system, knew well the advantages modern direct roadways gave a military force. He experienced this advantage first hand with Germany’s autobahn — first on the defensive as the Germans used the autobahn to move their troops and supplies, and later on the offensive as he moved his own troops on these same roads. The best analogy to this urgency in business today is e-business. E-business is forcing companies to embrace the fact that they are part of an electronically connected business community. Business systems, shielded with manual and batch processes, can no longer remain isolationists in this environment. These systems must share their information internally with other applications, externally through Web front-end applications, and with customers, suppliers, and business partners through business-to-business (B2B) exchanges. And this exchange must occur at an even greater pace than in the past. The trend is clear: the degree and tempo of interapplication integration is increasing within and among companies. These developments reveal how inadequately connected core business systems are today and how ill prepared the current infrastructure is for the future. The technologies embodied in EAI, such as intelligent messaging (see sidebar, “Declaration of Independence”), are the best solutions for creating open, interconnected application systems. However, neglecting or minimizing the need to invest appropriately in infrastructure is easy. After all, it’s just infrastructure, which typically doesn’t carry a high priority. The hype surrounding Web front-end and e-commerce applications, in comparison, tends to attract more attention and budget dollars. Second, simply thinking of adding yet more interfaces to a growing mix of application systems can be painful in itself. This “pain factor” puts some organizations into denial. And finally, there’s the issue of simply agreeing what to do about the problem. These issues are similar to those facing federal and state government officials between the late 1930s and mid 1950s. What they did during most of this period is typical of most organizations: They appointed committees and studied the problem. Although their intentions were good, the commitment to action was disappointing. To their credit, the committees did lay out most of the design standards that typify interstate highways today: four-plus lanes, controlled access, and above-grade crossings. These standards were far-reaching as well, in that they stipulated that interstate highways were to be constructed based on traffic levels estimated 20 years into the future. What was lacking, however, was strong leadership to make the proposed interstate highway system a priority. Instead, most of the implementation and funding were left to the individual states. Most states found it difficult to direct federal aid and their own highway funds toward construction of an interstate highway system. Many complained about the way the federal funds were being apportioned; others complained that the design standards were too high. Some states eventually decided to “do their own thing” and built toll roads in the interstate corridors. As expected, progress was slow. From 1938, when the first feasibility study was commissioned, to 1953, when President Eisenhower took office, the government spent $955 million on building little more than 6,400 miles of highway. Of that, only 24 percent met interstate design standards! It wasn’t until President Eisenhower took office that the interstate highway system finally came into its own. Eisenhower brought leadership, vision, and a commitment to action that had not been present before. One of his first actions after taking office was to make the interstate highway system a national priority. This decision had an immediate effect because the Federal Aid Highway Act of 1954 increased the interstate system funding sevenfold from the 1952 level of $25 million to $175 million. Later in that same year, President Eisenhower called on the state governors to embrace his grand plan for a national system of highways and a bold funding level of $50 billion over 10 years. In early 1955, the Clay Committee, appointed by the White House, forwarded a report to Congress recommending a more modest $27 billion. More important, however, it recommended that the states contribute only $2 billion of this amount because of the interstate system’s national importance. These efforts helped build the necessary momentum. In summer 1956, Congress passed a new Federal Aid Highway Act, which essentially kicked off the interstate highway system as we know it today. This legislation included most of the important principles proposed by the Clay Committee, namely: the necessary funding level ($25 billion over 12 years), and that the bulk (90 percent) of the funding was to come from the federal government. The financing mechanism was the Highway Revenue Act of 1956, passed three months earlier. This act increased the gas tax a few cents per gallon and directed a portion of the revenue to fund the interstate system. The combination of these two pieces of legislation finally completed the interstate highway puzzle and cleared the path to make it a reality.
Repeating HistoryThese historical events hold many lessons for business organizations; if you recognize the need for a better road system in your organization, use history as a guide. First, some goals — such as interstate highway systems and EAI — are so important to the collective whole that they deserve high priority. Consider, for example, what our national highway system would resemble today if implementation and control had been left in the hands of the states. It is doubtful it would be nearly as effective or far-reaching in its design and applicability. Thus, the goal of any EAI initiative should be to create an enterprisewide infrastructure for the long term — not necessarily for 20 years, but far into the future nonetheless. Second, a central EAI group offers the best platform to launch such an initiative. Analogous to the federal government in its scope and authority, this group should have an enterprisewide scope and be empowered to authorize and implement the necessary standards and technology across your organization’s platforms and systems. This group functions to evangelize the benefits of the technology and how all application groups can use it best. It also provides the leadership and vision that motivate the application groups to embrace the infrastructure and not invent or reinvent their own solutions. Such a group could also serve as an implementation arm focused on delivering and supporting the new breed of integration solutions for the enterprise. Third, a detailed study and master plan are not necessary to get started. What is necessary is an agreement on the technology and standards or guidelines for its use. For example, the standards published by the Bureau of Public Roads in 1945, which became the basis for interstate design, were more functional than technical. They allowed sufficient leeway in implementation, but were clear on the desired outcome. Furthermore, you should keep in mind that all the pieces of the EAI puzzle may not be available today and may need to be built in the future. Finally, the realization of a pervasive EAI infrastructure doesn’t happen overnight. We enjoy the benefits our interstate highway system today, but it took time to build and is still undergoing construction. Pilot projects are useful and necessary to demonstrate benefits and gain consensus within an organization. EAI, however, should be viewed and supported as a strategic long-term mission.
Hit the PavementThe interstate highway system had a dramatic impact on the United States over the last 50 years. Although its original motivation centered on national defense objectives, the actual application has been far from defense-oriented. Historians have also shown that interstate highways have had a significant influence on U.S. culture. Given the similarities I pointed out earlier, it is easy to postulate that EAI will have similar ramifications within organizations. For example, once an organization buys into the EAI concept and begins using the technologies for more and more of its system integration needs, the value of the infrastructure grows. Integration and business scenarios once considered impossible or impractical with traditional techniques will fall well within the scope and capabilities of an EAI infrastructure. Moreover, new and unanticipated uses of the infrastructure will inevitably begin to surface. The whole paradigm of application integration changes; diversity in your application systems can begin to be seen as a competitive advantage instead of an impediment. The important point is to start earlier rather than later. DECLARATION OF INDEPENDENCETHE RIGHT INFRASTRUCTURE APPROACH MAKES ALL THE DIFFERENCE FOR BUSINESS FLEXIBILITY Intelligent messaging provides the strong, loosely coupled infrastructure needed for connecting application systems into effective business processes. It is the “glue” that makes disparate application systems easier to connect and more flexible and adaptable to evolving business demands. The term refers to the use of a messaging-based architecture in combination with an integration broker. Messaging provides an assured data communication medium; an integration broker provides data transformation and content-based routing (intelligent message transformation and routing) for the messages. What makes intelligent messaging a better integration approach than file-based, point-to-point, batch interfaces? Integration is about supporting and automating business processes — whether they are order-to-cash, procurement, or anything else. One application system rarely hosts a complete business process across an entire organization; more likely, multiple application systems on different computers are involved, even when ERP systems exist. In an ideal world, the information supporting a business process flows among application programs in response to business events, such as a user entering a transaction from a workstation, or simply implied from a database update. The exchanged data is related to the event and is typically small and transactional in nature — one record, in file-based terms. Intelligent messaging is inherently well- suited to this type of event-driven information exchange. Messaging lets application programs communicate asynchronously and in a relative realtime manner. An application experiencing a business event can put the relevant data onto a messaging backbone without concern for who needs to get it or how it will get there. The messaging infrastructure takes care of delivering the message to the recipient applications, in a near realtime manner. And, should the target application system or some part of the network be unavailable at that moment, the data is stored and forwarded at a later time. Likewise, recipient applications can process messages immediately as they arrive or deal with them in some other delayed manner. Messaging alone, however, still leads to point-to-point interfaces. It also leaves receiving applications to deal with data format and semantic differences of the sending application. The integration broker solves these issues by acting as a middleman providing both data transformation and message-routing capabilities. Using a message broker has at least three advantages: • It reduces the number of application interconnection points. In intelligent messaging, all messages route through the integration broker for evaluation and subsequent routing. Thus, interface management improves because the integration points normally associated with point-to-point interfaces reduce in number or disappear. It also increases the opportunities to reuse data formats and business logic.
• It makes applications and their interface logic less interdependent. Abstracting the interface logic away from the source or target applications accomplishes three goals. First, it simplifies the logic needed in the source and target integration point applications (and the need to deal with multiple platforms, operating systems, and programming languages). Second, you can make the source or target integration points more reusable. Instead of coding them for a specific interface, you can now write them as general-purpose extracts or updates — in effect, business APIs to their respective applications. Third, it reduces the ripple effect an application change can have on interface partners. The integration broker addresses the change’s effect on dependent interfaces. Paul W. Timberlake (ptimberlake@promenix.com) is the southwest regional director for Promenix Inc. (www.promenix.com), a systems integration consulting firm focused on delivering “interstate highway-class” EAI solutions to Fortune 500 companies.
Copyright © 2004 CMP Media Inc. ALL RIGHTS RESERVED |
 |
Most Popular This Week
IE Weekly Newsletter
Subscribe to the newsletter
| |
|
|