Why it might be time to forget function, activity, transaction (aka Why everyone in the records and information management community needs to learn information architecture).

One upon a time, records managers developed classification schemes so that records managers and officers could store, find and manage their stuff. We practiced custodial record-keeping - because we could take custody of the one physical record that existed.

Those days are gone, but much of the thinking present in those days persists in our practices. Most of the records management field were educated during the custodial era, and even those who weren't are being educated by people whose theory and practical ideas came from the custodial period.

The idea of a function based classification scheme is one of these practices that came from the custodial period (and if we're being historically honest, from archival theory before being co-opted by record-keeping).

The basic idea is incredibly sound, logical and neat. How can anything actually exist outside of the functions and activities of an organisation?

The problem is that things can and do. The idea that every organisation is neatly broken down into functions and activities and everything happens neatly in those divisions doesn't survive the first contact with any organisation that has more than two people (HR/Recruitment doesn't start by recruiting someone to do HR/recruitment).

FAT is a nice idea, but it reflects a kind of proto-bureaucratic viewpoint about work in which every activity originates and manages its own work, contains all of the expertise to complete it, captures and handles all of its own information and completes the work without ever needing any other part of the organisation to be involved in any way - and that doesn’t exist in the real world.

Despite this mismatch between actual work and organisation of information about the work, FAT worked in the custodial era because we had files, and files did something that a FAT classification scheme couldn't - files crossed organisational boundaries while still keeping everything neat and being wholly self-contained.

The challenge now, is that files aren't physical things anymore, and work is specialised and distributed because it's the only way to be both efficient and effective.

It's simple things - like the fact that the first point of contact for initiation of a business process in most organisations isn't the team that executes the process, it's generally some form of customer service team.

Processes also regularly make use of information generated by other processes because many ideas are organisational - like identity. We expect to have to identify ourselves formally to an organisation once, and there to then be a relatively lightweight verification process for future work with the organisation (ie. 100 points of identity first, then name and date of birth later) with other processes - Name and Address Registers are a great example of this in local government, almost every process will rely on it, but no individual activity is wholly responsible for creating or updating it.

The challenge here is that any structure (information or otherwise) creates some kind of tension because it requires us to make choices that prioritise one need over another - ie. where does this process originate vs. where does the bulk of the work get done, and where does that mean the record sits? Or we would like three bedrooms so friends can stay, but we also need an office and we only have three rooms.

When we design effective information structures, they find the right level of tension between these competing needs. When we design ineffective information structures, they break - and people find workarounds that better suit the need they have.

I think we see a lot of this in the FAT (and FAST) classification schemes that are present in records management. The tension between the structure of the organisation and how work is organised, and how business processes need to cross function and activity boundaries is too much for the structure and our enforcement tools to bear, and so people work around it.

The two most common manifestations of this tension are that people create an information store that reflects how they work, or they mis-use the structures that we create so that they can work effectively within them - thereby destroying any chance that the structure will achieve the purpose for which it was designed.

This tension is one of the reasons that I think we are seeing so many records management programs fail to achieve meaningful capture rates.

So if we're moving away from FAT as the dominant paradigm, what should we be moving to?

I think the answers are in information architecture.

Information architecture is a discipline that emerged from physical architecture as people started to think about how information flowed through the buildings they were designing, and used that idea to improve their designs. Eventually, it became what we think of as information architecture.

It really rose to prominence with the web when people started to realise that the way they designed their websites could really make or break their businesses.

What information architecture brings to the table, is that it is descriptive, rather than prescriptive.

Both the bane and boon of FAT design is that when applied strictly, there is one right way, and we know when we're done. If you've got all your functions and activities mapped, and you have a space to store the information associated with your transactions - you're good to go.

Information Architecture just says that you need to be effective, and that there are lots of balancing problems to deal with - there's no right or wrong, you should structure your information in ways that let you achieve your goals. It's principles vs. rules.

Inherent in it though, is the idea that if the current classification scheme is resulting in people putting information in the wrong place - change the classification scheme. This includes ignoring structural elements of the organisation, or any other ideas about functions of your organisations and activities in those functions.

The challenge of this, is that you're never done, and you should expect your architecture to change over time - which creates a problem, because every change can mean user training and migration of data - which can be impossible, because of the way that some data is intermingled.

The issue is that either way we're stuck with a balancing problem.

Function, Activity, Transaction is not going to magically be more successful in the future than it has been in the recent past. So we can stick with it - and avoid the problems of change while also ignoring the fact that our work isn't structured like our organisation. We also have to acknowledge that it's too inflexible to deal with the way needs compete in the real world.

Or we can adopt approaches from information architecture - and accept the primacy of effectiveness as a goal that should outweigh all the administrative problems that it creates.

The nice thing about information architecture, is that there's room for FAT within it - because sometimes is just the best thing there is. The rest of the time, it falls back to basic principles that are core to us in records management - findability being core.

So what do you think?

Have you made strict FAT effective in your organisation?

Have you been practicing information architecture ever realising it?

Do you agree, disagree? Violently disagree?