Enterprise Information Architecture: No Small Endeavor

I often think about inputs vs. outputs. That is, in order to get more out of a system and data, you typically have to put more into it. The aphorism has stood up remarkably well in my ten-plus years of consulting large organizations on how to manage their systems and information.

Against this backdrop, I was reading Robert Hillard’s book: Information-Driven Business: How to Manage Data and Information for Maximum Advantage. Hillard writes extensively about Entperprise Information Architecture (EIA) and the need for organizations to take a holistic approach to systems and data management throughout the enterprise. In this post, I discuss why many organizations get so little out of their systems and data–and the requirements for EIA.

Definitions

Lest I get ahead of myself, let’s get our terms straight. Wikipedia defines Information Architecture as:

the art of expressing a model or concept of information used in activities that require explicit details of complex systems. Among these activities are library systems, Content Management Systems, web development, user interactions, database development, programming, technical writing, enterprise architecture, and critical system software design. Information architecture has somewhat different meanings in these different branches of IS or IT architecture. Most definitions have common qualities: a structural design of shared environments, methods of organizing and labeling websites, intranets, and online communities, and ways of bringing the principles of design and architecture to the digital landscape.

This definition is rife with other definitions and important concepts well beyond the scope of one post–or even a series of posts, for that matter. Suffice it to say for now that one doesn’t “implement” EIA in six months. In other words, it’s the antithesis of an ERP or CRM project with a “go-live” or system activation date. On the contrary, EIA is a state of mind and ongoing process for one simple reason: things change, especially these days. Systems, data, people, process, and technology are hardly static entities. We’re not living in 1970.

Requirements for EIA

Hillard writes that requirements for EIA include:

• Business context
• Enterprise Metadata
• Systems Inventory
• Master Data
• Information Governance
• Key Data Sets
• Data Set Metrics
• Information Flows
• Information Users
• Priority Standards
• Priority Investments
• Data Quality Measures

These are necessary steps for organizations to do EIA effectively.  For example, it’s hard to imagine an organization with its arms around EIA sans data quality measures or data governance. Even not understanding the flows to which Hillard refers is fraught with peril. If you don’t know how information gets from point A to point B, then how can you properly manage it?

Barriers

Achieving the holy grail of EIA is anything but easy because, quite simply, we live in the real world. Hillard writes that one major “barrier to the development of such a strategic information architecture is the business executive’s seemingly insatiable desire for instant gratification. (Perhaps these executives have a great deal in common with toddlers!)”

Truer words have never been written. Even a CIO who “gets it” may be replaced after a few years and, as is often the case, successors want to put their own stamps on an organization. Even the same CIO may have to abandon key initiatives because of cost or regulatory issues, not to mention changes in the organization’s strategic direction. Finally, let’s not place too much emphasis on the role of the CIO. As a wise man once told me, “culture eats strategy for lunch.” CIOs aren’t the ones doing the audits, entering the data, and making the everyday decisions that invariably effect data quality, integrity, and management.

Simon Says

The bottom line is that EIA is a massive endeavor easy to do wrong or incompletely. The number of moving parts that need to be coordinated is downright daunting, even in properly run companies. (Dysfunctional organizations might as well not even try EIA.)

Of course, perfection is hardly required–and only the most draconian environments look at EIA as a binary. Organizations and senior management need to recognizes that EIA is a long-term and highly beneficial process–without a definitive end. Its benefits can be significant, but those looking for a “quick hit” would be better served by discrete projects such as MDM.

Feedback

What say you?