PlugIT results: Methods and experiences for application integration and production Juha Mykkänen HIS R & D Unit, University of Kuopio PlugIT seminar 30.

PlugIT results: Methods and experiences for application integration and production

Juha Mykkänen

HIS R & D Unit, University of Kuopio

PlugIT seminar

30 August 2004, Kuopio

In this presentation

• Challenges for application integration and production

• PlugIT application integration results (other than interfaces), some examples

• PlugIT application production and development results, some examples

• Experiences

• Where to find more information– marked with [ ]

Recognized challenges for application integration

• Heterogeneity on many levels: functionality, technology, architecture, standards, terminologies

• Software processes (research + standardization) do not consider existing applications, lack of implementations

• Integration solutions (industry) cheap and fast (once), expensive and laboursome (repeated), lack of systematic approach

• Different types of integration needs (usability, redundancy, interactivity, data transfer)

• Huge amount of local adaptation Integration specification methods, integration modelsPrecise definition, standardization, conformance testing

Recognized challenges for application production

• Lack of reuse

• Need for architectural vision

• Migration from legacy systems

• New technologies give new possibilitiesComponent-based software-engineering

• Quality problems in applicationsSoftware verification and validation, software

testing

• Gather experiences, apply several different methods, technologies and tools

Goals of method portfolios (in 2002)

• How to Plug IT (integration)– integrate application easier, faster, more efficiently

– define and test new approaches for integration

– support open interfaces with examples, methods and practices

– improve reuse of integration solutions

– increase use of standards and ease their introduction

• How to Do IT (production)– efficient production of new applications move towards

component- and service-based development

– support tool selections for application production and integration

– support software development process (engineering, implementation, testing, introduction, maintenance) with methods and tools

– identify and acknowledge integration goals in software production

Results: background studies etc. (integration AND production)

• Survey of current status of healthcare software development [15]

• Number of related studies– technologies [1]– tools [2]– testing methods and tools [various]– healthcare standards [various, 3, 16]

• Workshops– biannual seminar workshops (interface and method

development, training)– software testing day– BEA Systems, Microsoft, Oracle, PICNIC workshops

Results: Application Integration

Results: Integration methods

• Supporting assets for integration work (and interfaces) of PlugIT project

– multilateral collaboration for open integration specification [4]– integration specification process for integration projects in

general [4]– specification guidelines and examples [4]– evaluation and selection of standards [3]– PlugIT interface conformance testing (PlugIT-leima) [5]– reference implementations [5]– dynamic model for integration of business applications [15]

• Available for integration solution specification and evaluation of integration solutions

Goals of application integration• Process and workflow improvements, e.g. reduce

overlapping actions (re-keying, maintenance, development) and data

• Right information, right place ,right time – users / professionals + management (~EAI) PlugIT focus– partner organizations, regional systems (~B2B)– customers, patients (~B2C)

• Cost savings• Requirements for methods and solutions

– reduce local tailoring, repeatability, reuse– low introduction threshold for real-world integration projects– must fit into various organizations, application environments,

technologies– must find balance between: Local requirements + Standards +

Existing systems– emphasis on collaboration and open solutions

Phases in integration project

• Requirements-driven• Goal-oriented• Multilateral• Participants have

also ”other duties”• In PlugIT

– open specifications (design)

– local or product-specific implementation

[adapted from: Saranummi, Tolppanen: Järjestelmäintegraatio-projektin vaiheet, 2003.]

Project startupProject startup

Funcional designFuncional design

Technical designTechnical design

Application finalization/ implementation of

components

Application finalization/ implementation of

components

Implementation of process changes,

education

Implementation of process changes,

education

Deployment, introduction

Deployment, introduction

Project conclusionProject conclusion

Desig

n p

hase

Imp

lem

en

tati

on

p

hase

Const

ant

pro

cess

im

pro

vem

ent

Results: multilateral integration + specifications [4]

