ARTICLE IN PRESS

International Journal of Information Management 27 (2007) 159–172

www.elsevier.com/locate/ijinfomgt

The information audit: Role and scope

Steven Buchanan, Forbes Gibb
Graduate School of Informatics, University of Strathclyde, 26 Richmond Street, Glasgow G1 1XH, UK

Abstract

The information audit (IA) is central to the effective organisational management of information, however, there is
evidence from the field that the IA is neither fully accepted nor commonly practiced. This paper highlights and discusses
three challenges to current practice: limited guidance on management of scope; ambiguous linkage to related ICT
development processes; and the lack of a standard methodological approach. In response to these challenges, the role and
scope of the IA is re-examined, key relationships to information strategy and information system architecture (ISA) are
defined and mapped, and a two-dimensional matrix is proposed to manage scope.
r 2007 Elsevier Ltd. All rights reserved.

Keywords: Information audit; Information resource management; Information strategy; Information systems

1. Introduction

This is the first paper in a series of three providing a comprehensive review of the information audit (IA).
This paper re-examines role and scope, while later papers will review methodological approaches, and case
studies from the field.

1.1. Definition of purpose

Early IA definitions (Burk & Horton, 1988; Reynolds, 1980) focused on identification of formal information
sources with an emphasis on document management. However, more recent definitions have expanded upon
this relatively narrow focus, acknowledging the importance of organisational perspective and the broad
spectrum of information resources. In a previous paper by the authors (Buchanan & Gibb, 1998), the IA was
defined as a process for ‘‘discovering, monitoring and evaluating an organisation’s information resources in
order to implement, maintain, or improve the organisation’s management of information’’. A similar, more
recent definition is provided by the ASLIB Knowledge & Information Management Group,1 which describes
an IA as ‘‘A systematic examination of information use, resources and flows, with a verification by reference to
both people and existing documents, in order to establish the extent to which they are contributing to an
Corresponding author.
E-mail address: steven.buchanan@cis.strath.ac.uk (S. Buchanan).
1
http://www.kimnet.org.uk

0268-4012/$ - see front matter r 2007 Elsevier Ltd. All rights reserved.
doi:10.1016/j.ijinfomgt.2007.01.002
 ARTICLE IN PRESS
160 S. Buchanan, F. Gibb / International Journal of Information Management 27 (2007) 159–172

organisation’s objectives’’. Recent authors of IA methodologies, most notably Henczel (2001), Orna (2004),
and Wood (2004), also provide similar definitions.
Elaborating on the definition above Buchanan and Gibb proposed that in its simplest form, the objectives of
the IA could be limited to:

 identifying an organisation’s information resources,

 identifying an organisation’s information needs.

However, when applied to its full potential, the objectives of the IA could also include one or more of the
following:

 Identifying costs and benefits of information resources.

 Identifying opportunities to use information resources for strategic competitive advantage.
 Integrating IT investments with strategic business initiatives.
 Identifying information flows and processes.
 Developing an integrated information strategy and/or policy.
 Creating awareness of the importance of IRM and defining the management role.
 Monitoring and evaluating conformance with information-related standards, legislation, and policy
guidelines.

The IA was therefore positioned as central to the effective organisational management of information. The
ultimate goal of the IA, it was argued, was to provide integrated strategic direction for an organisation’s
management of its information resources and as such, it was believed that the IA should be considered as the
first step of information strategy development.
With such a central role, it is therefore reasonable to assume that the IA would be widely accepted among
organisations and be part of information management best practice, particularly given the phenomenal growth of
information-based services and online systems over the last decade, and the growing recognition of information as
a primary resource and tradable commodity. However, there is evidence from the field suggesting that the IA is
neither accepted nor commonly practiced, with DiMattia and Blumenstein (2000) reporting that, ‘‘there is no
consensus on whether there is a benefit to be gained through an (information) audit’’.

1.2. Challenges

One of the first challenges faced when considering an IA is that there is limited linkage to related ICT
development processes, which makes it extremely difficult to incorporate the IA into established operational
practice and to demonstrate value. As previously highlighted, the IA has both a key strategic and operational
role, but ironically, there is only limited explicit mapping from IA methods to established ICT development
processes, with which it shares common goals, particularly information strategy and information systems
architecture.
Historically (see Fig. 1), early IA approaches (1976–1988) focused upon relatively static identification of
formal information sources, but later methods (notably Orna, 1990) added organisational analysis and the

