IEA TEAMs Structure and Governance

1
IEA TEAMs Structure and Governance

• Presented by Colleen Coggins
• Interior Enterprise
  Architect

2
IAWG AGENDA

• DEAR DEPLOYMENT
• Phased Roll Out - Expectations Colleen
• DEAR Wizard Fred
• User Accounts Richard Sullivan
• Licensing Colleen
• DOI Modernization Blueprint Methodology- Colleen
• IEA Governance Colleen
• Bureau level EA Programs Colleen/ALL
• IEA Performance Measures

3
Scope of Teams

• There are Three Phases to Architecture
  Development
• Document the As-Is Environment
• Define the Target Architecture
• Develop transition plans from As-Is to target.
• Each IEA team, under defined roles and
  responsibilities, should operate in all three
  phases.
• Architecture Governance is Required for All
  Architecture Layers (i.e., business, data,
  applications and technology). For example
• Business Ensure new system starts conform to
  re-engineered processes
• Data Ensure new system starts conform to
  Interior data standards
• Applications Ensure new system starts conform
  to conceptual target applications architecture
• Technology Ensure new system starts/upgrades
  conform to TRM.

4
Issues to Consider

• Architecture is a broad program that incorporates
  input from the highest levels of Interior (e.g.,
  business goals and objectives) to specific
  technical standards (e.g., messaging and
  relational database mgmt. systems)
• IEA Teams structure should ensure business
  requirements drive IT decisions not vice versa.
• IEA Teams structure should maximize team members
  time and input while eliminating redundant
  analyses
• Business Representatives should define/validate
  business requirements, supporting functions,
  processes, etc.
• Technology Reps. Should leverage defined business
  reqmts. recommend suitable technology
  solutions.
• Multiple teams are required to ensure breadth of
  architecture is addressed consistent with OMB
  Federal Enterprise Architecture Model.
• One team, IAWG, is required to ensure accurate
  alignment with all FEA models.

5
Business Architecture

• As-Is
• Document Current Way of doing Business (i.e.,
  functions, processes and activities)
• Associate As-Is Capabilities to Business
  Requirements (i.e., DOI Strategic Plan)
• Identify Opportunities for Streamlining Processes
• Identify Opportunities for Standardizing
  Processes
• Relevant FEA Models
• PRM, BRM

• To-Be
• Optimized Processes defined through
  re-engineering.
• Re-engineered processes captured and integrated
  back into IEA as Target Business Architecture.
• Transition Plans
• Feeds Modernization Blueprint
• Feeds Workforce Planning

• Analysis
• Identify Gaps in
• Current
• Business
• Capabilities
• versus
• Defined
• Business Rqmts.

6
Data Architecture

• To-Be
• Standardized Data
• Optimize sharing of data in DOI data stores.
• Define data exchange formats (e.g., XML Schema)
• Transition Plans
• Data Integration/
• Consolidation Plans
• Feeds Modernization Blueprint

• As-Is
• Document Current Data Requirements (e.g., data
  subject areas).
• Identify Opportunities for Sharing Data
• Identify Opportunities for Standardizing Data
• Relevant FEA Model
• DRM

• Analysis
• Identify Gaps in
• Meeting Current
• Data Requirements
• Identify Areas for
• Data sharing
• and Integration.

As-Is
To-Be
Transiton Plan
7
Applications Architecture

• To Be
• Develop Modernization Blueprints for LOBs.
• Identify Systems to be
• Retired
• Consolidated
• Integrated
• New Starts
• Analyses Based on Criteria across all IEA layers
  Business,
• Data, Applications, Technology
• Determine Transition Plans
• Tactical
• Strategic

• Analysis
• Identify Gaps in
• App. Systems ability to
• meet Current
• Business Rqmts.
• Identify Areas for
• App. Integration.

• As-Is
• Identify Current Systems (Operational Planned)
• Identify Current Services Provided by
  Applications
