Integrated Requirements Design - OMG · IRD recognizes that an integrated team must address these...

Integrated Requirements DesignA practical methodology for SOA

Wendell Ocasio, MDChief Medical Officer, Agilex Technologies

SOA in Healthcare Conference 2009

2© Agilex Technologies, Inc. www.agilex.com

The Problem

Everybody wants “a SOA” for their organization

It is no longer controversial or hard to convince leadership to embrace “SOA”

But…what does it mean?“SOA” has become an almost meaningless buzzwordHow to actually accomplish something that brings value?

First question should be: What is the value?

What is needed

Practical techniques that allow you to:Define the expected valueUnderstand your particular challenges (“requirements”)Apply SOA principles that result in IT systems that provide the desired value (“design”)

What is Integrated Requirements Design?

Traditionally, the activity of eliciting and analyzing requirements is done separately from the design of the solutions

Different teams -> requirements thrown “over the fence”Solutions that meet requirements but do not provide the value that users expect

IRD recognizes that an integrated team must address these two aspects together

SOA Myths / misconceptions

You can get/buy/acquire/build SOASOA is:

SOA means Enterprise Service BusSOA is all about the businessSOA improves runtime performanceStart by identifying “common services”

Inadequate SOA analogy

SOA is like the roads, telephone lines, electrical lines needed to build a new housing development

We already have the Internet (or IP-based communications)

Thoughts on ESB

Enterprise Service Buses (ESBs)Do not equal SOAAre not really busesAre not a prerequisite for service orientationYou do not need to standardize ESBs across your entire enterprise

So…what is SOA?

SOA is an organizational principleValue is most apparent in:

Complex environmentsMultiple disparate IM/IT resourcesFrequent change

Better analogy: a marketStock market efficiently relates investors and industrySOA relates consumers and producers of IM/IT resources

So…what is a service then?

A mechanism that brings together a provider of a capability with potential consumers of that capabilityCorollary:

Understanding needs and capabilities of the enterprise needs to occur before you can define mechanismsDo not start by identifying services

How do I organize my enterprise?

1. Understand needs

2. Establish capabilities

3. Implement the mechanisms

Hardest aspect of SOA

Scoping the capability (Goldilocks)

Mergers are not always goodExample: orders

Just because we can generalize between clinical orders and medical logistics orders, it does not follow that a large “orders” service covering the two is a good idea

Mechanics of IRD Methodology

Top-downArchitecture principlesManagement RepositoryGovernance

Bottom-upDefine InitiativesUnderstand business processesDefine service specifications and components

Examples of Architectural Principles

Understand information requirements firstEnterprise dataAuthoritative sourcesSeparation of presentation from logicSeparation of data from services

Integrated Management Repository

Enterprise-wide repository of:RequirementsInformation exchangesBusiness process models & use casesSystem architectureService specifications and contracts

Integration allows for traceability

Governance

The ability to make and enforce decisions at an enterprise level:

TechnologyService definitionsInformation semanticsStandardsEtc…

May take many forms (not mutually exclusive):CommunitiesArchitecture / Investment Review BoardsEtc…

Bottom-up analysis

Based on analysis of each initiativeMust have well-defined scope and purpose

Lack of defined scope is primary cause of long delays throughout the lifecycleLack of defined purpose is primary cause of solutions that “meet the requirements”but are not valuable to the users

Overarching Description Document

Other names:Vision DocumentConcept of Operations

Main Goal:Clearly define scope and purpose of initiative

It is the single most important IRD artifact

Overarching Description Document

Recommended sections:Problems

Do not say “lack of automation in…”

CustomersHigh level functional descriptionBusiness valueScope clarificationAssumptions/preconditionsConstraintsRisks

Informal architecture diagrams

System

TransactionRepository

Data Warehouse

Correspondence

Application data plus

attachments

enrollmentInformation

ServiceInformation

AcademicInstitution

Information

EligibleDependents

/End User

Applicants /Claimants

-facing UI

Manage claim status

Educational BenefitHistory

Staff-facing UI

SNAIL MAIL TOVETS/SCHOOLS

FinancialInformation

Choice TBD

Treasury

Choice TBD

SNAIL MAIL/

Manage claims

adjudication

Choice TBD

Reports

Rules Engine

Workflow Engine

Corporate DB

EnterpriseData

Attribute-basedSecurity

RulesEngine

FinancialTransactions

Attribute-based

Security/Access

EducationData Source(s)

DoDData Source(s)

EnterpriseData Source(s)

InternalV

antSelf Service

InstitutionSelf Service

WorkflowEngine Other Services

FinancialService

InstitutionsData Source(s)

Chapter 33Specific

SPAWAR

External

RulesEngine

FinancialTransactions

Attribute-based

Security/Access

EducationData Source(s)

ExternalData Source(s)

EnterpriseData Source(s)

InternalU

laimant

Self ServiceInstitution

Self Service

WorkflowEngine Other Services

FinancialService

InstitutionsData Source(s)

