Digital longevity has emerged as a key challenge for information systems in many domains. In this article we explore the hypothesis that longevity is a non-functional quality attribute of information and software artifacts, driven by organizational capabilities and sociotechnical change processes. While software evolution and maintenance have produced a rich body of knowledge on keeping software systems alive after creation, little emphasis has been placed on the underlying factors contributing to the longevity of information systems up-front. We attempt to dene, motivate and outline the facets of longevity and pose a series of research questions that lead to a research roadmap and open up an interdisciplinary research path on Information Systems Longevity Engineering.
longevity. 1a: long duration of individual life. b: length of life. 2: long continuance : permanence, durability 3
This article argues that a new perspective on the concerns of longevity in information systems design can improve the discipline’s success in ensuring controlled achievement of longevity in our ultimate core product: information systems. We outline such a perspective and outline an initial research agenda by posing a series of focused research questions. Essentially, longevity can be seen as a non-functional quality attribute of an artifact that describes the degree to which the artifact continues to full its purpose for a certain timespan or as long as a dened set of conditions holds. We need to distinguish between the 3 http://www.merriam-webster.com/dictionary/longevity longevity of information artifacts, the longevity of the system and software components, and the longevity of the information systems managing these artifacts, while acknowledging these are intricately linked.
Users have understood the business side of the problem, being faced with data
loss, software cost overruns, lack of business continuity, and violations of
compliance regulations requiring access to data and traceability of business processes.
However, in IS design and engineering, there is a focus on ex-post preservation,
i.e. maintenance and evolution. This contributes to cost overruns over the
system lifecycles and ever-increasing concerns about ‘aging software systems’ [
While both the preservation of information and the governance, maintenance and evolution of software and information systems as disciplines are each making advancements, it is crucial to be aware that these are but two sides of one coin: digital data is meaningless without interpretative systems, and systems become pointless without the data they are expected to process.
At the same time, the longevity of the information processed within software systems poses similarly complex challenges. These challenges have evolved into an active area of research most commonly called digital preservation. In this article, we attempt to bring these two perspectives together and outline a research agenda for improving our ability to control the longevity of information systems.
This document is structured as follows. Section 2 discusses digital longevity from the perspective of keeping digital content alive and discusses how notions of longevity are increasingly becoming urgent matters of attention for information systems and software systems themselves, and argues why a more holistic perspective is needed. Section 3 introduces a conceptual perspective for addressing longevity, and poses a number of focused research questions to be tackled. Section 4 summarizes the discussion and outlines next steps. 2
To understand the facets of longevity as it applies to information systems, it is
useful to introduce a discipline entirely focused on digital longevity: The eld
of Digital Preservation (DP) is concerned with keeping digital information
authentic, understandable, and usable, through time and across changing
sociotechnological environments [
DP is often seen as a case of interoperability through time. Consider a
Shannon communication channel [
From its origin in the areas of cultural heritage and eScience, DP has emerged
as a key challenge for information systems in almost any domain from
eCommerce and eGovernment to manufacturing, nance, health, and private lifestyle
[
We dene information longevity as the objective that is met if information artifacts remain fullling their intended purpose across time for as long as needed. On the other hand, systems longevity for an information system can be dened as the objective that is met if it is possible to manage the system over time so that it remains fullling its intended purpose for as long as needed.
For information systems longevity , that means that 1. the information managed by the system needs to fulll the objective of longevity, 2. it needs to be possible to sustain the information system, across an unstable organizational and technological context, for as long as a dened set of conditions holds, and, 3. it can be shown that one eectively can, for that system, move the information base and the dened valid states changes (the systems’ behavioural schema, or business rules) to another instance of another information system.
What arises from this view is that information longevity as an organisational
capability relates to the ability to govern information independently of and across
systems. Existing approaches to IT Governance, in comparison, are considering
information primarily as how it is managed within a system.
The concerns of systems longevity have in dierent expressions and with
narrower focus already stirred interest in the software engineering (SE) and IS
communities. However, longevity concerns are generally considered late in the
software lifecycle and on isolated levels such as technical portability across
platforms, modiability of source code, interoperability of components, or resilience
against disruptions [
To counter software aging, software evolution and maintenance refers to the
‘modication of a software product after delivery to correct faults, to improve
performance or other attributes, or to adapt the product to a modied
environment.’ [
Figure 2 shows the two key dimensions of the challenge: Information Longevity, until now, is still treated largely as a problem isolated from Systems Longevity and treated as an ex-post phenomenon. Similarly, information systems longevity is generally considered after the fact. While longevity is a key concern in systems engineering, and a set of problem areas are well-acknowledged and increasingly sophisticated in contributing to the ability of information systems to achieve longevity, succesfully establishing Information Systems Longevity Engineering requires an interdisciplinary eort, shifting from ex-post treatment to a-priori design. The potential benets are increased sustainability, improved cost eectiveness, and better control for system users over their information, irrespective of customer-supplier relationships and contextual change. In particular in times of cloud computing, these challenges are emerging as crucial requirements for information systems design. How can we accomodate these concerns systematically? 3
Goals and Challenges. Certain non-functional quality attributes of systems,
such as maintainability and portability, aim at extending the system lifetime
on the technological development level. The standard ISO SQUARE [
Longevity as a design concern, on the other hand, must be considered from the conception phase on, on all levels from the system context to the source code. It has implications for all levels in all successive phases, including retirement. Longevity is not meant to replace existing concerns, but connect them. Correspondingly, an engineering process that integrates longevity will need to bridge existing processes and concerns on all abstraction levels throughout the entire system lifecycle. In fact, longevity can be seen as a crucial enabler for business/IT alignment. Software, as an intermediate logical layer that connects the organization to the physical technological infrastructure and supports necessary and innovative business capabilities, should have the capability to keep up with the organization’s goals in the short- and long-term. Not accommodating the concern in software systems engineering causes severe business disruptions since systems do not keep pace with technological evolution and with abrupt changes in the business environment.
Research Strategies. To achieve the specication of such a process, we
need a solid conceptual model of the relationship between design concerns,
nonfunctional requirements and quality attributes of systems, engineering processes,
artifacts, and process metrics. We thus propose to create a systematic link
between longevity processes, capabilities, and systems quality attributes. We
believe that it is possible to systematically analyze primary enablers and inhibitors
on particular software engineering processes that contribute to longevity of
capabilities, software systems and components. The required perspective is provided
by Enterprise Architecture [
A primary goal for enterprise architecture is to maintain the alignment
between business and IT in organisations [
Based on a systematic analysis of (1) the high-level perspective of Enterprise Architecture, (2) the specic systems engineering methods and processes, process areas, artifacts and metrics for the purpose of engineering capabilities, and (3) empirical software engineering data, we plan to build a conceptual process framework for addressing longevity as a fundamental concern from the conception phase of an Information System’s lifecycle. In the following, we outline some of the initial key research questions that we believe can lead the way. The proposed research not only aims at developing systems with the longevity concern accounted for, but it also aims at assessing and improving existing systems with respect to their longevity qualities.
Research Questions. If our goal is to improve the achievement of controlled levels of longevity, where do we have to start? The following section outlines a number of research questions, starting at the ultimate goal to improve the achievement of controlled levels of longevity.
Dene, estimate, and measure. How can we dene and measure the needs, values and costs of longevity? How can we estimate the desired life spans of software systems and their components? How can we position the factors causing obsolescence and those contributing to maintainability with respect to the desired longevity of the system and its components?
Costs, benets, and risks. What are the cost-benet-risk relations of longevity? What is the value added of increasing the expected longevity of a given artifact by a certain time span? What are the marginal costs of increasing the expected longevity of a given artifact by a certain time span? How early in the development lifecycle can we provide serious estimates?
Longevity as a design concern. How can we integrate longevity as a necessary design concern into the IS lifecycle from Conception to Retirement? How can longevity become a rst-class citizen in Information Systems Engineering?
Non-functional quality. How does longevity relate to existing quality attributes of software systems? How do elements of existing quality models inuence longevity? What are the relationships between certain intrinsic qualities of software such as modularity, extrinsic properties such as portability, and longevity as a contextual quality in time? How can we decompose and separate these qualities to make them manageable? Which aspects have been neglected so far?
Diagnosis over time. Which artifacts and processes do we need to
diagnose, and which measures should we collect to diagnose them? How do
phenomena such as code decay [
Architectures and Tradeos . In which way does the introduction of longevity as a concern restrict the design space of S? At which point in the development lifecycle is longevity so important that it should take center stage? What is the impact of longevity as a concern on enterprise architectures? How can this be assessed and in which kind of viewpoint? How can we create a set of viewpoints to analyse this impact?
Given a desired set of features derived from longevity as a concern, how can
we prioritize and select these and assess the impact of not implementing subsets
of them? Whose concern should longevity be at which point of the lifecycle?
Given that only a limited number of quality concerns can be feasibly incorporated
into a design at any given point, which other qualities might get displaced at
which point? What are typical trade-o relations? How can we incorporate these
concerns into systematic trade-o analysis methods such as ATAM [
Who should have the responsibility to incorporate longevity as a concern into information systems engineering processes? What are useful patterns for addressing longevity?
Baseline analysis. Which techniques that contribute to information systems longevity by addressing non-functional quality concerns exist in which elds? Considering axes such as the Information Systems lifecycle phases and enterprise abstraction layers shown in Figure 2: Which are the actual dimensions we need to consider to position longevity and the related concerns? Which variables do we need to meausre to assess the current state of art of these techniques towards achieving longevity?
It becomes clear that in order to develop fundamental concepts for integrating longevity as a necessary design concern into the IS lifecycle from Conception to Retirement, an interdisciplinary approach is required that bridges Enterprise Governance of IT, Software Engineering, Requirements Engineering, Digital Preservation, Empirical Software Engineering, Systems Engineering, Information Systems Design, and other disciplines. 4
Our hypothesis is that longevity is a non-functional quality attribute of software artifacts, driven by organizational capabilities and socio-technical change processes. By including the fundamental concerns of longevity into the design and engineering of systems on the capability level, longevity as a vertical integrator should be able to relate these development concerns with change on the organizational level.
The denition of a longevity engineering approach as a bridge between isolated perspectives of existing processes will contribute to an increased independence and independent evolution of capabilities versus their constituent parts.
This article set out rst elements of a research roadmap towards a fundamental understanding of the factors contributing to software longevity. It is clear that this is a challenging eort requiring focused, longer-term research. Part of this work has been funded by the Vienna Science and Technology Fund (WWTF) through project ICT12-046 (BenchmarkDP).