Process Step 4: Define the Conceptual Solution Architecture    (3ZQ2)

Activity 4.2: Define the target conceptual solution architecture    (3ZQ3)

Activity Description:    (3ZQ4)

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.    (3ZQ5)

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.    (3ZQ6)

http://colab.cim3.net/file/work/fsam/Step4/4.2---Tasks.jpg    (3ZQ7)

Activity Inputs:    (3ZQ8)

4.2.1 Identify service and solution reuse opportunities    (3ZQC)

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 provides 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.    (3ZQD)

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).    (3ZQE)

This task is focused on identifying potential cross-cutting services and common service components that can be leveraged for reuse within the target service 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.    (3ZQF)

FTF Touch Point: 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.    (3ZQG)

PGFSOA Touch Point: 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).    (3ZQH)

4.2.2 Define applicable high-level technology, service, and information standards    (3ZQI)

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 architecture requirements defined in process steps 2 and 3.    (3ZQJ)

This task begins with a review of the target business and information 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 associated with the target service maturity levels are aligned with the overall strategic improvement opportunities for the segment.    (3ZQK)

For each major business function, the services and associated standards as required by stakeholders to perform or interact with the business functions should be identified. This includes:    (3ZQL)

4.2.3 Identify required target system and service components    (3ZQQ)

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 result in 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).    (3ZQR)

As the development of the target conceptual architecture is tightly coupled with the business and information architecture, this task may become highly iterative as changes to the business and information architectures are identified.    (3ZQS)

4.2.4 Define relationships between target systems and services    (3ZQT)

The final task in defining the conceptual solution architecture is to define the relationships between systems and services in the context of the business functions and overall boundaries of the segment, as defined by interfaces with external customers, systems, services, and organizations.    (3ZQU)

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 (e.g., organizational).    (3ZQV)

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.    (3ZQW)

The integrated service component and technology model is an analytical technique that may be applied to each service components 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.    (3ZQX)

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 helps illustrate the mapping of service reference model (SRM) components to their supporting technical components as identified in the technical reference model (TRM).    (3ZQY)

Considerations for Enterprise Services:    (3ZQZ)

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.    (3ZR0)

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 in order to support the target ADS services.    (3ZR1)

Considerations for Business Services:    (3ZR2)

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.    (3ZR3)

Communications Considerations:    (3ZR4)

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

Review and validate activity results with governance bodies and key stakeholders.    (3ZRA)

Activity Outputs:    (3ZRB)

Suggested Analytical Techniques:    (3ZRI)

http://colab.cim3.net/file/work/fsam/Step4/4.2---AT.jpg    (3ZRP)

Next Activity: 4.3 /Identify_and_analyze_system_and_service_transition_dependencies    (3ZRQ)