Process Step 4 — Define the Conceptual Solution Architecture

Step Description and Purpose

The Define the Conceptual Solution Architecture process step includes activities that help the architect define the conceptual solution architecture for the target state. Although this guidance is for segment architecture, a complete segment architecture should include a conceptual depiction of the target systems and services architecture that is consistent with the existing agency enterprise architecture. Hence, the term conceptual solution architecture defines the segment systems and services (e.g., business and information exchange) including the supporting technical and service components used to automate and improve business functions within a segment. The scope of the conceptual solution architecture includes service components, data sources, systems, and the interfaces between them (See example in Figure 1). Segment services may include business services, enterprise services, and other technical service components. Note that the processes associated with the business functions may be described in detail within the business and data architectures defined in process step 3. The conceptual solution architecture also describes the segment boundaries defined by interfaces with external customers, systems, services, and organizations. As such, the conceptual solution architecture provides an integrated view of the combined systems, service, and technology architectures.

As a general rule, the specification of technical and service components should, in principle, be vendor-agnostic within the conceptual solution architecture. As such, the conceptual solution architecture is not specific or unique to a particular solution or application architecture. The key exceptions to this rule are where existing as-is systems, standard commercial of the shelf (COTS) solutions, and solutions offered by SmartBUY and enterprise license agreements (ELAs) are to be included as part of the target state. This integrated view will greatly improve the hand-off to solution architects by providing a means for linking systems to services and their supporting technology components. 

Figure 1 :  Example of conceptual solution architecture system interface diagram

This process step includes activities and tasks related to information gathering about and assessment of the as-is segment systems and services to determine the business value and overall alignment of the as-is systems and services to the performance, business and information requirements developed in the prior process steps. Based on the analysis of the as-is systems and services, the requirements for the target conceptual solution architecture are defined so the architect can determine the target systems and services required to enable the segment's performance, business, and data architectures. In defining the target state conceptual solution architecture, the architect is encouraged to select reusable service components, including cross-agency initiatives defined in the Federal Transition Framework (FTF).

Once the target conceptual solution architecture is defined, the dependencies, constraints, risks, and issues associated with the transition are analyzed to identify alternatives to be considered. This analysis results in a set of recommendations that will be carried forward into the subsequent process step for developing the final segment blueprint.

Note that suggested analytical techniques are included for activities within the methodology to better define what is core for a complete segment architecture in the form of descriptive (not prescriptive) guidance on how to accomplish the analysis. The suggested analytical techniques provide guidance as to what outputs are core for defining a complete segment architecture.

Moreover, the key data analytical techniques suggested will serve to build up the agency-specific instantiation of the DRM Abstract Model for data description, data context, and data sharing attributes.   Information seeded in process step 3 is summarized in process step 4 and reported to OMB in the segment architecture template, providing OMB with instantiation for key DRM attributes. Specifically, process step 4.2 provides a summary of data reuse within the segment in the reuse summary and data reuse artifacts. The reused information system list in the reuse summary artifact provides data context information about data assets and data stewards. The exchange package definition and reuse section in the data reuse artifact provides data sharing information about exchange packages linked to data context information about data stewards and data assets. Information exchange package reuse information in the data reuse artifacts provides data description information about entities linked to data context information about data stewards.

Step Outcome

The outcome of this step is the conceptual solution architecture that supports the target performance, business and data architectures developed in the preceding process steps, along with the advantages and disadvantages of alternative strategies for transitioning from the as-is state to the target state.

Suggested Analytical Techniques

Suggested analytical techniques are provided corresponding to each activity in this process step. Certain FSAM outputs are classified as 'core' to identify the architectural information necessary to specify a complete segment architecture. For each FSAM output, the table includes examples of analytical techniques associated with the output(s). These analytical techniques provide descriptive (not prescriptive) guidance on how to perform the analysis and capture the architectural information for each output. Agencies may employ other templates or artifacts that provide the equivalent level of information and analysis.  

Step At-a-Glance

