I need to ask you for a bit of indulgence. For the next minuteor so, I want you to forget your job is to manage IT for aninsurance carrier.

Instead, imagine yourself being in charge of a factory. It's alarge factory. Every day it produces tens of thousands of differenttypes of widgets. It is a nicely automated place. Severalsophisticated assembly lines spew out various products. Hundreds ofpeople feed the machinery with an assortment of parts, control theflow, and check the output.

Sounds all right? Well, there is a twist. While you can sort-ofhear the hum of your machines, you cannot see anything. It is aninvisible operation. Your workers see their respective bits andpieces, they know which buttons to push and which parts to feed andwhere, but as soon as you step away from an individual workstation,it all disappears. Nothing is visible. No one can take a picture.There are no drawings.

As a consequence, no one can point out with any precision wherethe two lines converge or how changing the unit specs in oneassembly point may affect the other lines. If you think this is atotal and rather absurd fantasy, think again. This is exactly whatyou're running: a huge and largely invisible factory.

Scared You?

No? Then, if you still are smiling, tell me this: How many ofyour big, big problems–you know, sleepless-night-inducing ones–arecaused by the simple fact no one, and I mean no one, fullyunderstands the details of how your factory system works. Then,someday your company executives want to make a Very ImportantChange, and you're asked a rapid series of questions. They usuallygo like this: Can our system handle it? How fast can we implement?For how much? What are the implications? What options do wehave?

Of course, you know very well what you don't know, and so aftersweating just a bit, you launch a project to find out. Perhapsseveral days or weeks and thousands of dollars later, you get ananswer. Or perhaps by that time it is either too late or you aretotally embarrassed into admitting you aren't sure. Meanwhile,pressure steadily grows.

What you and your business leaders need is a blueprint thatenables you to compare the actual implementation of the enterprisewith their future vision. In the absence of such blueprints,companies suffer under the business managers' mistaken view of howthe enterprise truly operates, making it impossible to takeeffective, transformational action. An enterprise informationarchitecture (EIA) is such a blueprint.

Several months ago (May 2005) I wrote a piece under the catchytitle of "Fire the Architects!" If you read the piece on firing,you might remember its gist. Traditional IT architects do moredamage than good. You need to approach this task differently and,likely, with a different set of people.

What I did not address, however, is the issue that prevents mostcompanies from investing in the development of an enterpriseinformation architecture–the strong perception that architecture isnot a survival issue for IT. Today, I'll beg to differ. How manytimes have you participated in meetings where criticalbusiness-change issues were discussed and argued, yet not a shredof a visual plan (model) representing the complex structures andprocesses being discussed was present. Did it mean the participantsdidn't perceive the models? Of course not. Implicitly they all heldtheir own models in their heads, invisible to you and the rest ofthe group. Were these models the same? We never will know withcertainty, but plenty of empirical evidence–which shows up later inthe form of "that's not what I wanted"–tells us they were not. Thatshould be no surprise. In most human communication, implicitevidence breeds heterogeneity of views. I suspect in mostsituations, the "10 people/10 models" formula reigns.

Hence, the first objective of EIA is to give you and yourbusiness clients a means to communicate clearly about what everyonewants and needs. It becomes a key instrument that introducesclarity and certainty to analyzing the details of business ideasand the implications of change.

Three Layers of Drawings

What you use for that purpose is a three-layer set of drawings.We will call the first layer of drawings the "BusinessArchitecture." This layer shows the way in which the company isorganized and how it executes its individual business services(i.e., business process steps) in a value chain to its internal andexternal users and customers.

The second layer, the "Application Architecture," takes you tothe factory itself. The blueprints represent the actual layout,functionality, and data flows occurring inside your systems. Thislayer of EIA allows the engineers to understand and analyze thecomplex relationships between systems, data, processes, andbusiness. It also allows you to identify gaps and bottlenecks aswell as improvement opportunities in your automated processes.Furthermore, for the business as well as the project managers, itprovides an irreplaceable tool for planning and assessing theoptions, their timing, and costs before any designing andprogramming starts.

But perhaps the most important benefit of ApplicationArchitecture lies elsewhere. With time, you can use it to plan fora systems architecture that is both component based and uses commonservices (as in Web services). As a result, in one swoop, you cangain the ability of faster response (speed to market) but also beready for new ideas such as SOA (service-oriented architecture) ifand when SOA becomes a real killer.

