Proposed Architecture Framework

Advanced Planning Briefing

Office of Enterprise Development

Joaquin J. Martinez de Pinillos

Director Software Engineering

November 17, 2009

Proposed Architecture Framework


overview

Office of Enterprise Development (OED)

Software Engineering (SE)

The SE team strives to apply a systematic, reliable and disciplined

approach to plan, architect, design, test, and release software for

VA business operations.

SE follows the OI&T policy for IT strategy and enterprise

architecture guidelines.

SE interacts with business customers, Enterprise Infrastructure

Engineering (EIE), and Operations and Maintenance Teams to meet

business needs and to make the software development life cycle

(SDLC) seamless.

SE is comprised of three services: Application & Data Architecture

Service, Standards & Compliance Service, and Testing Service.


Line of Sight in Action

Strategy

Business

PRM

BRM

Data

DRM

Applications & Services

Technology Infrastructure

SRM

TRM

Information & Data

Line of Business (LOB) or

Business Process Modeling

Center of Excellence (PMCE)

SE

Business Process Models

Performance Reference Model

(PRM)/Strategy Documents

Systems Engineering (SE)/Architecture and

Engineering Processes

System Development Life Cycle (SDLC) Process

IT Products IT Products IT ProductsIT Products

SE Artifacts


Interface between Software Engineering (SE)

& Line of Business (LOB)

SE

LOBStrategy

Business

PRM

BRM

DataDRM


Technology Infrastructure

SRM

TRM

InformationInformation & Data

Challenge

•Some LOB do not have business

architecture capability

• SE interface will help close that

gap


System of Systems (SoS)

Software

module or

Service i.e.

lab,

scheduling,

identity, etc

Software

module or

Service i.e.

lab,

scheduling,

identity, etc

Software

module or

Service i.e.

lab,

scheduling,

identity, etc

Software

module or

Service i.e.

lab,

scheduling,

identity, etcSoftware

module or

Service i.e.

lab,

scheduling,

identity, etcSDLC Process

•Provide boundary conditions and definition of black

boxes

•Software Engineering Management Plan (SEMP)

•Heavy focus on SoS Architectures/Designs

• 508 Requirements/Design

• Disaster Relief (DR)

• Service Oriented Architecture (SOA)

•Etc.

•Provide processes in the development of individual

modules

•Heavy use of Rational/Jazz Tool Suite although has

some need for software engineering tool suites

•Agile Development Methodology

•Project/Service focused requirements

•Lab

•Payment of benefits

•Etc

Software

module or

Service i.e.

lab,

scheduling,

identity, etc

SOA Stack Common Services

-Heavy use of Rational Tool Suite (with Jazz

enhancement). Some Systems Engineering Tools

-Heavy use of a modeled based Systems

Engineering Tools Suite and some Rational (with

Jazz enhancement) Products

Business Architecture

Artifacts

Systems Engineering/Architecture

and Engineering Processes


System of Systems

Software

module or

Service i.e.

lab,

scheduling,

identity, etc

Software

module or

Service i.e.

lab,

scheduling,

identity, etc

Software

module or

Service i.e.

lab,

scheduling,

identity, etc

Software

module or

Service i.e.

lab,

scheduling,

identity, etcSoftware

module or

Service i.e.

lab,

scheduling,

identity, etc

SDLC ProcessSoftware

module or

Service i.e.

lab,

scheduling,

identity, etc

SOA Stack Common Services

Systems Engineering/Architecture

and Engineering Processes

•Artifacts of SE Process feed into

various spots in SDLC

•Artifacts need be focused on SoS

•Artifacts need to tie into business

architecture

Challenge

•How do artifacts which are updated on a periodic

basis fit into a time based (project based) project

•Sequencing artifact updates to all project

schedules not possible

•SE artifacts must take into account projects at

different states in SDLC and be able to

account for different life cycle states

Business Architecture

Artifacts


Strategy

Business

Information & Data


Technology & Infrastructure

Architecture Artifacts

Services(What are they going to be)

SW-TRM Network Architecture

COOP DR Architecture

