Core Systems Framework
Glossary

Download the glossary in Word format

A | B | C | D | E | F | G | H | I | J | K | L | M
N | O | P | Q | R | S | T | U | V | W | X | Y | Z


Build or Buy Decision (see “Replacement”)
A build or buy decision is one that organizations make when looking to replace part or all of existing systems. An organization that has chosen to replace an application must then decide whether it wants to write, or “build,” its own application, or acquire, or “buy,” a software package.

Most feasibility studies include at least one option for each of these alternative approaches.


Burning Platform
“Burning platform” describes the situation where the hardware or system software cannot be upgraded to support the required functionality for any reason, including removal of vendor support, inability to support growth in processing demands or architectural limitations (such as processing capacity, storage capacity, connectivity limitations, and inadequate security).


Commercial Software (High-tech Dictionary)
Software developed for and sold to the general public. Generally there are licensing fees associated with the use of such software.


Core System
Core systems are applications and enabling technologies that support critical business functions for the state or for one or more agencies. Current core systems support the administrative business of state government such as payroll/personnel, accounting/budgeting, and purchasing. They also support state services such as licensing and client payments.

It should be noted that not all core systems are “legacy” or “mainframe-based”, although they may be. Core systems may also use client/server or Web technologies. Agencies are beginning to consider specific portions of the infrastructure as core systems. An example is the state network, without which constituents would be unable to access the applications.


Develop (Agency, Vendor, Combined)
The custom writing and implementation of software to meet a specific set of business requirements. Sub-categories under this development alternative include “Agency”, “Vendor”, and “Combined”. “Agency” developed means that agency staff do all the development and implementation work on the new application. “Vendor” means a vendor does all the development and implementation work. “Combined,” means a mix of agency and vendor staff do the development and implementation work. There are many variations of how an agency and vendor may work together. ISB policy recommends agencies strongly consider using vendor staff to develop complex applications because it lowers the risk to an agency.


Enterprise-wide
In the context of Core Systems, “Enterprise-wide” refers to information technology requirements, plans, systems, etc. that span or are common across multiple State agencies. An enterprise-wide system is not necessarily a core system. The state's accounting system, AFRS, would be considered both an enterprise-wide and core system; the Travel Voucher System, used for submitting travel expenses, is an example of an enterprise-wide system that is not considered a core system.

It should be noted that “Enterprise-wide” as used in this Framework applies only to state agencies. A system used by a single state agency and multiple non-state governmental entities would not be considered enterprise-wide.


Extension /Enhancement
Extension and enhancement refer to providing an additional business function or client access with minimal modification to the basic application. Extension/enhancement is often the preferred approach for applications and systems that are delivering benefits through the existing architecture. Enhancement is usually used to provide web access to core systems.

Extension and/or enhancement are used when new application functionality is required due to the addition of legislatively mandated programs or changes to existing programs; development of data warehouses to support decisions that would be difficult using the existing system; the addition of graphical front-end support (i.e., Web browser) that provides a standard and familiar user experience; and the modification of an application to provide Internet accessibility.

A recent example of a large, mainframe-based system that continues to be extended and enhanced is DSHS' Automated Client Eligibility System (ACES) with its data warehouse. This system remains viable and extensible into the foreseeable future. Another example is DOL's application for renewing automobile license tabs online.


Legacy Systems
Legacy systems are those that have existed within an organization for many years in basically their original form. They are typically the core systems (or at least the core data) of any organization and are usually larger, mainframe-based systems. Examples include the state's payroll system, AFRS, and the driver's licensing application.

Although used throughout the industry, this term is falling out of favor because of increasing negative connotations such as old, inflexible, expensive, mainframe, obsolete.


Modify (Extend, Enhance, Refurbish, Re-engineer, and Renovate)
Modify means to change the operation of a core system without completely changing the hosting platform or the software that runs the application. A proposal to modify a core system may involve the following strategies: extend, enhance, refurbish, re-engineer, and renovate. Major proposals usually involve several, if not all, of the above strategies, so the Framework does not break down the “Modify” alternative by type of strategy employed.


