Table of contents
  1. 1. Executive Overview
    1. Background
    2. Top-Level Overview of the FSAM
      1. Figure 1: FSAM High-Level Overview
    3. Segment Sizing and Timing
      1. Table 1: Segment Sizing Guide
      2. Table 2: Target Duration for Completing FSAM Steps
    4. Structure of the FSAM Guidance
      1. Figure 2: FSAM Process Steps, Activities, and Tasks
      2. Table 3 : Structure of the FSAM Guidance Document
    5. FSAM Suggested Analytical Techniques
    6. Conclusion
    7. References
    8. Appendix I: Summary of FSAM Outputs
      1. Summary of FSAM Outputs and Suggested Analytical Techniques
  2. 2. FSAM Contributors
    1. Contributing Agencies and Assessed Best Practices:
    2. FSAWG Core Team Members
    3. FSAWG Sub-Team Members
  3. 3. Process Step Guidance Documents
    1. Figure 1: FSAM High-Level Overview
    2. Process Step Guidance Documents
    3. Structure of the FSAM Guidance Document
    4. Step 1: Determine Participants and Launch Project
      1. Step Description and Purpose
      2. Step Outcome
      3. Suggested Analytical Techniques
      4. Step 1 At-a-Glance
      5. Activity Details
        1. Activity 1.1:  Determine the executive sponsor
          1. Activity Description:
          2. Activity 1.1:  Determine the executive sponsor
        2. Activity Inputs:
        3. Tasks:
          1. 1.1.1      Identify the segment governance framework
          2. 1.1.2      Communicate to business owner(s) the role of the executive sponsor
          3. 1.1.3      Determine the most appropriate executive to be executive sponsor
        4. Considerations for Enterprise Services:
        5. Communications Considerations:
        6. Activity Outputs:
        7. Suggested Analytical Techniques
      6. Activity 1.2:  Develop the purpose statement for the segment
        1. Activity Description:
          1. Activity 1.2:  Develop the purpose statement for the segment
        2. Activity Inputs:
        3. Activity Tasks:
          1. 1.2.1      Discuss the business challenges facing each business owner
          2. 1.2.2      Synthesize the common business challenges across the business owners
          3. 1.2.3      Communicate how segment architecture could assist with common business challenges
        4. Communications Considerations:
        5. Activity Outputs:
        6. Suggested Analytical Techniques
      7. Activity 1.3:  Solicit core team members
        1. Activity Description:
          1. Activity 1.3:  Solicit core team members
        2. Activity Inputs:
        3. Activity Tasks:
          1. 1.3.1      Communicate to business owner(s) the role of the core team
          2. 1.3.2      Determine personnel to be appointed to the core team
          3. 1.3.3      Communicate appointments to the affected personnel
          4. 1.3.4      Issue a memorandum to communicate the formation of the core team and the purpose statement
        4. Communications Considerations:
        5. Activity Outputs:
        6. Suggested Analytical Techniques
      8. Activity 1.4:  Create core team charter and project plan
        1. Activity Description:
          1. Activity 1.4:  Create core team charter and project plan
        2. Activity Inputs:
        3. Activity Tasks:
          1. 1.4.1      Develop draft core team charter
          2. 1.4.2      Create project plan for segment architecture development
          3. 1.4.3      Review and approve core team charter, project plan and governance
        4. Communications Considerations:
        5. Activity Outputs:
        6. Suggested Analytical Techniques
      9. Activity 1.5: Establish the communications strategy
        1. Activity Description:
          1. Activity 1.5:  Establish the communications strategy
        2. Activity Inputs:
        3. Activity Tasks:
          1. 1.5.1      Determine communications goals and objectives
          2. 1.5.2      Identify audience groups and design themes and key messages
          3. 1.5.4      Implement project collaboration website
        4. Communications Considerations:
        5. Activity Outputs:
        6. Suggested Analytical Techniques
      10. Step References
    5. Step 2: Define the Segment Scope and Strategic Intent
  4. Step Description and Purpose
  5. Step Outcome
  6. Suggested Analytical Techniques
  7. Step 2 At-a-Glance
  8. Activity Details
    1. Activity 2.1:  Establish segment scope and context
      1. Activity Description:
      2. Activity Inputs:
      3. Tasks:
        1. 2.1.1      Review segment architecture development purpose statement
        2. 2.1.2      Identify organization components
        3. 2.1.3      Identify stakeholders
        4. 2.1.4      Establish segment summary description
        5. 2.1.5      Validate / approve segment scope and context
        6. 2.1.6      Optional Task — Refine / update scope and context
      4. Communications Considerations:
      5. Activity Outputs:
      6. Suggested Analytical Techniques
    2. Activity 2.2:  Identify and prioritize strategic improvement opportunities
      1. Activity Description:
      2. Activity Inputs:
      3. Tasks:
        1. 2.2.1      Review segment scope and context
        2. 2.2.2      Determine stakeholders' needs
        3. 2.2.3      Identify segment risks and impacts
        4. 2.2.4      Identify performance gaps
        5. 2.2.5      Formulate and prioritize business needs
        6. 2.2.6      Formulate and prioritize strategic improvement opportunities
        7. 2.2.7      Validate strategic improvement opportunities
      4. Considerations for Enterprise Services:
      5. Considerations for Business Services:
      6. Communications Considerations:
      7. Activity Outputs:
      8. Suggested Analytical Techniques
    3. Activity 2.3:  Define segment strategic intent
      1. Activity Description:
      2. Activity Inputs:
      3. Activity Tasks:
        1. 2.3.1      Describe segment target state vision
        2. 2.3.2      Establish segment's strategic performance
        3. 2.3.3      Identify target maturity levels for common / mission services
        4. 2.3.4      Document the strategic intent
      4. Communications Considerations:
      5. Activity Outputs:
      6. Suggested Analytical Techniques
    4. Activity 2.4:  Validate and communicate the scope and strategic intent
      1. Activity Description:
      2. Activity Inputs:
      3. Activity Tasks:
        1. 2.4.1      Package the scope and strategic intent
        2. 2.4.2      Present the scope and strategic intent for approval
      4. Communications Considerations:
      5. Activity Outputs:
      6. Suggested Analytical Techniques:
  9. Step References
    1. Step 3: Define Business and Information Requirements
  10. Step Description and Purpose
  11. Suggested Analytical Techniques
  12. Step Outcome
  13. Step 3 At-a-Glance
  14. Activity Details
    1. Activity 3.1:  Determine current business and information environment associated with strategic improvement opportunities
      1. Activity Description:
      2. Activity Inputs:
      3. Tasks:
        1. 3.1.1      Determine the value chains for the common / mission services
        2. 3.1.2      Define the business function model and associate it to the value chain
        3. 3.1.3      Analyze existing IT investments that relate to the business processes
        4. 3.1.4      Analyze business processes and determine high-level information requirements, including organizational relationships
        5. 3.1.5      Assess current information sources
      4. Considerations for Enterprise Services:
      5. Considerations for Business Services:
      6. Communications Considerations:
      7. Activity Outputs:
      8. Suggested Analytical Techniques
    2. Activity 3.2:  Determine business and information improvement opportunities
      1. Activity Description:
      2. Activity Inputs:
      3. Tasks:
        1. 3.2.1                  Align strategic improvement opportunities to the business architecture
        2. 3.2.2                  Determine the required adjustments to the business architecture
        3. 3.2.3      Align strategic improvement opportunities to the data architecture
        4. 3.2.4      Determine the required adjustments to the data architecture
      4. Communications Considerations:
      5. Activity Outputs:
      6. Suggested Analytical Techniques
    3. Activity 3.3:  Define target business and data architectures
      1. Activity Description:
      2. Activity Inputs:
      3. Tasks:
        1. 3.3.1      Define target business processes and their performance including organizational relationships
        2. 3.3.2      Define target data relationships and business data stewards
        3. 3.3.3      Define the target information services
        4. 3.3.4      Ensure target business and data architectures addresses strategic improvement opportunities
      4. Considerations for Enterprise Services:
      5. Considerations for Business Services:
      6. Communications Considerations:
      7. Activity Outputs:
      8. Suggested Analytical Techniques
    4. Activity 3.4:  Validate and communicate target business and data architectures
      1. Activity Description:
      2. Activity Inputs:
      3. Tasks:
        1. 3.4.1      Package business and data architectures
        2. 3.4.2      Present business and data architectures for approval
      4. Communications Considerations:
      5. Activity Outputs:
      6. Suggested Analytical Techniques:
  15. Step References
    1. Step 4: Define the Conceptual Solution Architecture
  16. Step Description and Purpose
  17. Step Outcome
  18. Suggested Analytical Techniques
  19. Step At-a-Glance
  20. Step 4 At-a-Glance
  21. Activity Details
    1. Activity 4.1:  Assess systems and technology environment for alignment with performance, business, and information requirements
      1. Activity Description:
      2. Activity Inputs:
      3. Tasks:
        1. 4.1.1      Collect information on existing segment system and service capabilities
        2. 4.1.2      Define the as-is conceptual solution architecture
        3. 4.1.3      Assess business value and performance of systems and services
        4. 4.1.4      Determine adjustments necessary to the as-is conceptual solution architecture
      4. Communications Considerations:
      5. Activity Outputs:
      6. Suggested Analytical Techniques
    2. Activity 4.2:  Define the target conceptual solution architecture
      1. Activity Description:
      2. Activity Inputs:
        1. 4.2.1      Identify service and solution reuse opportunities
        2. 4.2.2      Define applicable high-level technology, service, and information standards
        3. 4.2.3      Identify required target system and service components
        4. 4.2.4      Define relationships between target systems and services
      3. Considerations for Enterprise Services:
      4. Considerations for Business Services:
      5. Communications Considerations:
      6. Activity Outputs:
      7. Suggested Analytical Techniques
      8. Target conceptual solution architecture
      9. Target Service  Component Architecture
      10. Target Technical Architecture
      11. Integrated service component and  technology model
      12. Reuse Summary
      13. Data Reuse
    3. Activity 4.3:  Identify and analyze system and service transition dependencies
      1. Activity Description:
      2. Activity Inputs:
        1. 4.3.1      Identify and analyze alternatives for transition
        2. 4.3.2      Develop recommendations outlining selected alternatives
      3. Communications Considerations:
      4. Activity Outputs:
      5. Suggested Analytical Techniques
    4. Activity 4.4:  Validate and communicate the conceptual solution architecture
      1. Activity Description:
      2. Activity Inputs:
      3. Activity Tasks:
        1. 4.4.1      Package the conceptual solution architecture
        2. 4.4.2      Present the conceptual solution architecture for approval
      4. Communications Considerations:
      5. Activity Outputs:
      6. Suggested Analytical Techniques:
  22. Step References
    1. Step 5: Author the Modernization Blueprint
  23. Step Description and Purpose
  24. Step Outcome
  25. Suggested Analytical Techniques
  26. Step 5 At-a-Glance
  27. Activity Details
    1. Activity 5.1:  Perform cost / value / risk analysis to develop implementation recommendations
      1. Activity Description:
      2. Activity Inputs:
      3. Tasks:
        1. 5.1.1      Identify findings
        2. 5.1.2      Develop transition options
        3. 5.1.3      Perform cost / value / risk analysis to compare transition options
        4. 5.1.4      Develop prioritized implementation recommendations
        5. 5.1.5      Develop lessons learned
      4. Communications Considerations:
      5. Activity Outputs:
      6. Suggested Analytical Techniques
    2. Activity 5.2:  Develop draft blueprint and sequencing plan
      1. Activity Description:
      2. Activity Inputs:
      3. Tasks:
        1. 5.2.1      Develop the draft work breakdown structure
        2. 5.2.2      Develop the draft sequencing plan
        3. 5.2.3      Develop the draft segment blueprint
      4. Communications Considerations:
      5. Activity Outputs:
      6. Suggested Analytical Techniques
      7. Segment Blueprint Sample Outline
    3. Activity 5.3:  Review and finalize the blueprint and sequencing plan
      1. Activity Description:
      2. Activity Inputs:
      3. Tasks:
        1. 5.3.1      Distribute the draft segment blueprint for review
        2. 5.3.2      Collect comments
        3. 5.3.3      Develop the final segment blueprint
      4. Communications Considerations:
      5. Activity Outputs:
      6. Suggested Analytical Techniques
    4. Activity 5.4:  Brief core team and obtain approval
      1. Activity Description:
      2. Activity Inputs:
      3. Tasks:
        1. 5.4.1      Distribute final review materials
        2. 5.4.2      Conduct review and obtain approval
      4. Communications Considerations:
      5. Activity Outputs:
      6. Suggested Analytical Techniques:
  28. Step References
  29. 4. Outputs and Suggested Analytical Techniques
  30. 5. FSAM Data Model
    1. Background
    2. Table 1 :  EASR/FSAM Artifact Alignment
    3. Purpose and Scope of the FSAM Logical Data Model
    4. References
    5. FSAM Logical Data Model
      1. Figure 1:  FSAM Logical Data Model
      2. Table 2:  FSAM/Exhibit 53 Crosswalk
      3. Table 3:  FSAM/Exhibit 300 Crosswalk
      4. Table 4:  FSAM/Enterprise Architecture Segment Report (EASR) Crosswalk

Federal Segment Architecture Methodology Toolkit

Last modified
Table of contents
  1. 1. Executive Overview
    1. Background
    2. Top-Level Overview of the FSAM
      1. Figure 1: FSAM High-Level Overview
    3. Segment Sizing and Timing
      1. Table 1: Segment Sizing Guide
      2. Table 2: Target Duration for Completing FSAM Steps
    4. Structure of the FSAM Guidance
      1. Figure 2: FSAM Process Steps, Activities, and Tasks
      2. Table 3 : Structure of the FSAM Guidance Document
    5. FSAM Suggested Analytical Techniques
    6. Conclusion
    7. References
    8. Appendix I: Summary of FSAM Outputs
      1. Summary of FSAM Outputs and Suggested Analytical Techniques
  2. 2. FSAM Contributors
    1. Contributing Agencies and Assessed Best Practices:
    2. FSAWG Core Team Members
    3. FSAWG Sub-Team Members
  3. 3. Process Step Guidance Documents
    1. Figure 1: FSAM High-Level Overview
    2. Process Step Guidance Documents
    3. Structure of the FSAM Guidance Document
    4. Step 1: Determine Participants and Launch Project
      1. Step Description and Purpose
      2. Step Outcome
      3. Suggested Analytical Techniques
      4. Step 1 At-a-Glance
      5. Activity Details
        1. Activity 1.1:  Determine the executive sponsor
          1. Activity Description:
          2. Activity 1.1:  Determine the executive sponsor
        2. Activity Inputs:
        3. Tasks:
          1. 1.1.1      Identify the segment governance framework
          2. 1.1.2      Communicate to business owner(s) the role of the executive sponsor
          3. 1.1.3      Determine the most appropriate executive to be executive sponsor
        4. Considerations for Enterprise Services:
        5. Communications Considerations:
        6. Activity Outputs:
        7. Suggested Analytical Techniques
      6. Activity 1.2:  Develop the purpose statement for the segment
        1. Activity Description:
          1. Activity 1.2:  Develop the purpose statement for the segment
        2. Activity Inputs:
        3. Activity Tasks:
          1. 1.2.1      Discuss the business challenges facing each business owner
          2. 1.2.2      Synthesize the common business challenges across the business owners
          3. 1.2.3      Communicate how segment architecture could assist with common business challenges
        4. Communications Considerations:
        5. Activity Outputs:
        6. Suggested Analytical Techniques
      7. Activity 1.3:  Solicit core team members
        1. Activity Description:
          1. Activity 1.3:  Solicit core team members
        2. Activity Inputs:
        3. Activity Tasks:
          1. 1.3.1      Communicate to business owner(s) the role of the core team
          2. 1.3.2      Determine personnel to be appointed to the core team
          3. 1.3.3      Communicate appointments to the affected personnel
          4. 1.3.4      Issue a memorandum to communicate the formation of the core team and the purpose statement
        4. Communications Considerations:
        5. Activity Outputs:
        6. Suggested Analytical Techniques
      8. Activity 1.4:  Create core team charter and project plan
        1. Activity Description:
          1. Activity 1.4:  Create core team charter and project plan
        2. Activity Inputs:
        3. Activity Tasks:
          1. 1.4.1      Develop draft core team charter
          2. 1.4.2      Create project plan for segment architecture development
          3. 1.4.3      Review and approve core team charter, project plan and governance
        4. Communications Considerations:
        5. Activity Outputs:
        6. Suggested Analytical Techniques
      9. Activity 1.5: Establish the communications strategy
        1. Activity Description:
          1. Activity 1.5:  Establish the communications strategy
        2. Activity Inputs:
        3. Activity Tasks:
          1. 1.5.1      Determine communications goals and objectives
          2. 1.5.2      Identify audience groups and design themes and key messages
          3. 1.5.4      Implement project collaboration website
        4. Communications Considerations:
        5. Activity Outputs:
        6. Suggested Analytical Techniques
      10. Step References
    5. Step 2: Define the Segment Scope and Strategic Intent
  4. Step Description and Purpose
  5. Step Outcome
  6. Suggested Analytical Techniques
  7. Step 2 At-a-Glance
  8. Activity Details
    1. Activity 2.1:  Establish segment scope and context
      1. Activity Description:
      2. Activity Inputs:
      3. Tasks:
        1. 2.1.1      Review segment architecture development purpose statement
        2. 2.1.2      Identify organization components
        3. 2.1.3      Identify stakeholders
        4. 2.1.4      Establish segment summary description
        5. 2.1.5      Validate / approve segment scope and context
        6. 2.1.6      Optional Task — Refine / update scope and context
      4. Communications Considerations:
      5. Activity Outputs:
      6. Suggested Analytical Techniques
    2. Activity 2.2:  Identify and prioritize strategic improvement opportunities
      1. Activity Description:
      2. Activity Inputs:
      3. Tasks:
        1. 2.2.1      Review segment scope and context
        2. 2.2.2      Determine stakeholders' needs
        3. 2.2.3      Identify segment risks and impacts
        4. 2.2.4      Identify performance gaps
        5. 2.2.5      Formulate and prioritize business needs
        6. 2.2.6      Formulate and prioritize strategic improvement opportunities
        7. 2.2.7      Validate strategic improvement opportunities
      4. Considerations for Enterprise Services:
      5. Considerations for Business Services:
      6. Communications Considerations:
      7. Activity Outputs:
      8. Suggested Analytical Techniques
    3. Activity 2.3:  Define segment strategic intent
      1. Activity Description:
      2. Activity Inputs:
      3. Activity Tasks:
        1. 2.3.1      Describe segment target state vision
        2. 2.3.2      Establish segment's strategic performance
        3. 2.3.3      Identify target maturity levels for common / mission services
        4. 2.3.4      Document the strategic intent
      4. Communications Considerations:
      5. Activity Outputs:
      6. Suggested Analytical Techniques
    4. Activity 2.4:  Validate and communicate the scope and strategic intent
      1. Activity Description:
      2. Activity Inputs:
      3. Activity Tasks:
        1. 2.4.1      Package the scope and strategic intent
        2. 2.4.2      Present the scope and strategic intent for approval
      4. Communications Considerations:
      5. Activity Outputs:
      6. Suggested Analytical Techniques:
  9. Step References
    1. Step 3: Define Business and Information Requirements
  10. Step Description and Purpose
  11. Suggested Analytical Techniques
  12. Step Outcome
  13. Step 3 At-a-Glance
  14. Activity Details
    1. Activity 3.1:  Determine current business and information environment associated with strategic improvement opportunities
      1. Activity Description:
      2. Activity Inputs:
      3. Tasks:
        1. 3.1.1      Determine the value chains for the common / mission services
        2. 3.1.2      Define the business function model and associate it to the value chain
        3. 3.1.3      Analyze existing IT investments that relate to the business processes
        4. 3.1.4      Analyze business processes and determine high-level information requirements, including organizational relationships
        5. 3.1.5      Assess current information sources
      4. Considerations for Enterprise Services:
      5. Considerations for Business Services:
      6. Communications Considerations:
      7. Activity Outputs:
      8. Suggested Analytical Techniques
    2. Activity 3.2:  Determine business and information improvement opportunities
      1. Activity Description:
      2. Activity Inputs:
      3. Tasks:
        1. 3.2.1                  Align strategic improvement opportunities to the business architecture
        2. 3.2.2                  Determine the required adjustments to the business architecture
        3. 3.2.3      Align strategic improvement opportunities to the data architecture
        4. 3.2.4      Determine the required adjustments to the data architecture
      4. Communications Considerations:
      5. Activity Outputs:
      6. Suggested Analytical Techniques
    3. Activity 3.3:  Define target business and data architectures
      1. Activity Description:
      2. Activity Inputs:
      3. Tasks:
        1. 3.3.1      Define target business processes and their performance including organizational relationships
        2. 3.3.2      Define target data relationships and business data stewards
        3. 3.3.3      Define the target information services
        4. 3.3.4      Ensure target business and data architectures addresses strategic improvement opportunities
      4. Considerations for Enterprise Services:
      5. Considerations for Business Services:
      6. Communications Considerations:
      7. Activity Outputs:
      8. Suggested Analytical Techniques
    4. Activity 3.4:  Validate and communicate target business and data architectures
      1. Activity Description:
      2. Activity Inputs:
      3. Tasks:
        1. 3.4.1      Package business and data architectures
        2. 3.4.2      Present business and data architectures for approval
      4. Communications Considerations:
      5. Activity Outputs:
      6. Suggested Analytical Techniques:
  15. Step References
    1. Step 4: Define the Conceptual Solution Architecture
  16. Step Description and Purpose
  17. Step Outcome
  18. Suggested Analytical Techniques
  19. Step At-a-Glance
  20. Step 4 At-a-Glance
  21. Activity Details
    1. Activity 4.1:  Assess systems and technology environment for alignment with performance, business, and information requirements
      1. Activity Description:
      2. Activity Inputs:
      3. Tasks:
        1. 4.1.1      Collect information on existing segment system and service capabilities
        2. 4.1.2      Define the as-is conceptual solution architecture
        3. 4.1.3      Assess business value and performance of systems and services
        4. 4.1.4      Determine adjustments necessary to the as-is conceptual solution architecture
      4. Communications Considerations:
      5. Activity Outputs:
      6. Suggested Analytical Techniques
    2. Activity 4.2:  Define the target conceptual solution architecture
      1. Activity Description:
      2. Activity Inputs:
        1. 4.2.1      Identify service and solution reuse opportunities
        2. 4.2.2      Define applicable high-level technology, service, and information standards
        3. 4.2.3      Identify required target system and service components
        4. 4.2.4      Define relationships between target systems and services
      3. Considerations for Enterprise Services:
      4. Considerations for Business Services:
      5. Communications Considerations:
      6. Activity Outputs:
      7. Suggested Analytical Techniques
      8. Target conceptual solution architecture
      9. Target Service  Component Architecture
      10. Target Technical Architecture
      11. Integrated service component and  technology model
      12. Reuse Summary
      13. Data Reuse
    3. Activity 4.3:  Identify and analyze system and service transition dependencies
      1. Activity Description:
      2. Activity Inputs:
        1. 4.3.1      Identify and analyze alternatives for transition
        2. 4.3.2      Develop recommendations outlining selected alternatives
      3. Communications Considerations:
      4. Activity Outputs:
      5. Suggested Analytical Techniques
    4. Activity 4.4:  Validate and communicate the conceptual solution architecture
      1. Activity Description:
      2. Activity Inputs:
      3. Activity Tasks:
        1. 4.4.1      Package the conceptual solution architecture
        2. 4.4.2      Present the conceptual solution architecture for approval
      4. Communications Considerations:
      5. Activity Outputs:
      6. Suggested Analytical Techniques:
  22. Step References
    1. Step 5: Author the Modernization Blueprint
  23. Step Description and Purpose
  24. Step Outcome
  25. Suggested Analytical Techniques
  26. Step 5 At-a-Glance
  27. Activity Details
    1. Activity 5.1:  Perform cost / value / risk analysis to develop implementation recommendations
      1. Activity Description:
      2. Activity Inputs:
      3. Tasks:
        1. 5.1.1      Identify findings
        2. 5.1.2      Develop transition options
        3. 5.1.3      Perform cost / value / risk analysis to compare transition options
        4. 5.1.4      Develop prioritized implementation recommendations
        5. 5.1.5      Develop lessons learned
      4. Communications Considerations:
      5. Activity Outputs:
      6. Suggested Analytical Techniques
    2. Activity 5.2:  Develop draft blueprint and sequencing plan
      1. Activity Description:
      2. Activity Inputs:
      3. Tasks:
        1. 5.2.1      Develop the draft work breakdown structure
        2. 5.2.2      Develop the draft sequencing plan
        3. 5.2.3      Develop the draft segment blueprint
      4. Communications Considerations:
      5. Activity Outputs:
      6. Suggested Analytical Techniques
      7. Segment Blueprint Sample Outline
    3. Activity 5.3:  Review and finalize the blueprint and sequencing plan
      1. Activity Description:
      2. Activity Inputs:
      3. Tasks:
        1. 5.3.1      Distribute the draft segment blueprint for review
        2. 5.3.2      Collect comments
        3. 5.3.3      Develop the final segment blueprint
      4. Communications Considerations:
      5. Activity Outputs:
      6. Suggested Analytical Techniques
    4. Activity 5.4:  Brief core team and obtain approval
      1. Activity Description:
      2. Activity Inputs:
      3. Tasks:
        1. 5.4.1      Distribute final review materials
        2. 5.4.2      Conduct review and obtain approval
      4. Communications Considerations:
      5. Activity Outputs:
      6. Suggested Analytical Techniques:
  28. Step References
  29. 4. Outputs and Suggested Analytical Techniques
  30. 5. FSAM Data Model
    1. Background
    2. Table 1 :  EASR/FSAM Artifact Alignment
    3. Purpose and Scope of the FSAM Logical Data Model
    4. References
    5. FSAM Logical Data Model
      1. Figure 1:  FSAM Logical Data Model
      2. Table 2:  FSAM/Exhibit 53 Crosswalk
      3. Table 3:  FSAM/Exhibit 300 Crosswalk
      4. Table 4:  FSAM/Enterprise Architecture Segment Report (EASR) Crosswalk