Fig. 1. Information audit approaches (Barker, 1990; Best, 1985; Gillman, 1985; Henderson, 1980; Quinn, 1979; Riley, 1976; Worlock,
1987).
 ARTICLE IN PRESS
S. Buchanan, F. Gibb / International Journal of Information Management 27 (2007) 159–172 161

mapping of information flow, aspects of the information system often overlooked by early ICT planning and
development processes, which were typically solution driven and based upon technical specifications and pre-
derived requirements. In this era (early 1990s), the IA could be positioned as providing vital organisational
context to information systems analysis, and a more holistic view of information resources. However, systems
development processes, particularly within the field of requirements engineering, have evolved rapidly over the
previous 15 years to now include extensive business process and information flow modelling tools and
techniques (BPML, UML, etc.), while the evolution of IA methods, tools and techniques has remained
relatively static, with modelling still largely based on now superseded data flow diagrams. As a consequence, it
is the authors’ opinion that the IA is often dismissed or overlooked by organisations in favour of more readily
understood, and embedded, systems development processes and practice. The potential problem with this
approach is that firstly, most systems development approaches still place greater emphasis on the technical
stages and components of development at the expense of organisational analysis and involvement (Juristo,
2002; Young, 2001); and secondly, information modelling and analysis is typically narrowly focused on the
solution/project domain, not the organisation as a whole. Under these circumstances, organisations can still
find themselves lacking clear top-down strategic direction, and will typically suffer from a piecemeal approach
to the management of information resources.
A second challenge is one of scope management. With the majority of popular IA methods (Buchanan &
Gibb, 1998; Henczel, 2001; Orna, 1990) advocating a top–down approach incorporating organisational
analysis, in-depth mapping and analysis of information systems/information flow, and extending to cost/value
analysis of individual information resources, the IA can quickly become a significant and costly undertaking.
Progress has been made towards a more standard and pragmatic approach by several authors; but there stills
exist concerns regarding the complexity and scale of the undertaking (Buchanan & Gibb, 1998), and there is
little practical guidance on the scope of the IA, and how to tailor it to individual circumstances and goals.
A third challenge is that there is no standard, agreed methodological approach. Instead, the practitioner is
faced with a variety of academic and proprietary methods, some comprehensive, some no more than
frameworks, which require the practitioner to labour through one or more management textbooks to arrive at
an appropriate choice of method, and to identify the numerous tools and technique(s) required to support the
methodological process. While it can be debated as to whether or not a standard is required, the lack of an
agreed methodological approach does make methodology selection a little haphazard, particularly given that
there also limited empirical evidence regarding the usability of existing methods. For example, in a recent
review of IA methods, Botha and Boon (2003) concluded, ‘‘y more research is needed on the topic of
information auditing and more methodologies need to be tested in practice. This would enable information
professionals to develop reliable information auditing methodologies that can be used with confidence’’.
This paper begins with challenges one and two, re-examining role and scope before addressing challenge
three in a later paper, which reviews methodological approaches.

2. Role and scope

To understand the role and scope of the IA , a holistic approach is required, acknowledging the spectrum of
information resources to be audited, and mapping from information strategy to information systems
architecture, in order to fully understand the related role of the IA.

2.1. Auditing the information spectrum

The unique characteristics of data, information, and knowledge, and the relationship between these three
elements (see Fig. 2), are central to the IA, as they help to identify the range of information systems and, more
importantly, to highlight key differences in structure, state, and application, which have implications for the

Fig. 2. The information spectrum.

 ARTICLE IN PRESS
162 S. Buchanan, F. Gibb / International Journal of Information Management 27 (2007) 159–172

identification, evaluation, and management of an organisation’s information resources, and for deciding what
is within and outside of scope.

2.1.1. Data
Data are facts concerning objects, events, or other entities. Data can be quantitative, being a measurement
of a particular property (such as age or quantity), and can be objective, the value being unaffected by personal
interpretation. In temporal terms, data can be historical, and when used to forecast, predictive. Data can also
be non-quantitative, indicating a property that classifies an object into a category (such as a profession or
address), and can be subjective, acquired through personal assessment and subject to variability. It is
important to emphasise that raw data has no intrinsic value until it can be exploited by turning it into
information. Databases, which store and manage data, are the foundation of all information systems. They
support transaction processing, querying, publishing, and the acquisition of business intelligence about
customers, markets, products, and services.
From an information management perspective, key data concerns are typically associated with data
protection/storage, and records management and regulatory compliance. Data are often implicitly identified
by an IA as part of information mapping (typically captured as sources of information). However, more
explicit data questions to be answered by an IA would include:

 What are the sources of data?

 How are these data retrieved and analysed?
 What is done with these data?
 What legal and regulatory requirements are applicable?

