ITKE54 Kehittämismenetelmät ja arkkitehtuurit liiketoiminnassa

Transkriptio

1 ITKE54 Kehittämismenetelmät ja arkkitehtuurit liiketoiminnassa Jukka Heikkilä Ville Seppänen Elektroninen liiketoiminta Tietojenkäsittelytieteiden laitos Informaatioteknologian tiedekunta Jyväskylän yliopisto tel:

2 And the suggested solution is: Business Models, Architectures and Platforms Business Model makes the relationship between constituents of business visible (see e.g. Osterwalder & Pigneur, 2001) -> ITKE50 The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them. (Bass, Clements, and Kazman) But an architecture for ebusiness -system is a subset, or superset of offerings services applications 2

3 Viitekehyksiä prosessien ja komponenttien yhteensovittamiseen 3

4 Yleise mmin: ISAframe work: Zachman,

5 Complete ISA: Sowa & Zachman, 1992 Three additional dimensions: People Agent Work Time Time Cycle Motivation Ends Means 5

6 Compl ete ISA (Sowa & Zachman, 1992) 6

7 Extension to ISA: Information FrameWork (IFW) Change of focus: from systems to corporatewide information to reusable industry-specific components from systems development to information utilization from rigid to flexible functionality, faceting i.e., multiple views Change of metaphor: from construction of buildings to city planning Used originally for Information management in financial services in Europe 7

8 Component based architecture Architecture is the foundation for the swproduct line. Architecture forms the organizational plan for component development. Architecture is the root of system qualities. Architecture ensures that variability across products can be accomplished by changes confined to one or a select set of components. 8

9 Komponentit arkkitehtuurissa (Häkkinen, 2000) There is a gap in here! Tieto Toiminto Verkko Aika Ihmiset Motivaatio Soveltamisala Yritysmalli Järjestelmämalli Teknologia -malli Komponentit Toimiva järjestelmä Ohjelmistoarkkitehtuuri Sovelluskehys & k i lli komponenttimalli OHJELMISTO- KOMPONENTTI 9

10 Komponenttityypit (Häkkinen & Peltola, 1998) Räätälöidyn komponentin: tietty toiminta tietyssä ympäristössä räätälöitynä valmistajalta Valmiskomponentti on ohjelmistojen kehittäjille uudelleenkäytettäväksi suunnattu komponenttituote. Standardoitu rajapinta määrää käyttöympäristön. Lisäkekomponentti on täydentävä, loppukäyttäjille suunnattu valmiskomponentti (esim. Plug-init) Sovitekomponenttia käytetään, jos valmiskomponentti ei täytä kaikkia ohjelmistonkehittäjän asettamia vaatimuksia, niin se voidaan sovittaa näihin erityistarpeisiin. Muutokset tekee komponentin valmistaja (esim. Toimialakohtainen adapteri) 10

11 Sovitekomponentti Helppoa, komponentti sovitettu asiakkaan tarpeisiin Helppoa, sillä komponentti toteutettu sopimaan asiakkaan ympäristöön Voidaan määrittää itse laatukriteerit Toteutus suhteellisen edullinen, käyttö ja ylläpito edullista Komponenttityypit soveltajan näkökulmasta (Häkkinen, 1999) Ongelma Valmiskomponentti Räätälöity komponentti Komponentin Perustuu toimittajan Helppoa, käyttökelpoisuuden tarjoamaan komponentti arviointi dokumentaatioon toimitettu asiakkaan Komponentin käyttöönotto Komponentin laatu Komponentin kustannukset (toteutus, käyttö ja ylläpito) Juridiset seikat ISA-mallin Motivaatio-sarake Perustuu toimittajan tarjoamaan dokumentaatioon Toimittaja takaa, mutta varmistettava itse Kaikki kustannukset edullisia verrattuina perinteiseen ohjelmistoon ja muihin komponenttityyppeihin Toimittajalla avainasema sopimusten määrittämisessä Asiakkaan varmistettava itse dokumentaation avulla, hyvin hankalaa tarpeisiin Helppoa, sillä komponentti toteutettu sopimaan asiakkaan ympäristöön Voidaan määrittää itse laatukriteerit Toteutus valmiskomponenttia ja perinteistä ohjelmistoa monta kertaa kalliimpi, käyttö ja ylläpito edullista Asiakas avainasemassa sopimuksen määrittämisessä Asiakas voi vaikuttaa kehityksen aikana, hankalaa Toimittaja ja asiakas neuvotteluissa tasavahvoja Asiakas voi vaikuttaa kehityksen aikana, hankalaa 11