Step 4 At-a-Glance

	Process Step 4 Activities
	Assess systems and technology environment for alignment with performance, business, and information requirements	Define the target conceptual solution architecture	Identify and analyze system and service transition dependencies	Validate and communicate the conceptual solution architecture
Who Participates in This Activity?	Segment architect Core team	Segment architect Core team	Segment architect Core team	Executive sponsor Core team Segment architect
What Are the Inputs to This Activity?	Process step 1 outputs Process step 2 outputs Process step 3 outputs EA knowledge base	Federal Transition Framework (FTF) As-is system and services scoring As-Is Conceptual Solution Architecture	Target Conceptual Solution Architecture Target Service Component Architecture Target Technical Architecture Integrated service component and technology model	Target Conceptual Solution Architecture Target Service Component Architecture Target Technical Architecture Integrated service component and technology model Transition recommendation profile Transition recommendation sequencing diagram Reuse Summary Data Reuse Recommendation Sequencing Milestones
What are the Outputs from This Activity?	As-is system and services scoring As-Is Conceptual Solution Architecture	Target Conceptual Solution Architecture Target Service Component Architecture Target Technical Architecture Integrated service component and technology model	Transition recommendation profile Transition recommendation sequencing diagram Reuse Summary Data Reuse Recommendation Sequencing Milestones	Conceptual Solution Architecture Presentation
Which Stakeholders / Customers Will Use the Outputs from This Activity?	Core team Segment architect System owner	Core team Segment architect System owner	Executive sponsor Core team Business owners Segment architect Solution architect	Leadership Executive sponsor Core team Business owners Segment architect
What are the Associated FEA Profiles?	Security and Privacy Geospatial Records Management	Security and Privacy Geospatial Records Management	Security and Privacy Geospatial Records Management	None
Touch Points to NIST 800-39	Security controls should be reflected in the FEA solution architectures
Touch Points to FTF		Determine re-usable cross-agency initiatives
Touch Points to PGFSOA		Identify the opportunities for sharing and reuse of services
Considerations for Enterprise Services		Target systems considerations for enterprise services
Considerations for Business Services		Target systems considerations for business services
What is the Relative Complexity of This Activity?

 
Activity Details

Activity 4.1:  Assess systems and technology environment for alignment with performance, business, and information requirements

Activity Description:

This activity builds upon the analysis of the segment's business and information environment performed in process step 3 and is within the scope identified in process step 2. The focus of this activity is to collect and analyze information pertaining to the as-is use of systems and services and how well those systems and services support the performance, business, and data architectures. This activity includes assessing the segment's systems and services across several dimensions, including business, data and technology alignment; service management; and maturity. This activity also includes a high-level assessment of existing system interfaces within the segment and the data that is exchanged between those systems.

By performing an analysis of existing systems and services against the performance, business, and data requirements for the target state, the architect should be able to answer key questions related to the target conceptual solution architecture including:

• How are the systems and services in the segment performing to deliver business value for the costs associated with operating and maintaining them?
• What is the relationship between the existing systems, services and technologies (i.e., as-is conceptual solution architecture)? 
• What existing systems or services are associated with authoritative data sources?

Activity 4.1:  Assess the systems and technology environment for alignment with
performance, business, and information requirements

Activity Inputs:

• Process step 1 outputs
• Process step 2 outputs
• Process step 3 outputs

Tasks:

4.1.1      Collect information on existing segment system and service capabilities

This task leverages the performance, business, and data architecture analysis conducted in process step 3 to identify the key systems and services capabilities that should be assessed in process step 4. The analysis in process step 3 has been conducted within the scope set in process step 2. Therefore, the analysis in process step 4 is focused within the established scope of the segment architecture as defined and accepted by the core team. Key process step 3 artifacts to consider include the business and information to strategic improvement opportunities alignment matrix, the business and data architecture adjustment profiles, and the as-is key information sources qualitative assessment.

During this task, the architect gathers information that will be useful to conducting an analysis on how well the current systems and services support target mission delivery. Information being gathered may include the systems currently in use, services currently in use, any known security issues or risks, and stakeholder feedback with regard to overall system performance and alignment to business needs. Performance information may also be derived from existing program performance assessments (e.g., Program Assessment Rating Tool).