The third, and relatively simplest, layer is the "TechnologyArchitecture." The objective is to maximize the cost-effectivenessof your technology infrastructure. Therefore, the blueprints shouldbe used to maximize sharing and commonality of platforms, tools,and processes.

A fully developed EIA delivers an impressive set ofbenefits:

o Documentation of how your enterprise really works (The SystemIs the Enterprise).

o A blueprint for any future IT development.

o A tool to unify and integrate business processes across theenterprise.

o A tool to unify and integrate the data.

o A tool to help select the packages.

o A tool to enable faster change by lowering the complexitybarriers.

o Reduced solution delivery time.

Why Do Only a Few Have It?

If architectures produce so many benefits, then how is it so fewcompanies actually use them? Why do senior executives of theoverwhelming majority of corporations not see the architecturalapproach as an object of enlightened self-interest?

In 1999, John Zachman, one of the leading proponents of thearchitectural approach to development, wrote: "Architecture IsCounter-Cultural." Indeed, and especially in the United States,there is a strong market-driven business culture of short-termorientation. Accounting rules do not allow the easy measurement ofvalue from reusable (and well-architected) things.

Yet what is the payback on the architected, planned system ofroads? Clearly huge. Would any private enterprise make suchinvestment? Not likely. I suspect if it weren't for the existenceof Congress and similar bodies of people who actually can spendother people's money, we never would have seen our interstatehighway system. Conversely, the corporate compensation systemsbuilt on rewards for the immediate short-term gain effectivelylimit the enthusiasm for long-term (read: architectural)investments.

In short, the inherent complexity of EIA, the scarcity ofarchitectural skills, and the constraints imposed by the structuraland financial order of business keep corporate executives indeep-rooted doubt. Consequently, the architectural approach ispossible under only one of the two conditions: Either it isdisguised as a common-sense process applied to the implementationof daily emerging needs, or it is led by a superb visionaryeffort.

I'm often asked how to justify a return on investment for EIA.My answer is I don't know how to do it, although this should not beheld against investing in EIA. Many other important corporateactivities such as strategic planning, market research, orintelligence gathering cannot be quantifiably justified. We investin them because we intuitively understand they all advance us tobetter, more knowledgeable decision-making. In many instances,these very activities become central to creating a competitiveadvantage for our companies. So is the promise of EIA.

Most of you know about this kind of implicit ROI from personalexperience. I'm sure you have met people who built or renovatedtheir houses without the involvement of an architect. If youhaven't, believe me, it does happen. Some of these people have doneOK. Some have not. Undoubtedly, the ones who spent an additional 10percent to 15 percent on a good architectural plan ended up with adwelling that not only closely matches what they wanted and neededbut also is aesthetically pleasing while encompassing a robust yetfunctional design.

Think about it this way. How would you have an intelligentdiscussion with your builder if you could not look at the set ofarchitectural plans? How would you understand and argue aboutdifferent design options? Of course, there always is a simple way.You can say, for instance: "Build me a nice house with fourbedrooms, three bathrooms, a kitchen…oh, a two-story, please, and asmall office would be nice, too. Call me when you're done." Iwonder how many of you spend your money using this strategy?

Creating an architecture-based approach to building systemsrequires skills, discipline, and commitment. It also affects the ITand corporate culture.

As my friend and renowned IT architect Paul Winter once said:"Architecture is a way of life; when it flourishes it's a fullexpression of the corporate culture–it's a way of thinking,planning, designing, and building. It's as basic to the corporatelife as maps and blueprints are for engineers and urban planners.It is not something superimposed on their professional activities;it's an organic part of it. So, it's part of a culture and amindset."

I hope this kind of cultural change sounds appealing to you.However, if you still see it as just a risky idea, I'd like topresent my closing argument.

I believe many CIOs have lost their jobs precisely because theydid not have a blueprint to help them respond to the challenges athand. Hence, my final message: Just as a strategic plan is a keytool in your CEO's cache, you must have an architectural plan inyour drawer. I'm ready to say it is your sine qua non. Demand it,create it, use it. And forever flourish.

Marek Jakubik, a former CIO of Zurich Financial and PitneyBowes, is a co-founder and managing director of the InsuranceTechnology Group (www.insurancetg.com). He can be reached at416-214-3445 or [email protected].