EDIT STEPS 2-5

 

  1. 1. Executive Overview
    1. Background
    2. Top-Level Overview of the FSAM
      1. Figure 1: FSAM High-Level Overview
    3. Segment Sizing and Timing
      1. Table 1: Segment Sizing Guide
      2. Table 2: Target Duration for Completing FSAM Steps
    4. Structure of the FSAM Guidance
      1. Figure 2: FSAM Process Steps, Activities, and Tasks
      2. Table 3 : Structure of the FSAM Guidance Document
    5. FSAM Suggested Analytical Techniques
    6. Conclusion
    7. References
    8. Appendix I: Summary of FSAM Outputs
      1. Summary of FSAM Outputs and Suggested Analytical Techniques
  2. 2. FSAM Contributors
    1. Contributing Agencies and Assessed Best Practices:
    2. FSAWG Core Team Members
    3. FSAWG Sub-Team Members
  3. 3. Process Step Guidance Documents
    1. Figure 1: FSAM High-Level Overview
    2. Process Step Guidance Documents
    3. Structure of the FSAM Guidance Document
    4. Step 1: Determine Participants and Launch Project
      1. Step Description and Purpose
      2. Step Outcome
      3. Suggested Analytical Techniques
      4. Step 1 At-a-Glance
      5. Activity Details
        1. Activity 1.1:  Determine the executive sponsor
          1. Activity Description:
          2. Activity 1.1:  Determine the executive sponsor
        2. Activity Inputs:
        3. Tasks:
          1. 1.1.1      Identify the segment governance framework
          2. 1.1.2      Communicate to business owner(s) the role of the executive sponsor
          3. 1.1.3      Determine the most appropriate executive to be executive sponsor
        4. Considerations for Enterprise Services:
        5. Communications Considerations:
        6. Activity Outputs:
        7. Suggested Analytical Techniques
      6. Activity 1.2:  Develop the purpose statement for the segment
        1. Activity Description:
          1. Activity 1.2:  Develop the purpose statement for the segment
        2. Activity Inputs:
        3. Activity Tasks:
          1. 1.2.1      Discuss the business challenges facing each business owner
          2. 1.2.2      Synthesize the common business challenges across the business owners
          3. 1.2.3      Communicate how segment architecture could assist with common business challenges
        4. Communications Considerations:
        5. Activity Outputs:
        6. Suggested Analytical Techniques
      7. Activity 1.3:  Solicit core team members
        1. Activity Description:
          1. Activity 1.3:  Solicit core team members
        2. Activity Inputs:
        3. Activity Tasks:
          1. 1.3.1      Communicate to business owner(s) the role of the core team
          2. 1.3.2      Determine personnel to be appointed to the core team
          3. 1.3.3      Communicate appointments to the affected personnel
          4. 1.3.4      Issue a memorandum to communicate the formation of the core team and the purpose statement
        4. Communications Considerations:
        5. Activity Outputs:
        6. Suggested Analytical Techniques
      8. Activity 1.4:  Create core team charter and project plan
        1. Activity Description:
          1. Activity 1.4:  Create core team charter and project plan
        2. Activity Inputs:
        3. Activity Tasks:
          1. 1.4.1      Develop draft core team charter
          2. 1.4.2      Create project plan for segment architecture development
          3. 1.4.3      Review and approve core team charter, project plan and governance
        4. Communications Considerations:
        5. Activity Outputs:
        6. Suggested Analytical Techniques
      9. Activity 1.5: Establish the communications strategy
        1. Activity Description:
          1. Activity 1.5:  Establish the communications strategy
        2. Activity Inputs:
        3. Activity Tasks:
          1. 1.5.1      Determine communications goals and objectives
          2. 1.5.2      Identify audience groups and design themes and key messages
          3. 1.5.4      Implement project collaboration website
        4. Communications Considerations:
        5. Activity Outputs:
        6. Suggested Analytical Techniques
      10. Step References
    5. Step 2: Define the Segment Scope and Strategic Intent
  4. Step Description and Purpose
  5. Step Outcome
  6. Suggested Analytical Techniques
  7. Step 2 At-a-Glance
  8. Activity Details
    1. Activity 2.1:  Establish segment scope and context
      1. Activity Description:
      2. Activity Inputs:
      3. Tasks:
        1. 2.1.1      Review segment architecture development purpose statement
        2. 2.1.2      Identify organization components
        3. 2.1.3      Identify stakeholders
        4. 2.1.4      Establish segment summary description
        5. 2.1.5      Validate / approve segment scope and context
        6. 2.1.6      Optional Task — Refine / update scope and context
      4. Communications Considerations:
      5. Activity Outputs:
      6. Suggested Analytical Techniques
    2. Activity 2.2:  Identify and prioritize strategic improvement opportunities
      1. Activity Description:
      2. Activity Inputs:
      3. Tasks:
        1. 2.2.1      Review segment scope and context
        2. 2.2.2      Determine stakeholders' needs
        3. 2.2.3      Identify segment risks and impacts
        4. 2.2.4      Identify performance gaps
        5. 2.2.5      Formulate and prioritize business needs
        6. 2.2.6      Formulate and prioritize strategic improvement opportunities
        7. 2.2.7      Validate strategic improvement opportunities
      4. Considerations for Enterprise Services:
      5. Considerations for Business Services:
      6. Communications Considerations:
      7. Activity Outputs:
      8. Suggested Analytical Techniques
    3. Activity 2.3:  Define segment strategic intent
      1. Activity Description:
      2. Activity Inputs:
      3. Activity Tasks:
        1. 2.3.1      Describe segment target state vision
        2. 2.3.2      Establish segment's strategic performance
        3. 2.3.3      Identify target maturity levels for common / mission services
        4. 2.3.4      Document the strategic intent
      4. Communications Considerations:
      5. Activity Outputs:
      6. Suggested Analytical Techniques
    4. Activity 2.4:  Validate and communicate the scope and strategic intent
      1. Activity Description:
      2. Activity Inputs:
      3. Activity Tasks:
        1. 2.4.1      Package the scope and strategic intent
        2. 2.4.2      Present the scope and strategic intent for approval
      4. Communications Considerations:
      5. Activity Outputs:
      6. Suggested Analytical Techniques:
  9. Step References
    1. Step 3: Define Business and Information Requirements
  10. Step Description and Purpose
  11. Suggested Analytical Techniques
  12. Step Outcome
  13. Step 3 At-a-Glance
  14. Activity Details
    1. Activity 3.1:  Determine current business and information environment associated with strategic improvement opportunities
      1. Activity Description:
      2. Activity Inputs:
      3. Tasks:
        1. 3.1.1      Determine the value chains for the common / mission services
        2. 3.1.2      Define the business function model and associate it to the value chain
        3. 3.1.3      Analyze existing IT investments that relate to the business processes
        4. 3.1.4      Analyze business processes and determine high-level information requirements, including organizational relationships
        5. 3.1.5      Assess current information sources
      4. Considerations for Enterprise Services:
      5. Considerations for Business Services:
      6. Communications Considerations:
      7. Activity Outputs:
      8. Suggested Analytical Techniques
    2. Activity 3.2:  Determine business and information improvement opportunities
      1. Activity Description:
      2. Activity Inputs:
      3. Tasks:
        1. 3.2.1                  Align strategic improvement opportunities to the business architecture
        2. 3.2.2                  Determine the required adjustments to the business architecture
        3. 3.2.3      Align strategic improvement opportunities to the data architecture
        4. 3.2.4      Determine the required adjustments to the data architecture
      4. Communications Considerations:
      5. Activity Outputs:
      6. Suggested Analytical Techniques
    3. Activity 3.3:  Define target business and data architectures
      1. Activity Description:
      2. Activity Inputs:
      3. Tasks:
        1. 3.3.1      Define target business processes and their performance including organizational relationships
        2. 3.3.2      Define target data relationships and business data stewards
        3. 3.3.3      Define the target information services
        4. 3.3.4      Ensure target business and data architectures addresses strategic improvement opportunities
      4. Considerations for Enterprise Services:
      5. Considerations for Business Services:
      6. Communications Considerations:
      7. Activity Outputs:
      8. Suggested Analytical Techniques
    4. Activity 3.4:  Validate and communicate target business and data architectures
      1. Activity Description:
      2. Activity Inputs:
      3. Tasks:
        1. 3.4.1      Package business and data architectures
        2. 3.4.2      Present business and data architectures for approval
      4. Communications Considerations:
      5. Activity Outputs:
      6. Suggested Analytical Techniques:
  15. Step References
    1. Step 4: Define the Conceptual Solution Architecture
  16. Step Description and Purpose
  17. Step Outcome
  18. Suggested Analytical Techniques
  19. Step At-a-Glance
  20. Step 4 At-a-Glance
  21. Activity Details
    1. Activity 4.1:  Assess systems and technology environment for alignment with performance, business, and information requirements
      1. Activity Description:
      2. Activity Inputs:
      3. Tasks:
        1. 4.1.1      Collect information on existing segment system and service capabilities
        2. 4.1.2      Define the as-is conceptual solution architecture
        3. 4.1.3      Assess business value and performance of systems and services
        4. 4.1.4      Determine adjustments necessary to the as-is conceptual solution architecture
      4. Communications Considerations:
      5. Activity Outputs:
      6. Suggested Analytical Techniques
    2. Activity 4.2:  Define the target conceptual solution architecture
      1. Activity Description:
      2. Activity Inputs:
        1. 4.2.1      Identify service and solution reuse opportunities
        2. 4.2.2      Define applicable high-level technology, service, and information standards
        3. 4.2.3      Identify required target system and service components
        4. 4.2.4      Define relationships between target systems and services
      3. Considerations for Enterprise Services:
      4. Considerations for Business Services:
      5. Communications Considerations:
      6. Activity Outputs:
      7. Suggested Analytical Techniques
      8. Target conceptual solution architecture
      9. Target Service  Component Architecture
      10. Target Technical Architecture
      11. Integrated service component and  technology model
      12. Reuse Summary
      13. Data Reuse
    3. Activity 4.3:  Identify and analyze system and service transition dependencies
      1. Activity Description:
      2. Activity Inputs:
        1. 4.3.1      Identify and analyze alternatives for transition
        2. 4.3.2      Develop recommendations outlining selected alternatives
      3. Communications Considerations:
      4. Activity Outputs:
      5. Suggested Analytical Techniques
    4. Activity 4.4:  Validate and communicate the conceptual solution architecture
      1. Activity Description:
      2. Activity Inputs:
      3. Activity Tasks:
        1. 4.4.1      Package the conceptual solution architecture
        2. 4.4.2      Present the conceptual solution architecture for approval
      4. Communications Considerations:
      5. Activity Outputs:
      6. Suggested Analytical Techniques:
  22. Step References
    1. Step 5: Author the Modernization Blueprint
  23. Step Description and Purpose
  24. Step Outcome
  25. Suggested Analytical Techniques
  26. Step 5 At-a-Glance
  27. Activity Details
    1. Activity 5.1:  Perform cost / value / risk analysis to develop implementation recommendations
      1. Activity Description:
      2. Activity Inputs:
      3. Tasks:
        1. 5.1.1      Identify findings
        2. 5.1.2      Develop transition options
        3. 5.1.3      Perform cost / value / risk analysis to compare transition options
        4. 5.1.4      Develop prioritized implementation recommendations
        5. 5.1.5      Develop lessons learned
      4. Communications Considerations:
      5. Activity Outputs:
      6. Suggested Analytical Techniques
    2. Activity 5.2:  Develop draft blueprint and sequencing plan
      1. Activity Description:
      2. Activity Inputs:
      3. Tasks:
        1. 5.2.1      Develop the draft work breakdown structure
        2. 5.2.2      Develop the draft sequencing plan
        3. 5.2.3      Develop the draft segment blueprint
      4. Communications Considerations:
      5. Activity Outputs:
      6. Suggested Analytical Techniques
      7. Segment Blueprint Sample Outline
    3. Activity 5.3:  Review and finalize the blueprint and sequencing plan
      1. Activity Description:
      2. Activity Inputs:
      3. Tasks:
        1. 5.3.1      Distribute the draft segment blueprint for review
        2. 5.3.2      Collect comments
        3. 5.3.3      Develop the final segment blueprint
      4. Communications Considerations:
      5. Activity Outputs:
      6. Suggested Analytical Techniques
    4. Activity 5.4:  Brief core team and obtain approval
      1. Activity Description:
      2. Activity Inputs:
      3. Tasks:
        1. 5.4.1      Distribute final review materials
        2. 5.4.2      Conduct review and obtain approval
      4. Communications Considerations:
      5. Activity Outputs:
      6. Suggested Analytical Techniques:
  28. Step References
  29. 4. Outputs and Suggested Analytical Techniques
  30. 5. FSAM Data Model
    1. Background
    2. Table 1 :  EASR/FSAM Artifact Alignment
    3. Purpose and Scope of the FSAM Logical Data Model
    4. References
    5. FSAM Logical Data Model
      1. Figure 1:  FSAM Logical Data Model
      2. Table 2:  FSAM/Exhibit 53 Crosswalk
      3. Table 3:  FSAM/Exhibit 300 Crosswalk
      4. Table 4:  FSAM/Enterprise Architecture Segment Report (EASR) Crosswalk
See Model for Performance-driven Government (MPG)
 
 
The FSAM is available as an online toolkit for agencies to download and use in developing segment architecture throughout their respective organizations. The toolkit includes the step-by-step guidance documents that describe the process steps, related activities, and specific tasks for developing a complete segment architecture. In addition, the toolkit includes best practice examples and templates for suggested analytical techniques that can be used when developing segment architectures.
 

1. Executive Overview

http://www.fsam.gov/federal-segment-architecture-methodology-toolkit/overview.php

Background

In January 2008, the Federal Segment Architecture Working Group (FSAWG) was formed as a sub-team of the Federal CIO Council's Architecture and Infrastructure Committee (AIC). The FSAWG consists of federal agency architects who volunteered to leverage existing enterprise architecture (EA) best practices to develop a standard methodology for creating and using segment architectures. The FSAWG developed the Federal Segment Architecture Methodology (FSAM), a step-by-step process that includes best practices from across the federal EA community. The FSAM features easy-to-use templates that expedite architecture development and maximize architecture use. The FSAM includes step by step guidance based on business-driven, results-oriented architecture.

According to the Office of Management and Budget (OMB) Federal Enterprise Architecture (FEA) Practice Guidance, segment architecture is a "detailed results-oriented architecture (baseline and target) and a transition strategy for a portion or segment of the enterprise."  The FSAM supports all three segment types as defined in the OMB FEA Practice Guidance:  core mission area, business service, and enterprise service segments.  According to the OMB FEA Practice Guidance:

A core mission area segment represents a unique service area defining the mission or purpose of the agency. Core mission areas are defined by the agency business model (e.g., tactical defense, air transportation, energy supply, pollution prevention and control, and emergency response).

A business service segment includes common or shared business services supporting the core mission areas. Business services are defined by the agency business model and include the foundational mechanisms and back office services used to achieve the purpose of the agency (e.g., inspections and auditing, program monitoring, human resource management, and financial management).

An enterprise service segment includes common or shared IT services supporting core mission areas and business services. Enterprise services are defined by the agency service model and include the applications and service components used to achieve the purpose of the agency (e.g., knowledge management, records management, mapping/GIS, business intelligence, and reporting).

The FSAM consists of process steps for developing a core mission area segment architecture. The FSAM also includes guidance for tailoring the approach to develop business service and enterprise service segment architectures.

The FSAM is based on the principle that segment architecture development should be driven by segment leadership . FSAM is a scalable and repeatable process designed to help architects engage segment leaders to deliver value-added plans for improved mission delivery. Specifically, FSAM includes guidance to help architects establish clear relationships among strategic goals, detailed business / information management requirements, and measurable performance improvements within the segment. The FSAM helps architects ensure that a well constructed and defensible plan of action is developed in partnership with segment leaders.

The FSAWG members recognized that differences between individual segments and organizations would require FSAM to be flexible and extensible. The FSAWG members were careful to consider types of architectures as well as the need for agencies to develop and implement segment architectures that reflect their unique mission requirements and organizational cultures. Although the FSAM is prescriptive, it has been designed to allow organization and segment specific adaptations. For example, although templates are included in the FSAM, these templates can be modified or tailored to the specific needs of the organization or segment using the FSAM guidance. As a further benefit to architects, the FSAM provides suggested analytical techniques designed to conform to segment reporting requirements as identified by the OMB FEA Program Management Office (PMO).

Top-Level Overview of the FSAM

The FSAM top level consists of five process steps that help architects identify and validate the business need and scope of the architecture, define the performance improvement opportunities within the segment, and to define the target business, data, services, and technology architecture layers required to achieve the performance improvement opportunities. The FSAM process steps conclude with the creation of a modernization blueprint document that includes a transition sequencing plan for using and implementing the segment architecture. The top level FSAM process steps are shown in Figure 1.

Figure 1: FSAM High-Level Overview
This graphic shows the high-level process steps for FSAM.

The OMB FEA Practice Guidance requires each agency to prioritize its segments and select a segment to architect. Once this is completed, the agency's architects can leverage the FSAM to work with segment leadership to assign executive sponsorship, ensure participation of business owners, and develop a business-owner-approved segment architecture blueprint. Each of the FSAM process steps is important in the development of a complete and actionable segment architecture. In order for the segment architecture to be "actionable", it must include specific, measurable milestones and deliverables that, once achieved, will lead to the targeted performance improvements. The five FSAM process steps are:

  1. Determine Participants and Launch the Project: The architect leverages the guidance in this process step to engage with key stakeholders to establish the segment governance framework, validate the business owner(s) for the segment, formally appoint an executive sponsor and a core team, and establish the purpose statement to guide the architecture development. This process step also includes guidance for introducing a solid project management foundation for the segment architecture development effort with the creation of a project plan and communications strategy. Key questions addressed within this process step are similar to those that one might normally ask when initiating a project:
    • What is the governance framework for the development of the segment architecture?
    • Does the business owner(s) understand the process and time commitment for developing the segment architecture?
    • Who is the executive sponsor?
    • Who is on the core team? Are these the right people?
    • What is the specific purpose for developing this segment architecture?
    • Is the charter approved to develop the segment architecture in the context of the purpose statement crafted by the business owner(s)?
    • Is there a project plan and communications strategy for the development of the segment architecture?
  2. Define the Segment Scope and Strategic Intent: The architect leverages the guidance in this process step to engage with key stakeholders to produce a segment scope and to define the strategic improvement opportunities for the segment. The architect then defines the segment strategic intent which consists of the target state vision, performance goals, and common / mission services and their target maturity levels. The subsequent FSAM process steps provide guidance for architects to align the architecture with the strategic intent to create a complete segment performance line-of-sight and to support achieving the target state vision. Key questions addressed within this process step include:
    • Based on the high-level problem statement, what are the strategic improvement opportunities and gaps?
    • What are the major common / mission services associated with the strategic improvement opportunities?
    • Who are the segment stakeholders and what are their needs?
    • What is the scope of the segment architecture?
    • What are the current segment investments, systems, and resources?
    • What are the deficiencies or inhibitors to success within the segment?
    • What is the target state vision for the segment?
    • What is the performance architecture for achieving the target state vision? 
  3. Define Business and Information Requirements: The architect leverages the guidance in this process step to engage with key stakeholders to analyze the segment business and information environments and determine the business and information improvement opportunities that will achieve the target performance architecture. Within this step, the architect begins with by developing a broad, holistic view of the overall business and information requirements associated with the strategic improvement opportunities identified in the previous step. Information requirements include the information exchanges that relate to the critical business processes associated with the performance improvement opportunities. The business and data architectures are derived from these requirements. The business and data architectures developed at the end of this step may include the specification of business and information services respectively, and should be sufficiently complete and actionable to result in more efficient processes and allocation of resources. Key questions addressed within this step include:
    • How well does the current (as-is) business and information environment meet the needs of the segment stakeholders?
    • How should the target business and information environment be designed?
    • Have the segment's goals and performance objectives been translated into actionable and realistic target business and data architectures expressed within business functions, business processes, and information requirements?
    • Have the business and information requirements been analyzed and documented to the lowest level of detail necessary to form actionable recommendations?
    • Did the business and information analysis provide a synchronized and cohesive set of recommendations?
    • Does the core team understand the adjustments that are required for the current business and information environments to fulfill the target performance architecture? 
  4. Define the Conceptual Solution Architecture: The architect leverages the guidance in this process step to engage with key stakeholders to produce the conceptual solution architecture. The conceptual solution architecture is an integrated view of the combined systems, services, and technology architectures that support the target performance, business, and data architectures developed in the preceding process steps. This process step also includes guidance for developing recommendations for transitioning from the current (as-is) state to the target state. The conceptual solution architecture produced at the end of this step is of benefit to segment and solution architects as well as to downstream capital planning and budget personnel. Key questions addressed within this step include:
    • What existing systems and services are deployed within the as-is conceptual solution architecture?
    • How well do the existing systems and services currently support the mission? 
    • Which systems and services should be considered for retirement and / or consolidation?
    • How should the target conceptual architecture be designed to fulfill the target performance architecture?
    • Are the selected target systems, components, and services reusable?
    • Does the conceptual solution architecture support the target performance, business, and data architectures developed in prior steps?
    • Have the dependencies, constraints, risks, and issues associated with the transition been analyzed to identify alternatives to be considered?
    • Are there existing external services (e.g. FTF services) that can be leveraged in the target architecture?
  5. Author the Modernization Blueprint: The architect leverages outputs from previous process steps to engage with key stakeholders to create a segment architecture blueprint including sequencing and transition plans. The outcome of this process step is a series of validated implementation recommendations supported by holistic analysis of segment business, data, technology, systems, and service components. The modernization blueprint includes findings and recommendations as well as supporting artifacts and diagrams that illustrate the analysis performed throughout the architecture development process. For instance, artifacts such as the SWOT analysis and the conceptual solution architecture are key visuals in the modernization blueprint. Note that recommendations in the modernization blueprint typically span a strategic time horizon on the order of 3-5 years. Key questions addressed within this step include:
    • Have the strategic improvement opportunities from process step 2 been supported in the analysis, recommendations, and transition planning?
    • Have the findings from the previous process steps been identified, categorized, and prioritized?
    • Have the transition options been analyzed for costs, benefits, and risks in order to develop recommendations for implementation?
    • Are the recommendations clearly described in the blueprint?
    • Has the blueprint and sequencing plan been reviewed and approved by the executive sponsor, business owner(s), and core team?

The FSAM has been designed to assist architects as they develop and use actionable segment architectures. The outputs from the FSAM have also been designed specifically for use within other downstream processes, including investment management, enterprise transition planning, solution architecture development, and system lifecycle management.

Segment Sizing and Timing

The annual timing of segment architecture development is critical as the federal government has annual deadlines for capital planning and budget processes that impact the use and implementation of the architecture. Understanding a segment's size and complexity prior to beginning a segment architecture development effort can help the team determine the overall duration and level of effort expected. Such estimates also enable an agency's EA program to estimate the resources that may be required to support the development of a specific segment architecture. Table 1 provides an example of how an agency could determine the size and complexity of a specific segment.

Table 1: Segment Sizing Guide

 
Segment Evaluation Factors Segment Size
Small Medium Large
Number of associated internal organizations / agencies 1 1-3 >3
Number of associated external organizations / agencies 0-1 1-3 > 3
Number of service types within the segment 1-5 6-10 > 10
Number of major investments within the segment 1-2 2-5 >5
Segment information technology (IT) budget as a percentage of overall agency annual IT budget < 5% 5%-10% >10%
Segment budget as a percentage of overall agency annual budget <1% 1%-2% >2%

These segment sizing factors are not intended to be an exhaustive list but to be leveraged as a starting point for agencies in determining the anticipated level of effort when undertaking a segment architecture development. Table 2 provides potential target durations for architecting segments of different sizes and complexity (Steps 2 through 5). There is no exact science to determine segment size. Expert judgment and available historical information should be used when multiple categorizations are identified based on the recommended segment sizing factors. EA organizations should work to build their capabilities and optimize their efficiencies toward achieving these durations. Since Step 1 is associated with establishing the overall segment governance, the duration of this step is driven primarily by organizational complexity and is less dependent upon other segment-sizing parameters. Therefore, estimates of the time required to complete Step 1 are not provided as they can vary greatly, irrespective of segment size.

Table 2: Target Duration for Completing FSAM Steps

 
FSAM Steps Target Duration
Small Medium Large
Step 1 Depends on organizational complexity
Step 2 2-4 wks 4-6 wks 6-8 wks
Step 3 2-6 wks 4-8 wks 6-10 wks
Step 4 2-6 wks 4-8 wks 6-10 wks
Step 5 2-4 wks 4-6 wks 6-8 wks
Total (Step 2 thru 5) 8-20 wks 16-28 wks 24-36 wks