DatabaseSpecific

ExternalFET

BET WEAMSWAVE BDN

VAONCE

ECAPCorporate

DataWarehouse

PCGLVONAPP

Claimant

Institutions

Job Aids

Treasury

APP E APP DAPP H APP I

APP xAPP Y

DataWarehouse

APP CAPP G

Claimant

Institutions

Job Aids

Treasury

Behavioral models

Define the business processesMore detail – specify how the functional actors interact with technical actorsSeparate processes within separate spans of control via poolsShow explicit information exchanges via Message Flows

Map to an information modelExpand the graphical model with textual business rules

Preferred standard: Business Process Modeling Notation (www.bpmn.org)

Behavioral model notation

Structural Models

Show the parts of the solution and their interrelationshipsExplicitly separate the concepts of:

Abstract service or system function specificationsSoftware componentsNodes (physical servers and execution environments)

Preferred approach:Derived from CBDI Forum Service Architecture & Engineering meta model for SOAhttp://www.cbdiforum.com/public/meta_model_v2.php

Architectural layers

Help separate the partsRules determine the dependencies between members of each layerNo standard list of layers – decide based on your enterprise principlesExample list of layers:

ApplicationLegacy / Departmental systemsProcess ServicesEntity ServicesUtility ServicesData Sources

Specification diagrams

Show the different system functions across layers and their dependencies System functions:

Are equivalent to the technical actors in the behavioral modelsCan be applications, legacy systems, services, or data sources

Services are specified by operationsMessages (input/output)Pre- and post-conditionsService Level Agreements

Requires specification information beyond what is shown in the picture

Specification Diagram notation o b j e c t E R C C R S p e c i f i c a t i o n M o d l e

P ro c e ss C o n t ro l L a y e r

A p p l i c a t i o n

C o re S e rv i c e L a y e r

U t i l i t y L a y e r

D a t a L a y e r

A l e r t H a n d l e r M a n a g e r

+ C re a t e A l e r t ( )+ S e n d A l e r t ( )

P r o v i d e r D o c u m e n t V i e w e r

+ P r i n t ( )+ R e t r i e v e ( )+ S o r t ( )+ V i e w ()

S to r a g e C D R T r a d i n g P a r tn e r R e g i s tr y S to r a g e

9 9 7 P r o c e s s M a n a g e r

+ A c c e p t ( )+ C re a t e ( )+ R e j e c t ( )+ S t o re ( )

M a n u a l E x c e p t i o n H a n d l e r

+ R e so l v e E x c e p t i o n ( )+ R e t r i e v e E x c e p t i o n ( )+ S o r t E x c e p t i o n ( )

T r a d i n g P a r tn e r S e r v i c e M a n a g e r

+ A d d (B u si n e ss I n f o rm t i o n , I D ) : S t r i n g+ D e l e t e ( )+ R e t r i e v e ( )+ U p d a t e ( )+ V e r i f y ( )

X 1 2 M e s s a g e P r o c e s s o r

+ P ro c e ss X 1 2 ()

P r o v i d e r A l e r t M a n a g e r

+ R e t r i e v e A l e r t ( )

2 7 5 M e s s a g e P r o c e s s o r

+ P ro c e ss 2 7 5 ( )C D A R 2 M e s s a g e

M a n a g e r

+ P ro c e ss C D A R 2 ( )

C D R S to r a g e M a n a g e r

+ A d d ()+ A p p e n d ()+ R e t r i e v e ( )+ S t a t u s( )+ U p d a t e ( )

A u d i t F u n c t i o n M a n a g e r

N a m e : E R C C R S p e c i f i c a t i o n M o d l eA u t h o r : I R D F S W GV e rs i o n : 2 . 0C re a t e d : 3 / 5 / 2 0 0 8 9 : 0 8 : 3 7 P MU p d a t e d : 3 / 1 5 / 2 0 0 8 1 2 : 2 2 : 4 4 P M

C L R T r a n s m i t te r

X 1 2 E n v e l o p e M o d u l e

S to r a g e C D R (L o c a l )

Implementation diagrams

Show the specific software components that will implement the system functionsComponents:

May be decomposed into sub-componentsMay act as both service providers and service consumers

Implementation Diagram notation c m p E RCCR Im ple m e nta tion M ode l

L e g e n d

ALTHA Clin ic a l Da ta Re s pos itory (CDR)

S tor a geS to r a g eCDR

Com p one nt1

P ro v id e dIn te r fa ce

Com po ne nt2

Re q u i re dIn te r fa ce

Na m e : E RCCR Im p l e m e n ta t i o n M o d e lA u th o r: FS WGV e rsio n : 2 .0Cre a te d : 3 /5 /2 0 0 8 9 :2 9 :0 0 A MUp d a te d : 3 /2 4 /2 0 0 8 1 :0 3 :5 6 P M

Re q u i re d i n te rfa ce i s a se rvi ce co n su m e r

P ro v id e d i n te rfa ce i s a se rvi ce p ro vi d e r.