Information-gathering can be performed using a variety of methods, including querying an existing repository of EA information and conducting interviews with key stakeholders (e.g., business owners) to understand the systems and services within a segment and to identify existing data sources. The information collected should be at a sufficient level of detail to assess the data fit, business fit, technology fit, service management, and maturity level of the system or service and should include the total cost to provide, deliver, support, and manage data, systems, and services in the portfolio. Cost data associated with the current operational environment is useful in determining projected cost efficiencies that may result from implementing the target segment architecture. These cost data should be extracted from existing exhibit 300s and the exhibit 53. A useful approach for capturing cost data for information technology systems is using the baseline cost reporting template provided in OMB Memorandum M-06-22 to facilitate the capture and reporting of cost savings and cost avoidance that the target conceptual solution architecture will achieve.

The cost information gathered during this task should be leveraged in the capital planning and investment control (CPIC) phase to support the cost-benefit analysis and return-on-investment analysis that will be utilized in the development of subsequent business case(s).   For example, if redundant services and systems are identified for decommissioning in subsequent activities, it will be helpful to have determined a rough cost for the current environment.

4.1.2      Define the as-is conceptual solution architecture

The as-is conceptual solution architecture serves as a baseline for determining the required adjustments to the segment architecture in order to align the strategic, business, and information improvement opportunities in subsequent tasks. Although this guidance is for segment architecture, the architect must develop an understanding of the current conceptual systems and services environment so subsequent analysis of the target systems and services architecture can be performed.

The as-is systems and services interface diagram should be constructed to illustrate how the business functionality identified in the business model (process step 3) is associated with existing system and service components. This model shows the existing systems and services in the as-is state and identifies the relationships (e.g., data exchange packages) between them, but it may also include an overlay to show the boundaries of key business functions and external interfaces (e.g., organizational). The data depicted in the as-is systems and services interface diagram should align with portions of the conceptual data model from process step 3, and the systems and services depicted should be enablers of the business processes and activities analyzed in process step 3.

Unlike the description of the target conceptual solution architecture as developed in activity 4.2, the description of the as-is conceptual model should include only the as-is systems and services interface diagram in order to limit the analysis of the as-is conceptual solution architecture to what is necessary to provide an adequate baseline. The subsequent development of the target conceptual solution architecture will include other artifacts, such as the service component model and technology model.

4.1.3      Assess business value and performance of systems and services

An assessment of the value and performance of as-is systems and services within the defined scope of the segment is performed to determine where adjustments to the segment architecture should be investigated. This assessment is a critical task in ensuring alignment to the strategic, business, and information requirements depicted in process steps 2 and 3.

An overall assessment is performed for each as-is system or service to determine how well the system or service supports the segment strategic intent, as developed in process step 2. This assessment should also include an identification of the degree of functional overlap with other systems or services and the extent to which the systems or services are associated with re-engineered or streamlined business processes (e.g., automated workflow).
The business value assessment should also take into consideration the overall efficiency of applicable investments (e.g., return on investment) relative to available alternatives to these investments in similar systems and services or to other enterprise services.

4.1.4      Determine adjustments necessary to the as-is conceptual solution architecture

Results of the as-is systems and services analysis are compiled and evaluated using the as-is system and services scorecard, which produces a comprehensive scoring of the cost, fit, and value of as-is systems. The analysis results should be evaluated to answer key questions relative to the needs of the target conceptual solution architecture, including:

NIST 800-39, Sec. 3.3: Security controls should be reflected in the FEA solution architectures and should be traceable to security requirements allocated to mission/business processes defined in the FEA segment architectures. Certain security controls (e.g., common security controls) may be provided by cross-federal information security initiatives, supporting infrastructure, other shared security services or solutions, or cross agency, segment, or bureau initiatives. Note: The selection of security controls is based on NIST800-53 in accordance with FIPS 199 impact levels determined during the security categorization process and the minimum security requirements defined in FIPS 200.