HW Standards & Architecture

Business Models SOS

Federal Enterprise Architecture(FEA)

Enterprise Requirements

Project Scope


HeV Project Scope

PRM

BRM

SRM

TRM

DRMData

Architecture• SOA Linkage• Coding• Interface Standards (SOA Shop)• Data Standards• Design Standards (SOA)• Programming Standards

Standards & Practices



Business Reference Model

Data Reference Model

Service Component Reference Model

Technical Reference Model

FEA Reference Models

(from FEA Overview Presentation by FEA PMO, February 2004)

PRM

BRM

DRM

SRM

TRM


Standardized framework to measure the performance of

major IT investments and their contribution to program

performance

Function-driven framework for describing business

operations of the Federal Government independent of the

agencies that perform them

Model describing, at an aggregate level, the data and

Information that support program and business line

operations

FEA Reference Models Cont’d

DRM

BRM

PRM


Business and performance-driven functional

framework that classifies service components with

respect to how they support business and/or

performance objectives

Component-driven, technical framework used to identify

the standards, specifications, and technologies that

support and enable the delivery of service components

and capabilities

FEA Reference Models Cont’d

SRM

TRM


Federal Enterprise Architecture (FEA)

Data Reference Model (DRM)(Data Architecture)

Service Component Reference Model (SRM)(Service Model, Application Architecture)

Performance Reference Model (PRM)(Metrics)

Business Reference Model (BRM)(Business Processes)

Technical Reference Model (TRM)(Standards, Specifications, Technologies)

Measure Delivery of Business Services Business

Services

Strategic Outcomes

Govern


Business ModelsSOS

Project Scope

ie, Reliability and Availability

Data Architecture

Services(What are they going to be)

SW-TRMNetwork Architecture

HW Architecture & HW Standards

Enterprise Requirements


FEA REFERENCE MODEL ARTIFACTS


Project Goals and Objectives (Scope)Technical Sequence PlanIntegrated Master ScheduleReliability and Availability RequirementsReliability and Availability Implementation PlanMetrics Measurement Plans and ProceduresMetrics Measurement ToolsMetrics Database, Analysis Tools, and Reports

Business Reference Model Business Processes Definition Document (Business use cases)Business Requirements Management ProcessBusiness RequirementsBusiness RulesBusiness Rules Management Plan

Architecture & Artifacts

BRM

PRM


Architecture & Artifacts Cont’d

Data Reference Model Data Architecture ModelData Standards- Data Descriptions (Data Dictionary)- Data Context (Taxonomies)- Data Sharing (Query Points and Exchange)DRM Abstraction Model

Service Component Reference Model

(see Services – Slides 9-12)

Current Architecture Diagram (As Is)Future Architecture Diagram (To Be Model)Service ModelServices Definition ArtifactsServices Usage ArtifactsServices Management Processes and Tools


SRM

DRM



Technical Reference Model IT-Technical Reference Model Enterprise Requirements RepositoryEnterprise Requirements Compliance Criteria and Review ProcessesLegislative Compliance Evaluation DatabaseSecurity PlanSoftware Development StandardsSoftware Development EnvironmentSoftware Management Processes- Requirements Management and Traceability- Change Management- Deployment Management- Version Management- Defect Tracking- Issue Management- Task Management


TRM



Technical Reference Model Cont’d

Test Management ProcessTest EnvironmentHardware Architecture ModelHardware StandardsNetwork Architecture ModelNetwork StandardsOperations and Troubleshooting ProceduresInventory Management Plans and Tools(FEA puts this in SRM but seems to make more sense here)


TRM


Strategy

Business

Information & Data




Strategy

FEA: Strategy


Strategy

SE Strategic Plan

•Work within VA strategic plan

•Modernize technology based on T-21

•Meet program goals & objectives


Strategy

Business

Information & Data




FEA: Business

Business


Business Models

Business-Based Lexicon Document

• Describes business capability

• Provides framework for discussion

• Illustrates lexicon in no more than 20 pages

• Ties into VA strategic plan


Business Products:

Capabilities that provide business unique services

• Project goals & objectives

• Modeling & monitoring tool plan

• Workshop definition documentation

• Process models with business requirements

• Process metrics & KPIs

• Gap analysis

• Re-use plans

• Business service models

• Conceptual model

• Business use case narratives & diagrams

• Functional flow diagrams

Business Products


Strategy

Business

Information & Data




FEA: Information & Data

Information & Data


Standards & Practices

Standards• SOA design pattern

• Coding & programming standards

– The initial standards profile, addressing Java coding standards,

will be published as an entry in the IT-TRM by 12/1/2009.

– Additional profiles, to include all major identified technologies in

use for VA development, will be published throughout 2010,

– The first generation of profiles will be complete by 12/1/2010

• Interface Standards

• Data Standards

• Design Standards


Governance

Standards, Specifications, Patterns

• Data Strategy, Interface Design and Architecture with associated Coding standards are synergistically evolved through BRM/BPM analysis

• Service-Orientation is appropriate embedded in each of these based on a business case evaluation of the capabilities being augmented or transformed.

Fed by co-

evolution of

technology and

BRM/BPM

analysis


Strategy

Business

Information & Data




FEA: Applications & Services

Applications &

Services


Service Definition Methodology will:

• Define all VistA-HealtheVet products

• Categorize infrastructure products

Service Definition Methodology


Infrastructure Products

•Provide key features/functions required by HeV

(aka “Common Services”)

•Align with enterprise VA Standards, specifications, patterns,

and practices wherever possible

-OED SE Enterprise Architecture Review Governance will manage/oversee

“gap”

•Initial Web service-based core infrastructure services

reference implementation built as part of VBA Ch 33

-Not every capability or “service” in HeV is/will be web-services based



Infrastructure Products Initial Service Reference

Implementation Offerings:

•Discovery

•Messaging

•Security

•Identity

Inclusive of physical implementation as well as SSPP,

developer, [FEA] architecture documentation and OED SE

governance process to manage evolution and extension of

capabilities (initial release: 6/10)

Infrastructure Products Cont’d


Service Artifacts

Two Categories of Service Artifacts:

• Service Definition Artifacts

-Used by SE to identify and categorize products

• Service Usage Artifacts

-Provided to projects to inform projects of services provided by

products and to provide instructions for use of services

Service Artifacts


•Additionally, documentation to support product development

-List of documentation/templates required for Infrastructure

products

-List of documentation/templates required for business products

•Documentation requirements on a project identified via

project-to-product map

-Documentation will be structured along product (not project) lines

-A project will create/update documents for products that the

project affects

•Additionally, Service Definition Methodology will support

development of HealtheVet to-be architecture evolution and transition

products

-Sequence Plan (PRM Artifact)

-Master Schedule (PRM Artifact)

Service Artifacts Cont’d

VistAProduct List

V1...Vn

VistA Products

MPI

VistA-HeV As-Is Arch Model

VistA

HeV

U/I

VIEDS

VLink

CAIP

HeV

U/I

CAIP

KAAJEE FatKAAT

DSVIE

HWSC

ADR

HDR

DoD Info

HEC

CorpDB

CorpDBCorpDBCorpDB

CorpDBCorpDBCorpDB

Adapt

Ext I/F

Adapt

VistA

EnterpriseInfrastructure Services

HeV

.HeV

. .

BusinessInfrastructure

HeV To-Be Arch Model

Adapt

ADR

HDR

CorpDBCorpDBCorpDBCorpDB

DoD Info

Ext I/F

......

.

Adapt

.

Adapt

User I/F. .

CS CS

. .Portfolio1

Proj1.1

Proj1.2

Portfolio2...PortfolioN...ProjN.n

OBS

HeV“Egg Chart”

FEA Model

VistA-HeVProduct List

V1...

Vn

HeV1....HeVn

VistA-HeV Products

HeV Products

HeVn HeV1… Product List Product Categorization- Infrastructure- Business

P1...Pn

Infrastructure

P1...

Pn

Business

Product-to-Project Mapping

Pn