12 Architecture functions (Youngs et al., 1999) Breaking down the complexity of the IT system so that developers can analyze and design components that are relatively isolated from one another Analyzing the functionality so that required technical components (or infrastructure) can be identified Assisting in the analysis of service-level requirements so that the means of delivering them can be designed Providing a basis for the specification of the physical computer systems on which the IT system will execute and the mapping of components onto these computer systems 12

13 Integrated Architecture Fwk (Maes et al p. 11; c.f. Mustikkamaa 2001) Business As Is Vision, Strategy Architectural design Development, Change Operation, maintenance Business Vision Integrated Architecture Framework Business and IT Transformation IT Enabled Enterprise IT Vision IT As Is 13

14 1) Terminal domain Mobile phones Computers PDA s 2) Network domain Telecom Network Mobile Network IP Network Service Gateways Produc t 3) Enabling technology/ platform domain Application Management User, Service & Security Management System Management Product Platform Content & Data Management archite cture 4) Application domain Self-care concept Trading concept Application Gateways Communi cation concept Business support concept Entertain ment concept Informati on concept bluepri nt (Mustikkamaa, 2001) 5) Content domain 6) Business domain Content 1 Content provider 1 Content Gateways Content 2 Content 3 Content 4 Content 5 Content N Content provider 2 Content provider 3 Content provider 4 Content provider 5 Content provider 14 N

15 1) Terminal domain Mobile phones Computers PDA s 2) Network domain Telecom Network Mobile Network IP Network IS archi- 3) Enabling Technology/ platform domain Service Gateways User, Service & Security Management Application Management System Management Content & Data Management tecture Information Systems Platform blue- 4) Application domain Management applications Product Development applications Product Delivery & Development applications Sales & Marketing applications Customer Care a plications Customer Data & Event Management Billing applications print (Mustikkamaa, 2001) 5) Content domain Product Data Management Business Data Management Content Gateways Operation Data Management Business data Product data Operation & manitenance data Customer data Event data 6) Business domain Management process Product Delivery Management process Delivery and Production process Sales & Marketing process Customer Care process Billing process 15

16 Verkostossa Virtual Enterprise Reference Architectures Basedon GERAM (Generic Enterprise Architecture and Methodology) by IFAC/IFIP Task Force on architectures for Enterprise Integration ISO 15704, ISO

17 VERAM (Zwegers et al., ) Layers of VERAM Each layer build upon the previous one(s) Virtual Enterprise Concept VERA Virtual Enterprise Reference Architecture VERAM Components Contingency factors Roles, Legal aspects, Social aspects, Business environment, Standards, Technologies General level Re-usable components, models & knowledge for VEs Modelling Languages Modelling Methodology Modelling Modelling Tools VE Reference Models VE configuration tools Enterprise applications & interfaces Applications & infrastructures VE infrastructure modules Methodology Guidelines Particular level Specific components, models & knowledge of a particular VE VE implementation VE Models Operational ICT environment for VE VE in business operation 17

18 Do we need the intermediate stage? Why not just XP or RAD in an Agile way? One-of-a-kind project or multiple similar products/projects? Ready made, tested templates and components Multiple interconnections Technical conformity ICT stdsetc Functional conformity I/O, sequence of processes, delays/lead times Procedural conformity Abstraction Quality stds and procedures, information sharing and disclosure 18

19 Kuvaukset Asiakkaat mukaan: Psykologiset vaatimukset tarkkuuden asemesta Yksinkertaisuus Yleisyys Kommunikaation tuki Visualisointi Tapahtuman vaatimukset Event-driven - mikä on event? Koordinaatio Poikkeukset Eri asteinen varmuus - miten ottaa huomioon? 19

20 Example (Tolvanen, 2003): JustInsurances.com Domain Idea Solve problem in domain terms Map to code, implement Map to code, implement Map to UML Damage! Risk factor! Liability! Bonus! Generate, Add bodies UML Model Use case Activity Stereotype Class Attribute Java Assembler inner class? Session Bean? static final? integer? Finished Product 20

21 What is domain-specific modelling (Tolvanen, 2003) Captures domain knowledge (as opposed to code) Uses domain abstractions Applies domain concepts and rules as modeling constructs Allows developers to design products with domain terms Apply familiar terminology Solve the RIGHT problems! Solve problems only ONCE! 21

22 Use Cases: Utilizing the structure Tähän päähän tullee segmentoinnin seurauksena hienosyisempiä asiakasryhmiä -eli enemmän Use-caseja Transfer between accounts Deposit Entity Boundary Control 22

23 Use Case: Collaboration diagram (Booch et al., 1998) 23

