Occasionally, I will ask my students, “Why is the Roman Coliseum still standing?” The answer that I’m fishing for is, “Because the folks who tried to tear it down in the Middle Ages for building material were not as good engineers as the folks who put it up hundreds of years earlier.” All this was recently brought to mind because I’ve been reading a series of historical novels set in 9th century England based around the struggles between the Saxons and the Danes. In a number of places in these novels, the central character comments about the Roman ruins and how no one in his time could understand how the ancient Romans built the bridges, roads, baths, and castles that they did. These references got me thinking about architecture, engineering, and infrastructure.
History tells us that the Romans were not great conceptual thinkers, certainly not on a par with the Greeks. The Romans were great at a few key things: war, administration, and engineering, and all of these things hung together. War made it possible for a small city state in Italy ultimately to conquer a very large portion of the known world; administration made it possible to govern and administer Rome’s huge, far-flung, and diverse empire; and engineering made it possible to build the roads, aqueducts, walls, and castles to secure and provision that empire.
Why is any of this important to today’s C-level executives and what role does enterprise architecture play in any of this? Well, the first thing is that over time, the Romans learned to think long-term. When they captured a new province, the first thing they did was to begin to build roads and fortifications, castles, and aqueducts to allow them to protect and supply what they had conquered.
Modern enterprises would do well to emulate the Romans’ thinking. Take a major merger. In addition to working to integrate the financial and marketing aspects of this new business empire, top management should set the IT planners and engineers at work to integrate the data and systems from these different merged units. IT is today’s most critical infrastructure.
Now, I’ve worked for a number of companies that were seriously into the merger and acquisition. Two that were successful were a bank holding company and a clothing conglomerate. In both cases, they had a systems strategy. In the case of the bank holding company, it immediately converted the acquired bank to its banking systems, even though in a number of cases, this meant that the systems that the merged bank had to work with were less sophisticated than the ones it already had in place.
In the case of the clothing company, the firm felt that it was acquiring “brands” and “marketing,” and therefore insisted that the acquired company quickly install the holding company’s A/P software (it wanted to control costs) and move to the holding company’s general ledger. Here’s where it gets interesting. The company being acquired was most successful at marketing a specific brand to a specific market. It was loath to give up its control over the marketing function upon the merger. What the holding company did was to say it was not going to force its marketing system on the acquired company’s marketing folks — and it didn’t. What it did do was set up its G/L so that it included the acquired company’s entire customer list.
Recent business history is full of stories of mergers and acquisitions that failed because the resulting company could not integrate the information from its various parts. Perhaps the most significant case in modern history is the ongoing saga of the US Department of Homeland Security and its attempt to integrate all of the data from all of its critical parts. Despite billions of dollars devoted to this activity, recent stories from the front pages around the world show that this is not a done deal.
The integration of information systems and enterprise data is one of most important problems facing top business and IT management around the world.