Note: This table provides rough order of magnitude duration estimates for completing a segment architecture. The actual duration will depend on the availability of resources, the level of general EA and facilitation skills, and overall knowledge of FSAM. More accurate targets can be derived based on historical information and past performance from the organization's actual segment architecture development efforts.

Structure of the FSAM Guidance

The FSAM is structured with three levels of decomposition: process steps, activities, and tasks. The process steps, activities, and tasks are presented in an online toolkit containing guidance documents as well as analytical templates designed to expedite the development of segment architectures. Figure 2 shows an example of the three levels of decomposition, including the high-level process steps, activities a process step, and tasks within an activity.

 

Figure 2: FSAM Process Steps, Activities, and Tasks

Graphic is Figure 2 and shows an example of the three levels of decomposition, including the high-level process steps, activities process steps, and tasks within an activity.

 

The FSAM guidance consists of five process step guidance documents that include detailed descriptions of the associated activities and tasks. The guidance documents follow a uniform structure that includes the elements described in Table 3.

Table 3 : Structure of the FSAM Guidance Document

 
FSAM Guidance Document Element Description
Step Description and Purpose This section explains the overall purpose of the process step and provides an overview of the process step.
Step Outcome The step outcome summarizes the overall expected result when the step is completed.
Step At-A-Glance The step-at-a-glance is a summary table of the process step and associated activities, including the participants and stakeholders involved in each activity and the inputs and outputs for each activity. The table also highlights any touch points with other key documents, including National Institute of Standards and Technology (NIST) 800-39, the Federal Transition Framework (FTF), and Practical Guide to Federal Service Oriented Architecture (PGFSOA), as well as any associated Federal Enterprise Architecture (FEA) Profiles. The at-a-glance table also has links to key considerations for architects that are developing enterprise and business service segment architectures and an indication of the overall level of complexity of each activity.
Activity Details Activity details provide a detailed description of each activity in the process step.
Activity Short Description Each activity is explained in a short summary description.
Activity Flow Chart with Tasks Each activity also has a task-level diagram that illustrates the relationship of the tasks within the activity.
Activity Inputs Inputs are defined for each activity and represent information that should be available or collected before starting the activity. In many cases, inputs to a given activity correspond to the outputs of a preceding activity.
Tasks A description of each task within the activity is provided.
Communication Considerations Communication considerations include additional guidance related to key messaging associated with managing stakeholder expectations, gaining buy-in to recommendations, and other items for the architect to consider.
Enterprise Services Considerations This section contains additional guidance to be applied when architecting an enterprise services segment.
Business Services Considerations This section contains additional guidance to be applied when architecting a business services segment.
Activity Outputs Outputs are defined for each activity and represent the resulting architectural information produced by the corresponding activity.
Suggested Analytical Techniques (with examples and templates) For each output, suggested analytical techniques and corresponding examples and templates are provided based on best practices of contributing agencies.

FSAM Suggested Analytical Techniques

The FSAM includes a comprehensive toolbox of suggested analytical techniques as summarized in Appendix I. Analytical techniques are provided for the outputs of each activity, as defined in FSAM, and are based on agency best practices that were assessed for inclusion by the FSAWG.

Appendix I identifies those outputs that are considered "core FSAM outputs." The "core" designation suggests that the outputs deliver a complete segment architecture, as defined in the OMB EAAF v3.0 reporting requirements. All mappings defined in Appendix I are based on the data attributes as defined for each output in the corresponding suggested analytical techniques.

Appendix I also identifies which FSAM outputs, when used with the suggested analytical techniques, either support (S) or are core (C) to satisfying key usage requirements corresponding to strategic planning, capital planning, information technology (IT) governance, EAAF reporting, solution development, and security / privacy. These additional designations are meant to assist architects with identifying opportunities for FSAM outputs to be used within other planning and decision making processes.

Conclusion

The OMB FEA Practice Guidance includes core philosophies that should be embraced by the architecture community. According to the OMB FEA Practice Guidance:

"Business-led architecture is more successful in meeting strategic goals, responding to changing mission needs, and serving citizens' expectations than technology or budget driven architecture. This principle encourages agency architects to proactively collaborate with business stakeholders to develop architecture work products for a segment. Architects must understand the current state of the business and where the business stakeholders would like to make improvements. With this shared understanding, architects and business stakeholders can work together to develop the architecture work products supporting better investment and implementation decision-making."

Within the federal EA community, the core premise that architecture is about achieving results is widely accepted. However, many architects still struggle to answer the question of "how":

  • How do I get my business community involved?
  • How do I know what to study?
  • How do I turn artifacts into decisions?
  • How do I use my resources to affect change?
  • How do I integrate EA with CPIC and solution architecture?
  • How do I drive change as a Chief Architect?

The FSAM has been designed to provide federal architecture practitioners with an approach to answering these "how" questions in order to achieve results. Using the FSAM step-by-step, repeatable process, the EA community can resolve the "how" questions, and proactively engage segment leaders in transformation planning to produce actionable plans that lead to measurable results.

References

"Value to the Mission," Federal Enterprise Architecture (FEA) Practice Guidance pdf, Federal Enterprise Architecture Program, Management Office, Office of Management and Budget, December 2006

Improving Agency Performance Using Technology, Enterprise Architecture Assessment Framework v3.0, Federal Enterprise Architecture Program, Management Office, Office of Management and Budget, July 2008 [Draft]

Appendix I: Summary of FSAM OutputsEdit section

Summary of FSAM Outputs and Suggested Analytical Techniques

 
Process
Step
Output FSAM Core Output (Y/N)? Support for Existing Mandatory Requirements and Management Processes
(C=Core, S=Supports)
Suggested 
Analytical
Technique
Stategic Planning
Capital Planning /Budget
Mission / IT Governance
EAAF Reporting
Solution Development
Security /Privacy
Value Provided
Step 1 Governance framework No     S       Identifies key roles and responsibilities for segment architecture development and shows relationships to existing governance bodies. Governance framework
Step 1 Segment architecture development purpose statement Yes S S C C     Articulates the issues that the segment architecture will address.  Guides the core team in the development of the segment architecture. Segment architecture development purpose statement
Step 1 Core team roster No     S       Identifies core team and provides organizational and contact information. Core team roster
Step 1 Core team formation memorandum No     S       Communicates the existence of the core team, its members, and its purpose. Core team formation memorandum
Step 1 Core team charter No     S       Establishes the authority of the project, roles and responsibilities, operational ground rules, decision-making structure, preliminary scope, and stated objectives and goals. Core team charter
Step 1 Project plan No     C       Guides the segment architecture development process and ensures timely delivery. Project plan
Step 1 Communications strategy No     C       Identifies core stakeholders and ensures that messaging requirements for all stakeholders have been identified and planning for key communications has been accomplished. Communications strategy
Step 2 Stakeholders and their relationships Yes S   S S     Identifies the appropriate stakeholders and the relationships between them and the servicing organization.  Ensures the inclusion of all relevant perspectives on how to overcome the business challenges identified in the segment purpose statement. Stakeholder map
Step 2 Business drivers and mandates Yes S   C       Provides the foundation from which the segment's performance line-of-sight will be built, demonstrating the linkage to the strategic, business, and investment improvement opportunities identified in subsequent steps. Driver and policy map
Step 2 Segment scope Yes     C S     Helps build consensus within the core team on the range of strategic improvement opportunities and helps focus core team working sessions. Segment summary
Step 2 Segment context No     S S     Provides a visual context diagram corresponding to the segment scope. Current operating environment diagram
Step 2 Stakeholder needs No     S       Provides the basis for formulating the consolidated business needs of the segment. Stakeholder needs
Step 2 Risks and impacts No    S S   S S Identifies potential high-level risks and impacts associated with the segment scope and context, including risks not addressed optimally by the current environment. Risk capture template
Step 2 Performance gaps Yes S S C S S S Identifies current state performance gaps in order to facilitate prioritization of performance improvement opportunities. Performance gap analysis
Step 2 Strategic improvement opportunities Yes S S C S S  S Identifies internal and external factors which affect the achievement of the segment purpose statement.  Prioritizes performance improvement opportunities and aligns them with the business needs of the organization as a whole. SWOT analysis
Step 2 Segment performance goals and objectives Yes S S C S S S Establishes the key performance indicators, measures, and metrics that will be used to measure the achievement of segment goals and vision. Strategic alignment of opportunities
Step 2 Common / mission services target maturity levels No S   S       Establishes the target maturity levels required to achieve the segment vision according to segment strategic performance goals and objectives. Common / mission services maturity framework
Step 2 Segment architecture vision summary No  S    S       Summarizes the purpose, scope, mission and target vision for the segment, in text and visual forms. Segment summary
Step 2 Performance scorecard Yes  S C S C S S Includes strategic, business, program and segment performance data.  Conforms to EAAF 3.0 reporting requirements Performance scorecard
Step 3 As-is business value chain No     S S S S Identifies the high-level logical ordering of the chain of processes that deliver value. As-is business value chain analysis
Step 3 As-is business function model Yes       S S S Identifies the business functions that will be affected by potential process improvements.  Ensures that processes are analyzed in context with the correct business functions and that appropriate mappings to the FEA BRM are established. As-is business function model
Step 3 As-is key business process model No       S S S Defines processes that may require process optimization.  Assists in determining high-level information and information security requirements. As-is business activity model
Step 3 As-is business process swim lane diagram No       S S S Defines processes that may require process optimization.  Assists in determining high-level information and information security requirements. As-is business process swim lane diagram
Step 3 As-is key information sources and qualitative assessment No       S S S Documents the sources of information in the current state and determines the most trusted sources of data by information class and data entity. Authoritative Data Source (ADS) candidate qualitative analysis matrix
Step 3 Business and data architecture adjustment profiles No S S   S S S Groups related opportunities and formally documents the limitations of the current state, desired characteristics of the target state, how the target state will help achieve strategic improvement opportunities, and risk and cost considerations. Business and data architecture adjustment profiles
Step 3 Target business value chain diagram No S S   S S S Identifies differences in the processes that are currently being provided between the current and target states.  Helps determine where new processes are required and where existing processes may no longer be necessary. Target business value chain analysis
Step 3 Target business function model Yes       C C C Identifies the business functions that will be affected by potential process improvements.  Ensures that processes are analyzed in context with the correct business functions and that appropriate mappings to the FEA BRM are established. Target business function model
Step 3 Target key business process model No       S S S Defines optimized processes as required to achieve segment performance objectives.  Assists in determining high-level information and information security requirements. Target business activity model
Step 3 Target business process swim lane diagram No       S S S Defines optimized processes as required to achieve segment performance objectives.  Assists in determining high-level information and information security requirements. Target business process swim lane diagram
Step 3 Target conceptual data model Yes       C C C Provides the structure and terminology for information and data in the target environment.  Includes subject areas, information classes, key entity types, and relationships. Target conceptual data  model
Step 3 Target data steward assignments Yes       C C C Identifies the organization responsible for the creation, maintenance and quality of each information class appropriate to support business activities in the target environment. Target data steward matrix
Step 3 Target business data mapped to key business processes (CRUD) No       S S S Help identify candidate information services, including new authoritative data sources, and producers and consumers of information. CRUD matrix results table
Step 3 Target information sharing matrix Yes       S S S Assists in discovery of opportunities for re-use of information in the form of information-sharing services, within and between segments. Target information sharing matrix
Step 3 Target Information Flow Diagram Yes       S S S Assists in discovery of opportunities for re-use of information in the form of information-sharing services, within and between segments. Target information flow diagram
Step 4 As-is system and services scoring No         S Determines where adjustments to the segment systems and services architecture should be investigated. As-is systems and services description and scoring
Step 4 As-Is conceptual solution architecture Yes         C C Shows the existing systems and services in the as-is state and identifies the relationships between them.  May also include an overlay to show the boundaries of key business functions and external organizational interfaces. As-is system interface diagram
Step 4 Target conceptual solution architecture Yes    C      C  Shows the proposed systems and services in the target state and identifies the relationships between them.  May also include an overlay to show the boundaries of key business functions and external organizational interfaces. Target system interface diagram
Step 4 Target Service Component Architecture Yes    C      C Describes service components and the mechanisms for providing service delivery to customers.  Provides a framework and vocabulary for guiding discussions between service providers and consumers. Service component model (SCM)
Step 4 Target Technical Architecture Yes    C      C Shows the technology components that support service delivery for each SCM service component. Technology model
Step 4 Integrated service component and technology model No          S Shows the service-to service interaction, supporting technical components, and information flows associated with each service component.  Used to derive the TRM. Integrated service component and technology model
Step 4 Transition recommendation profile No        S Describes a recommended transition alternative.  May include intermediate target states and alternative recommendations based on multiple funding levels. Transition recommendation profile
Step 4 Transition recommendation sequencing diagram No      S    S The single, consolidated diagram that shows the transition recommendation sequencing milestones for an implementation alternative.  Transition recommendation sequencing diagram
Step 4 Reuse Summary Yes   C   C     Describes segment reuse of business, system, and service components from other segments and by other segments.  Conforms to EAAF 3.0 reporting requirements. Reuse summary
Step 4 Data Reuse Yes   C   C     Describes segment reuse of information exchange packages and data entities from other segments and by other segments.  Conforms to EAAF 3.0 reporting requirements. Data Reuse
Step 4 Recommendation Sequencing Milestones Yes   C S C     Preliminary version of the Step 5 Target Recommendation Sequencing Milestones.  Conforms to EAAF 3.0 reporting requirements. Recommendation sequencing milestones
Step 5 Analysis of cost, value and risk for transition options No      S   Informs the prioritization (selection and sequencing) of transition options to formulate a set of implementation recommendations. Value measuring methodology cost to value matrix
Step 5 Proposed implementation recommendations No        S S Comprises the set of implementation recommendations that are used to develop the recommended high-level implementation plan. Draft recommendation implementation overview visual
Step 5 Strategic systems migration / sequencing overview Yes      C  S C C The single, consolidated diagram that shows the transition recommendation sequencing recommendations for the selected implementation recommendations. Recommendation sequencing diagram
Step 5 Recommendation implementation sequencing plan No      C  S Sequencing plan that includes all tasks associated with the overall transition of business processes, systems and services to achieve the target state.  Identifies internal and external dependencies as milestones or predecessor tasks. Implementation sequencing plan
Step 5 Segment architecture blueprint document (incl. sequencing plan) Yes  S    C  S C Description of the overall segment transition plan that is focused on implementation of the business transformation recommendations.   Contains descriptions of some of the key analysis performed in prior process steps. Modernization blueprint
Step 5 Segment Mappings Yes   C   C     Provides the FEA CRM mappings for the segment and shows the relationship between the segment and its investment portfolio, PART programs supported, and government-wide FTF and e-Gov initiatives. Segment mappings
Step 5 Transition Plan Milestones Yes S C C C C C Provides the implementation and performance improvement milestones for the segment transition plan. Transition plan milestones
Step 5 Document review log No           A log used to collect review comments and change requests for the segment architecture blueprint. Document review form
Step 5 Feedback tracking document and feedback action report No      S       A log used to record feedback and document and track follow-up actions. Feedback tracking and action report
 

2. FSAM Contributors

http://www.fsam.gov/about-federal-segment-architecture-methodology.php#contributing

Contributing Agencies and Assessed Best Practices:

The Federal Segment Architecture Methodology (FSAM) was produced by the Federal Segment Architecture Working Group (FSAWG). The FSAWG was formed in January 2008 as a sub-team to the Architecture and Infrastructure Committee (AIC), a committee that reports to the Federal CIO Council. The FSAWG was formed at the request of the Chief Architect, from the Office of Management and Budget (OMB).

Over 50 volunteers representing government and industry contributed to the collaboration that produced the FSAM. This methodology represents a significant accomplishment in moving segment architecture development towards a repeatable process in support of improving federal agencys' mission execution and service delivery to our citizens and business partners. The FSAWG consisted of the following voting members:

FSAWG Core Team Members

 
Government Core Team Member Agency
Colleen Coggins (FSAWG Chair) Department of the Interior (DOI)
Kshemendra Paul Office of Management and Budget (OMB)
Rich VonBostel Department of Justice (DOJ)
David Prompovitch Department of Transportation (DOT)
Janet Gentry Department of the Treasury (Treasury)
Walt Okon Department of Defense (DoD)
Ken Clark Representative from Program Manager for the Information Sharing Environment (PM-ISE)
Ylanda Ford Housing and Urban Development (HUD)
Marlene Howze Department of Labor (DOL)
Lisa Jenkins Environmental Protection Agency (EPA)
Kunal Suryavanshi (contractor) Office of Personnel Management — Human Resources Line of Business (HR-LOB)
John Teeter Department of Health and Human Services (HHS)
Donna Roy Department of Homeland Security (DHS)

In addition to the FSAWG Core Team, a larger working team of staff members was established under the direction of the FSAM Core Team and met on a weekly basis. The FSAWG Sub-Team consisted of the following members:

FSAWG Sub-Team Members

 
Sub-Team Member Agency Contractor?
Suzanne Acar DOI  
John Antlitz HHS  
Graham Barrowman HUD Yes
Scott Bernard DOT — Federal Railroad Administration (FRA)  
Emile Beshai Treasury  
Tim Biggert HR-LOB Yes
Carrie Boyle DOJ Yes
Thomas Charuhas DOI — National Park Service (NPS) Yes
Kristi Coney DoD  
Margot Delapp DISA DoD Yes
Cynthia Dittmar DHS Yes
Mark Gust EPA Yes
Adel Harris DOI Yes
Beverly Hacker DOI Yes
Ryan Kobb HR-LOB Yes
Shankar Krishnan DOJ Yes
Samuel Lampert DOJ Yes
Viesturs Lenss DOI Yes
Candyce Love PM-ISE Yes
Tinisha McMillan DoD  
Pat McNaughton DOL Yes
Heather Miller DOI Yes
James Minier Treasury Yes
Mohan Prabandham HR-LOB Yes
John Reed DOL Yes
Diane Reeves DOI  
Gail Reid PM-ISE Yes
Barbara Rice DISA DoD  
Kenya Savage PM-ISE Yes
Kevin Schmitt DOI Yes
Quinise Sherman DISA DoD  
Tom Smialowicz OMB Yes
Jerad Speigel DOI Yes
Rick Tucker DoD Yes
Laura Turbe DOI Yes
Todd Werts DOL Yes
Katrinia Whittington Treasury  

 

In addition, 18 assessed best practices were considered in the development of the FSAM. These best practices are considered the best of the best throughout the federal-government:

  • HUD — Segment Architecture Development Guidance / Work Product and Decision Templates
  • DoD — DoDAF Version 2.0 (Draft)
  • DOI — Methodology for Business Transformation (MBT)
  • DOJ — Information Sharing Segment Architecture (ISSA)
  • PM-ISE — Information Sharing Environment EA Framework
  • PM-ISE — FEA Information Sharing Environment Profile
  • DHS — Information Sharing Environment
  • DOL — EA Quick Reference Guide
  • DOL — IT Investment Management Quick Reference Guide
  • DOL — STREAMLine Methodology
  • Treasury — Segment Architecture Analysis Guide
  • Treasury — Segment Architecture Process Guide
  • Treasury — Segment Architecture Roadmap
  • HRLOB — Segment Architecture Approach
  • EPA — OSWER Segment Architecture Line-of-Sight: From Architecture through Implementation
  • HHS — HHS Architecture Development Methodology (ADM)
  • FEA — Security and Privacy Profile (v2) (Draft)
  • FEA — Records Management Profile

3. Process Step Guidance Documents

http://www.fsam.gov/federal-segment-architecture-methodology-toolkit/guidance.php

Figure 1: FSAM High-Level Overview

This graphic shows the high-level process steps for FSAM.

 

Process Step Guidance Documents

Step 1: Determine Participants and Launch Project

Step 2: Define the Segment Scope and Strategic Intent

Step 3: Define Business and Information Requirements

Step 4: Define the Conceptual Solution Architecture

Step 5: Author the Modernization BlueprintStructure of FSAM Process Step Guidance Documents

 

The FSAM guidance consists of five process step guidance documents that include detailed descriptions of the associated activities and tasks. The guidance documents follow a uniform structure that includes the elements described below.

Structure of the FSAM Guidance Document

 
FSAM Guidance Document Element Description
Step Description and Purpose This section explains the overall purpose of the process step and provides an overview of the process step.
Step Outcome The step outcome summarizes the overall expected result when the step is completed.
Step At-A-Glance The step-at-a-glance is a summary table of the process step and associated activities, including the participants and stakeholders involved in each activity and the inputs and outputs for each activity.  The table also highlights any touch points with other key documents, including National Institute of Standards and Technology (NIST) 800-39, the Federal Transition Framework (FTF), and Practical Guide to Federal Service Oriented Architecture (PGFSOA), as well as any associated Federal Enterprise Architecture (FEA) Profiles.  The at-a-glance table also has links to key considerations for architects that are developing enterprise and business service segment architectures and an indication of the overall level of complexity of each activity.
Activity Details Activity details provide a detailed description of each activity in the process step.
Activity Short Description Each activity is explained in a short summary description.
Activity Flow Chart with Tasks Each activity also has a task-level diagram that illustrates the relationship of the tasks within the activity.
Activity Inputs Inputs are defined for each activity and represent information that should be available or collected before starting the activity.  In many cases, inputs to a given activity correspond to the outputs of a preceding activity.
Tasks A description of each task within the activity is provided.
Communication Considerations Communication considerations include additional guidance related to key messaging associated with managing stakeholder expectations, gaining buy-in to recommendations, and other items for the architect to consider.
Enterprise Services Considerations This section contains additional guidance to be applied when architecting an enterprise services segment.
Business Services Considerations This section contains additional guidance to be applied when architecting a business services segment.
Activity Outputs Outputs are defined for each activity and represent the resulting architectural information produced by the corresponding activity.
Suggested Analytical Techniques (with examples and templates) For each output, suggested analytical techniques and corresponding examples and templates are provided based on best practices of contributing agencies.
 

Step 1: Determine Participants and Launch Project

http://www.fsam.gov/federal-segment-architecture-methodology-toolkit/step1.php

 

Step Description and Purpose

The methodology begins with the Determine Participants and Launch Project process step which includes activities to identify the overall governance framework for the segment architecture development, educate the business owner(s) on the process and time commitment for developing the segment architecture, select the executive sponsor, formulate a specific purpose for the segment architecture being developed, and form the core team to guide the segment architecture development. A key input to this step is a prioritized segment selected for architecture development and the identification of a segment architect who will manage the execution of the FSAM. Note that guidance for prioritizing segments is available in the OMB FEA Practice Guidance.

Once the segment is selected and the architect is assigned, the architect should begin a relationship with the business owner for the segment. Typically, the business owner is the highest-level decision maker within an organization for the segment under development. Since segment architecture may result in recommended policy or even regulatory changes to optimize business processes, it is important that the business owner has the political and organizational influence to champion and drive needed changes to effect performance improvements.

In some cases, segments span several organizations (e.g., cross-agency initiatives) and each organization may have an affected business owner and other related governance bodies. This step outlines guidance for establishing a cross-agency governance framework for creating and sustaining the segment architecture. This step also includes guidance on bringing key business owners together to achieve a common purpose, educating them on the process of segment architecture development and identifying and appointing a senior executive as executive sponsor for the project.

Also within this step is the formation of a core team. This core team is a working level body of individuals, typically at the program manager level within the segment. The core team is an important group, as these subject matter experts will guide the development of the segment architecture. The core team might also include key stakeholders and IT personnel, from security for instance. During this step, the executive sponsor solicits key personnel from each affected organization to form the core team that will remain as a standing body throughout the segment architecture development process. The formation of the core team includes the development of the core team charter that bonds the team members into active and constructive participation throughout the architecture development process. The charter formalizes the core team's participation in developing the segment architecture in the context of the purpose statement crafted by the business owner(s). It is important that the business owner(s) formulate a purpose for the architecture being created so the core team and the chosen executive sponsor have a clear understanding of what is expected in terms of high-level performance improvements.

Lastly, the Determine Participants and Launch Project step is intended to start the segment architecture development off on a solid project management foundation. This step includes guidance for developing the project plan and communications strategy; both will be used throughout the segment architecture development process.

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.

Step Outcome

The outcome of this step is to establish the segment governance framework, validate the business owner(s), formally appoint an executive sponsor and a core team, establish the purpose statement to guide the architecture development, and to establish a project plan and communications strategy.  Note:  In the case of a mission-critical segment that only affects one organization, the business owner and executive sponsor will likely be the same individual.

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 1 At-a-Glance

 
  Process Step 1 Activities
  Determine the 