2.1.2. Information
Information is generated through the structured processing and refinement of data and, importantly,
through the application of context and meaning. In everyday use, information guides and informs individual
and organisational decision-making processes but, when effectively managed and processed, information
facilitates the generation of intellectual capital, which underpins innovation and growth. Information is
therefore a valuable, and tradable, organisational asset, which significantly can be reused, shared, and
distributed with limited loss of value. Companies are now regularly bought and sold on the basis of their
intellectual assets.
From an information management perspective, the focus is typically on operational reporting and decision
support. Analytical, database driven management information systems can improve the quality of information
that is available for decision making by providing powerful tools for analysis and exploration. Identifying
information as part of an IA involves mapping organisational information flow, and identifying information
systems and resources. The key questions that need to be answered are:

 What information is required to support tasks/processes?

 What information systems are used?
 How is this information obtained?
 How is this information used?
 How important is this information to the task/process?
 What is done with this information?

2.1.3. Knowledge
Knowledge is the final high-value stage of the information spectrum, with knowledge regarded as a primary
source of wealth (i.e. intellectual capital) and a key differentiator. However, the responsibilities for the
effective exploitation of knowledge are often unclear in organisations, despite the fad for knowledge
management and Chief Knowledge Officers in the 1990s. Stewart (1997) argued that enterprises have three key
forms of intellectual capital: human capital, which is rented and exists in the expertise and creativity of
 ARTICLE IN PRESS
S. Buchanan, F. Gibb / International Journal of Information Management 27 (2007) 159–172 163

employees; customer capital, which is shared and exists as brand image, reputation, understanding of
customer behaviour, etc.; and structural capital, which is owned and takes the form of processes, systems,
information and intellectual property. The development of human capital is typically the province of Human
Resources departments, while the creation of customer capital is that of Marketing and Sales. Structural
capital, on the other hand, is predominantly the responsibility of the Chief Information Officer who must
provide the technologies and systems:

 to facilitate the sharing of data and information which can help employees generate knowledge,
 to capture tacit knowledge which can then be retained and exploited by the organisation,
 to link employees to create communities of expertise and improve decision making,
 to analyse data and information to discover knowledge about products, customers and markets.

From an information management perspective, the key concerns at this point in the information spectrum
are therefore associated with harnessing and utilising organisational knowledge and expertise. Identifying the
knowledge base as part of an IA involves identifying, mapping, and facilitating access to the tacit and explicit
knowledge assets which the organisation has at its disposal (tacit assets will also have to be assessed as to
whether they ought to be (or can be) converted into explicit assets through codification). The key questions
that need to be answered as part of an IA are:

 Who are the experts, networks, and communities that hold or can provide knowledge of use to the
enterprise?
 What documented experience or experimental results do we have that can be shared to improve
performance.
 What intellectual property do we have?
 Where can we store, and from where will we subsequently retrieve, the relevant knowledge?
 Why is this knowledge important in the first place?

The information spectrum demonstrates that, for an IA to be effective, it must incorporate both hard and
soft systems theory. Data and information, to various degrees, can be represented from a hard systems
perspective, but knowledge requires both hard and soft system approaches (Checkland, 1999). Further,
information systems are designed and built in response to the needs of the organisation and its environment.
They take into account complex social, economic, organisational, and ergonomic requirements and
relationships, as well as having to be technically and logically sound.

2.2. Facilitating information strategy

Information strategy provides overarching tactical and operational guidance for the effective management
of an organisation’s information resources. The IA provides an inventory of these resources and, more
importantly, key organisational analysis. This positions the IA as an essential precursor to information
strategy development (Buchanan & Gibb, 1998).
Earl (2000) identifies four key information strategy components: information technology, information
systems, information management, and information resource.
However, Gibb, Buchanan, and Shah (2006) argue that Earl’s use of the term ‘information resource
strategy’ is perhaps unfortunate in that there has been a long-standing use of the term information resource to
refer to all of the resources used to exploit information: information personnel, technology, systems, and
content. They propose that a more appropriate term would be content strategy with the associated activity of
content management (see Fig. 3). Nevertheless, Earl’s model is important in making the distinction between the
technologies which provide infrastructure support, the systems which support or instantiate business
processes, the information which businesses generate or consume, and the over-arching management of all of
these resources.
Earl’s (2000) taxonomy provides a logical breakdown of information strategy components, which can be
adopted to guide and manage IA scope. This should allow an IA to focus on one or more components,
 ARTICLE IN PRESS