• What existing investments are included in this portfolio?
• What are the systems and services in the segment portfolio and how are these arrayed?
• How are the systems and services in the segment performing to deliver business value for the costs associated with operating and maintaining them?
• What risks are associated with existing information systems and services?
• What systems or services should be considered for the target state?
• What security and privacy continuous monitoring activities should be considered for the target state?

Key references related to security that should be considered when answering some of the questions above include:

• NIST SP 800-53A which provides the methods and procedures for assessing security and privacy-related controls
• NIST SP 800-37 which provides certification and accreditation requirements
• NIST SP 800-39 which provides framework for managing risks from information systems

Communications Considerations:

Activity resource requirements should be reviewed and verified with the core team to help ensure participation and access to key subject matter experts. Architects should work with systems and services owners to ensure they have current and accurate information about the segment services and systems.

Results of the analysis of systems and services should be verified with the core team and other key stakeholders. Where a segment has a large collection of interdependent systems and services, it may be preferable to establish a dedicated work group to verify the results of activity 4.1.

Activity Outputs:

• As-is system and services scoring
• As-Is conceptual solution architecture

Suggested Analytical Techniques

Output	Core	FEA Layers					Suggested Analytical Technique	Examples/Templates	Contributing Agency/Team
		P	B	D	S	T
As-is system and services scoring	No				X		As-is systems and services description and scoring	As-is systems and services description and scoring	Department of the Interior (DOI)
As-Is conceptual solution architecture	Yes		X		X	X	As-is system interface diagram	As-is system interface diagram	Department of the Treasury
		Key to FEA Layers P = Performance B = Business D = Data S = Service T = Technology

Activity 4.2:  Define the target conceptual solution architecture

Activity Description:

The purpose of this activity is to develop the target conceptual solution architecture that enables the performance, business, and data architectures defined in process steps 2 and 3. Although this guidance is for segment architecture, a complete segment architecture should include a conceptual depiction of the target systems and services architecture. Hence, the term conceptual solution architecture includes the segment target systems and services, the supported business functions, segment boundaries (as defined by interfaces with external customers, systems, services, and organizations), and the relationships between them. Target services may include business services, enterprise services, and other technical service components.

During this activity, the architect defines the systems and services for the target state, with an emphasis on reuse opportunities; this begins with the identification and selection of reusable service components from the Federal Transition Framework (FTF) Catalog, followed by the subsequent consideration of other available standard service, data, and technology components. Since segment-specific system and service solutions tend to involve higher costs for both development and operations, the specification of such unique service components and non-standard technologies should be considered only in situations where there are mission-critical needs or a lack of available reusable service or technology components.

Activity 4.2:  Define the target conceptual solution architecture

Activity Inputs:

• Federal Transition Framework (FTF)
• As-is system and services scoring
• As-Is conceptual solution architecture

4.2.1      Identify service and solution reuse opportunities

FTF Usage Guide, Sec. 3.1: The FTF Catalog provides information to agency decision makers to support the implementation of cross-agency initiatives, and provides guidance to working groups with responsibility to develop cross-agency initiative architecture. The catalog supports usage scenarios for agency decision makers and cross-agency task forces, working groups or communities of practice with responsibility to develop initiative architecture.

It is considered best practice when defining a target conceptual solution architecture to reference the Federal Transition Framework (FTF) Catalog as a starting point for reuse of cross-agency initiatives. The FTF Catalog is a key mechanism by which agencies can identify existing Federal cross-agency initiatives in order to improve alignment of their segment architectures with Federal-wide performance, business, and information requirements. Leveraging the FTF also ensures that best practices are incorporated into the conceptual solution architecture, which will lead to a more flexible and robust target state.

In addition, service and technology components associated with standard COTS solutions and existing SmartBUY agreements and ELAs should be identified for incorporation into the target state. Leveraging such common enterprise solutions will enable agencies to realize significant cost avoidance and cost savings when acquiring associated standard IT hardware and software products. The associated COTS and SmartBUY standards and specifications should also be identified in the agency technical reference model (TRM).   In many cases, reusable service components may include enterprise infrastructure services (e.g., authentication) and existing ADS information services (e.g., data, map, and exchange services).

