Winning in Today's Information Economy with a Data-centric Business Strategy

An Executive Perspective on Data Strategy

Why care about Data?

Why should business leaders care about data and why should they care about having a business strategy that draws on data-centric tenants? I don’t mean this rhetorically; I mean really, why should they care? If you are reading this and you are responsible for an operational front-line process, a manager for an operational area or a leader of a business unit or division, you have probably started to think about this question out of necessity. If you are reading this and you work in technology, you may have been hoping for the day when your business partners start to consider questions like this.

Slaying the Legacy Dragon - Modernizing the Monolithic Legacy System

An Executive Perspective on Large Scale Legacy System Modernization Programs

Phasing out the Mainframes

Many organizations are facing the end of life for their core legacy systems. These systems, often mainframes or the like, have been enabling critical business functions for the last 25-30 years. When faced with the reality that the legacy systems are becoming a hindrance to business agility and growth (not to mention the daily risk of instability), you are the IT executive being looked at for the answer. Replacing legacy systems usually has lots of upsides for the business – greater efficiency, new functionality and business agility – but it also comes with incredible delivery risk and expense.

White Paper: Building a Data-centric Strategy & Roadmap

Why do you need a data strategy? Because competing in today’s marketplace requires data-driven strategies

We believe that the future marketplace for almost every industry is going to be heavily reliant on information to compete. While everyone may acknowledge this, very few organizations actually live it.

White Paper: Valuing Data Management

In the fall of 2013, as the new book Monetizing Data Management was being completed, we decided to survey our audience to see how they were addressing this important topic. A statistically significant sample of more than 100 responses provides important insights into this issue that we discuss in this white paper on how organizations define value.

White Paper: The Precarious State of The CDO - Insights Into a Burgeoning Role

The role of the chief data officer (CDO) is relatively new across the organizational landscape – 70% of current CDO positions were created in the last year alone! The past decade has seen a combination of events, forcing organizations to consider this increasingly important role:

The Perfect [Data] Storm

Peter Aiken, PhD and Lewis Broome of Data Blueprint highlight the need for business to provide a solid data foundation to their data leveraging initiatives. The good news is that this same information architecture can be used for data leveraging strategies. As businesses, we have all benefitted from computer automation. We are now reaching the limits of automation-based benefits and will increasingly look to data leverage as the new source of these benefits. Data, of course, plays a huge role in both of these concepts and advantageous data management correspondingly becomes a necessary but insufficient precondition to success. Information architecture patterns such as Master Data Management [MDM] provide “hows” that correspond to business objective “wants”.

Data Management and Data Administration

Data management (DM) has existed in conjunction with software development and the management of the full set of information technology (IT)-related components. However, it has been more than two decades since research into DM as it is practiced has been published. In this paper, the authors compare aspects of DM across a quarter-century timeline, obtaining data using comparable sets of subject matter experts. Using this information to observe the profession’s evolution, the authors have updated the understanding of DM as it is practiced, giving additional insight into DM, including its current responsibilities, reporting structures, and perceptions of success, among other factors. The analysis indicates that successfully investing in DM presents current, real challenges to IT and organizations. Although DM is evolving away from purely operational responsibilities toward higher-level responsibilities, perceptions of success have fallen. This paper details the quarter-century comparison of DM practices, analyzes them, and draws conclusions.

Using Codes of Conduct to Resolve Legal Disputes

We illustrate the current application of CoCs (codes of conduct) with a fictional enterprise resource planning (ERP) system implementation failure that is a compilation of real-life cases. Subject to binding panel arbitration, the plaintiff and defendant in the case presented conflicting interpretations of the same facts: From the plaintiff’s perspective, the defendant failed to migrate the ERP system as promised; the defendant countered that defective and poor-quality data delayed the migration. Using ACM/IEEE-CS CoC as a reference, expert testimony convinced the arbitration panel that the defendant’s position was untenable, and the panel accordingly awarded the plaintiff a multimillion-dollar judgment.

Rapidly Improving Quality in Large Data Collections

While data quality has been a subject of interest for many years, only recently has the research output begun to converge with the needs of organizations faced with these challenges. This paper addresses the fundamental issues existent within existing approaches to improving DoD data quality (DQ). It briefly discusses our collective motivation, examines three root causes preventing more rapid DQ improvement progress. An examination of “newly perceived” realities in this area leads to discussion of several considerations that will improve related efforts.

Dr. Peter Aiken gave this presentation at the 2010 SEI/Carnegie Mellon Data Quality Workshop on October 26, 2010.

Measuring Data Management Practice Maturity

Increasing data management practice maturity levels can positively impact the coordination of data flow among organizations, individuals, and systems. Results from a self-assessment provide a roadmap for improving organizational data management practices.

Assuring Data Quality for ERP Implementation - Part II

