Home/Publications/Best Practices Newsletter/2013 – Best Practices Newsletter/The Roles and Responsibilities of an Information Architect

CIDM

October 2013

 


The Roles and Responsibilities of an Information Architect


CIDMIconNewsletter Severin Foreman, Altera Corporation

This article is based on a presentation I gave at CIDM’s CMS/DITA North America 2013 in Rhode Island. While the presentation title included “Roles and Responsibilities,” I realized afterwards that I focused mostly on the responsibilities. Since I think the roles an Information Architect (IA) plays are important, I framed this article around the roles of an IA, and I discuss the responsibilities contained within each role. For each role and responsibility, I also list questions you want to ask in that role. Because my experience as an IA involves helping organizations transition to structured authoring and DITA-based publishing, the article is written from that perspective.

Since DITA is an emerging technology, and because the position of Information Architect is new within the field of DITA content production, what it means to be an IA can vary widely depending on

  • your experience and skills
  • the needs of your organization
  • the experience and skills of others in the organization

Whenever I hear other IAs speak, I’m always amazed at how different their focus is from my own. I can speak from my experience as an IA, but I’m just one IA in a big world.

Below are the roles I’ve played as an IA. I’ll delve into each deeper throughout the article:

  • Requirements Analyst
  • Salesperson
  • Information Model Developer
  • Project Manager
  • Trainer/Coach
  • Programmer
  • Leader

Requirements Analyst

Analyzing requirements is a key role and should be an ongoing one. I divide requirements analysis into two categories: audience requirements and writer requirements. There is usually a big push to analyze audience requirements at the start of the project, because the desire to better serve your audience frequently drives a conversion from the current authoring and publication system to one that is DITA based. But analysis of customer requirements doesn’t have to end as a DITA implementation matures. New requirements can emerge as systems evolve, and overlooked requirements must be addressed in later phases of the project. If your organization wants to continuously improve information delivery channels, gathering audience requirements is an ongoing task.

Questions to ask when analyzing audience requirements:

  • What are the current pain points for your audience? Maybe your team is limited to delivering information in one format. There might be issues with consistency and accuracy of information. Try to frame these matters in quantifiable terms whenever possible. And by quantifiable, I mean money.
  • What don’t you want to change?
  • How would you like to innovate? Do you want to automatically incorporate data from external sources into publications? Deliver content to mobile devices? Provide new channels for audience feedback?

In addition to analyzing customer requirements, you also want to analyze writer requirements. I call writers my “other customers.” Increasing writer productivity and efficiency helps them to do a better job supporting the performance of your audience.

  • What are your current pain points? Do writers spend too much time tracking down all instances of the same content? Is there inconsistent formatting or application of standards? Does your team spend too much time in production? Are different people using different tools and holding different licenses?
  • What do you like about your current system? Sometimes the team won’t know what they will miss until it’s gone. In the systems I’ve implemented, writers do not have control over page formatting in PDF output. Writers have been mostly OK with this, but occasionally miss the ability to adjust the appearance of output. However, a colleague I met at the conference told me how his system allowed writers fine control over page formatting in a DITA-based system.

Salesperson

Wait! Don’t stop reading. I realize that the role of salesperson might seem out of place, but if you are championing a conversion to a DITA-based system, you need to repeatedly sell that system to writers, to stakeholders in other departments, and to management. In many cases, you fulfill the role of salesperson by simply communicating progress and explaining the details of the new system and its benefits. Craft your message for each audience and multiply the message by repeating it frequently and using different communication channels. Use email, social media (if available), meetings, and presentations as opportunities to evangelize what you are doing.

Writers and other publications stakeholders want to know how the output you produce will be improved and how the new system will affect how they do their jobs. SMEs will have the same questions about output changes and also want to know how working with DITA will change their ability to contribute or review content. Management wants to know about all of the above, plus the costs and fiscal impact of the new system. When communicating to management, remember to demonstrate how improvements in documentation help increase operating leverage (simply put, the gap between costs and revenues).

The benefits of the new system will not be self-evident to everyone. People need to be reminded about the changes and the progress your team is making. If you have consistently communicated the benefits of the system and the progress that your team has made, you can refer to prior communications when confronted by people who haven’t read them.

In the role of Salesperson, you might need to perform the following tasks:

  • Write a business justification
  • Develop metrics to measure progress
  • Craft the definition of success
  • Send regular communications to writers, management, and external stakeholders

Questions to ask in the role of Salesperson:

  • What will the new output look like?
  • What day-to-day or release-to-release efficiencies will be gained?
  • Who are the budget approvers?
  • Do other departments need to be involved?
  • How will your project change the way your company produces content?
  • How frequently do you need to communicate with various stakeholders?
  • Which communication channels are available?
  • How will you get feedback?

Information Model Developer

Because the information model sets the standards and rules that govern content development, developing an effective one is a primary IA function. The process of developing the information model is likely to yield many interesting and passionate discussions with writers, who can have strong opinions about how information should be structured and presented.

