As information architects, the core of our profession rests on the analysis of information, the identification of structure, the creation of taxonomies and site maps, and the development of wireframes and user interfaces. These skills are well-honed, and we play a significant role in the design and creation of many systems, from websites to web 2.0.
Working within the enterprise, we are confronted with new challenges. There is a lack of clarity around needs and goals, organisational issues are paramount, and the real challenge is making things happen and getting users to adopt the new solutions.
This is the focus of what is often called “enterprise IA”, the application of information architecture in complex business environments. To be successful in these situations, we need skills and strategies that focus much more on people than on information.
This article explores some of the approaches needed to ensure that we are successful at implementing IA within organisations, with the goal being to encourage further discussion in the community about these issues.
Business strategy
More than any other skill set, enterprise information architects need to have a strong understanding of business strategy and planning. With so many possible issues to solve, the greatest success is achieved when activities are designed to support organisational strategy and to deliver tangible business benefits.
In practice, this includes:
- Building a strong understanding of overall corporate strategy and directions.
- Using this knowledge to select projects that will support organisational goals.
- Designing projects to deliver tangible and visible benefits within the organisation.
- Developing project plans that will deliver “quick wins” while building momentum for longer-term activities.
- Conducting good project management, including working within project constraints and maximising the use of project resources.
At the end of the day, enterprise IA projects need to be able to demonstrate that they have made a real and measurable difference to the core activities of the organisation.
Top down and bottom up
Successful enterprise projects follow both a “top down” and “bottom up” approach that combines overall business strategy with an in-depth understanding of staff needs and issues.
This is illustrated in the following diagram:
For an information architecture project, this means:
- Working with senior management to obtain strategic input, including overall business goals and objectives.
- Conducting in-depth research with key staff groups to identify major staff issues and needs.
- Using the strategic view as a “lens” to select key activities that both support business goals and meets the needs of staff.
- Developing a set of tactical (short-term) strategic (longer-term) activities to deliver improvements to information management within the organisation.
While this is not the only way that an enterprise IA project can be managed, it demonstrates different approaches that must be explored by information architects when addressing complex business problems.
Understanding staff
User research techniques such as interviews, focus groups, contextual inquiry, and workplace observation are well understood and widely practiced by most IAs. While these techniques are important in general IA projects, they are critical for enterprise IA activities.
For a typical website project, the starting point is to define goals, objectives, and broad functionality. Research is then done to determine the best way to design and deliver the solution, with user-centered methodologies driving interface design and site structure.
Within the enterprise, the order is reversed. The starting point, as outlined earlier, is to conduct research with staff. The purpose is to identify the needs and issues of staff, which then helps define the goals and scope of the project.
This research is much more open-ended than typical user-centered design. Staff aren’t asked questions about the intranet, portal or document management system. Instead, the aim is to build an in-depth understanding of how staff work, and the environment in which they operate. In practice, we’re looking for issues and needs that we don’t even know to ask about. (The “unknown unknowns”, to quote a now-infamous speech in the US political arena.)
This approach is much closer to ethnography than user-centered design, and we can learn much from this discipline when working within the enterprise. By building up this depth of knowledge, we can target the most important needs, confident that the solutions delivered will be useful (and used) in practice.
Organisational change
Enterprise IA projects are only successful when delivered solutions are actually used by staff. While this is more certain when solutions are based on an in-depth knowledge of staff needs, a comprehensive change management plan will still be required.
Organisational change becomes a key element of enterprise IA projects. Information architects working within complex business environments need to have a strong understanding of organisational culture and how to work effectively within it.
For example, the greatest enemy of our projects is not active resistance, but apathy. While information problems within the organisation are generally widely known, they are not seen as sufficiently urgent or important to be addressed as a matter of priority.
Enterprise IA projects must start by creating a sense of urgency within the organisation. A strong message and vision must be created for the projects, and communicated widely to build support at all levels of the organisation.
Technology
Enterprise information architects must be prepared to work across technology boundaries. This is about delivering a single user experience that provides a seamless work environment regardless of what technology is used behind the scenes.
This means that enterprise IA projects must at least have an understanding of:
- intranets
- content management systems
- document and records management systems
- collaboration tools
- applications and databases
This is not to say that enterprise architects need to be technologists or developers. In most cases, enterprise projects will be supported by IT teams and departments that provide specialist skills in these areas.
Enterprise IAs must, however, understand enough of these technologies to create solutions, taxonomies, and designs that help to bring these systems closer together, towards the goal of a single user experience.
Working with others
There are many disciplines that are working to solve enterprise issues, including:
- knowledge management
- content management
- information management
- document and records management
There is no one group that “owns” the problem, or has all the skills, tools and resources to solve it. While each group has its own models and metaphors, each successfully addresses at least part of the overall problem.
This is where we need to build our skills in working with others, what Lou Rosenfeld calls our “horse trading” skills. This is not just about working in multi-disciplinary teams, it is about working with key individuals from other teams, business units or even divisions, all reporting through different chains of command.
(This is where establishing a “community of practice” focusing on enterprise issues can be very helpful. This approach is actually drawn from the knowledge management domain, further demonstrating the need for collaboration between disciplines.)
Successful enterprise IAs are those with people skills, perhaps ahead of their specialist skills in card sorting, taxonomies, wireframes, and paper prototypes.
A call to arms
The need to deliver better solutions within organisations is great. When driven solely by technology, enterprise projects almost invariably deliver unusable interfaces and poorly structured information that generates considerable resistance to change.
While information architects are not the only group working within the enterprise space, there is the opportunity to demonstrate leadership in delivering effective projects and solutions.
If this is to occur, then the information architecture community needs to build its knowledge in the areas of business strategy and organisational change. We also need the people skills to work well with many other groups within the enterprise, each of whom contributes some part of the overall solution.
This is not to say that all information architects need these skills. Designing interfaces and structuring information is a worthy challenge, and it remains as the core of information architecture.
Space must be found, however, to discuss and explore the unique challenges encountered within the enterprise. We must recognise that a strategic view is equally important as professional design expertise and enterprise information architects must be supported in their quest for best-practice approaches and techniques.
So much more can be written about enterprise information architecture, and this article merely scratches the surface. It is hoped, however, that it will contribute to the discussions in this space, and to help raise the visibility of issues already being wrestled with by information architects in many organisations.
Final words
All of this is not to say that information architects need to become specialists in business strategy and organisational change. We will certainly not be hired to develop business strategy for organisations (and nor should we be!).
In an ideal world, information architects will be part of a broader team within an organisation that includes change managers, professional communicators and other specialists. As part of this team, we must understand organisational issues, but are not responsible for resolving them.
In practice, however, information architects often work alone or in small teams. Even large corporations often leave IA projects with only modest support and resources, perhaps due to a lack of understanding of the full challenges involved in delivering enterprise solutions.
In these cases, information architects are then faced with two choices: become more proficient in the areas outlined in this article, or narrow the scope (and expectations) of the project.
In either case, enterprise information architects will always benefit by having at least a core knowledge of organisational issues and approaches.
Further reading
The fields of business strategy and organisational change are well-developed and supported by many highly effective resources. In particular, the following books have strongly influenced the author when addressing enterprise challenges:
- Leading Change (John P. Kotter; ISBN 0875847471) – this provides a very practical methodology for creating and driving change within an organisation. Required reading for every information architect.
- The Heart of Change (John P. Kotter, Dan S. Cohen; ISBN 1578512549) – a companion volume that explores the role of storytelling in organisational change, providing many powerful examples of real situations.
- Good to Great (Jim Collins; ISBN 0066620996) – explores why some organisations make the jump from “good” to “great”, based on extensive empirical research. Provides many insights that are valuable in enterprise IA projects.
Beyond this, there are many articles, journals, and training opportunities that can be used to build expertise in the fields of business strategy and organisational change. Once core IA skills have been developed, enterprise information architects should switch their focus to exploring these areas.
About the author
James Robertson is apparently the “intranet guy”, or so he was told at the IA Summit in Vancouver . He runs Step Two Designs , a consultancy based in Sydney , Australia , and has written over one hundred articles on intranets and content management, which can be found on his site. He also has a blog, the writing of which gives him something to do each morning while his brain warms up.
James, very thought-provoking article. When I think about enterprise IA, I think about how we need to think beyond any given project and start thinking more holistically. How does the project I am working on fit into the bigger picture? Am I thinking about knocking down silos and setting up opportunities for seamless data/information/knowledge transfer?
I think you bring up good points about how we need to connect with others in the organization who are more strategically minded, but I disagree with your phrase, “As part of this team, we must understand organisational issues, but are not responsible for resolving them.” It may not be part of our job description, but I believe as enterprise IAs, we are in the unique position to be agents of change. I find that in the process of requirements gathering, I often have the chance to speak with many different folks throughout the organization. In addition, my role often takes on that of the intermediary between the tech folks and the end users. This role therefore affords me the opportunity to influence the decision-makers.
I can be a change agent, but I must be aware of the culture in the organization. So many projects fail, by way of cost, time, or quality of the product. However, if we can be change agents, both aware of the “bigger picture” and aware of the culture in a given organization, then I think we’ll be better prepared to use our people skills to get buy-in on the projects we work on.
Nice article James. Gives a broad overview of the problems/scenarios in Enterprise IA.
IA’s should be the first to cut any activity/ function/content that would add to the information pollution. A fancy application built in-house would be no good if there is a publicly available tool and your enterprise users prefer the same to what you have so painstakingly crafted.
Analytics tools are a great way to understand how users how their system. I have seen examples where logs show us navigational paths from task based activity to the static content browsing. Such kind of research helps in crafting a solid IA that reduces time spent by employees on finding information rather than doing tasks.
Hi Rob,
“As part of this team, we must understand organisational issues, but are not responsible for resolving them.”
Actually, I agree with you on this. 🙂
My take is that really, we should be responsible for resolving some (if not all) of the fundamental organisational issues. I just wanted to soften the message, so as not to scare off too many IA’s. 😉
Cheers, James
Another important factor IMHO in Enterprise IA is to manage internal organizational politics. The amount of internal manouvering that goes on does seem to have an impact on IA strategy. Business units & Groups competing and justifying spends can make an impact and threaten to derail your goals.
True, especially in the stakeholder interview stage. We’ve found that some clients like to be in the room so that the strategy team is not in a position where we have to say no to stakeholder requests that we already know users will find cluttersome and irrelevant.
We’ve softened that message by saying, “good sites are a balance between business metrics and user needs–and we strive to hit that as perfectly as we can–with as much deference to our users as possible.”
or
“Hmmm…perhaps it is worth exploring. Depending on the prototyping budget and overall research timeframe, we can test that concept with a refined user population and see if they accept it as part of their content and functional goals.”
Yup, organisational politics is a major factor. This is why I’m spending most of my time reading books on leadership and organisational change… 🙂
As always, James, excellent content. I agree with the often overlooked oganizational issues you mention. It’s about time we acknowledge these factors and be aware of them so they don’t prevent us from accomplishing our goals.
Now, back to those books on leadership and change I go. 🙂
One of the first articles I’ve seen that discusses enterprise information architecture (EIA) as opposed to information architecture (IA) which most of us know as web IA. So thanks!
In the last 12 months I’ve taken on a role as an enterprise information architect in a university that has identified the need for and value of Enterprise Architecture. We still don’t have a clear idea of what EIA is, what it means for us, how we resource it or what we actually produce.
James suggests EIA should be part of a broader team in an ideal world. In our environment this is the case, however its not plain sailing. EIA is one of three viewpoints within enterprise architure in our organisation. However our lack of maturity in enterprise architecture means EIA is often overlooked as the more clearly defined and understood areas of application and infrastructure architecture become the focus of the discussion.
The comments about business strategy, lack of clarity around needs and goals, the need for in-depth understanding of staff needs and issues, organisational change issues, and the soft skills required are right on the money. At least based on my limited experience in the area!
I’d like to see more discussion about EIA: what it is, how its done and who’s doing it.
James,
Another issue I have seen in communicating widely within organizations about the vision and goals is that people really do not care much for this stuff. People are so involved in their routine work that another initiative or communication is seen a “yet another blah blah blah from mgmt”. In this process even extremely important initiatives suffer.
The question here is how do we communicate effectively. Do we foster involvement at a lager scale? BTW, am enjoying your article a lot and can relate to a lot of issues that you have mentioned here:-)
And a lot of these issues you have mentioned are fodder for new stories. Can we expect some more on the same?
Hear, hear. What you said. One addition:
— For better or worse, we have so grown as a trade, craft, guild that we are now deep inside large organizations, and many of our issues are purely turfological: who owns what, who can sign off on what, and how early can we get to the table so that we can guide and facilitate the decision making in the right direction from the beginning
Very insightful, refreshing, and honest take on what it takes to get good IA through (without loss of fidelity) in a complex ecosystem. If I may add a few points that deal with “attitudes, motivations, and approaches” taken by interactions designers and architects, both good and bad, perhaps adding more tools to our arsenal to be used in enterprise design exercises:
http://blogs.oracle.com/lukekowalski/2006/07/31#a28
The linked-in CHI prez (“Design is the Easy Part”) also talks about the same challenges, where focus on stakeholders and organizational dynamics is often more imortant than the raw data/design ideas…
Good article. Its nice to hear someone talking about EIA. I came to IA not from IT or web design but from being a Quality manager in the automotive sector for many years and came to IA through producing online quality manuals.
I find a lot in common between EIA and the Quality function. The skills/knowledge gained in document control, change management, negotiation etc from Quality I have found invaluable in my new career as an EIA.
EIA’s must also recognise that many organisations have now adopted various standards (ISO 9000, 14001, TS 16949 etc) that are important to their business. These standards must be subsumed and maintained as part of the enterprise’s information system. I think that information systems built around their internal policies and procedures may work better for some organisations but the traditional scope of the ‘Quality Manual’ must be expanded to include all areas/functions of the organisation. The scope of the information system must also reflect the organisation’s environment and ensure that all relevant external information is available and subsumed into the overall system.
Great to be having a debate on this!