P1

P2

P[n+1]

PN

...

Proj1 Proj2 ... ProjN

x

x x x

x x

x x

x

x

x

...

ICD List

(Unilateral

)

Infrastructure

Uni ICD List

(Bi/Multi-

lateral)

Business

Bi/ MultiBi/ MultiBi/ MultiBi/ MultiBi/ Multi

N2Chart

P1

P2

...PN

P1 P2 ... PN

x x

x

x

Ext I/FExt I/FExt I/FExt I/FExt I/F

Proj Doc

Seq Plan

Master Schedule

HeV to VistA-HeV Product Mapping

HeVn

HeV1

...

VHeV1 ... VHeVN

x

x x

x

Service Definition Methodology


Service Definition Methodology and Supporting Artifacts

ACTIVITY ARTIFACTS

1 Register HealtheVet Products VistA-HealtheVet Products List

2 Update VistA As-Is Architecture Model VistA-HealtheVet As-Is Architecture Model

3 Categorize HealtheVet Products

- Infrastructure Products

- Business Products

Categorized VistA-HealtheVet Products List


Business Products

4 Develop HealtheVet To-Be Architecture Model HealtheVet To-Be Architecture Model

Service Model

5 Map HealtheVet (To-Be Architecture) Products to

VistA-HealtheVet (As-Is Architecture) Products

HealtheVet (To-Be Architecture) Products to

VistA-HealtheVet (As-Is Architecture) Products

Map

6 Identify HealtheVet Product-to-Product

Dependencies (Interfaces)

N-squared Chart

(HealtheVet Product – to – HealtheVet Product)

7 Identify Product Usage (Interface) Documentation

- Infrastructure Products: Uni-Lateral ICDs

- Business Products: Bi-/Multi-Lateral ICDs

List of Uni-Lateral ICDs

Uni-Lateral ICDs = Common Service Standards

DocsList of Bi-/Multi-Lateral ICDs

8 Develop Project-to-Product Mapping Project-to-Product Map

9 Structure Project Documentation in accordance

with Products

Product Documentation List

Product Documentation Templates

10 Develop “HealtheVet Evolution” Artifacts

- Sequence Plan

- Master Schedule

Sequence Plan (PRM Artifact)

Master Schedule (PRM Artifact)

Advanced Planning Briefing Artifacts Cont’d

SERVICE DEFINITION ARTIFACTS ARTIFACT STATUS

VistA-HealtheVet Products List - VistA Products are already registered

- VistA-HealtheVet Products List will be available when HealtheVet

Products register

(requires management direction to HealtheVet Projects)

VistA-HealtheVet As-Is Architecture Model - Strawman exists

- Can be updated when VistA-HealtheVet Products List is available

Categorized VistA-HealtheVet Products List - Several Analysis Products to support categorization exist

- To complete requires VistA-HealtheVet Products List and some

additional analysis

HealtheVet To-Be Architecture Model

Service Model- Strawman exists

- To complete requires VistA-HealtheVet Products List and support of

project teams responsible for Infrastructure Products

HealtheVet (To-Be Architecture) Products to VistA-HealtheVet

(As-Is Architecture) Products Map

- Has been started for Messaging Products

- Will be developed in conjunction with HealtheVet To-Be Architecture

Model

N-squared Chart - Cannot be started until VistA-HealtheVet Products List is available

- Will require analytical support from Project Teams

List of Uni-Lateral ICDs

List of Bi-/Multi-Lateral ICDs- Will be identified as a consequence of development of

- Categorized VistA-HealtheVet Products List

- N-squared Chart

Project-to-Product Map - Requires VistA-HealtheVet Products List

- PMO-owned Artifact


SERVICE USAGE & PRODUCT DEVELOPMENT

ARTIFACTS

ARTIFACT STATUS

Product Documentation List

Product Documentation Templates- Already exists for VistA Products

- May require some updating to completely support

HealtheVet Products; determination will be made

when HealtheVet Products comply with VistA

Product Registration and Management Process

Uni-Lateral ICDs - Required Uni-Lateral ICDs will be identified as a