[Mykkänen, Tikkanen, Rannanheimo, Eerola, Korpela. Specification Levels and Collaborative Definition for the Integration of Health Information Systems. Proceedings of Medical Informatics Europe 2003].

Contex ts tudies , tec hnology

ev aluations

D e s crip tio no f cu rre n t s ta tu s

Pilo tingp la n

- l is t o f in i tia l in tegration needs-s pec i fic ation guidel ines-c ontent defin i tions for s pec i fic ations-ex am ple s olutions- tem plates- tools

-ex is ting in tegration s olutions-pi lo t s ys tem s-ex is ting tec hnologies and tools-ex is ting produc tion and qual i ty proc es s

Pro jectp la n

Hea lth se rv icep rov ide r (e .g .

ho sp ita l)

Mo de ra to r(Plu g IT p ro je ct)

Applic ationvendors

W ork proc essimprovement

Integrationneed

R equ iremen tsan a lys is

So lu tio nspecifica tio n

Imp leme n ta tion(p ilo t)

Ac c eptanc eDeploy mentAdaptation

1.INTEGRATIONREQUIREMENTS

2. PLATFORM-INDEPENDENT INTERFACE

SPECIFICATION3. TECHNOLOGY-

SPECIFIC INTERFACESPECIFICATION

4. IMPLEMENTATIONDESCRIPTION

s p e cifica tio nw o rk

s p e cifica tio nw o rk

im p le m e n ta tio nw o rk

-doc um entation-evaluation-integration proc es s developm ent-generaliz ation-m ethodvalidation

-heal th k now-how-pi lo t s ys tem s-ex is ting tec hnologies- func tional and qual i ty requi rem ents

i te ra tio n , n e w ve rs io n s

p ro d u ctim p le m e n ta tio n

O p en , reu sa b lein teg ra tion spe cifica tion s

lo ca l re q u ire m e n ts

Three types of participants –

solutionsmust benefit

all

Background, prioritization,

design – real needs

Specification of open and reusable

integration solutions

Benefits of implementation and

introduction

Results: how to define integration solutions? [4]

[Mykkänen, Porrasmaa, Rannanheimo, Korpela: A process for specifying integration for multi-tier applications in healthcare. Int J Med Inf 2003:70(2-3):173-182.]

1. W hat: Model theintegration domain

2. W here: Examineapplic ation arc hitec ture

3. How: Examinetec hnic al infrastruc ture

4. W hat: Identifyfunc tional interfac esand selec t their sty le

5. How: Chooseintegration tec hnology

7. How: Choose toolsand produc ts for

integration

6. How: Spec ifytec hnic al interfac es

-integration requirements-func tionality in existing applic ations

-applic ation arc hitec ture-applic ation infrastruc ture

-func tional integration points

-semantic mediation requirements

-func tional andsemantic standards

-tec hnic alstandards

-new methods, toolsand tec hnologies

- integration points inapplic ation arc hitec ture

-existing applic ationinfrastruc ture

-tec hnology -neutralfunc tional interfac es-semantic mediationfor interfac es

-new applic ation infrastruc ture- integration tec hnologies

-tec hnology -spec ificfunc tional interfac es

SP

EC

IFIC

AT

ION

ITE

RA

TIO

N, V

ALID

AT

ION

1.INTEGRATIONREQUIREMENTS

2. PLATFORM-INDEPENDENT INTERFACE

SPECIFICATION

3. TECHNOLOGY-SPECIFIC INTERFACE

SPECIFICATION

4. IMPLEMENTATIONDESCRIPTION

Requirements + process

improvement

Solutions in theparticipatingapplications

Healthcare-specificstandards and

models

Technology standards, tool

support

Incremental specification,examples and guidelines for phases,

aim at comprehensive and accurate solutions,but straightforward and repeatable

method

Results: Conformance testing in PlugIT [5]

Ac c e pte dD r aft

Im pl e m e nte d

S pe cif ica t io n

S o f twa re

(Avai l abl e )

a cce pta n ce