executive sponsor
Develop the purpose statement for the segment Solicit core
team members
Create core team charter and 
project plan
Establish the communications strategy
Who Participates in 
This Activity?
Business owner(s)
Executive Sponsor
Segment architect
Business owner(s)
Executive sponsor
Segment architect
Executive sponsor
Segment architect
Executive sponsor
Core team
Segment architect
Executive sponsor
Core team
Segment architect
What Are The Inputs 
to This Activity?
List of affected organizations and their business owner(s) (Strategic plan and organization chart)
Agency strategic plans
Agency policies
Executive orders
Legislation 
President's budget
Preliminary list of affected PART Measures 
Preliminary list of affected PAR Measures
List of affected organizations and their business owner(s) (strategic plan and organization chart)
Agency strategic plans
Agency policies
Executive orders 
Legislation 
President's budget
Preliminary list of affected PART Measures 
Preliminary list of affected PAR Measures
Identification of the segment leadership to include affected business owner(s) and a designated Executive sponsor
Governance framework
List of affected organizations and identified business owner(s) (Strategic plan and organization chart)
Segment architecture development purpose statement
Segment architecture development purpose statement 
Core team roster
Core team formation memorandum
Core team charter
Project plan
Governance framework
What Are The Outputs from This Activity? Identification of the segment leadership to include affected business owner(s) and a designated executive sponsor.
Governance framework
Segment architecture development purpose statement Core team roster
Core team formation memorandum
Core team charter
Project plan
Communications strategy
Which Stakeholders / Customers Will Use the Outputs from This Activity? N/A Executive sponsor
Core team
Business owner(s)
Executive sponsor
Core team
Business owner(s)
Business owner(s)
Executive sponsor
Core team
Business owner(s)
Core team
Touch Points to FTF   The FTF Catalog includes mandatory initiatives that must be included in the agency EA      
What Are The Associated FEA Profiles? None None None None None
Considerations for Enterprise Services Enterprise services governance framework        
Considerations for Business Services Business services governance framework        
What Is The Relative Complexity of This Activity? 2 out of 4 1 out of 4 3 out of 4 2 out of 4 3 out of 4
Legend that shows 4 levels of increasing complexity.


Activity Details

Activity 1.1:  Determine the executive sponsor
Activity Description:

This activity begins with an overall definition of the segment governance structure. In particular, it is critical to identify up-front a comprehensive governance framework for creating and sustaining the segment architecture when developing segment architectures that span multiple agencies. This also leads to the definition of the business owner(s) for the segment who must understand the planning and resource commitments associated with developing the segment architecture. A business owner is typically a senior agency official with executive decision making authority within the segment.

Once the business owner(s) have a high level understanding of the planning concept and resource commitments, then they are ready to discuss the selection of an executive sponsor. Note that in many cases, the executive sponsor and business owner may be the same individual or an obvious choice rendering the tasks within this activity irrelevant.  However, in cross-agency initiatives, there may be several business owners involved from several organizations and it is helpful to designate an executive sponsor.

An executive sponsor should be just that — an executive who is willing to sponsor and champion the concept of transformation within the segment. The executive sponsor will be a visionary leader for the core team and will play a key decision making role in determining the direction and scope of the segment architecture findings and recommendations. The executive sponsor is in a decision-making role and should therefore be a senior official with the authority to make decisions within the segment.

During this activity, the business owner(s) should also be educated on the segment architecture process. This education can include formally meeting with the business owner(s) of the segment to communicate how their resources will be used in developing the segment architecture. This education can be used to set expectations up front so that the appropriate executive sponsor and core team can be selected.

Activity 1.1:  Determine the executive sponsor
Flowchart for Activity 1.1
Activity Inputs:
  • List of affected organizations and their business owner(s) (strategic plan and organization chart)
  • Agency strategic plans
  • Agency policies
  • Executive orders
  • Legislation
  • President's budget
  • Preliminary list of affected PART measures
  • Preliminary list of affected PAR measures
Tasks:
1.1.1      Identify the segment governance framework

The segment architect who is responsible for leading the execution of the FSAM must first work with business owners to establish a governance framework. The governance framework should identify the key roles for the segment architecture development (business owner, executive sponsor, and core team) and show the relationships to existing governance bodies that may have operational oversight over the delivery of segment mission services. This may also include specific cross-agency governance teams that will own and maintain specific layers of the segment architecture through to the implementation of solutions that support the overall segment target state vision as established by the segment architecture.

The governance framework articulates the relative accountability and authority for decision-making, ensures a consistent and well-defined approach for decision-making, provides a mechanism for adjudicating disagreements or differences in perspective and provides a definition of roles and responsibilities to ensure performance measures are met. While the roles and responsibilities of each committee in the governance framework are described in the governance framework, many existing governance bodies will likely have existing governing charters that establish overall authority, roles and responsibilities, and decision-making processes. The segment governance structure must align with existing agency governance processes including the management of the overall enterprise architecture, capital planning process, security and privacy management processes, human capital management process, quality assurance processes, and the systems development lifecycle processes.

The governance framework should also be designed to consider the additional factors driving the overall prioritization of the segment architecture development (e.g., agency strategic plans, policies, executive orders, legislation, budget priorities, and the PART and PAR program assessments).

1.1.2      Communicate to business owner(s) the role of the executive sponsor

It is important to educate the business owner(s) on the role of the executive sponsor. Some executive sponsor candidates might be more qualified than others based on the time and leadership requirements of the position. Optimally, the executive sponsor will provide visionary leadership and play an active role in shaping the direction of the segment architecture. Note that the executive sponsor should be a leader from within the segment, not an architect or an IT professional (unless the segment is an IT specific segment).

Overall, an executive sponsor should have the following characteristics:  effective communicator, senior executive, talented leader, respected within the affected organizations, visionary, good political skills, energetic, and excited about opportunities for transformation.

1.1.3      Determine the most appropriate executive to be executive sponsor

There are positive and negative aspects to being the executive sponsor for a segment architecture development. The most significant positive is to be in a position of leadership for this planning effort. The leadership position affords the executive with a unique opportunity to shape the future of the segment. The most significant negative is the dedication of time to the effort. The executive sponsor will need to be current on the actions and recommendations of the core team.  As previously mentioned, in many segments, there is just one business owner and that business owner would typically be the executive sponsor. In these cases, these tasks are not relevant. If however the segment includes multiple organizations, the business owner(s) from each organization should select the executive sponsor. In most cases involving multiple organizations within the same agency, there is a senior executive who is the natural choice to be the executive sponsor. Note that in cases involving multiple agencies, there could be several senior executives at peer levels. In these cases, it is important to designate an executive sponsor that will be representative of the segment, not a single specific organization.

Note that one of the business owner(s) may volunteer to be the executive sponsor. If there is only one volunteer, then the executive sponsor role can be considered filled. In many cases, the affected business owner(s) should come to consensus on designating the executive sponsor.

Considerations for Enterprise Services:

An enterprise service segment will typically require a governance framework that includes representation of all affected organizations / sub-agencies that will be affected.

Considerations for Business Services:

A business service segment will typically require a governance framework that includes cross- cutting representation of affected organizations and business functions.

Communications Considerations:

Engaging the business owner(s) can be difficult to schedule. It is often possible to leverage pre-existing governance teams that include these leaders in order to conduct this activity. This activity can be accomplished in one meeting with the business owner(s).

Activity Outputs:
  • Identification of the segment leadership to include affected business owner(s) and a designated executive sponsor
  • Governance framework
Suggested Analytical Techniques
 
Output Core FEA Layers Suggested Analytical Technique Examples/Templates Contributing Agency/Team
P B D S T
Governance framework No           Governance framework Governance framework word format Department of Justice (DOJ)
  Key to FEA Layers:
P = Performance
B = Business
D = Data
S = Service
T = Technology

Activity 1.2:  Develop the purpose statement for the segment

Edit sectionActivity Description:

It is critical that the business owner(s) and the executive sponsor formulate their intent for the segment architecture development.  This segment architecture intent, or purpose statement, serves to communicate to the core team the reason why the segment architecture is being created. For example, the purpose statement could be higher citizen satisfaction, lower costs, more efficient operations, addressing a GAO audit, and/or introducing a new service to citizens.

In some cases, the purpose statement can be a high-level statement of principles. In other cases, the purpose statement might be a more detailed listing of objectives and expected areas to consider. This is the opportunity to establish why this segment architecture is important and what its implementation should accomplish.

The purpose statement is particularly important for segments that span multiple organizations and have multiple business owner(s). In these instances, a purpose statement established at the start of the project provides clarity for the individuals in multiple organizations that will be participating in the project. As different organizations typically have different motivators and mandates, the establishment of a purpose statement provides clarity for the working-level project participants and establishes a common expectation across affected organizations.

Activity 1.2:  Develop the purpose statement for the segment
Flowchart for Activity 1.2
Activity Inputs:
  • List of affected organizations and their business owner(s) (strategic plan and organization chart)
  • Agency strategic plans
  • Agency policies
  • Executive orders
  • Legislation
  • President's budget
  • Preliminary list of affected PART measures
  • Preliminary list of affected PAR measures
  • Identification of the segment leadership to include affected business owner(s) and a designated executive sponsor
  • Governance framework
Activity Tasks:

 

1.2.1      Discuss the business challenges facing each business owner
FTF Usage Guide, Sec. 3.1:  [The] FTF Catalog includes both mandatory and informational initiatives. Mandatory initiatives must be included in agency enterprise architecture and the agency EA Transition Strategy, and agency alignment with these initiatives is assessed as part of the annual EA assessment process.

A facilitated session is an ideal way to extract from the business owner(s), which topics or issues are the highest priority.  In most cases, there will be several prominent, sensitive issues to arise from this facilitated session. It is important to determine the pressing issues so that the architecture can be developed to address what the business owner(s) find important. Issues to consider should include the overall factors driving the prioritization and selection of the segment architecture development effort that may include agency strategic plans, policies, executive orders, legislation, budget priorities, and available PART and PAR program assessments.

1.2.2      Synthesize the common business challenges across the business owners

In most cases, the business owners will have very similar issues or priorities. The fact that the business owners operate within the same segment means a high probability that the business owners face common challenges. However, whether there is immediate consensus or not, the business owners need to focus on the issues or priorities that they face in common so that the core team has a primary focus and does not expend time determining the leadership's intent.

1.2.3      Communicate how segment architecture could assist with common business challenges

The facilitator of the session should communicate to the business owner(s) how the concept of segment architecture can assist with solving the prioritized issues or challenges from the previous task. This is a good opportunity to communicate how architecture is actionable ... meaning that architecture can be used to solve real problems and spur meaningful action within the segment. For instance, the segment architecture can help with process optimization, improved information sharing, improved use of investments, or better formulation of services to citizens.

1.2.4      Formulate the purpose statement

The purpose statement should be a succinct but meaningful articulation of the major challenges or issues that the business owner(s) would like to see addressed within the segment architecture. This purpose statement guide the core team as it develops the segment architecture. The purpose statement should also be direct enough to ensure that the core team understands expectations and develops an actionable segment architecture based on those expectations.

Communications Considerations:

As previously noted, engaging the segment leadership can be difficult to schedule. It is often possible to leverage pre-existing governance team meetings that the segment leaders are members of in order to conclude this activity. This activity can be completed together with the previous activity during the same meeting.

Activity Outputs:
  • Segment architecture development purpose statement
Suggested Analytical Techniques
 
Output Core FEA Layers Suggested Analytical Technique Examples/Templates Contributing Agency/Team
P B D S T
Segment architecture development purpose statement Yes X         Segment architecture development purpose statement Segment  architecture development purpose statement word format Federal Segment Architecture Working Group (FSAWG)
  Key to FEA Layers
P = Performance
B = Business
D = Data
S = Service
T = Technology

Activity 1.3:  Solicit core team members

Activity Description:

The core team is a critical entity throughout the segment architecture development process. Without a knowledgeable, enthusiastic and constructive core team, the segment architecture might not be valid, relevant or implementable. This activity involves the executive sponsor recruiting the best and brightest subject matter experts from the affected organizations. All affected organizations need a seat at the table and that seat needs to be filled by an individual who will embrace the purpose statement and respond positively to other core team members. In general, you want less than 10 people on the core team.

Note that the core team membership is critical to the success of the project. The core team typically consists of program manager level personnel who are subject matter experts in the segment, and possibly key segment stakeholders. Core team members should be constructive, able to think outside of a single organizational context, good communicators, visionary, and excited about change. It is important to note that the core team may decide to invite other subject matter experts for advice, as needed, to supplement their knowledgebase as they move through the segment architecture development process. The important element of the core team is that it is a highly functional team that has the knowledge and vision to develop an actionable segment architecture.

Activity 1.3:  Solicit core team members
Flowchart for Activity 1.3
Activity Inputs:
  • List of affected organizations and identified business owners (strategic plan and organization chart)
  • Segment architecture development purpose statement
Activity Tasks:
1.3.1      Communicate to business owner(s) the role of the core team

It is important to educate the business owner(s) on the role of the core team. The core team is the key group of working level resources that will help shape and develop the target state for the segment. These resources should be from the segment, not architects or IT professionals (unless the segment is an IT specific segment). Overall, the core team members should expect to contribute a significant amount of time thinking about and meeting on the target state planning for the segment.

1.3.2      Determine personnel to be appointed to the core team

In most cases, the core team will be appointed by the business owner(s) or the executive sponsor. This task usually involves a dialogue with the business owner(s) or executive sponsor to ensure that desired personnel are available and can contribute time to the segment architecture development.

1.3.3      Communicate appointments to the affected personnel

Once appointments have been determined, a formal outreach to the appointed individuals is a good way to bring those individuals into the segment architecture development process. Sometimes a one on one conversation with each appointed individual is better than a group introduction to the process and the role of a core team member.

1.3.4      Issue a memorandum to communicate the formation of the core team and the purpose statement

Although the communications strategy has not yet been developed, this task produces a communications item in the form of a core team formation memorandum to communicate the existence of the core team, its members and its purpose.

Communications Considerations:

The development of the core team is critical to building buy-in to the segment architecture and critical to ensure that affected organizations are participating via knowledgeable subject matter experts (SMEs). It is important to cast a wide net of communications in order to get the most representative and constructive collection of members on the core team. Once the core team has been developed, it is important to make its membership known throughout the segment.

Activity Outputs:
  • Core team roster
  • Core team formation memorandum
Suggested Analytical Techniques
 
Output Core FEA Layers Suggested Analytical Technique Examples/Templates Contributing Agency/Team
P B D S T
Core team roster No           Core team roster Core team roster word format Federal Segment Architecture Working Group (FASWG)
Core team formation memorandum No           Core team formation memorandum Core team formation memorandum
word format
Federal Segment Architecture Working Group (FSAWG)
  Key to FEA Layers
P = Performance
B = Business
D = Data
S = Service
T = Technology

Activity 1.4:  Create core team charter and project plan

Activity Description:

The segment architecture development should include the use of project management techniques just like any other project. The core team needs to establish a charter to support the development of the segment architecture. The core team charter establishes the legitimacy of the project, the role of its players, operational ground rules, decision-making structure, preliminary scope, and stated goals and objectives. 
In addition to the charter, the segment architecture development should be guided by a project plan. The project plan will guide the process and ensure timely delivery of the segment architecture. The FSAM process steps, activities, tasks and outputs are major contributors to the structure and sequencing of the project plan.

Activity 1.4:  Create core team charter and project plan
Flowchart for Activity 1.4
Activity Inputs:
  • Segment architecture development purpose statement
  • Core team roster
  • Core team formation memorandum
Activity Tasks:
1.4.1      Develop draft core team charter

The core team charter should include the role of the core team members, the roster of the core team, the decision-making structure for the core team, the purpose statement, and the preliminary scope of the project. Although the core team charter is an important document, it should not take months to develop.

1.4.2      Create project plan for segment architecture development

Although there is a lot unknown about the segment at this point, a project plan should be developed to detail the milestones and proposed dates for the segment architecture development. There is always a risk of the architecture development becoming a prolonged analytical exercise. The project plan will help ensure that the segment architecture is developed within an acceptable time frame.

1.4.3      Review and approve core team charter, project plan and governance

It is important that the segment architecture development process begin with common intentions and a common understanding of expectations. The core team charter, project plan and governance should be reviewed and approved by the business owner(s) and executive sponsor to ensure approval of the initial direction of the segment architecture development effort.

Communications Considerations:

The core team charter should be available to interested parties during the segment architecture development to communicate to organizations and their representatives the governance and overall purpose of the segment architecture effort.

Activity Outputs:
  • Core team charter
  • Project plan
Suggested Analytical Techniques
 
Output Core FEA Layers Suggested Analytical Technique Examples/Templates Contributing Agency/Team
P B D S T
Core team charter No           Core team charter Core team charter word format Federal Segment Architecture Working Group (FSAWG)
Project plan No           Project plan Project plan project format Federal Segment Architecture Working Group (FSAWG)
  Key to FEA Layers
P = Performance
B = Business
D = Data
S = Service
T = Technology

Activity 1.5: Establish the communications strategy

Activity Description:

Successful communication requires the development of a communication strategy. The communication strategy should identify relevant stakeholders in the context of the purpose statement and the core team's knowledge of the affected organizations. The communication strategy includes the necessary value-based messages for the respective types of stakeholders.

For effective communications and collaboration, the core team should establish a web site to facilitate barrier-less information dissemination. The communication strategy should address the necessary targeting (stakeholder, timing and delivery means) of the value messages that are important throughout the project. This targeting should be orchestrated with existing organizational and informational channels, behaviors, calendars and events to optimize reach and usefulness.

Examples of key organizational events would be workshops, collaborative forums, communities of practice or interest (COP, COI), and the annual budget and CPIC cycles. The communication plan should identify the optimal formats and delivery channels (email, brochure, presentations, and web) to sustain effective communications.

Activity 1.5:  Establish the communications strategy
Flowchart for Activity 1.5
Activity Inputs:
  • Core team charter
  • Project plan
  • Governance framework
Activity Tasks:
1.5.1      Determine communications goals and objectives

First, it is important to consider what the core team needs to accomplish its communication strategy. A simple dialogue with the core team can help determine objectives to be included in their communication efforts. The governance framework can also provide additional guidance as to the specific communication needs and requirements associated with key segment governance stakeholders. The effectiveness of communication efforts can be measured by the goals and objectives established.

1.5.2      Identify audience groups and design themes and key messages

Once the goals and objectives of the segment architecture have been established, a facilitated session with the core team can help identify the audience groups to which communications should be directed. For each audience group, the communication strategy should capture the design themes and key messages that are relevant throughout the segment architecture development process.

1.5.3      Select tactical communications vehicles

The tactical communications vehicles should be determined based on the communication strategy. Since the core team has already established the communication goals and objectives, audience groups, design themes and key messages, tactical communications vehicles can be selected more intelligently as appropriate. Common vehicle types include print, web and multimedia. Within those vehicle types are tactical communications vehicles such as brochures (print), slick sheets (print), website (web), collaboration forums (web), videos (multimedia), and podcasts (multimedia).

1.5.4      Implement project collaboration website

Since there are many documents (e.g., analytical results, findings, recommendations, presentations, artifacts, transition plans) that will be formulated and reviewed throughout the segment architecture development process, a collaborative website improves communication and consensus building. Project websites are an ideal way of keeping core team members and even audience groups abreast of meetings, presentations, decisions and overall architecture development progress.

Communications Considerations:

A realistic and practical communications strategy is an important component to the segment architecture development process. In many cases, resources will be scarce and effective communications to key audience groups is better than weaker communications to a wider audience.

Activity Outputs:
  • Communications strategy
Suggested Analytical Techniques
 
Output Core FEA Layers Suggested Analytical Technique Examples/Templates Contributing Agency/Team
P B D S T
Communications strategy No           Communications strategy Communications strategy word format Federal Segment Architecture Working Group (FSAWG)
  Key to FEA Layers
P = Performance
B = Business
D = Data
S = Service
T = Technology

Step References

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

 

Step 2: Define the Segment Scope and Strategic Intent

http://www.fsam.gov/federal-segment-architecture-methodology-toolkit/step2.php

 

Step Description and Purpose

Edit section

This process step provides guidance for architects to define the segment scope and strategic intent, which includes the performance architecture through which achievement of strategic improvement opportunities will be measured. Since segments may be extremely broad from a function, process, product, service, and organizational impact standpoint, it is imperative that a clear understanding of the focus for the segment is defined up front. In order to define the segment's scope and strategic intent, the architect can use this process step to develop a comprehensive understanding of the relevant segment goals and desired outcomes, major strategic improvement opportunities, performance gaps, business mandates and drivers, and key common / mission services delivered to meet principal stakeholders' needs.

This process step synthesizes these factors toward establishing the context and scope that drive the remaining steps of this methodology. The gathering and analysis of stakeholder needs and business drivers contributes to identifying strategic improvement opportunities. There may be numerous business needs and strategic improvement opportunities identified in this process step and it is important that these opportunities be prioritized to a manageable number so that "analysis paralysis" does not occur in subsequent steps.

Analysis of the current business state from a strategic improvement perspective, through techniques such as Strengths, Weaknesses, Opportunities and Threats (SWOT) analysis, provides the foundation for defining the strategic intent of the segment. The strategic intent describes the target state vision and establishes the segment performance goals.

The segment performance architecture includes the goals, key performance indicators, measures, and metrics.  The performance architecture may be based on the Performance Accountability Report (PAR) and Program Assessment Rating Tool (PART) report(s) for programs within the scope of the segment. An example of segment performance metrics are the consolidation, standardization and optimization metrics that are derived from the IT Infrastructure Line of Business. The segment performance architecture is used to measure overall success achieved from implementing the segment transition plan in an effort to reach the target state. By examining the cause and effect of implementing forthcoming segment recommendations (e.g., enhancing new services, retiring redundant solutions), one can maintain a clear line of sight as described in the Federal Enterprise Architecture (FEA) Performance Reference Model (PRM).

In the subsequent steps in this methodology, the architect will deliver recommendations that are aligned directly with the segment scope and strategic intent defined in this process step. In addition, the subsequent steps of the methodology will feed back to this process step and provide further refinement of and updates to the segment's scope and strategic intent.

Note:  While performing this process step, the project plan must be updated to account for the size and complexity of the segment, as defined in this process step.

Key Decisions:

  • Based on the high-level problem statement, what are the strategic improvement opportunities and gaps?
  • What are the major common / mission services associated with the strategic improvement opportunities?
  • Who are the segment stakeholders and how do they relate to the strategic improvement opportunities?
  • What is the scope of the segment architecture being developed?
  • What are the current segment investments, systems, and resources?
    Note:  If this question can be answered with existing information, it may be answered during this process step. However, if there is no definitive answer to this question after this process step, it may be answered in the subsequent steps.
  • What are the deficiencies or the inhibitors to success within the segment?
  • What is the target state vision for the segment?
  • What is the performance architecture for achieving the target state vision?
  • What are the important security and privacy considerations for the segment?

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.

Step Outcome

Edit section

The outcome of this step is a segment scope and set of prioritized strategic improvement opportunities based on the needs of the segment's stakeholders. The strategic intent, which consists of the target state vision, performance goals, and common / mission services target maturity levels, is also established. The subsequent process steps in this methodology will form recommendations that align to the segment strategic intent to provide a complete segment performance line-of-sight and support the achievement of the segment target state vision.

Suggested Analytical Techniques

Edit section

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 2 At-a-Glance

Edit section

 
  Process Step 2 Activities
  Establish segment scope
and context
Identify and prioritize strategic improvement opportunities Define segment strategic intent Validate and communicate the scope and strategic intent
Who Participates in
This Activity?
Core team
Business owner
Executive sponsor
Segment architect
Core team
Business owner
Stakeholders
Executive sponsor
Segment architect
Core team
Business owner
Executive sponsor
Segment architect
Executive sponsor
Core team
Segment architect
What Are the Inputs 
to This Activity?
Segment architecture development purpose statement 
Core team roster 
Core team formation memorandum  
Core team charter 
Project plan 
Communications strategy 
List of affected organizations and their business owner(s)
EA knowledge base
Agency strategic plans
Agency policies
Executive orders
Legislation 
President's budget
Preliminary list of affected PART Measures
Preliminary list of affected PAR Measures
Stakeholders and their relationships
Business drivers and mandates
Segment scope 
Segment context 
Segment architecture development purpose statement  
Project plan 
Communications strategy 
List of affected organizations and their business owner(s)
Agency strategic plans
Agency policies
Executive orders
Legislation 
President's budget
PART
PAR
Stakeholder needs 
Risks and impacts 
Performance gaps 
Strategic improvement opportunities
Segment scope 
Segment context 
Strategic intent
What are the Outputs 
from This Activity?
Stakeholders and their relationships
Business drivers and mandates
Segment scope 
Segment context
Stakeholder needs
Strategic improvement opportunities
Risks and impacts
Performance gaps
Segment performance goals and objectives
Common / mission services target maturity framework 
Segment architecture vision summary
Performance scorecard
Segment scope and Strategic intent presentation
Which Stakeholders / Customers Will Use the Outputs from This Activity? Senior agency leadership
Segment architects
Business owner(s)
Strategic planning team
Strategic planning team
Budget and capital planning officials
Senior agency leadership
Business owner(s)
Strategic planning team
Chief Information Officer(s)
Budget and capital planning official(s)
Program manager(s)
IT infrastructure manager(s)
Information Assurance team member(s)
Project manager(s)
Software architect(s) and developer(s)
Senior agency leadership
Business owner(s)
Strategic planning team
Chief Information Officer(s)
Budget and capital planning official(s)
Program manager(s)
IT infrastructure manager(s)
Information Assurance team member(s)
Project manager(s)
Software architect(s) and developer(s)
What are the Associated 
FEA Profiles?
Security Geospatial
Security
Records
Records
Security
None
Touch Points to NIST 800-39   Leveraged to assist with identifying security requirements for the segment    
Touch Points to NIST 800-60   Leveraged to assist with identifying security requirements for the segment    
Considerations for 
Enterprise Services
  Reuse of enterprise services    
Considerations for 
Business Services
  Cross-cutting opportunities related to business services    
What is the Relative 
Complexity of This Activity?
1 out of 4 3 out of 4 2 out of 4 1 out of 4
Legend that shows 4 levels of increasing complexity.


Activity Details

Edit section

Activity 2.1:  Establish segment scope and context

Edit section

Activity Description:

Edit section

