Practicing Enterprise Information Architecture II: Architecture

People
Value
Process
Technology
Practicing Enterprise Information Architecture II:
What to Deliver and How to Deliver Information
Architecture
Freddie Mac Enterprise Architecture
Leon Bernal, Architecture, Director
Xinhua Deng, Ph.D., Senior Information Architect
-1-
Succeed With Information Architecture (Recap)
I. People
- Information Architecture (IA) resides in Enterprise Architecture (EA) with executive
support
People
- Requires soft and technical skills
II. Process
- Engage early before budget is set
- Create architecture
- Approval at control gate
Value
III. Technology
- Use
U proven ttechniques
h i
IV. Value
Technology
- Improve systems environment
Process
- Eliminate breakage from ‘out-of-scope’ impacts
- Improve data quality: data definition, minimized redundancy, defined SOR, and clear
access path for consumers
-2-
I People: Who Creates Architecture?
-3-
Four EA Disciplines
Model
System &
Service
Model Data,
Information
Lifecycle &
System
Define Hardware,
Operating System,
Network Security &
Network,
Middleware
Model Function,
Process, Business
System
-4-
Collaboration to Build Better Systems
Business
Architect
Delivery
Services
Application
pp
Architect
Develop
Architecture
Build the
System
Partners
架
构
EA
Information
Architect
Client
Services
Technical
Architect
-5-
Establish
Business Case
II Process: How and What to Deliver for Information
Architecture?
-6-
Early Engagement Is Key
Guidance
Phase 0
Opportunity
Assessment
Strategy
Solution
Approach
Architecture and
Business Case
Approval
Phase 1
Pipeline
Analysis
Project
Origination
Architecture and
Design
g Approval
pp
Phase 2 / SDLC
Project &
Initiative Execution
Project
Initiation
Project
Planning
Project
Execution
Create and Review Architecture, Provide Guidance
Architecture
Approval
-7-
Phase 3 / SDLC
Post
Implementation
Project
Close-Out
IT
Production
Solution
Close-Out
Architecture Engagement
Goals
1. Determine whether project change is architecturally significant
2. Ensure that architecture allows us to go from current state to desired state
3. Ensure the architecture meets requirements and is consistent with our
goals and principles
4 Ensure
4.
E
D
Design
i iis consistent
i t t with
ith the
th approved
d architecture
hit t
Processes
1.
2.
3.
4.
5.
6.
Determine if engagement is to create or review architecture
Create SOW if creating architecture
Submit architecture or design
g to g
group
p mailbox for review
Review performed by senior architect with delegated approval authority
Review SLA is 5 business days for feedback or approval
Retain approved artifacts under version control
-8-
Information Architect Role & Responsibilities
- Define EA Goals, Principles and
Guidelines
- Define Corporate Data Architecture
- Create, review and approve
architecture and design for Pipeline
projects and Initiatives
- Define system partitioning with
Application, Business, and
Technical Architects
- Define information model
- Define canonical data model,
system logical data model
model,
conforming dimensions and facts
- Create interface formats based on
CDM XML
CDM,
-9-
Consider:
- Is approach aligned with strategy,
requirements,
q
, standards?
- What is the appropriate source?
- What data is created or changed?
- What is impact
p
on data
consumers?
- What data history is required?
- What constraints apply?
Define:
- System of record
- Alternate data source
- Read only copy
- Data structure
patterns
- Interface p
- Historical record
Architecture Deliverable
1
2
3
4
5
SCOPE and OBJECTIVES
ARCHITECTURE ASSESSMENT
2.1 Project Team’s Assessment
2.2 Architecture Services’ Assessment
ARCHITECTURE SOLUTION
3.1 Current-State Capability
3.2 Architectural Assumptions
3 3 Architectural Decisions
3.3
3.4 Open Issues
3.5 End-State Vision
3.6 Models
3.6.1
Logical Data Model
3.6.2
Business Model
3.6.3
Information Model
364
3.6.4
Application Architecture Model
3.7 Architecture Risks
ARCHITECTURE ALTERNATIVE ANALYSIS
ARCHITECTURE EVOLUTION PRIORITIES
- 10 -
Joint Effort
IA Effort
BA Effort
IA Effort
AA Effort
Joint Effort
Architecture Assessment
No
Yes
System changes are architecturally significant if they affect key structural
elements of a system, externally visible properties, and their relationships.
1.
2.
Creating a new system is architecturally significant
Changing
g g a system
y
can be architecturally
y significant
g
if:
ƒ
Creating a new data entity
ƒ
Creating a changing a data source
ƒ
Creating or changing a system interface
ƒ
Creating or changing an external interface
ƒ
Creating new PPI or confidential data
- 11 -
Logical Data Model
In Phase 0:
1. Name and define the data entities that will be stored by, produced by,
or consumed by the system as described in the requirements.
2. Indicate the System
y
of Record for the data when defining
g the data
entity.
In Phase 1, elaborate on Phase 0 as follows:
3. Create a data model that depicts the data entities, the relationships
between the data entities and the cardinality of the relationships.
4. Identify confidential and Personal Protected Information (PPI) at the
d t entity
data
tit level.
l
l
In Phase 2, elaborate on Phase 1 as follows:
5 Create a Logical Data Model including all data entities and data
5.
attributes that are part of the solution.
6. Prepare a data dictionary, naming and defining all data entities
and data attributes in the data model.
- 12 -
Create Logical Data Model using CDM
Create
Requirements
IT Review
Requirements
Create or
Change Data
Model?
No
Yes
No
Search
S
h ffor Data
D t
Element in CDM
System
Metadata?
Is Data
Element in
CDM?
No
Add Data Element
to CDM
- 13 -
Yes
Yes
Create Logical
System Data
Model
End
Logical Data Model – Fund Loan
Fund Loan: Purchase Loan and Create Security,
essential to Freddie Mac Mortgage-Related business
Loan Origination
RESPA Summary
Financial Instrument
Z
Loan Settlement
Loan Position
Loan Borrower
Loan
•
•
Pool
Security
Collateral Group
•
Loan Activity
Agreement
Loan Acquisition
Counterparty
p y
Fund Loan
Mortgage Backed Security
Securitization Trust
Create Security
- 14 -
Leverage CDM
Depict entities and
relationships needed
to meet requirements
Subject areas: Loan
Loan,
Security, Party,
Agreement
Logical Data Model Description
Entity Name
Loan
Agreement
Pool
Counterparty
MBS
Loan Origination
Entity Definition
An agreement, in writing, between a lender and a borrower where the borrower will be loaned a specific amount of
money over a specific amount of time at a specific interest rate or rates.
Meeting of minds (or an evidence of mutual accord or understanding) between two or more legally competent
parties, about their relative duties and rights regarding current or future performance.
A collection of (usually similar) financial instruments that are treated as an aggregate, such as for collateral
backing a security or as sharing a credit enhancement.
Counterparty is a company that does business with or supports the business of Freddie Mac. A counterparty
engages with Freddie Mac in a transaction where one or more parties agree on an exchange of assets at a
specific point in time and deliver on the ag
A mortgage-backed
g g
security
y ((MBS)) is an asset-backed security
y whose cash flows are backed by
y the p
principal
p and
interest payments of a set of mortgage loans. Payments are typically made monthly over the lifetime of the
underlying loans.
Loan origination is the process of creating a (mortgage) loan, culminating in the signing of the loan documents by
the lender, the borrower, witnesses, and/or their agents. It also records information about the loan that is current
at the time of origina
•
•
Name and define each entity, and each attribute.
Align with the CDM to standardize data definition.
- 15 -
Information Model
In Phase 0:
1. Create one overall Information Model Diagram depicting the system and systems with
which this system will interface.
2. Assign responsibility for data entities, systems of record, and data stores.
3 Depict what is new or changing in this initiative/project
3.
initiative/project.
4. Use data names defined in the Logical Data Model.
In Phase 1, elaborate on Phase 0 as follows:
5. Complete the information-oriented diagram including all impacted systems,
subsystems, data stores, and data entities in the diagram.
6. Name and define each system depicted in the diagram.
7. Depict service interfaces, data proxies and data movement.
8. Annotate data movements with the data access mechanism
9. If there are multiple data stores in a system, depict the data stores involved in data
accesses and movements.
10 Identify object/entity volumes and sizing estimates (the system at rest)
10.
rest).
11. Define each system with which this system interfaces, and the technology choice
12. Define impacts to each data consumer.
In Phase 2,
2 prior to SDLC Checkpoint A Design review:
13. Update the Information Model defined in Phase 1 with changes and the rationale
for the change.
- 16 -
Information Model – Fund Loan
Counterparty
+ Counterparty (S OR)
Deal
+ A greem ent (S OR)
+ Counterparty
C
t
t (ROC)
Loan S ourc ing
+ A greem ent (ROC)
+ Counterparty (ROC)
+ Financ ial Ins trum ent ((S OR))
+ Loan (S OR)
+ Loan A c quis tion (S OR)
+ Loan B orrower (S OR)
+ Loan Origination (S OR)
+ Lo an S ettlem ent (S OR)
+ RE S P A S um m ary (S OR)
Loan S ervic ing
+ A greem ent (ROC)
+ Counterparty (ROC)
+ Loan (ROC)
+ Loan A c tivity (S OR)
+ Loan Origination (ROC)
+ Loan P osi ti on ( S OR)
S ec urity S truc ture
+ A greemen t (ROC)
+ Collat eral Group (S O R)
+ Loan (ROC)
+ P ool (S OR)
Data Integration Hub
+ Ag reem ent (ADS )
+ Co llateral Gro up (A DS )
+ Coun terparty (A DS )
+ Financ ial Ins trum ent (A DS )
+ Loan (A DS )
+ Loan A c qus iti on (A DS )
+ Loan A c tivity
y (A
( DS )
+ Loan B orrower (A DS )
+ Loan Origination (A DS )
+ Loan P os ition (A DS )
+ Loan S ettlem ent (A DS )
+ M B S (A DS )
+ P ool (A DS )
+ RE S P A S um m ary (A DS )
+ S ec uritiz ation Trus t (A DS )
+ S ec urity (A DS )
S ec urity Is s uranc e
+ Collateral Group (ROC)
+ Counte rparty (ROC)
+ M B S (S OR)
+ P ool (ROC)
+ S ecur itiz ati on Trus t (S OR)
+ S ecurit y (S OR)
W arehouse Foundat io n Lay er
+ A greem ent (A DS )
+ Collateral Group (A DS )
+ Counterparty (A DS )
+ Financi al Ins trume nt (A DS )
+ Loan (A DS )
+ Loan A c qus ition (A DS )
+ Loan A c tivity (A DS )
+ Loan B orrower (A DS )
+ Loan Origination (A DS )
+ Loan P osi ti on (A DS)
+ Loan Se tt lem ent ( ADS )
+ M B S (A DS )
+ P ool (A DS )
+ RE S P A S um m ary (A DS )
+ S ec uritiz ation Trus t (A DS )
+ S ec urity (A DS )
E nterpris e Data M art
+ A gree ment (ROC)
+ Collat eral Group (RO C)
+ Counterparty (ROC)
+ Financ ial Ins trum ent (ROC)
+ Loan (ROC)
+ Loan A c quis ition (ROC)
+ Loan A c tivity (ROC)
+ Loan B orrower (ROC)
+ Loan Origination (ROC)
+ Loan P os ition (ROC)
+ Loan S ettlem ent (ROC)
+ MB S (RO C)
+ P ool (ROC)
+ RE S P A S um m ary (ROC)
+ S ec uritiz ation Trus t (ROC)
+ S ec urity (ROC)
SOR System
SOR:
S
Of
Record
ROC: Read Only
Copy
ADS: Alternate
Data
Source
1. Arrows indicate the dependencies between systems
2. Data Entities are from the Logical Data Model
- 17 -
Information Model Description – Fund Loan
Counterparty
Deal
Loan
Sourcing
Certifies and maintains a record of counterparties with whom the company will do business and the types of
business transactions for which the counterparty is eligible. SOR for counterparty.
Maintains a record of negotiated business terms related to the deal. Uses ROC of counterparty from data
integration hub and is SOR for agreement.
Accepts loan data into the company and records the purchase of the loan. Uses a ROC of counterparty and
deal from data integration hub and is SOR for most loan data. Creates fund loan event.
Processes and maintains a record of the loan events such as loan payment, loan payoff. Uses a ROC of
Loan Servicing counterparty, agreement, loan and loan origination from data integration hub. SOR for loan activity and loan
position Fund loan event initiates set up of loan for servicing
position.
servicing.
Security
Structure
Creates pools of loans that will form the structure for a MBS and structures the cash flow. Uses ROC of loan
and agreement from data integration hub and is SOR for pool and collateral group. Fund loan event initiates
securitization of the loan.
Security
Issuance
Creates MBS using
g security
y structure,, manages
g the transfer of ownership
p of a MBS to an investor,, disclosing
g
MBS characteristics to the capital market, and wiring the MBS to the Federal Reserve Board (FRB). Gets
the pool and counterparty from data integration hub, SOR for MBS, securitization trust and the security.
Data
Integration
Hub
Integrates and stages business transaction data and related reference data. Maintains the current view of
entities. Serves as the alternate data source for data consuming systems. Reconciles to SOR.
Warehouse
Foundation
Layer
Maintains a normalized, historical record of data and serves as the alternate data source for the enterprise
data marts. Reconciles to SOR.
Enterprise
Data mart
Maintains dimensional structures facilitating data analysis, management and financial reporting. Reconciles
to the Warehouse Foundation Layer.
- 18 -
EA Scoring and Communication
- Score Architecture for 5 Goals
+1 = Moving Toward Goals
0 = Neutral
-1 = Moving Away From Goals
- Communicate Scores to Stakeholders
Agility
SPOT
Security
Reliability
0
0
0
0
0
Y
Y
Y
Y
Y
R
-1
Interoperability
G
1.000
Score
1
R
-1
G
1.000
Score
1
R
-1
G
1.000
Score
- 19 -
1
R
-1
G
1.000
Score
1
R
-1
G
1.000
Score
1
Scoring is Based On EA Goals
What It Means
EA Goal
Agility
‐Business agility requires flexible IT systems
Single Point of Truth
‐Ability to rely on our data for running our business
Interoperability
‐Ability for systems to communicate with each other
Reliability
‐Ability to rely on our systems for running our business
Security
‐Ability to protect our sensitive information and systems
- 20 -
II Technology: What Tools and Patterns are in the
Information Architecture Toolbox?
- 21 -
Information Architecture Toolbox
Mission
Strategy & Policy
EA Standards and Principles
EA Review Processes
EA Catalog
Data
Data
Data
Data
Storage
Definition
Movement
Persistence
• TDS
• Canonical
Data Model
• DW
• ODS
• Data
Mart
• Business
Data
Dictionary
• XML
• ETL
• Messages
&
Messaging
• ESB
Metadata
Business
Unstructured
Intelligence
Data
• System of
Record
• Metadata
Repository
• Conforming
Dimensions
• Document
Management
• Alternate
Data Source
• Architecture
Repository
• Conforming
Facts
• Email
• Read Only
Copy
• Data Model
Repository
• Source from
Historical
Record
Canonical Data Model
Metadata Management (MDR & CDE Registry)
Information Quality and Controls
Data Security
- 22 -
Freddie Mac Enterprise Architecture Contacts
L
Leon
Bernal
B
l
Architecture, Director
Freddie Mac
8250 Jones Branch Drive
M L
McLean,
VA 22021
[email protected]
- Think strategically
- Keep
K
enterprise
t
i view
i
- Act specifically
- Be persistent
- Keep
p smiling
g
Xinhua Deng, Ph.D.
S i IInformation
Senior
f
i Architect
A hi
Freddie Mac
8250 Jones Branch Drive
McLean, VA 22021
[email protected]
What?!
Out of
Scope?
- 23 -