im ple m e n ta t io nim ple m e n ta t io nn e w v e rs io n

im ple m e n ta t io no f in te rfa ce

n e w v e rs io n

P ubl i cpu blica t io n

pu blica t io nn e w v e rs io n

im ple m e n ta t io n

C o nfo r m antt e s t in g ,in s pe ct io n

I n te rfa ceco n fo rm a n cece rt if ica teC o n fo rm a n ce t e s t in g a n d in s pe ct io n

Results: Conformance testing experiences [5]

• Developed and used conformance testing method, test cases and test tool with Context management case

• Test suite (test cases, reports, tools) for conformance testing

• Specifications (and their conformance clauses) not enough for certification

• Implementations required to validate specifications– reference implementations provided by PlugIT: also testing services

needed

• Testing gives valuable feedback – to software developers, quality improvement– to the specification process and standardization– interface testing is not certification, necessary but not sufficient for

interoperability

Dynamic model for the integration in enterprise service architecture [15]

• Dynamic model to improve interoperability of business applications in service-based architecture

• Businesses produce outcome products in collaborative networks

• Business process of an enterprise or an organisation is seen as set of services

• Business process consists of result of several services• Evolve software architecture with service paradigm to

improve integration of business applications• Goal is to provide an information system migration path for

enterprises to achieve business goals and competitiveness• Karhunen H: Dynaaminen malli liiketoimintasovellusten

integroimiseksi. PlugIT-hankkeen selvityksiä ja raportteja 15.

Experiences from multilateral integration definition and implementation [4]

• 9 teams, 14 integration targets, different types of needs• Specification and implementation of integration solutions

– Knowledge of integration domain necessary in solution specification– Most urgent integration needs in first iterations (minimum level), versioning– Specification and implementation as separate “projects”, especially in open integration

(implementation benefits, protection of competitive edge)– Controlled introduction of new solutions and technologies, migration for applications and

organizations, reference implementations• Standards and local solutions

– Standards, technologies and tools have effects on many levels, support and resources needed to evaluate solutions

– Top-down: healthcare-specific standards should be based on common technologies– Bottom-up: collection of solutions from existing applications requires, generalization (design

conventions, harmonization, standardization process)– Evaluation and certification is necessary, external certification authority– Flexibility using open technologies and separation of data from functionality

• Multilateral integration projects– Participants from different disciplines, combination of expertise, common language– Management-level commitment – requirements, resources, timeframe– Research group as a neutral moderator in specification, “consultant” in implementation– Local and product-specific aspects (introduction, maintenance, ownership) separated from open

specification

[Mykkänen, Porrasmaa, Korpela, Häkkinen, Toivanen, Tuomainen, Häyrinen, Rannanheimo. Integration Models in Health Information Systems: Experiences from the PlugIT project. Medinfo 2004].

Results: Software development process

Results: software development process

• Technology and tool studies [1,2]

• Pakkanen: case study of software development process [13]

– requirements engineering

– component-based software

– related to integration and testing in PlugIT

• Software testing methods and studies [various]– UML-based testing

– testing component-based systems

– how to test software

– control of testing processes

– testing tools, automatization

– defect management

Pakkanen: case study of software development methods [13]

• Piloting many different methods for software design and development: Case: user id management (university)

• Applied component-based software design process (Cheesman&Daniels)

• Requirements: combination of three methods, input for design• Design: defined service architecture, interfaces, components,

database• Implementation: implemented components using many tools and

technologies (J2EE, .NET), database migration example, integration example

• Testing: system and acceptance testing• Evaluated methods and technologies: main lesson:Adequate specifications before implementation provide savings in

implementation, deployment and maintenance – understanding does not necessarily require laborious analysis

Pakkanen publication:

Soveltamiskokemuksia ohjelmistotuotannon menetelmistä: vaatimusmäärittely, käyttöliittymäsuunnittelu, arkkitehtuurisuunnittelu, toteutus ja testaus. [13]

