enterprise architecture tjtse25 2009 yrityksen kokonaisarkkitehtuuri · consolidated reference...
TRANSCRIPT
Enterprise ArchitectureTJTSE25 2009
Yrityksen kokonaisarkkitehtuuri
J u k k a ( J u p s ) H e i k k i l äP r o f e s s o r , I S ( e B u s i n e s s )
F a c u l t y o f I n f o r m a t i o n T e c h n o l o g y
U n i v e r s i t y o f J y v ä s k y l ä
e - m a i l : j u p s @ c c . j y u . f i
t e l : + 3 5 8 5 0 5 8 1 8 3 6 1
h t t p : / / w w w . c s . j y u . f i / e l
1
The roles (Unde, 2008)
7 • Journal 15 • www.architecturejournal.net
Becoming an Architect in a System Integrator!"#$%&'#()*+
Being an architect is tough! What architects do is a mystery to much of the world—this is hardly surprising since an architect’s work is intangi-ble—“thought-ware,” if you will—and it happens in the background. That makes many wonder about the architect’s role in an organization. Archi-tects interact with many stakeholders—CIOs, project managers, business users, and developers—and each expects them to work differently. While the CIO expects an architect to derive a solution roadmap for implement-ing the company’s IT vision, the developer expects the architect to pro-vide direction on the technical problem. The architect needs to have a bird’s eye view in one scenario, while in some other scenarios, the architect needs to dive deep into the problem area. The architect is expected to be both a generalist and a specialist. Many companies try to reduce the ambiguity by introducing different fl avors of the role, such as enterprise architect or solution architect. Ironically, differentiation within the role can add to the confusion since there is no standardization of the designations across companies. Let’s fi nd the commonalities and defi ne these different fl avors of the role.
The Architect RoleTypically, there are three different variations of the roles (Figure 1):
Enterprise Architect/Chief ArchitectThe enterprise architect is responsible for implementing the CIO’s vision and strategy for IT. It includes defi ning strategic programs (usually multiyear, multimillion dollars for large organizations), selecting the appropriate technology platforms, and providing guidance for implementations. The enterprise architect aids the CIO in making sure that the IT investments are aligned to the business strategy, and provide competitive edge for the organization. The person is also responsible for defi ning the standards and guidelines, and putting up a governance mechanism to align implementation to the defi ned standards and guidelines. In some organizations, this role is merged with that of the CIO
and has the title “Chief Architect.” This is especially true for many product and platform companies.
Solution ArchitectThe solution architect is responsible for implementing a strategic IT program. This includes defi ning the architectural solution for the program (usually spanning multiple technologies), selecting technology platforms in adherence to corporate strategy, handling intergroup communication, and making decisions on technical issues in implementation. The solution architect usually needs to mediate between business and technology teams and various other groups. The solution architect is the “go-to” person for any technology confl icts, implementation issues, or decisions. In some organizations, this role is defi ned just as “Architect.” The senior position has the title “Lead Architect.”
Technical ArchitectThe technical architect is usually a technology specialist in a particular technology. This person has expert knowledge of the underlying technology function, its integral components, and understands the strengths and limitations of the technology. This person is responsible for determining the applicability of the technology, for defi ning the best possible architecture using that particular technology, and also for guiding the team in implementing the solution. Generally, the technology architect is expected to know the various vendor tools in the technology area, the latest trends in the market, and various architectural alternatives for implementing the solution.
SummaryI am currently involved in a program for grooming aspiring architects within L&T Infotech into full-fl edged architects. As a result, I have extensively researched the role of an architect and talked to many architects across different industries to understand their role and the competencies that make them successful. This article is an attempt to crystallize the wisdom I’ve gathered from this work.
Figure 1: Architect Roles
EnterpriseArchitects
High
TechnicalArchitects
ProjectScope
OrganizationScope
TechnologyDepth
TechnologyBreadth
Technology Focus
Low
Stra
tegy
Foc
us
High
SolutionArchitects
2
EAMM/EAMMF (Nascio,2003; GAO, 2003)
Based on CMU/SEI CMM (Capability Maturity Model
1. Informal Program
2. Repeatable Program
3. Well-defined Program
4. Managed Program
5. Continuosly Improving Vital Program
What to expect of an org at this level?
Administration?
Planning?
Framework?
Blueprint?
Communication?
Compliance?
Integration?
Involvement?
3
1.Creating EA awareness
2.Building the EA mgmt foundation
3.Developing EA products
4.Completing EA products
5.Leveraging the EA to manage change
EAMMF (Nascio,2003; GAO, 2003)
4
Interoperability:Services to citizens
Interoperability:Offices, compani
es
Interoperability:Other
governments,
ministries
= EA methodology= EA governance
= National EA
= Administrative area EA
= Office EA
5
FEA practice guidance (OMB, 2007)
FEA Practice Guidance – Overview
November 2007 1 - 3
Figure 1-1 illustrates the relationship of segments across multiple agencies. A single agency contains both core mission area segments and business service segments. Enterprise services are those cross-cutting services spanning multiple segments. Segments can be leveraged within an agency, across several agencies, or the entire federal government.
Principles
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. 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.
Agencies are expected to architect first, and then use the architecture to guide and inform information technology (IT) investment planning and implementation (program and project management). This principle recognizes the time required to capture business needs, define higher performance levels and develop architecture sufficient to drive investment decisions. This also recognizes the time required to reconcile how much of the business needs will be met by individual business solutions or enterprise (agency-wide) investments.
For more information on federal architectural principles, refer to the Architectural Principles for the U.S. Government located at www.egov.gov.
Performance Improvement Lifecycle
Results-oriented architecture is developed within the context of the Performance Improvement Lifecycle broken down into three-phases: “Architect”, “Invest” and “Implement” (Figure 1-2). Each lifecycle phase is comprised of tightly integrated processes which combine to transform the agency’s top-down strategic goals and bottom-up system needs into a logical series of work products designed to help the agency achieve strategic results. Through practice area integration, the Performance
Figure 1-1: Segments and Services
Mapping / Geospatial / Elevation / GPS
Security Management
Records Management
Ec
on
om
ic
De
ve
lop
me
nt
Ed
uc
ati
on
Co
mm
un
ity a
nd
So
cia
l S
erv
ice
s
He
alt
h
Hu
ma
n
Re
so
urc
es
Fin
an
cia
l
Ma
na
ge
me
nt
Na
tura
l
Re
so
urc
es
Ho
me
lan
d
Se
cu
rity
HHS
Energy
DHS
Interior
Justice
EPA
SBA
Defense
TreasuryE
nte
rpri
se
Serv
ices
Core Mission Area
Agen
cies
Business Services
Mapping / Geospatial / Elevation / GPS
Security Management
Records Management
Ec
on
om
ic
De
ve
lop
me
nt
Ed
uc
ati
on
Co
mm
un
ity a
nd
So
cia
l S
erv
ice
s
He
alt
h
Hu
ma
n
Re
so
urc
es
Fin
an
cia
l
Ma
na
ge
me
nt
Na
tura
l
Re
so
urc
es
Ho
me
lan
d
Se
cu
rity
HHS
Energy
DHS
Interior
Justice
EPA
SBA
Defense
TreasuryE
nte
rpri
se
Serv
ices
Core Mission Area
Agen
cies
Business Services
Mapping / Geospatial / Elevation / GPS
Security Management
Records Management
Ec
on
om
ic
De
ve
lop
me
nt
Ed
uc
ati
on
Co
mm
un
ity a
nd
So
cia
l S
erv
ice
s
He
alt
h
Hu
ma
n
Re
so
urc
es
Fin
an
cia
l
Ma
na
ge
me
nt
Na
tura
l
Re
so
urc
es
Ho
me
lan
d
Se
cu
rity
HHS
Energy
DHS
Interior
Justice
EPA
SBA
Defense
TreasuryE
nte
rpri
se
Serv
ices
Core Mission Area
Agen
cies
Business Services
6
FEA and its governance
7
Consolidated Reference Model Version 2.3
October 2007 6
2.2 Business Reference Model (BRM)
The BRM provides a framework facilitating a functional (rather than organizational) view of the federal government’s lines of business (LoBs), including its internal operations and its services for citizens, independent of the agencies, bureaus and offices performing them. The BRM describes the federal government around common business areas instead of through a stove-piped, agency-by-agency view. It thus promotes agency collaboration and serves as the underlying foundation for the FEA and E-Gov strategies. While the BRM does provide an improved way of thinking about government operations, its true utility as a model can only be realized when agencies effectively use it. The functional approach promoted by the BRM will do little to help accomplish the E-Gov strategic goals if it is not incorporated into business-focused enterprise architectures and the management processes of federal agencies and OMB. The BRM is structured into a tiered hierarchy representing the business functions of the federal government. Refer to Figure 2 for the BRM tiered hierarchy.
Figure 2: BRM Structure
Business Area
Line of
Business
Sub-function
Business Area
Line of
Business
Sub-function
2.3 Service Component Reference Model (SRM)
The SRM is a business-driven, functional framework classifying Service Components according to how they support business and performance objectives. It serves to identify and classify horizontal and vertical Service Components supporting federal agencies and their IT investments and assets. The model aids in recommending service capabilities to support the reuse of business components and services across the federal government. IT investments can be service providers or consumers. Service providers allow consumers to reuse their business and technical capabilities. The SRM is organized across horizontal service areas, independent of the business functions, providing a leverage-able foundation for reuse of applications, application capabilities, components, and business services. It is structured hierarchically as depicted in Figure 3.
Figure 3: SRM Structure
Service Domain
Service Type
Component
Service Domain
Service Type
Component
Consolidated Reference Model Version 2.3
October 2007 6
2.2 Business Reference Model (BRM)
The BRM provides a framework facilitating a functional (rather than organizational) view of the federal government’s lines of business (LoBs), including its internal operations and its services for citizens, independent of the agencies, bureaus and offices performing them. The BRM describes the federal government around common business areas instead of through a stove-piped, agency-by-agency view. It thus promotes agency collaboration and serves as the underlying foundation for the FEA and E-Gov strategies. While the BRM does provide an improved way of thinking about government operations, its true utility as a model can only be realized when agencies effectively use it. The functional approach promoted by the BRM will do little to help accomplish the E-Gov strategic goals if it is not incorporated into business-focused enterprise architectures and the management processes of federal agencies and OMB. The BRM is structured into a tiered hierarchy representing the business functions of the federal government. Refer to Figure 2 for the BRM tiered hierarchy.
Figure 2: BRM Structure
Business Area
Line of
Business
Sub-function
Business Area
Line of
Business
Sub-function
2.3 Service Component Reference Model (SRM)
The SRM is a business-driven, functional framework classifying Service Components according to how they support business and performance objectives. It serves to identify and classify horizontal and vertical Service Components supporting federal agencies and their IT investments and assets. The model aids in recommending service capabilities to support the reuse of business components and services across the federal government. IT investments can be service providers or consumers. Service providers allow consumers to reuse their business and technical capabilities. The SRM is organized across horizontal service areas, independent of the business functions, providing a leverage-able foundation for reuse of applications, application capabilities, components, and business services. It is structured hierarchically as depicted in Figure 3.
Figure 3: SRM Structure
Service Domain
Service Type
Component
Service Domain
Service Type
Component
Consolidated Reference Model Version 2.3
October 2007 7
2.4 Technical Reference Model (TRM)
The TRM is a component-driven, technical framework categorizing the standards and technologies to support and enable the delivery of Service Components and capabilities. It also unifies existing agency TRMs and E-Gov guidance by providing a foundation to advance the reuse and standardization of technology and Service Components from a government-wide perspective.
Aligning agency capital investments to the TRM leverages a common, standardized vocabulary, allowing interagency discovery, collaboration, and interoperability. Agencies and the federal government will benefit from economies of scale by identifying and reusing the best solutions and technologies to support their business functions, mission, and target architecture. The TRM structure is depicted in Figure 4.
Figure 4: TRM Structure
2.5 Data Reference Model (DRM)
The DRM is a flexible and standards-based framework to enable information sharing and reuse across the federal government via the standard description and discovery of common data and the promotion of uniform data management practices. The DRM provides a standard means by which data may be described, categorized, and shared. These are reflected within each of the DRM’s three standardization areas:
! Data Description: Provides a means to uniformly describe data, thereby supporting its discovery and sharing.
! Data Context: Facilitates discovery of data through an approach to the categorization of data according to taxonomies. Additionally, enables the definition of authoritative data assets within a CommCOI.
! Data Sharing: Supports the access and exchange of data where access consists of ad-hoc requests (such as a query of a data asset), and exchange consists of fixed, re-occurring transactions between parties. Enabled by capabilities provided by both the Data Context and Data Description standardization areas.
Due to the size and scope of the DRM, only an excerpt of the DRM is included in this Consolidated Reference Model document. The current version of the complete DRM (Version 2.0) is located on the www.egov.gov website using the following link: http://whitehouse.gov/omb/egov/documents/DRM_2_0_Final.pdf. The DRM provides a frame of reference to:
! Facilitate COIs (which may be aligned with the LoBs delineated in the FEA Business
Reference Model) in establishing common language.
Service Area
Service
Category
Service
Standard
Service Area
Service
Category
Service
Standard
Consolidated Reference Model Version 2.3
October 2007 8
! Enable needed conversations to reach credible cross-agency agreements around:
governance, data architecture and an information sharing architecture and an
information sharing architecture.
The DRM provides guidance to enterprise architects and data architects for implementing repeatable processes to enable data sharing in accordance with federal government-wide agreements, including agreements encompassing state, local, tribal governments, as well as other public and private non-governmental institutions. The intent is to mature, advance and sustain there data agreements in and iterative manner. The DRM can provide value for agency data architecture initiatives by:
! Providing a means to consistently describe data architectures: The DRM’s approach to Data Description, Data Context, and Data Sharing enables data architecture initiatives to uniformly describe their data artifacts, resulting in increased opportunities for cross-agency and cross-COI interactions.
Figure 5: DRM Structure
! Bridging data architectures: The DRM provides a “Rosetta Stone” to facilitate communications between enterprise and data architects about data and data architecture in their efforts to support the business/mission needs of the COIs that they support.
! Facilitating compliance with requirements for data architectures: The DRM’s standardization areas provide a foundation for agency data architecture initiatives to put forth requirements that can result in increased compatibility between agency data architectures.
As a reference model, the DRM is presented as an abstract framework from which concrete implementations may be derived. The DRM’s abstract nature will enable agencies to use multiple implementation approaches, methodologies and technologies while remaining consistent with the foundational principles of the DRM. For example, the DRM abstract model can be implemented using different combinations of technical standards. As one example, the Exchange Package concept in the Data Sharing
PRM
BRM
SRM
Consolidated Reference Model Version 2.3
October 2007 5
2 Reference Model Overview
The FEA consists of a set of interrelated “reference models” designed to facilitate cross-agency analysis and the identification of duplicative investments, gaps and opportunities for collaboration within and across agencies. Collectively, the reference models comprise a framework for describing important elements of the FEA in a common and consistent way. Through the use of this common framework and vocabulary, IT portfolios can be better managed and leveraged across the federal government. This chapter introduces the purposes and structures of the five FEA reference models:
! Performance Reference Model (PRM)
! Business Reference Model (BRM)
! Service Component Reference Model (SRM)
! Technical Reference Model (TRM)
! Data Reference Model (DRM)
2.1 Performance Reference Model (PRM)
The PRM is a framework for performance measurement providing common output measurements throughout the federal government. It allows agencies to better manage the business of government at a strategic level, by providing a means for using an agency’s EA to measure the success of IT investments and their impact on strategic outcomes. The PRM accomplishes these goals by establishing a common language by which agency EAs can describe the outputs and measures used to achieve program and business objectives. The model articulates the linkage between internal business components and the achievement of business and customer-centric outputs. Most importantly, it facilitates resource-allocation decisions based on comparative determinations of which programs and organizations are more efficient and effective. The PRM focuses on three main objectives:
! Help produce enhanced performance information to improve strategic and daily decision-making
! Improve the alignment and better articulate the contribution of inputs to outputs, thereby creating a clear “line of sight” to desired results
! Identify performance improvement opportunities that span traditional organizational structures and boundaries
The PRM structure is designed to clearly express the cause–and-effect relationship between inputs and outputs. This “line of sight” is articulated through the use of the Measurement Area, Category, Grouping, and Indicator hierarchy. Refer to Figure 1 for the PRM structure.
Figure 1: PRM Structure
Measurement Area
Measurement
Category
Measurement Grouping
Measurement Area
Measurement Category
Measurement Indicator
Measurement Area
Measurement
Category
Measurement Grouping
Measurement Area
Measurement Category
Measurement Indicator
TRM
DRM
FEA CRM (Consolidated reference model, OMB 2007)
8
e.g. PRM (OMB, 2007)
Consolidated Reference Model Version 2.3
October 2007 10
3 Performance Reference Model
The PRM framework (Figure 6) is designed to clearly articulate the cause-and-effect relationship between inputs, outputs, and outcomes. The framework builds from the value chain and program logic models. This “line of sight” is critical for IT project managers, program managers, and key decision-makers to understand how, and to the extent, key inputs are enabling progress toward outputs and outcomes. The PRM captures this “line of sight” to reflect how value is created as inputs (such as Technology) and used to create outputs (through Processes and Activities), which in turn, impact outcomes (such as, Mission, Business and Customer Results). Guiding the entire PRM are “Strategic Outcomes,” representing broad, policy priorities driving the direction of government (such as, to Secure the Homeland).
Figure 6: PRM Framework
Strategic Outcomes
Value
Customer Results
Processes and Activities
TechnologyOther Fixed Assets Human Capital
Mission and Business Results
• Services for Citizens
• Support Delivery of
Services
• Management of
Government Resources
OUTCOMES: Mission and business-critical
results aligned with Levels 1 and 3 of the
BRM. Results measured from a customer
perspective.
OUTPUTS: The direct effects of day-to-
day activities and broader processes
measured as driven by desired
outcomes. Aligned with Level 2 of the
BRM
INPUTS: Key enablers
measured through their
contribution to outputs and, by
their extension, outcomes.
• Customer Benefit
• Service Coverage
• Timeliness and
Responsiveness
• Service Quality
• Service Accessibility
• Financial
• Productivity
• Cycle Time and Timeliness
• Quality
• Security and Privacy
• Management and
Innovation
• Technology Costs
• Quality Assurance
• Efficiency
• Information and Data
• Reliability and Availability
• Effectiveness
Strategic Outcomes
Value
Customer Results
Processes and Activities
TechnologyOther Fixed Assets Human Capital
Mission and Business Results
• Services for Citizens
• Support Delivery of
Services
• Management of
Government Resources
OUTCOMES: Mission and business-critical
results aligned with Levels 1 and 3 of the
BRM. Results measured from a customer
perspective.
OUTPUTS: The direct effects of day-to-
day activities and broader processes
measured as driven by desired
outcomes. Aligned with Level 2 of the
BRM
INPUTS: Key enablers
measured through their
contribution to outputs and, by
their extension, outcomes.
• Customer Benefit
• Service Coverage
• Timeliness and
Responsiveness
• Service Quality
• Service Accessibility
• Financial
• Productivity
• Cycle Time and Timeliness
• Quality
• Security and Privacy
• Management and
Innovation
• Technology Costs
• Quality Assurance
• Efficiency
• Information and Data
• Reliability and Availability
• Effectiveness
The PRM is structured around Measurement Areas, Measurement Categories, Measurement Groupings, and Measurement Indicators.
! Measurement Areas – The high-level organizing framework of the PRM capturing aspects of performance at the output levels. This layer is directly linked to the performance objectives established at the agency and program levels. The PRM includes six measurement areas: Mission and Business Results, Customer Results, Processes and Activities, Human Capital, Technology, and Other Fixed Assets.
! Measurement Categories – Collections within each measurement area describing the attribute or characteristic to be measured. For example, the Mission and Business Results Measurement Area include three Measurement Categories: Services for Citizens, Support Delivery of Services, and Management of Government Resources, corresponding to the Lines of Business in the BRM.
9
e.g. PRM hierarchy
(OMB, 2007)
Mission and Business Results Measurement Area
Customer Results Measurement Area
Customer Benefit
Service Coverage
425: New customers and market penetration
426: Frequency and depth
KPIs
KPIs
Consolidated Reference Model Version 2.3
October 2007 5
2 Reference Model Overview
The FEA consists of a set of interrelated “reference models” designed to facilitate cross-agency analysis and the identification of duplicative investments, gaps and opportunities for collaboration within and across agencies. Collectively, the reference models comprise a framework for describing important elements of the FEA in a common and consistent way. Through the use of this common framework and vocabulary, IT portfolios can be better managed and leveraged across the federal government. This chapter introduces the purposes and structures of the five FEA reference models:
! Performance Reference Model (PRM)
! Business Reference Model (BRM)
! Service Component Reference Model (SRM)
! Technical Reference Model (TRM)
! Data Reference Model (DRM)
2.1 Performance Reference Model (PRM)
The PRM is a framework for performance measurement providing common output measurements throughout the federal government. It allows agencies to better manage the business of government at a strategic level, by providing a means for using an agency’s EA to measure the success of IT investments and their impact on strategic outcomes. The PRM accomplishes these goals by establishing a common language by which agency EAs can describe the outputs and measures used to achieve program and business objectives. The model articulates the linkage between internal business components and the achievement of business and customer-centric outputs. Most importantly, it facilitates resource-allocation decisions based on comparative determinations of which programs and organizations are more efficient and effective. The PRM focuses on three main objectives:
! Help produce enhanced performance information to improve strategic and daily decision-making
! Improve the alignment and better articulate the contribution of inputs to outputs, thereby creating a clear “line of sight” to desired results
! Identify performance improvement opportunities that span traditional organizational structures and boundaries
The PRM structure is designed to clearly express the cause–and-effect relationship between inputs and outputs. This “line of sight” is articulated through the use of the Measurement Area, Category, Grouping, and Indicator hierarchy. Refer to Figure 1 for the PRM structure.
Figure 1: PRM Structure
Measurement Area
Measurement
Category
Measurement Grouping
Measurement Area
Measurement Category
Measurement Indicator
Measurement Area
Measurement
Category
Measurement Grouping
Measurement Area
Measurement Category
Measurement Indicator
10
BRM (OMB, 2007)
Consolidated Reference Model Version 2.3
October 2007 26
4 Business Reference Model
The Business Reference Model provides a framework facilitating a functional (as opposed to organizational) view of the federal government’s LoBs, including its internal operations and its services for the citizens, independent of the agencies, bureaus and offices performing them. By describing the federal government around common business areas instead of by a stove-piped, agency-by-agency view, the BRM promotes agency collaboration and serves as the underlying foundation for the FEA and E-Gov strategies. While the BRM does provide an improved way of thinking about government operations, it is only a model; its true utility can only be realized when it is effectively used. The functional approach promoted by the BRM will do little to help accomplish the goals of E-Government if it is not incorporated into EA business architectures and the management processes of all Federal agencies and OMB. The BRM is structured into a tiered hierarchy representing the business functions of the federal government. Business Areas are at the highest level followed by LoBs, then the corresponding business Sub-functions related to each LoB. The Business Areas separate government operations into high-level categories relating to the purpose of government (Services for Citizens), the mechanisms the government uses to achieve its purpose (Mode of Delivery), the support functions necessary to conduct government operations (Support Delivery of Services), and the resource management functions that support all areas of the government’s business (Management of Government Resources). The Business Areas of the BRM break down further into LoBs, and each LoB is comprised of a collection of Sub-functions representing the lowest level of granularity in the BRM. Figure 10 provides an overview of the BRM.
Figure 10: BRM Overview
Mode ofDelivery
of Services
Management of Government Resources
G o v e rn m e nt Se rv i c e D e liv e ryD ir e c t Se rv i c e s f or C itiz e nsKn o w l e d g e C r e a tio n a n d M g mtPu b li c G o o ds C r e a tio n a n d M g mtRe g u l a tory C o m p li a n c e a n d En for c e m e nt
Fin a n c i a l V e h i c l e sF e d e r a l Fin a n c i a l Assist a n c e
C r e d it a n d Insur a n c e
Lo c a l
Fin a n c i a l M a n a g e m e nt
Hu m a n Re so ur c e M a n a g e m e nt
Su p p ly C h a in M a n a g e m e nt A d m in istr a tiv e M a n a g e m e nt
Inf orm a tio n a n d Te c hn o lo g y M a n a g e m e nt
Ed u c a tio nEn e rgy
Services for C itizens
Support Delivery of Services
Management of Government Resources
Le g isl a tiv e Re l a tio nsPu b li c Aff a irsRe g u l a tory D e v e lo p m e ntPl a nn in g a n d Bu d g e tin g
D ir e c t Se rv i c e s f or C itiz e nsKn o w l e d g e C r e a tio n a n d M g mtPu b li c G o o ds C r e a tio n a n d M g mtRe g u l a tory C o m p li a n c e a n d En for c e m e nt
F e d e r a l Fin a n c i a l Assist a n c eC r e d it a n d Insur a n c e
Tr a nsf e rs to St a t e s a n d Lo c a l G o v e rn m e nts Lo c a l
Fin a n c i a l M a n a g e m e ntHu m a n Re so ur c e M a n a g e m e ntSu p p ly C h a in M a n a g e m e nt A d m in istr a tiv e M a n a g e m e nt
Inf orm a tio n a n d Te c hn o lo g y M a n a g e m e nt
Int e rn a tio n a l Aff a irs a n d C o m m e r c e
D e f e nse a n d N a tio n a l Se c urityHo m e l a n d Se c urityInt e llig e n c e O p e r a tio nsL a w En f or c e m e nt
Liti g a tio n a n d Ju d i c i a l A c tiviti e sC orr e c tio n a l A c tiv iti e s
Ed u c a tio nEn e rg yH e a lth
Tr a nsp ort a tio nIn c o m e Se c urity
C o ntro ls a n d O v e rsi g htRe v e nu e C o ll e c tio n
Int e rn a l Risk M g mt a n d M iti g a tionG e n e r a l G o v e rn m e nt
The Business Reference Model (BRM)
Pur p ose o f G o v e rn m e nt
M e c h a n isms Use d to
A c h i e v e Purp ose
G o v e rn m e nt O p e r a tio ns
Su p p ort Fun c tions
N a tur a l Re so ur c e s
C o m m un ity a n d So c i a l Se rv i c e s Ec o n o m i c D e v e lo p m e ntWorkf or c e M a n a g e m e nt
G e n e r a l Sc i e n c e a n d Inn o v a tion
Env iro n m e nt a l M a n a g e m e nt
D is a st e r M a n a g e m e nt
Re so ur c e M a n a g e m e nt
Fun c tions
Mode ofDelivery Mode ofDelivery
of Services
Management of Government Resources
G o v e rn m e nt Se rv i c e D e liv e ryD ir e c t Se rv i c e s f or C itiz e nsKn o w l e d g e C r e a tio n a n d M g mtPu b li c G o o ds C r e a tio n a n d M g mtRe g u l a tory C o m p li a n c e a n d En for c e m e nt
Fin a n c i a l V e h i c l e sF e d e r a l Fin a n c i a l Assist a n c e
C r e d it a n d Insur a n c e
Lo c a l
Fin a n c i a l M a n a g e m e nt
Hu m a n Re so ur c e M a n a g e m e nt
Su p p ly C h a in M a n a g e m e nt A d m in istr a tiv e M a n a g e m e nt
Inf orm a tio n a n d Te c hn o lo g y M a n a g e m e nt
Ed u c a tio nEn e rgy
Services for C itizens
Services for C itizens
Support Delivery of Services
Support Delivery of Services
Management of Government Resources
Management of Government Resources
Le g isl a tiv e Re l a tio nsPu b li c Aff a irsRe g u l a tory D e v e lo p m e ntPl a nn in g a n d Bu d g e tin g
Le g isl a tiv e Re l a tio nsPu b li c Aff a irsRe g u l a tory D e v e lo p m e ntPl a nn in g a n d Bu d g e tin g
D ir e c t Se rv i c e s f or C itiz e nsKn o w l e d g e C r e a tio n a n d M g mtPu b li c G o o ds C r e a tio n a n d M g mtRe g u l a tory C o m p li a n c e a n d En for c e m e nt
F e d e r a l Fin a n c i a l Assist a n c eC r e d it a n d Insur a n c e
Tr a nsf e rs to St a t e s a n d Lo c a l G o v e rn m e nts
F e d e r a l Fin a n c i a l Assist a n c eC r e d it a n d Insur a n c e
Tr a nsf e rs to St a t e s a n d Lo c a l G o v e rn m e nts Lo c a l
Fin a n c i a l M a n a g e m e ntHu m a n Re so ur c e M a n a g e m e ntSu p p ly C h a in M a n a g e m e nt A d m in istr a tiv e M a n a g e m e nt
Inf orm a tio n a n d Te c hn o lo g y M a n a g e m e nt
Int e rn a tio n a l Aff a irs a n d C o m m e r c e
D e f e nse a n d N a tio n a l Se c urityHo m e l a n d Se c urityInt e llig e n c e O p e r a tio nsL a w En f or c e m e nt
Liti g a tio n a n d Ju d i c i a l A c tiviti e sC orr e c tio n a l A c tiv iti e s
Int e rn a tio n a l Aff a irs a n d C o m m e r c e
D e f e nse a n d N a tio n a l Se c urityHo m e l a n d Se c urityInt e llig e n c e O p e r a tio nsL a w En f or c e m e nt
Liti g a tio n a n d Ju d i c i a l A c tiviti e sC orr e c tio n a l A c tiv iti e s
Ed u c a tio nEn e rg yH e a lth
Tr a nsp ort a tio nIn c o m e Se c urity
Ed u c a tio nEn e rg yH e a lth
Tr a nsp ort a tio nIn c o m e Se c urity
C o ntro ls a n d O v e rsi g htRe v e nu e C o ll e c tio n
Int e rn a l Risk M g mt a n d M iti g a tionG e n e r a l G o v e rn m e nt
C o ntro ls a n d O v e rsi g htRe v e nu e C o ll e c tio n
Int e rn a l Risk M g mt a n d M iti g a tionG e n e r a l G o v e rn m e nt
The Business Reference Model (BRM)
Pur p ose o f G o v e rn m e nt
M e c h a n isms Use d to
A c h i e v e Purp ose
G o v e rn m e nt O p e r a tio ns
Su p p ort Fun c tions
N a tur a l Re so ur c e s
C o m m un ity a n d So c i a l Se rv i c e s Ec o n o m i c D e v e lo p m e ntWorkf or c e M a n a g e m e nt
G e n e r a l Sc i e n c e a n d Inn o v a tion
Env iro n m e nt a l M a n a g e m e nt
D is a st e r M a n a g e m e ntN a tur a l Re so ur c e s
C o m m un ity a n d So c i a l Se rv i c e s Ec o n o m i c D e v e lo p m e ntWorkf or c e M a n a g e m e nt
G e n e r a l Sc i e n c e a n d Inn o v a tion
Env iro n m e nt a l M a n a g e m e nt
D is a st e r M a n a g e m e nt
Re so ur c e M a n a g e m e nt
Fun c tions
11
SRM (OMB, 2007)
Consolidated Reference Model Version 2.3
October 2007 48
Figure 15: SRM Overview
Service Domains Service Types
Customer Services
Process Automation Services
Business Management Services
Digital Asset Services
Business Analytical Services
Back Office Services
Support Services
• Customer Relationship Management
• Customer Preferences
• Customer Initiated Assistance
• Tracking and Workflow
• Routing and Scheduling
• Management of Process
• Organizational Management
• Investment Management
• Supply Chain Management
• Content Management
• Document Management
• Knowledge Management
• Records Management
• Analysis and Statistics
• Visualization
• Knowledge Discovery
• Business Intelligence
• Data Management
• Human Resources
• Financial Management
• Asset / Materials Management
• Security Management
• Collaboration
• Search
• Communication
• Reporting
• Development and Integration
• Human Capital / Workforce
Management
• Systems Management
• Forms Management
Service Domains Service Types
Customer Services
Process Automation Services
Business Management Services
Digital Asset Services
Business Analytical Services
Back Office Services
Support Services
• Customer Relationship Management
• Customer Preferences
• Customer Initiated Assistance
• Tracking and Workflow
• Routing and Scheduling
• Management of Process
• Organizational Management
• Investment Management
• Supply Chain Management
• Content Management
• Document Management
• Knowledge Management
• Records Management
• Analysis and Statistics
• Visualization
• Knowledge Discovery
• Business Intelligence
• Data Management
• Human Resources
• Financial Management
• Asset / Materials Management
• Security Management
• Collaboration
• Search
• Communication
• Reporting
• Development and Integration
• Human Capital / Workforce
Management
• Systems Management
• Forms Management
5.1 Customer Services Domain
The Customer Services Domain defines the set of capabilities directly related to an internal or external customer, the business’s interaction with the customer, and the customer-driven activities or functions. The Customer Services Domain represents those capabilities and services at the front end of a business and interface at varying levels with the customer.
Figure 16: Customer Services Domain
Customer Services
(701) Customer
Relationship Management
510: Call Center Management
511: Customer Analytics
512: Sales and Marketing
513: Product Management
514: Brand Management
515: Customer / Account
516: Contact and Profile
518: Customer Feedback
519: Surveys
517: Partner Relationship
(702) Customer
Preferences
520: Personalization
521: Subscriptions
522: Alerts and Notifications
(703) Customer Initiated
Assistance
523: Online Help
524: Online Tutorials
525: Self-Service
526: Reservations / Registration
527: Multi-Lingual Support
528: Assistance Request
529: Scheduling
Management
Management
Management
Customer Services
(701) Customer
Relationship Management
510: Call Center Management
511: Customer Analytics
512: Sales and Marketing
513: Product Management
514: Brand Management
515: Customer / Account
516: Contact and Profile
518: Customer Feedback
519: Surveys
517: Partner Relationship
(702) Customer
Preferences
520: Personalization
521: Subscriptions
522: Alerts and Notifications
(703) Customer Initiated
Assistance
523: Online Help
524: Online Tutorials
525: Self-Service
526: Reservations / Registration
527: Multi-Lingual Support
528: Assistance Request
529: Scheduling
Management
Management
Management
12
SSC Shared Service Center
(‘components’) (OMB, 2009)
IBM has been approved to offer Federal agencies Personnel Action Processing, Benefits Management, and all non-core HR functions. IBM offers Oracle/PeopleSoft Human Resource Management System (HRMS) to support the mandatory core SSC services. IBM offers self-service Benefits Management capabilities through the HRMS Portal and access to OPM's Employee Express with a bi-directional interface. At this time, IBM does not offer core Compensation Management services. IBM, together with its partners A+ Government Solutions, Cognos, Dougherty & Associates, Taleo, Watson Wyatt, and YRCI, provides the non-core HR services of the HR LOB SSC. IBM's SSC service offering for the HR LOB functions is summarized below:
13
...cntnd (OMB, 2009)
14
TRM (OMB, 2007)
Consolidated Reference Model Version 2.3
October 2007 65
6 Technical Reference Model
The TRM is a component-driven, technical framework categorizing the standards and technologies to support and enable the delivery of Service Components and capabilities. It also unifies existing agency TRMs and E-Gov guidance by providing a foundation to advance the reuse and standardization of technology and Service Components from a government-wide perspective. Aligning agency capital investments to the TRM leverages a common, standardized vocabulary, allowing interagency discovery, collaboration, and interoperability. Agencies and the federal government will benefit from economies of scale by identifying and reusing the best solutions and technologies to support their business functions, mission, and target architecture. Organized in a hierarchy, the TRM categorizes the standards and technologies that collectively support the secure delivery, exchange, and construction of business and application Service Components that may be used and leveraged in a component-based or service-oriented architecture (CBA or SOA, used synonymously from here forward). The TRM consists of:
! Service Areas represent a technical tier supporting the secure construction, exchange, and delivery of Service Components. Each Service Area aggregates the standards and technologies into lower-level functional areas. Each Service Area consists of multiple Service Categories and Service Standards. This hierarchy provides the framework to group standards and technologies that directly support the Service Area.
! Service Categories classify lower levels of technologies and standards with respect to the business or technology function they serve. In turn, each Service Category is comprised of one or more Service Standards.
! Service Standards define the standards and technologies that support a Service Category. To support agency mapping into the TRM, many of the Service Standards provide illustrative specifications or technologies as examples.
Figure 23 provides a high-level depiction of the TRM.
Figure 23: TRM Overview
Service Access and Delivery
Access Channels Delivery Channels Service Requirements Service Transport
Web Browser Internet Legislative / Compliance Supporting Network Services
Wireless / PDA Intranet Authentication / Single Sign-on Service Transport
Collaboration / Communications Extranet Hosting
Other Electronic Channels Peer to Peer (P2P)
Virtual Private Network (VPN)
Service Platform and Infrastructure
Support Platforms Delivery Servers Hardware / Infrastructure
Wireless / Mobile Web Servers Servers / Computers
Platform Independent Media Servers Embedded Technology Devices
Platform Dependent Application Servers Peripherals
Software Engineering Portal Servers Wide Area Network (WAN)
Integrated Dev.Environment Database / Storage Local Area Network (LAN)
Software Configuration Mgmt Database Network Devices / Standards
Test Management Storage Video Conferencing
Consolidated Reference Model Version 2.3
October 2007 66
Modeling
Component Framework
Security Presentation / Interface Business Logic Data Management
Certificates / Digital Signature Static Display Platform Independent Database Connectivity
Supporting Security Services Dynamic Server-Side Display Platform Dependent Reporting and Analysis
Content Rendering Data Interchange
Wireless / Mobile / Voice Data Exchange
Service Interface and Integration
Integration Interoperability Interface
Middleware Data Format / Classification Service Discovery
Enterprise Application Integration Data Types / Validation Service Description / Interface
Data Transformation
6.1 Service Access and Delivery Service Area
The Service Access and Delivery Service Area, illustrated in Figure 24, defines the collection of Access and Delivery Channels used to leverage the Service Component, and the legislative requirements governing its use and interaction.
Figure 24: Service Access and Delivery Service Area
Service Accessand Delivery
Access Channels
850: Web Browser
851: Wireless / PDA
852: Collaboration /
Delivery Channels
854: Internet
856: Extranet
857: Peer to Peer (P2P)
858: Virtual Private
Hardware /
Infrastructure
862: Supporting Network
863: Service Transport
Service Requirements
859: Legislative /
861: Hosting
Network (VPN)
Services
Communications
853: Other Electronic
Channels
855: Intranet Compliance
860: Authentication / Single Sign-on
Service Accessand Delivery
Access Channels
850: Web Browser
851: Wireless / PDA
852: Collaboration /
Delivery Channels
854: Internet
856: Extranet
857: Peer to Peer (P2P)
858: Virtual Private
Hardware /
Infrastructure
862: Supporting Network
863: Service Transport
Service Requirements
859: Legislative /
861: Hosting
Network (VPN)
Services
Communications
853: Other Electronic
Channels
855: Intranet Compliance
860: Authentication / Single Sign-on
The Service Access and Delivery Service Categories and Standards are defined below:
Access Channels
Access Channels define the interface between an application and its users, whether it is a browser, personal digital assistant or other medium.
Web Browser – Defines the program serving as the front end to the World Wide Web on the Internet. In order to view a site, you type its address (URL) into the browser's location field.
Examples of Web Browsers include:
! Internet Explorer – Microsoft Internet Explorer (MSIE) is the most widely used World Wide Web browser.
! Netscape Communicator – Netscape is the second most widely used World Wide Web browser.
15
DRM (OMB, 2007)
Separate set of hundreds of pages...
Data Description: Provides a means to uniformly describe data, thereby supporting its discovery and sharing.
Data Context: Facilitates discovery of data through an approach to the categorization of data according to taxonomies. Additionally, enables the definition of authoritative data assets within a CommCOI.
Data Sharing: Supports the access and exchange of data where access consists of ad- hoc requests (such as a query of a data asset), and exchange consists of fixed, re- occurring transactions between parties. Enabled by capabilities provided by both the Data Context and Data Description standardization areas.
16
So, what is this about?
17
FEA Segment identification (OMB, 2007)
FEA Practice Guidance – Introducing Segment Architecture
November 2007 2 - 11
content of the EA transition strategy and the relationship between segment architecture and the EA transition strategy. The Chief Architect and agency EA program staff, in close collaboration with internal stakeholders, facilitate all activities to develop agency-level EA and the EA transition strategy, including the identification and prioritization of enterprise segments.
Segment identification is a continuous, iterative process. Enterprise assets including systems and IT investments are mapped to the agency-level reference models to create a segment-oriented view of the enterprise (see Figure 2-2).
Enterprise Assets
• Programs
• Processes
• Information
• Applications
• Technology
• Investments
• Personnel
• Organizations
• Facilities
Performance
Business
Data
Services
Technology
Reference Models
• Core Mission Areas
• Common Business
Services
• Common Enterprise
Services
Segments
Enterprise Assets
• Programs
• Processes
• Information
• Applications
• Technology
• Investments
• Personnel
• Organizations
• Facilities
Performance
Business
Data
Services
Technology
Reference Models
• Core Mission Areas
• Common Business
Services
• Common Enterprise
Services
Segments
Segment identification applies a variety of internal and external inputs such as the agency mission statement, agency strategic goals and objectives, legislative mandates, common or shared business and information requirements, and cross-agency initiatives described in the � � � � � � � � � � � � � � � � � � � � � � � � � � � � � . This process organizes and consolidates enterprise assets into logical groups aligned with a common purpose (mission area) or common service, and identifies segments in three categories: core mission areas, business services and enterprise services.
Table 2-5 provides a summary description of each segment type including the related architectural reference model and segment owner.
Segment Type Description FEA Reference
Model Segment
Owner
Core Mission Area Unique service areas 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).
Business Reference
Model: Services for
Citizens
Business Area
Figure 2-2: Segment Identification
18
FEA architectural levels & attributes
(OMB, 2007) FEA Practice Guidance – Overview
November 2007 1 - 5
By definition, EA is fundamentally concerned with identifying common or shared assets – whether they are strategies, business processes, investments, data, systems or technologies. EA is driven by strategy, it helps an agency identify whether its resources are properly aligned to the agency mission and strategic goals and objectives. From an investment perspective, EA is used to drive decisions about the IT investment portfolio as a whole. Consequently, the primary stakeholders of the EA are the senior managers and executives tasked with ensuring the agency fulfills its mission as effectively and efficiently as possible.
By contrast, segment architecture defines a simple roadmap for a core mission area, business service or enterprise service. Segment architecture is driven by business management and delivers products that improve the delivery of services to citizens and agency staff. From an investment perspective, segment architecture drives decisions for a business case or group of business cases supporting a core mission area or common or shared service. The primary stakeholders for segment architecture are business owners and managers.
Segment architecture is related to EA through three principles: structure, reuse and alignment. First, segment architecture inherits the framework used by the EA, although it may be extended and specialized to meet the specific needs of a core mission area or common or shared service. Second, segment architecture reuses important assets defined at the enterprise level including: data; common business processes and investments; and applications and technologies. Third, segment architecture aligns with elements defined at the enterprise level, such as business strategies, mandates, standards and performance goals.
Solution architecture defines agency IT assets such as applications or components used to automate and improve individual agency business functions. The scope of a solution architecture is typically limited to a single project and is used to implement all or part of a system or business solution. The primary stakeholders for solution architecture are system users and developers.
Figure 1-3: Architectural Levels and Attributes
19
FEA practice guidance (OMB, 2007)
FEA Practice Guidance – Overview
November 2007 1 - 3
Figure 1-1 illustrates the relationship of segments across multiple agencies. A single agency contains both core mission area segments and business service segments. Enterprise services are those cross-cutting services spanning multiple segments. Segments can be leveraged within an agency, across several agencies, or the entire federal government.
Principles
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. 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.
Agencies are expected to architect first, and then use the architecture to guide and inform information technology (IT) investment planning and implementation (program and project management). This principle recognizes the time required to capture business needs, define higher performance levels and develop architecture sufficient to drive investment decisions. This also recognizes the time required to reconcile how much of the business needs will be met by individual business solutions or enterprise (agency-wide) investments.
For more information on federal architectural principles, refer to the Architectural Principles for the U.S. Government located at www.egov.gov.
Performance Improvement Lifecycle
Results-oriented architecture is developed within the context of the Performance Improvement Lifecycle broken down into three-phases: “Architect”, “Invest” and “Implement” (Figure 1-2). Each lifecycle phase is comprised of tightly integrated processes which combine to transform the agency’s top-down strategic goals and bottom-up system needs into a logical series of work products designed to help the agency achieve strategic results. Through practice area integration, the Performance
Figure 1-1: Segments and Services
Mapping / Geospatial / Elevation / GPS
Security Management
Records Management
Ec
on
om
ic
De
ve
lop
me
nt
Ed
uc
ati
on
Co
mm
un
ity a
nd
So
cia
l S
erv
ice
s
He
alt
h
Hu
ma
n
Re
so
urc
es
Fin
an
cia
l
Ma
na
ge
me
nt
Na
tura
l
Re
so
urc
es
Ho
me
lan
d
Se
cu
rity
HHS
Energy
DHS
Interior
Justice
EPA
SBA
Defense
TreasuryE
nte
rpri
se
Serv
ices
Core Mission Area
Agen
cies
Business Services
Mapping / Geospatial / Elevation / GPS
Security Management
Records Management
Ec
on
om
ic
De
ve
lop
me
nt
Ed
uc
ati
on
Co
mm
un
ity a
nd
So
cia
l S
erv
ice
s
He
alt
h
Hu
ma
n
Re
so
urc
es
Fin
an
cia
l
Ma
na
ge
me
nt
Na
tura
l
Re
so
urc
es
Ho
me
lan
d
Se
cu
rity
HHS
Energy
DHS
Interior
Justice
EPA
SBA
Defense
TreasuryE
nte
rpri
se
Serv
ices
Core Mission Area
Agen
cies
Business Services
Mapping / Geospatial / Elevation / GPS
Security Management
Records Management
Ec
on
om
ic
De
ve
lop
me
nt
Ed
uc
ati
on
Co
mm
un
ity a
nd
So
cia
l S
erv
ice
s
He
alt
h
Hu
ma
n
Re
so
urc
es
Fin
an
cia
l
Ma
na
ge
me
nt
Na
tura
l
Re
so
urc
es
Ho
me
lan
d
Se
cu
rity
HHS
Energy
DHS
Interior
Justice
EPA
SBA
Defense
TreasuryE
nte
rpri
se
Serv
ices
Core Mission Area
Agen
cies
Business Services
20
Technology
Service Component
Data
Business
Initiative Layer
Performance & Strategy
TRM
SRM
DRM
BRM
PRM
FEA ReferenceModels
Catalog Section
FTF Catalog
Cross-agencyInitiative
Section 1
2
3
.. Initiative
Performance & Strategy
Business
Data
Service
Technology
Section
Laye
rs
21
22
Using the FTF (OMB, 2007)
EA AssessmentFramework
+
Agency EA Self-Assessment
+
Step 1 Step 2 Step 3
Publish Assess
FTF CatalogAgency
EA TransitionPlan
AgencyBudget
Verify
Agency BudgetEvaluation
+
22
EA Transition (OMB, 2007)
FEA Practice Guidance – EA Transition Strategy
November 2007 4 - 3
Step 0: Establish Baseline and Target Architectures
Baseline and target architectures for the agency should be developed before the EA transition strategy, which is why this is enumerated as “Step 0”. When developing the agency baseline and target architectures, architects need to work closely with the business owners to ensure the future state architecture meets the needs of the business and is focusing on priorities that will help the agency perform its mission more effectively. It is understood the agency target architecture will change over time as business needs and priorities change. As future plans are accomplished, the baseline should also be updated as necessary.
Establishing the baseline architecture is very much a data gathering exercise, while designing the target requires more analysis. In general, the baseline architecture should be modeled at a high level across the enterprise, but provide more detail for areas of priority concern to the mission of the agency. The level of detail to which the baseline architecture needs to be completed should be limited to the information needed to identify areas for improvement, and for the baseline to serve as the starting point for the transition strategy. It is likely some analysis of the baseline has already been done to identify areas for improvement, such as, consolidation opportunities or organizational inefficiencies.
When developing the target architecture, the architects need to work closely with the business owners to ensure the target meets the future needs of the business and focuses on priorities to help the agency perform its mission more effectively. The target architecture should resolve deficiencies identified by business owners and identify new approaches, such as best practices from outside the organization to address the
Figure 4-3: Developing the EA Transition Strategy
BaselineArchitecture
TargetArchitecture
5. DefinePrograms& Projects
3. EnterpriseSequencing
Plan
To AgencyCPIC & Budget Process
Transition Strategy
2. Refine & PrioritizeSegments
1. Redundancy& Gap Analysis0.
4. DevelopSegment
Architectures
Adjustment
FEA Practice Guidance – EA Transition Strategy
November 2007 4 - 2
“Architect” phase leading to a proposed investment portfolio in the “Invest” phase. Because the IT investment portfolio is generated from the architecture, the agency should be able to show progress toward achieving mission objectives and business results by implementing the investments in the portfolio.
Developing the Transition Strategy
The transition strategy is developed through a number of major steps. The details of how these steps are performed can vary from agency to agency based on a variety of factors, such as the organizational complexity of the agency, the scope of the agency’s mission, and agency governance processes. The major steps to develop the transition strategy are:
Step 0: Establish baseline and target architectures (and identify segments);
Step 1: Perform redundancy and gap analyses;
Step 2: Refine and prioritize architecture segments;
Step 3: Lay out the enterprise sequencing plan;
Step 4: Develop segment architectures; and
Step 5: Define programs and projects.
Figure 4-2: EA Transition Strategy in the Performance Improvement Lifecycle
EA Transition Strategy
23
From architecting to implementation (OMB, 2007)
FEA Practice Guidance – Overview
November 2007 1 - 4
Improvement Lifecycle provides the foundation for sound IT management practices, end-to-end governance of IT investments, and the alignment of IT investments with an agency’s strategic goals so an agency can achieve its desired mission outcomes and business results.
Table 1-1 summarizes the processes included in each phase of the Performance Improvement Lifecycle, as well as the processes used to transition from one phase of the lifecycle to the next.
Phase Processes
Architect
! Develop and maintain EA as the shared view of the current and future state of
the agency.
! Define and prioritize segments as part of the EA transition strategy that
defines the sequencing of individual segments.
! Develop segment architecture to provide a bridge between the enterprise
vision (EA and EA transition strategy) and the investment in and
implementation of individual business and information management solutions.
Invest ! Define the implementation and funding strategy for individual solutions
identified in the EA transition strategy and described in the segment
architecture.
! Create the program management plan to implement the individual solutions
identified in the implementation and funding strategy.
Implement
! Execute projects according to the program management plans.
! Measure performance to determine how well the implemented solutions
achieve the desired results and mission outcomes and provide feedback into
the enterprise and segment architecture development processes.
Table 1-1: Performance Improvement Lifecycle Processes
Agency Chief Architects, and the EA practice as a whole, must provide valuable, results-driven information at varying levels of detail to support each link in the Performance Improvement Lifecycle.
Architecture Levels
Enterprise, segment, and solution architecture provide different business perspectives by varying the level of detail and addressing related but distinct concerns. Just as enterprises are themselves hierarchically organized, so are the different views provided by each type of architecture. Figure 1-3 illustrates the relationships between enterprise architecture, segment architecture and solution architecture.
Figure 1-2: Performance Improvement Lifecycle
24
EA in big pict
REPORT TO CONGRESS
ON THE BENEFITS
OF THE PRESIDENT’S
E-GOVERNMENT INITIATIVES
FISCAL YEAR 2009
25
Intra and inter (OMB, 2009)
The Department of Transportation (DoT) is providing funding in FY 2009 to the following E-Government Initiatives:
Government to Citizen Portfolio
! !"#$#%&'()##"#%$*+&(,-.'/0&-&*%(12$*(
(
Government to Business Portfolio
! 34#"*&##(5$%&6$7(((
Government to Government Portfolio
! 5'$*%#89/0((
Internal Efficiency and Effectiveness Portfolio
! ,*%&9'$%&:()+;4"#"%"/*(<*0"'/*-&*%(=(>/$*#($*:(5'$*%#
Lines of Business (LoB)
! 34:9&%(?/'-42$%"/*($*:(<@&+4%"/*(>/3(! ?"*$*+"$2(A$*$9&-&*%(>/3((! 5&/#.$%"$2(>/3(! 5'$*%#(A$*$9&-&*%(>/3(! B4-$*(C&#/4'+&#(A$*$9&-&*%(>/3((
26
Intra and inter (OMB, 2009, pp. 115-116)
”Grants.gov (Managing Partner HHS [Human and Health Services (Jups)])
The Grants.gov initiative benefits DoT and its component organizations, including the Federal Aviation Administration, Federal Highway Administration, Federal Motor Carrier Safety Administration, Federal Railroad Administration, Federal Transit Administration, Maritime Administration, National Highway Traffic Safety Administration, Office of the Secretary, Pipeline and Hazardous Material Safety Administration, Research and Innovative Technology Administration, Saint Lawrence Seaway Development Corporation, Office of Inspector General, and the Surface Transportation Board, by providing a single location to publish grant (funding) opportunities and application packages. Additionally, it provides a single site for the grants community to apply for grants using common forms, processes and systems. DoT derives its largest source of benefits from Grants.gov by not having to develop its own system for collecting electronic grant applications for paper-based discretionary grant programs.
In FY 2008, DoT received 2,040 electronic applications from the grants community via Grants.gov, with 57 total application packages posted. New discretionary grant programs in FY 2008 were able to use Grants.gov rather than having to modify DoT software systems to accept pre-award data collection.
Across DoT, Grants.gov has helped the Department standardize grant data items and procedures. Grants.gov has helped to improve accountability, reporting and to prepare for future GM LoB planning.”
27
Complicated, uh?
Let us re-abstract!
28