Story: How I Removed the <xref> Element from the DITA DTDs

Early in the process of implementing DITA at Epicor Software, I attended a DITA user group meeting where Michael Priestly gave a presentation on DITA linking. Priestly explained that inline links make content less readable, and he demonstrated how you can use the DITA map structure and relationship tables to generate links at the bottom of a topic. I was sold! I took this information to my team and suggested that we remove all inline links from our help system and replace them with “DITA style” links. The team responded with immediate and strong resistance. “Inline links are everywhere,” they said. “I wouldn’t recognize online help without embedded links.” Since we were all newcomers to DITA, I did not have the authority to override the team and implement my ideas. We were at an impasse. It was a stroke of luck that caused one of the strongest proponents of inline links to have a reversal on the subject. The following are excerpts from an e-mail thread that described why he changed his mind.

From his first message:

I’m starting to question if having links within the text is effective. Many times when I’m reading through a help topic, I just skip over these links

[and] continue reading the topic. If I do click on them as I read, I really disrupt the flow of information and often have to page back to find my place on the previous topic. They are annoying and actually disrupt my understand[ing] of the topic.

He also wrote this after I asked him why he had changed his mind:

What sparked this change is that my home computer nearly fried here a month ago, so I spent a lot of time reading help topics. It is a different world when you are using the help, instead of creating it. I found the info I needed, but wow, using the help was stressful. Was I entering the right words? Should I click on that link, or will I find everything I need on this topic? What should I do? I need to solve this problem…

His real-world experience trumped all theoretical arguments. I now had the most senior writer on our team on my side, and with that I removed the <xref> element from the DTDs.

Along with defining content structures, you might be introducing your team to topic-based authoring and minimalism, the details of which can surprise many. Language that used to make sense in the context of a book-style publication might not be meaningful when the same content is published online.

Questions to ask in the role of Information Model Developer:

  • What opportunities for content reuse exist and how do you set up topics effectively?
  • What types of navigation are important?
  • Which elements do you need and which can you omit?
  • Do you need specialization?
  • When should you use your experience as an Architect as an argument for doing something a certain way?

Story: When to use “I’m the IA” as an argument

Part of the DITA implementation at Altera involves transforming a significant amount of existing documentation to DITA, which must be stored in a file-based system until we can acquire and implement a Component Content Management System. During a meeting, our team was struggling to devise a file naming and organization standard that would meet the needs of various sub-teams. After half an hour of discussion that seemed to go in circles, I finally said, “Listen, I’ve used the system I’m proposing before, and it scaled very well. I think I need everyone to just trust me on this.” That argument successfully ended the discussion. Later, I expressed to a colleague that I prefer not to settle issues by saying “I’m the architect, that’s why,” he said, “But that’s why we hired you. You’ve been there before and have the experience to help us with these decisions.” So the lesson is that sometimes “I’m the architect” might be the correct way to settle an issue. However, I don’t want to rely on that strategy too often.

Project Manager

Implementing an information architecture is a multifaceted initiative with many aspects that must be managed independently to meet the larger strategic goal. It requires time management and planning skills to be able to prioritize and delegate tasks. Some of the initiatives to manage include

  • Analysis of customer requirements
  • Analysis of writer requirements
  • Development of a taxonomy (or formalization of an accidental taxonomy)
  • Selection of tools
  • Implementation of tools
  • Development of an information model
  • Development of output styles
  • Implementation of code and branding changes
  • Training schedules for writers, managers, and external stakeholders
  • Tracking overall progress

Trainer/Coach

Moving to a new authoring and publishing architecture is a significant initiative, one that requires copious amounts of training for various audiences. Obviously, the technical writers need training. But there might be several other audiences, too. For example, other managers in your department might want to use or learn about DITA. Part of the new information architecture might involve getting direct content contributions from subject matter experts, or the subject matter experts might be using new tools to perform reviews. Also, if you can, try to train some team members to perform architectural tasks, whether that is related to information modeling, stylesheet development, or scripting.

One of the major challenges of training is delivering the right amount at the right time. DITA is a challenging subject, especially if the writers on your team are unfamiliar with XML, structured authoring in general, or topic-oriented authoring. I have found that new practitioners can become overwhelmed within the first hour of training. Add new tools to the mix, and the technical communicators on your team have a lot to learn.

Because learning anything new can be difficult, it’s important to instill confidence in the team as you go along. Assure the team that they will get it and that you will be available to help as they put their new knowledge and skills into practice

Questions to ask in the role of Trainer/Coach:

  • How much training is needed?
  • Is it possible to take a phased approach?
  • How do I handle training in areas where the information model has not been finished? It’s hard to think through every aspect of an implementation, so issues do come up during training or at later stages.
  • How much do managers need to understand how content will be written and published?
  • Is it possible to train others to support architectural initiatives?
  • How often should I communicate progress (while not inducing information fatigue on the part of my team)?
  • Do I provide enough encouragement?

Programmer