PGFSOA, 3.2.3: Adoption of some common services across the federal government will start with infrastructure services (e.g., authentication, auditing) but quickly expand to business utility services (e.g., federal employee lookup, simple approval process, calendar services, scheduling).

This task includes the identification of potential cross-cutting services and common service components that can be leveraged for reuse within the target conceptual solution architecture. The result of completing this task is the identification of reusable service components that can be incorporated into the target state, such as enterprise data standards (e.g., information-sharing data exchange), business services (e.g., Grants.gov), and other cross-agency initiatives defined in the FTF, along with other standard enterprise solutions, such as those defined by COTS and ELA standards and other available enterprise services. A reuse summary template and data reuse template are leveraged to capture applicable reuse opportunities for the segment.

In assessing the costs associated with the target services identified in this task, expert judgment and available historical information should be used to develop estimates when specific costs of services are not known.

4.2.2      Define applicable high-level technology, service, and information standards

High-level technology, service, and information standards for the target segment architecture should be specified with the goal of maintaining alignment with the segment performance, business, and information requirements defined in process steps 2 and 3.

This task begins with a review of the target business and data architecture developed in process step 3, along with the target maturity level for services, as identified in process step 2. The purpose of this review is to ensure that the specification of high-level technology, service, and information standards are aligned with the overall strategic improvement opportunities for the segment.

For each major business function, the required services and associated standards should be identified. This includes:

• Identifying service interface needs
• Defining high-level requirements related to security controls
• Identifying information services required to support authoritative data sources
• Identifying the maturity level for the underlying capabilities needed to deliver the service

4.2.3      Identify required target system and service components

The result of completing this task is the selection of systems and services to be included in the target state, based on performance, business, and information requirements from process steps 2 and 3. The architect should review the results of the business value analysis, combined with the specification of technology, service, and information standards in prior tasks, to identify target systems that provide the necessary capabilities to support the target business and data architectures. This analysis should also take into account how the existing systems and services in the segment are performing in terms of business value and cost. High business-value systems in the current state could be good candidates for the target state environment.

Selecting target-state systems may include carrying forward an existing system to the target state, consolidation of multiple systems to reduce the total number of systems supporting a business function, and/or identification of a new high-level system requirement associated with automation of business processes. In selecting services, this may involve the selection of enterprise services (e.g., FTF Catalog), standardization and consolidation of existing services, or the establishment of new services (e.g., a new data service to support information exchanges).

As the development of the target conceptual solution architecture is tightly coupled with the business and data architecture, this task may become highly iterative as changes to the business and data architectures are identified.

4.2.4      Define relationships between target systems and services

The final task in defining the conceptual solution architecture is to define the relationships between systems and services within the context of the overall boundaries of the segment. The architect should construct the target systems and services interface diagram to illustrate how the business functionality identified in the business model (process step 3) is associated with target system and service components. The target systems and services diagram shows the systems and services in the target state and identifies the relationships (e.g., data-exchange packages) between them. This diagram may include an overlay to show the boundaries of key business functions and external interfaces.

The architect should capture target services in a service component model (SCM), an analytical technique that may be applied to business and enterprise service segments to describe service components and the mechanisms for providing service delivery to customers. This model, which provides a framework and vocabulary for guiding discussions between service providers and consumers, is meant to be a catalyst for true cross-agency collaboration. Along with development of the SCM, the technology model (TM) is developed to show the technology components that support the service delivery for each service component defined in the SCM.

The integrated service component and technology model is an analytical technique that may be applied to each service component to create the TM and show the service-to-service interaction, supporting technical components, and the information flows associated with each service component. This is a particularly useful artifact that illustrates the standardization around service components for enterprise and business service segments. In the integrated service component and technology model, service-to-service interactions are defined as one of two types:  information flow or control flow. Control flow describes how a service component invokes or uses other service components, while information flow describes how information-exchange packages (as previously defined in process step 3) flow between service components.

