A New Service Model For Records Management

I was at an ARMA lecture series this week in which the topic of discussion was the lifecycle management of records – was it truly a lifecycle or is it more of a continuum and how do you present that to users.

I personally found that the discussion was completely off the mark.  Who cares what you call it – the point is that information (records) is part of a process and the value of the information is based on the state of the process within which it is being created or used. This means to me that Records Management isn’t so much responsible for the end product (eg: a record) but the integrity of the processes used to manage the record through all its states – and that can’t be done effectively at the end of the process when the user is finished with the document.

Records Management discussions have to evolve into discussions of how and where records management can feed into the organizations business model.  Business models are changing as new technology services appear.  The skill sets of Records Managers are well placed to help guide an organization through those changes, but records management services will have to expand into three areas:

1. Business advisory services whereby Records Managers can provide advice on how to deliver on the principles of accountability and transparency that so many companies bandy about.  This will require records managers to be able to draw a correlation between the companies business model/accountability framework and the value of recordkeeping practices for the senior management team.  They will need to be able to explain how these practices can feed a company’s objectives for agility and innovation, while minimizing risk …. and this can’t be done by talking about the relevancy of the records lifecycle.

2. Business Analysis Services – Records Management resources must also become part of the application development team to:

  • Educate users about information characteristics (security, access, which information item produced through the process is important, for how long, etc.) when they have a stake in the outcome.
  • Guide business users through the identification of requirements to ensure that record keeping practices are incorporated as seamlessly as possible into the tool being developed – and that the end-user is the one asking for it.
  • Provide the record keeping metadata standards to be captured within the business tool and through the business processes.
  • Educate IT resources in general about the principles of recordkeeping – these aren’t separate requirements, they are foundational requirements to any business application.

3. Information Architecture – Records managers have a lot of experience in developing taxonomies, classifying information and developing synonym trees.  This experience, coupled with training in data management, concepts of search, and their enterprise perspective would make them an invaluable member of the Information Architecture team.

To realize this new service model will require changing the perceptions of the business and IT teams, AND changing the culture of the records management team.

Posted in Information Management, Managing Change, Strategic Planning, Uncategorized | Leave a comment

Information Architecture: The Semantics of Managing Information

It has been a while since my last post because I’ve been researching Information Architecture.  I knew that information architecture is, or should be, the lynch pin for application and network architecture.  However I’ve been running up against the bias that information architecture is solely a component of application design, primarily web design, and since everything was moving to the web anyways, why would an Enterprise Information Architecture be needed.   So I took a course in Information Architecture in December and came away with the following conclusions:

1. Information Architecture identifies the information that is meaningful to an organization. Information is valuable if it is relevant.  Defining the information that is relevant to the organization, project, etc. is essential to making an organization effective.  Defining the relationships between the information elements adds meaning, where none may have been before and creates the basis for knowledge management.

2. Key Word Search is not the complete answer. In speaking with application developers I often encounter skepticism about the value of developing an ontology to support search.  Search tools are powerful enough now to to find everything.. Granted, but I don’t want to find everything – just what is relevant.  It comes back to point 1.  Here is a list of reasons why developing an ontology to support search is important.

According to Kent Bimson: Ontologies help to find:

  • Synonyms
  • Specific names versus class names (Mary versus Person)
  • Pronoun references – (Her versus Mary)
  • Paraphrasing eg: Prime Minister versus Mr. Harper
  • Modal verbs – (could be, possibly, etc.)
  • Tenses – (was versus is)
  • Acronyms

3. Data Architects and Library trained resources should be key resources on any IM team. These two resources have very complimentary skill sets.  Library trained resources understand how to classify and create ontologies, primarily in the world of unstructured information.  Data architects also know how to classify and create relationships between data elements for structured information using data mapping techniques programmers can use to develop applications or solutions.  The combination of these two resources covers both the structured and unstructured arena of information to provide a complete view of an enterprise’s information.

