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

Instead, imagine yourself being in charge of a factory. It's a large factory. Every day it produces tens of thousands of different types of widgets. It is a nicely automated place. Several sophisticated assembly lines spew out various products. Hundreds of people feed the machinery with an assortment of parts, control the flow, and check the output.

Sounds all right? Well, there is a twist. While you can sort-of hear the hum of your machines, you cannot see anything. It is an invisible operation. Your workers see their respective bits and pieces, they know which buttons to push and which parts to feed and where, 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 where the two lines converge or how changing the unit specs in one assembly point may affect the other lines. If you think this is a total and rather absurd fantasy, think again. This is exactly what you're running: a huge and largely invisible factory.

Scared You?

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

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

What you and your business leaders need is a blueprint that enables you to compare the actual implementation of the enterprise with their future vision. In the absence of such blueprints, companies suffer under the business managers' mistaken view of how the enterprise truly operates, making it impossible to take effective, transformational action. An enterprise information architecture (EIA) is such a blueprint.

Several months ago (May 2005) I wrote a piece under the catchy title of "Fire the Architects!" If you read the piece on firing, you might remember its gist. Traditional IT architects do more damage 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 most companies from investing in the development of an enterprise information architecture–the strong perception that architecture is not a survival issue for IT. Today, I'll beg to differ. How many times have you participated in meetings where critical business-change issues were discussed and argued, yet not a shred of a visual plan (model) representing the complex structures and processes being discussed was present. Did it mean the participants didn't perceive the models? Of course not. Implicitly they all held their own models in their heads, invisible to you and the rest of the group. Were these models the same? We never will know with certainty, but plenty of empirical evidence–which shows up later in the form of "that's not what I wanted"–tells us they were not. That should be no surprise. In most human communication, implicit evidence breeds heterogeneity of views. I suspect in most situations, the "10 people/10 models" formula reigns.

Hence, the first objective of EIA is to give you and your business clients a means to communicate clearly about what everyone wants and needs. It becomes a key instrument that introduces clarity and certainty to analyzing the details of business ideas and 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 "Business Architecture." This layer shows the way in which the company is organized and how it executes its individual business services (i.e., business process steps) in a value chain to its internal and external users and customers.

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

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

The third, and relatively simplest, layer is the "Technology Architecture." The objective is to maximize the cost-effectiveness of your technology infrastructure. Therefore, the blueprints should be used to maximize sharing and commonality of platforms, tools, and processes.

A fully developed EIA delivers an impressive set of benefits:

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

o A blueprint for any future IT development.

o A tool to unify and integrate business processes across the enterprise.

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 complexity barriers.

o Reduced solution delivery time.

Why Do Only a Few Have It?

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

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

Yet what is the payback on the architected, planned system of roads? Clearly huge. Would any private enterprise make such investment? Not likely. I suspect if it weren't for the existence of Congress and similar bodies of people who actually can spend other people's money, we never would have seen our interstate highway system. Conversely, the corporate compensation systems built on rewards for the immediate short-term gain effectively limit the enthusiasm for long-term (read: architectural) investments.

In short, the inherent complexity of EIA, the scarcity of architectural skills, and the constraints imposed by the structural and financial order of business keep corporate executives in deep-rooted doubt. Consequently, the architectural approach is possible under only one of the two conditions: Either it is disguised as a common-sense process applied to the implementation of daily emerging needs, or it is led by a superb visionary effort.

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 be held against investing in EIA. Many other important corporate activities such as strategic planning, market research, or intelligence gathering cannot be quantifiably justified. We invest in them because we intuitively understand they all advance us to better, more knowledgeable decision-making. In many instances, these very activities become central to creating a competitive advantage for our companies. So is the promise of EIA.

Most of you know about this kind of implicit ROI from personal experience. I'm sure you have met people who built or renovated their houses without the involvement of an architect. If you haven't, believe me, it does happen. Some of these people have done OK. Some have not. Undoubtedly, the ones who spent an additional 10 percent to 15 percent on a good architectural plan ended up with a dwelling that not only closely matches what they wanted and needed but also is aesthetically pleasing while encompassing a robust yet functional design.

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

Creating an architecture-based approach to building systems requires skills, discipline, and commitment. It also affects the IT and 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 full expression of the corporate culture–it's a way of thinking, planning, designing, and building. It's as basic to the corporate life 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 a mindset."

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 to present my closing argument.

I believe many CIOs have lost their jobs precisely because they did not have a blueprint to help them respond to the challenges at hand. Hence, my final message: Just as a strategic plan is a key tool in your CEO's cache, you must have an architectural plan in your 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 Pitney Bowes, is a co-founder and managing director of the Insurance Technology Group (www.insurancetg.com). He can be reached at 416-214-3445 or marek.jakubik@insurancetg.com.

Special Reports /

Architecture Aids Survival

Related Stories

Recommended For You