In “Succeeding at IA in the Enterprise,” James Robertson calls for Enterprise Information Architects to pay attention to the realm of business strategy, and Bob Goodman in “Change Architecture: Bringing IA to the Business Domain” offers the notion of EIAs as change agents or change architects.
Yes, EIAs can be a force for change, but so can anyone. The real question is: should the discipline of Enterprise Information Architecture be defined to include organizational change as one of its essential features. I don’t think it should be.
Whatever it is that information architects learn to become enterprise information architects (EIA), I think it is essential that we not lose our focus. The heart of IA is information and knowledge, and we need to build on that foundation, not try to turn into something else when we add the term “enterprise.”
It is the same for business strategy. Yes, EIAs should better understand their organization’s business strategy and integrate the strategic vision. And, yes, EIAs can contribute to the development of business strategy, but not directly. We should not try to tell business analysts how to do their job. What we can do is provide input into the development of business strategy based on our understanding of and access to information and how those issues are essential to any business strategy.
Integrating business strategy into EIA is only a part of what it means to move from IA to EIA, and I’d like to take a look at the essential issues that IAs bring to the enterprise and what sorts of things IAs need to add and/or learn to develop an enterprise perspective.
The move towards “Enterprise”
To start we should recognize that adding “enterprise” to our titles is part of a broader trend toward enterprise solutions in a variety of fields from technology to management restructuring. For example, content management, knowledge management, and learning management software vendors are all moving toward creating platforms for the entire enterprise that cover the entire life cycle of information and knowledge.
However, the truly essential feature of enterprise solutions — and what we have to recognize if we want to become EIAs — is that moving to an enterprise perspective does not mean simply doing bigger or more varied projects. Rather, it is a move away from a project-centric model toward an infrastructure model.
In order to have an enterprise-wide solution, you must develop an infrastructure that enables projects to be fully integrated, that enables projects to build on a common foundation rather than always starting from scratch, and that enables projects to be accomplished cheaper and faster with a broader impact.
The next step is the most important and the most difficult. It is the creation of a solid, well-articulated semantic infrastructure.
A semantic infrastructure consists of all the various kinds of information and content in an organization plus the ways that information and content is organized and structured. It includes structured and unstructured documents, tacit knowledge, and other non-document-based content like images and animation. It also includes the policies and procedures around the creation and dissemination of that content, the technologies that support content creation and dissemination (search, CM, portals, etc.), and finally, and most importantly, the ways that content is structured such as metadata, taxonomies, controlled vocabularies, semantic networks, ontologies, social network analysis representations, knowledge and topic maps, and other advanced knowledge representations.
A semantic infrastructure also includes modeling and/or mapping people and their activities. This includes formal and informal communities of all kinds, the information behaviors associated with those communities, linguistic and category preferences, and most of all, how information is used within the full range of business and support activities that these communities engage in.
In my opinion, it is this enterprise-wide semantic infrastructure that is the context within which EIA should operate, and it is the essential feature of defining what an enterprise information architect does and understanding how EIAs differ from IAs.
Distinguishing EIA from IA
Two key elements distinguish an enterprise IA from a basic IA. The first is the role an EIA plays in the design, development, and maintenance of an enterprise’s semantic infrastructure. The second is the scope and type of projects an EIA can be involved in as they develop applications that use and build on this semantic infrastructure.
Let’s start by looking at how an EIA might help develop a semantic infrastructure. A complete answer is beyond the scope of this article, but a simple answer is: IA skills and tools can support research that is fundamental to the creation of a well-designed semantic infrastructure. This can include such activities as researching information needs and behaviors of different users, mapping different communities in an organization, and ethnographic studies.
Just as more and more enterprises become convinced of the importance of content structures like taxonomies, however, EIAs should become more aware of and focus more attention on these content structures. EIAs should also be more aware of how different groups categorize the world around them in different ways and what those differences mean for information architecture. For example, as someone’s knowledge of a field increases, they tend to focus on the more precise levels of a taxonomy while novices tend to prefer higher level categories. Mapping these category level preferences into designs is an important component of a semantic architecture. This is a natural extension of the traditional work on metadata and labeling that goes into IA work today.
The type and scope of applications and projects is the second key element that distinguishes an IA from and EIA. For traditional information projects like search and portals, and even individual intranet website projects, it is important to approach them with an enterprise-wide perspective. One of the reasons these types of projects fail to deliver their full value is that they do not take into account the entire enterprise.
In addition, enterprise information architects work on a broader range of projects, not just traditional information projects like search and Content Management. These other projects could include adding an important emphasis on how information organization and presentation impacts all business activities. (But not to tell other groups how to run their business activities.)
EIAs should also be involved in knowledge management projects like collaboration, communities of practice, and innovation programs. Too often the failure of knowledge management programs is blamed on culture, when all it needed was an understanding of and support for the various group’s information behaviors – a really good information architecture.
Finally, EIAs should not just be involved in the enterprise’s information architecture, but also involved in the information architecture of the enterprise. They should apply IA skills to understand, model, and support how information and knowledge flows within the enterprise.
This could include studying and developing new information architectures for how people do everyday jobs, how desktops or webtops are set up, how those designs impede daily information use, and how to improve those designs. It could also use an expanded social network analysis of who gets their information from what people or content repositories and what kinds of information are not reaching critical audiences. In other words, instead of focusing on the design of the intranet, EIA can focus on the people in the organization and support the information seeking strategies and behaviors that are part of their daily routine.
The place of EIA in the enterprise
The last question I want to examine is where EIA fits in within today’s organizations. It is clear that a semantic architecture needs a broad, interdisciplinary team. It should include members from IT, business units, and information professionals like librarians, information architects, and others.
In addition, this interdisciplinary team will need to partner with other departments throughout the enterprise, including business, technology, sales, administration, and research.
The actual makeup of the team and where it is located organizationally will vary from industry to industry, but from experience we know it should not be located in IT. IT should be involved; people from IT should be on the team, but despite the fact that “information” appears in their department description, we should remember that they are not really information professionals.
For example, many enterprise search, content management, and portal projects fail to deliver full benefits because what is needed to make them work goes way beyond traditional “needs assessments.” It is not enough to have people go out and ask users what they need. You need to have information professionals (IAs, librarians, knowledge engineers, etc.) to develop new creative possibilities to offer to users. You need someone who can ask deeper questions about information behaviors.
Having IT, business analysts, and subject matter experts involved is important and necessary, but none of those three groups understands information and knowledge at a sufficiently deep level to offer truly creative and innovative alternatives that make information and knowledge systems work across the whole enterprise.
On the other hand, it has been suggested that EIA should lead this central information/knowledge team. Personally, I don’t think this is a good idea for a number of reasons having to do mostly with the difference between knowledge and information and the background/training that most IAs have. However, EIA might be one candidate to lead this interdisciplinary team, as long as we start with a greatly expanded definition of the role of EIA based on a stronger emphasis on semantic architecture.
The other major candidates for leading this team are knowledge management and learning departments. Learning groups are a good place, but like IA, traditionally, they don’t deal with the depth and breath of knowledge modeling that is needed. Learning is only one type of information and knowledge activity and we need something to cover the full spectrum of activities: searching, using existing information to create new documents, writing reports, and even using information to make a sale.
Personally, I think that knowledge management departments are a very good place to locate this team, but it does require KM to shift focus away from an over-reliance on the idea of tacit knowledge and move towards actually modeling knowledge—in other words, KM with more emphasis on knowledge than management.
Knowledge architecture is a term that I think captures the essential nature of this interdisciplinary team and, at the same time, adds the focus of actually modeling knowledge to KM. However, it is not a widely used term and requires significant explanation.
Whatever term is used will require some redefining (KM), some expansion (EIA), or some explanation and general acceptance (KA). Take your pick or come up with an entirely new one.
However, what is more important than who will lead this team is to pay attention to how all the members of this interdisciplinary team communicate among themselves. The team will need the services of a good IA to help the team communicate and interact with the rest of the organization. Regardless of who leads, the Enterprise Information Architect will always be an essential part.
There is a great deal more that could be said be but in the interests of brevity, let me close with this thought. This vision of enterprise information architecture might not be what you think of or want an EIA to be, but this vision is meant to be a broad one that attempts to locate EIA within an even broader context that ultimately consists of some form of knowledge management. Within this vision of EIA, however, there is room for many different IA roles.
Some EIAs might work closely with the team doing more advanced knowledge representations. Some might work with the semantic specialists like taxonomist and metadata designers. Some might work with business strategy groups, and some might work with business process re-designers. On the other hand, some might work on traditional intranet projects, some with search or portal projects, and some doing traditional IA on new knowledge management projects.
For me, it is not so much that EIA represents a new field, so much as expanding the definition of what information architecture is and, at the same time, locating IA within a new enterprise approach to information and knowledge.