• 290 likes • 431 Views
BIS 210 – Enterprise Systems. Gio Wiederhold CS, EE, Medicine March 2001 [SPWF: Medical Informatics , chap.5]. Outline. Systems and Components Requirements Buy or Build Software Engineering Trends. Systems and Components. System: a collection of components Components: Hardware
E N D
BIS 210 – Enterprise Systems Gio Wiederhold CS, EE, Medicine March 2001 [SPWF:Medical Informatics, chap.5] Gio: BIS 210ES
Outline • Systems and Components • Requirements • Buy or Build • Software Engineering • Trends Gio: BIS 210ES
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? Gio: BIS 210ES
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 Gio: BIS 210ES
One Application in the World Transform Data into Information Match Costumer Model Hierarchical to Resource Model General network (and maintain models) Gio: BIS 210ES
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) Gio: BIS 210ES
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] Gio: BIS 210ES
System Architecture = Connections among Components • Issues • Performance • Reliability • Maintainability • Factors • Size • Number of components Gio: BIS 210ES
Architectural Models • Central • ok for single objective • Distributed • owned subsystems • autonomous services • Transaction • small services, isolated • database provides all communication • often 3-layer Gio: BIS 210ES
users at workstations value-added services hidden data and simulation resources Transforming Data to Information Application Layer Mediation Layer Foundation Layer Gio: BIS 210ES
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 ? Gio: BIS 210ES
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 Gio: BIS 210ES
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] Gio: BIS 210ES
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 ? Gio: BIS 210ES
Decision can differ by layer • Programming Elements used Products • who difficulty revenue potential 4 Service (GUI) Components Services customer low ? v.high: browsers 3 Application Lang. Capabilities Components domain exp. moderate high 2 Platform (API) Primitives Capabilities funct.progr. high moderate 1 Native Generic SW Primitives syst.progr. v.high low Gio: BIS 210ES
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 Gio: BIS 210ES
Life Dep MC 13 ? 12 11 years10 90 9 maint. cost/y % 80 8 Life of asset Depreciation Mainte- nance Cost 70 7 60 6 depr./y % Life Dep MC 50 5 40 4 long lifetime low depreciation @ 1 / lifetime high maintenance cost 30 3 20 2 10 1 0 automobile software hardware Is the waterfall, i.e., engineering model valid? • Software differs from hardware Gio: BIS 210ES
13 12 11 years 10 9 8 7 6 Life Dep MC 5 4 3 2 1 Maintenance Strategy Life Dep MC Good BENEFIT/COST wrt customer • Benefit isrelevant 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% 90 80 70 60 50 40 30 20 10 0 software hardware Gio: BIS 210ES
Composition of modules • Completeness Multiple vendors • New & modern ? Risk • Legacy • Interface specifications • Formats • Terminology • Ontologies • Effect on performance Gio: BIS 210ES
History: Logical Progression 1945 1955 1960 1975 1990 • 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 Gio: BIS 210ES
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) Gio: BIS 210ES
Evidence • CURRENT ARGUMENTS • Component architecture • Description • Asynchrony • Inheritance • CORBA vs XML vs UDDI vs ... PAST ARGUMENTS • Hardware architecture Number of bits/word Number of registers Size of address field • DEC vs IBM vs CDC vs Mac ARGUING implies VALUE SHIFT from Hardware to Software Componentry Gio: BIS 210ES
Workforce reallocation Integration Coding 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 . . . Gio: BIS 210ES
Growth through Reuse New Applications Prior & Revised Mediators Extended Data Resources Gio: BIS 210ES
Incremental Maintenance 1. New/Revised application needs more data 2. Mediator isolates other applications 3. New application checks out data and function 4. Other applications can join when feasible versus 1. New/Revised application needs more data 2. Determine affected applications 3. Change affected codes, create test scaffolding 4. Plan for system-wide release at three-month cycle 5. Batch all other changes for that cycle 6. Perform critical, risky release of batch Gio: BIS 210ES
New Metrics • Productivity Lines of Code --> Time to Asssemble a Product • Time to Update Product Several years --> 3/6 months • Satisfaction of System Administrator --> Customer • -- missing: • Performance based on Detailed data --> Component / Service specs Gio: BIS 210ES
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 ? Economics Gio: BIS 210ES
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 Gio: BIS 210ES
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. Gio: BIS 210ES