Chapter 2Requirementsengineering

Chapter 5Implementation of

componens

Maintenance Introduction

Chapter 4Architecture and

component design

Chapter 5Applicationassembly

Chapter 6Testing

Chapter 3User interface

design

1 Introduction

Pakkanen: implementation tools used [13]

= user interface= application logic

Results: software testing [various]

• Identified goal: improve methods and practices for software quality assurance and testing

• UML-based testing• Testing component-based systems• How to test software• Control of testing processes• Testing tools, automatization• Defect management• Software inspections

• http://www.cs.uku.fi/research/Teho/julkaisut.html

Testing results examples

• Applied software inspection method with Pakkanen [13]

– goal: to introduce and evaluate the inspection method– two inspection meetings were organized– results: increased quality of documentation: about 40

improvement suggestions/defects in one meeting

• Research of Test Process Management- Levels and methods of Software Testing

- Sample test documents with test cases

• More examples tomorrow– component-based testing– testing experiences of a Hospital Information System

Summary

• These results are not separated from requirements (previously today) or integration solutions (next)

• Application integration and development are more and more related

– 1/3 of system acquisition costs deals with integration

• Requirements and testing phases in software development (and integration) need more support

– methods, tools, relation to development

• Interdisciplinary research teams and multilateral collaboration to achieve concrete goals

– new ideas, useful results

– and new research topics..

References[1] Component and service technology families. Mykkänen,

Sormunen, Karvinen, Tikkanen, Päiväniemi. Studies and reports of the PlugIT project 1.

[2] Ohjelmistotuotannon välineselvitys - näkökulmia terveydenhuollon ohjelmistoyrityksen välinesalkun kokoamiseen. Karvinen, Riekkinen, Virkanen, Mykkänen, Sormunen, Porrasmaa, Tikkanen. PlugIT-hankkeen selvityksiä ja raportteja 2.

[3] Standardien arviointi ja valinta terveydenhuollon sovellusintegraatiossa. Mykkänen, Häyrinen, Savolainen, Porrasmaa. PlugIT-hankkeen selvityksiä ja raportteja 3.

[4] Terveydenhuollon sovellusintegraatioratkaisujen määrittely. Mykkänen, Porrasmaa, Rannanheimo, Tikkanen, Sormunen, Korpela, Häyrinen, Eerola, Häkkinen, Toivanen. PlugIT-hankkeen selvityksiä ja raportteja 4.

[5] Avointen integrointiratkaisujen hyödyntäminen, toteuttaminen ja testaus. Mykkänen, Toroi, Karhunen, Virkanen, Mäki, Sormunen, Rannanheimo, Tuomainen. PlugIT-hankkeen selvityksiä ja raportteja 5.

References[13] Soveltamiskokemuksia ohjelmistotuotannon menetelmistä:

vaatimusmäärittely, käyttöliittymäsuunnittelu, arkkitehtuurisuunnittelu, toteutus ja testaus. Riekkinen, Karvinen, Virkanen, Reponen, Ikävalko, Silvennoinen, Savolainen, Porrasmaa, Laitinen. PlugIT-hankkeen selvityksiä ja raportteja 13.

[14] Ohjelmistotuotannon nykytilaselvitys 2003 - kohderyhmänä terveydenhuollon ohjelmistoyritykset ja organisaatiot. Porali, Riekkinen, Pohjolainen, Mykkänen, Toroi, Kärkkäinen, Eerola. PlugIT-hankkeen selvityksiä ja raportteja 14.

[15] Dynaaminen malli liiketoimintasovellusten integroimiseksi. Karhunen. PlugIT-hankkeen selvityksiä ja raportteja 15.

[16] HIPAA-lainsäädäntö terveystietojen sähköisen käsittelyn näkökuömasta - katsaus USA:n terveyslakiin. Reponen. PlugIT-hankkeen selvityksiä ja raportteja 16.

[various] See: http://www.plugit.fi/julkaisut/