Process Step 3 — Define Business and Information Requirements
Step Description and Purpose
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
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
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.
| 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? | |||||
![]() | |||||
Activity Details
Activity 3.1: Determine current business and information environment associated with strategic improvement opportunities
Activity Description:
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
![]()
Activity Inputs:
- Process step 1 outputs
- Process step 2 outputs
Tasks:
3.1.1 Determine the value chains for the common / mission services
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
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
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
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
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:
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:
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:
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:
- 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
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 Department of Justice (DOJ) As-is business function model Yes X As-is business function model As-is business function model Department of the Interior (DOI) As-is key business
process modelNo X As-is business activity model As-is business activity model Department of Defense (DoD) As-is business process
swim lane diagramNo X As-is business process swim lane diagram As-is business process swim lane diagram ![]()
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 ![]()
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
Activity Description:
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
![]()
Activity Inputs:
- 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:
3.2.1 Align strategic improvement opportunities to the business architecture
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
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
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
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:
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:
- Business and data architecture adjustment profiles
Suggested Analytical Techniques
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 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
Activity Description:
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
![]()
Activity Inputs:
- 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:
3.3.1 Define target business processes and their performance including organizational relationships
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
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
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
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:
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:
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:
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:
- 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
Output Core FEA Layers Suggested Analytical Technique Examples/Templates Contributing Agency/Team P B D S T Target business
value chain diagramNo X Target business value chain analysis Target business value chain analysis Department of Justice (DOJ) Target business
function modelYes X Target business function model Target business function model Department of the Interior (DOI) Target key business
process modelNo X Target business activity model Target business activity model Department of Defense (DoD) Target business process
swim lane diagramNo X Target business process swim lane diagram Target business process swim lane diagram Department of Justice (DOJ) Target conceptual
data modelYes X Target conceptual data model Target conceptual data model Office of Personnel Management - Human Resources Line of Business (HR-LOB) Target information
flow diagramYes X X Target information flow diagram Target information flow diagram Information Sharing Environment (ISE) Target data
steward assignmentsYes X Target data steward matrix Target data steward matrix 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 Department of Health and Human Services (HHS) Target information
sharing matrixYes X Target information sharing matrix Target information sharing matrix 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
Activity Description:
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
![]()
Activity Inputs:
- 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:
3.4.1 Package business and data architectures
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
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:
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:
- Business and data architecture presentation
Suggested Analytical Techniques:
None
Step References
Federal Enterprise Architecture Program, The Data Reference Model, Version 2.0
, 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
, April 2008
A Practical Guide to Federal Service Oriented Architecture
, Version 1.1, June 2008

