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.
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.
Conclusion
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.
This is a really interesting viewpoint for exploring roles and stratifications for “information” professions and a great follow-up to James Robertson’s earlier Boxes and Arrows article.
In larger enterprises, there tends to be more budget and infrastructure for lots of different people with different job titles, and more clearly defined roles and responsibilities. However, most organizations lack suffient resources to hire all these people, sometimes requiring, for example, IT professionals to also be information professionals in the IA sense.
You wrote that EIAs should probably not be seen or take responsibility for being change agents. However, you also wrote that “…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.”
Is this not being an enterprise change agent with grand visions, or is it more reflective of an EIA pointing out simple matters of improved efficiency?
I don’t know the answer to this question, but I believe that most companies, if they respect IA as a profession and the people they hire are really good at what they do, then EIAs will indeed be “change agents”–even at the enterprise level where budgets and resources are less limited than those of smaller organizations.
But, heck, that’s just a semantic distinction.
Thanks and good question. The answer is that EIA’s can and should be change agents — but then so can everyone. What I was getting at was that I don’t think that change agent is something that should become a part of the definition of what an EIA essentially is. In part this is because the term has no discrimintive power (everyone is/can be a change agent) and in part because I don’t see it as an essential part of what an EIA *is*, rather it is a description of the impact that an EIA can have.
That being said, considering an EIA as part of a semantic infrastructure rather than part of this or that intranet project, has the potential for truely powerful change.
Yep, I’m with you. I just turned to the appropriate semantic relationships chapter in my Polar Bear copy and started thinking about IA and EIA as alternately inset circles. Focus is a good thing!
Nitpicky typo:
“we should remember that they not really information professionals.”
should read
“we should remember that they *are* not really information professionals.”
The article uses terms or phrases like “Information”, “Information Architecture”, “Knowledge”, “Wisdom”, “Semantics” “Semantic Infrastructure” etc. When we look up the definitions of these terms in the publications of computer science or information technology or Wikipedia we come across many definitions which are not consistent.
It would be helpful for readers if the authors declare what definitions they are relying on. If they have their own definitions of the key terms or phrases, they should be kind enough to define and support them. Over time, the community of authors and readers should be able to arrive at most comprehensive and widely accepted definitions and use them for building more complex concepts and systems.
Cris,
Thanks for catching that! All fixed now.
Hi Tom –
UI design (or Interaction Design) is an important qualification for most of the IA job descriptions that I’ve recently seen. How would this look on an EIA job description?
Thanks.
I would so like to see an expanded definition of knowledge in IA. The word knowledge linked to information in this article appears, to me, to have a fairly narrow definition, representing, for example, the natural result of appropriate combining of information. As a non-programmer businessperson, my concept of knowledge encompasses the full spectrum of understanding.
The limitations of data management are what they are, but would not an attitude focused on building bridges between the 2 definitions and uses of knowledge offer far greater potential application of technology in our activities and endeavors? There must be more (says I) to user knowledge than what marketing and usability managers typically focus on eliciting.
Vera
I agree that there is a change coming with how IA works within Enterprise systems. In my current position as and IA I find my self having to develop strategies and infrastructure not because I want to but IA seem to be the only one with an understanding of both technology, usability, and to some extent business analysis.
Working in a large corporation you often find your self as the point person in places where an IA should not be however as business and technology evolves IA evolve with it. And as an IA grows in there craft why not include EIA and the next level in that evolution.
Architecture is an enterprise activity. Enterprise architecture is composed of Business Architecture (Strategies, Processes and Models, Roles), Information Architecture – Information supporting the Business (Typing, Modeling, Organizing, Structure, Frameworks, Governance, Data Architecture), Application Architecture – Solutions delivering information to the business (Application Portfolio, Application Data Mapping), Tecnical Architecture (Infrastructure dupporting the apps, and info environments)… There are slight variations on this.
If businesses, and/or government departments need to organize information at the enterprise level…. What is the business benefit? What are the enterprise goals that would make an organization see this as imperative?
Possible points of view could include Business Flexibility, Change Impact Analysis, the ECM virtues (Enhanced reliability, better decisions, maximize reuse)…
I am the converted, but it continues to be a tough sell in many areas, and not whisper of a thought in others. We need an ROI model. How to measure the Cost of not having EIA and how to measure the benefit of subscribing to it, which becomes a modus operandi vs a one time affair.
a recent sharepoint implementation i worked with had many of the issues/questions/metaphysical circles within circles discussed here
— much of what the technology was being asked to do could have been accomplished with a piece of paper and a pencil: people who weren’t taking notes before needed to learn that discipline first; then comes the discussion on whether the doc goes into a filing cabinet or a retrieval system tagged and bagged with taxonomy/folksonomy etc
— the questions being asked around the structure/exchange of info were really larger, org-wide workflow questions: how does group a work with group b and when do they tell group c about what they’re doing … thinking thru and then documenting that (how it is and how it should be) precedes the implementation …
so, many enterprise wide issues, many change management issues, many cultural issues … and some wiframes and user flows, too
and when you get to where you’re going, there you are
Information architecture as a practice is simply the directed planning and design of a shared information environment.
Please, note the use of terms like “directed”, “shared” and “information environment”.
The concerns of this practice include the environmental context (includes objectives or purpose, roles and actions), information classification, information exchange, information structure, information presentation, information security and information use.
I have deliberately used the term, “environment” as opposed to system or system-of-systems to suggest an open environment which facilitates information exchange.
The scope of the environment determines the size of the problem. The scope may be value-network (community of enterprises), enterprise-wide, an application. The scope determines the importance of a concern for example, if the scope is within a network of organisations in an environment like the Airport, information sharing may take precedence over presentation. Even then, presentation is still critical towards the provision of flight information to Passengers and Visitors.
The methods or techniques applied to the different areas of concern differ depending on the scope of the environment.
It would be useful if someone develops a matrix mapping some of these dimensions mentioned above. I suspect that this matrix may provide insights on the differences between the roles of the global information architect, enterprise information architect and application information architect.
All information architects should be trained to adapt methods to match the scope of the environment. For example, Resource Lifecycle Analysis (Ron Ross) while commonly used to bridge Enterprise Information Strategy Planning and the development of an Enterprise Subject Area Model can be adapted for use as Entity Life History (SSADM) for the design of an application logical data models.
In summary, it is the scope of the environment or domain that determines whether you play at the enterprise or application level and not the size of the application (even where the application is labbelled “enterprise”).
If you spend more time working on information standards for interoperability within an industry or community of organisations, you are probably an enterprise architect even where your title is “Data Analyst”
At the end of year 2007, I had proposed a different name, Enterprise Information Architecture, from Enterprise Architecture. Today I found exactly same term, EIA in your article. And core concepts look similiar with my idea. What I am saying is that EIA could be more suitable term in stead of Enterprise Architecture. With just the Enterprise Architecture, it is very difficult to imagine that it is related with information areas. Among Enterprise, Information and Architecture, the Information is the most important thing. Therefore Information should be never omitted. But current Enterprise Architecture community seem to cause some confusion between enterprise domain and information area by using Enterprise Architecture to represent the Information Architecture. Now I am a little bit relieved from the EIA, which is more sound usage, in my opinion. If you want more of my definition of EIA, please let me know.
This is exactly what I envision as follows –
I would view Information Architecture as a part of the overall Enterprise Architecture. Its like healthy blood (Tuned IA) flowing through a healthy body (tuned EA).
EA is the super set and IA need to be viewed as the subset of EA and then we would be able to appreciate the effect of IA on EA efforts within an enterprise.
-Deepesh Joseph
http://informationmanagementresearch.blogspot.com/