4. Terminology Matters – Each area of expertise has their own specific language to describe information and information relationships.  Defining what these terms are and the semantic relationship between them will create a common language that makes it easier for teams to work together.  (As an aside, the terminology and definitions that Microsoft introduced with SharePoint has muddied the terminology waters between application developers and business analysts and records managers.)

5. Use graphics and representational languages to describe relationships between elements. As we move toward a more integrated model of information exchange and sharing, being able to represent the relationships from a conceptual to a programmable level is essential (see point 4).  Newer standards are being created, in particular OWL a web ontology language that is based on RDF XML AND DAML+OIL.

6. Standford University is doing a lot of work on semantics and ontologies. They have a tutorial on building ontologies and a free open source ontological application for building and maintaining ontologies called Protogé.  Here’s a list from Wikipedia of other Ontology tools.

7. Service Oriented Architecture appears to be the way to go.  Still working on learning more about this, but the general idea is that a call for information is routed through a service center that interprets the call, identifies all the relationships and their associated information stores, and then routes the call accordingly.  While this approach reduces duplications, supports more intuitive responses, and centralizes all the relationships, it also can increase the complexity of the solution architecture and can add a layer of administration to the solution and its governance.

Feel free to add comments and additional references.  It’s a big topic that requires input from all fields involved in managing information.

Posted in Information Architecture, Information Management | Tagged | 2 Comments

Information Architecture

The key to information management is classification.  Many organizations focus on the Information Design elements – a corporate taxonomy (a function or subject based classification system), security classification and stewardship.  While those elements are a good starting point, information classification needs to go much further to provide an organization with a robust, flexible and faceted framework that supports improved operational efficiencies and a dynamic foundation for business intelligence practices.  This framework is an Information Architecture.

According to the Institute Architecture Institute the definition for information architecture is:

in•for•ma•tion ar•chi•tec•ture n.
1. The combination of organization, labeling, and navigation schemes within an information
system.
2. The structural design of an information space to facilitate task completion and intuitive
access to content.
3. The art and science of structuring and classifying web sites and intranets to help
people find and manage information.
4. An emerging discipline and community of practice focused on bringing principles of
design and architecture to the digital landscape.

Information Architecture is often associated with web sites, as definition 3 points out, however Information Architecture, in my opinion, is something that can and should be applied at the enterprise level.  The elements of an information architecture may vary between organizations, however the key to an enterprise information architecture is a faceted approach.  A faceted approach refers to an architecture that supports non-hierarchical links between information descriptors.  These links enable the information to be retrieved through any of the descriptors, or through combinations of descriptors. From a users point of view, a faceted approach to classifying information supports the “exploratory”, “don’t know what you need to know” and “re-finding” approaches to search as explained in Four Modes of Seeking Information.  (Think Epicurious.com). From a web teams’ perspective the faceted elements often become the meta data fields for the site.

From an IM person’s perspective, a faceted approach supports a robust method for enterprise information retrieval and management.  For example, through a faceted approach, it is possible to identify information holdings based on security level, the media in which it is stored, the directorate responsible for the information, the activity or subject in which it has been classified, it’s retention period, it’s storage location, by its vital information status for business continuity purposes, by client, etc.  In an enterprise architecture these facets should support and reflect the objectives of the organization.

While information architectures are regularly created for data warehouses, often called master data plans, and for websites, there is a need for an enterprise information architecture to pull all these architectures together and ensure a consistency in terminology and structure that will be the foundation for enterprise federated search and a compliant and intelligent organization.

 

Posted in Uncategorized | Leave a comment

IM Governance

The definition I like most for the term “Governance” is from Wikipedia: “governance relates to consistent management, cohesive policies, processes and decision-rights for a given area of responsibility. For example, managing at a corporate level might involve evolving policies on privacy, on internal investment, and on the use of data.”  I may be slightly biased.