This activity consists of identifying at a high-level the segment stakeholders, business domains, common / mission services, information exchanges, systems, security, and technical focus areas in the context of the "segment architecture development purpose statement" from process step 1. Some of these items may not be known at this point. However, the more information that is available to describe the proposed segment scope and formulate a clear understanding with the core team, the better.

Activity 2.1:  Establish segment scope and context
Flowchart for Activity 2.1

Activity Inputs:

Edit section

  • Segment architecture development purpose statement
  • Core team roster
  • Core team formation memorandum
  • Core team charter
  • Project plan
  • Communications strategy
  • List of affected organizations and their business owner(s)
  • EA knowledge base
  • Agency strategic plans
  • Agency policies
  • Executive orders
  • Legislation
  • President's budget
  • Preliminary list of affected PART measures
  • Preliminary list of affected PAR measures\

Tasks:

Edit section

2.1.1      Review segment architecture development purpose statement
Edit section

The core team reviews the problem statement developed in process step 1 with the business owner(s) and executive sponsor to establish a firm understanding of the segment business drivers and mandates associated with the problem statement. The business drivers and mandates are the foundation from which the segment's performance architecture will be built, demonstrating the linkage to the strategic, business, and investment improvement opportunities identified in subsequent activities and process steps. Business drivers and mandates may include agency strategic plans, policies, executive orders, legislation, budget priorities, and available PART and PAR program assessments.

2.1.2      Identify organization components
Edit section

With a firm understanding of the problem statement and the organizations affected by the problem statement, the core team identifies the high-level relationships between the affected organization(s) and the organization components, as well as the relationships between those components, through any number of means, including the review of any existing enterprise architecture (EA) knowledge bases, PAR, and PART reports.

Organization components may include, when applicable and available, organization units, business functions and processes, common / mission services, applications and information exchanges. Any known relationships between each of the organization components are also identified within this task.

2.1.3      Identify stakeholders
Edit section

This task requires a review of the organization components and the segment architecture development purpose statement in order to identify the segment stakeholders (e.g., consumers, participants, functional representatives). Each stakeholder may have a different perspective on how to overcome the business challenges articulated through the segment architecture development purpose statement.  This task includes identifying the appropriate stakeholders and the relationships between them and the servicing organization(s).

2.1.4      Establish segment summary description
Edit section

After identifying the business drivers and mandates (e.g., GAO reports) for the segment, the organization components, and the stakeholders, the core team now establishes a segment summary description. The summary description is the synthesis of these items into a cohesive document that supports the segment architecture development purpose statement.   The summary description also includes an overview of security and privacy requirements and drivers for the segment. This is a critical task, as it also summarizes the components and stakeholders that are engaged in subsequent activities to elaborate on the business' needs to meet the intended purpose of the segment.

This task also includes augmenting the summary description with an illustration that depicts the current state of the operating environment.  The summary description and the illustration provide the scope and context through which the subsequent process steps are bound.   Defining segment scope helps build consensus within the core team on the range of strategic improvement opportunities and helps focus core team working sessions. Documenting the current-state operating environment could be depicted visually through a simple current operating environment diagram (e.g., Current state Concept of Operations or DoDAF OV-1), which will help to provide a visual context around the problem statement.

2.1.5      Validate / approve segment scope and context
Edit section

The core team formalizes the segment scope and context. Taking all available information into consideration, the executive sponsor and business owners validate and approve the parameters that define the segment boundaries.

2.1.6      Optional Task — Refine / update scope and context
Edit section

It is understood that a more detailed analysis of the business and information in Process Step 3 and the technology and services in Process Step 4 may warrant adjustments to the segment scope and context.  This task consolidates that information for consideration by the executive sponsor and business owners. The goal of this activity is to remain flexible on the scope while avoiding any arbitrary injection of scope creep in the segment architecture development process.

Communications Considerations:

Edit section

The segment architect may need to facilitate meetings or provide other communication support to structure the decision-making process that occurs between the core team, executive sponsor, and business owner(s). The executive sponsor can be consulted to develop or adjust the communication strategy by which consensus can best be achieved.

Activity Outputs:

Edit section

  • Stakeholders and their relationships
  • Business drivers and mandates
  • Segment scope
  • Segment context

Suggested Analytical Techniques

Edit section

 
Output Core FEA Layers Suggested Analytical Technique Examples/Templates Contributing Agency/Team
P B D S T
Stakeholders and their relationships Yes   X       Stakeholder map Stakeholder map word format Department of Health and Human Services (HHS)
Business drivers and mandates Yes X         Driver and policy map Driver and policy map word format Department of Health and Human Services (HHS)
Segment scope Yes X         Segment summary Segment summary word format Department of Health and Human Services (HHS)
Segment context No   X X     Current operating environment diagram Current operating environment diagram word format Environmental Protection Agency (EPA)
  Key to FEA Layers
P = Performance
B = Business
D = Data
S = Service
T = Technology

Activity 2.2:  Identify and prioritize strategic improvement opportunities

Edit section

Activity Description:

Edit section

This activity consists of identifying the segment stakeholder needs, segment risks and impacts, and performance gaps. The core team uses this information to formulate the segment business needs and identify a set of high-level strategic improvement opportunities. The segment's strategic improvement opportunities are then prioritized and selected to form the foundation through which the segment strategic intent is developed.

Activity 2.2:  Identify and prioritize strategic improvement opportunities
Flowchart for Activity 2.2

Activity Inputs:

Edit section

  • Stakeholders and their relationships
  • Business drivers and mandates
  • Segment scope
  • Segment context
  • Segment architecture development purpose statement
  • Project plan
  • Communications strategy
  • List of affected organizations and their business owners
  • Agency strategic plans
  • Agency policies
  • Executive orders
  • Legislation
  • President's budget
  • PART
  • PAR

Tasks:

Edit section

2.2.1      Review segment scope and context
Edit section

This task includes analyzing the business drivers and mandates, the segment scope, and the segment context to begin discerning the business needs of the impacted organization(s). This includes the consideration of factors that led to the overall prioritization and selection of the segment architecture development effort such as agency strategic plans, policies, executive orders, legislation, budget priorities, and available PART and PAR program assessments.

Three tasks (2.2.2, 2.2.3 and 2.2.4) are aimed at understanding the current performance state of the segment scope from three vantage points:  the stakeholders' viewpoint; unaddressed risks and impacts; and existing performance gaps (i.e., PAR, PART, and other existing performance measures).

2.2.2      Determine stakeholders' needs
Edit section

By establishing the segment scope, the core team has identified its stakeholders and their relationships and is now able to engage them in a coordinated, effective, and efficient manner. The core team engages the stakeholders to identify their key business needs, requirements and objectives / outcomes. The needs of each stakeholder (owner, participant, producer, and consumer) are elicited to provide a basis for formulating the consolidated business needs of the segment.

There are varying methods by which stakeholders can be engaged. For instance, stakeholders might be engaged in working sessions which may include developing read-ahead materials and then facilitating working sessions to identify needs. Another possibility for engaging stakeholders is to issue a data call to collect stakeholders' key business needs, requirements and objectives / outcomes.

2.2.3      Identify segment risks and impacts
Edit section
Edit section
NIST 800-39, Sec. 3.2: The first step in building an effective organization-wide information security program is to conduct a thorough analysis of the organization's mission and business processes informed by the organization's enterprise architecture, identifying the types of information that will be processed, stored, and transmitted by the information systems supporting those processes. 


NIST 800-60, Sec. 2.0: Security categorization provides a vital step in integrating security into the government agency's business and information technology management functions and establishes the foundation for security standardization amongst their information systems. Security categorization starts with the identification of what information supports which government lines of business, as defined by the Federal Enterprise Architecture (FEA). Subsequent steps focus on the evaluation of the need for security in terms of confidentiality, integrity, and availability. The result is strong linkage between missions, information, and information systems with cost effective information security.

The core team identifies potential high-level risks and impacts associated with the segment scope and context. For example, security and privacy items that are not adequately addressed in the current environment may be identified here as risks. Segment architects can leverage the latest version of the Security and Privacy Profile and NIST 800-39, Managing Risk from Information Systems, to facilitate discussions to ensure adequate security controls are identified up front for addressing confidentiality, integrity and availability of key business functions. The core team may engage relevant resources by documenting factors that influence or are influenced by the identified risks and impacts. For example, the EA knowledge base(s) could be accessed to identify potentially impacted components. This task includes guidance for architects to provide valuable contextual information for each of the identified risks in order to develop viable mitigation strategies and plans. Working collaboratively with the relevant resources (e.g., EA, security), the core team identifies high-level strategies for mitigating potential risks and impacts. Additionally, a determination at a high-level can be made as to the security categorization / security needs of the segment scope and context. Segment architects can leverage NIST 800-60 to help identify the security needs for the segment.

2.2.4      Identify performance gaps
Edit section

This task includes a review of any pre-existing performance architectures, OIG/GAO reports, customer surveys, or deficiencies in achieving PAR and PART metrics that are within the segment scope identified in activity 2.1. Customer, business, process / activity, and technology performance information is collected for the "current state" in order to identify, quantify, and prioritize segment performance gaps between current and target performance metrics.

Identification of performance gaps should also include consideration and identification of opportunities within the existing segment IT strategic portfolio (e.g., overall size and complexity of the existing portfolio). This will help ensure that strategic IT portfolio opportunities are factored into the overall direction and focus of the segment architecture. For segments that include business services, this identification should also include the identification of strategic opportunities related to the optimization of the IT portfolio as it supports cross-cutting business services.

2.2.5      Formulate and prioritize business needs
Edit section

This task involves the consolidation of the segment scope and context, specifically the business drivers and mandates, stakeholder needs, risks and impacts, and pre-existing performance architecture(s) and metrics. The collection of these various business needs forms the foundation through which strategic improvement opportunities are identified.

After it consolidates the business needs, the core team conducts a review and prioritization of the business needs to determine the significance of the needs in relation to the segment architecture development purpose statement. The output of this task is a set of business needs that have been prioritized and categorized based on their respective sources.

2.2.6      Formulate and prioritize strategic improvement opportunities
Edit section

Having prioritized and categorized the segment business needs, the core team reviews the business needs and identifies strategic improvement opportunities, which can address any number of business needs the core team deems significant.

Strategic improvement opportunities are reviewed to identify internal and external factors which may contribute to or detract from the achievement of the improvement(s) identified. In doing so, the prioritization and selection of the strategic improvement opportunities is aligned with the prioritized business needs of the organization as a whole.

Strategic improvement opportunities can also include the identification of specific technology improvements that can help close mission performance gaps. An example of this would be the identification of enterprise services (e.g., authentication) to close gaps related to mission risk.

Where possible, the prioritization of strategic opportunities should reflect opportunities for cost savings, cost avoidance, or other agency performance improvements that can be derived from greater precision and timeliness of specific investments. For example, the cost performance metrics and benchmark data from the IT Infrastructure Line of Business (ITILoB) can be used to identify potential cost savings / cost avoidance opportunities associated with cost efficiencies or operational improvements in providing IT infrastructure services.

A number of analytical techniques can be leveraged to prioritize the strategic improvement opportunities. One such technique is the SWOT analysis. Additional information regarding SWOT analysis is provided in the suggested analytical technique table below, along with other techniques that can be applied during this activity.

2.2.7      Validate strategic improvement opportunities
Edit section

The executive sponsor reviews and validates the prioritized strategic improvement opportunities and formally approves or rejects them.

Considerations for Enterprise Services:

Edit section

Strategic opportunity analysis should include the consideration of reuse of enterprise services (e.g., trusted internet connection reuse, authentication, etc.). This analysis will ensure that technology reuse opportunities are factored into the overall strategic direction and focus of the segment architecture.

Considerations for Business Services:

Edit section

Business services provide a strategic opportunity to leverage existing investments across multiple segments. Identification of performance gaps should also include consideration and identification of opportunities related to the optimization of the IT portfolio as it supports cross-cutting segment business services.

Communications Considerations:

Edit section

The segment architect may need to facilitate meetings or to provide other communication support to structure the information-gathering with the stakeholders. The executive sponsor can also be consulted to develop or adjust the communication strategy by which the stakeholders can best be engaged.

Activity Outputs:

Edit section

  • Stakeholder needs
  • Risks and impacts
  • Performance gaps
  • Strategic improvement opportunities

Suggested Analytical Techniques

Edit section

 
Output Core FEA Layers Suggested Analytical Technique Examples/Templates Contributing Agency/Team
P B D S T
Stakeholder needs No X X X X X Stakeholder needs Stakeholder needs word format Federal Segment Architecture Working Group (FSAWG)
Risks and impacts No X X X X X Risk capture template Risk capture template excel format Department of Transportation (DOT)
Performance gaps Yes X         Performance gap analysis Performance gap analysis word format Department of Housing and Urban Development (HUD)
Strategic improvement opportunities Yes X         SWOT analysis SWOT analysis word format Department of Defense (DoD)
X         Strategic improvement opportunities analysis Strategic improvement opportunities analysis excel format Department of Housing and Urban Development (HUD)
  Key to FEA Layers
P = Performance
= Service
T = Technology

Activity 2.3:  Define segment strategic intent

Edit section

Activity Description:

Edit section

This activity, which results in the segment strategic intent, consists of reviewing the prioritized strategic improvement opportunities and developing the language to describe the target state vision, goals, outcomes, performance indicators, and the target product(s) and/or service(s) target maturity levels. 
Note:  If this is a common service segment, business scenarios may be defined at this point to describe the strategic improvement opportunities and clarify the vision of the segment.

In addition, the segment scope is collated with the outputs developed within this activity to produce a comprehensive document which summarizes the overall segment scope and strategic intent. This document is the final output of process step 2 and is validated and approved (or rejected) by the business owner(s) and/or the executive sponsor.

Activity 2.3:  Define segment strategic intent 
Flowchart for Activity 2.3

Activity Inputs:

Edit section

  • Stakeholder needs
  • Risks and impacts
  • Performance gaps
  • Strategic improvement opportunities

Activity Tasks:

Edit section

2.3.1      Describe segment target state vision
Edit section

With a firm understanding of the prioritized strategic improvement opportunities, the core team develops a simple one-page graphic illustrating the target state vision for the segment (e.g., Target Concept of Operations or DoDAF OV-1). The illustration should be a high-level description of the proposed operating environment—including planned changes to stakeholder interactions, business processes, information sharing, applications, and technology—to address the strategic improvement opportunities. This graphic is meant only to illustrate the target state and will be enhanced by additional analysis in subsequent process steps.  Additional variations of the graphic should be developed throughout the segment architecture development process.  The graphic should be complemented by a summary vision statement describing the target operating environment and its linkage to the respective business drivers and mandates.

2.3.2      Establish segment's strategic performance
Edit section

Strategic performance is designed to measure how a segment supports the strategic goals of the agency. The purpose of the segment performance is to create a reporting framework to measure the activities and investments within a segment. Performance metrics may cover a wide range of systems, technologies, processes, activities and outcomes within a segment. A successful segment architecture will feature a line of sight from IT investment performance up to strategic success.  Segment line of sight is developed by gathering metrics from many layers that are aligned to a common purpose. This line of sight will show strategic performance that is supported by segment performance that is supported by program performance that is supported by investment performance.  

This task includes establishing the performance scorecard, which is focused on providing a complete picture of segment performance from the highest level of strategic performance down to business and investment performance to measure the success in achieving the segment goals and vision.

Note:  When developing the performance scorecard, not all performance indicators, measures, and metrics may be known at this point. Subsequent process steps may identify additional indicators, measures, and metrics through which the segment will be measured.

Performance indicators should be structured according to the FEA PRM to ensure the segment has a balanced set of outcomes. These performance linkages will enhance understanding of the success the implementation of the segment architecture has had on the organization(s).

2.3.3      Identify target maturity levels for common / mission services
Edit section

The in-scope common or mission services have been identified within the context of the vision for the segment. In this case, services refer to the high-level end services delivered to the stakeholders and customers.  These services often encompass multiple FEA service domains, types, and components. This task establishes the target maturity levels that will contribute to achieving the segment vision while aligning to the segment strategic performance. With the establishment of these maturity levels, the strategic performance architecture has been completed and forms the foundation to which the business and technical performance must align.

This is a key task in that the maturity levels that are defined here will be the targets through which business and investment improvement opportunities identified in subsequent process steps will ultimately align.

2.3.4      Document the strategic intent
Edit section

Consolidating the segment vision, key performance indicators, measures, metrics, and common / mission target maturity levels into the segment strategic intent provides a clear line of sight to the inputs, outputs, outcomes, and understanding of the performance goals of the segment. The subsequent process steps are leveraged to identify how the business and/or investments will contribute to achieve the performance goals of the segment.

Communications Considerations:

Edit section

Identification of the target maturity levels for common / mission services may require that key stakeholders or subject-matter experts be consulted to identify existing maturity levels.

Activity Outputs:

Edit section

  • Segment performance goals and objectives
  • Common / mission services target maturity levels
  • Segment architecture vision summary
  • Performance scorecard

Suggested Analytical Techniques

Edit section

 
Output Core FEA Layers Suggested Analytical Technique Examples/Templates Contributing Agency/Team
P B D S T
Segment performance goals and objectives Yes X         Strategic alignment of opportunities Strategic alignment of opportunities word format Department of Housing and Urban Development (HUD)
Common / mission services target maturity levels No X X   X   Common / mission services maturity framework Common / mission services maturity framework word format Department of the Interior (DOI)
Segment architecture vision summary No X X X X X Segment summary Segment summary  (MS Word Format) Department of Health and Human Services (HHS)
Performance scorecard Yes X         Performance scorecard Performance scorecard excel format Federal Segment Architecture Working Group (FSAWG)
  Key to FEA Layers
P = Performance
B = Business
D = Data
S = Service
T = Technology

Activity 2.4:  Validate and communicate the scope and strategic intent

Edit section

Activity Description:

Edit section

This activity includes packaging and gaining approval of the segment scope and strategic intent from the executive sponsor and business owner(s).

Activity 2.4:  Validate and communicate the scope and strategic intent
Flowchart for Activity 2.4 

Activity Inputs:

Edit section

  • Segment scope
  • Segment context
  • Segment strategic intent

Activity Tasks:

Edit section

2.4.1      Package the scope and strategic intent
Edit section

The architect should develop a package that summarizes the segment scope and strategic intent.

2.4.2      Present the scope and strategic intent for approval
Edit section

A presentation that includes the segment scope and strategic intent should be prepared by the architect. The architect should conduct a detailed workshop review of these architecture products for the core team. The core team then decides whether to proceed to process step 3 or to refine the segment scope and strategic intent. The review should also include the agency Chief Architect to ensure that the proposed scope and strategic intent is aligned with the overall enterprise architecture.

It is recommended that there be a formal sign-off of the scope by the executive sponsor and business owner. In order to solicit further management support for the segment scope and strategic intent based on the underlying strategic performance improvement opportunities, optional sign-off of the scope and strategic intent should also include other key segment leadership roles such as the performance improvement officer (PIO), chief information officer (CIO), and the change management officer (CMO),

Communications Considerations:

Edit section

After the segment scope and strategic intent are approved, the appropriate business and/or technical architects and stakeholders within the organization must be engaged. This may require developing different messages for the various stakeholders to articulate the scope and strategic intent in terms with which the stakeholders are familiar.

Activity Outputs:

Edit section

  • Segment scope and strategic intent presentation

Suggested Analytical Techniques:

Edit section

None

Step References

Edit section

NIST Special Publication 800-60, Vol. I, Rev. 1, Guide for Mapping Types of Information and Information Systems to Security Categories pdf, August 2008

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

Step 3: Define Business and Information Requirements

http://www.fsam.gov/federal-segment-architecture-methodology-toolkit/step3.php

 

Step Description and Purpose

Edit section

The Define Business and Information Requirements process step includes an analysis of the "as is" business and information environment and identifies business improvement opportunities to help fulfill the strategic improvement opportunities identified in process step 2. Within this process step, the architect works with the business owners and SMEs to translate the segment's goals and performance objectives defined in process step 2 into an actionable and realistic target business and data architectures expressed within business functions and business processes and information requirements. These artifacts are vetted and confirmed with business owners and SMEs to ensure they support the strategic intent and performance architecture developed in the prior step. Critical inputs to this process step include the common/mission services maturity levels and the strategic intent defined in process step 2. This matrix does not assess service-component-level (SRM) services but general business-level services or capabilities required by business processes, including their security / privacy requirements. Service component assessment occurs in process step 4. Throughout this step, the term "service" refers to the high-level end services delivered to stakeholders and customers, such as recreation reservations and permits. These services can encompass several SRM service domains, types and components. The intent of process step 3 is to determine adjustments that are necessary to the segment's business and information environment to fulfill the performance architecture (e.g. outcomes and target measures), including effective delivery of common/mission services.

The key to success for this process step is to analyze and document the business and information requirements to the lowest level of detail necessary to form actionable recommendations. It is also important that the information and business analysis provides a synchronized and cohesive set of recommendations that guide the segment architecture findings and recommendations.  

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.

Suggested Analytical Techniques

Edit section

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 Outcome

Edit section

The outcome of this process step is an understanding of the adjustments to the current business and information environments that are required to achieve the target performance architecture, including delivery of common/mission services, identified in process step 2.

Step 3 At-a-Glance

Edit section

 
  Process Step 3 Activities
  Determine current business and information environment 
associated with strategic improvement opportunities
Determine business and information improvement opportunities Define target business and data architectures Validate and communicate target business and data architectures
Who Participates 
in This Activity?
Business owner
Business subject matter experts (SMEs)
Business analyst/architect
Information analyst/architect
Segment architect
Security analyst
Core team
Business owner
Business SMEs
Business analyst/architect
Capital planner
Segment architect
Core team
Business owner
Business SMEs
Business analyst/architect
Information analyst/architect
Segment architect
Security analyst
Core team
Executive governance team
Business owner
Business SMEs
Business analyst/architect
Information analyst/architect
Capital planner
Segment architect
Security analyst
Core team
What Are the Inputs
to this Activity?
Process step 1 outputs
Process step 2 outputs
EA knowledge base
Existing documentation on the current business and information environment (Business processes, practices, rules, PAR and applicable PART reports)
Segment scope and strategic intent
Common/mission services maturity levels 
As-is business value  chain diagrams 
As-is business function model 
As-is key business process models  
As-is key business process swim lane diagrams  
As-is key information sources qualitative assessment
Existing documentation on the current business and information environment (Business processes, practices, rules, PAR and applicable PART reports)
Segment scope and strategic intent 
Common/mission services maturity levels 
As-is business value chain diagrams 
As-is business function model 
As-is key business process models  
As-is key business process swim lane diagrams  
As-is key information sources qualitative assessment 
Business and data architecture adjustment profiles 
Target business function model
Target business value chain
Target key business process models
Target key business process swim lane diagrams
Target conceptual data model 
Target data steward assignments
Target business data mapped to key business processes (CRUD)
Target information sharing matrix 
Updated data reference model
Target information flow diagram
What are the Outputs from This Activity? As-is business value chain diagrams
As-is business function model
As-is key business process models 
As-is key business process swim lane diagrams
As-is key information sources and qualitative assessment
Business and data architecture adjustment profiles Target business function model
Target business value chain
Target key business process models
Target key business process swim lane diagrams
Target conceptual data model 
Target data steward assignments
Target business data mapped to key business processes (CRUD)
Target information sharing matrix 
Updated data reference model
Updated data reference model
Target information flow diagram
Business and data architecture presentation
Which Stakeholders / Customers will Use the Outputs from This Activity? Business owners
Subject matter experts
Project managers
Core team
Segment architects
Portfolio managers
Systems engineers
Business owners
Subject matter experts
Project managers
Core team
Segment architects
Portfolio managers
Systems engineers
Business owners
Subject matter experts
Project managers
Core team
Segment architects
Portfolio managers
Systems engineers
Business owners
Subject matter experts
Project managers
Core team
Segment architects
Portfolio managers
Systems engineers
What Are the Associated FEA Profiles? Records Mgmt
Security
Geospatial
Information Sharing
Records Mgmt
Security
Geospatial
Records Mgmt
Security
Geospatial
Information Sharing
Records Mgmt
Security
Geospatial
Touch Points to 
NIST 800-39
Information and information systems are categorized accordingly      
Touch Points 
to PGFSOA
  Business processes may be shared across organizations
EA helps identify significant information exchanges
   
Considerations for Enterprise Services Scope of as-is analysis of business environment   Enterprise services and ADS  
Considerations for Business Services Scope of as-is analysis of business environment   Business services and ADS  
What is the Relative Complexity of This Activity? 4 out of 4 3 out of 4 4 out of 4 1 out of 4
Legend that shows 4 levels of increasing complexity.


Activity Details

Edit section

Activity 3.1:  Determine current business and information environment associated with strategic improvement opportunities

Edit section

Activity Description:

Edit section

This activity includes an analysis of the current business and information environment in the context of the strategic improvement opportunities identified in process step 2. Specifically, the architects need to define and analyze the portions of the current business and information requirements that are relevant to the strategic improvement opportunities and the common / mission services identified in process step 2. The intent is to analyze the current business and information environment so that in subsequent activities any adjustments to the current state can be determined and strategic improvement opportunities can be achieved.

Activity 3.1:  Determine current business and information 
environment associated with strategic improvement opportunities
Flowchart for Activity 3.1

Activity Inputs:

Edit section

  • Process step 1 outputs
  • Process step 2 outputs

Tasks:

Edit section

3.1.1      Determine the value chains for the common / mission services
Edit section