A l l Fu n cti o n w i l l ca l l M a n u a l P ro ce ss Ha n d le r i f n e ce ssa ry

T h i s co m p o n e n t e xp o se s a n i n te rfa ce fo r o th e r co m p o n e n ts to u se . T h e i n te rfa ce i s a co n tra ct to p ro vid e sp e ci fi c b e h a vio r to o th e r co m p o n e n ts th a t re q u i re th a t se rvi ce .

T h i s co m p o n e n t n e e d s th e se rvi ce s o f a n o th e r co m p o n e n t to p e rfo rm i ts re q u i re d wo rk.

AHLTA Us e r Inte rfa c e

P roiv i de r A le rt M od ule

Doc um e nt M odule

Ale rt Ha ndle r

A le rtHa n d le rM a n a g e r

AHLTA S tora ge M od ule

CDR S t o ra g eM a n a g e r

M HS G a te w a y (Agnos itic )

X 1 2 M e s s a ge P roc e s s or

X 1 2 E nv e lope M od ule

2 7 5 M odule2 7 5 M e ssa g eP ro ce sso r

9 9 7 M odule9 9 7 P ro ce ssM a n a g e r

CDA R2 M oduleCDA R2M e ssa g eM a n a g e r

Tra ding P a rtne r

Tra ding P a rtne r M a na ge rT ra d in g P a rtn e r

S e rv i ceM a n a g e r

Tra ding P a rtne r Re gis try

T ra d in gP a rtn e rRe g i stryS to ra g e

:M a nua l P ro c e s s Ha nd le r

M a n u a lE xce p ti o nHa n d le r

Audit M odule

A d u i t Fu n cti o nM a n a g e r

ALTHA Clin ic a l Da ta Re s pos itory (CDR)

S tora ge L oc a l

S to ra g e CDR(L o ca l )

Deployment Diagram

Show the nodes in which the software components will be deployedNodes can be:

Servers (in a particular location or virtualized in a cloud)Execution environments within servers

Examples: web servers, app servers, ESBs

Deployment diagram notation deployment ERCCR Deployment Model

Data Center

AHLTA Clinical Work Station

ALTHA Local Cache

Nam e: ERCCR Deplo yment ModelAuthor: FS WGVersion: 2.0Crea ted: 3/5/2008 9:52:13 AMUpda ted: 3/15/2008 12:14:19 PM

AHLTA Front End Processor

CLR S ender

MHS Gateway

AHLTA Superdome

:AHLTA User Inter face

:ALTHA Clinical Data Resposi tory

:Trading Partner

:Manua l Process Handler

:AHLTA Storage Module

:Audit Module

X12 Me ssage Proce ssor

:Alert Handler:ALTHA Clinical

Data Resposi tory (CDR) Storage Local

MTF LAN

PECC LAN

MTF LAN

Internet

Lessons learned from IRD

Don’t create a wall between requirements and designGet scope and purpose right earlyBusiness needs comes before service definitionDetermine how to make and enforce decisions

Questions

Wendell Ocasio, MDChief Medical Officerwendell.ocasio@agilex.com(703) 889-3899

Integrated Requirements Design - OMG · IRD recognizes that an integrated team must address these...

Documents

IRD-RI752 - DTIC

DANOBAT-OVERBECK Grinding Solutionspress.danobatgroup.com/.../danobat-overbeck-grinding-solutions-en... · IRD-200 IRD-400 IRD-600 Internal grinding diameter (max.) ... DANOBAT-OVERBECK

Lb Ird Structuring

Requirements for an Integrated UAS CNS Architecture · Requirements for an Integrated UAS CNS Architecture 2017 Integrated Communications Navigation and Surveillance (ICNS) ... Border

Enterprise Architecture IRD

Integrated Information Requirements and Costing Processes

NOAA/NWS Radar Functional Requirements€¦ · Radar Functional Requirements Integrated Working Team Concurrence The Radar Functional Requirements Integrated Working Team (IWT) membership

T.Sharon-A.Frank 1 Internet Resources Discovery (IRD) Intelligent IRD

Integrated Requirements Management

iRD Resolution Challenge

ProView integrated receiVer-decoders - NyeTec · PRoVieW iRd PoCKet Guide 6 PRoVieW iRd PoCKet Guide 7 ProView 8100 commercial integrated receiver-decoder High-quality, all-purpose

IRD Mechanalysis Limited

i 1 Integrated IRD IRD

Ird Mechanalysis

ProView integrated receiVer-decoders - NyeTec iRd PoCKet Guide 6 PRoVieW iRd PoCKet Guide 7 ProView 8100 commercial integrated receiver-decoder High-quality, all-purpose decoding and

Integrated Approval Requirements Fast Rail Project... · This Integrated Approval Requirements document provides an integrated process for the evaluation and approval of the planning,

Integrated Supplier Quality Requirements

IRD User Manual

TAX PROPOSALS - IRD

Integrated Unit Requirements