In the IM Model, governance is an encompassing activity.  Governance is required at the program level to legitimize the program and provide a foundation for measuring its impact, however it is also an essential component of every layer in the model.  In fact, once the program documents are produced – the policy instruments, the charter, IM strategy, roadmap, deployment plans  and awareness activities -the majority of work is at the initiative level.  And interestingly enough, the discussions on governance never get easier, regardless of the people around the table.  We always start with the basics and define everyone’s roles and responsibilities; while we struggle with ensuring everyone around the table has the same understanding and are using the same definition for the terms being used.  More often than not, we aren’t, so we end up developing those understandings as we develop the governance.

Being an impatient person I have often found this process frustrating.  I thought it was common sense, but I have come to realize that these discussions on terminology and creating a common understanding are an important step in raising IM awareness and bringing about a culture change.  This step can’t be skipped – it legitimizes IM activities and embeds IM principles into the organization.

Examples of IM governance requirements at the different model layers are:

1. Information Design – retention and disposition schedule approval process.  Changes to this schedule should be approved by the most senior person in the organization.  Ultimately that person is accountable for ensuring that the information in their organization is managed in a transparent and efficient manner, particularly in the face of audits or litigations.

2. Information Architecture – data governance.  Data governance is a framework to address “data quality, data management, data policies, business process management, and risk management surrounding the handling of data in an organization” (Wikipedia). The Data Governance Institute is more specific in their definition “Data Governance is the exercise of decision -making and authority for data-related matters.”  Through data governance, the integrity and trustworthiness of the data can be ensured.

3. IM Tools – Support Model. With any IT tool there are different support models available to choose from, such as ITIL. The common element in each are the predefined roles and responsibilities.  Using a model doesn’t negate the need for discussions between the various parties, but it does provide a scope and boundaries for the discussions that significantly reduces the time it takes to bring everyone up to a consistent understanding of the activities.

This entry completes my explanation of the the model I use.  In future posts I will go into more specific topics such as SharePoint 2010 and Records Management, faceted classification, when does information become a record, search, etc.  Let me know if you have any suggestions as I would love to create a discussion around these topics so that different perspectives can be presented.

Posted in Uncategorized | 2 Comments

Application Layer

Most end users equate information management with the tools they are using.  They create information through these tools, they save this information to a place on a network or hard drive and they can search for this information using tools.  They may never physically touch this information, except through tapping on a keyboard.

One of the biggest challenges for an IM person working with end-users is to get them to think outside the tool set, but often end users don’t have the language to describe what it is they are trying to do with their information.  And it’s not limited to ‘end users’.  Technical resources are bombarded with new tools to better manage networks, access, content management systems, reporting, systems development, etc.  Most technical resources don’t equate these types of applications with information management, and yet that’s what they are all about – organizing or providing the ability to re-use information to reduce errors and redundancy.

The following diagram from Mike 2.0, presents IM applications (tools) according to categories: Business Intelligence, Information Asset Management, Access, Search and Delivery, Enterprise Data Management, Enterprise Content Management.  Mike2.0 refers to these categories as solution offerings.

Mike 2.0 Core Solution Offerings

For most IM people, we tend to be pigeon-holed into the areas of Information Asset Management and Enterprise Content Management.  However what this diagram represents to me is the importance of ensuring that practitioners in the areas of Business Intelligence; Search, Access and Delivery; and Enterprise Data Management receive training in information management theory.  In the end, it is these resources that make better information practices tangible to end users.

Posted in Information Management | Leave a comment

Enterprise Architecture

Information management marries the classification of information with the information and communication technologies.  The Enterprise Architecture stage of the IM Model is the bridge between those two elements.

The definition for enterprise architecture provided by the Institute for Enterprise Architecture is: [a complete expression of the enterprise; a master plan which “acts as a collaboration force” between aspects of business planning such as goals, visions, strategies and governance principles; aspects of business operations such as business terms, organization structures, processes and data; aspects of automation such as information systems and databases; and the enabling technological infrastructure of the business such as computers, operating systems and networks.]