164 S. Buchanan, F. Gibb / International Journal of Information Management 27 (2007) 159–172

Fig. 3. Information strategy taxonomy (adapted from Earl, 2000).

dependent upon individual circumstances and IA purpose. Formal adoption should also make explicit the
existing implicit relationship between the IA and information strategy, that is: if a key output or next step is
information strategy, then IA methodological structure and scope should align with the de facto information
strategy taxonomy.

2.3. Contributing to information system architecture (ISA)

The definition of ISA as provided by IEEE2 standard 1471–2000 is, ‘‘the fundamental organisation of a
system, embodied in its components, their relationships to each other and the environment, and the principles
governing its design and evolution’’.
ISA is guided by information strategy, and precedes more technically detailed information system
development; it is concerned with the holistic design from both a strategic and operational perspective). The
Open Group3 identifies four subset components to ISA, which have parallels with Earl’s information strategy
taxonomy:

 Business process: core business processes within the strategic, governance, and organisational framework.
 Application: individual applications, their interactions, and relationship to business processes.
 Data: logical and physical data assets and management resources.
 Technology: the software infrastructure supporting applications.

The authors believe that an IA should be capable of directly contributing to ISA development, as there is
natural synergy between their respective inputs/outputs. To illustrate this relationship, two popular
approaches to architecture development are discussed below: the Zachmann Architectural Framework, and
The Open Group Architectural Framework (TOGAF).

2.3.1. The Zachman Architectural Framework

The Zachman framework (Zachman, 1987) was proposed as an approach to information systems
architecture, which tackled the acknowledged, but then only partially addressed requirement for multiple
stakeholder views of an ISA. Zachman drew on proven architectural principles and processes from the
construction, manufacturing, and avionics industries, to develop a framework suitable for information
systems architecture. The framework provides a comprehensive and modular classification of viewpoints and
models, representing and relating all stakeholder perspectives, and allowing architects to focus on selected
aspects of the system without losing sight of the bigger picture. In the years since its publication, it has become
the de facto standard for many within the system architecture practitioner community.
The framework is a matrix of six columns and six rows providing 36 cells representing the views of an ISA
(see Table 1). The initial framework was made up of the first three columns (Zachman, 1987), but this was
later expanded (Sowa & Zachman, 1992) to the six as illustrated. The columns represent the abstractions (or
descriptions), which are possible, and which, when isolated, contain the complexity of the design problem.
2
http://www.ieee.com
3
http://www.opengroup.org
 ARTICLE IN PRESS
S. Buchanan, F. Gibb / International Journal of Information Management 27 (2007) 159–172 165

