19.4. EIA Strategy and Operations We've described EIA design work that focuses on small steps and quick wins that don't necessarily require a huge outlay of resources, time, or staff. Because so many of these improvements can be made "under the radar," they often can take hold without requiring management sign-off up and down the chain of command. Of course, there are far more ambitious designs that you can tackle within each of the four areas we covered above. But whether the focus is on short- or long-term goals, someone has to be responsible for design, implementation, maintenance, and governance of an enterprise information architecture. And management will ultimately have to be involved in setting policies, finding funding, and settling the political disputes that will inevitably arise. Unfortunately, most enterprises have not dedicated staff to this work, or if they have, those staff are buried inside other business units that distract them from their primary goals. And management, despite its talking the talk of "information is our most strategic commodity" doesn't yet walk the walk. How does ownership of an enterprise information architecture evolve? 19.4.1. A Common Evolutionary Path The following table charts a common path for both operational and strategic aspects of EIA. Strategic work focuses on the growth, positioning, funding, and governance of EIA resources and staff, while the operational side addresses who actually does the work of developing and maintaining an EIA. This table shows how both tracks can evolve side by side over time, often in concert, in a "typical" enterprise environment. | Operational EIA | Strategic EIA |
|---|
| Individuals recognize that EIA issues existA handful of people "in the trenches" responsible for some aspect of their business units' respective information architectures independently become aware that there are IA challenges that affect the entire enterprise. They may see the need for their own work (e.g., managing a search engine, developing product metadata or a style guide) to be coordinated or shared with others, but have little or no contact with like-minded peers within the enterprise. Nor do they have incentive to coordinate efforts. | Managers stuck in redesign modeManagement is mostly unaware of and disinterested in EIA issues, although it may occasionally grapple with other relevant enterprise issues, such as branding. Typically, the enterprise web site is in the hands of the marketing function, and the enterprise intranet is managed by IT. Efforts to improve either site tend to be of the one-shot comprehensive "redesign" variety; accordingly, momentum quickly dissipates, and little institutional knowledge is retained.At this point, there is little value in attempting to engage decision-makers in the process of developing a coordinated EIA. However, some managers may begin to emerge as possible future champions of EIA projects. | | Community of interest emergesAs IA becomes more accepted throughout the enterprise, more people assume the job title "information architect"; it becomes easier to find similarly titled peers. Other triggers for bringing IA peers together include external events, such as attending local professional meetings and IA conferences, or the installation of an enterprise-class application (e.g., CMS, portal, or enterprise search engine), which requires significant configuration by internal staff.An informal community of shared interest within the enterprise emerges, typically through the efforts of one or a few instigators, and is usually managed via an email discussion list and regular brown-bag lunches. At this point, few efforts are made to coordinate IA activities; it's more typical to compare notes on "how we did it" (e.g., how best bets are being implemented locally), as well as sharing external best practices gleaned at conferences. | Friendly managers lend tacit supportA few "enlightened" managers emerge; their recognition of EIA issues often comes directly from analyzing the failures of past redesigns. These enlightened managers aren't yet in a position to provide resources or to allocate a portion of staff time to EIA efforts, but are supportive (or at least don't disapprove) of their staff who wish to participate in the informal activities of the community of interest. | | Community of practice achieves formal recognitionThe community of interest becomes one of practice, with IAs from different units quietly coordinating efforts with enterprise implications. Examples include developing user-centered requirements for inclusion in functional specifications when new enterprise applications are being selected, and sharing budgets to cover software licenses or consulting from IA specialists (e.g., taxonomists). A semi-formal leadership structure emerges within the community of practice, mostly to manage communications within the group (rather than activities or resources). Local business units' respective IA activities still trump EIA work for all involved. | Advisory Committee emergesFormalization of an in-house EIA community comes in the form of an official "blessing" on the part of managers. These managers are often drawn from a combination of friendly managers and "squeaky wheels" (vocal managers responsible for major content areas, product groups, or user constituencies), and they take on a semi-official role as an Advisory Committee. Meetings are irregular and often draw attendance from a different subset of managers each time. Official Advisory Committee responsibilities are minimal. At this point, its chief role is to serve as a means for communicating about EIA and related issues between departments and, occasionally, to advocate to senior managers on behalf of the community of practice when it identifies specific needs or requires help dealing with policy issues and internal politics. | | Distributed teams assigned to specific EIA projectsGrowth in demand for better EIA coordination leads to formal allocation of IA staff to specific enterprise projects, especially around the implementation and configuration of enterprise-class applications, as well as metadata and interface design guidelines. IAs from business units continue to work primarily on local projects, but their enterprise allocation continues to increaseeven if only for temporary projectsand they begin to take on formal responsibility for EIA-related projects.EIA teams that are initially constituted for specific projects increasingly become permanently established. External IA specialists are more commonly brought in to assist in EIA efforts. | Advisory Committee matures; Strategic Board backs it up The Advisory Committee becomes a formal decision-making group, advising EIA teams, formulating EIA policy and strategy, and paving the way for projects when EIA teams need more senior-level assistance. The Committee meets more regularly, and its membership becomes increasingly representative of important constituencies and internal units (extending especially beyond IT and Marketing).The Advisory Committee recognizes that its growing scope of responsibility requires additional authority and funding; it advocates for the creation of a very senior Strategic Board (akin to a company's Board of Directors) to put at least the appearance of teeth into proposed policies through visible support (even if this support takes the form of rubber-stamping new policies). The Board, which meets every few months, also helps identify sources of funding for major EIA-related projects. | | Business unit dedicated to EIA in placeA permanent EIA unit, usually drawn from internal staff, are now in place, with its own management structure. Team size varies, often based on scope (some units are more broadly focused on enterprise user experience or knowledge management). As team size reaches double digits, specialists in such areas as metadata development, user testing, search systems, and metrics are brought on as full-time staff. Though their primary responsibility is the enterprise architecture, both generalists and specialists also provide IA consulting to local business units on an as-needed basis. The EIA team also takes on a leadership role in training local IA staff and with EIA "intellectual property," such as the enterprise-wide style guide and metadata standards. | Strategic players formalize and expand their rolesSeeing the strategic nature of enterprise information, the Strategic Board takes on a greater role, paving the way for the creation of a new cost center, a business unit dedicated to EIA and related areas. Other groups that have a role in EIA strategy begin to form, such as a user-advocacy board (useful for maintaining an enterprise-wide pool of users for testing and evaluation purposes).The Advisory Committee also takes on a more formal, active role as the primary decision-making group, serving as executive managers of the EIA business unit. |
This isn't how it always happens, but it's a relatively close approximation of the mean. (Another common path toward in-house EIA competence involves the migration of an e-commerce team or web development group to a group that addresses EIA as well.) More importantly, this evolution will provide you ideas and, if nothing else, a straw man that you can react to as you chart your own course. 19.4.2. The EIA Group's Ideal Qualities and Makeup As with an actual information architecture, you should consider assembling an in-house EIA group from both the top down and bottom up. Think of the top-down approach as the strategy end of things, where senior people figure out the big picture of where the EIA unit should be headed and how it will get there. The bottom-up side is comprised of the operational tasks involved in actually doing the work at hand. As much as possible, separate these two areas; their respective missions, tasks, and members will be quite different. 19.4.2.1. The strategists The strategistsmembers of the Advisory Committee and Strategic Boardfocus on the role of the EIA unit within the broader enterprise. Their mission is to ensure that the enterprise benefits from a quality information architecture through the efforts of the EIA group. Their goals are to: Understand the strategic role of information architecture within the enterprise Promote information architecture services as a permanent part of the enterprise's infrastructure Align the EIA operations team and its services with the enterprise's goals Ensure the financial and political viability Inform EIA operations of changes in strategic direction that may impact the enterprise's information architecture plans Help develop EIA operating policies Support the EIA team's management Assess the EIA team's performance
In effect, strategists are responsible for the success of EIA operations. That means navigating politics, getting buy-in from management across the enterprise, and acquiring funding and other resources. It also requires the development of metrics to help judge the success of the enterprise information architecture broadly, and EIA operations specifically. People who would be effective and available in the director's role exhibit these qualities: Have been in the enterprise long enough to have wide visibility, an extensive network, and the ability to draw on years of institutional memories and experiences Are entrepreneurial; can read and even write a business plan Have a track record of involvement with successful enterprise initiatives Have experience with centralized efforts, successful or not (failures are as informative as successes) Can navigate political situations Can "sell" a new, abstract concept; have experience finding internal funding Resemble or can at least understand your clients in terms of outlook, position within the org chart, personality, and golf handicap Have experience with consulting operations, either as a provider or a purchaser Have experience negotiating licensing agreements with vendors
19.4.2.2. Operations People The EIA operations team takes on the tactical work of information architecture: researching and analyzing factors related to content, users, and business context; designing information architectures that address those factors; and implementing that design. Besides delivering the EIA Unit's services, the operations unit follows (and upholds) policies and procedures for content management and architectural maintenance. How should this team be staffed? There are many roles that would be nice to have on your team, including: Strategy Architect Thesaurus Designer Interaction Architect Technology Integration Specialist Information Architecture Usability Specialist Search Analyst Controlled Vocabulary Manager Indexing Specialist Content Modeling Architect Ethnographer Project Manager
Of course, staffing each of these areas is a fantasy for most of us, but this ideal gives you something to shoot for. More importantly, it helps you line up outside consulting expertise. Don't have a usability specialist on staff? Your entrepreneurial business model might allow you to pass a consultant's costs to your clients. When you do get around to hiring staff for your interdisciplinary operations team, look for these qualities: Entrepreneurial mindset Ability to consult (i.e., do work and justify IA and navigate difficult political environments) Willingness to acknowledge ignorance and seek help Ability to communicate with people from other fields Experience within the organization Experience of prior enterprise-wide centralization efforts Sensitivity to users' needs Knowledge about information architecture and related fields (of course)
Finally, consider what gaps your EIA unit is filling within the enterprise. You may find that you want to broaden your scope, branching toward conventional IT services such as hosting, or toward visual design, editorial, or other areas under the broader umbrella of experience design. Select your staff and consultants accordingly to fit the needs of the enterprise. |