There are a number of enterprise architecture frameworks available.  Many will be familiar with the Zachman Framework, the Open Group Architecture Framework (TOGAF), Federal Enterprise Architecture (FEA) and the Meta Framework that was taken over by Gartner.  Each of these frameworks have pros and cons depending on your objectives.  For a good article that compares these frameworks click here.  Within the Canadian federal government, there is a working group developing an enterprise architecture framework.  The results of their work are available to government of Canada employees through GCPedia – the government of Canada wiki.

One aspect of the definition provided by the Institute for Enterprise Architecture that I find missing is the information architecture component.  Maybe data is supposed to cover all information formats, but in my world data tends to refer to information elements stored in a database, and information (the generic term) tends to refer to unstructured information such as text, audio and video.  (Segway: I sometimes think this subtlety is what is causing a mis-communication between classification specialists and application development specialists.)

An interesting open source information architecture framework that has been evolving for the last few years is MIKE2.0.  It started in 2007 through BearingPoint.  When I first started following it in 2008 it was very data focused, but over the last year it has really evolved to encompass all forms of information formats.  An article Hello My Name is Mike2.0 from the e-zine Information Management provides a good overview of the site and what it provides.  It has also been adopted by AIIM as the cornerstone of its enterprise2.0 certification program.

One thing I have learnt with developing and implementing an IM Program is that the biggest challenge is not the technologies, methodologies, standards, etc.  There are a lot of references available if you know where to look or are curious enough to search.  No, the biggest challenge is the cultural change that must occur in all areas of the organization for these frameworks to be understood and adopted – which is why my IM model is more high level and geared to a business audience.  I need to sell IM and its practices in a fashion that business owners can understand.  For my technical audience, Mike2.0 is a great communication tool.

For anyone on twitter interested in enterprise architecture, follow the hashtag #entarch – thanks to @webtechman for that reference.

Posted in Information Architecture, Information Management, Managing Change | Leave a comment

IM Model Components – Information Design

Information Design is an interesting term.  Can information be designed, is it something that should be designed? Or is it just the presentation of information that is designed?

In the case of the IM Model, information design relates to the elements used to categorize information to meet the basic requirements of record keeping, information security, and business continuity required by an organization to manage its resources. With these in place, an organization can meet its legal obligations, but it isn’t necessarily leveraging the strategic value inherent in information.  That is left to content management and business intelligence strategies.

Record Keeping has often been associated with managing only the information that is identified as a record.  However, as technology has evolved and the responsibilities of identifying records have devolved to the information creator there has been a shift towards the concept that all information an organization creates is a record and should be managed accordingly.  The Generally Accepted Recordkeeping Principles presented by ARMA and the definition of  Information Management supported by AIIM promote this shift.

So, while conceptually that’s great, the reality is that some information in an organization has more value than others.  How do you identify which information is worth more than other pieces of information?  Primarily through the retention and disposition schedule (RDS), however the level of sensitivity applied to it and whether it is essential information for business continuity purposes also labels the information as more valuable than others.

Another factor that is important as it relates to how the value of information is determined is the governance model associated with the retention and disposition schedule.  Through the schedule, the ‘owner’ of the information is identified.  The owner is responsible for signing off on either the destruction or archiving of the information before the action is taken.  The governance model to approve and manage changes to the RDS ensures the information valuable to the corporation is identified and managed accordingly.

These record keeping tools however, don’t address the challenges of identifying the ‘official’ record from supporting documentation or various drafts/versions of the record.  This challenge is addressed through business rules developed by the ‘owner’ of the record and the records manager, and electronic tools available to manage the information.

So after all that why call it Information Design?  Because the record keeping principles proposed by ARMA are the foundation designs on which all IM Programs are built.  By applying these classification structures to an organization’s information we are opening the door for more effective tools and practices that will deliver better value on an organizations’ most strategic asset – its information.

Posted in Information Management, Uncategorized | Leave a comment