Presenting results subsequent to those presented at the 2003 ICIQ Conference, we describe how our team-based approach to addressing legacy data quality has necessarily evolved over a multi-year period. Developed as a team by the government in conjunction with a research institute, an initial task has evolved considerably over the ensuing years. A “data quality challenge” associated with DoD/DLA’s migration from SAMMS to SAP, has now evolved through six distinct phases. Tangible savings and results have been documented. Perhaps more useful are the lessons learned over the multiple project years as we collectively reached improved understandings of the problem nature and its implications. These involve evolving and maturing our understanding and approach to data quality by adding a structure-orientation to what had been addressed as a practice-oriented data quality challenge. Earlier recognition would have permitted additional savings to be realized.

XML-based Portals Save You Money

XML-based portals can allow you to develop information delivery systems in weeks instead of years and often without requiring application programmers.

Using Your Information: Metadata

This article describes metadata and the reasons that I consider metadata management to be the number one issue facing the intelligence community. On these pages, I will address topics of importance to the intelligence community such as: What is metadata? Why is it important? Why has metadata been a difficult topic to address in the past? The answers to these questions should make it easier for intelligence community professionals to convince management to plan, budget and invest resources in metadata management.

Extracting Data from Free Text Fields

This experience paper describes a repeatable model developed to address a class of data quality problems encountered when converting text data to ERPs. Users often devise their own means of implementing system features not directly supported by the systems. Often they employ what are known as clear-text, free-text, or “comment” fields to support the desired features. Moving data from these fields to ERPs involves first extracting atomic data items. Unlike most data, free text is not subject to structural or practice-oriented data quality measures when it is created. This results in a range of data quality challenges ranging from typing errors to structural errors such as prime key mismatch, duplication, and other issues. In our experiences with one large government system, a number of challenges were encountered that contained enough internal differences to require the development of a more generic framework for addressing this type of problem. The specifics of the actual issues confronted are not as interesting as the lessons that can be learned from the general approach to problems of this type. The solution type developed demonstrated a positive return on investment to the government. We will discuss the challenges, the costs associated with continuing along the original path, the solution developed, and its applicability to other organizations and situations.

Experiences Reverse Engineering Manually

Whether automated or manual techniques are employed, reverse engineering goals remain identical. This paper describes the development and application of a manual reverse engineering analysis of a large, legacy system. The reverse engineering analysis goal was to provide a preliminary analysis identifying potential functionality in a legacy system that could be reused as part of a larger system reengineering effort. The manual analysis was required because circumstances prevented the application of automated reverse engineering techniques. The paper describes: the larger organizational systems reengineering context in which the reverse engineering was required; the circumstances motivating the specific reverse engineering analysis goals; the situational characteristics preventing application of automated techniques; the manual reverse engineering process developed to achieve the analysis goals; the evolution of the analysis products during the course of the analysis; the analysis results; the resources required to produce the results; and an evaluation of the process effectiveness.

Data Reverse Engineering - A Historical Survey

Data reverse engineering is a rapidly growing field, which is sometimes misunderstood. In our effort to promote the realization that data reverse engineering is a valuable and essential part of reverse engineering and is now finding its place in software engineering, we present a summary of the history of data reverse engineering. In this paper, a definition of data reverse engineering, a summary of the history of what has been done and published, a statement about the state-of-the-art today, and a comment on the future of DRE is presented.

The BRIDGE: Reverse Engineering Systems Metadata

Based on widely available Office-suite components, we developed a flexible toolkit to support the methodology and facilitate enterprise software system migration. The toolkit allows users to capture, analyze, and publish various implementation-specific metadata. We used the toolkit to publish metadata for use by the technical implementation team as well as by project management and business users. We describe each methodology component, the associated toolkit elements developed to implement each component, the various component outputs, and the resources required to implement the solution. The methodology was developed in the context of an anonymous real world implementation. Organizations can use this approach to create a sound basis for reverse engineering system metadata when migrating to enterprise software.

Reverse Engineering New Systems

Practitioners and researchers are currently investigating reverse engineering as a means of leveraging system reengineering and maintenance efforts. This article illustrates the utility of reverse engineering new systems, using as an example a commercial, client server system. We describe the motivations for, approach to, and results of reverse engineering a new system from PeopleSoft (see Enterprise Software side bar). The reverse engineering was a preliminary implementation activity that was designed to derive unavailable metadata describing the PeopleSoft system architecture. The derived metadata was maintained in a repository and used in subsequent implementation activities. An important finding was that, maintained in a normalized format, the three metadata types (describing system, workflow, and data structures) effectively assisted system implementation. This case study contributes both theoretical and practical insights, broadening the perceived utility of reverse engineering.

Requirements-driven Data Engineering

In the early 1990s, the effectiveness and efficiency of the information systems (IS) supporting the US Department of Defense’s non-combat operations was questioned. As had many organizations, the support had evolved into multiple, redundant, unintegrated, undocumented, stove-piped IS. These systems require unnecessarily large non-combat IT expenses, supporting war fighting efforts. Lack of integration hindered the Department from effectively providing mission support information. DOD’s efforts to re-engineer the non-combat IS is one of the first attempts to apply requirements-driven data engineering to a large systems environment. Its application to DOD’s non-combat IS data environment has provided tangible results: (1) from the top down, an enterprise model (EM) now specifies Department-wide requirements capable of guiding future integration and development efforts; (2) from the bottom-up, non-cobat IS are being significantly reduced, simplifying the overall problem; and (3) data quality engineering methods, guided by the EM, are being developed and applied to the remaining IS. This success has achieved a prerequisite necessary to increase the effectiveness and efficiency of the systems.

