6 Reasons Why Your PAA is not an Information Architecture

As tempting as it may be to use your unadorned PAA as a GCDOCS folder structure, be wary; what looks like an ideal shortcut, in most cases it turns out to be a “false friend” that may result in mismanaged IRBVs and severe end-user dissatisfaction. Here are 6 reasons why the PAA alone is not sufficient for your EDRMS/GCDOCS implementation.

‘But you’ve got a bee-hive–or something like one–fastened to the saddle,’ said Alice.

‘Yes, it’s a very good bee-hive,’ the Knight said in a discontented tone, ‘one of the best kind. But not a single bee has come near it yet.

Lewis Carroll, Through the Looking Glass

What is a Program Alignment Architecture (PAA)?

The Program Alignment (formerly Activity) Architecture is something that all Government departments and agencies that adhere to the Treasury Board Policy on Management, Resources and Results Structures should have on hand for planning, reporting and resource allocation.

How does a PAA relate to a GCDOCS/EDRMS Information Architecture?

To the IM Architect looking to implement an EDRMS/GDOCS, it is often one of the only up-to-date, enterprise-wide classifications available. As such, a departmental PAA may seem like the ideal candidate for an Information Architecture: it’s an enterprise wide classification; it nominally covers all activities in a given department; it traces sources for funding and has huge value for departmental reporting.

PAAs are far from useless in a GCDOCS/EDRMS context. Many end-users, records managers and those responsible for departmental planning and monitoring will find it extremely helpful to have the traceability to a PAA built right into their Information Architecture from the start. Business activities are by far the most stable element of a government department or agency, and the PAA can and should be able to map, or even frame these activities to give a solid account of the key business and information context of an organization. As a piece of metadata, the PAA is a fine candidate for a “mandatory” or inherited field, depending on the context.

But by itself, a PAA cannot stand-in for these activities. As tempting as it may be to stick in your unadorned PAA as a GCDOCS folder structure, be wary; what looks like an ideal shortcut, in most cases it turns out to be a “false friend” that may result in mismanaged IRBVs and severe end-user dissatisfaction. Here are 6 reasons why the PAA alone is not sufficient for your EDRMS/GCDOCS implementation:

  1.  PAAs are not designed to be user friendly. As a folder path, navigation structure, or even as a metadata facet, the PAA programs and sub-programs are not immediately intuitive to most users. Forcing users who are required to think functionally or organizationally for their everyday work to suddenly file to a PAA folder structure might raise some hackles and alienate them from the beginning.
  2.  PAAs are too high level for good records management. A PAA sub-program alone will in most cases be far too high level even for rationalized and newly “rolled-up” retention classification schemes. A single sub-program may still comprise a wide range of different activities that all could entail different records classifications and periods. Furthermore, regarding the Library and Archive Generic Valuation Tools (GVTs) no PAA program or subprogram will map exclusively or simply to a single GVT or GVT activity. Trying to fit an IM or RM-based classification using the LAC GVTs within an architecture based on the PAA requires careful consultation, interpretation and analysis. A departmental PAA alone is not sufficient to map to these activities.
  3. PAAs are unknown.  There is no guarantee that a department’s PAA is known throughout the organization. Beyond the fact that most users will not be comfortable with the PAA, some users may be genuinely baffled as to what parts of the PAA apply to their work. Using strict interpretation of the PAA as an implementation architecture for your GCDOCS/EDRMS environment will require major contortions and upsets to the business realities of the department.
  4.  PAAs can shift. As priorities and emphases change within a department, the PAA may follow suit. While activities and functions may remain relatively stable within a given department, a PAA has no reason to maintain a particular hierarchy in order to satisfy secondary considerations to its raison d’être ­– such as IM or user experience.
  5.  PAAs can break up families. Not only does the PAA exclude the mixing of activities, it also doesn’t usually take the organizations of a department into consideration. A single program may span over multiple organizations, while another may only apply to a tiny division or even a subset of activities performed by a specific group. Blindly using a PAA to separate co-existing organizations is an unnecessarily complex way to set up an implementation.
  6.  A PAA is developed for planning and reporting, not filing and finding. Just because a map shows you where there grocery stores are, this does not make it the same thing as a cookbook. As stated in the Policy on Management, Resources and Results Structures the PAA is architecture for managing results, decision making and ensuring accountability to stated outcomes and priorities. While it is certainly a useful tool for these activities, nothing about the PAA’s history or intended use have anything to do with providing end-user experience for a system or an exhaustive classification of electronic information objects. In many cases, the PAA is an intended state – a story through which a department can frame its activities and funding in the context of its mandate. Admirable as it is, this alignment can have precious little to do with existing information resources insofar as individual, classifiable and findable IRBVs.


Leave us a comment: * Your information is never shared