MOSTD
MOSTD stands for Management and Oversight of Strategic Technologies Division. Staff is located out of the Department of Information Services. They provide IT policy leadership and oversight for the state, and explore new technologies that deliver government services where and when they are needed. The MOSTD Division provides staff support to the Information Services Board (ISB) regarding statewide strategic and tactical IT planning.


Outsource
The acquisition of an application and maintenance from a vendor. Hardware platform specifications are provided by vendor but application may reside on or be “hosted” on agency-supplied hardware platform. Everything else (e.g., software, training, support) is provided by the vendor (complete solution). There are many variations of how agency and vendor staff may work together to provide an outsource alternative.


Public Domain Software
Software which normally has been developed for a governmental entity and has no copyright protection and can be used or copied by anyone free of charge or license fees. The phrase “public domain” is often used incorrectly to refer to freeware or shareware (software which is copyrighted but is distributed without (advance) payment). Public domain means no copyright -- no exclusive rights.


Rehosting
Rehosting involves the migration of an application to a different computing platform. It should be considered as an option when an application remains viable but the hardware and/or operating system platform is no longer viable or able to provide a function that is critical to the continued operation or enhancement of the system. An example of a situation that may force rehosting is where the hardware or software cannot be upgraded to support security functions that are needed for direct client access or for other issues associated with a “burning platform.”

An example of a system that has been designated for rehosting is the Community and Technical Colleges administrative applications. The existing applications maintain the high degree of functionality required by the colleges. This rehosting project will move the existing business logic and data to a modern hardware platform and modern relational database system. Once this has been accomplished, the Center for Information Services (CIS) and the colleges can begin to enhance application functionality.


Replacement
Replacement means converting to an entirely new application that provides the same or similar business function. A replaced application is retired at the end of conversion. Replacement is an option when the cost of continued maintenance and/or proposed enhancements would exceed the cost of implementing an entirely new system. It may also be an option if there is a question of the availability of technical resources to continue with the current system.


Requirements
In terms of the “New Requirements” and “Impact Analysis” tools found within the Core System Framework, requirements are: 1) the high-level critical business factors (from alerts or trends) that are driving an agency to develop a proposal to do something or do nothing with their Core System; 2) anything new or significant (a Federal, State or Governor mandate, something to sustain or enhance a system, to leverage a business opportunity, etc.), that may result in pursuing a proposal to do something or do nothing with their Core System.


Retirement
Retirement is the last step in the life cycle of a system or application. It occurs when the application is turned off and removed from the agency portfolio due to the inability to provide a useful business function.


System
A group of related automated procedures and components that work together to support a business objective. A system typically includes the hardware, the database, all the data entry, update, query and report programs, and the associated procedures.


System Refurbishment/Reengineering/Renovation
Systems are candidates for refurbishment, reengineering, or renovation when the business logic embodied in the application no longer matches the processes as they exist in the physical world, or to improve the performance and/or maintainability of the application.

System refurbishment means rewriting existing software to do what was originally intended. It often involves modifications to the coding.

System reengineering means rewriting existing application logic to match current business processes. It often involves changes to the design and data structures.

System renovation means rewriting part or all of an existing application in another language while maintaining the existing logic (for example, converting from COBOL to JAVA).


Vendor Partnerships
Vendor partnerships occur when an organization partners with an external vendor to produce some or all of the system components, attributes, and activities that might otherwise be done by the organization's IT department alone. These items may include application development, disaster recovery facilities, and network management. Reasons for partnering include scarcity of resources, focusing on core competencies, cost containment, or blending expertise from both the public and private sector to develop solutions.

 

 

 

| Home | Privacy | Site Map | Copyright © 2008 by DIS