The integrated service component and technology model also shows each service component in relation to the TM which describes the technical components that support the service delivery for each service component. These relationships between the SCM and TM components help illustrate the mapping of service reference model (SRM) components to their supporting technical components as identified in the technical reference model (TRM).

Considerations for Enterprise Services:

Enterprise services may be implemented in the form of reusable service components that may or may not replace existing systems. It is entirely possible that an enterprise service may result in standardization across sub-systems to reuse enterprise service components without affecting the overall number of systems in the IT portfolio. An example of this would be the incorporation of authentication services across all systems in a portfolio.
Enterprise services may also be associated with the specification of a target authoritative data source (ADS) and related data standards and data services. This type of association may result in the aggregation of systems within the target architecture of an enterprise services segment as required to support the target ADS services.

Considerations for Business Services:

Cross-cutting business services will likely result in the consolidation of systems to provide a common business service and solution. An example of this would be the adoption of a grants management service provider and standardized grants management service delivery processes using the FTF Grants Management Line of Business.

Communications Considerations:

Review and validate activity plans and resource requirements with governance bodies and key stakeholders. Establish a work group to verify:

• Architectural drivers
• Segment-specific service component requirements
• Technical, operational, interoperability, and service delivery requirements
• Integrated target systems and services diagram

Review and validate activity results with governance bodies and key stakeholders.

Activity Outputs:

• Target conceptual solution architecture
• Target service component architecture
• Target technical architecture
• Integrated service component and technology model
• Reuse summary
• Data reuse

Suggested Analytical Techniques

Output	Core	FEA Layers					Suggested Analytical Technique	Examples/Templates	Contributing Agency/Team
		P	B	D	S	T
Target conceptual solution architecture	Yes		X		X	X	Target system interface diagram	Target system interface diagram	Department of the Treasury
Target Service Component Architecture	Yes				X		Service component model (SCM)	Service component model	Office of Personnel Management - Human Resources Line of Business (HR-LOB)
Target Technical Architecture	Yes					X	Technology model	Technology model	Office of Personnel Management - Human Resources Line of Business (HR-LOB)
Integrated service component and technology model	No				X	X	Integrated service component and technology model	Integrated service component and technology model	Office of Personnel Management - Human Resources Line of Business (HR-LOB)
Reuse Summary	Yes	X	X	X	X	X	Reuse Summary	Reuse summary	Federal Segment Architecture Working Group (FSAWG)
Data Reuse	Yes			X			Data Reuse	Data reuse	Federal Segment Architecture Working Group (FSAWG)
		Key to FEA Layers P = Performance B = Business D = Data S = Service T = Technology

Activity 4.3:  Identify and analyze system and service transition dependencies

Activity Description:

During process step 5, transition options are developed and formulated into implementation recommendations. However, it is beneficial during process step 4 to analyze and explore transition alternatives that may be driven by logical dependencies, risks, or issues that may exist between as-is and target systems and services. This activity is focused on identifying, analyzing, and selecting recommendations for transition alternatives that are based on logical dependencies or other considerations (e.g., cost savings / cost avoidance) that may introduce intermediate transitional states along the path to achieving the target state. This analysis also helps to reduce and simplify the number of transition options to be included in the transition planning within process step 5.

Activity 4.3:  Identify and analyze system and service transition dependencies
 

Activity Inputs:

• Target conceptual solution architecture
• Target service component architecture
• Target technical architecture
• Integrated service component and technology model
• Reuse summary
• Data reuse

4.3.1      Identify and analyze alternatives for transition

In some cases, it may not be possible to plan a straightforward transition from the as-is to target systems and services state. One of the primary reasons for this task is to identify the need for intermediate target states that may be necessary on the road to achieving the ultimate goal of the target state.
Logical dependencies could be required to support a new system supporting a mission-critical need before an existing similar system is decommissioned. Additional transition constraints may sometimes be derived based on other factors or risks, such as budget cycle requirements for obtaining investment funds or the need to maintain an intermediate state between the as-is and the target during an extended deployment horizon. Examples of risks or issues include risks associated with implementing new technologies and complexity that requires several interrelated systems to undergo conversion at the same time.

