Consolidated Artifact Definitions
Artifacts are units of information input and output by the activities. This page consolidates the definitions from across all the activities in the guides. Some artifacts are formal products that have specific content (e.g., the HS IT Strategic Plan). Others are placeholders for categories of information that are usually context dependent, such as External Conditions.
Artifacts can be realized in many different ways depending on the context in which an activity is performed. The Resources provides a growing list of templates, samples, checklists, or other items to help identify, format, and use some of these artifacts.
Guidance on applying the processes defined by the guides is available in the Customizing the IT Planning and Management Guides page.
| 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 |
Advance Planning Document (APD). This document records information for the APD process, which is designed to: (1) Describe in broad terms the State's plan for managing the design, development, implementation, and operation of a system that meets Federal, State, and user needs in an efficient, comprehensive, and cost-effective manner; (2) Establish system and HS program performance goals in terms of projected costs and benefits; and (3) Secure Federal financial participation (FFP) for the State.
Advance Planning Document Update (APDU). There are two types of APD Updates (APDUs), which are used to keep HHS informed of the project status, and to obtain continued funding throughout the life of the project:
- Annual APDUs, which are used for providing the official project status reports and requesting continued project funding; and
- As Needed APDUs, which are used if significant changes occur in the project approach, procurement, methodology, schedule or costs.
Activity Status. This represents the reporting of information about the state of a managed set of activities, such as those for to Plan the Course of Action. The type of status varies depending on the activity.
Agency Technical Architecture Reference Set (A-TARS). This is a virtual document that organizes all the Technical Architecture descriptions and accompanying technical guidelines. The A-TARS content can be rendered in any format that furthers its direct use by system designers, such as type libraries for service interface definitions, online HTML help files, or embedded compound document files.
A-TARS: Agency-Wide System Properties. This portion of the A-TARS describes the essential characteristics that all the Agency's automated systems (or parts) should possess (e.g., availability, privacy, maintainability). These properties guide the architects design decisions and tradeoffs, such as selecting architectural styles (e.g., central host or distributed). These properties act as criteria for determining the adequacy of the technical architecture elements in whole or part. The properties should account for unanticipated changes in the business or technology environment over the duration established for the IT vision. These properties must conform to the principles in the HS IT Strategic Plan.
A-TARS: Data Sources and Business Rules Reference Set. This portion of the A-TARS describes the common data stores, message formats, business rules, and related data, message, and rule processing technologies and guidelines. The goal is to ensure data interoperability and its validity across the Agency.
A-TARS: Integrated Technology Descriptions. This portion of the A-TARS describes the way the technology elements are assembled to form a set of interacting computing platforms. The top-level entities that are described are the platforms or specialized equipments, data sources, and their interconnections.
A-TARS: Networking Reference Set. This portion of the A-TARS describes essential characteristics, assumptions, and guidelines for networking the Enterprise computing platforms within and external to the HS Agency.
A-TARS: Platform, Equipment, and Solutions Reference Set. This portion of the A-TARS describes the significant hardware and/or software configurations that are to be used across the Agency (e.g., existing legacy systems, functional user desktop or application servers configurations, and prepackaged solutions).
A-TARS: Services Reference Set. This portion of the A-TARS describes the elementary services that are defined for the Agency. The definition includes the service interfaces, execution behavior, reference implementations and other information essential to consistently procuring, building, and deploying common, reusable services. The services are organized according to service areas in accordance with the Agency Technical Reference Model.
A-TARS: Agency Standards Reference Set. This portion of the A-TARS consolidates the list of Agency standards and how they have been adapted. These can be consolidated into one place or distributed across the other parts of the A-TARS, as needed.
A-TARS: TRM Description. This portion of the A-TARS describes the Agency's Technical Reference Model. This model categorizes and describes the services and their relationship to one another in accordance with a conceptual model, such as the Open Software Environment.
A-TARS: Technology Boundaries Descriptions. This portion of the A-TARS describes the external entities and their interaction across the Agency's technology boundaries. This establishes the essential characteristics for the interaction platforms and devices.
A-TARS: Technology Element Descriptions. This represents the aggregation of four portions of the A-TARS: Data Sources and Business Rules Reference Set; Network Reference Set; Platform, Equipment, and Solutions Reference Set; and Services Reference Set. These describe the basic building blocks from which the Agency systems are constructed.
A-TARS: Technology Guidelines Reference Set. This portion of the A-TARS provides technical and management guidelines to the developers and users of the A-TARS. Architects and developers will apply these guidelines to promote consistent definition, presentation, and implementation of the Agency technical elements. This may include process or product guides, such as engineering guides (coding, design, testing), configuration management guides (configuration identification), and vendor qualification (evaluating compliance to the ATA).
AIS Design and Implementation Information. This represents descriptions of the existing automated systems. This information accurately reflects the state of the existing technology. This may include process (e.g., engineering practices such as tools and methodologies), as well as products (e.g., existing software products or components) information.
Ancillary Design Information. This represents the additional design information available to users of the A-TARS. This information is not necessarily a formal part of the A-TARS. This additional data may include design notes, trade studies, reference implementations, simulations, prototypes, analytical models, or additional descriptive material. That information can be retained within a Technical Architecture Team repository and referenced from the A-TARS, as needed.
B
C
Critical Factors. This represents statements about the few things that must be in place to achieve a set of goals.
Change Requests. This represents requests to change description in the A-TARS (e.g., a service description). These requests can originate from any source, such as an HS program (e.g., TANF), the IT project, or the Technical Architecture process. These changes represent the need for corrective, perfective, or adaptive maintenance of the architecture descriptions.
Changes. This information denotes a formal or informal request to change an output of an activity. If the work product to be changed has been formally released by that activity (e.g., completed a peer review), it may require a formal change request. Work products that are in process do not need a formal change request.
Change Requests. This represents the documentation of requests to change the deployed technology assets. Requests can be initiated from any source, such as new or changing needs, maintenance actions, or changes occurring outside the HS Agency. The requests are analyzed and the user issues changes to the technical assets or the HS Agency technology related processes (those defined in the IT Planning and Management Guides)
Configuration Management Plan. This represents the detailed plans for each project's CM activities. In addition to the CM resources and schedules, it identifies the CM procedures and practices, such as the identification scheme and products to be managed.Contracting Strategy Document. This document defines which of the products will be built internally, by contractors, or purchased, and the rationale that was used in the make or buy decision.
Contract Management Plan. This document describes the process that will be used by the HS Agency personnel to manage a specific contract.
Contractor Management Plan. This document describes the process that a specific contractor will use to manage their activities.
Contractor and Procurement Documentation. This is the collection of legal and binding documentation that has been agreed to for a specific contract.
Contractor Status Reports. This represents information a contractor provides to the HS Agency regarding performance progress or issues for a specific contract.
D
Decision Papers. Major decisions (such as from formal reviews) are officially recorded and used as a basis for adjusting or showing commitment to plans and progress. The decision can concern the overall IT evolutionary path, a specific plateau, or a specific project.
Descriptions of the Current Situation. This information summarizes the most important characteristics of the current environment. It describes the current internal, external, and IT conditions (opportunities, threats, strengths, or weaknesses) that bear on the HS IT Division's strategic choices. Example items to be described include statutes, orders, and rulings; values and priorities of external organizations as expressed in policies, plans, and budgets; existing HS IT models and summary data. Plans that give insight into the current intentions or direction of IT and IT-related activities as also examined (HS Agency strategic, acquisition, staffing, training, project, maintenance or other plans). These plans may be formally of informally documented.
Deployed Configuration. This represents the total set of hardware, software, associated documentation, and data that is configured and placed into the business, developmental, or operational environment.
Deployment Project Plan. This represents the detailed plans for each deployment project's activities. Each project is tracked against its plan. These plans are integrated and coordinated in the IT Evolution Plan. These plans document all deployment project activities necessary to coordinate with the recipients of the deployed products.
Developmental Configuration. This represents the total set of hardware, software, associated documentation, and data that is integrated and ready for deployment to the business, developmental, or operational environments.
Directives for Mid-Course Adjustments. This represents higher-level guidance to the architecture and planning activities to make adjustments to those activities, as needed. For large deviations, the HS IT Strategic Plan will be revised.
E
Estimate of the Situation. This document contains the current goals, stakeholders, objectives and constraints for the IT evolution, plateau, or project Initially, it is documented as a part of the Define Context process, and kept up to date as the IT evolution progresses.
External Conditions. This represents the sources from which the Strategy Team can learn about the various circumstances outside the HS Agency. These are situations and forces usually beyond the HS Agency's control that, nevertheless, can bear on the HS Agency's success, causing it to adapt in some way. From outside, come inhibitors and facilitators such as government regulations, economic conditions, various trends (technology, industry, society, etc.) and behaviors of "competitor" or "partner" organizations. Overarching constraints are also considered to be included in this information.
F
G
Goals. A statement of the IT Division or HS Agency's strategic goal is a broad area of endeavor that must be addressed if the IT Division is to make progress toward its vision.
H
HS IT Conditions. This represents the sources from which the IT Strategy Team can learn about the various circumstances within the IT Division, as well as the IT Division's interactions with other entities. This includes the obligations, responsibilities, and interfaces within and outside the IT Division. Included in the information is data about the inventory of IT assets and the life-cycle processes used to produce, operate, and retire these assets. HS Agency models that are used to describe the IT systems or their use are also considered part of this information set (e.g., process or logical data models), including the IT-related plans (e.g., current system development or upgrade plans).
HS IT Initiatives. This part of the HS IT Strategic Plan represents the definition of the highest-level organization of actions taken to achieve the goals.
HS IT Strategic Plan. This work product describes the strategy for the HS IT Division. It is the overarching document (or set of documents) that defines the vision, mission, goals, initiatives, and other information necessary to establish and maintain the strategic alignment of the HS IT Division with the State HS Agency. This plan is used as the basis for defining and implementing further detailed actions within the HS IT Division as well as supporting actions outside it.
I
Internal Conditions. This represents the sources from which the IT Strategy Team can learn about the various circumstances and forces inside the HS Agency. These conditions bear on the success of the HS Agency. The HS Agency has some measure of control over these conditions, so tradeoffs can be made when trying to improve them. These conditions can either facilitate or inhibit the HS Agency's ability to adapt to changing external conditions. Internal conditions may represent competencies that might need to be improved. Overarching constraints are also considered to be included in this information. This information may include summary descriptions of the HS IT strategic needs captured and encoded into either summary lists or formal models and statements. Examples are subject area diagrams, high-level process/function diagrams, lists of reporting requirements, or geographic or organizational models.
IT Archive. This represents the retention of IT products or data items after they are removed from the usage environment. The HS Agency cannot immediately destroy them and may need to refer to them for legal or other reasons.
IT Baseline and Assessment. This represents summarization of information about the current IT inventory and its qualities. This contains information about the number and types of IT assets (e.g., applications, platforms, data sources, and networking), as well as a subjective quick-look into some of the asset's essential properties (e.g., maintainability, usability, and reliability). This can include process aspects as well (cycle time for processing change requests).
IT Evolution Plan. This represents those plans that define the evolutionary path for the HS IT infrastructure and applications. This plan defines each plateau that will be achieved over time. Each plateau may include updates to the current functionality for specific HHS programs and/or updates to the HS IT infrastructure. All HS IT Project Plans are components of the IT Evolution Plan.
IT Products and Data. This represents individual or aggregate IT products and associated by-products produced or used during the fabrication, deployment, or operation of the HS Agency's automated information systems. Products may include any technology element, such as applications, computer platforms, networking infrastructure and devices, data stores, or miscellaneous equipment. Data includes any documentation needed to create, maintain, or use the products, such as design, user, or maintenance documentation and training materials.
IT Project Plan. This represents the detailed plans for each IT project's activities. Each IT project is tracked against its plan. The set of all IT project plans is integrated and coordinated in the IT Evolution Plan. There can be many types of IT projects depending on the approach taken to produce the technology products, such as development, prototyping, maintenance, acquisition, or contracting with vendors.
Internal Conditions. This represents the sources from which the Strategy Team can learn about the various circumstances and forces inside the HS Agency. These conditions bear on the success of the HS Agency. The HS Agency has some measure of control over these conditions, so tradeoffs can be made when trying to improve them. These conditions can either facilitate or inhibit the HS Agency's ability to adapt to changing external conditions. Internal conditions may represent competencies that might need to be improved. Overarching constraints are also considered to be included in this information. This information may include summary descriptions of the HS IT strategic needs captured and encoded into either summary lists or formal models and statements. Examples include subject area diagrams, high-level process/function diagrams, lists of reporting requirements, or geographic or organizational models.
J
K
L
Lessons Learned. This represents project technical and management information that is kept after a project completes. It is analyzed and used to improve the technical and management processes.
M
Mandates. This represents the current and new regulations that the HS Agency must follow. Some of these mandates may flow from court rulings or State and Federal legislation and regulations.
Maintenance Requests. This represents requests from stakeholders in the business, development, or operational environments to correct, perfect, or adapt the deployed IT to meet needs.
Measurements. This represents activity measurements. The measurements taken depend on the context for the activity, such as strategic measures.
N
O
Operational Configuration. This represents a snapshot of a set of hardware, software, associated documentation, and data that exists in the business, developmental or technical operational environment at any particular time. This configuration changes as the IT products are used and maintained.
Operations Status. This represents the collection, analysis, and dissemination of performance, defect, cost of operations, and other data for the operational systems.
Operations Project Plan. This represents the detailed plans for administering, operating, and sustaining the technical assets once released for use. Each project is tracked against its plan. Theses plans are integrated and coordinated in the IT Evolution Plan. These plans document all deployment project activities necessary to coordinate with the recipients of the deployed products.
Overarching Constraints. This represents overall organizational obligations imposed on the HS IT Division by Federal, State, or the HS Agency. These obligations can generally be found in the policies, standards, plans, budgets, architectures, or guidelines. They generally are non-negotiable. Examples are State strategic goals and Enterprise system architectures of State and/or county HS Agencies, related Agencies or departments, and related IT Divisions, as well as Federal reporting requirements.
Some of these constraints may originate within the HS Agency, perhaps in reaction to the HS Agency external conditions. The HS Agency has control over the decisions that lead to these constraints and conditions, and it is possible that one can make tradeoffs.
P
Performance Measures. This represents key measurements for insight into progress against a goal or subgoal. The measures provide management the ability to take action if actual performance deviates from planned. These measures can be process-related (e.g., effort, schedule, cost) or product-related (e.g., lines of code, number of requirements, and number of entities).
Plan for Evolution Planning. This represents the detailed plan to guide the development of the HS IT Evolution Plan. It defines the individuals that are responsible for providing detailed portions of the HS IT Evolution Plan.
Planning Advance Planning Document (PAPD). A PAPD is a written plan of action to determine the need for, feasibility of, and projected costs and benefits of an automatic data processing equipment or services acquisition. PAPDs are used by States that will be reimbursed for the costs of planning for the implementation of a system, including acquisition of equipment or services.
Plateau Plan. This represents the set of plans that guides an increment or step in the overall IT Evolution Plan. A plateau generally includes a change in the functionality for specific HS Programs and a modification to the HS IT infrastructure as the next logical in the IT evolution. A plateau is generally scheduled every three to six months. A plateau may focus on evolving IT capabilities in the development, business, or operational environments.
Process and Product Evaluations. This represents the results of any review or audit of project activities or products by the Quality Assurance team.
Project Archives. This represents project technical and management information that is kept after a project completes. It is analyzed and used to improve the technical and management processes.
Project Charter. A charter defines the authorities, responsibilities, and constraints that the overarching HS Agency IT organization delegates to a specific project management team. The charter can establish the portion of the A-TARS that is applicable to the project, the project's cost and schedule constraints, specific requirements or requirements source (if the project supports a specific mandate or program), and the interdependencies between this project and other projects in the IT Evolution Plan.
Project or Product Requirements. This represents the complete set of technical and nontechnical requirements that a project and its products must satisfy. Technical requirements may include A-TARS allocated design constraints, functional capabilities, quality factors, performance, and other characteristics. Nontechnical requirements can include deadlines, budget, interfaces with other projects, processes and practices to be used, and other constraints. Requirements are allocated through the project's plans.
Q
Quality Assurance Plan. This represents the detailed plans for each project's AQ activities. In addition to the QA resources and schedules, it identifies the QA procedures and practices. This includes the products or processes to be reviewed or audited and how noncompliance issues are handled.
R
Risk Management Plan. This document describes the risk analysis and management processes that will be used. The current risks, their priority, and the planned mitigation strategies are included.
S
Status. This represents status that is reported to track progress (e.g., cost, schedule, quality, or technical progress). The type of status varies for each reporting activity.
Status Against the HS IT Strategic Plan. This represents the compilation and analysis of actual results against the HS IT Strategic Plan.
Strategic Analysis and Data. This represents the set of available data and analysis compiled during the Strategic IT Planning and Management Activities. That information is assumed to be retained and available as needed by other activities.
Strategic Directives. This represents higher-level guidance to the architecture and planning activities. This allows strategic adjustments, when necessary.
Strategic Foundations. This represents the purpose of the HS Agency or IT Division, as described by their mission, vision, and guiding principles.
Strategy Project Plan. This represents the collection of plans that are used to control the strategy project. This may include cost, schedule, effort, risk, and other elements.
Study Results. This information is a placeholder to denote the results of an architectural study. The results are summarized in study papers that may be referenced from the A-TARS. The type of results will differ based on the goals and conduct of the study.
Study Work Plan. This information is a placeholder for the plans governing the architectural studies. These plans relay the goals of the studies and ensure that the appropriate resources and controls are in place. These plans are a part of the overall Technical Architecture Work Plans and Direction.
Subgoals. A subgoal is a statement of what the HS Agency or IT Division expects to achieve over a specific period of time, generally 1 to 3 years, in order to move forward toward the organization's mission and vision. Subgoals flow logically from goals, and each subgoal can be linked to at least one of the higher-level goals.
Support Plans. This represents the set of plans for each project's support activities. This includes Configuration Management and Quality Assurance Plans, among others.
T
(HS Agency) Technical Architecture. This represents descriptions of the types of applications, platforms, and external entities; their interfaces and services; and the context within which the entities interoperate. This is the blueprint for the technology within the HS Agency. The Technical Architecture is the basis for selecting and implementing the infrastructure and the applications it supports. It is described in the HS Agency Technical Architecture Reference Set.
(HS Agency) Technical Architecture Work Plans and Direction. This represents the work-level plans and accompanying management direction necessary to establish and control the Technical Architecture activities. This plan includes by reference the applicable portions of any higher-level plans, such as the HS IT Strategic Plan. Requirements from those higher-level plans are allocated to the architecture activities and assumed to be levied through the Technical Architecture Work Plans and Direction, as necessary.
Technical Capability. This represents the capability of the IT Division and the HS Agency to deliver and use the needed IT technology efficiently and effectively.
U
V
W
Waiver or Design Approvals. This represents oversight by the architects for project-level IT decisions. This includes granting (or denying) waiver requests and formal review and approval of system designs. Engineering and management practices, also under the jurisdiction of the Architecture Team are also subject to review (e.g., guidelines published in the Technical Guidelines portion of the A-TARS).
Waiver or Design Requests. This represents requests by the IT projects for approval of architecture-related design and implementation decisions. These may include exceptions to a part of the Technical Architecture or notification of project technology choices when they must be coordinated with the architects.