Table 1
The Zachaman framework (Zachman, 1992; http://www.zifa.com)

Data Function Network People Time Motivation

what how where who when why

Scope List of things List of processes List of locations List of List of events/ Lists of business
important to the the business in which the organisations cycles significant goals and
business performs business important to the to the business strategies
operates business
Business model Semantic model Business process Business Work flow Master schedule Business plan
model logistics system model
System model Logical data Application Distributed Human Processing Business rules
model architecture system interface structure model
architecture architecture
Technology Physical data System design Technology Presentation Control Rule design
model model architecture architecture structure
Detailed Data definitions Program Network Security Timing Rule
representation architecture architecture definition specification
Functioning Data Function Network Organisation Schedule Strategy
enterprise

The columns of the framework also represent a set of questions, which lead to the different perspectives.
These questions (with similarities to those asked during the IA) are:

 What is the system made of?

 How does the system work?
 Where are the system components and connections?
 Who does the work?
 When do things happen?
 Why are various choices made?

The rows represent the perspectives which are:

 Scope: represents the contextual view of the planner or investor who wants an estimate of the scope of the
system, what it would cost, and how it would perform.
 Business model: represents the conceptual view of the owner who wants to understand the business process
model, and the relationship between entities and processes.
 System model: represents the logical view of the designer who must determine the data elements and
functions that represent business entities and processes.
 Technology model: represents the physical view of the builder who must adapt the information system
model to the details of the programming languages, I/O devices, etc., and consider the constraints of tools,
technology, and resources.
 Detailed representation: represents the out-of-context view of the subcontractor who typically works from
detailed specifications, often at the module level.
 Functioning enterprise: represents the operational system view.

Zachman is a logical framework, which does not prescribe or describe any particular method,
representation technique, or automated tool. The Open Group (2006) state that the main strength of the
framework is that, ‘‘it provides a way of thinking about an enterprise in an organised way, so that it can be
described and analysed’’.

2.3.2. TOGAF
The TOGAF is an enterprise architecture development method, which can be applied at the enterprise,
multi-system, or single-system level of an organisation. The original version released in 1995 was based on the
 ARTICLE IN PRESS
166 S. Buchanan, F. Gibb / International Journal of Information Management 27 (2007) 159–172

Fig. 4. TOGAF application development method (TOGAF, 2006).

Technical Architecture Framework for Information Management (TAFIM), developed over several years by
the US Department of Defense. Since 1995, TOGAF has evolved year-on-year through extensive industry
consultation and user-group feedback and involvement; the following discussion references TOGAF Version
8.1.1. (TOGAF, 2006).
TOGAF consists of three main parts:

1. Architectural development method (ADM): The ADM is at the core of the TOGAF model, providing a
systematic step-by-step approach to enterprise architecture development (see Fig. 4). The model begins
with preliminary setup tasks associated with scope, definition, and management processes. The next
phase continues scoping and establishing the remit of the architectural exercise, but with the emphasis
now on vision, strategic alignment, and organisational recognition and endorsement. The following three
phases focus on systematic architectural modelling (baseline and target) of the business domain,
information systems (data and applications), and technology platform(s). The final four phases are
concerned with migration planning, change management, implementation and governance (viewed as
parallel rather than sequential processes). ADM is regarded as a continuous, cyclical, and iterative process;
with the first iteration regarded as the hardest, primarily due to having just set out on the enterprise
continuum.
2. Enterprise continuum: a virtual repository of architectural artefacts and assets, which exists to enable
architectural development. This continuum is expressed by TOGAF as a combination of two comple-
mentary architectural concepts:
J Architectural continuum: provides a way to define and understand generic architectural rules,
representations, and relationships among foundation frameworks (baseline generic service platforms);
and to discover commonality and eliminate unnecessary redundancy. Presented as an evolu-
tionary process, which begins with the TOGAF foundation architecture through common system
architectures, and industry specific architectures, to an organisation’s own individual architecture.
The continuum represents a progression from logical to physical, and from general to specific,
with the design process based upon adoption/leverage of reusable architectural components and building
blocks.
J Solutions continuum: the solution continuum (products and services, system solutions, industry
solutions, organisation solutions) represents the implementation of the architecture at the corresponding
levels of the architecture continuum. At each level, the solutions continuum is a population of the
architecture with reference to building blocks, either purchased products or built components, that
represent a solution to the enterprise’s business need expressed at the respective level.
3. Resource base: The TOGAF resource base specifies the resources required to support ISA, and provides a
selection of guidelines, templates, and background information to support the use of the TOGAF ADM.
 ARTICLE IN PRESS
S. Buchanan, F. Gibb / International Journal of Information Management 27 (2007) 159–172 167

The resource base is also a repository of case studies, and includes guidelines for evaluating architectural
tools.
In contrast to Zachman, the TOGAF framework provides a step-by-step method for ISA planning,
development, and change management. While Zachman is simple and non-prescriptive, TOGAF is detailed
and prescriptive. However, rather than viewing the frameworks as either/or approaches, they should be
considered as highly compatible components of an overall tailored approach to ISA development. Viewed in
combination, TOGAF provides the methodological step-by-step development process, while Zachman guides
representation, analysis and design.

2.4. Information strategy, ISA, and the IA

In an ideal best practice scenario, the ISA would be driven and guided by information strategy, with both
facilitated by the output of the IA. The Zachman framework identifies the architectural entities essential to a
‘‘system view’’, while TOGAF extends Earl’s taxonomy, bridging the gap between information strategy and
ISA development. These key relationships are illustrated in Fig. 5.
To achieve convergence and integration with the IA, alignment should be sought between the outputs of the
IA and the respective inputs to both information strategy and ISA development. While the link between the IA
and information strategy has been formally acknowledged and incorporated into audit methodologies (most
notably Buchanan & Gibb, 1998; Orna, 1990), the link from audit to system architecture has not. To bridge
this gap and further extend, the value of the IA would require the IA to integrate with the model illustrated in
Fig. 5. At a high level, this could be accomplished by adopting Earl’s taxonomy noted earlier. At the more
detailed level, synchronicity between inputs/outputs is required. For example (illustrative only as dependent
upon individual IA methodologies), the output of an IA could map (approximately) to the top two rows of the
Zachman framework: scope and business model, and contribute to the application architecture component of
the system model (see Table 2). The remaining cells of the Zachman framework are more closely associated
with systems development and not immediately within the scope of an IA; however, there may be some further
synergy on a case-by-case basis, particularly across the system model row.
Absolute matching of inputs/outputs could be sought through detailed specification of IA tasks and
standardised output, but it is the authors’ belief that the above general mapping would suffice in most IA
instances, with the benefit of not overly extending or complicating the IA process. The immediate value of
Table 2 is in illustrating the relationship between the outputs of the IA, and the inputs to the ISA development
process. While it is the authors’ belief that absolute matching of input/output is not necessary, the
establishment of an information audit taxonomy to facilitate this process is deemed both necessary and of high
immediate value.

Fig. 5. Information strategy and information system architecture.

 ARTICLE IN PRESS
168 S. Buchanan, F. Gibb / International Journal of Information Management 27 (2007) 159–172

Table 2
From information audit to system architecture development: shared input/output

Data Function Network People Time Motivation

what how where who when why

Scope List of things List of processes List of locations List of List of events/ Lists of business
important to the the business in which the organisations cycles significant goals and
business performs business important to the to the business strategies
operates business
Business model Semantic model Business process Business Work flow Master schedule Business plan
model logistics system model
System model Logical data Application Distributed Human Processing Business rules
model architecture system interface structure model
architecture architecture
Technology Physical data System design Technology Presentation Control Rule design
model model architecture architecture structure
Detailed Data definitions Program Network Security Timing Rule
representation architecture architecture definition specification
Functioning Data Function Network Organisation Schedule Strategy
enterprise

3. An information audit taxonomy

As previously noted, Earl’s taxonomy (adopting the revised model proposed by Gibb et al. (2006)) provides
a logical breakdown of information strategy components, which can be used to manage and direct IA scope.
Adopting this taxonomy would allow an IA to focus on one or more components, dependent upon individual
organisational circumstances and the remit of the IA. However, a potential limitation to this approach is that
it might inadvertently lead to a one-dimensional view of the organisation. To add a second dimension to this
proposed taxonomy, the concept of ‘‘perspectives’’ is introduced, which acknowledges that an auditor might
not only wish to focus on one or more components, but may also wish to adopt a particular view of the
organisation. These perspectives are proposed as strategic, process, and resource.

3.1. The strategic perspective

The strategic perspective would focus upon the realisation of strategic objectives through mapping and
analysis of the relationship from organisational mission to information resources. Buchanan (1996) proposed
a simple hierarchy to define and map this relationship (see Fig. 6), which has also been incorporated into
Henczel’s (2001) IA methodology.
The model identifies the following key elements (Buchanan, 1998):

 Mission: the high-level operational direction and core values.

 Goals: the end state that the enterprise wishes to achieve over the medium to long term in accordance with
the mission statement.
 Objectives: the specific, quantifiable and attainable short-term targets, which measure the degree to which
the enterprise is realising its goals.
 Critical success factors (CSFs): the factors essential to the achievement of objectives.
 Task/activity: the specific steps that will be taken to ensure CSFs are met, and objectives realised.
 Information resources: the information resources required to support the achievement of tasks/activity.

In the strategic perspective, information resources are identified, but not inventoried. Priority and resulting
depth of analysis would focus on those resources identified to be of greatest strategic importance (Buchanan
(1998) proposed assigning values to resources on a scale of 1–5 according to degree of importance to the
related task (see Table 3)). Any inventory information gathered would be viewed as a by-product of the
 ARTICLE IN PRESS
S. Buchanan, F. Gibb / International Journal of Information Management 27 (2007) 159–172 169

Fig. 6. The strategic IA view (Buchanan, 1996).

strategic investigation, which could, of course, be built upon in a later IA. Typical questions to be answered by
a strategic oriented IA would include:

 What is our mission?

 How can we achieve this?
 What is essential to our success?
 What information resources do we use/require?
 Are there any gaps or constraints?
 Were can we use information resources to our competitive advantage?

The key output of a strategically oriented IA would be an organisational information strategy.

Recommendations would focus upon future strategic direction and the enabling role of information resources.

3.2. The process perspective

The process perspective focuses upon work flow and associated information flow through modelling of
organisational processes. In simple terms, a process is a set, or sequence of activities that results in the
accomplishment of a task, or the achievement of an outcome. Processes are one element of a system, and
inherit several system characteristics. They begin with an input, and end with an output (see Fig. 7); they
contain sub-processes; have one or more customers, and typically, several stakeholders. They can be divided
into four main types (Ould, 1995):

 Core processes: for servicing external customers through fulfilling orders, manufacturing, insurance policy
processing, etc.
 Support processes: for servicing internal customers and providing administrative back-up for core processes,
e,g. managing finances, purchasing, data processing.
 Management processes: for planning, organising, and overseeing the enterprise.
 Business network processes: for linking partners and systems in the supply/demand chain.
 ARTICLE IN PRESS
170 S. Buchanan, F. Gibb / International Journal of Information Management 27 (2007) 159–172

Fig. 7. The process model.

While a functional structure is necessary to define reporting lines and to organise physical assets, an
overemphasis on functions can create barriers to effective information flow and encourage managers to adopt
protectionist stances, thereby constraining the value that can be generated by the enterprise. A process view
transcends this functional view as it forces the enterprise to look at how information flows and how functions
must co-operate in order to achieve customer satisfaction (Gibb et al., 2006).
Typical questions to be answered by a process oriented IA would include:

 What do we do?
 How do we do it?
 How can we prove we do what we say?
 What information resources do we use and require?
 What systems do we use?
 What information related problems do we experience?
 What could we do to improve what we do?

The key output of a process oriented IA would be process-based mapping and analysis of information flow
and related information resources. Recommendations would focus upon improving existing work flow
through better information provision, support, and management. Process models produced by this activity
can also directly contribute to process and service management initiatives (Gibb et al., 2006), further extending
the value of the IA.

3.3. The resource perspective

The resource view focuses on identification, classification, and evaluation of information resources. In
contrast to the strategic and process perspectives, which primarily identify those resources associated with a
strategic goal or in-scope operational process, the resource perspective sets out to comprehensively identify
and inventory all information resources. Data would be collected on each resource (owner, task supported,
source, medium/channel, cost, etc.) and values would be assigned to each resource according to importance to
the task supported (see Table 3). This then allows the auditor to differentiate between those resources of
strategic importance, those fulfilling an important support role, and those either not used, or of little value to
the organisation.
Typical questions to be answered by a resource oriented IA include:

 What are our information resources?

 How do we use them?
 How do we manage and maintain them?
 Are we conforming to applicable regulatory requirements?
 Which are our key information resources?
 Which are of no value to us?
 Are there opportunities to better manage our information resources?
 What problems do we have with information resources?

The key output of a resource oriented IA would be a detailed inventory and evaluation of an organisations
information resources. Recommendations would focus upon more efficient and effective information resource
management. Continuing the theme of extending IA value through synergy with related activity, the output of
 ARTICLE IN PRESS
S. Buchanan, F. Gibb / International Journal of Information Management 27 (2007) 159–172 171

Table 3
The value of information resources (Buchanan, 1996)

Value Description

5 Critical to the task

4 Provides significant benefits or adds value to the task
3 Contributes directly to the task but not essential
2 Provides indirect or minor support to the task
1 Not used or has no perceived benefits for the task

Fig. 8. IA scope matrix.

a resource oriented IA would provide much of the initial input required for a content audit. The purpose of the
content audit is to identify how organisational content can be unified and reused in pursuit of enterprise and/
or web content management (Rockley, 2002; Marsh, 2005). A resource oriented IA identifies this content (via
the inventory), explores use, and importantly, assigns associated values. A content audit would then further
analyse and model this content as the basis for the development of an enterprise content management system.

4. Conclusions

Earl’s information strategy taxonomy provides a logical breakdown of components, which should be within
the scope of an IA. TOGAF extends Earl’s taxonomy, bridging the gap between information strategy and
ISA. The Zachman framework provides integration from IA output to ISA input, and identifies and defines
several of the organisational and architectural entities essential to a system view. The taxonomy provides the
auditor with the flexibility to focus on one or more individual components dependent upon individual
circumstances and requirements. Organisational perspectives provide a second dimension to this taxonomy,
allowing the information audit to be scoped not just according to taxonomy component but also by one or
more desired organisational views. It is proposed that the natural order would be to identify firstly the
appropriate perspective(s), and then the components that are within scope. The resulting two-dimensional
scope matrix is illustrated in Fig. 8.
Finally, in consideration of this re-examination of IA role and scope, a refined definition is proposed: the
purpose of the IA is to provide a holistic approach to identifying and evaluating an organisation’s information
resources and information flow, in order to facilitate effective and efficient organisational information
systems. The IA provides both strategic and operational direction, and contributes directly to ISA
development. This more clearly positions the IA to related practices, and in so doing, also extends the value of
the IA. The next paper in this series reviews the capability of existing IA methodologies to meet this role.

References

Barker, R. L. (1990). Information audits: Designing a methodology with reference to the R & D division of a pharmaceutical company.
Occasional publications series no. 8 (pp. 5–34). Sheffield: Department of Information Studies, University of Sheffield.
Best, D. (1985). Information mapping: A technique to assist the introduction of information technology in organizations. In B. Cronin
(Ed.), Information management: From strategies to action (pp. 75–94).
 ARTICLE IN PRESS
172 S. Buchanan, F. Gibb / International Journal of Information Management 27 (2007) 159–172

Botha, H., & Boon, J. A. (2003). The information audit: Principles and guidelines. Library Review, 53(1), 23–38.
Buchanan, S. (1996). The information audit: An integrated strategic approach. Unpublished report, University of Strathclyde Information
Strategy Office.
Buchanan, S., & Gibb, F. (1998). The information audit: An integrated strategic approach. The International Journal of Information
Management, 18(1), 29–47.
Burk, C. F., & Horton, F. W. (1988). InfoMap: A complete guide to discovering corporate information resources. Englewood Cliffs, NJ:
Prentice-Hall.
Checkland, P. (1999). Systems thinking, systems practice. Chichester: Wiley.
DiMattia, S. S., & Blumenstein, L. (2000). In search of the information audit: Essential tool or cumbersome process? Library Journal, 1,
48–50.
Earl, M. J. (2000). In D. A. Marchand, T. H. Davenport, & T. Dickson (Eds.), Mastering information management (pp. 16–22).
Gibb, F., Buchanan, S., & Shah, S. (2006). An integrated approach to process and service management. International Journal of
Information Management(26), 44–58.
Gillman, P. L. (1985). An analytical approach to information management. The Electronic Library, 3(1), 56–60.
Henczel, S. (2001). The information audit: A practical guide. London: K.G. Saur.
Henderson, H. L. (1980). Cost effective information provision and the role for the information audit. Information Management, 1(4), 7–9.
Juristo, N., et al. (2002). Is the European industry moving toward solving requirements engineering problems? IEEE Software, 19(6),
70–76.
Marsh, H. (2005). How to do a content audit. Available at: http://www.contentcompany.biz/articles/content_audit.html?
Open Group (2006). TOGAF 8.1.1. Online. Available at: /http://www.opengroup.org/architecture/togaf8-doc/arch/S.
Orna, E. (1990). Practical information policies: How to manage information flow in organisations. Aldershot: Gower.
Orna, E. (2004). Information strategy in practice. Aldershot: Gower.
Ould, M. A. (1995). Business processes: Modelling and analysis for re-engineering and improvement. Chichester: Wiley.
Quinn, A. V. (1979). The information audit: A new tool for the information manager. Information Manager, 1(4), 18–19.
Reynolds, P. D. (1980). Management information audit. Accountants Magazine, 84(884), 66–69.
Riley, R. H. (1976). The information audit. Bulletin of the American Society for Information Science, 2(5), 24–25.
Rockley, A. (2002). The Gilbane Report: Performing a content audit. Available at: http://gilbane.com/gilbane_report.pl/89/
Performing_a_Content_Audit.html.
Sowa, J. F., & Zachman, J. A. (1992). Extending and formalising the framework for information systems architecture. IBM Systems
Journal, 31(3), 590–616.
Stewart, T. A. (1997). Intellectual capital: The new wealth of organizations. New York: Doubleday.
Wood, S. (2004). Information auditing: A guide for managers. Available at: /http://www.freepint.com/shop/report/infoaudit/S.
Worlock, D. R. (1987). Implementing the information audit. Aslib Proceedings, 39, 255–260.
Young, R. R. (2001). Effective requirements practices. Addison-Wesley: Boston.
Zachman, J. A. (1987). A framework for information systems architecture. IBM Systems Journal, 26(3), 276–292.

Steven Buchanan is an Information Systems Lecturer in the Graduate School of Informatics, University of Strathclyde. He has carried out
extensive consultancy work and research in the areas of information strategy, enterprise architecture, information systems, and
information audits. He has worked across Europe and throughout Australasia for a number of public and private sector organisations,
spanning telecommunications, finance, education, government, and microelectronics.

Forbes Gibb is a Professor of Information Science in the Graduate School of Informatics, University of Strathclyde. He has been involved
in several major EU funded research projects (SIMPR, STAMP, AUTOSOFT, MIND) and teaches in the areas of information strategy,
service management, and content management.