The architecture decision matrix provides a structured approach to identifying alternatives for the transition from the as-is to the target conceptual solution architecture. This analysis technique identifies and analyzes risks and issues and develops alternatives to address each. The architecture decision matrix also provides a structured approach to determining risks associated with business fit along the dimensions of performance, business, data, and service management and includes consideration of risks or issues associated with technology fit for application, technology, and security components. Alternatives are captured using the matrix for a decision by the core team.

4.3.2      Develop recommendations outlining selected alternatives

Based on the analysis in the previous task, the core team selects the alternatives for transition. Alternatives may include implementing intermediate target states and developing alternative funding strategies based on cost and available investment funds.

Once approved, these recommendations will carry forward into the summary of findings and recommendations developed for the segment blueprint in process step 5. Milestones for the recommendations may be established during this task, however, it is understood that additional milestones may be developed in process step 5 as well.

Communications Considerations:

Review and validate transition recommendation plans and resource requirements with appropriate governance bodies and key stakeholders.

Activity Outputs:

• Transition recommendation profile
• Transition recommendation sequencing diagram
• Recommendation sequencing milestones

Suggested Analytical Techniques

Output	Core	FEA Layers					Suggested Analytical Technique	Examples/Templates	Contributing Agency/Team
		P	B	D	S	T
Transition recommendation profile	No				X		Transition recommendation profile	Transition recommendation profile	Department of the Treasury
Transition recommendation sequencing diagram	No				X		Transition recommendation sequencing diagram	Transition recommendation sequencing diagram	Department of the Interior (DOI)
Recommendation sequencing milestones	Yes	X	X	X	X	X	Recommendation sequencing milestones	Recommendation sequencing milestones	Federal Segment Architecture Working Group (FSAWG)
		Key to FEA Layers P = Performance B = Business D = Data S = Service T = Technology

Activity 4.4:  Validate and communicate the conceptual solution architecture

Activity Description:

This activity includes packaging and gaining approval of the conceptual solution architecture by the executive sponsor and business owners.

Activity 4.4:  Validate and communicate the conceptual solution architecture

Activity Inputs:

• Target conceptual solution architecture
• Target service component architecture
• Target technical architecture
• Integrated service component and technology model
• Transition recommendation profile
• Transition recommendation sequencing diagram
• Recommendation sequencing milestones

Activity Tasks:

4.4.1      Package the conceptual solution architecture

The architect should develop a package that summarizes the as-is and the to-be conceptual solution architecture and provides an overview of the transition considerations, alternatives, and recommendations. This should include the relevant artifacts describing the target conceptual solution architecture and how the performance, business, and information requirements are aligned with the target state conceptual solution architecture.

4.4.2      Present the conceptual solution architecture for approval

A presentation that includes the important aspects of the integrated target system and services model, the SCM, and the TM should be prepared by the architect. The architect should conduct a detailed workshop review of these architecture products for the core team. The review should also include the agency Chief Architect to ensure that the proposed conceptual solution architecture is aligned with the overall enterprise architecture.

Communications Considerations:

Brief process step 4 results to applicable governance teams and stakeholder groups.
For segments requiring a formal cross-agency review of the analyses performed in this process step, consolidate the outputs into a final report for formal distribution and review. Review and validate the final report with appropriate work groups, governance bodies, and key stakeholders.

Activity Outputs:

• Conceptual Solution Architecture Presentation

Suggested Analytical Techniques:

None

Step References

OMB Memorandum M-06-22, Cost Savings Achieved Through E-Government and Line of Business Initiatives , Office of Management and Budget, August 8, 2006

NIST Special Publication 800-53A, Guide for Assessing the Security Controls in Federal Information Systems , July 2008

NIST Special Publication 800-37, Guide for the Security Certification and Accreditation of Federal Information Systems , May 2004

NIST Special Publication 800-39, [DRAFT] Managing Risk from Information Systems: An Organizational Perspective , April 2008

Federal Transition Framework Catalog of Cross Agency Initiatives , Version 1.0, December 2006

A Practical Guide to Federal Service Oriented Architecture , Version 1.1, June 2008