Enterprise Architecture TJTSE25 2009 Yrityksen kokonaisarkkitehtuuri · Consolidated Reference Model Version 2.3 October 2007 6 2.2 Business Reference Model (BRM) The BRM provides

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


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


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


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


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


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


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 Area



TRM

DRM

FEA CRM (Consolidated reference model, OMB 2007)

8

e.g. PRM (OMB, 2007)


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


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 Area



Measurement Area

Measurement

Category


Measurement Area



10

BRM (OMB, 2007)


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


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


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


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


Ed u c a tio nEn e rgy









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


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


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
















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




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




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)


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)


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


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)


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


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


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


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)


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

Documents

Enterprise Architecture TJTSE25 2009 Yrityksen kokonaisarkkitehtuuri · Consolidated Reference Model Version 2.3 October 2007 6 2.2 Business Reference Model (BRM) The BRM provides