Using the common / mission services maturity levels identified during process step 2, the architect focuses on the business processes that the business area must perform in order to deliver those services. The task should begin with a high-level focus on the key business processes that deliver services, with the intent of identifying the critical chain of business processes that deliver value. The common / mission services maturity framework matrix serves as a scoping tool to ensure that the segment architecture effort maintains focus on the services that require attention, so the segment performance objectives can be achieved.

First, the services that are currently produced by the business area (from the common / mission services maturity levels in process step 2) should be reviewed. Then, for each current product and service, the business area's current chain of business processes will be diagramed using a value chain.  The value chain drawing is a high-level logical ordering of business processes that provides an overview of how value (i.e., product or service) is produced. The core team should not default to an "analysis paralysis" mode; if the current value chain of business processes is determined to be ad-hoc, or if consensus cannot be determined, this may highlight a major segment architecture finding and result in a recommendation for business process definition, optimization and standardization. A segment may contain several value chains however to maintain a manageable scope, the focus should be on the few that most require attention.

Documenting the value chains is an important mechanism for determining the elements of the business architecture associated with the strategic improvement opportunities and target services from process step 2. By focusing on a specific value chain, the architects can perform additional business architecture analysis on the areas of impact, based on the segment's strategic intent.

3.1.2      Define the business function model and associate it to the value chain
Edit section

The purpose of this task is to associate the business processes in the value chain to their associated business function(s) in order to identify the magnitude of the business functions that will be affected by potential business process improvements. In the case of business processes that deliver enterprise services (e.g., geospatial, infrastructure), a full mapping is not required, although understanding the magnitude of functions affected is helpful in determining future implementation level impacts (e.g. scalability).  

Business areas are decomposed to define a hierarchy that includes functions and business processes. A business function is a logical set of business processes performed on a continual basis that has no specific beginning or end point. Functions are decomposed into business processes, which are a group of related business activities usually executed in a sequential fashion to achieve an intermediate or end-result product or service.

A business function model is created to show the critical business processes identified in the value chain analysis in the context of the business area functions and Federal Enterprise Architecture (FEA) Business Reference Model (BRM).   Existing reference models that catalogue enterprise business functions may be used in structuring the functional hierarchy, but the business processes in the business function model must be consistent with the business processes defined in the value chain models. The intent of this documentation is to ensure that the business processes are in context with the business functions and that the appropriate mappings to the FEA BRM are established.

3.1.3      Analyze existing IT investments that relate to the business processes
Edit section

Existing business cases include a wealth of valuable business and performance information.  Architects should research these business cases to learn more about the existing business and information environments and any associated deficiencies relevant to the strategic intent and performance architecture developed in process step 2. During this task, the architect should identify which of the existing investments are related to the segment and then analyze the existing exhibit 300 and 53 information to prepare a summary of the characteristics of the portfolio—number of investments, total dollar value, and development vs. steady state spending percentage. Associating existing IT investments to business processes aids in determining the level of automation that currently exists in executing these business processes, as well as potential redundant solutions that support the same business processes.

In addition to current investments, the architect in concert with other business leadership (e.g., Chief Financial Officer / Budget Officer) should analyze whether proposed future investments are consistent with the strategic direction for the segment as determined by the preceding process step. The analysis should identify investment efficiency opportunities within the segment in the form of 1) potentially redundant investments for consolidation and 2) opportunities to reprogram/restructure investments to align more closely with the segment architecture strategy and performance objectives. Investments can also be analyzed relative to support for overall strategic performance improvement opportunities, as identified in program assessments (e.g., Performance Assessment Rating Tool (PART)). This information will be analyzed more closely in determining business value when the conceptual solution architecture is developed in process step 4.

3.1.4      Analyze business processes and determine high-level information requirements, including organizational relationships
Edit section

Within the segment, based on the strategic improvement opportunities, certain business processes may be of key interest. In many cases, business processes are defined at a level too high to determine where deficiencies in performance or service delivery are occurring and may need to be decomposed to the activity level. Critical business processes should be defined at the activity level to derive high-level information requirements for the segment. Although this methodology does not prescribe a standard modeling notation for this task, at a minimum, business processes should be modeled to depict information inputs, outputs and value-added activities to perform the business process. The architect should analyze the activities associated with the key business processes in the value chains previously defined to determine critical 'fault points' in business processes that may require business process optimization. These 'fault points' are documented in the output known as the business and data architecture adjustment profile. The architect should concentrate analysis on the information within the business process flows to determine high-level information requirements, which should also include information security and risk requirements.

NIST 800-39, Sec. 3.2: Conducting the security categorization process as an organization-wide exercise helps ensure that the process accurately reflects the criticality, sensitivity, and priority of the information and information systems that are supporting organizational mission/business processes and is consistent with the organization's enterprise architecture.

To establish the information security and risk requirements, it is necessary to conduct an "impact analysis, or security categorization, which uses the mission-based and management and support information types from NIST Special Publication 800-60 to assign appropriate FIPS 199 impact levels for the security objectives of confidentiality, integrity, and availability of the information" (as stated in NIST Special Publication 800-39).

The analysis during this task should also identify the organizations that perform the business processes and activities. Interactions across organizational boundaries in performing the business processes should be described so that ownership and accountability can be analyzed. These interactions can be described using swim-lane diagramming techniques. In many instances, the analysis of organizational relationships to business processes and activities can yield critical insight into a segment's current state environment.

Overall, it is important to document business processes and activities to a level that is meaningful for identifying requirements that will help achieve the strategic improvement opportunities identified in process step 2. Extended process modeling efforts are not recommended unless clearly warranted based on the strategic improvement opportunities or the value chain analysis.

3.1.5      Assess current information sources
Edit section

Through the documentation of the business processes and information flows, the architect should become familiar with the information requirements critical to the segment. During this task, the architect performs a qualitative analysis of the usefulness of key as-is information sources. The intent of this task is to document the sources of information in the current state before qualitatively assessing them along the key dimensions of accuracy, completeness, consistency, precision, timeliness, uniqueness, and validity. Part of the assessment of current data sources is the identification of existing security and privacy controls that are a part of the segment's workflow, data management practices, system designs, infrastructure management, and other protective measures. During the development of the target systems and services architecture in process step 4, activity 2, existing information sources will be analyzed to determine whether they require adjustment to achieve the target information requirements identified in process step 3, activity 2.

Part of the development of target information services is identifying target authoritative data sources (ADS) for key shared information. Myriad data sources for the same information, which become inconsistent because of differences in data management practices, are a root cause of business process and information delivery issues. During this task, recommendations for candidate ADS may be developed. The goal of ADS identification is to determine the most trusted sources of data by information class and data entity through a structured analysis. This analysis produces Data Reference Model (DRM) and Service Reference Model (SRM) touch points for information exchanges.

Considerations for Enterprise Services:

Edit section

Enterprise services will likely result in the requirement for standardization of service management processes across the enterprise. When developing an enterprise services segment, the analysis of the as-is business environment may need to be limited so that all processes across all affected organizations are not defined, but rather that the affected business functions and key business process information sources are analyzed.

For example, when implementing enterprise service management for IT infrastructure services, the focus should be on identifying opportunities for adopting shared business practices. It may be necessary to identify requirements for key service management processes such as asset management and determine the extent to which such requirements are already practiced within existing business processes without performing a detailed as-is analysis of asset management processes across multiple organizations and / or sub-agencies within the enterprise.

Considerations for Business Services:

Edit section

Cross-cutting business services may result in the standardization of service delivery processes across the enterprise. When developing a business services segment, the analysis of the as-is business environment may need to be limited to the extent necessary in order to identify the affected business functions and key business process information sources that need to be standardized to deploy the cross-cutting business services.

For example, when implementing a cross-cutting business service for financial management, the focus should be on identifying the requirements and opportunities for standardizing business practices to enable cross-cutting solutions without performing a detailed as-is analysis of varied existing business service delivery processes across multiple organizations and / or sub-agencies within the enterprise.

Communications Considerations:

Edit section

Business experts must be actively engaged to identify business functions properly, especially in situations where a formal business function model is not available.  Additionally, the use of FSAM often requires the collection of data from a number of sources. In absence of the availability and easy access to the necessary information in consolidated form, there may be a need for explicit data collection activities to collect the required segment baseline information.

Activity Outputs:

Edit section

  • As-is business value chain diagrams
  • As-is business function model
  • As-is key business process models
  • As-is key business process swim lane diagrams
  • As-is key information sources and qualitative assessment

Suggested Analytical Techniques

Edit section

 
Output Core FEA Layers Suggested Analytical Technique Examples/Templates Contributing Agency/Team
P B D S T
As-is business value chain No   X       As-is business value chain analysis As-is business value chain analysis word format Department of Justice (DOJ)
As-is business function model Yes   X       As-is business function model As-is business function model word format Department of the Interior (DOI)
As-is key business 
process model
No   X       As-is business activity model As-is business activity model word format Department of Defense (DoD)
As-is business process 
swim lane diagram
No   X       As-is business process swim lane diagram As-is business process swim lane diagram word format Department of Justice (DOJ)
As-is key information sources and qualitative assessment No   X X     Authoritative Data Source (ADS) candidate qualitative analysis ADS candidate qualitative analysis word format Department of the Interior (DOI)
  Key to FEA Layers
P = Performance
B = Business
D = Data
S = Service
T = Technology

Activity 3.2:  Determine business and information improvement opportunities

Edit section

Activity Description:

Edit section

The segment architect should analyze the gap between the current and required business environment in the context of the strategic improvement opportunities identified in process step 2. This activity provides guidance for determining which elements within the current state business and information environment must change to meet the desired strategic improvement opportunities. The segment architect should describe the needed changes to the business and information environments and whether any of these changes are currently addressed with planned initiatives or investments. The result of this activity is an articulation of the changes that must be made within the target business and data architectures (to be defined in the next activity).

Activity 3.2:  Determine business and information improvement opportunities
Flowchart for Activity 3.2

Activity Inputs:

Edit section

  • Existing documentation on the current business and information environment (business processes, practices, rules, PAR and applicable PART reports)
  • Segment scope and strategic intent
  • Common / mission services maturity levels
  • As-is business value chain diagrams
  • As-is business function model
  • As-is key business process models 
  • High-level information requirements
  • As-is key business process swim lane diagrams 
  • As-is key information sources qualitative assessment

Tasks:

Edit section

3.2.1                  Align strategic improvement opportunities to the business architecture
Edit section

Within this task, the architect should align the elements of the business architecture to the strategic improvement opportunities outlined in process step 2. In other words, the architect should be able to depict which aspects of the business architecture are most closely aligned with the strategic improvement opportunities. The architect can use the business and information to strategic improvement opportunities alignment matrix to link the business processes and activities to the strategic improvement opportunities. The purpose of the matrix is to link business processes with the strategic improvement opportunities so the architect can determine which business processes and activities may need adjustments/optimization to achieve the strategic improvement opportunities and deliver the target services.

3.2.2                  Determine the required adjustments to the business architecture
Edit section
Edit section
PGFSOA, Sec. 4.1.6: Many of the benefits of SOA are derived from sharing — sharing information, sharing business processes, sharing reference architectures, and sharing services.

Using the business and information to strategic improvement opportunities alignment matrix, the architect should determine which elements of the business architecture need to be adjusted to achieve the strategic improvement opportunities from process step 2.  For example, if the analysis of the current business processes revealed business process efficiency opportunities and those business processes are tied to strategic improvement opportunities, the architect should determine if the business process efficiencies will help achieve those strategic improvement opportunities and therefore should be recommended. The intent of this analysis is not to attempt to re-engineer business processes by recommending numerous changes to the business architecture, but to determine the key business processes and high-level adjustments necessary to achieve the strategic improvement opportunities articulated in process step 2.

The architect should also do the research required to determine if business and IT initiatives are currently planned that will support the required changes in business architecture, and whether these initiatives would, when implemented, fully or partially address the required adjustments. Where possible, the identification of business improvement opportunities should also consider additional opportunities for cost savings, cost avoidance, and other performance improvements that can be derived from greater precision and timeliness of specific investments. For example, the cost performance metrics and benchmark data from the IT Infrastructure Line of Business (ITILoB) can be used to identify potential cost savings / cost avoidance opportunities associated with business process efficiencies or operational improvements in providing IT infrastructure services. The impact of planned investments can be documented in the business and information to strategic opportunities alignment matrix.

The architect should use the business and data architecture adjustment profile to document potential changes to the business environment that could help achieve the strategic improvement opportunities outlined in process step 2. The architect should use the business and data architecture adjustment profile to formally document the limitations of the current state, desired characteristics of the target state, how the target state will help achieve the strategic improvement opportunities from process step 2, and any known risk and cost considerations.

3.2.3      Align strategic improvement opportunities to the data architecture
Edit section
Edit section
PGFSOA, Sec. 4.1.7: Employ enterprise architecture tools and artifacts to identify significant information exchanges across domains of interest.

Through the business process and activity analysis, the architect has become more familiar with the segment's information environment. Although the architect has documented business modifications that can help achieve the strategic improvement opportunities, the architect should re-use the business process and activity analysis to determine if there are data architecture deficiencies that require adjustment to the current state.  For example, the architect might have conducted business process analysis and determined that the business processes are sound but may also have noticed information-related deficiencies (e.g., insufficient data to make business decisions, redundant data entry between systems or manual routing of information that can be automated via information exchanges). In this case, the architect may observe that there is an information collection and/or sharing deficiency whose resolution might lead to the achievement of a strategic improvement opportunity from process step 2.

The architect should amend the business and information to strategic improvement opportunities alignment matrix to capture the information-related elements that align to the strategic improvement opportunities. In other words, the business and information to strategic improvement opportunities alignment matrix will now include elements of the business and data architectures and how they map to the strategic improvement opportunities.

3.2.4      Determine the required adjustments to the data architecture
Edit section

Using the business and information to strategic improvement opportunities alignment matrix, the architect should determine which elements of the data architecture should be adjusted to achieve the strategic improvement opportunities from process step 2.  For example, if the analysis of the current business processes revealed information collection, storage, and sharing opportunities tied to strategic improvement opportunities, the architect needs to determine if the data architecture opportunities will help achieve those strategic improvement opportunities and should therefore be recommended. Part of the determination of adjustments to the data architecture is the identification of existing security and privacy controls that will be a part of the segment's workflow, data management practices, system designs, infrastructure management, and other protective measures.  The intent of this analysis is not to re-design the full data architecture by making numerous data architecture recommendations, but to determine the key high-level adjustments necessary to achieve the strategic improvement opportunities defined in process step 2.  Creation of new ADS may be required to achieve identified strategic improvement opportunities. The architect should also do the research required to determine if there are business and IT initiatives currently planned that will address the changes in the data architecture and whether these initiatives would, when implemented, fully or partially address the required adjustments.

Use the business and data architecture adjustment profile to document potential changes to the information environment that could help achieve the strategic improvement opportunities outlined in process step 2. Use the business and data architecture adjustment profile to formally document the limitations of the current state, desired characteristics of the target state, how the target state will help achieve the strategic improvement opportunities from process step 2, and any known risk and cost considerations.

Communications Considerations:

Edit section

Business experts should be consulted to ensure that the appropriate details of the business processes are adequately represented and that any available business performance data are incorporated into the analysis.

Activity Outputs:

Edit section

  • Business and data architecture adjustment profiles

Suggested Analytical Techniques

Edit section

 
Output Core FEA Layers Suggested Analytical Technique Examples/Templates Contributing Agency/Team
P B D S T
Business and data architecture adjustment profiles No   X X     Business and data architecture adjustment profiles Business and data architecture adjustment profiles word format Department of the Treasury
  Key to FEA Layers
P = Performance
B = Business
D = Data
S = Service
T = Technology

Activity 3.3:  Define target business and data architectures

Edit section

Activity Description:

Edit section

During this activity, the architect should define the optimal target business and data architectures to reflect each of the business and information improvement opportunities identified in the prior activities. During this activity, the architect will define the target business and information environments by developing target versions of the current state business and information artifacts previously developed. The scope of this analysis should focus only on critical business processes and information at an appropriate level of detail and granularity so as to:

  • Identify the target state business processes and information
  • Facilitate the derivation of the data architecture from the business architecture
  • Maintain traceability between the business architecture and data architecture

In the end, the target business and data architectures will be recommended for implementation. The result will be to achieve the strategic improvement opportunities from process step 2, to operationalize the organization's data reference model (DRM), and to maintain compliance with information assurance and security mandates.

Activity 3.3:  Define target business and data architectures
Flowchart for Activity 3.3

Activity Inputs:

Edit section

  • Existing documentation on the current business and information environment (business processes, practices, rules, PAR and applicable PART reports)
  • Segment scope and strategic intent
  • Common / mission services maturity levels
  • As-is business value chain diagrams
  • As-is business function model
  • As-is key business process models 
  • As-is key business process swim lane diagrams 
  • As-is key information sources qualitative assessment
  • Business and information to strategic improvement opportunities alignment matrix
  • Business and data architecture adjustment profiles

Tasks:

Edit section

3.3.1      Define target business processes and their performance including organizational relationships
Edit section

For each target common / mission service from process step 2, the architect should diagram the target chain of business processes in a value chain drawing describing the value that will be produced by the business processes. The target value chain might be identical to the current-state value chain because it is not uncommon for changes to be at the activity level rather than at the business process level. The intent of the target value chain analysis is to identify any differences in the business processes that are currently being provided, versus those that need to be provided in the target state. The value chain analysis will help determine where new business processes are required and where existing business processes may no longer be necessary.

Just as in the as-is analysis, the value chain should then be aligned to the target business function model and the FEA BRM.  The architect should use the business function model to identify the critical business processes identified in the value chain analysis in the context of the business area functions and the FEA BRM. The business processes identified in the business function model must be consistent with the business processes identified in the value chain models. Additionally, it is necessary to ensure that the processes include built-in security and privacy controls that will provide proper levels of protection that support effective business performance and which meet federal laws, policies, directives, and guidance for the level of information criticality/sensitivity for the segment.

For each key business process identified in the business function model and value chain models, it is necessary to define and analyze the target business processes and associated performance measures. The business and data architecture adjustment profiles are a major driver for the differences between the current and target state business process models. The business process models (e.g., IDEF0, BPMN) should be developed to describe the units of work, rules, guidance, enablers and performance measures for each key target business process. In addition, the architect should identify the information exchanged between key business processes along with the producers and consumers of that information and the mechanisms used to enable the exchange. Information access and exchange services are summarized for information classes in the target information sharing matrix.

Just as in the current state analysis, the architect should understand the relationships between business processes and the organizations that perform or participate in those business processes. Using the business function model, value chain models, and business process models, the architect should develop a target swim lane flow to describe a view of how organizational units interact in the context of the business processes that are delivering the services. The architect should make keen observations about accountability in the context of the organizations and their business processes.

3.3.2      Define target data relationships and business data stewards
Edit section

Using the understanding of the key information flows developed during the business process and activity analysis, the architect should develop the target conceptual data model to provide a graphical representation of the business data requirements and relationships. The data model will provide the structure and terminology for information and data in the target environment. The target conceptual data model should include subject areas, information classes, key entity types and relationships.

The target conceptual data model should be used to update the enterprise data reference model (DRM). The articulation of the target conceptual data model will be used in subsequent activities and process steps for continued analysis regarding data and its relationships to stewards and information sources.

The architect should develop target data steward assignments by mapping each information class within the target conceptual data model to an organization that will be the business data steward for that information class. The business data steward is responsible for the creation, maintenance and quality of the data to support target business activities in the target environment.

Based on the development of the target data steward assignments, the architect should be able to communicate changes in stewardship and delivery of information. For instance, if two offices currently collect, store, and maintain the same data, and one office is designated as the steward, the other office could then become a customer of the steward office, rather than a second supplier of the same data.

3.3.3      Define the target information services
Edit section

In this task the architect develops a matrix that documents how target business processes use the business information identified in the target conceptual data model (e.g., CRUD analysis). This matrix allows the architect to map target business processes to core data entities to help identify candidate information services, including new ADS, and business processes that need to use these information services (preliminary requirements for orchestration). The matrix also helps identify producers and consumers of this information. At the end of this step, the as-is key information sources and qualitative assessment artifacts should be updated with final recommendations concerning their designation as ADS.

The identification of information services is a key component to the target architecture. This task allows the architect to bridge the business and data architectures by linking business processes and business information.  Through this analysis, the architect should discover opportunities for re-use of information in the form of information sharing services. This analysis should also ensure that the information services include built-in security and privacy controls that will provide proper levels of protection that support effective business performance and which meet federal laws, policies, directives, and guidance for the level of information sensitivity for the segment. The architect should also look for information sharing service opportunities outside of the segment, within other parts of the enterprise and within the federal sector.

3.3.4      Ensure target business and data architectures addresses strategic improvement opportunities
Edit section

The architect should review the outputs of the activities and tasks to ensure that the strategic improvement opportunities identified in process step 2 have been adequately addressed by the target business and data architectures. During this task, the architect should review the business and data architecture adjustment profiles and the target business and information artifacts to ensure that there is full coverage of the strategic improvement opportunities from process step 2.

Any strategic improvement opportunities that have not been addressed by the target business and data architectures should be reviewed to ensure that there are no relevant business and information touch-points. For instance, strategic improvement opportunities that are purely technology-related will be addressed in process step 4.

Considerations for Enterprise Services:

Edit section

Enterprise services may be associated with the adoption of data standards and data services associated with target authoritative data sources. For example, geospatial services can include standardized mapping services for data as served by an authoritative data source (ADS) leveraging established geospatial data standards. Such enterprise services may also involve standardization of target business processes for consumers and producers of ADS information.

Considerations for Business Services:

Edit section

Business service segments may result in the tight coupling of standardized business processes supported by target authoritative data sources. For example, standardized grants management business processes may be coupled with an authoritative data source for grants data to provide a common solution across the enterprise.

Communications Considerations:

Edit section

Business experts should be actively engaged in defining the target business and data models. These models should be communicated actively to obtain a wide array of participation from within the segment.

Activity Outputs:

Edit section

  • Target business architecture artifacts
    • Target business function model
    • Target business value chain
    • Target key business process models
    • Target key business process swim lane diagrams
  • Target data architecture artifacts
    • Target conceptual data model
    • Target information flow diagram
    • Target data steward assignments
    • Target business data mapped to key business processes (CRUD)
    • Updated data reference model
    • Target information sharing matrix

Suggested Analytical Techniques

Edit section

 
Output Core FEA Layers Suggested Analytical Technique Examples/Templates Contributing Agency/Team
P B D S T
Target business 
value chain diagram
No   X       Target business value chain analysis Target business value chain analysis word format Department of Justice (DOJ)
Target business 
function model
Yes   X       Target business function model Target business function model word format Department of the Interior (DOI)
Target key business 
process model
No   X       Target business activity model Target business activity model word format Department of Defense (DoD)
Target business process 
swim lane diagram
No   X       Target business process swim lane diagram Target business process swim lane diagram word format Department of Justice (DOJ)
Target conceptual 
data model
Yes     X     Target conceptual data  model Target conceptual data model word format Office of Personnel Management - Human Resources Line of Business (HR-LOB)
Target information
flow diagram
Yes   X X     Target information flow diagram Target information flow diagram word format Information Sharing Environment (ISE)
Target data 
steward assignments
Yes     X     Target data steward matrix Target data steward matrix word format Department of the Interior (DOI)
Target business data mapped to key business processes (CRUD) No   X X     CRUD matrix results table CRUD matrix results table word format Department of Health and Human Services (HHS)
Target information 
sharing matrix
Yes     X     Target information sharing matrix Target information sharing matrix excel format Department of the Interior (DOI)
  Key to FEA Layers
P = Performance
B = Business
D = Data
S = Service
T = Technology

Activity 3.4:  Validate and communicate target business and data architectures

Edit section

Activity Description:

Edit section

Gain approval from the core team in regards to the target business and data architectures.

Activity 3.4:  Validate and communicate target business and data architectures
Flowchart for Activity 3.4

Activity Inputs:

Edit section

  • Target business architecture artifacts
    • Target business function model
    • Target business value chain
    • Target key business process models
    • Target key business process swim lane diagrams
  • Target data architecture artifacts
    • Target conceptual data model
    • Target data steward assignments
    • Target business data mapped to key business processes (CRUD)
    • Updated data reference model
    • Target information sharing matrix

Tasks:

Edit section

3.4.1      Package business and data architectures
Edit section

The architect should develop a package that describes the business and data architectures for the core team to review. This presentation should include a summary of how the business and data architectures align with the high-level business and information requirements derived at the beginning of this step.

3.4.2      Present business and data architectures for approval
Edit section

A presentation that includes the business and data architectures should be prepared by the architect. The architect should conduct a detailed workshop review of the business and data architectures. The core team decides at this point whether to proceed into process step 4 or refine the business and data architectures. The review should also include the agency Chief Architect to ensure that the proposed business and data architectures are aligned with the overall enterprise architecture.

Communications Considerations:

Edit section

Executive briefing materials should not be in architecture language but in business terms and context and at an appropriate level for the audience.

Activity Outputs:

Edit section

  • Business and data architecture presentation

Suggested Analytical Techniques:

Edit section

None

Step References

Edit section

Federal Enterprise Architecture Program, The Data Reference Model, Version 2.0 pdf, November 17, 2005

Porter, Michael E., Competitive Advantage: Creating and Sustaining Superior Performance, New York, NY, 1985

Spewak, Steven H., Enterprise Architecture Planning: Developing a Blueprint for Data, Applications, and Technology, Princeton, NJ, 1992

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

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

Step 4: Define the Conceptual Solution Architecture

http://www.fsam.gov/federal-segment-architecture-methodology-toolkit/step4.php

 

Step Description and Purpose

