04/19/23 Gio: BIS 210ES Bis210-1

BIS 210 – Enterprise Systems

Gio WiederholdCS, EE, Medicine

March 2001

[SPWF:Medical Informatics, chap.5]

04/19/23 Gio: BIS 210ES Bis210-2

Outline

• Systems and Components

• Requirements

• Buy or Build

• Software Engineering

• Trends

04/19/23 Gio: BIS 210ES Bis210-3

Systems and Components

System: a collection of components• Components:

– Hardware• Processing transformation• Input – Output to people/paper• Communication among components• Storage temporal communication

– Programs to drive the hardware

What's different when writing systems from writing programs?

04/19/23 Gio: BIS 210ES Bis210-4

Large systems

• Many communication paths– People as sources and sinks– Components as intermediate nodes

• Many objectives– Solution workflow is hierarchical

• Conflicting decompositions– Interactions form a network

• conflicts with simple design models

04/19/23 Gio: BIS 210ES Bis210-5

One Application in the World

Transform Data into Information

Match

Costumer Model

Hierarchical

to

Resource Model

General network

(and maintain models)

04/19/23 Gio: BIS 210ES Bis210-6

Hospital Information Systems

Many Functions / many types of users• Patient admission, transfer, discharge• Order entry & distribution to subsystems

• Pharmacy, Lab, Radiology, Supplies, ...• Record of actions performed• Triggering of follow-ups needed• Billing • Inpatient Medical Records• Surveillance (iatrogenic diseases)

04/19/23 Gio: BIS 210ES Bis210-7

Ambulatory Care

Multiple patient contact points • Problem tracking why more important for outpatients?

• Care tracking: medications, ...., outcomes• Scheduling• Long-term medical records• . . . many more

This is a wonderful list, and there is nothing more wonderful than a list, and we could go on and on adding things, but now we have to go to do real (work). [Umberto Ecco, The Name of the Rose]

04/19/23 Gio: BIS 210ES Bis210-8

System Architecture

= Connections among Components

• Issues– Performance– Reliability– Maintainability

• Factors– Size– Number of components

04/19/23 Gio: BIS 210ES Bis210-9

Architectural Models

• Central– ok for single objective

• Distributed– owned subsystems– autonomous services

• Transaction– small services, isolated– database provides all communication– often 3-layer

04/19/23 Gio: BIS 210ES Bis210-10

Transforming Data to Information

Application Layer

Mediation Layer

Foundation Layer

hidden data and simulation resources

value-added services

users at workstations

04/19/23 Gio: BIS 210ES Bis210-11

Buy or Build ? time is an issue

• Build (to get exactly the system you want tomorrow)– Specification requires experience– Building takes personnel and time (3 years?)– Long-term commitment to staff

• Buy (and adapt your operations to its capabilities)– Specifications are based on other prior experiences– Not all functions may be available from one source– If it's complete today it's likely obsolete today

• Mixed (compose from best available modular pieces)– Ideal ? Faster (1 year?) – Which of many standards ?

04/19/23 Gio: BIS 210ES Bis210-12

Build: Software Engineering

Where to start ? Where to go to ?• Waterfall model Traditional Engineering

– Requirements specifications design code test deliver maintain?

• Rapid Prototyping Iterative ~3-month cycle

– Demo:build {code test deliver fix}

Prototype 1 ... n {"}, Operational n+1 ... m {"}

• Watersluice Priority-based [Burback]

– Most risky module first ... design assess ...

– Scaffolding

04/19/23 Gio: BIS 210ES Bis210-13

Lifetime costs of SW systems

• Requirements 3 %

• Specifications 3 %

• Design 5 %

• Code 5 %

• Module Test 8 %

• Integration test 7 %• Maintenance 67 % much more later

[Meiler Page-Jones: The Practical Guide to Structured Systems Design, Prentice Hall, 1988]

04/19/23 Gio: BIS 210ES Bis210-14

Design Defects in Applications

• Requirements 29.1 %• Functionality 14.2 % (when delivered)• User interface 22.0 %• Data definition 8.7 %• Error checking 5.3 %• Data handling 10.2 %• Computation 5.5 %• Logic Implementation 3.9 %

[Robert Grady: Practical SW Metrics for Program Management and Process Improvement, Prentice Hall,1992]

Why ?

04/19/23 Gio: BIS 210ES Bis210-15

Decision can differ by layer

– Programming Elements used Products• who difficulty revenue

potential

4 Service (GUI) Components Services customer low ? v.high: browsers3 Application Lang. Capabilities Components domain exp. moderate high2 Platform (API) Primitives Capabilities funct.progr. high moderate1 Native Generic SW Primitives syst.progr. v.high low

04/19/23 Gio: BIS 210ES Bis210-16

Maintenance

• Definition: Unscheduled tasks to fix• errors in software (often induced by growth in scope)

• adapt to externally imposed changes (tax laws, regulations, interfaces, customer expectations, …)

• adapt to internally imposed changes (mergers, corporate reorganization, new product lines, ...)

• Crucial leverage:– 60-90% of system costs are SW-maintenance