consequence of development of Categorized VistA-

HealtheVet Products List

- Identified Uni-Lateral ICDs will be assigned to

Project Team for the Infrastructure Product for

development

(Messaging Team has already begun development of

Messaging Uni-Lateral ICD)

EVOLUTION AND TRANSITION ARTIFACTS ARTIFACT STATUS

Sequence Plan (PRM Artifact)

Master Schedule (PRM Artifact)- Strawman of these Artifacts requires analysis of the

following Service Definition Artifacts:

- Categorized VistA-HealtheVet Products List

- VistA-HealtheVet As-Is Architecture Model

- HealtheVet To-Be Architecture Model

- Project-to-Product Map

Artifacts Cont’d


Strategy

Business

Information & Data




FEA: Technology & Infrastructure

Technology &

Infrastructure


3535

Enterprise Requirements Management

Program Objectives

• Central compilation and tracking of cross- cutting enterprise-level requirements

• Assure allocation of enterprise-level requirements to projects

• Enhance traceability from and to project-level requirements

• Foster requirements engineering best practices

• Align requirements management with system development methodology and processes


3636


Enhancement & Maintenance

• Performed on an annual cycle - completed by 9/30/09

– Centrally gather and elicit enterprise-level requirements

– Conduct and participate in peer reviews and validate enterprise-

level requirement submissions

– Establish and maintain an enterprise-wide requirements

repository

– Perform change and configuration management of enterprise

requirements repository contents


3737


Functions and Services

• Project-level services provided upon request

(est. 90 day cycle assuming full commitment of ERM, SE, SME & Project resources)

– Allocate enterprise-level requirements to projects

– Trace enterprise-level requirements to project-level requirements

– project system requirements review

• Program system requirements reviews – semi-annual in October &

April


Technology & Infrastructure Roadmap

Technology Roadmap

../../../../VATechnologyRoadmap.swf


Technology Roadmap


40

IT-Technical Reference Model

• IT-TRM identifies technologies approved or prohibited for VA system development

• Forecasts technology evolution to assist project planning

• Provides a technical framework to categorize standards and technologies

• Uses common, standardized vocabulary, enabling inter/intra-agency collaboration and interoperability

• Fosters reuse of solutions and technologies

• Supports e-Gov initiative; aligns with FEA


41

IT-Technical Reference Model

(Software)

Deliverable Timelines• HSD&D Extended Tool List (ETL)

– Predecessor to TRM; approved and prohibited tools

• TRM v1 approved by the ARB on 4/25/2007

– Populated with 25 basic technology entries

• TRM v2 approved by the ARB on 9/17/2008

– Refreshed TRM v1.0 entries, added 26 new tools

– Merged verbose listing of ETL entries into the TRM

• TRM v3.0 approved by the ARB on 1/7/2009

– Re-Assessed/Refreshed 51 entries

• TRM v3.1 completes the v3 update cycle on 5/13/2009

– v3 noted intent to refresh 15 entries in 2009

• TRM v3.2 added 14 approved, 3 prohibited tools on 8/4/2009

• TRM v4.0 will add 13 assessments; approval expected 9/16/2009


Network Architecture

• Strategy to Implement Fault Tolerant Delivery Solution

– Redundant Paths to Highly Available Systems

– Addressing the Last Mile

• Flexible Construct to Respond to Business Drivers

– Dynamic Quality Of Service

– Scale to Meet Changing Requirements

• Migration Away From De-Centralized Architecture

– Regional Data Processing Centers (RDPC) High Availability

Solution

– Network topology from the RDPC’s all the way down to the

hardware.

Network Architecture:

RDPC—High Availability Solutions


RDPC - High Availability Solution


Continuity of Operations Planning (COOP)

Disaster Relief (DR) Architecture

Artifacts of Form, Function and Program

• Artifacts of Form:

– Blueprint for hardware deploy at AITC and HITC (Owner CDCO: TBD) Need resource(s) allocated to work on this

– Software Data Flow Diagram – showing the software of each system, any data stores they may use, and the dataflow between them(Owner: SE First Draft Completed)