Edit section

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
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

Edit section

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

Edit section

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

Edit section

Step 4 At-a-Glance

Edit section

 
  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?
2 out of 4 3 out of 4 3 out of 4 1 out of 4
Legend that shows 4 levels of increasing complexity.


Activity Details

Edit section

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

Edit section

Activity Description:

Edit section

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
Flowchart for Activity 4.1

Activity Inputs:

Edit section

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

Tasks:

Edit section

4.1.1      Collect information on existing segment system and service capabilities
Edit section

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
Edit section

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
Edit section

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
Edit section

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:

Edit section

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:

Edit section

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

Suggested Analytical Techniques

Edit section

 
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 excel format Department of the Interior (DOI)
As-Is conceptual solution architecture Yes   X   X X As-is system interface diagram As-is system interface diagram word format 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

Edit section

Activity Description:

Edit section

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
Flowchart for Activity 4.2

Activity Inputs:

Edit section

  • Federal Transition Framework (FTF)
  • As-is system and services scoring
  • As-Is conceptual solution architecture
4.2.1      Identify service and solution reuse opportunities
Edit section
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
Edit section

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
Edit section

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
Edit section

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:

Edit section

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:

Edit section

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:

Edit section

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:

Edit section

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

Suggested Analytical Techniques

Edit section

 
Output Core FEA Layers Suggested Analytical Technique Examples/Templates Contributing Agency/Team
P B D S T

Target conceptual
solution architecture

Edit section

Yes   X   X X Target system interface diagram Target system interface diagram word format Department of the Treasury

Target Service 
Component Architecture

Edit section

Yes       X   Service component model (SCM) Service component model word format Office of Personnel Management - Human Resources Line of Business (HR-LOB)

Target Technical Architecture

Edit section

Yes         X Technology model Technology model word format Office of Personnel Management - Human Resources Line of Business (HR-LOB)

Integrated service component and 
technology model

Edit section

No       X X Integrated service component and technology model Integrated service component and technology model word format Office of Personnel Management - Human Resources Line of Business (HR-LOB)

Reuse Summary

Edit section

Yes X X X X X Reuse Summary Reuse summary excel format Federal Segment Architecture Working Group (FSAWG)

Data Reuse

Edit section

Yes     X     Data Reuse Data reuse excel format 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

Edit section

Activity Description:

Edit section

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
Flowchart for Activity 4.3

Activity Inputs:

Edit section

  • 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
Edit section

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
Edit section

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:

Edit section

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

Activity Outputs:

Edit section

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

Suggested Analytical Techniques

Edit section

 
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 word format Department of the Treasury
Transition recommendation sequencing diagram No       X   Transition recommendation sequencing diagram Transition recommendation sequencing diagram word format Department of the Interior (DOI)
Recommendation sequencing milestones Yes X X X X X Recommendation sequencing milestones Recommendation sequencing milestones excel format 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

Edit section

Activity Description:

Edit section

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
Flowchart for Activity 4.4

Activity Inputs:

Edit section

  • 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:

Edit section

4.4.1      Package the conceptual solution architecture
Edit section

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
Edit section

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:

Edit section

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:

Edit section

  • Conceptual Solution Architecture Presentation

Suggested Analytical Techniques:

Edit section

None

Step 5: Author the Modernization Blueprint

http://www.fsam.gov/federal-segment-architecture-methodology-toolkit/step5.php

 

Step Description and Purpose

Edit section

The Author the Modernization Blueprint step is the culmination of the process for creating a segment architecture blueprint. The step begins with the identification and categorization of findings and the definition of associated transition options that address segment performance improvement opportunities and implementation of the performance, business, data, and conceptual solution architectures developed in process steps 2, 3 and 4. Transition options are a set of one or more alternatives for transitioning from the as-is to the target state. Transition options are analyzed for cost, benefit and risk in order to develop implementation recommendations. These implementation recommendations consist of validated transition options related to the findings and, ultimately, segment performance improvement opportunities. Taking into consideration logical and discretionary dependencies between the implementation recommendations, these recommendations are prioritized to develop a sequencing plan that provides the basis for developing the modernization blueprint. Figure 1 provides an overview of the development and sequencing of implementation recommendations.

Figure 1 :  Overview of development and sequencing of implementation recommendations
Overview of development and sequencing of implementation recommendations

During this process step, the draft modernization blueprint and sequencing plan are developed and undergo a structured review process with the core team. The review process also helps obtain buy-in that will carry forward into the implementation of the segment architecture. As reviewer feedback is received, comments and change requests provide the basis for finalizing the modernization blueprint and sequencing plan.

The segment architecture blueprint is finalized and formally presented for approval to the executive sponsor, business owner, and core team. Once the segment architecture blueprint and sequencing plan are approved, the executive sponsor, business owner, and core team are prepared to move forward with gaining any additional approvals of the broader business community and capital planning governance teams (such as the Investment Review Board) as necessary. An approved blueprint is ready for overall integration into enterprise transition planning, as well as to move forward into the implementation processes associated with investment management, solution architecture development, and system lifecycle management.

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.

Step Outcome

Edit section

The outcome of this step is a series of validated implementation recommendations described in a detailed, actionable segment architecture blueprint supported by holistic analysis of segment business, data, technology, and service components.   The executive sponsor, business owner, and core team have reviewed and approved the blueprint and sequencing plan for target architecture implementation.

Suggested Analytical Techniques

Edit section

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 5 At-a-Glance

Edit section

 
  Process Step 5 Activities
  Perform cost / value / risk analysis to develop implementation recommendations Develop draft blueprint and sequencing plan Review and finalize the blueprint and sequencing plan Brief core team and 
obtain approval
Who Participates in this Activity?

Core team
Segment architect

Core team
Segment architect

Executive sponsor
Core team
Business owner(s)
Segment architect

Executive sponsor
Core team
Business owner(s)
Segment architect

What are the Inputs to this Activity?

Process step 1 outputs
Process step 2 outputs
Process step 3 outputs
Process step 4 outputs

Analysis of cost, value and risk for transition options
Proposed implementation recommendations

Strategic systems migration / sequencing overview 
Recommendation implementation sequencing plan
Segment architecture blueprint document (incl. sequencing plan)
Segment mappings
Transition plan milestones

Final strategic systems migration / sequencing overview 
Final strategic systems migration / sequencing performance milestones
Final recommendation implementation sequencing plan
Final segment architecture blueprint document (incl. sequencing plan)
Document review log
Feedback tracking and action report

What are the Outputs from this Activity?

Analysis of cost, value and risk for transition options
Proposed implementation recommendations

Strategic systems migration / sequencing overview 
Recommendation implementation sequencing plan
Recommendation implementation sequencing performance milestones
Segment architecture blueprint document (incl. sequencing plan)
Segment mappings
Transition plan milestones

migration / sequencing overview 
Final strategic systems migration / sequencing performance milestones
Final recommendation implementation sequencing plan
Final segment architecture blueprint document (incl. sequencing plan)
Document review log
Feedback tracking and action report

Blueprint executive summary presentation
Approved segment architecture blueprint document (incl. sequencing plan)
Record of decision (ROD)

Which Stakeholders / Customers will use the Outputs from this Activity?

Senior agency leadership
Business owners
Strategic planning team
Chief Information Officer
Budget and capital planning officials
Program managers
Information Assurance team members

Senior agency leadership
Business owners
Chief Information Officer

Senior agency leadership
Business owners
Strategic planning team
Chief Information Officer
Budget and capital planning officials
Program managers
IT infrastructure managers
Information Assurance team members

Senior agency leadership
Business owners
Strategic planning team
Chief Information Officer
Budget and capital planning officials
Program managers
IT infrastructure managers
Information Assurance team members
Project managers
Software architects and developers

What are the Associated FEA Profiles?

Security
Geospatial
Records Management

 

Security
Geospatial
Records Management

 

What is the Relative Complexity of this Activity?

2 out of 4

2 out of 4

2 out of 4

1 out of 4

Legend that shows 4 levels of increasing complexity.


Activity Details

Edit section

Activity 5.1:  Perform cost / value / risk analysis to develop implementation recommendations

Edit section

Activity Description:

Edit section

This activity includes guidance for architects to produce findings and transition options that business owners can use to develop a prioritized strategy to drive business improvements. These business improvement activities ultimately will take the form of a formal business case submission(s) and may include specific project or activities to conduct business process re-engineering, systems integration, establishment of formal partnerships, policy development or other transformational approaches.

Findings can represent almost any issue, from outdated technologies, to poor business process fit, to redundancies, etc. Findings are developed using the relevant artifacts from process steps 2, 3 and 4 and should be categorized according to the associated business products and services. Transition options are then developed for each of the findings. Transition options are a set of one or more alternatives for transitioning from the as-is to the target state. The transition options may be categorized further according to the service components, business processes or capability areas that are impacted.

For each set of transition options, analysis is performed to determine the associated cost, benefit and risk. This requires a balance between the depth of analysis (e.g., high-level cost breakdown), available data (e.g., risk analysis assumptions), and the type of recommendations under consideration (strategic vs. tactical). The results of this analysis are a key input to finalizing the sequencing for implementation of the transition options.

The implementation recommendations are reviewed with key stakeholders and other governance teams as needed to achieve consensus. This review should also include a validation that the segment architecture as developed in process steps 2, 3, and 4 provides the necessary context and level of detail to inform downstream solution-level implementation activities. Any changes to the implementation recommendations resulting from these reviews must also be reviewed and approved by the core team.

Activity 5.1:  Define and categorize findings and transition options
Flowchart for Activity 5.1

Activity Inputs:

Edit section

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

Tasks:

Edit section

5.1.1      Identify findings
Edit section

Findings are developed by reviewing the results of process steps 1 through 4. Specifically, the strategic improvement opportunities from process step 1, the business and information opportunities from process step 3, and the conceptual solution architecture from process step 4.

The findings are aligned with and categorized according to the segment strategic, business, and investment improvement opportunities. This alignment will be extended to the subsequent transition options and implementation recommendations to be defined later in this process step.

Note:  This step should focus on synthesizing and summarizing information generated during prior steps and not on the detailed analysis. If detailed analysis is required, then it may be necessary to repeat some of the prior analysis steps.

5.1.2      Develop transition options
Edit section

Transition options may be modular (i.e., stand-alone), in that they may be implemented independent of other transition options. Transition options may also share dependencies with each other. Such dependencies are likely to be identified as a consequence of the overall architectural analysis performed in process steps 2, 3, and 4. In practice, it is a good idea to attempt to consolidate and de-couple transition options as much as possible in order to reduce the complexity of subsequent cost / value / risk analysis.

As with the alignment of findings in the previous task, transition options are also aligned with and categorized according to the segment strategic, business, and investment improvement opportunities. This provides line-of-sight of the recommendations and presents the transition option in a more actionable context for business owners to evaluate and prioritize.

Note:  Throughout this activity, transition options that share dependencies with each other should be grouped into a higher-level transition option. This may especially be the case where there are dependencies between transition options that are derived based on different findings. In such cases, the opportunity to generalize the findings to encompass both sets of transition options may need to be considered.

Transition options are grouped and summarized as a set derived from the findings. Typically, this will take form such as the following:

  • Strategic, business, or investment opportunity
    • Finding 1
      • Transition Option 1.1
      • Transition Option 1.2
    • Finding 2
      • Transition Option 2.1
  • Etc.
5.1.3      Perform cost / value / risk analysis to compare transition options
Edit section

For each transition option, a value estimate is derived for each strategic focus area. This may require additional input from key stakeholders. An aggregate cost estimate is prepared that includes the appropriate level of detail.  Some more significant and strategic transition options may require more detailed lifecycle cost estimates based upon the requirements for funding review and approval. Cost may also include decommissioning costs associated with transition options that eliminate a service or that result in system retirement. This should rely on cost estimates developed in step 4 that are reviewed, finalized, and rolled-up to the associated transition options.

Risk analysis is performed for each transition option that includes the identification of the top risks in terms of overall impact. This involves assessing the likelihood of the occurrence of the risk, along with assessing the impact on both the cost and value of the transition option. Risks are then rolled up to obtain an overall likelihood and cost / value impact.

Cost, value and risk estimates for each transition option should be analyzed using a quantitative approach such as the value measuring methodology (VMM). Results of the analysis should be used to inform the prioritization (selection and sequencing) of transition options to formulate a set of implementation recommendations in the subsequent task.

5.1.4      Develop prioritized implementation recommendations
Edit section

Results of the cost / value / risk analysis are reviewed with the key stakeholders to gain buy-in to the proposed implementation recommendations. This review should include the value-to-cost comparison, together with the updated draft of the implementation recommendation overview and the draft system migration diagram. This is a critical step to ensure buy-in to the implementation recommendation proposals that are to be formalized in the segment blueprint and sequencing plan in the subsequent activity.

The architect should review the results of the cost / value / risk analysis with the core team members to select and sequence the transition options. The finalized list of prioritized transition options comprises a set of implementation recommendations that are used to develop a proposal for the high-level recommendation implementation plan.

The set of prioritized transition options is organized and presented using a high-level recommendation implementation overview visual that includes a summary of each implementation recommendation and the proposed high-level recommendation implementation activities.
Rough order of magnitude cost estimates developed in prior steps are refined to account for the actual sequencing of implementation recommendations.

5.1.5      Develop lessons learned
Edit section

Lessons learned are captured in collaboration with the core team for the segment architecture development to provide historical information that can be used to inform and guide future segment architecture initiatives and identify ways to improve on the overall segment architecture development methodology.

Communications Considerations:

Edit section

Consult with the business architecture and data architecture teams to identify issues relative to business processes and data. Transition options need to be shared across the organization to determine if there are any external dependencies or existing efforts. Certain sensitive transition options may need to be vetted with key business experts (e.g., general counsel, HR, etc.) before such transition options can be formalized.

It may be necessary to consult with key stakeholders when performing value analysis. Cost and risk analysis may also require additional input from business experts.

Where external dependencies are known to exist, the implementation recommendations need to be shared across organization(s). The executive sponsor and core team should be informed of any proposed changes to the implementation recommendations. This is especially critical when consensus is difficult and external dependencies exist that cannot be managed entirely within the scope of authority of the core team (e.g., inter-agency initiative).

Activity Outputs:

Edit section

  • Analysis of cost, value and risk for transition options
  • Proposed implementation recommendations

Suggested Analytical Techniques

Edit section

 
Output Core FEA Layers Suggested Analytical Technique Examples/Templates Contributing Agency/Team
P B D S T
Analysis of cost, value and risk for transition options No           Value measuring methodology cost to value matrix Value measuring methodology cost to value matrix excel format General Services Administration (GSA)
Proposed implementation recommendations No           Recommendation implementation overview Recommendation implementation overview word format Federal Segment Architecture Working Group (FSAWG)
  Key to FEA Layers
P = Performance
B = Business
D = Data
S = Service
T = Technology

Activity 5.2:  Develop draft blueprint and sequencing plan

Edit section

Activity Description:

Edit section

The validated implementation recommendations provide the basis for producing the detailed blueprint document and sequencing plan. The draft blueprint document summarizes the results of the business analysis and strategy and provides an overview of the target data, services, and technology environment along with the results of analysis of the findings, transition options, and associated implementation recommendations.

Activity 5.2:  Develop draft blueprint and sequencing plan
Flowchart for Activity 5.2

Activity Inputs:

Edit section

  • Updated analysis of cost, value and risk for transition options
  • Finalized implementation recommendations

Tasks:

Edit section

5.2.1      Develop the draft work breakdown structure
Edit section

Using the updated implementation recommendations, a draft sequencing work breakdown structure (WBS) is developed. For each implementation recommendation, a top-down representation of the deliverables that are required for implementation is developed and described in the WBS. The WBS should incorporate deliverables associated with all aspects of the transformation, including technology, process, system, data, etc., along with any associated workforce development, communication and change management activities.

5.2.2      Develop the draft sequencing plan
Edit section

Based on the completed WBS, both a high-level recommendation implementation sequencing plan and a strategic systems migration / sequencing overview are developed to summarize the sequencing plan for the segment. The recommendation implementation sequencing plan contains information regarding the timing and dependencies between those items identified in the WBS, including the technology, process, system, data, associated workforce development, communication, and change management activities.  These items constitute the blueprint recommendations that are outlined in the draft implementation sequencing plan analytical technique identified below.  The strategic systems migration / sequencing overview is focused on the actual sequencing and transition of systems and services to achieve the target state.

Note that the  strategic systems migration / sequencing overview is essentially a single consolidated diagram containing the individual transition recommendation sequencing diagrams developed in process step 4 that correspond with the selected implementation recommendations. A corresponding consolidated table of strategic systems migration / sequencing performance milestones is also developed.

Once the high-level sequencing is developed, a more detailed draft sequencing plan is developed in the form of a project schedule that includes all tasks associated with the overall transition of business processes, systems and services to achieve the target state. This sequencing plan details the sequenced tasks necessary to develop the elements of the WBS. Internal and external dependencies are also included as either milestones or predecessor tasks.

5.2.3      Develop the draft segment blueprint
Edit section

A draft segment blueprint is developed that describes findings, recommendations, and the overall segment transition plan. This document should be generated according to the outline provided below. A separate executive summary document may also be created. The blueprint document also contains descriptions of some of the key analysis performed in process steps 2, 3 and 4.

Communications Considerations:

Edit section

It may be necessary to consult with the business architecture and data architecture teams to identify business processes and data elements of the WBS. The WBS form may also need to be shared across the organization whenever external dependencies are known to exist for specific recommendations.

Activity Outputs:

Edit section

  • Strategic systems migration / sequencing overview
  • Strategic systems migration / sequencing performance milestones
  • Recommendation implementation sequencing plan
  • Segment architecture blueprint document (incl. sequencing plan)
  • Segment mappings
  • Transition plan milestones

Suggested Analytical Techniques

Edit section

 
Output Core FEA Layers Suggested Analytical Technique Examples/Templates Contributing Agency/Team
P B D S T
Strategic systems migration / sequencing overview Yes       X X Recommendation sequencing diagram Recommendation sequencing diagram word format Department of the Interior (DOI)
Recommendation implementation sequencing plan No           Implementation sequencing plan Implementation sequencing plan project format Federal Segment Architecture Working Group (FSAWG)
Segment architecture blueprint document (incl. sequencing plan) Yes X X X X X Modernization blueprint Modernization blueprint word format Federal Segment Architecture Working Group (FSAWG)
Segment mappings Yes X X X X X Segment mappings Segment mappings excel format Federal Segment Architecture Working Group (FSAWG)
Transition plan milestones Yes X X X X X Segment transition plan milestones Segment transition plan milestones excel format Federal Segment Architecture Working Group (FSAWG)
  Key to FEA Layers
P = Performance
B = Business
D = Data
S = Service
T = Technology

Segment Blueprint Sample Outline

Edit section

  • Executive Overview:  This brief (1-2 pages) overview describes the motivation behind the segment blueprint. It is focused on providing clear, concise answers to key questions, such as:
    • Where are we today? (Baseline)
    • Why do we need to modernize? (Target Performance Improvement Opportunities)
    • What is our vision for modernization? (Target Architecture)
    • How should we execute modernization? (Candidate Solutions / Projects)
    • When should we modernize and what are the relationships to other initiatives? (Sequencing Plan / Implementation Plan)
    • Who needs to participate for this initiative to be successful? (Resource Plan)
  • Overview of Business Performance Opportunities:  Provides a discussion of the scope, strategic intent, drivers and opportunities for improvement within the segment. This section further elaborates upon the following key questions:
    • Where are we today? (Baseline)
    • Why do we need to modernize? (Target Performance Improvement Opportunities)
  • Recommendations for Segment Modernization:  Describes the existing architecture issues from a variety of perspectives that address the target performance opportunities. The Findings and Recommendations (F&R) are described in the context of the specific business products and services where improvements are recommended due to strategic drivers such as eliminating redundancies, filling voids or other general industry trends. All findings are associated to specific recommendations on how to proceed. Expected performance improvements associated with the recommendations are also identified. This section further elaborates upon the following key questions:
    • How should we execute modernization? (Candidate Solutions / Projects)
  • Target Business / Data and Technology Environment:  This should include a brief description of the business functions and services that are provided and the strategic objectives that are to be achieved by the transformation. It also describes target state for the technology environment required to support the segment modernization recommendations and the strategic systems migration plan, along with the target conceptual data model and environment. This section further elaborates upon the following key questions:
    • What is our vision for modernization? (Target Architecture)
    • Have we achieved the required level of security and privacy protection for the segment? (Target Architecture)
  • Sequencing Plan:  Describes the as-is state, target state, and the integrated steps required to transition from the as-is to the target environment based on the identified recommendations. Within the sequencing plan, performance improvements are also associated with segment transition milestones. The sequencing plan will also inform the downstream prioritization and development of business cases or investment proposals, initiation of projects, and development of policies and procedures. This section further elaborates upon the following key questions:
    • When should we modernize and what are the relationships to other initiatives? (Sequencing Plan / Implementation Plan)
    • Who needs to participate for this initiative to be successful? (Resource Plan)
  • Additional Appendices: (as needed) that provide artifacts or additional reference information that provide more detailed architectural information and analysis (e.g. supporting artifacts, repository reports, data standards, etc.).

Activity 5.3:  Review and finalize the blueprint and sequencing plan

Edit section

Activity Description:

Edit section

The draft segment architecture blueprint is distributed to the core team for review. Throughout the review process, feedback is recorded and consolidated, and resulting actions are tracked. Once the review is completed, the final segment architecture blueprint document is prepared for submission to the appropriate governance teams.

Activity 5.3:  Review and finalize the blueprint and sequencing plan
Flowchart for Activity 5.3

Activity Inputs:

Edit section

  • Strategic systems migration / sequencing overview
  • Strategic systems migration / sequencing performance milestones
  • Recommendation implementation sequencing plan
  • Segment architecture blueprint document (incl. sequencing plan)

Tasks:

Edit section

5.3.1      Distribute the draft segment blueprint for review
Edit section

The draft segment blueprint is distributed for review to the core team, business owner(s) and executive sponsor. Accompanying this distribution is a cover letter that describes the highlights of the blueprint. A separate executive summary document may also be provided for review. During the review process, a document review form may be used to collect review comments and change requests.    

5.3.2      Collect comments
Edit section

During the review process, all feedback is recorded, dispensed and consolidated. Follow-up actions are documented and tracked through to completion.

5.3.3      Develop the final segment blueprint
Edit section

As feedback actions are documented and closed, comments and changes are also incorporated into the draft segment blueprint document. This may also result in updates to other work products such as the sequencing WBS and project plan.

Communications Considerations:

Edit section

It may be necessary to conduct face-to-face meetings with individual core team members, business owner(s) and the executive sponsor to review the blueprint findings, implementation recommendations and sequencing plan.

Activity Outputs:

Edit section

  • Document review log
  • Feedback tracking and action report

Suggested Analytical Techniques

Edit section

 
Output Core FEA Layers Suggested Analytical Technique Examples/Templates Contributing Agency/Team
P B D S T
Document review log No           Document review form Document review form word format Federal Segment Architecture Working Group (FSAWG)
Feedback tracking and action report No           Feedback tracking and action report Feedback tracking and action report excel format Federal Segment Architecture Working Group (FSAWG)
  Key to FEA Layers
P = Performance
B = Business
D = Data
S = Service
T = Technology

Activity 5.4:  Brief core team and obtain approval

Edit section

Activity Description:

Edit section

In this activity, a formal presentation of the segment blueprint is made to the core team, business owner(s), and the executive sponsor, after which the decision to approve the segment blueprint is recorded either as a separate signed document or in the form of published meeting minutes. Any issues that arise during the final review are addressed and closed as needed. The formal presentation may also be accompanied by an executive overview document describing the need for the transformation and a summary of the analysis of findings, transition options and implementation recommendations. Once this activity is complete, the executive sponsor, business owner(s) and core team can move forward with gaining approvals from the broader business community and capital planning governance teams such as the Investment Review Board (IRB).

Activity 5.4:  Brief core team and obtain approval
Flowchart for Activity 5.4

Activity Inputs:

Edit section

  • Strategic systems migration / sequencing overview
  • Recommendation implementation sequencing plan
  • Segment architecture blueprint document (incl. sequencing plan)
  • Document review log
  • Feedback tracking and action report

Tasks:

Edit section

5.4.1      Distribute final review materials
Edit section

The finalized segment blueprint is distributed for review to the core team, business owner(s) and executive sponsor. Accompanying this distribution is a cover letter that describes the highlights of the blueprint. A separate executive summary document may also be provided for review.

5.4.2      Conduct review and obtain approval
Edit section

A formal review meeting is scheduled and conducted to obtain formal approval of the blueprint by the core team, business owner(s) and executive sponsor and a record of decision is created to document the decision.

Communications Considerations:

Edit section

Once approved, the executive sponsor should be prepared to present the blueprint to other governance teams for additional approval as may be required.

Activity Outputs:

Edit section

  • Blueprint executive summary presentation
  • Approved segment architecture blueprint document (incl. sequencing plan)
  • Record of decision (ROD)

Suggested Analytical Techniques:

Edit section

None

Step References

Edit section

Value Measuring Methodology:  Highlights pdf, Federal Chief Information Officer (CIO) Council Best Practices Committee, October, 2002.

Value Measuring Methodology:  How to Guide pdf, Federal Chief Information Officer (CIO) Council Best Practices Committee, October, 2002.

4. Outputs and Suggested Analytical Techniques

http://www.fsam.gov/federal-segment-architecture-methodology-toolkit/outputs-techniques.php