• (e.g., WorkFlow, Customer
• Relationship Mgmt.)
• Identify System Redundancy
• Functional Overlaps
• Data Overlaps
• Competing Systems for Delivering Business Rqmts.
• Determine System Adherence to TRM
• Relevant FEA Models SRM
• Plus Input from mapping to PRM, BRM, DRM
  TRM

8
Technology Architecture

• To-Be
• Determine Preferred Technology Architecture.
• Based on Business Requirements
• Covers all technology domains.
• Defines standards via TRM
• Transition Plans
• Feeds Modernization Blueprint
• Feeds DOI Consolidated
• Acquisitions

• As-Is
• Identify As-Is Technology Architecture (e.g., SMS
  extracts of existing infrastructure)
• Associate As-Is Technology Capabilities to
  Business Requirements (i.e., DOI Strategic Plan)
• Identify Opportunities for Standardizing
  Technologies for Simplified Infrastructure.
• Relevant FEA Models
• SRM (Technical Services), TRM

• Analysis
• Identify Gaps in
• Capabilities for
• Current
• Infrastructure
• To support
• Defined
• Business Rqmts.

As-Is
To-Be
Transiton Plan
9
Proposed IEA Teams Demarcation Lines
The ARB will oversee the technical standards for
these groups (e.g., Application Integration and
Middleware technologies, data exchange XML,
etc.). In addition, the ARB will also oversee CM
for DOI-wide Infrastructure Projects (e.g., AD,
ESN).
10
How will Interiors Modernization Blueprints be
Developed?
Technology
Business
Data
Applications
BRM
PRM
TRM
DRM
SRM
IBAT
DRMSG
ARB
IAWG System Owners
Validated Systems Inventory and Capabilities
Validated Technology Rqmts.
Validated Data Models
Validated Business Models
Consolidated recommendations To E-Gov, MIT MEC
DOI Modernization Blueprints/LOB
DEAR
IAWG (Validate FEA/IEA Mappings)
IBAT ARB (Review Business Technical
Findings Recom.
Note Line of Business (LOB) Architecture Teams
(e.g., Fire, Financial Mgmt., should coordinate
with and advise their respective IEA reps. on the
accuracy of the IEA mappings and resulting
findings and recommendations
11
IEA Teams Responsibilities

• IAWG Bureau Chief Architects or EA Designate
• Overall EA responsibility within Bureau
• Coordinates with Bureau architecture reps. from
  all IEA layers
• Ensures proper integration/association of EA data
  
• Primary POC for Bureau-level DEAR Repositories
• Overall Responsibility for Bureau Input into
  Developing Modernization Blueprints.

12
IEA Teams Responsibilities

• IBAT Business Representatives from each Bureau
  and Key LOBs
• Defines/validates Business Models
• Serves as liaison to Appropriate Business
  Managers.
• Participate in Business-layer analysis of
  Modernization Blueprint
• Change Management Board for DOI Business Models
  Integrated in DEAR

13
IEA Teams Responsibilities

• DRMSG Data Architects
• Defines/Validates Data Architecture
• Serves as Liaison between Data Stewards to
  develop Data Architecture
• Identifies Opportunities for Consolidating/Integra
  ting Redundant Data Stores.
• Identifies Opportunities for Standardizing Data
• Coordinates/oversees Interior data
  standardization efforts.

14
IEA Teams Responsibilities

• ARB Oversees Technical Architecture
• Primary recommendation board to ITMC for TRM
  Approval
• Oversees Domain Architecture Teams Products
• Technology Architect provides leadership and
  oversight to DATs.
• Oversees technical standards and products
  associated with Data (e.g., ODBC, JDBC, XML) and
  Applications (e.g., application middleware) under
  guise of TRM.
• Change Control Board for DOI-wide IT
  Infrastructure Initiatives (e.g., ESN, AD).
• Co-Chaired by DOI DCIO and Bureau-level DCIO

15
QUESTIONS/DISCUSSION