CHAPTER 4
The Applications Component
Applications have been in existence since the earliest systems were built. The development lifecycle for applications, the day-to-day operation of the applications, and the ongoing maintenance that applications require is well documented. For all of these reasons, applications are well known to almost anyone looking at the corporate information factory.
Another way to think of the applications in the CIF is as a collection vehicle that is responsible for:
Gathering detailed transaction data
Interacting directly with the end user
Auditing and adjusting data
Editing data
Undoubtedly, the applications in the corporate information factory accomplish more than the simple functions listed here. For example, applications collect this data as part of their core function to automate key business processes within the corporation, such as accounts payable, accounts receivable, order processing, and transaction processing. The simple functions, however, are found in one form or another throughout the applications environment.
Dated Applications
The applications specified 20 years ago to address business problems are no longer sufficient alone to address the evolving needs of business. The corporation’s business climate has changed dramatically over time, but the application infrastructure representing the business of the corporation has not. Therefore, applications are not without their own unique challenges.
If applications were easy to change once built, there would be no problem. However, applications are notoriously difficult to change once implemented, because over time, they have become a collective millstone around the neck of the corporation; each new application merely adds weight to it. In this sense, applications are anything but easy to understand and manage.
The inability to be responsive to change is not the only challenge associated with applications. Another challenge is their unintegrated nature.
Unintegrated Applications
The applications are unintegrated for a variety of reasons:
The applications were built to suit the needs of one group, then another.
Applications were required as part of a corporate merger.
Applications were first built in-house and then augmented by third-party software packages.
The cost justification process applied to the development of applications did not allow for anything other than an immediate and obvious set of requirements to be addressed, thereby limiting the extensibility and reuse of the application solution.
This lack of integration of applications surfaces in many ways, such as:
Inconsistent key structures
Inconsistent encoding structures
Inconsistent structuring of data
Inconsistent reference structures of data
Inconsistent definitions of data
Inconsistent code and calculations
Inconsistent reporting
The lack of integration across the application environment severely affects its credibility and agility.
Applications’ Response Times
One of the features of the applications environment is the level (i.e., the speed) of responsiveness to the users of its systems. Users of applications often expect very good response times for the transactions that are being executed by the application. Good response time usually means a response in one to two seconds from the moment the request was issued.
It is reasonable that the end user expects very good transaction response time because:
Very little data is involved in any given transaction.
Transactions are run on technology capable of giving good response time.
The transactions operation details data that are directly and personally relevant to the consumer.
In some cases, the consumer interacts directly with the system, such as through an ATM or Web site. In other cases, the consumer interacts with the systems through an intermediary, such as an airline service professional or a bank teller.
Migrating from an Unintegrated State
Because the lack of integration of applications is a very large problem, it is normal for a company to migrate from an unintegrated state to an integrated state.
The problem with the migration suggested in Figure 4.1 is that it is expensive, painful, and slow to accomplish. Older unintegrated applications, for all of their faults, are very difficult to fundamentally alter largely because they run the day-to-day business. One of the burning issues of applications is how to achieve this migration. Five key steps are fairly common to the reengineering of these applications:
Define the strategic business vision. This includes a conceptual description of the evolving business landscape and the imperatives and competencies needed to compete on this landscape.
Define the information architecture needed to support the strategic business vision.
Figure 4.1 The transformation from an unintegrated state to an integrated state is slow, expensive, and still at a detailed level.
Assess the current application inventory and how this inventory aligns to the competencies defined in the strategic business vision.
Develop a migration plan that defines and prioritizes a series of three-to-four-month projects that will evolve, retire, or develop new applications to support the business vision. Each of these strategic projects should deliver immediate and incremental value to the business.
Execute the migration plan. To expedite the migration plan, companies may elect to purchase third-party application solutions from such companies as SAP, PeopleSoft, Baan, Epiphany, and Oracle.
External Data, Metadata, and Applications
Like other parts of the CIF, applications make use of external data and metadata. Figure 4.2 shows this relationship.
External data plays an important role in supporting detailed requests, at the most granular level. Applications also make use of metadata. Metadata keeps track of where data is coming from (end user, external companies, etc.), how data is being used (billing, order processing, etc.), and where data is going (data warehouse, ODS, etc.). Probably the most interesting distinction between metadata for the applications versus metadata for the data warehouse or ODS is that it is more important to the systems developer than it is to the end user. The systems developer is responsible for changes to the applications that interpret the data and, therefore, needs the knowledge of the applications provided by the metadata. Generally speaking, the end user deals with the applications environment through the system developer. In some respects, the systems developer becomes the “living” metadata repository for the end-user community. This is in contrast to the data warehouse where the end user is directly involved in evolving the DSS capabilities that interpret the data and, thus, needs access to the metadata that describes it.
Figure 4.2 External data and metadata are made available to the applications.
Feeds into and out of the Applications Environment
The flow of data into and out of the applications is simple. Figure 4.3 shows that raw detailed data is collected directly from the end user. This data represents the input feed of data into the CIF. The raw detailed data then flows out of the applications to the I & T layer.
An important architectural component of the applications environment is the system of record. This resulting source of data is captured by the I & T layer, transformed, and loaded into the data warehouse and/or ODS. The system of record represents the best source of data because it is:
The most complete source
The most accurate source
The most current source
The source that most closely conforms to the corporate data model
Figure 4.3 Applications feed data into the I & T layer.
Note that the data in the system of record does not have to be perfect and may occasionally contain imperfections. Also, note that the system of record may contain multiple sources for the same unit of data. Under one set of conditions, the system of record may reside in Application A. Under a different set of conditions, the system of record may reside in Application B, and so forth.
A good way to understand the relationship of data and processing in applications versus data and processing in the ODS and the data warehouse is to think of data as operating on a continuum of time. This continuum is suggested by the measurement of seismic activity. In Figure 4.4, a stylus is constantly measuring seismic activity, and tape is constantly moving beneath the stylus. Applications represent the recording of the seismic activity and the first few seconds after the recording has been made. The ODS captures the next few seconds in the life of the data. Then the data warehouse captures the data historically.
The continuous spectrum of the flow of data and how the data resides in different components of the CIF explains the relationship of the data in the corporate information factory to the architectural component.
Figure 4.4 One way of viewing the relationship of the age of data within the corporate information factory: Imagine a seismograph tracking the shaking of the earth. The data that is gathered has a different age. Based on the age of the data, there is a different use of the data and different implications to the organization.
Summary
Applications are the component of the data warehouse where transaction data is gathered directly, either from the end user or directly from the consumer. The history of applications is such that they are unintegrated. This lack of integration shows up in many places, such as:
Key structure of data
Definition of the data
Data layout
Encoding structure of the data
The use of reference tables
Transaction response time is an important issue for the applications component of the CIF. Another important issue is the integration of the applications. Unfortunately, applications are difficult and slow to integrate after they have been built and installed.
Data leaves the application layer and is fed into the I & T layer. An important decision to be made by the I & T layer is in selecting the system of record, the source of data that will flow into the I & T layer. The system of record represents the best data, not necessarily perfect data, that the corporation has collected in the applications.
Now that we understand where the detail/transaction data comes from, let’s take a closer look at how the I & T layer brings it all together.