The FSAM includes a comprehensive toolkit of suggested analytical techniques as summarized in Appendix I. Analytical techniques are provided for the outputs of each activity, as defined in FSAM, and are based on agency best practices that were assessed for inclusion by the Federal Segment Architecture Working Group (FSAWG).

Appendix I identifies which of the outputs are considered "core FSAM outputs."  The "core" designation suggests that the outputs deliver a complete segment architecture, as defined in the OMB EAAF v3.0 reporting requirements. All mappings defined in Appendix I are based on the data attributes as defined for each output in the corresponding suggested analytical techniques.

Appendix I also identifies which FSAM outputs, when used with the suggested analytical techniques, either support (S) or are core (C) to satisfying key usage requirements corresponding to strategic planning, capital planning, information technology (IT) governance, EAAF reporting, solution development, and security / privacy. These additional designations are meant to assist architects with identifying opportunities for FSAM outputs to be used within other planning and decision making processes.

Appendix I: Summary of FSAM Outputs PDF format HTML format
Relationship Diagram of FSAM Outputs by Process Step PDF format
Analytical Techniques by Process Steps zip format

5. FSAM Data Model

http://www.fsam.gov/federal-segment-architecture-methodology-toolkit/data-model.php

Background

As part of the development of the Federal Segment Architecture Methodology (FSAM), Federal Segment Architecture Working Group (FSAWG) members followed the evolution of the segment architecture template being developed in parallel by the Performance and Investment Tiger Team (P&ITT). With the release of Enterprise Architecture Framework 3.0, FSAWG and P&ITT team members collaborated to align relevant FSAM artifacts precisely with the Enterprise Architecture Segment Report (EASR) and with the information collection requirements presented by EAAF 3.0 Key Performance Indicators (KPI's). That alignment is summarized in Table 1.

Table 1 :  EASR/FSAM Artifact Alignment

 
Enterprise Architecture Segment Report (EASR) Corresponding FSAM Artifact
Segment Identification Incorporated as a header. Segment identification information is created in the EA-level processes that define and prioritize segments.
Segment Mappings Form Segment mappings
Segment Performance Form Performance scorecard
Segment Transition Planning Form Transition plan milestones
Segment Collaboration and Reuse Form Stakeholder map
Reuse summary
Data Reuse

Purpose and Scope of the FSAM Logical Data Model

The EASR integrates data available in and reported from the agency capital planning and investment control (CPIC) process with data available in agency segment architectures. For the first time this year, the CPIC portfolio is linked directly and precisely to the agency segment architectures in agency IT budget justification submissions, the OMB Circular A-11 Exhibit 53 and Exhibits 300. In order to better understand the data integration requirements that EAAF 3.0 OMB reporting will require, support the management of the data consistency requirements EAAF 3.0 creates, and ensure that FSAM artifacts are aligned correctly, FSAWG has produced an integrated logical data model, Figure 1.

The FSAM logical data model describes the Exhibit 53 and Exhibit 300 data that is of interest for EA reporting and integrates it with the EASR data. Crosswalks between the FSAM data model, the Exhibit 53, the Exhibit 300, and the EASR are provided in Tables 2, 3 and 4, respectively.

References

OMB Circular No. A-11 Part 2 (2008), Section 53—Information Technology and E-Government pdf 
OMB Circular No. A-11 Part 7 (2008), Section 300—Planning, Budgeting, Acquisition, and Management of Capital Assets pdf
Federal Enterprise Architecture Program EA Assessment Framework, Version 3.0, Draft, 2008
Enterprise Architecture Segment Report, Version 1.1, November 25, 2008

FSAM Logical Data Model

 

Figure 1:  FSAM Logical Data Model



(click above thumbnail to see larger version)

 

Relationship Legend
Broken line = Non-identifying relationship
Solid line = Identifying relationship
Unmarked Child = Zero, one or more instances
Z on Child = Zero or one instances
P on Child = One or more instances

Table 2:  FSAM/Exhibit 53 Crosswalk

 
Column Number Column Label ID Definition FSAM Entity FSAM Attribute
1 2009 UPI 532009UPI The unique project identifier used to report the investment in the 2009 Budget. Indicating the UPI used for the 2009 Budget process allows cross-walk and historical analysis crossing fiscal years for tracking purposes. All investments CY UPI Code
2 2010 UPI 532010UPI The identifier depicting agency code, bureau code, mission area (where appropriate), part of the exhibit where investment will be reported, type of investment, agency four-digit identifier, and two-digit investment category code. All Investments BY UPI Code
3 Investment Title 53IT A definitive title explaining the investment. If the investment title has changed, include the previous name in parentheses. For "funding source" information, provide the 10-digit OMB max account code. All Investments Investment Title
4 Investment Description 53IDscr A short public description (limited to 255 characters) for each investment (major, migration, partner contribution, and non-major). This description should explain the entry item, its components, and what program(s) it supports. All Investments Investment Description
5 Primary FEA Mapping - Line of Business or Service Type (3 digit code) 53PFEA1 The 3-digit code for either the primary Line of Business from the FEA BRM OR the primary cross-cutting Service Type from the FEA SRM. All Investments Primary FEA Mapping LOB or Service Type
6 Primary FEA Mapping - Sub-Function or Service Component (3 digit code) 53PFEA2 The 3-digit code for either the primary Sub-function under the BRM Line of Business OR the primary cross-cutting Service Component under the SRM Service Type identified in the BRM Line of Business or SRM Service Type. All Investments Primary FEA Mapping Sub-Function or Service Component
15 Development, Modernization, Enhancement (DME) (PY/2008) ($M) 53DMEPY Development/Modernization/Enhancement (DME) means the program cost for new investments, changes or modifications to existing systems to improve capability or performance, changes mandated by the Congress or agency leadership, personnel costs for investment management, and direct support. For major IT investments, this amount should equal the sum of amounts reported for planning and acquisition plus the associated FTE costs reported in the exhibit 300. All Investments DME PY Amount
16 Development, Modernization, Enhancement (DME) (CY/2009) ($M) 53DMECY Development/Modernization/Enhancement (DME) means the program cost for new investments, changes or modifications to existing systems to improve capability or performance, changes mandated by the Congress or agency leadership, personnel costs for investment management, and direct support. For major IT investments, this amount should equal the sum of amounts reported for planning and acquisition plus the associated FTE costs reported in the exhibit 300. All Investments DME CY Amount
17 Development, Modernization, Enhancement (DME) (BY/2010) ($M) 53DMEBY Development/Modernization/Enhancement (DME) means the program cost for new investments, changes or modifications to existing systems to improve capability or performance, changes mandated by the Congress or agency leadership, personnel costs for investment management, and direct support. For major IT investments, this amount should equal the sum of amounts reported for planning and acquisition plus the associated FTE costs reported in the exhibit 300. All Investments DME BY Amount
18 Steady State (SS) (PY/2008) ($M) 53SSPY Steady State (SS) means maintenance and operation costs at current capability and performance level including costs for personnel, maintenance of existing information systems, corrective software maintenance, voice and data communications maintenance, and replacement of broken IT equipment. for major IT investments, this amount should equal the amount reported for maintenance plus the associated FTE costs reported in the exhibit 300. All Investments SS PY Amount
19 Steady State (SS) (CY/2009) ($M) 53SSCY Steady State (SS) means maintenance and operation costs at current capability and performance level including costs for personnel, maintenance of existing information systems, corrective software maintenance, voice and data communications maintenance, and replacement of broken IT equipment. for major IT investments, this amount should equal the amount reported for maintenance plus the associated FTE costs reported in the exhibit 300. All Investments SS CY Amount
20 Steady State (SS) (BY/2010) ($M) 53SSBY Steady State (SS) means maintenance and operation costs at current capability and performance level including costs for personnel, maintenance of existing information systems, corrective software maintenance, voice and data communications maintenance, and replacement of broken IT equipment. for major IT investments, this amount should equal the amount reported for maintenance plus the associated FTE costs reported in the exhibit 300. All Investments SS BY Amount
21 Investment C&A Status (00, 02, 22, 25, 55) 53C&A The current security Certification and Accreditation (C&A) status of the investment's system(s). All Investments C&A Status
24 Segment Architecture (6 digit code) 53SA The agency segment architecture the investment supports. All Investments Segment Code


Table 3:  FSAM/Exhibit 300 Crosswalk

 
Page Part Section Number
/Table
Question or Label FSAM Entity FSAM Attribute
10 I A 1 Date of Submission Exhibit 300 Investments Part I Section A Submission Date
10 I A 2 Agency Exhibit 300 Investments Part I Section A Agency
10 I A 3 Bureau Exhibit 300 Investments Part I Section A Bureau
10 I A 4 Name of this Capital Asset Exhibit 300 Investments Part I Section A Capital Asset Name
10 I A 5 Unique Project (Investment Identifier) Exhibit 300 Investments Part I Section A BY UPI Code
10 I A 7 What was the first budget year this investment was submitted to OMB? Exhibit 300 Investments Part I Section A First Year of Budget Submission
10 I A 8 Provide a brief summary and justification for this investment, including a brief description of how this closes in part or in whole an identified agency performance gap. Exhibit 300 Investments Part I Section A Investment Description
11 I A 14 Does this investment support a program assessed using the Program Assessment Rating Tool (PART)? Part I Section A PART Information N/A
11 I A 14a If "yes," does this investment address a weakness found during a PART review? Part I Section A PART Information PART Weakness Addressed
11 I A 14b If "yes," what is the name of the PARTed program? Part I Section A PART Information PART Program Name
11 I A 14c If "yes," what rating did the PART receive? Part I Section A PART Information PART Program Rating
16 I D PI Table Fiscal Year Integrated Performance Information Fiscal Year
16 I D PI Table Strategic Goal (s) Supported Integrated Performance Information Strategic Goal Supported
16 I D PI Table Measurement Area Integrated Performance Information Measurement Area
16 I D PI Table Measurement Grouping Integrated Performance Information Measurement Grouping
16 I D PI Table Measurement Indicator Integrated Performance Information Measurement Indicator
16 I D PI Table Baseline Integrated Performance Information Measurement Baseline
16 I D PI Table Target Integrated Performance Information Measurement Target
16 I D PI Table Actual Results Integrated Performance Information Measurement Actual Results
19 I F 3 Is this investment identified in a completed and approved segment architecture? All Investments (Exhibit 53)  
19 I F 3a If "yes," provide the six digit code corresponding to the agency segment architecture. All Investments (Exhibit 53) Segment Code
19 I F 4 Agency Component Name Part I Section F SRM Table Agency Component Name
19 I F 4 Agency Component Description Part I Section F SRM Table Agency Component Description
19 I F 4 FEA SRM Service Type Part I Section F SRM Table FEA SRM Service Type
19 I F 4 FEA SRM Component (a) Part I Section F SRM Table FEA SRM Component
19 I F 4 Service Component Reused (b) Component Name Part I Section F SRM Table Service Component Reused Component Name
19 I F 4 Service Component Reused (b) UPI Part I Section F SRM Table Service Component Reused UPI
19 I F 4 Internal or External Reuse? (c) Part I Section F SRM Table Internal or External Reuse
19 I F 4 BY Funding Percentage (d) Part I Section F SRM Table BY Funding Percentage
20 I F 5a FEA SRM Component (a) Part I Section F TRM Table FEA SRM Component
20 I F   FEA TRM Service Category Part I Section F TRM Table FEA TRM Service Category
20 I F   FEA TRM Service Standard Part I Section F TRM Table FEA TRM Service Standard
20 I F 5b Service Specification (b) Part I Section F TRM Table Service Specification
24 II C 4 Description of Milestone (Current Baseline) Integrated E-300 Milestones Table Milestone Description
24 II C 4 Planned Completion Date (Current Baseline) Integrated E-300 Milestones Table Planned Completion Date
24 II C 4 Actual Completion Date (Current Baseline) Integrated E-300 Milestones Table Actual Completion Date
25 III B 2b Description of Milestone Integrated E-300 Milestones Table Milestone Description
25 III B 2b Planned Completion Date Integrated E-300 Milestones Table Planned Completion Date
25 III B 2b Planned Total Cost Integrated E-300 Milestones Table  
25 III B 2b Actual Completion Date Integrated E-300 Milestones Table Actual Completion Date
29 IV C 4 Description of Milestone (Current Baseline) Integrated E-300 Milestones Table Milestone Description
29 IV C 4 Planned Completion Date (Current Baseline) Integrated E-300 Milestones Table Planned Completion Date
29 IV C 4 Actual Completion Date (Current Baseline) Integrated E-300 Milestones Table Actual Completion Date


Table 4:  FSAM/Enterprise Architecture Segment Report (EASR) Crosswalk

 
EASR Object/Section Segment Architecture Template Attribute Definition/Description Associated FSAM Output FSAM Entity FSAM Attribute
Segment Identification Segment Code The segment architecture code as submitted to OMB. All FSAM artifacts in Table 1 Segment Identification Segment Code
Segment Identification Name Name of the Segment. All FSAM artifacts in Table 1 Segment Identification Segment Name
Segment Identification Description Brief Description of the Segment. All FSAM artifacts in Table 1 Segment Identification Segment Description
Segment Identification Organizational Owner Agency Name All FSAM artifacts in Table 1 Segment Identification Organizational Owner
Segment Identification Agency Code Agency UID. Agency Code as defined in OMB-A11 Appendix C. All FSAM artifacts in Table 1 Segment Identification Agency Code
Segment Identification Segment Type Core Mission, Business Services, or Enterprise Service Segment. All FSAM artifacts in Table 1 Segment Identification Segment Architecture Type
Segment Identification Segment Maturity Segment Development Phase All FSAM artifacts in Table 1 Segment Identification Segment Maturity
Segment Identification Priority Segment Identifies with a Yes/No if this Segment has been identified by the Agency as a Priority Segment All FSAM artifacts in Table 1 Segment Identification Priority Segment
IT Investment Mapping Investment Name Investment Name. Segment Mappings All Investments Investment Title
IT Investment Mapping IT Investment UPI Related IT Investment UID from the Exhibit 53 if applicable. Segment Mappings All Investments BY UPI Code
IT Investment Mapping Description Investment Description. Segment Mappings All Investments Investment Description
PARTed Program Mapping Parted Program Name PARTed Program Name. Segment Mappings PART Mapping PARTed Program Name
PARTed Program Mapping PARTed Program ID PARTed Program ID. Segment Mappings PART Mapping PARTed Program ID
PARTed Program Mapping Associated IT Investment Investment Name. Segment Mappings Part I Section A PART Information PART Program Name
PARTed Program Mapping IT Investment UPI Related IT Investment UID from the Exhibit 53 if applicable. Segment Mappings Part I Section A PART Information BY UPI Code
FTF Initiative Use FTF Initiative Name FTF Initiative supported or used by this Segment. Segment Mappings FTF Initiative Mapping FTF Initiative Name
FTF Initiative Use FTF Supported or used by Segment? Yes/No. Segment Mappings FTF Initiative Mapping Supported/Used Indicator
FTF Initiative Use Explanation for not using the FTF Initiative (if applicable)  Not separately defined in the segment architecture template. Segment Mappings FTF Initiative Mapping Explanation for Not Using FTF
FEA BRM Mapping BRM Business Area FEA BRM Business Area Segment Mappings BRM Mapping BRM Business Area
FEA BRM Mapping BRM Line of Business FEA BRM Line of Business Segment Mappings BRM Mapping BRM Line of Business
FEA BRM Mapping BRM Sub-Function FEA BRM Sub-Function Segment Mappings BRM Mapping BRM Sub-Function
FEA BRM Mapping Current/Target Current State, Target State, Both States Segment Mappings BRM Mapping Current/Target
FEA SRM Mapping SRM Service Domain FEA SRM Service Domain Segment Mappings SRM Mapping SRM Service Domain
FEA SRM Mapping SRM Service Type FEA SRM Service Type Segment Mappings SRM Mapping SRM Service Type
FEA SRM Mapping SRM Component FEA SRM Component Segment Mappings SRM Mapping SRM Component
FEA SRM Mapping Current/Target Current State, Target State, Both States Segment Mappings SRM Mapping Current/Target
FEA TRM Mapping TRM Service Area FEA TRM Service Area Segment Mappings TRM Mapping TRM Service Area
FEA TRM Mapping TRM Service Category FEA TRM Service Category Segment Mappings TRM Mapping TRM Service Category
FEA TRM Mapping TRM Service Standard TRM Service Standard Segment Mappings TRM Mapping TRM Service Standard
FEA TRM Mapping Current/Target Current State, Target State, Both States Segment Mappings TRM Mapping Current/Target
Strategic Performance PAR Metric PAR performance measurement. Performance Scorecard PAR Performance PAR Metric
Strategic Performance Fiscal Year Fiscal year in which the metric is being measured. Performance Scorecard PAR Performance Fiscal Year
Strategic Performance Component, Bureau, Operating Division, etc. Owning organization. Agency and Bureau Code as defined in the OMB-A11 Appendix C. Performance Scorecard PAR Performance Agency Component Code
Strategic Performance Agency Code Agency and Bureau Code as defined in the OMB-A11 Appendix C. Performance Scorecard PAR Performance Agency Code
Strategic Performance Strategic Goal Agency strategic goal supported by the performance metric. Performance Scorecard PAR Performance Strategic Goal
Strategic Performance Target Target metric. Performance Scorecard PAR Performance PAR Metric Target
Strategic Performance Actual Actual metric. Performance Scorecard PAR Performance PAR Metric Actual
Strategic Performance Achieved? Whether or not the target was achieved. Performance Scorecard PAR Performance Target Achieved Indicator
Segment Performance Fiscal Year Fiscal year that the metric is captured. Performance Scorecard Segment Performance Fiscal Year
Segment Performance Metric Performance Metric Description Performance Scorecard Segment Performance Segment Metric
Segment Performance Target Target Metric Performance Scorecard Segment Performance Segment Metric Target
Segment Performance Actual Actual metric. Performance Scorecard Segment Performance Segment Metric Actual
Segment Performance Comments Comments, including reference to the M-06-22 completed if this metric describes Cost Savings/Avoidance. Performance Scorecard Segment Performance Comments
Program Performance Program PARTed Program Name. Performance Scorecard PART Performance Program Name
Program Performance Component, Bureau, Operating Division, etc. Owning organization. Performance Scorecard PART Performance Agency Component Code
Program Performance Agency Code Agency and Bureau Code as defined in the OMB-A11 Appendix C. Performance Scorecard PART Performance Agency Code
Program Performance Year Assessed The last year the program was assessed. Performance Scorecard PART Performance Year Assessed
Program Performance Final Rating Final PART rating. Performance Scorecard PART Performance Final Rating
Business Performance Fiscal Year Fiscal year that the metric is captured. Performance Scorecard Integrated Performance Information Fiscal Year
Business Performance Metric ID Agency-defined ID for the performance metric. Performance Scorecard Integrated Performance Information Measurement ID
Business Performance Metric Type Type of Metric Performance Scorecard Integrated Performance Information Metric Type
Business Performance Measurement Indicator Performance Metric Description Performance Scorecard Integrated Performance Information Measurement Indicator
Business Performance IT Investment Name Investment Name. Performance Scorecard All Investments Investment Title
Business Performance System/App/Program Name System/App/Program Name Performance Scorecard Integrated Performance Information System/App/ Program Name
Business Performance Strategic Goal Agency strategic goal supported by the performance metric. Performance Scorecard Integrated Performance Information Strategic Goal Supported
Business Performance Line of Business or Service Type FEA BRM Line of Business or SRM Service Type Performance Scorecard Integrated Performance Information LOB or Service Type
Business Performance Sub-Function or Service Component FEA BRM Sub-Function or SRM Service Component Performance Scorecard Integrated Performance Information Sub-Function or Service Component
Business Performance Agency Business Process Agency-Defined Business Process. Performance Scorecard Integrated Performance Information Agency Business Process
Business Performance Target Target Metric Performance Scorecard Integrated Performance Information Measurement Target
Business Performance Actual Actual metric. Performance Scorecard Integrated Performance Information Measurement Actual Results
Segment Transition Plan Milestone ID Agency-Defined ID for the Milestone. Segment Transition Plan Milestones Segment Transition Plan Milestone ID
Segment Transition Plan IT Investment/System /Program/etc. Major IT investment or program related to the milestone. Segment Transition Plan Milestones Segment Transition Plan IT Investment/ System/ Program
Segment Transition Plan Segment Milestone Segment Milestone. Segment Transition Plan Milestones Segment Transition Plan Milestone Description
Segment Transition Plan Target Completion Date Target Completion Date. Segment Transition Plan Milestones Segment Transition Plan Planned Completion Date
Segment Transition Plan Actual Completion Date Actual Completion Date. Segment Transition Plan Milestones Segment Transition Plan Actual Completion Date
Segment Transition Plan Dependant on Milestone X Row number of a milestone that this milestone's completion is dependant upon. Segment Transition Plan Milestones Segment Transition Plan Dependency Milestone ID
Segment Transition Plan Dependencies/ Constraints Dependencies or constraints related to this milestone. Segment Transition Plan Milestones Segment Transition Plan Dependencies/Constraints
Segment Collaboration & Reuse Segment Name  Name of the segment. Segment/Business/System/ Service Reuse Segment Identification Segment Name
Segment Collaboration & Reuse Segment Code OMB Segment Code Segment/Business/System/ Service Reuse Segment Identification Segment Code
Segment Collaboration & Reuse Segment Reuse Explanation Explanation on how a Segment is being Reused by another segment Segment/Business/System/ Service Reuse Segment Identification Reuse Explanation
Stakeholders Stakeholder Name of the Stakeholder group affected by this Segment Stakeholder Map Template Stakeholders Stakeholder Name
Stakeholders Agency Code Agency Code of the Stakeholder Stakeholder Map Template Stakeholders Stakeholder Agency Code
Information System System Name Name of the System being Reused in this segment. This represents secondary mappings for IT Investments Segment/Business/System/ Service Reuse Information System Reuse System Name
Information System System Description System Description Segment/Business/System/ Service Reuse Information System Reuse System Description
Information System System Owner System Owner Name Segment/Business/System/ Service Reuse Information System Reuse System Owner
Information System Agency Code Agency Code of the system Segment/Business/System/ Service Reuse Information System Reuse Owner Agency Code
Data Exchange Package Reused Data Exchange Package Name

Name of the Data Exchange Package

Data Reuse

Data Exchange Package Reuse

DEP Name

Data Exchange Package

Data Exchange Description

Description of the information being exchanged in the package and the systems which are exchanging the data

Data Reuse

Data Exchange Package Reuse

DEP Description

Data Exchange Package

Organizational Owner

Organizational Owner Data Reuse Data Exchange Package Reuse DEP Organizational Owner
Data Exchange Package Data Steward Person/ Group/ Division/ Etc responsible for maintaining the data standard for the information contained within the Data Exchange listed Data Reuse Data Exchange Package Reuse DEP Data Steward
Data Exchange Package Agency Code Agency Code of the owner of the data exchange Data Reuse Data Exchange Package Reuse Owner Agency Code
Data Exchange Package Owning Information System Name of the system which owns the information being used in the data exchange Data Reuse Data Exchange Package Reuse Owning Information System
Data Exchange Package Using Information System Name of the system which receives the information being used in the data exchange Data Reuse Data Exchange Package Reuse Using Information System
Data Entity Data Package Name

Name of the data package which the Data Entity is found

Data Reuse

Data Entity Reuse

DEP Name

Data Entity

Data Entity Name

Name of the Data Entity that is part of the Data Exchange Package being reused

Data Reuse

Data Entity Reuse Entity Name
Data Entity Description Description of the Data Entity Data Reuse Data Entity Reuse Entity Description
Data Entity Data Steward (Organization) Organization/ Person/ Group/ Division/ Etc responsible for maintaining the data standard for the information contained within the Data Exchange listed Data Reuse Data Entity Reuse Data Steward
Data Entity Agency Code Agency Code for the Data Steward Data Reuse Data Entity Reuse Steward Agency Code
Business Collaboration and Reuse BRM Business Area BRM Business Area Segment/Business/System/ Service Reuse Business Collaboration and Reuse BRM Business Area
Business Collaboration and Reuse BRM Line of Business BRM Line of Business Segment/Business/System/ Service Reuse Business Collaboration and Reuse BRM LOB
Business Collaboration and Reuse BRM Sub function BRM Sub function Segment/Business/System/ Service Reuse Business Collaboration and Reuse BRM Sub function
Business Collaboration and Reuse Providing Organization Name of the Organization that may provide the reusable business activity Segment/Business/System/ Service Reuse Business Collaboration and Reuse Providing Organization
Business Collaboration and Reuse Agency Code Agency Code of the Providing Organization Segment/Business/System/ Service Reuse Business Collaboration and Reuse Providing Organization Agency Code
System Service System Service Name Name of the Service being reused Segment/Business/System/ Service Reuse System Service Reuse Service Name
System Service  System Service Description Description of the Service being reused Segment/Business/System/ Service Reuse System Service Reuse Service Description
System Service System Name Name of the System providing the service Segment/Business/System/ Service Reuse System Service Reuse System Name
System Service Provider Organization System Owner Name Segment/Business/System/ Service Reuse System Service Reuse Provider Organization
System Service  Agency Code Agency code of the System Owner Segment/Business/System/ Service Reuse Reused System Service Provider Agency Code

Data Integration would be simplified with the addition of the PARTed Program ID to the Exhibit 300.

Page statistics
2245 view(s) and 3 edit(s)
Social share
Share this page?

Tags

This page has no custom tags.
This page has no classifications.

Comments

You must to post a comment.

Attachments