Reverse Engineering of Data

Interest in reverse engineering is growing as organizations attempt to reengineer existing systems instead of replacing them. When a system is reverse engineered, it is examined, documented, modeled, analyzed, and understood in order to better inform subsequent efforts. Of additional value, the reverse engineering analysis outputs can be reused as a source of enterprise architecture components. Since successful systems reengineering (SR) depends on effective reverse engineering, it (reverse engineering) is viewed as a critical part of SR.

Synergy Between BPR and Systems Reengineering

Business process reengineering (BPR) and systems reengineering (SR) are often implemented separately, in an uncoordinated fashion. Yet practitioners realize that BPR can be informed by SR and that SR can benefit from the application of BPR concepts. This research indicates that potential synergies can result when BPR and SR are pursued in an integrated fashion. The paper presents an integrated BPR and SR model that has been successfully applied in practice.

Data Reengineering Fits the Bill

It’s a relatively common situation. You break open the shrink-wrap on a million-dollar client-server application and read the directions, which say something like “plug your database in here.” The problem is that your legacy data (like that in most large organizations) resides on multiple platforms. In the case of the Commonwealth of Virginia, the legacy pay system runs as a 10-year-old VSAM-based application on an Amdahl MVS host. (…) Most commercial client-server applications assume that your goal is to replace the legacy database. The existing data capabilites are inadequate – the client-server technology is being implemented to enable Virgina to meet the increased data requirements. So how do you transform the existing application to meet the new requirements?

Hypermedia-based Support for Requirements Analysis

This paper describes our efforts at providing hypermedia-based support for requirements analysis. We present an overview of our concept of hypermedia-based support for the requirements analysis process, our experiences using this technology, and some remaining technological challenges highlighted by our experiences. Our analysis of requirements and analysts’ needs indicates several productivity related benefits will result from the successful application of hypermedia technologies especially in rapid prototyping contexts. These relate to hypermedia’s ability to more faithfully capture and represent system requirements, providing increased requirements traceability and giving analysts direct, repeatable access to multimedia requirements information that would otherwise be unavailable.

Hypermedia Support for Software Development

Hypermedia technologies have been available for about a decade. Beginning with Douglas Engelbart, researchers have become interested in applying hypermedia concepts and technologies to software development. This paper assesses this symbiosis between hypermedia and software development as described by research contributions; by our count, more than one hundred articles. To date, no collection of, or guide to, this literature has been published. A number of significant contributions are classified, described, and appraised – providing a guide into what has been a rich but perhaps under-reported research area. Hypermedia has made significant contributions to software development in three primary areas: coping with massive amounts of information associated with software development projects; establishing and maintaining linkages between various types of software engineering documents; and enabling development engineers to record, document, and preserve knowledge about development thoughts, processes and rationale. These contributions may help direct the focus of future research towards building on, combining and assessing the resulting contributions. A research agenda is proposed along these lines.

Cooperative Interactive Storyboard Prototyping

Certain types of products appear to be continually associated with poor interfaces. Especially for these product types, the need for active end-user participation in development activities is seen increasingly as critical to quality interface development. Cooperative Interactive Storyboard Prototyping (CISP) is a development approach facilitating active end-user participation in design activities that help to address these apparently difficult design problems. Key features of CISP include: 1) reducing the time and effort required to produce iterations of prototype interfaces; 2) support for interactive prototype use, evaluation and modification; and 3) creation and use of modifiable, domain specific building blocks.

Hypermedia-based Requirements Engineering

This chapter outlines a hypermedia-based approach to the requirements engineering portion of software development life cycle. While as yet untested, hypermedia-based tools and techniques seem to offer promising benefits to the analysis and design phases of certain classes of software system development. The first half of the chapter is devoted to a examination of the development of hypermedia as a technology. While its conceptual origin dates to 1945, only recent efforts by software engineers have resulted in tools that begin to approach the functionality of concepts put forth by researchers in the field. These concepts are briefly reviewed. A wide range of software packages have what are labeled as hypermedia capabilities. The next section presents definitions intended to cut through the hype surrounding the evolution of this new technology. The following section presents an examination of the actual capabilities of hypermedia-based systems. These have been summarized as eight features common to systems with hypermedia capabilities. The second half of the chapter is devoted to a discussion of the application of hypermedia features to requirements engineering functions. While not applicable, to all cases each of the eight features can be implemented in a fashion augmenting the development of certain classes of software applications. Specific classes of systems benefitting from the application of hypermedia-based requirements engineering are identified. The requirements engineering process is briefly described in terms of four basic functions: capture, organize, structure, and present. Hypermedia support for each function is outlined. The chapter closes with a brief description of a workstation constructed from off-the-shelf components capable of supporting hypermedia-based requirements engineering.