integrated requirements design - omg · ird recognizes that an integrated team must address these...

© Agilex Technologies, Inc. www.agilex.com

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

XYZ

DB A

DB B

Data Warehouse

DB X

Correspondence

Application data plus

attachments

enrollmentInformation

ServiceInformation

AcademicInstitution

Information

EligibleDependents

/End User

Applicants /Claimants

APP B

-facing UI

Manage claim status

DB C

Educational BenefitHistory

Staff-facing UI

SNAIL MAIL TOVETS/SCHOOLS

FinancialInformation

Choice TBD

Treasury


Choice TBD


Choice TBD

SNAIL MAIL/

Manage claims

adjudication

Choice TBD

Other

Reports

Rules Engine

Workflow Engine

Staff

Corporate DB

EnterpriseData

Attribute-basedSecurity

DB F

RulesEngine

FinancialTransactions

Attribute-based

Security/Access

EducationData Source(s)

DoDData Source(s)

EnterpriseData Source(s)

InternalV

A UI

Claim

antSelf Service

InstitutionSelf Service

WorkflowEngine Other Services

…

FinancialService

InstitutionsData Source(s)

Chapter 33Specific

SPAWAR

VA

External

RulesEngine

FinancialTransactions

Attribute-based

Security/Access

EducationData Source(s)

ExternalData Source(s)

EnterpriseData Source(s)

InternalU

IC

laimant

Self ServiceInstitution

Self Service

WorkflowEngine Other Services

…

FinancialService

InstitutionsData Source(s)

DatabaseSpecific

ORG A

ORG B

ExternalFET

TIMS

BET WEAMSWAVE BDN

VAONCE

VIS

ECAPCorporate

VADIR

DataWarehouse

PCGLVONAPP

Claimant

UI

Institutions

Job Aids

Treasury

APP H

APP F

APP E APP DAPP H APP I

APP J

APP a

APP xAPP Y

APP B

DataWarehouse

APP CAPP G

Claimant

A

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

MCSC

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

MTF

AHLTA Front End Processor

CLR S ender

MHS Gateway

AHLTA Superdome

:AHLTA User Inter face

:ALTHA Clinical Data Resposi tory

(CDR)

: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

WAN

PECC LAN

MTF LAN

WAN

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 [email protected](703) 889-3899

integrated requirements design - omg · ird recognizes that an integrated team must address these...

Documents