Paula: The efforts of data warehousing represented the bright hope of finally getting data out of the bowels of corporate applications and delivering it to the everyday workers making decisions. Up to that point reams of "green bar" reports went unused because typically they only contained references to data that was needed to make decisions. Individuals had to first filter and then put the data in their own context, often combining and recombining data, to derive value -- witness the proliferation of standalone processes based on spreadsheets. But the data warehousing projects were treated like all other systems engineering efforts and had simple rollout plans. Companies were just not prepared to fundamentally restructure core processes, redefine roles and change organizational designs to take advantage of what was being implemented.

Lou: In your TDAN columns you discussed some of the failings of the systems engineering approach to developing systems. What's wrong with systems engineering? Is there some new paradigm emerging that we should pay attention to, if not adopt?

Paula: Well, having spent many years immersed in systems engineering, I would often find myself shoving multitudes of "update pages" into multi-volume methodology manuals and discovered something: all the various methodologies started with directions based on some aspect of "using the requirements...." I realized then that the whole rest of the process was doomed: all of the methodologies assumed that requirements were these "things" that already existed.

If you tried to learn more about how systems engineering approached the requirements gathering process, you found that the classes taught by the experts focused on the process of managing requirements, but did little to improve the process of eliciting requirements. No one seemed to be responsible for this process and there was certainly no role defined in most methodologies for subject matter experts who would accept responsibility for requirements. It was simply a task left to systems designers or programmers.

After the requirements were gathered, the "essence" of their intent was often lost as the work was handed off from team member to team member. So I kept looking for a better way.

Lou: Where did you look?

Paula: Initially at data warehousing and CRM (Customer Relationship Management). Here were two areas that seemed to offer promise because their goal was to support customer analysis. In other words, ongoing use of these systems was so crucial to their owner's business success that their requirements had to be continually fulfilled beyond roll-out.

Now I'm involved in customer experience design and the evolving disciplines embodied by the interactive agency model, with far more focus and blending of left and right brain activities. It's more organically whole and therefore more stable to support continuous change, which is what companies have been asking for help with from technologists for years.

It was also fairly obvious who didn't value it and that was a big indicator that a) we were probably not the right development group for them, and b) if they had trouble valuing IA, they probably would have trouble valuing all of our development group.

Lou: Is there an analogy here for information architects?

Paula: We certainly appear to be a very mixed-brained group, so we have great potential. But we still haven't tackled the "how do we successfully define and ensure the implementation of business requirements" issue yet. In order to accomplish the last half of that issue we will need to champion efforts to fundamentally change the way businesses are designed and operated if our work is to be successful.

Lou: Getting back to your sabbatical, you spent time boning up on, among other things, ethnography and Ayn Rand. Very interesting. What's the connection?

Paula: Both are artifacts I collected along the way of trying to solve the requirements dilemma. I started with epistemology, the philosophy of learning. Ayn Rand's Introduction to Objectivist Epistemology describes how we, as infants, immediately need to classify things based on what they are and what they aren't. Definitions of things typically do not tell you what the subject is not, yet I often found that database administrators would ask me questions about data elements where they clearly needed to know if an item was "not" something in order to make sure they were going to select the right data.

I was also struck by our need to understand how people think and perceive to better understand what they are telling us and what they aren't telling us. It is imperative to use these theories to better design our results, again, based on how people will perceive things and how they learn. Ethnography (a set of methods and techniques used primarily by anthropologists in their field work) is definitely another artifact that can help us improve requirements gathering. With ethnographic methods we can consider how the immediate and not-so-immediate environment influences an individual's ability to perceive what needs to be accomplished and how it can be accomplished, using what lies before them.

If given a budgetary constraint, I would much rather pay for a corporate anthropologist to help assess what the opportunities and challenges of a situation are, than to have a usability expert on the team. That's not to say that I don't value usability experts. But from my experience as a technical writer, I can tell you that people can only tell you part of the story as it relates to their experience; a trained observer has to fill in the rest.

Lou: I'm sure the usability engineers out there will love hearing this. So how did this year and a half mental break get you into information architecture?

Paula: It really was a continuous evolution. I had already adopted the title Information Architect (and had several colleagues follow my lead) while at MCI, mainly because if I called myself a data architect people would have expected me to design data models. I did design data models, but from a conceptual perspective. People who hire or fill positions typically don't know the difference. And I really was involved in the perspective of the recipient, including designing an intranet to help fill in some context for individuals to decide which data in the warehouse would help solve their problems. While this is generally referenced as the metadata, I've always said it's just bigger than the "essence of the data" - it also includes the "essence of the people", metapeople; the "essence of the process", metaprocess - so you'll often hear me refer to meta"stuff".

Looking for a new job and using job search engines, I kept throwing out the title "Information Architect" to see if I'd get any nibbles. For a long time a lot of "old boots" would show up-typically someone using the term looking for a data jockey. But a year ago "Information Architect" started showing up more frequently, and the job descriptions began to match both my talents and my interests. The transition was easy for me because other than the specific form of the deliverables, and some of the terminology, I had already been doing all of the tasks required to get to the deliverables.

Lou: From your perspective as a technical writer cum systems engineer cum data warehousing specialist cum information architect, what significant trends do you see impacting information architecture as a field?

Paula: Well, I'm not sure it's a trend yet, but there's certainly an opportunity for information architects to take a leadership role in defining customer experience. Why? Because customer experience does not begin or end with the Internet. Someone has to be interested in the bigger picture. If we don't step up to the plate, who will?

That leads to a second trend: the collaborative agency model will gain ground within organizations. In order to ensure a successful Internet experience, we have to design it in conjunction with all other touch points of interaction. We have to learn to integrate and optimize experiences. This breadth of responsibility will not be the responsibility of a single role. That's why, down the road, information architecture will be performed by a whole division that includes multiple architects in a variety of roles.

Lou: It's interesting that you're seeing the agency model getting more play; I'm guessing that this is mostly true of your most sophisticated clients?

Paula: Recently I watched in awe as a company, that Geoffrey Moore would describe as a "laggard," asked us to help them adopt aspects of our agency model to support their increasing volume of Internet-based development. I suddenly realized that if a laggard company was doing this, then there must be many others. Subsequent engagements have confirmed this. And through recent dialogs with industry analysts, who also want to insist that this is likely only a trend among the "leaders," it appears that no one else sees this trend or takes it seriously.

The Gartner Group made the prediction that by the year 2004, 80% of technology components in corporations will be Internet-based. A simple correlation can be drawn that a near equal amount of Internet-based development will be going on. As corporations begin to supplant their IT departments with models that begin to look more like interactive agencies, there will be an immediate and significant shortage of Information Architects, not to mention all of the other design-related roles. These are certainly uncomfortable but wonderful challenges…

Lou: …and your points validate some trends I've been noticing: there certainly won't be any impending shortage of information architecture positions. But if you're getting into the field, you'd better be prepared to be part of a team-we're all beginning to face projects that are simply too huge and complex for solo IAs to take on. Thanks Paula!