– Software Deployment Diagram – showing the deployment of software toprocessors but ignoring the detail of how applications use the networkfor data communications (Owner: SE, December, 2009)


Artifacts of Function:

-System-specific DR plans

(Owner: HeV Project Teams, Mostly Completed)

-HeV overarching DR Plan - to facilitate system recovery order at HITC

(Owner: SE First Draft Completed)

-Database synchronization plan after recovery at HITC

(Owner: MPI, PSIM, ADR, TBD)

May become part of some system -specific DR Plans

-Plan for recovery of messages at HITC

(Owner: SE and HeV Project teams, TBD)

COOP DR Architecture Cont’d


Artifacts of Program:

-Implementation Plan for Scalent and VMware software upgrades.

( Owner: EIE , TBD)

-Migration Plan for applications

(CDCO: TBD)

-Design of the new hardware upgrades

(Owner EIE, Completed)

-Project Schedule

( Owner , SE/EIE/CDCO First draft Complete)

COOP DR Architecture Cont’d


Data Architecture Reference Model

Enterprise Information Architecture

– A planned approach to building an organization that

encompasses business needs and IT

– Allow integration and coordination across the enterprise

– Requires a shift away from vertical or proprietary to horizontal

approaches that cut across the organization


Data Architecture Components

•Provide a standardized approach to data and database access

thru the use of:

-Uniform data modeling techniques

-Naming conventions

-Data dictionary with fully realized metadata

-Data Access - Instituting defined technology architecture

-Security & auditing services that are uniform across the

enterprise

Data Architecture Reference Model Cont’d


HealtheVet (HeV) Data Architecture - Definition

• Repositories will be used to house re-engineered HeV data

• Repositories will be stood-up on an as needed basis, following the HeV

sequence plan

• Analysis will need to be performed on the methodology employed for

data migration

• Current CDS will need to be expanded as the enterprise requirements

are identified

• VHIM domains will need to be translated. Translation should follow the

sequence plan of HeV applications


Data Architecture Artifacts

• Implement Enterprise Data Dictionary

– Re-evaluating enterprise elements tool that is currently used for the

Data Architecture Repository (DAR) – complete

– Performing evaluation of other tools available for DAR – 12/01/09

– Fully implement the agreed upon solution – Q1 2010


• Establish VA Data Model

– Review existing VistA model – ongoing

– Review & Translate the VHIM UML domains

o each domain will take approximately 4 – 8 weeks

depending on the size and complexity of the

domains. There are 20+ domains remaining and

new domains will be discovered as the HeV

sequence plan is initiated

– Create a conceptual & logical data model of the HeV

applications; must follow the sequence plan established

for HeV.

Data Architecture Artifacts Cont’d

HeV to-be Data Architecture

Repositories Roadmap


Hardware Architecture & Standards

• HW architecture and standards from EIE

• Needs to include HW architecture and standards for all programs

• Needs to include deployment models for existing programs and

projects

• Needs to include how programs and projects design or engage EIE

to design HW

• The starting point for HW architecture and standards is the RDC

artifacts


Standards

Storage

Servers

LAN

WAN

Data Center


Standards

Storage

Servers

LAN

WAN

Data Center

56

WAN Acceleration

VistA Imaging

Virtualization

Legacy VistA


One on Ones


One on Ones - Purpose

• VA will be hosting 30 minute one on one

sessions with industry on the VA

Architecture

• These sessions will be for industry to

provide feedback on this presentation

• Other documentation on the system

architecture can be found at:

http://www1.va.gov/oamm/oa/tac/

http://www1.va.gov/oamm/oa/tac/


One on Ones - Registration

• Registration for one on ones will be

announced on FedBizOpps

• Registration for the one on ones will be

handled similar to the Registration for the

APBI

• Time slots will be allocated on a first come

first serve basis

• Not a marketing opportunity

• Limited to 6 attendees


Feedback/Input for One on Ones

• VA is looking for feedback/input in the

following areas:

– The Architecture and Architecture Framework

presented