- 2.16.1.1 Enterprise Life Cycle (ELC) Overview
- 2.16.1.2 Enterprise Life Cycle Framework
-
This subsection provides an overview of the Enterprise Life Cycle (ELC). This includes what the ELC is (characteristics and structure) and why the ELC is used (purpose and objectives).
-
The ELC is the approach used by IRS to manage and implement business change and information systems initiatives.
-
The ELC is appropriate for use by all (major, non-major, small-other) projects.
-
The ELC provides the direction, processes, tools, and assets necessary to accomplish business change in a consistent and repeatable manner.
-
The objectives of the ELC are to:
-
Enhance chances for successfully achieving the desired business change
-
Standardize the approach for managing and governing business change, and supporting information system projects and programs throughout IRS; and
-
Help ensure project and program success by reducing risk and ensuring compliance with applicable internal and external standards and mandates.
-
-
There are several reasons that IRS uses the ELC. First, the ELC is based on best practices of both government and industry. Using a documented life cycle based on these best practices enables IRS to follow repeatable processes that yield better results over the long run.
-
Second, by using the ELC, IRS can more easily comply with external requirements such as the Clinger-Cohen Act, the Government Performance and Results Act (GPRA), and the Federal Information and Security Management Act (FISMA).
-
Third, the IRS is implementing the recommendation made by the Treasury Inspector General for Tax Administration (TIGTA) to move to one life cycle that will accommodate all projects regardless of which IRS organization manages the project.
-
This document supports roles that enable the IRS to engineer and integrate systems; transition from the current Enterprise Architecture (EA) to the target EA; and otherwise manage changes to the enterprise.
-
The approval authorities for major, non-major and small-other projects are defined to assist the Program/Project Manager concerning the appropriate approval(s) necessary for the artifacts produced by the project. See Exhibit 2.16.1-2 for a table containing the proper approval authorities for artifacts produced by major projects. See Exhibit 2.16.1-3 for a table containing the proper approval authorities for artifacts produced by non-major and small-other projects.
-
Project personnel are responsible for coordinating with their managers to ensure they receive appropriate training to implement the guidelines in this IRM. Contact the ELCPMO training coordinator for current training information.
-
The ELC has three structural pieces:
-
Features
-
Process Assets
-
Enterprise Life Cycle Framework (ELC Framework)
-
-
Features - The ELC comprises many different features. Each ELC feature supports accomplishment of ELC objectives and represents an aspect of the ELC that projects must observe, comply with, or use. Milestones, reviews, and artifacts are examples of ELC features.
-
Process Assets - A Process Asset provides guidance, support, direction or assistance for how to accomplish the work. Examples of process assets include:
-
Directives
-
Procedures
-
Document Standards
-
Data Item Descriptions (DIDs) and Templates
-
Handbooks and Guides
-
Methodologies
-
Processes
-
Examples
Process assets are available in an on-line repository called the Process Asset Library or PAL ( http://elc.nc.no.irs.gov/). In addition, many ELC features are hot-linked to supporting process assets from the ELCPMO website ( http://bsm.web.irs.gov/ELCweb/).
-
-
Enterprise Life Cycle Framework - ELC features are organized in a pictorial representation called the Enterprise Life Cycle Framework. This framework illustrates how various ELC features relate to each other and where they come into play at various points in the life cycle of a project or program.
-
The Enterprise Life Cycle Framework (ELC Framework) is the structure for organizing and applying the process assets used to manage business change. The ELC Framework is composed of numerous structural elements; each serves a particular purpose and is implemented by one or more process assets. The framework organizes elements with similar purpose into six layers:
-
Management Layer
-
Governance Layer
-
System Life Cycle Layer
-
Solution Layer
-
Methodology Layer
-
Specialty Areas Layer
-
-
See Exhibit 2.16.1-1.
-
The purpose of the Management Layer is to plan, monitor, and control the work specified by the system life cycle. The assets associated with this layer address management functions performed by personnel who are part of or directly associated with the team or operational organization on a day-to-day basis. It includes the formation and management of projects and programs to support the life cycle, and, if necessary, the acquisition of outside services to perform the work.
-
Various types of projects are addressed and managed through the ELC. These basic types of projects are defined in the Management Layer.
-
These features constitute this layer:
-
Project Types
-
Acquisition Management
-
Program Management
-
Project Management
-
Service Management
-
-
A project is a group of tasks to accomplish a specific objective; with a beginning and ending date; that is planned, monitored, and measured; that follows a specific life cycle process; and that results in deliverables or end products. The ELC Framework addresses management of these types of projects:
-
Enterprise Planning Projects
-
Solution Development Projects
-
Solution Maintenance Projects
-
-
Enterprise Planning Projects - Enterprise planning projects provide the enterprise with an instrument through which to set future direction, specify unifying architecture, identify projects, set standards, and plan migration from current to future state. The scope of this type of project usually addresses multiple business areas and/or systems. Within the system life cycle, this type of project is usually initiated and concluded in the Vision and Strategy/Enterprise Architecture Phase.
-
Solution Development Projects - Solution development projects involve the design, development and/or acquisition, and deployment of solutions that support the enterprise vision and architecture. In the system life cycle, this type of project usually is initiated in the Project Initiation Phase and concluded in the System Deployment Phase. Note that a project with multiple releases may have one or more releases that are operational while development of the current release is in progress.
-
Solution Maintenance Projects - Solution maintenance projects maintain, enhance, or otherwise change an operational solution or solution component that is part of the Current Production Environment (CPE). The types of maintenance addressed are:
-
Planned Maintenance: a maintenance effort that is formally planned in advance as a project and executed with an appropriate degree of management and governance controls. A Planned Maintenance project may address multiple maintenance actions at the same time, will often originate from the Operations & Maintenance Phase, and may not need to execute all ELC stages
-
Emergency Maintenance: a maintenance effort that must be executed immediately to avoid data corruption or loss of service. These efforts must be conducted with the most prudent degree of oversight. Although this type of maintenance often needs to forego some of the rigor of a formal project, it should follow emergency procedures established to maximize the likelihood of successfully fixing the problem in an acceptable timeframe with minimum risk.
-
-
Acquisition management is the process of obtaining products or services through contractual agreements (e.g., Task Orders) with outside vendors or contractors. The process includes planning, directing, controlling, and administering such contracts throughout the life cycle of the acquisition.
-
The Acquisition Management component spans the entire life cycle from Vision & Strategy through Operations & Maintenance. However, for any specific project, the Acquisition Management feature is tailored to span only those portions (if any) of the life cycle that are supplied by outside contractors.
-
A program is a group of related projects managed in a coordinated way to obtain benefits and control not available from managing them individually. Programs may include elements of related work outside the scope of the discrete projects in a program. Because most business change initiatives are broad and complex, they are often structured as a set of related projects that are implemented over a period of time. Program management involves planning, directing, controlling, and administering these initiatives throughout the life cycle as a program. This focuses on management of the coordination between individual projects as well as guidance and direction for common aspects among the individual projects.
-
The Program Management feature spans the portion of the life cycle from program initiation through systems deployment. However, there may be periods in which some projects have been delivered and others are in-process or have not yet begun. As a result, Program Management does not terminate after systems deployment but partially overlaps Service Management.
-
Project management is the discipline applied to ensure orderly and controlled initiation, planning, execution, and close-out of a project.
-
Project management functions according to a Project Management Plan (PMP) in conjunction with the closely related disciplines of requirements management, quality management, configuration management, risk management, issue and action item management, and others to ensure project success.
-
The Project Management feature of the ELC Framework spans the portion of the life cycle that may be addressed by a formal project. This may include enterprise planning projects, solution development projects, and/or solution maintenance projects.
-
Service management involves planning, directing, controlling, and administering the support of a solution from the time it is deployed through the time it is retired. This includes management of services related to:
-
Operating and maintaining the technical infrastructure and automated solutions
-
Maintaining and enhancing the solutions
-
Helping users of the solutions
-
-
Simultaneously, within the time span of any system life cycle, there may be some portions of the solution that are operational and managed by Service Management, while other portions of the same initiative are in development and managed by Program/Project Management. In some cases, the Service Management role may be performed by an outside contractor for interim project releases and turned over to the IRS only after deployment of the final release.
-
Process assets associated with the Governance Layer address interventions by personnel or organizations that are not directly associated with the team performing the work on a day-to-day basis. These may include:
-
Executive interventions (e.g., to determine if a project still meets IRS objectives),
-
Specialty group interventions (e.g., System Engineering, Security, Privacy) to ensure conformance to certain requirements or standards,
-
Outside organization interventions (e.g., OMB, GAO) for purposes such as funding and auditing.
-
-
Governance activities are periodic and occur at specific points in the life cycle. These activities often take the form of reviews performed throughout the life cycle. The following features make up this layer:
-
Unified Work Request (UWR)
-
Project Chartering
-
OMB Compliance
-
Milestones
-
Milestone Reviews (including milestone readiness and exit reviews)
-
Certifications (including EA compliance certification and validation, and security certification and accreditation)
-
-
The Unified Work Request (UWR) is the single point of entry for requesting work from the IRS MITS organization. The UWR consolidates and replaces previous work request mechanisms such as the Change Request (CR) and the Request for Information Services (RIS). The UWR is completed before a project exists to document the details of what is requested. The UWR is then input to the IRS Capital Planning and Investment Control (CPIC) process to prioritize the request against all other requests and to allocate funds. If the UWR is funded, a project may then be chartered to perform the work. When the work is concluded, the UWR is updated with information on actual cost and effort.
-
Project chartering formally introduces the scope of work to be accomplished by a project and assigns management responsibility for the project at a high level. The charter lists the business processes, organizations, locations, requirements, systems, interfaces, tools, and target releases that the project must address, as derived from the IRS Enterprise Architecture (EA), which includes the information systems and business architectures.
-
Project chartering is included in the Governance Layer to illustrate and highlight its specific life cycle location. Information about project chartering is also found in the subsection on EA-related activities in the Enterprise Architecture Specialty Area. See IRM 2.16.1.2.6.3.
-
OMB Compliance entails satisfying OMB requirements for planning, budgeting, acquiring, and managing Federal capital assets. Two primary submissions must be made to OMB:
-
OMB Circular No. A-11, Part 7, Exhibit 53 (E53)
-
OMB Circular No. A-11, Part 7, Exhibit 300 (E300)
-
-
OMB Circular No. A-11, Part 7, Exhibit 53 - The E53 is the Agency IT Investment Portfolio. It is submitted to request funds from OMB as part of the normal budgeting cycle and updated as required. All projects requiring OMB funding are listed on the E53.
-
OMB Circular No. A-11, Part 7, Exhibit 300 - The E300 is a Capital Asset Plan and Business Case Summary. A business case is a formal justification for a project or program that outlines the benefits, costs, risks and alignment with organizational objectives. It is used to determine if the effort should receive funding. The IRS submits the E300 to OMB to obtain funding approval for new major projects ( See IRM 2.16.1.3.4.2 table of criteria). The E300 is updated periodically during the life of the project and is submitted after the solution is operational to demonstrate that planned benefits were realized.
-
OMB Compliance is included in the Governance Layer to illustrate and highlight the specific life cycle location for this governance item. Information about E300s and E53s is also found in the CPIC Specialty Area subsection. See IRM 2.16.1.2.6.8.
-
A milestone is an executive management decision point placed at a natural breakpoint in the life cycle; this usually occurs at the end of a life cycle phase. Milestones are points at which management requires updated cost, progress, and risk information to make project funding and "go/no-go" decisions for project continuation. The following table shows where milestones occur in the ELC:
Milestone Occurs at the End of: MS 0 Vision & Strategy/Enterprise Architecture Phase MS 1 Project Initiation Phase MS 2 Domain Architecture Phase MS 3 Preliminary Design Phase MS 4A Detailed Design Phase MS 4B System Development Phase MS 5 System Deployment Phase -
Note that through tailoring, phases may be modified and combined depending on the nature of the life cycle path used. In these cases, there is a single milestone at the end of the combined phase. For example, a single Milestone 3/4A instead of Milestone 3 and Milestone 4A.
-
Two types of reviews are related to milestones:
-
Milestone Readiness Review (MRR)
-
Milestone Exit Review (MER)
-
-
A Milestone Readiness Review is a project review performed by the reviewing organization to determine if the project is ready to begin the milestone exit process. Depending on the project category, the reviewing organization may be the ELCPMO, Business System Planning (BSP), Division Information Officer (DIO), or Program Management Office (PMO).
-
The purpose of the MRR is to eliminate last minute project delays and rework, and to streamline MER decisions made by the project's governance organization.
-
Existing information is gathered for the MRR. This includes project status, technical decision criteria from Life Cycle Stage Review (LCSR) results, and business criteria from the latest business case. This information is used to determine if the project has satisfied conditions outlined in the MRR checklist. If all conditions are satisfied, the reviewing organization will make a formal recommendation to the project's governance organization that the project is ready to begin the milestone exit process.
-
The following table depicts where MRRs are usually performed during the life cycle:
MRR for: Monitors Readiness to Exit: Vision & Strategy/Enterprise Architecture Phase MS 0 Project Initiation Phase MS 1 Domain Architecture Phase MS 2 Preliminary Design Phase MS 3 Detailed Design Phase MS 4A System Development Phase MS 4B System Deployment Phase MS 5 -
See IRM 2.16.1.3.5, Conducting Effective Reviews for further guidance on MRRs.
-
A Milestone Exit Review is a project review conducted at the end of a life cycle phase by the project's governance organization in compliance with IRS governance procedures. The purpose of the MER is to obtain executive approval for the project to continue on to the next phase, and if necessary, approve required funding.
-
The MER does not begin until the project's governance organization receives a formal recommendation from the reviewing organization that the MRR was successfully completed. See IRM 2.16.1.2.2.5.1, Milestone Readiness Reviews. Note that the MER is not meant to be a detailed or extensive technical review. It is an executive-level decision review based primarily on previously conducted reviews and recommendations.
-
See IRM 2.16.1.3.5, Conducting Effective Reviews for further guidance on MERs.
-
The following table shows the MERs usually conducted during the life cycle:
MER Approves Exit of Phase: Approves Progression to Phase: MS 0 Vision & Strategy/Enterprise Architecture Project Initiation MS 1 Project Initiation Domain Architecture MS 2 Domain Architecture Preliminary Design MS 3 Preliminary Design Detailed Design MS 4A Detailed Design System Development MS 4B System Development System Deployment MS 5 System Deployment Operations & Maintenance
-
Certifications occur at key points in the life cycle. They are technical evaluations resulting in a formal judgment as to whether the solution meets certain conditions. Certifications are included in the Governance Layer to illustrate and highlight the specific life cycle location of these important governance actions. Certifications are also discussed the ELC Specialty Areas. See IRM 2.16.1.2.6. The following certifications and related evaluations are included in the Governance Layer:
-
Enterprise Architecture Compliance Certification
-
Enterprise Architecture Compliance Validation
-
Security Certification and Accreditation Package
-
Privacy Package/Privacy Impact Assessment
-
-
Enterprise Architecture Compliance Certification is conducted to ensure that solution design conforms to the Enterprise Architecture (EA).
-
Projects are initially chartered to develop solutions that address business and technical components allocated from the Enterprise Architecture. As these projects progress through the life cycle, it is necessary to check at key points to ensure that the solutions are still in conformance with the higher-level design, standards, and intent of the EA.
-
EA Compliance Certification occurs at the end of the Logical Design Stage of the Preliminary Design Phase prior to MS 3. The certification verifies that the logical design complies with the EA.
-
EA Compliance Validation occurs at the end of the Physical Design Stage of the Detailed Design Phase prior to MS 4A. The evaluation verifies that the physical design and the final product comply with the EA.
-
Security and Privacy Certification and Accreditation ensure that a solution properly addresses security and privacy considerations and is authorized to operate with live data. The Department of the Treasury Directive, TD P 71-10, establishes Security Certification and Accreditation policy requiring a formal review (certification) and issuance of official declarations (accreditation) that all Sensitive But Unclassified (SBU) information systems or networks are approved to operate.
-
Certification is a technical evaluation process. It results in a judgement stating if a particular information system design or implementation (e.g., computer system, application or network design, and implementation) meets a pre-specified set of security requirements. Security Test and Evaluation (ST&E) of the system's security features determines if the required safeguards are in place and functioning as intended. To perform a more objective judgement, an independent reviewer (rather than a system developer) performs the certification.
-
Accreditation is the official management authorization for an information system/application to process SBU data in an operational environment. Accreditation is based on a comprehensive security evaluation of the information system's security documentation, addressing all aspects of security and privacy, including:
-
Administrative/Management Security
-
Communications Security
-
Information Security
-
Computer Security
-
Personnel Security
-
Physical Security
-
Contingency
-
Privacy
-
Compliance with federal laws and regulations
-
-
Accreditation is granted on the basis of recommendations made by the IRS's security office, and means that the IRS explicitly accepts the associated risks of system/application operation.
-
Security and Privacy Certification and Accreditation occurs during the Certification Stage of the System Development Phase prior to MS 4B with the system installed at all target sites, and is required before the system is allowed to process live data.
-
The System Life Cycle Layer is the core of the ELC Framework. All other layers are structured to support the System Life Cycle Layer. Process assets associated with this layer specify a standard progression and cycle of work performed over the life of a business change solution. This includes all work required to specify and develop and/or acquire the solution as well as work associated with operating and maintaining the completed solution until it is retired.
-
This layer does not include work involved with managing programs or projects that produce the solution.
-
This layer specifies what kind of work is performed but not how to do the work.
-
The following features are associated with this layer:
-
Perspectives
-
Stages
-
Phases
-
Paths
-
Operational capability
-
-
A perspective is a distinct dimension from which all life cycle work must be considered. Perspectives ensure that work performed and solutions produced reflect a holistic approach. The ELC Framework addresses the following perspectives:
-
Business Process
-
Organization
-
Location
-
Data
-
Application
-
Technology
-
-
Business Process Perspective - The business process perspective addresses what the enterprise does, how it does it, in what sequence, what rules it follows, and what results it obtains. Changes in the business perspective usually drive changes in all other perspectives. This ensures that the solution supports and enables the business.
-
Organization Perspective - The organization perspective deals with the people in the enterprise: their culture, their capabilities, their team structures, and their organizational units. It also addresses the support systems that make organizational change possible.
-
Location Perspective - The location perspective addresses where the enterprise does business in terms of both location types and specific physical facilities at a specific location. Locations may include customer and vendor sites as well as internal enterprise sites.
-
Data Perspective - The data perspective addresses the content, structure, relationships, and business data rules surrounding the information that the enterprise uses.
-
Application Perspective - The application perspective deals with the capabilities, structure, and user interface of software provided for the business users. Applications may be specific to the business of the enterprise, such as an order entry application, or general in nature, such as a word-processing program or an electronic spreadsheet.
-
Technology Perspective - The technology perspective addresses the hardware, system software, and communications components used to support the enterprise.
-
Perspectives have important uses throughout the life cycle. For example, they are used in initial project planning to help focus tailoring and to assess risk, during Domain Architecture to identify all relevant solution components, and during solution design to ensure that all aspects of the solutions are addressed. Additional guidance on Perspectives is found in the subsection on Using Perspectives. See IRM 2.16.1.3.2.
-
Phases are aggregations of one or more stages ( See IRM 2.16.1.2.3.3 for discussion of stages). These aggregations result in broad segments of work that encompass activities of similar scope, nature, and detail, and that provide natural breakpoints in the life cycle. Projects are managed within the bounds of phases. Each phase begins with a kickoff meeting and concludes with a milestone. This means that as the project is developing the solution, it should be stated that the project is is in a phase, not in a milestone. For example, the project is "in the Domain Architecture Phase" not "in Milestone 2" .
-
The following table identifies the phases of the system life cycle:
Phase General Nature of Work Stages Included Prior Milestone Concluding Milestone Vision & Strategy/Enterprise Architecture High level direction setting for the enterprise. (This is the only phase for enterprise planning projects.) -
Mission, Vision & Strategy
-
Enterprise Architecture
N/A MS 0 Project Initiation Startup of development projects. -
Project Initiation
MS 0 MS 1 Domain Architecture Specification of the operating concept, requirements, and structure of the solution. -
Business Solution Concept
-
Business Solution Architecture
MS 1 MS 2 Preliminary Design Preliminary design of all solution components. -
Application Requirements
-
Logical Design
MS 2 MS 3 Detailed Design Detailed design of solution components to a state from which they can be developed. -
Physical Design
MS 3 MS 4A System Development Coding, integration, testing, and certification of solutions. -
Development
-
Integration, Test and Evaluation
-
Certification
MS 4A MS 4B System Deployment Expanding availability of the solution to all target users. (Usually the last phase for development projects.) -
Deployment
MS 4B MS 5 Operations & Maintenance Ongoing management of operational systems. -
Operations & Maintenance
MS 5 System Retirement -
-
Stages represent the fundamental segments of work that define the system life cycle. The purpose of each stage is to evolve the solution to a new state or level of development. Stages account for the transformation of a high-level concept at the beginning of the life cycle into an operational solution at the end of the life cycle. Because solutions are managed within the bounds of stages, formal reviews of the solution occur at the end of many stages.
-
The life cycle is comprised of the following stages:
-
Mission, Vision and Strategy Stage
-
Enterprise Architecture Stage
-
Project Initiation Stage
-
Business Solution Concept Stage
-
Business Solution Architecture Stage
-
Application Requirements Stage
-
Logical Design Stage
-
Physical Design Stage
-
Development Stage
-
Integration, Test and Evaluation (IT&E) Stage
-
Certification Stage
-
Deployment Stage
-
Operations and Maintenance Stage
-
-
One or more related stages comprise a phase ( See IRM 2.16.1.2.3.2for discussion on phases).
-
The Mission, Vision and Strategy Stage is the first of two stages in the Vision and Strategy/Enterprise Architecture Phase. It is an enterprise-level stage that is performed, when needed, to set the direction for business change by developing future vision for a broad organizational area or by significantly updating an existing vision. State of the solution at the end of the Mission, Vision and Strategy Stage includes:
-
Scope of the enterprise defined in terms of business areas and/or systems to be addressed
-
Enterprise mission developed or clarified to include a statement of general purpose for why the organization exists
-
Future vision for the enterprise described from the perspective of business processes, organizations, locations, data, applications, and technology
-
Directional principles for each perspective; and
-
Future role of information technology in the business aligned with the new vision.
-
-
As an enterprise-level stage, Mission, Vision and Strategy addresses many business areas and/or systems, and is run as an enterprise planning project.
-
The Enterprise Architecture Stage is the second of two stages in the Vision and Strategy/Enterprise Architecture Phase. It is an enterprise-level stage that is performed, when needed, to provide the guiding structure for achieving the enterprise vision. This may entail developing a new architecture or making major revisions to current architecture. State of the solution at the end of the Enterprise Architecture Stage includes:
-
Target architecture specifying solution components and component relationships
-
Enterprise-level requirements
-
Intermediate architectures for incrementally achieving the target architecture and providing envisioned functionality over time
-
Identification of solution development projects for implementing the architecture; and
-
Enterprise standards to be observed by all projects.
-
-
As an enterprise-level stage, EA addresses many business areas and/or systems, and is run as an enterprise planning project.
Note:
The target IRS EA has already been defined. Any additional efforts occurring within this stage are to update and revise this architecture.
-
The Project Initiation Stage is the only stage in the Project Initiation Phase. Its purpose is to complete planning and preparation for a new solution development project. State of the solution at the end of the Project Initiation Stage includes:
-
Technical and business features of the EA allocated to the project
-
Completion of initial project planning; and
-
Assembly and orientation of the project team.
-
-
The Business Solution Concept Stage is the first of two stages in the Domain Architecture Phase. Its purpose is to describe the vision for the solution to be built. State of the solution at the end of the Business Solution Concept Stage includes:
-
Current state in terms of all ELC perspectives
-
Future direction for the business area specified
-
Conceptual specification of the solution selected to implement future direction; and
-
Development infrastructure sufficient to build the solution specified to a logical level.
-
-
To clarify solution state, documentation of the current state should only have enough detail to understand the current state, improve it, and plan for transition.
-
Future direction for the business area includes:
-
Specification of objectives and goals
-
User needs to be satisfied
-
Policies, principles, constraints, assumptions, and strategies
-
Description of the desired end state
-
Critical success factors; and
-
Critical business issues.
-
-
Conceptual specification of the solution selected to implement the future direction includes:
-
Pictures, narratives, and scenarios describing a system concept inclusive of all applicable ELC perspectives (i.e., process, organization, location, data, application, and technology)
-
Identification of potential current or commercially available assets that could be used as part of the solution
-
Identification of impacts on the current environment; and
-
Verification that the conceptual solution is consistent with and supports the high-level project solution concept.
-
-
The Business Solution Architecture Stage is the second of two stages in the Domain Architecture Phase. Its purpose is to specify the business system requirements and structure for a complete solution that implements the system concept and enables subsequent development of detailed software requirements. State of the solution at the end of the Business Solution Architecture Stage includes:
-
Specification of a complete set of business system requirements in conjunction with a set of detailed models that depict design of the future business system from all solution perspectives
-
System architecture structured to show all subsystem levels
-
Business scenarios illustrating how business will be conducted using all relevant aspects of the architecture
-
Initial definition of external interfaces
-
Selection of a commercial software package, if applicable
-
Functionality packaged into time-phased releases
-
Technical infrastructure for development specified to the physical level; and
-
Initial performance engineering model.
-
-
To further clarify solution state, a complete set of business system requirements includes:
-
Capability requirements
-
Business requirements including process, organization, location, and business performance requirements
-
Regulatory, contractual, and other programmatic requirements
-
Requirements for implementation of identified business rule sets
-
Information system requirements including functional, data, interface, information system and performance requirements
-
Operational requirements including information system management, and procedural requirements
-
Appropriate security control requirements, derived from controls defined in NIST 800-53a
-
Privacy requirements derived from the Privacy Reusable Program Level Requirements as approved by the Security Services & Privacy Executive Steering Committee
-
Technical infrastructure requirements
-
Establishment of requirements traceability to customer needs and the enterprise architecture; and
-
Plans completed for requirements validation and verification.
-
-
Designs of the future business system from all solution perspectives include:
-
Logical level business process model. These are definitions for external events and results that delimit process flows; major processes that are modeled from external events to results, that are decomposed to the lowest level of interest and relevance from a business perspective, and that are sufficient to accurately estimate scope and complexity of associated rule sets; subsequent rule harvesting, and any subsequent business process model refinement; identification of decision points and business rule sets associated with these business processes; and identification of system management and support processes.
-
Logical level organization model. This is a definition of roles, competencies, and work groups; organizational impact; specification of organizational interactions in terms of organization and decision-making structures; and staff planning.
-
Logical level location model. This is an identification of locations by type and geographic area; impact by location; assignment of processes to the locations where they will be performed; logical location specifications (i.e., facility requirements) created for each location.
-
Logical level technology model. This is an overview of technology types at all sites, including diagrams of site interconnections; detailed diagrams of individual pieces of technology and their interconnections at each site; detailed descriptions of each technology component, including requirements for capacity and reliability, service capabilities, and applicable standards; and detailed descriptions of each technical infrastructure interface.
-
Conceptual level data model. This is a definition of business entities and entity subtypes; specification of relationships between data entities including cardinality (or equivalent level of definition for object-oriented or other approaches); and distribution of data entities to processing sites (i.e., location and type of infrastructure component).
-
Conceptual level application model. This is an identification and definition of applications; definition and illustration of the relationship between applications; assignment of business processes to the applications that support them; and distribution of applications to processing sites (i.e., location and type of infrastructure component).
-
Security model. This is a high level explanation of the NIST SP 800-53a Controls applied to the application and description of the integration of security controls within the domain architecture. Drawings that describe the relationship of control mechanisms to the business system architecture are recommended.
-
-
A system architecture structured to show all subsystem levels includes:
-
System structure decomposed into identified subsystems and sub-subsystems
-
Business system requirements and business rules decomposed and unambiguously allocated to each defined level of the system structure
-
Identification and description of solution components
-
Interaction model that specifies interrelationships between components in all perspectives; and
-
Components allocated to the lowest levels of the architecture.
-
-
An initial performance engineering model includes:
-
Identification of time-critical functions
-
Identification of security-critical functions
-
Performance requirements
-
Workload estimates; and
-
Measurement objectives.
-
-
Initial definition of external interfaces includes:
-
Interface overview
-
Responsibilities for participating organizations
-
Interface requirements; and
-
Data structures transferred.
-
-
Physical level technical infrastructure for development and unit test includes:
-
Specific brands and model numbers to be acquired or used
-
Actual features and capacities
-
Physical layouts of all equipment, system software, and networks; and
-
Preparation of a Government Equipment List (GEL) for development and for unit testing.
-
-
The Application Requirements Stage is the first of two stages in the Preliminary Design Phase. Each project release (if more than one) will have a separate Application Requirements Stage. Its purpose is to develop a set of software requirements that enables the system architecture and to evolve the solution to a level allowing commencement of logical application (i.e., software) design. For clarity, completeness and specificity, application requirements may be fully represented as combinations of graphical and textual models linked to summary textual statements. State of the solution at the end of the Application Requirements Stage includes:
-
Domain architecture verified and updated, if necessary, to reflect any changes required due to implementation of the previous release (if not the first project release)
-
Logical design of business processes completed
-
Major functions performed by the application defined to a level sufficient to account for transformation of all data features processed by the function
-
Automated portions of each application function, business process, and business rule set identified
-
Data designed to a logical level
-
A database management system (DBMS) identified and, if applicable, selected
-
Application interface definitions for both external and internal interfaces developed to the conceptual level
-
Business rules harvested from all applicable sources
-
Application (i.e., software) requirements developed
-
Security and privacy concerns adequately addressed
-
Performance analyzed and updated, as necessary to reflect the impact of software requirements and the current state of the logical design
-
Technical infrastructure for development and testing on order; and
-
Technical infrastructure for the Enterprise Integration and Test Environment (EITE) specified to the physical level (if necessary).
-
-
To further clarify solution state, complete logical design of business processes includes:
-
Refinement and optimization of major business processes
-
Design of minor business processes to the logical level
-
Design of system management and support processes to the logical level
-
Identification of lowest-level decision points and rule sets; and
-
Analysis and definition of software parameter settings (if using packaged software).
-
-
Logical design of data includes:
-
Data analyzed and designed to a level sufficient to support business processes
-
Fully attributed and normalized data structure
-
Development of a data conversion strategy; and
-
Development of a data integration strategy.
-
-
Conceptual definition of application interface definitions includes:
-
Context diagrams developed for each application
-
Definition of external entities
-
Definition of interface boundary conditions
-
Data mapped from source system to target system; and
-
Interface requirements developed to the software level.
-
-
Harvested business rules include:
-
Identification of individual rules associated with each business rule set; and
-
Specification of business rules in conformance with defined terms and a fact model.
-
-
Application software requirements include:
-
Requirements statements reflecting the automated portions of the process design
-
Requirements that are consistent with and supportive of the business system requirements
-
User System Interface (USI) requirements and standards; and
-
Establishment of traceability of software requirements to business system requirements and to features of the logical process and data design.
-
-
Adequate consideration of security and privacy includes Security and Privacy packages updated (as necessary) to reflect the impact of software requirements and the current state of the logical design.
-
Performance analysis includes:
-
Updated business volumes, service levels, and process performance; and
-
Updated predictive models and benchmarks.
-
-
Physical level technical infrastructure for EITE includes:
-
Specific brands and model numbers to be acquired or used
-
Actual features and capacities
-
Physical layouts of all equipment, system software, and networks; and
-
Preparation of a Government Equipment List for EITE.
-
-
The Logical Design Stage is the second of two stages in the Preliminary Design Phase. Each project release (if more than one) will have a separate Logical Design Stage. Its purpose is to complete the solution design to a level sufficient to enable the software requirements and allow physical solution design to begin. State of the solution at the end of the Logical Design Stage includes:
-
Applications designed to the logical level
-
The user-system interface designed to the logical level
-
Interfaces designed to the logical level
-
Requirements managed to the logical level
-
Business rules model completed, including detailed specification of all business rules
-
Common services identified
-
Software architecture issues addressed
-
Logical design consistent with and in conformance with higher-level designs
-
Technical infrastructure for EITE on order (if necessary)
-
Security and privacy concerns adequately addressed
-
Performance analyzed and updated, as necessary, to reflect the impact of the current state of the logical design; and
-
Logical design parceled into increments or sub-releases, if appropriate. See IRM 2.16.1.3.3.1.4.
-
-
To further clarify solution state, logical design of applications includes:
-
Applications decomposed to the next level of modular structure (e.g., application subsystems)
-
Automated functionality assigned to each substructure
-
Definition of flow between application substructures; and
-
Development of preliminary application unit test plans.
-
-
Logical USI design includes:
-
An outline of User System Interface menu structure; and
-
Optional verification of USI design with a simulation prototype.
-
-
Logical interface design includes:
-
Identification and design of interfaces from application subsystems to external systems and IT services; and
-
Identification and design of interfaces between application subsystems and IT services.
-
-
Requirements managed to the logical level include:
-
Requirements allocated to appropriate components of the logical design, including all identified configuration items (CIs); and
-
Updated requirements traceability to the features of logical design.
-
-
Regarding completion of the business rules model: It is possible that application-level analysis in this stage will uncover further details associated with related business processes and rules, and provide further specificity to the business requirements to which they relate. However, discovery of new business requirements should be the exception.
-
Identification of common services includes:
-
IT services beyond those currently provided have been identified and defined
-
Identification and definition of system-wide common services beyond those currently provided; and
-
Identification and definition of application-level common services.
-
-
Addressing software architecture issues includes development of strategies and approaches for areas such as:
-
Proposed hardware and any constraints imposed
-
Proposed COTS and any constraints imposed
-
Operating system constraints
-
Multi-processing approach
-
Multi-programming approach
-
Data transmission approach (messaging or data interface)
-
Initialization
-
Resource monitoring/action
-
Recovery
-
Error processing
-
System management; and
-
Hours of operation (e.g., continuous operation or planned restarts).
-
-
Logical design consistency and conformance entails:
-
Logical design that is in compliance with the EA; and
-
Logical design that is consistent with and supportive of conceptual design of the data, application, technical infrastructure, business process, organizational, and location aspects of the solution.
-
-
Adequate consideration of security and privacy includes:
-
Appropriate security and privacy mechanisms derived from security requirements and incorporated in the logical design
-
Logical design mitigates risk in accordance with control guidance specified in NIST SP 800-53a
-
Logical design identifies all interfaces to common security and audit services used by the application
-
Logical design represents audit services in accordance with enterprise audit requirements
-
Development of Interconnection Security Agreements (ISA), as necessary
-
Development of a draft Information Technology Contingency Plan (ITCP), including disaster plans ( IRM 10.8.60, Information Technology (IT) Disaster Recovery Policy and Guidelines)
-
Remaining security risks are entered into the Item Tracking System (ITRAC) for tracking purposes; and
-
Security and Privacy Packages updated, as necessary, to reflect changes from the logical application design.
-
-
Performance analysis includes:
-
Updated business volumes and service levels
-
Updated predictive models; and
-
Updated benchmarks.
-
-
The Physical Design Stage is the only stage in the Detailed Design Phase and is performed for a functionality increment or for each component of a release. Its purpose is to complete solution design to its lowest level in a manner that implements the logical design and is sufficient to allow application programming and testing to begin. State of the solution at the end of the Physical Design Stage includes:
-
Requirements managed to the physical level
-
Relationships of physical-level applications, databases, and infrastructure relationships illustrated, and individual physical solution components appropriately designed to the most detailed level
-
Data designed to the physical level
-
Applications designed to the physical level
-
Production infrastructure designed to the physical level
-
External interfaces defined to the physical level and approved by all parties responsible for the interface
-
Physical design consistent with and in conformance with higher-level designs
-
Security and privacy concerns adequately addressed
-
Preliminary documentation and training needs addressed
-
Technical infrastructure for development and unit testing installed
-
Performance analyzed and updated to obtain required performance
-
Preparations made for database conversion and population
-
Test planning updated to reflect physical design; and
-
Physical design parceled into builds or drops, if appropriate ( See IRM 2.16.1.3.3.1.1 for additional information on builds and drops).
-
-
To further clarify solution state, requirements managed to a physical level include:
-
Requirements allocated to appropriate components of the physical design, including all identified configuration items; and
-
Updated requirements traceability.
-
-
Physical data design includes:
-
Physical database, sequential file, and object specifications showing exact data structure, layout, data relationships; and
-
Data dictionary.
-
-
Physical application design includes:
-
Definition of transactions and related processing
-
Decomposition of application subsystems into programs and IT services
-
Design of program flows and/or object structures
-
Detailed specifications sufficient to support coding and testing of all batch and interactive programs, application-level common services, IT services, and objects for all business and system management and support applications
-
Actual layouts for all USI windows; and
-
Actual layouts for all reports.
-
-
Physical production infrastructure design includes:
-
Overview diagram of the physical infrastructure showing the location of physical components by site and the interconnection of sites
-
Detailed physical infrastructure diagram for each site showing the location and interconnection of all infrastructure components
-
Detailed physical specifications for each component of the infrastructure, as installed
-
Preparation of a Production Government Equipment List (including extra units to be used as spares); and
-
Long lead time production infrastructure on order or in development.
-
-
Physical design consistency and conformance entails:
-
Physical design that complies with the EA; and
-
Physical design consistent with and supportive of logical design of the data, application, technical infrastructure, business process, organizational, and location aspects of the solution.
-
-
Adequate consideration of security and privacy includes:
-
Appropriate security and privacy mechanisms are derived from security requirements and are incorporated in the physical design
-
Security mechanisms are implemented using common services when feasible and local security mechanisms conform to approved standards
-
Physical design mitigates risk in accordance with control guidance specified in NIST SP 800-53a
-
Interconnection Security Agreements have been negotiated and approved
-
System audit plan maps audit functions to appropriate enterprise audit services
-
Remaining security risks are entered into ITRAC for tracking purposes
-
Security and Privacy Packages updated (as necessary) to reflect changes from the physical design.
-
-
Preliminary documentation and training needs include:
-
Identification of required documentation; and
-
Definition of learning modules for use in user training.
-
-
Installation of technical infrastructure for development and unit testing includes:
-
Installation, integration, and testing of technical infrastructure for development, for unit testing, and for a proof-of-technical-concept prototype.
-
-
Performance analysis includes:
-
Development of proof-of-technical concept prototype to validate technical performance and design feasibility
-
Updated business volumes and service levels
-
Updated predictive models; and
-
Updated benchmarks.
-
-
Preparation for database conversion and population includes:
-
Plan for data conversion developed
-
Plan for conversion testing developed
-
Conversion test materials prepared; and
-
Conversion software developed and tested.
-
-
Updated test planning includes:
-
Application unit test plans and related materials updated to reflect physical design
-
Integration test plans updated with integration strategies, test designs, and traceability of requirements to test sets and test cases
-
Security test plans updated with strategies, test designs, and traceability of requirements to test sets and test cases; and
-
Deployment tests updated to reflect management procedures, planned test composition, and requirements traceability verification.
-
-
The Development Stage is the first of three stages in the System Development Phase; it is performed for each solution component or for a functionality increment. Its purpose is to implement the physical design through actual construction and/or acquisition of all solution components. State of the solution at the end of the Development Stage includes:
-
Process perspective components of the solution developed
-
Organization perspective components of the solution developed
-
Location perspective components of the solution developed
-
Data perspective components of the solution developed
-
Application perspective components of the solution developed
-
Each component of the solution unit tested
-
Developed components consistent with design
-
Documentation completed
-
Planning for integration and system testing completed
-
Technical infrastructure for EITE installed (if necessary); and
-
All production technical infrastructure on order.
-
-
To further clarify solution state, process perspective components include:
-
Business processes documented in terms of pertinent directives and process descriptions
-
Work flow established and/or configured (if applicable); and
-
Manual procedures.
-
-
Organization perspective components include:
-
New roles and organization structures
-
Organizational change interventions; and
-
Training modules, including both instructor and student materials for user and operator training.
-
-
Location perspective components include locations constructed or retrofitted, as required to support the solution. If facility construction or remodeling is required, it may be necessary to accelerate this activity to an earlier portion of the life cycle to accommodate long lead times.
-
Data perspectives include:
-
Installed and configured (test) databases, files, and queues; and
-
Test data loaded in test databases.
-
-
Application perspective components include:
-
Installed and configured commercial software (if any)
-
All programs of the applications developed and unit tested (if applicable); and
-
Individual programs integrated into complete applications.
-
-
Components consistent with design include:
-
Developed components implement the approved physical design; and
-
Components remain compliant with the EA.
-
-
Documentation includes:
-
Initial user documentation; and
-
Initial operations documentation.
-
-
Unit testing includes:
-
Unit test materials, including test plans, test scripts and test data
-
Successfully executed unit tests; and
-
Test reports showing correction of all major defects.
-
-
The Integration, Test and Evaluation is the second of three stages in the System Development Phase. Each project release (if more than one) will have a separate Integration, Test and Evaluation Stage. Its purpose is to combine all individually developed components into a fully tested release. State of the solution at the end of the Integration, Test and Evaluation Stage includes:
-
All individually developed solution components integrated into a functionally complete project release
-
Security and privacy concerns adequately addressed
-
All applicable system tests successfully completed
-
System performance assessed and fine-tuned to optimize results; and
-
System ready for production site installation.
-
-
To further clarify solution state, a functionally complete release includes:
-
All components developed by the project integrated into a project release
-
Project release integrated with prior project releases, if necessary,
-
Project release integrated with legacy systems, as needed,
-
Project release integrated with systems external to the IRS, if necessary; and
-
Project release integrated with releases of other projects to form a program release, if necessary.
-
-
Adequate consideration of security and privacy includes:
-
Security and privacy requirements have been met by appropriate control mechanisms in the solution
-
System implements security via common services and approved mechanisms
-
System security functions according to the latest security design
-
Residual system risk is documented in the Security Risk Assessment; and
-
Security and Privacy Packages are updated (as necessary) to reflect the development.
-
-
Successful completion of system tests includes some or all of the following tests along with test completion reports, as tailored for the project:
-
System Integration Test (SIT)
-
System Acceptability Test (SAT)
-
Government Acceptance Test (GAT); and
-
Final Integration Test (FIT).
-
-
System ready for production site installation includes:
-
Updated Deployment Site Readiness Test (DSRT) Plan; and
-
Functional Configuration Audit (FCA) of the solution.
-
-
The Certification Stage is the third of three stages in the System Development Phase. Each project release (if more than one) will have a separate Certification Stage. Its purpose is to obtain certification of the release to process live data in the target environment. State of the solution at the end of the Certification Stage includes:
-
Solution installed at production sites; and
-
Solution certified for use with live data.
-
-
To further clarify solution state, a solution installed at production sites includes:
-
Production hardware, software, and infrastructure installed at all target sites
-
Databases installed, configured, and initialized
-
Release integrated at target sites
-
Transition gaps closed at target sites
-
Successful completion of Deployment Site Readiness Tests (DSRTs); and
-
Completion of a Physical Configuration Audit (PCA) of the solution.
-
-
A solution certified for use with live data includes:
-
Successful completion of Security, Test & Evaluation
-
Security Certification and Accreditation Package complete and the Security Assessment Report (SAR) accurately documents residual risk; and
-
Security and privacy risks to the application have been resolved or documented with approved Plan of Actions and Milestones in the Security Certification and Accreditation Package.
-
-
The Deployment Stage is the only stage in the System Deployment Phase. It is performed for each project release and is the last stage of a project. Its purpose is to put the solution into use by all users for the conduct of business.
Note:
Deployment may occur to all targeted users at once or may occur in stages.
-
State of the solution at the end of the Deployment Stage includes:
-
The business system is integral to conduct IRS business; and
-
The project or release has concluded.
-
-
To further clarify solution state (i.e., the system is the method to conduct IRS business):
-
Users trained
-
All transition gaps at user sites closed
-
Operations and Maintenance Personnel trained (as needed)
-
Operations and Maintenance transition gaps closed
-
Production database initialized with live data
-
Final performance evaluations completed
-
Initial Operational Capacity (IOC) obtained
-
Operations and maintenance of the system commenced (if necessary) to support live operations
-
All target users using the system
-
Full Operational Capability (FOC) obtained; and
-
Measurement system to support assessment of functional performance.
-
-
Conclusion of the project or release includes:
-
All pertinent project materials turned over to users and operations
-
Old system deactivated (if existing and appropriate)
-
Pertinent project materials archived
-
Project personnel reassigned (if necessary)
-
Contracts concluded (if any)
-
Project space reallocated (if needed); and
-
Operations and Maintenance team ready to take over O&M.
-
-
The Operations and Maintenance Stage is the only stage in the Operations and Maintenance Phase. Its purpose is to operate and maintain completed solutions or solution releases as part of ongoing business. State of the solution during the Operations and Maintenance Stage includes:
-
Systems and solutions operated to support daily business
-
Call center, help desk, or similar assistance provided
-
Fixes and modifications to operational solutions or releases made, as required
-
Disaster recovery implemented (exercise and maintenance of contingency and disaster plans); and
-
Solution retired at end of life.
-
-
To further clarify solution state, making fixes and modifications to operational solutions includes:
-
Immediate changes to fix critical problems made via Emergency Maintenance (when needed); and
-
Multiple non-critical changes accumulated and implemented as a new release of the solution via Planned Maintenance.
-
-
The ELC recognizes there are multiple ways to approach the solution to achieve the states defined by the ELC stages. To provide flexibility, the ELC supports multiple approaches called paths. A path is represented by a version of the ELC Framework that supports a unique technical or system engineering approach to accomplish life cycle work. Paths are like alternate roads; each cross different terrain, but all lead to the same destination. Projects may select one or more appropriate paths that provide the best fit for developing the solution.
-
The ELC Framework supports multiple paths that address various portions of the life cycle:
-
Two domain architecture paths address the Domain Architecture Phase
-
Four development paths address the Preliminary Design Phase, Detailed Design Phase, and the Development Stage of the System Development Phase; and
-
Two maintenance paths address solution maintenance in the Operations and Maintenance Phase.
-
-
The following subsections provide complete descriptions and explanations of all Domain Architecture and Development Paths. However, for any user who wishes to access graphical representations of these paths, they are available in the Enterprise Life Cycle (ELC) Guide, Version 3, via the Process Asset Library (PAL) website: http://elc.nc.no.irs.gov/
-
Domain Architecture Paths provide alternate approaches to the Domain Architecture Phase of the System Life Cycle. These paths provide different methods for specification of the architecture for the business system that will be built. The architecture is comprised of:
-
Individual system components to be developed and if necessary, integrated
-
Requirements allocated to each component
-
Specification of how components interact to satisfy the business vision; and
-
Organization of these components into a system structure (if necessary).
-
-
There are two Domain Architecture Paths:
-
Model-Based Architecture Path
-
Joint Architecture Design (JAD) Architecture Path
-
-
The Model-Based Architecture Path provides one approach for the development of domain architecture. The flexibility of this path makes it suitable for many types and sizes of projects. It also provides an architectural foundation appropriate for use with most development paths.
-
Characteristics of a Model-Based Architecture approach are:
-
Pre-defined business solution concept
-
Model-based design
-
Comprehensive requirements specification
-
System structuring
-
-
Pre-defined Business Solution Concept - A high-level business solution concept (providing the vision for the solution) is developed and agreed upon. This is one of the key drivers for development of business system requirements and models.
-
Model-Based Design - Architectural design of the solution is based upon a set of models that represent the solution from all applicable perspectives. These models may be diagrammatic representations, charts, matrices, textual descriptions, or any combination of these. The models are updated; they are meant to evolve as the solution evolves. The models identify and define the perspective's solution components and their interrelationships. Typical models may include:
-
Business Process Model to illustrate how business is conducted
-
Organization Model to illustrate interactions within the organization
-
Location Model to illustrate the nature and relationships between various places of business
-
Application Model to illustrate interactions between solution applications
-
Data Model to illustrate relationships between various types of supporting data
-
Technology Model to illustrate how technology components of the solution are interconnected
-
System Engineering Model to illustrate levels of structure within the system that will be built
-
Architecture Interaction Model to illustrate the interrelationships between solution components from ELC perspectives (i.e., business process, organization, location, data, application, and technology); and
-
Initial Business Rule Model to establish the guidelines by which business is conducted.
-
-
Comprehensive Requirements Specification - A comprehensive set of business system requirements is developed and approved. These include functional, operational, programmatic, and other types of requirements. Although these requirements are not meant to be static and may be further decomposed or refined in later phases of the life cycle, they should be relatively stable and form a solid foundation for designing/developing or procuring the solution.
-
The relationship between requirements and models may be flexibly addressed depending on the nature of the project. In many cases, requirements and models may be developed simultaneously, each informing the other in an iterative manner. In other cases, requirements may be developed first and used to drive the design of models. In still other cases, models may be designed and then used to distill the underlying requirements.
-
System Structuring - Large, complex systems have many layers of internal structure in the form of multiple levels of subsystems and sub-subsystems. In these cases, the model-based design approach assigns solution components from each model along with related requirements to each level of architectural structure as needed to completely define the system architecture. Note that if the system has a flat structure, the models and requirements alone sufficiently specify the architecture and no allocation to system structure is necessary.
-
Management and governance considerations for this path include the absence of an LCSR for the Business System Concept Stage, since at this point in the life cycle, the Business System Concept Report (BSCR) is the only major solution artifact. However, a Customer Technical Review (CTR) of the BSCR is performed and formal approval and acceptance of the BSCR is required prior to commencing the Business Solution Architecture Stage.
-
The JAD Architecture Path provides high-level architectural guidance to support logical design as opposed to detailed specification of concept, requirements and architecture. The following are characteristics of a JAD Architecture approach:
-
High-level architectural guidance
-
Full-time stakeholder involvement
-
Facilitated sessions
-
Iterative architecture design
-
Time-boxing
-
-
High-level Architectural Guidance - Only high-level representations are developed. These are meant to provide guidance and expectations so that the development team proceeds in the correct direction.
-
Full-time Stakeholder Involvement - Key system stakeholders representing both business and technical functions fully participate in the architecture development effort to ensure that directional guidance is both accurate and sufficient. These stakeholders are empowered to make project and architectural decisions.
-
Facilitated Sessions - Development of architecture occurs in one or more facilitated, interactive sessions with all stakeholders in the room to foster consensus and common understanding.
-
Interactive Architecture Design - The concept, requirements, and architecture are developed simultaneously and in multiple iterations as opposed to sequentially.
-
Time Boxing - Architecture development is often time-boxed with an agreement to pass the architecture to the development team after a set period of time as opposed to leaving completion unbounded. This helps avoid analysis-paralysis as well as situations where there is not common agreement as to what should be done.
-
Management and governance considerations for this path include the combination of the Business System Concept and Business Solution Architecture Stages, since concept, requirements, and architecture are highly simplified and directional in nature rather than prescriptive. JAD also capitalizes on the fact that these aspects of Domain Architecture are developed quickly in a workshop setting. Therefore, a single life cycle stage review at the end of the combined Business Solution Concept and Business Solution Architecture Stage is sufficient.
-
Development paths incorporate specific technical approaches for design and development of the solution. They include the portion of the life cycle encompassing all life cycle stages from the Application Requirements Stage through the Development Stage.
-
Development paths address design and development of solution components. If the solution comprises more than one component, multiple development paths may be used as appropriate. If a project release contains only a single component, then the path may apply to the entire release. If the project has only a single release, then the development path applies to the entire project.
-
The ELC Framework addresses the following development paths:
-
Waterfall path
-
Commercial-Off-the-Shelf Solution (COTS) Path
-
Rapid Application Development (RAD) Path
-
Iterative Custom Path
-
-
A waterfall development approach is distinguished by sequential development of a solution with frequent reviews and formal approvals required before continuation of work. These reviews and approvals occur at multiple points in the life cycle. The following are characteristics of a waterfall development approach:
-
Sequential Development
-
Evolving Teams
-
Formal Documentation
-
Formal Approvals
-
-
Sequential Development - A waterfall approach provides for serial solution design and development. Solution design evolves through a planned progression of successive levels from logical design to development. Solution components are then developed.
-
Evolving Teams - As the project life cycle progresses, the nature of the project team evolves to match the nature of activities performed. Early in the life cycle, architects have a prominent role. As the life cycle progresses into design, various types of analyst and designer roles dominate the activities. After physical design, programmer or developer roles dominate, followed by the testers.
-
Formal Documentation - At each stage of the solution, formal documentation is prepared and the solution may undergo formal review (i.e., in an LCSR). Detailed documentation provides evidence of completion during reviews and supports transition from one role to another as they evolve from phase to phase.
-
Formal Approvals - After each review, the work completed is approved. Subsequent work does not continue until the work done in the prior stage(s) is approved.
-
The Model-Based Architecture Path is typically used in conjunction with the Waterfall Development Path.
-
The COTS path is designed to capitalize on the benefits of a pre-existing solution. This may be a software package, a suite of integrated packages, or infrastructure components (e.g., servers, workstations). Activities in the COTS Path differ from the waterfall path. COTS is oriented toward selection and configuration of the pre-existing solution. The following are characteristics of a COTS development approach:
-
Solution Selection
-
Solution Configuration
-
Solution Lab
-
Identification of Solution Extensions
-
-
Solution Selection - Solution selection involves a full acquisition process. This includes activities to identify and pre-screen software packages or infrastructure components, conduct a formal Request for Proposal (RFP) or Request for Solution (RFS) process, document selection results in a Product Evaluation and Selection (PES) Report, and completion of contracting and legal requirements for obtaining the selected solution.
-
Solution Configuration - After acquisition, the solution is brought in-house and configured. Solution configuration involves choosing desired settings for each of the provided software options. Similar configuration may be needed for infrastructure components.
-
Solution Lab - For large, integrated suites of software, configuration is often conducted in a solution lab in order to get the package to function as desired. The solution lab is a team of users, process analysts, and technical personnel who work together to determine how best to configure the package to support the business process and related business rules and requirements. Since a software package developed for commercial use seldom conforms completely to IRS operations, implementation of a COTS package generally requires changing business process and rules to conform to package-imposed restrictions or the adoption of package-provided processes or business rules. A lab environment may also be used to conduct proof-of-technical concept prototype for infrastructure components.
-
Identification of Solution Extensions - The lab process identifies the need for extensions to standard solution functionality. These may include modifications implemented via user exits provided by the solution and custom interfaces to existing applications. Note that actual development of extensions may be handled as separate solution components and may follow separate paths. As a general practice, to protect warranties and ensure the ability to implement upgrades, invasive modification of COTS solutions should be avoided.
-
Management and governance considerations for this path include:
-
Application Requirements, Logical Design and Physical Design Stages are combined to reflect that work performed is oriented toward configuration and parameter setting for pre-existing software as opposed to software design. Therefore, separate LCSRs for preliminary and detailed design are not needed.
-
Preliminary and Detailed Design Phases are combined into a single phase concluding with a combined milestone: MS3/4A. Because logical and physical design are not separated, separate phases and milestone exits are not needed.
-
Modification of requirements for and placement of EA Compliance Certification and Validation may be required since the software application and its database already exist and have an inherent logical and physical design. These designs are not changeable, however, it may be necessary to modify the EA to reflect the application and data structure of the COTS package.
-
Documentation requirements may be modified to incorporate pre-existing vendor documentation.
-
-
If customization is incorporated into the COTS path, it may be necessary to split the Preliminary Design Phase and the Detailed Design Phase to accommodate this custom development work.
-
The Model-Based Architecture Path is typically used in conjunction with the COTS Development Path.
-
The RAD Path is a highly accelerated spiral development approach used to produce small, standalone solutions or solution components on existing infrastructure in a short time frame. Spiral development is a " try and see" approach that employs prototyping with successive rounds of requirements discovery, design, and development until the solution is complete. Prototyping produces a trial version of model of the system that is quickly developed and successively modified. The RAD Path capitalizes on the small, primarily stand-alone nature of the solution and a high performance team working in a high productivity environment.
-
The following are characteristics of a RAD development approach:
-
High-Level Direction
-
Requirements Discovery
-
Prototyping
-
Spiral Development
-
High Performance Teams
-
Limited Documentation
-
Time-box Management
-
-
High-Level Direction - With the RAD Path, activities in Domain Architecture are only meant to produce high-level guiding direction for the team. This is the JAD process. During JAD, a team representing all key stakeholders works together in facilitated sessions to produce a guiding concept and directional requirements. This provides bounds for the development effort, identifies objectives and constraints, and gets the team started in the right direction.
-
Requirements Discovery - Sometimes users do not know what they want until they see it and their concept of what they want may evolve as the solution evolves. Requirements discovery is part of the spiral development and accommodates a "moving target" approach by allowing requirements to emerge and evolve as the solution is built iteratively.
-
Prototyping - Prototyping is the process of developing an early version of a solution. Prototypes allow users to see the solution early and determine if it meets their needs. Prototypes also help technical personnel analyze solution feasibility. RAD primarily employs limited function prototypes. A limited function prototype provides an early subset of the actual solution. It is a persistent piece of code that evolves into the final solution. Limited function prototyping is the key enabler of spiral development and must be supported by advanced prototyping tools. These tools can assist in rapidly designing solutions and may automatically convert designs to code.
-
Spiral Development - This is a " try and see" approach to design and development. A trial solution is quickly designed and developed based on known (but not necessarily finalized) requirements and direction. The result is provided to users for their review and feedback, which may result in changed or additional requirements - this is the requirements discovery process. Based on a the refined set of requirements, the prototype design is updated. The process of rapid design, prototyping, solution analysis, and requirements discovery repeats, each time coming closer to the final solution - hence the term "spiral development. "
-
High Performance Teams - High performance teams are static and consist of a combination of full time users and technical case workers, and they use a "case worker" approach to increase productivity. Case workers are individuals who fill many of the functions required during the life cycle. For example, instead of having multiple teams members, one case worker may help discover requirements, design the solution, develop the prototype, and test the results. This approach eliminates handoffs and reduces the need for formal documentation.
-
Limited Documentation - Only minimal formal documentation is produced during the RAD process; there are several reasons. First, the accelerated nature of this path does not allow for creation of formal documentation during the design and development process. Further, the use of case workers reduces the need for formal documentation. And, due to the spiral development process, design is not complete until the solution is developed so there little to document. Finally, because there are not interim stage reviews, there is no need to document for approval purposes. As-built documentation may be produced after the fact to support ongoing operations.
-
Time-box Management - A time-box is a set period of time in which an activity is performed; it concludes at the deadline even if it is not completed. Time-box management achieves accelerated results, however, functionality may be sacrificed in the interest of time. Time-boxes are usually established for JAD and RAD activities. When the time-box period is over for a JAD, the project moves to a RAD with whatever direction is completed. When the time-box period is over for a RAD, the decision to deploy the latest RAD solution is made based on whatever functionality is completed. (Any foregone functionality may be developed and deployed in a later release.)
-
The JAD Architecture Path is typically used in conjunction with the RAD Development Path.
-
Management and governance considerations for this path include:
-
Application Requirements, Logical Design, Physical Design, and Development Stages are combined into a single stage. This reflects the spiral development approach performed by a high performance team. Since there is no distinct separation of requirements discovery, design, and development, only a single Life Cycle Stage Review is possible.
-
Preliminary and Detailed Design Phases are combined into a single phase concluding with a combined milestone: MS3/4A. Because logical and physical design are not separated, separate phases and milestone exits are not needed. Note that the Development Stage of the System Development Phase is also accelerated during this combined phase.
-
Postponement of the EA Compliance Certification is necessary since there is no distinct completion point for logical design. Also, logical design compliance certification must wait until physical design is complete. A single certification jointly addressing logical and physical design must suffice. In addition, this single certification cannot occur until development is complete.
-
RAD may be performed under a fixed-price contract, but it is not possible to issue the contract only for development based on an approved physical design. Because all design and development work are concurrent, a fixed-price contract would need to cover all design and development work.
-
-
The Iterative Custom Path provides a cyclical development approach that addresses an increasing portion of the solution with each cycle. This is sometimes referred to as an expanding spiral. The following are characteristics of an Iterative Custom development approach:
-
Solidified logical design
-
Concurrent physical design and development
-
Use of prototyping
-
-
Solidified Logical Design - The Iterative Custom approach is based on an approved logical design for the entire solution (component or release). This is similar to a waterfall approach but different than RAD, which does not produce an up-front logical design. The logical design may be broken into multiple prototyping sets.
-
Concurrent Physical Design and Development - Physical design and development are not sequential but are performed concurrently and iteratively with side-by-side participation of users and developers.
-
Use of Prototyping - Prototyping is used for detailed design and development of each set until the prototype comprises the entire logical design. This approach is used to accelerate completion of implementation.
-
Management and governance considerations for this path include:
-
Physical Design and Development Stages are combined because the work is performed using an iterative approach where physical design and development occur concurrently. Only a single life cycle stage review may be conducted at the end of the combined stage. Note that development work occurs prior to MS 4A.
-
EA Compliance Validation is postponed until development is complete since physical design and development are concurrent.
-
Fixed price bid for development based upon approved physical design is not possible with this path since physical design and development are concurrent.
-
-
The Model-Based Architecture Path is typically used in conjunction with the Iterative Custom Development Path.
-
Solution maintenance involves making changes to an existing, operational solution or release of a system. The ELC Framework addresses the following maintenance paths:
-
Planned Maintenance Path
-
Emergency Maintenance Path
-
-
The Planned Maintenance Path is a path for planned system maintenance of a non-emergency nature. This path manages change in an organized manner, minimizes the disruption caused by frequent system changes, and increases the efficiency and effectiveness of the system change process.
-
Service Management originates Planned Maintenance projects under the guidance of Operations and Maintenance Methodology or processes. Note that the maintenance project is managed under control of the Project Management component, while the existing system release is simultaneously managed under Service Management. When the project concludes, the new maintenance release transitions to the Operations and Maintenance Stage under control of Service Management. The following approaches characterize this path:
-
Concurrent maintenance actions
-
Technical development path basis
-
Selected stages and phases
-
Modification of existing documentation
-
-
Concurrent Maintenance Actions - Planned Maintenance typically addresses numerous system changes and simultaneously implements all of the changes as a new version (or release) of the system. This approach has advantages including improved management of the maintenance function, reduced amount of retraining, and potential improvement of coding efficiency and effectiveness. Under Planned Maintenance, changes may include combinations of different types of maintenance, including:
-
Corrective maintenance (e.g., fix errors, bugs, defects; replace equipment)
-
Adaptive maintenance (e.g., conform to changed environment -- for example, an operating system upgrade or change of database management system)
-
Preventive maintenance (prevent a problem before it occurs)
-
Perfective maintenance (e.g., upgrades or enhancements to system functionality and/or performance). Changes under Planned Maintenance include permanent repairs to replace temporary patches implemented by Emergency Maintenance.
-
-
Technical Development Approach Basis - Planned Maintenance is not a single, unique path (as are the development paths). Work performed in the Planned Maintenance Path is similar to work performed in development paths. Due to this similarity, Planned Maintenance projects may follow the most appropriate technical development approach given the nature of the changes being made. For example, a project making changes to custom code might select the Waterfall Path as the primary basis for proceeding. Or a project that needs to reconfigure a software package may select the COTS path. Criteria for choosing an appropriate development approach for Planned Maintenance are the same as for selecting a development path. Because of these similarities, the Planned Maintenance path selected for a project should be referred to as "Waterfall-Based Planned Maintenance" or "COTS-Based Planned Maintenance" .
-
Selected Stages and Phases - The Planned Maintenance Path is illustrated as a feedback loop that has multiple potential entry points into the life cycle. During the planning process, the appropriate entry point is determined based upon the earliest baseline that will be affected by the maintenance. For example, if the Functional Baseline will be affected (e.g., because new requirements must be specified), the project should begin in the Business Solution Architecture Stage of the Domain Architecture Phase. If the logical design portion of the Allocated Baseline will be affected, the Planned Maintenance project should begin in the Preliminary Design Phase. If the physical design portion of the Allocated Baseline will be affected, the Planned Maintenance project should begin in the Detailed Design Phase. If the Product Baseline will be altered by making changes directly to code but neither the logical or physical design are affected, the Planned Maintenance project may begin in the System Development Phase.
-
Modification of Existing Documentation - Planned Maintenance modifies an existing system. Unlike a new development project that must create new documentation, Planned Maintenance projects may update documentation that already exists to reflect the maintenance changes. If existing documentation is inadequate or non-existent, new documentation will be created in the currently approved ELC format
-
Management and governance considerations for this path include:
-
Planned Maintenance is managed as a formal project even though a formal Project Initiation Phase is not required. Appropriate project planning must be performed at the outset regardless of where the project commences the life cycle.
-
Reviews and other governance considerations are determined based on the nature of the maintenance performed and the technical development approach followed. As with new development, reviews and governance should be implemented in a manner that is workable given the size, cost, schedule, and risk of the project. For example, a Planned Maintenance project that must enter the life cycle during Domain Architecture may not need to have a separate MS 2 exit.
-
-
The Emergency Maintenance Path is an approach to correct critical defects or faults in an operational system that must be repaired immediately to prevent system corruption and/or loss of service. The Emergency Maintenance Path is executed during the Operations and Maintenance Stage and is guided by the Operations and Maintenance Methodology under the control of Service Management. The following approaches characterize this path:
-
Expediency-Driven Fixes
-
After-the-Fact Documentation
-
-
Expediency-Driven Fixes - In emergency situations, primary emphasis is on restoring the system quickly. This may involve making changes directly to code, implementing temporary patches until more permanent fixes can be made, or other practices that are necessary given the nature of the situation.
-
After-the-Fact Documentation - Given the urgency of emergency maintenance situations, documentation may be delayed until after the system has been satisfactorily restored. However, existing documentation must be updated to reflect any changes made.
-
Management and governance considerations for this path include:
-
Application of emergency procedures developed specifically to support and enable problem resolution in an acceptable timeframe while maintaining a prudent degree of oversight and management control; and
-
A UWR should be initiated after the fact to record the work that was performed.
-
-
Achievement of operational capability marks the passage of a system from a solution in development to a solution used by the IRS to conduct business. Two levels of operational capability are recognized:
-
Initial Operational Capability, and
-
Full Operational Capability.
-
-
Initial Operational Capability (IOC) - IOC occurs in the System Development Phase and marks the first live usage of the system by the first group of users to receive the system.
-
Full Operational Capability (FOC) - FOC marks complete usage of the system by all targeted users. This occurs in Milestone 5 and signals the end of deployment activities.
-
Prior to IOC, project activities are primarily development and test-related. Beginning with IOC, operations and maintenance activities must commence to support the first group of system users (even though the Operations and Maintenance Phase has not started). Between IOC and FOC, project activities include a mix of deployment and operations and maintenance activities. Subsequent to FOC, project activities are solely operations and maintenance. Finally, if the system is deployed to all target users simultaneously instead of incrementally, IOC and FOC may be concurrent.
-
The solution is the embodiment and end result of all the changes made to the business and related technology. It comprises a set of artifacts that satisfy the goals of the business change initiative. The purpose of assets associated with the Solution Layer is to manage the solution as it is produced. This includes providing standards for consistent solution specification, formal review of solution content, testing the solution, and establishing configuration management baselines for control of change. This layer provides control over artifacts and may be produced by multiple internal and external developers using different methodologies.
-
The following elements constitute this layer:
-
Artifacts
-
Data Item Descriptions
-
Customer Technical Reviews
-
Life Cycle Stage Reviews
-
Baselines
-
Tests
-
Configuration Management Audits
-