24 Use-caseista analyysiin Asiakkaan kieli Ulkoinen, hyödyntävä Use-cases Käyttäjän ja kehittäjän välinen sopimus, mitä järjestelmä tekee ja mitä ei Redundantti ja inkonsistentti Suunnittelijan kieli Sisäinen, konstruoiva Olioluokat, komponentit Ymmärryksen luominen Konsistentti Rakenteen ja toiminnan yhdistäminen Use-case toteutuksin 24

25 Ongelma jää: Paljon pelissä hajautuneen transaktion hallinnassa: Pystytäänkö implementoimaan nopeasti ja tehokkaasti mitä tehdä itse, mitä ostaa ulkoa? millä ansaintalogiikalla pitääkösopimus Välittyykö asiakkaan prosessi suunnitelmaan? Mistä tietoa asiakkaan ongelmasta/sykleistä sitoumukset Käsikirjoituksen puutteet kauppapaikat, huutokaupat, pörssit, yhteisostaminen Miten hallita transaktio? eri osapuolten järjestelmien integroiminen - utopiaako? 25

26 Sama lentovarauksesta 1/2 (Daum & Scheller, 2000) 26

27 Sama lentovarauksesta 2/2 (Daum & Scheller, 2000) 27

28 Summary: long transaction (Software AG, 1999) 28

29 Exceptions (Software AG, 1999) Exception handling definitions are used to indicate how to proceed if an exception is thrown by a business task during execution of the task. The following actions can be specified: the exception is to be ignored the business task is to be repeated the long transaction is to be set to a different state ONLY after the actions can the transaction be recorded in a database (ACID) 29

30 Asynkroniset samanaikaiset prosessit (Zisman, 1978) Kontrollirakenteen tarve koordinaatiota varten: esimerkkinä tieteellisen artikkelin referointi toimijat/roolit: päätoimittaja, toimittaja, arvioija, kirjoittaja, sihteeri (sihteeri kontrolloi :-) use case -ongelma: liian monia vaiheita ja alisysteemejä? Peruskäsitteet: Solmu (node): paikka (place: O) tai siirtymä (transition: ) Paikoissa tokenit (token: ) Paikka voi olla syötepaikka (input p.) tai tulospaikka (output p.) Jos kaikissa syötepaikoissa on token, siirtymä on aktiivinen Aktiivinen siirtymä voi kytkeä (fire) Kytkeytyminen siirtää syötepaikkojen tokenit tulospaikkoihin yksi token voi kytkeä vain yhden siirtymän 30

31 Asynkroniset samanaikaiset prosessit: esim. Systeemin tilat, sihteeri koordinaattorina: 1) odottaa artikkelin saapumista ack kirjoittajalle, toimittajalle pyyntö arvioijista 2) odottaa toimittajan nimittävän arvioijat +2vko; muistuta. Lähetä suostumuspyynnöt arvioijille 3) odottaa arvioijan suostumusta +2vko; muistuta. Lähetä artikkeli tai pyydä uutta arvioijaa 4) odottaa arvioijan raporttia +1kk; muistuta. Ack toimittajalle yksittäisestä raportista 5) odottaa kaikkien raporttien saapumista Lähetä toimittajalle ja pyydä päätös 6) odottaa toimittajan päätöstä +2vko; muistuta. Ack kirjoittajaa ja päätoimittajaa päätöksestä 31

32 Esim. jatkuu: Kaksi alisysteemiä - toimittaja T1 T2 T3 T4 Toimintojen verkko T6 T5 T7 T1: Artikkeli saapuu => ack kirjoittajalle, toimittajalta arvioijat T2: Arvioijalista => käynnistä arviointiprosessi (T8) T3: Kaikki arvioijaraportit => pyydä toimittajan päätös T4: Toimittajan päätös => dokumentit kirjoittajalle, päätoim. T5: Kirjoittaja vetäytyy => lopetusdokumentointi T6: +2vko => muistuta toimittajaa T7: - - => - - Tuotanto- säännöt 32

33 T15 T14 T13 Esim. jatkuu: Kaksi alisysteemiä: arvioija T8 T9 T10 T12 T11 T8: Käynnistyy arviojien nimityksen jälkeen => arv.pyyntö 2vkoa T9: Arvioijan suostumus => 1kk aikaa T10: Arviointiraportti saapuu => kiitä arvioinnista T11: +1kk => muistuta arvioijaa T12: +2vkoa => kysy uudelleen T13: Arvioija ei suostu => pyydä toimittajalta toinen arvioija T14: +2vko => muistuta toimittajaa uudesta arvioijasta T15: Toimittajalta uusi arvioija => arv.pyyntö 2vkoa 33

34 A metamodel example for networked environment (Jonkers et al., 2004) 34