1 / 29

BIS 210 – Enterprise Systems

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

jacob-levine
Download Presentation

BIS 210 – Enterprise Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. BIS 210 – Enterprise Systems Gio Wiederhold CS, EE, Medicine March 2001 [SPWF:Medical Informatics, chap.5] Gio: BIS 210ES

  2. Outline • Systems and Components • Requirements • Buy or Build • Software Engineering • Trends Gio: BIS 210ES

  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? Gio: BIS 210ES

  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 Gio: BIS 210ES

  5. One Application in the World Transform Data into Information Match Costumer Model Hierarchical to Resource Model General network (and maintain models) Gio: BIS 210ES

  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) Gio: BIS 210ES

  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] Gio: BIS 210ES

  8. System Architecture = Connections among Components • Issues • Performance • Reliability • Maintainability • Factors • Size • Number of components Gio: BIS 210ES

  9. 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

  10. users at workstations value-added services hidden data and simulation resources Transforming Data to Information Application Layer Mediation Layer Foundation Layer Gio: BIS 210ES

  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 ? Gio: BIS 210ES

  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 Gio: BIS 210ES

  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] Gio: BIS 210ES

  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 ? Gio: BIS 210ES

  15. 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

  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 Gio: BIS 210ES

  17. 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

  18. 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

  19. Composition of modules • Completeness Multiple vendors • New & modern ? Risk • Legacy • Interface specifications • Formats • Terminology • Ontologies • Effect on performance Gio: BIS 210ES

  20. 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

  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) Gio: BIS 210ES

  22. 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

  23. 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

  24. Growth through Reuse New Applications Prior & Revised Mediators Extended Data Resources Gio: BIS 210ES

  25. 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

  26. 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

  27. 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

  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 Gio: BIS 210ES

  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. Gio: BIS 210ES

More Related