Depending on the tools your organization acquires to author and publish content, there might be several opportunities to brand and customize output or to automate processes. In fact, there are so many possibilities to improve systems, that any particular technical skill you have (or would like to have) can be useful. Other areas can be contracted out, filled by other writers or by colleagues in other departments, or you can develop workarounds until solutions become available.

Questions to ask in the role of Programmer:

  • What opportunities are there to automate systems?
  • What are the organization’s branding requirements?
  • Who are the owners of various systems with which you need to integrate?
  • Which skills do you have that can help fill these needs and which skills need to be acquired from somewhere else?

 Leader

One constant I have encountered as an IA is that teams are hungry for leadership in a variety of forms. As an IA, you provide tactical leadership, which involves resource planning and overcoming obstacles that occur during the execution of a project plan. You might also function as a manager with a team reporting to you.

But perhaps even more importantly, you have the opportunity to lead strategically, to craft the future direction of your team. Even if no one is reporting directly to you, many people will depend on your sense of direction and confidence in execution. People want to know that you are aware of industry trends so that you can recommend and implement solutions that not only meet, but also delight writers and users alike. Strategic leadership is more than a superficial aspect of the job. Things only get done when people believe that they can be done. Your role as a leader instills that confidence.

Questions to ask in the role of Leader:

  • Do team members and others know how the new content and publication will look?
  • Am I devoting enough time to stay aware of industry developments?
  • Do other departments understand our initiative and appreciate the benefits?
  • Are your team members aware of the progress they’ve made?
  • Do you have enough space in your schedule to think strategically?
  • Do team members feel as though they have a positive impact on the project?
  • How does your organization make decisions?

Beyond the Roles and Responsibilities: Challenges you might face and culture change you might need in your organization

Challenges that an IA Might Face

The following are some challenges that I’ve seen at multiple organizations in the role of IA.

  • The big one—It’s hard to move a team to topic-oriented authoring: Information is more granular than before. Publishing to other media means that structures and language that made sense in books might not be appropriate. For example, language like “this chapter includes” is no longer appropriate in an online help environment.
  • Even writers who buy into the vision and seem to “get it” can struggle when writing actual topics: I’ve seen this one over and over. As you work with team members to develop the information model or other aspects of the system, some writers will demonstrate an excellent grasp of topic-oriented authoring and minimalism. But when the same writers begin drafting DITA content, they regress to habits associated with long-form book authoring. Even after people understand the concept of topic-oriented authoring, it still takes time to actually write effective topics.
  • Writers who think it’s a bad idea: Every team has at least one of these. It’s as though it’s a role on the team that must be filled. In my experience, the objections of naysayers are usually outweighed by the energy of the proponents. I have also seen team members with the strongest objections become proponents of the new system once they appreciate the benefits of it. My advice is to be patient and understanding. Every system has shortcomings, and those should be acknowledged while still promoting the benefits. Also, keep in mind that the complaints of your local curmudgeon might actually contain good ideas for system improvements.
  • Writers who want to continue desktop publishing: Many writers say that they welcome the idea of focusing more on content, but then sorely miss the ability to make last-minute formatting changes to their publications. One major benefit of moving to an XML-based system is that writers will spend significantly less time adjusting the format of output, but you will need to repeatedly (and patiently) remind people of it. I’ve gotten many requests to adjust the formatting of the stylesheets because a writer does not like the appearance of a single page in a single document. It’s hard to explain that any change you make affects all writers and all publications and that a change can mean a significant amount of regression testing.

Culture Change and Uncertainty in Your Organization

Lastly, changing to a DITA-based system with new tools and writing processes inevitably changes the culture of your organization. The first change is that collaboration increases. Teams that reuse content must work together more closely. And if everyone is using the same tools, writers can potentially be reassigned to the highest priority projects with greater flexibility. You might also find that new leaders emerge on the team because some people will adapt more quickly than others to the new processes and tools.

All of these changes can contribute to uncertainty and feelings of insecurity in your organization. Writers will struggle with new tools, new writing methodologies, and new publishing systems. Some team members who were the “gurus” in the old system might feel that the skills that made them indispensable are no longer needed. These feelings are natural and unavoidable. You can, however, do a lot to mitigate the effects. Be sure to employ the communication, training, and leadership strategies mentioned earlier, and make sure that team members have a significant role to play in the development of the new system and give people as many opportunities to have an impact as possible. CIDMIconNewsletter

About the Author:

serverinforeman

Severin Foreman
Altera Corporation
sforeman@altera.com

Severin Foreman is the Technical Communications Manager and Information Architect at Altera Corporation. He has 13 years of experience working with XML and XSLT and over 7 years of experience with DITA. Severin transitioned from Technical Writing to Information Architecture at Epicor, a software company, where he led the successful implementation of a DITA-based system. He holds a BA in English Literature from San Diego State University.

 [level-members]

We use cookies to monitor the traffic on this web site in order to provide the best experience possible. By continuing to use this site you are consenting to this practice. | Close