Time for architecture planning

Ford is the new Borland. For years, the trade press never printed “Borland” without the prefix “troubled tool-maker.” Nowadays it’s always “troubled auto-maker Ford.”

The business punditocracy has offered plenty of suggestions for Ford. Conspicuous by its absence is, “Build cars people want to buy.”

And we consultants wonder why we aren’t held in higher esteem.

Ford deserves its troubles. When former CEO Bill Ford touted, as his best example of Ford innovation, the hybrid technology it’s licensing from Toyota, he made it clear Ford figured research and development meant tweaking, enhancing, and occasionally bolting on something it bought from someone else in response to pressure from the marketplace.

Sounds like the way many businesses handle IT architecture.

Most of IT’s effort is, and should be, in response to business-driven ideas about how information technology could improve business operations. The governance process sorts through the requests, turns some down, and passes the rest to IT. If everything goes according to plan, IT tweaks and enhances what it already has, or sometimes buys a solution and bolts it into place through one sort of interface or another.

And here the metaphor breaks down like an old Pinto, so let’s get to the point: One of IT’s often-shirked responsibilities is recognizing when it’s time to step back and re-think the architecture instead of tweaking, enhancing, and bolting. Here are two of the most common situations that call for in-depth architecture planning:

The first (continuing with transportation-related analogies) is when you find yourself creating a Kevlar and titanium biplane — when you retain an underlying design that’s simply obsolete, but “re-platform” it using high-tech raw materials.

Perhaps the most common example of this is taking an old file-based application and porting it to a relational DBMS without changing the data model. I’ve seen more than one commercial application that’s “fully relational” in the brochure without being normalized in the slightest.

Somewhat less common are Windows applications that are really PC-DOS-based, but can run in a DOS box, even though the underlying language isn’t even sold anymore.

The Kevlar biplane is a pay-it-now or pay-it-later situation. At some point you’ll have to invest in good engineering. The longer you delay, the more risky and expensive it is to do what has to be done, and trying to stave off the inevitable until after your retirement party is more than a bit cheesy.

The Kevlar biplane scenario (KBS?) is relatively easy to recognize. What’s more difficult to spot is a challenge that defies analogy: The many-to-many mapping between your company’s challenges and the world of enterprise software.

Commercial application software is coalescing into a number of application “clouds.” Among the most important are the familiar alphabet soup:

• ERP (really, enterprise suites, like SAP and Oracle).
• CRM (customer relationship management, which is being absorbed into ERP)
• ECM (enterprise content management, which used to handle only “unstructured data,” but no longer).
• BPM (business process management, which used to be “workflow” until workflow earned a reputation for complex, late, and unsatisfying implementations).
• Business Intelligence (which used to be end-user report generators and then became data mining, but you can charge more for business intelligence).
• EAI (enterprise application integration — a standard way to glue various applications together so as to avoid the traditional interface spiderweb).
• Portals (Portals are important … but try to find a crisp definition and you’ll feel like you’re SCUBA diving in molasses).
• Point solutions, some of which continue to thrive because they handle particular tasks far better than what you get from any enterprise solution.

Most of what you’re being asked to do to support the goals of the various parts of the business can be solved with more than one cloud combination, which makes solution design confusing. Even more problematic, once you’ve done so you’ll have committed the enterprise to a particular architectural direction that will force a particular architecture on future design challenges.

So if, when you ponder your company’s software future, you reach for the Magic 8 Ball and it tells you, “Outlook cloudy. Try again later,” it’s probably time to take a deep breath and a step back. You need to plan your company’s enterprise architecture before you design any more solutions, because the confusion you feel is a clear sign that you accurately understand the situation.