A decade or so ago, John A. Zachman published a seminal article on technical architecture in the IBM Systems Journal. (In publishing, “seminal” means lots of people cite it but almost nobody actually has read it.) Almost immediately, IBM issued a ton of press releases whose only significant impact was to verb the word “architect,” which hitherto only had only been nouned.

The Zachman Framework for Enterprise Architecture continues to be popular among systems theoreticians, and it is largely responsible for popularizing the idea that management of technical architecture has become a key responsibility for IS organizations. It’s an important idea because without it you end up with a junk-filled data center, databases containing conflicting information, and a hodge-podge of applications that satisfy departmental requirements without supporting the enterprise as a whole.

The Zachman Framework may even have something to do with the framework presented in this column last week. My own ideas about technical architecture evolved in happy ignorance of Zachman’s work, and the methodologies don’t seen very similar, but my platform, information, and application layers described last week match up reasonably well with his network, functions, and data.

Pick the framework you like or invent your own. However you take on the subject, focus on keeping your architecture management practice simple enough that you can afford to do it, clear enough that everyone in IS can easily understand it, and practiced as a value-adding discipline, not as a collection of inflexible, bureaucratic rules. You want people to adhere to the architecture because it’s the best way to do business, not because the architecture police are standing on every corner waiting to shoot violators.

The first step in constructing your architecture is to translate your company’s strategic, tactical, and operational goals into an overall organizing principle on which you can hang your future architecture. Having a clear organizing principle keeps things neat and tidy. But how?

Chances are, you need to deliver more capabilities than you provide today, and with greater integration.

It’s a shame that these two requirements conflict, but they do, because in most IS shops, “integration” means creation of custom interfaces between every two items that need to communicate. As the number of items and need for integration increases, the number of custom point-to-point interfaces increases exponentially.

Which means the organizing principle for most IS shops today should be the creation of an integration-centric technical architecture – one that facilitates integration in all three architectural layers.

Things become even more straightforward once you realize you only have two ways to build an integration-centric architecture.

In some circumstances you can choose a core application – maybe an enterprise resource planning (ERP) suite – and make it the heart of your architecture. Rather than creating point-to-point interfaces between every two items that need linkage, you use this core application as the architectural hub of the enterprise and integrate everything else with it.

That’s great if someone sells a core application that fits your business well enough, or if one of the ERP suites supports enough of your company needs. In an era of business diversification, mergers, and acquisitions, though, many of you will conclude that building around a core application just isn’t feasible.

The alternative is to build an integration engine. The idea is simple enough – everything plugs into it, and it handles all of the translations. I presented this concept to a client a while back though, in the form of a PowerPoint slide showing all legacy and proposed applications and databases plugging into a central cylinder. “But Bob,” scolded the DBA, “that isn’t drawn to scale!”

True statement.

Designing and building an integration engine is a highly complicated exercise. If you go that route, don’t every use the words, “All you gotta do is to … .”

Instead, tell everyone involved in the decision, over and over, that your goal isn’t to make things easy. Nothing will make things easy.

Your goal is to take something that’s impossible and make it merely very difficult.

Back when the earth was young and dinosaurs … uh, batch mainframe processing … ruled the world, you picked a primary vendor, usually IBM or Digital, and your vendor defined your technical architecture.

IBM’s whole business strategy, in fact, revolved around control of the architecture. Even if you bought an Amdahl mainframe, Memorex controllers and Telex terminals IBM still defined the architecture. “Technical architecture management” meant buying and upgrading the components IBM mapped out.

Then IBM missed the boat on LANs, or maybe it caught the boat while the rest of us went to the airport. SAA failed and we replaced our SNA WANs with TCP/IP. Open systems and rampant multivendorism has given you control of your own architecture. Now you have to manage it yourself. Be careful what you ask for …

Yes, we’re back to developing our integrated IS plan. An integrated IS plan, you’ll recall, covers three topics: Company Goals, Technical Architecture, and Human Factors. We covered company goals in June, discovering the company’s strategic, tactical, and operational goals in the process and how to translate them into systems concerns.

Now it’s time for technical architecture.

One of the hardest ideas to get right in defining technical architecture is thinking at the right level. Technical architecture describes your systems environment in terms of functional building blocks and how they interact, not specific items and wiring. If “functional building block” isn’t too clear a term, an example may help. “Systems to help us manage our information,” is too vague to be of any use, while “Sybase running on mirrored AIX servers,” has too much detail, locking you into a specific technology.

For data management, you want to say something like, “We’ll support a mainframe RDBMS and a distributed object-relational database. We’ll also support whatever other data management systems are built into our legacy environment but will take advantage of opportunities to align them with our preferred architecture. Under some circumstances we may also choose to accept non-conforming technologies built into turnkey or packaged solutions, but will give preference to those conforming to our technical architecture.”

Technical architecture divides into three major layers: Platforms, Information, and Applications. Taking the last first, applications are what deliver business value. They’re the point of it all, because the rest of the company interacts with applications, not with information or platforms, except for the PC’s keyboard and monitor and the telephone’s handset and touchtone pad located on each employee’s desk. The company goals you developed in the previous section of your integrated plan drive changes to your portfolio of applications.

Information includes everything your applications chew on to produce results. The subject includes databases, word processing documents and spreadsheets, scanned images, Web pages (whether stored in HTML or dynamically generated) … that kind of stuff.

Object-oriented (OO) technology doesn’t change this, even though OO designs wrap data and programs (methods) together into tight bundles. You still manage code with OO programming, and you still have a persistence layer to store every instance of an object … and it’s the information that’s unique in every instance of the object, not the methods.

Don’t count your database management systems in your information layer. A DBMS is a platform along with every other piece of hardware and software you use to build applications and manage information. The platform layer includes host computers, servers, operating systems, DBMSs, all networking equipment, your PBX, and the software you use to manage it all.

The split between the systems management programs that belong in the platform layer and business processing that belongs in the application layer can seem fuzzy. The rule is: If it delivers direct business value it’s an application. If it helps provide computing resources, it’s a platform.

Over the next month we’ll look, layer by layer, at how to manage your technical architecture. And you thought you were having fun now.