• If maintenance costs can decrease 25% we double our capability to develop innovative products

• If maintenance costs increase by 25% we loose any capability for innovation

– Affected by paradigm change

04/19/23 Gio: BIS 210ES Bis210-17

Is the waterfall, i.e., engineering model valid?

• Software differs from hardware

00

4040

2020

7070

3030

1010

8080

9090

6060

5050

44

yearsyears 1010

1212

22

77

33

11

88

99

66

55

1313

1111

automobile software hardwareautomobile software hardware

Life of asset Depreciation Mainte- nance Cost

Life Dep MC

??

Life Dep MC

long lifetimelong lifetime

low depreciation 1 / lifetime

high maintenance cost

maint.cost/y %

depr./y %

04/19/23 Gio: BIS 210ES Bis210-18

Maintenance Strategy

Good BENEFIT/COSTwrt customer

• Benefit is relevant information,requires constant updating

• Avoid cost of change,don’t change system, interfaces

We expect SW to be adaptable– enables change, growth– long lifetimes– regular, high maintenance

• Cost– initial– maintenance (60-90% for SW)

100%100%

00

4040

2020

7070

3030

1010

8080

9090

6060

5050

44

years years 1010

1212

22

77

33

11

8899

66

55

1313

1111

software hardwaresoftware hardware

Life Dep MC

??

Life Dep MC

04/19/23 Gio: BIS 210ES Bis210-19

Composition of modules

• Completeness Multiple vendors – New & modern ? Risk– Legacy

• Interface specifications• Formats • Terminology

– Ontologies

– Effect on performance

04/19/23 Gio: BIS 210ES Bis210-20

1945

1955

1960

1975

1990

1945

1955

1960

1975

1990

History: Logical Progression

• Machine language– generation of basic code sequences

• Assembly language– shared code & shared data in memory

• Compiled languages– standardized code units with parameters

• Database services– control ceded to the DB administrator

• Object Libraries for specific Domains– domains & solution structure predefined

Loss of autonomy & Cede control Increase of scale & Benefit from work of others

04/19/23 Gio: BIS 210ES Bis210-21

Software Paradigm Shift

• Re-allocation of autonomy is gradual, invisible

• In the aggregate, over time, affects – Technology Paradigm– Business Practices– Educational needs

• Hypothesis:

We have to explicitly change from

a subroutine mentality (programmer control) to

a service mentality (cooperation & mediation)

04/19/23 Gio: BIS 210ES Bis210-22

Evidence

PAST ARGUMENTS• Hardware architecture

Number of bits/word

Number of registers

Size of address field

• DEC vs IBM vs CDC vs Mac

CURRENT ARGUMENTS

• Component architecture

Description

Asynchrony

Inheritance

• CORBA vs XML vs UDDI vs ...

ARGUING implies VALUE

SHIFT from Hardware to

Software Componentry

04/19/23 Gio: BIS 210ES Bis210-23

Workforce reallocation

Integration originally performed for large systems • by system integration companies:

– Honeywell, IBM federal, Fujitsu, Lockheed, SAIC, Andersen ...

Integration now performed for most systems• by application clients and services:

– too many to name, including you . . .

Coding

Integration

04/19/23 Gio: BIS 210ES Bis210-24

Growth through Reuse

New Applications

Prior & Revised Mediators

Extended Data Resources

04/19/23 Gio: BIS 210ES Bis210-25

Incremental Maintenance

1. New/Revised application needs more data2. Mediator isolates other applications3. New application checks out data and function4. Other applications can join when feasibleversus 1. New/Revised application needs more data2. Determine affected applications 3. Change affected codes, create test scaffolding 4. Plan for system-wide release at three-month cycle5. Batch all other changes for that cycle

6. Perform critical, risky release of batch

04/19/23 Gio: BIS 210ES Bis210-26

New Metrics

• ProductivityLines of Code --> Time to Asssemble a Product

• Time to Update ProductSeveral years --> 3/6 months

• Satisfaction ofSystem Administrator --> Customer– -- missing:

• Performance based on Detailed data --> Component / Service specs

04/19/23 Gio: BIS 210ES Bis210-27

Economics

Programming• Train programmers• Detailed system analysis• Detail coding and debug• Integration• Revisit specifications• Satisfy all requirements• Maintain software with

growth and as requirements change

Composition• Purchase of base• Learning its conventions• Adapting to them• Misunderstanding• Supplier errors• Multi-base mismatch• Unsatisfied requirements• Obtain updates• Participate in base

growth

Long term costs > < Dependence, Risk Development Speed ?

04/19/23 Gio: BIS 210ES Bis210-28

Software as a Service

Service Paradigm• Customer views understood within server domain• Processes use stored and maintained knowledge• Processing adds value to data objects accessed• Payment received for services and results

04/19/23 Gio: BIS 210ES Bis210-29

Summary

• No single path to Nirvana

• Large failure rate

• No large systems will be built anymore from the ground up

• Growth potential in Services

• Healthcare uses often very old systems– hard to show benefits of change– costs hard to justify versus benefits/income.