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: Tasapainoilua strategian, prosessin ja komponenttien välillä (Allen & Frost, 1998) 2 1

2 And the Solution is (?): Business Models, Architectures (and Platforms) Business Model makes the relationship between constituents of business visible (see e.g. Osterwalder & Pigneur, 2001) 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 3 Yleise mmin: ISAframe work: Zachman,

3 Complete ISA: Sowa & Zachman, 1992 Three additional dimensions: People Agent Work Time Time Cycle Motivation Ends Means 5 Compl ete ISA (Sowa & Zachman, 1992) 6 3

4 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 for Information management in financial services in Europe 7 Component based architecture Architecture is the foundation for the product 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 4

5 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 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 5

6 Komponenttityypit soveltajan näkökulmasta (Häkkinen, 1999) Ongelma Valmiskomponentti Räätälöity komponentti Komponentin Perustuu toimittajan käyttökelpoisuuden tarjoamaan arviointi dokumentaatioon Komponentin käyttöönotto Perustuu toimittajan Helppoa, tarjoamaan dokumentaatioon Helppoa, komponentti toimitettu asiakkaan tarpeisiin sillä komponentti toteutettu sopimaan asiakkaan ympäristöön Sovitekomponentti Helppoa, komponentti sovitettu asiakkaan tarpeisiin Helppoa, komponentti toteutettu sopimaan asiakkaan ympäristöön Komponentin laatu Toimittaja takaa, mutta Voidaan määrittää Voidaan määrittää varmistettava itse itse laatukriteerit itse laatukriteerit Komponentin Kaikki kustannukset Toteutus Toteutus kustannukset edullisia verrattuina valmiskomponenttia suhteellisen (toteutus, käyttö ja perinteiseen ja perinteistä edullinen, käyttö ja ylläpito) ohjelmistoon ja muihin ohjelmistoa monta ylläpito edullista komponenttityyppeihin kertaa kalliimpi, käyttö ja ylläpito edullista Juridiset seikat Toimittajalla Asiakas Toimittaja ja avainasema sopimusten määrittämisessä avainasemassa sopimuksen määrittämisessä asiakas neuvotteluissa tasavahvoja ISA-mallin Motivaatio-sarake Asiakkaan varmistettava itse dokumentaation avulla, hyvin hankalaa Asiakas voi vaikuttaa kehityksen aikana, hankalaa sillä Asiakas voi vaikuttaa kehityksen aikana, hankalaa 11 Architecture-Based Line Development Domain requirements Changes, Unsatisfied constraints, Errors, Adaptations Requirements Executable Model Domain Modeling Reqt Defn Spec Constraints Line Ref Arch Spec Design Unsatisfied constraints, errors Reference Architecture Imported Components Architecture Reusable Component Acquisition Reuse Library and Generator Components & Glueware Implementation Application Unsatisfied constraints, errors, adaptations System 3/25/98 twc SSEP 12 Source: Frank Belz TRW 6

7 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 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 14 7

8 Business function blueprint Business architecture Data access blueprint Application access blueprint Layers of archite cture (Klouwneberg, Koot & Van Schaik, 1995, p. 12; c.f. Mustikkamaa, 2001) IT architecture IT infrastructure Data storage blueprint Technology blueprint Management controls Business capabilities IT services IT components Application process blueprint Communication blueprint 15 1) Terminal Mobile phones Computers PDA s 2) Network Telecom Network Mobile Network IP Network Produc t archite cture bluepri nt (Mustikkamaa, 2001) 3) Enabling technology/ platform 4) Application 5) Content 6) Business Self-care concept Application Management Content 1 Content provider 1 Trading concept Service Gateways User, Service & Security Management System Management Platform Communi cation concept Business support concept Content Gateways Entertain ment concept Content & Data Management Informati on concept Content 2 Content 3 Content 4 Content 5 Content N Content provider 2 Application Gateways Content provider 3 Content provider 4 Content provider 5 Content provider 16 N 8

9 1) Terminal Mobile phones Computers PDA s IS architecture blueprint (Mustikkamaa, 2001) 2) Network 3) Enabling Technology/ platform 4) Application 5) Content Telecom Network Application Management Management applications Mobile Network Service Gateways User, Service & Security Management System Management Development applications Information Systems Platform Delivery & Development applications Business data data Operation & manitenance data Sales & Marketing applications Data Management Business Data Management Content Gateways Customer data IP Network Content & Data Management Customer Care a plications Operation Data Management Billing applications Customer Data & Event Management Event data 6) Business Management process Delivery Management process Delivery and ion process Sales & Marketing process Customer Care process Billing process 17 Liiketoimi-, prosessi- ja ICTarkkitehtuurit 18 9

10 Liiketoimi-, prosessi- ja ICTarkkitehtuurit 19 Liiketoimet yli kanavamallin 20 10

11 And in inter-organizational setting, everything gets more complicated!!! ITKE50 21 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? 22 11

12 Tarvemääritysten tulokset (Booch et al., 1999) Konteksti liiketoimintamallit (ks. edellä) Toiminnalliset määritykset Kunkin käyttäjäryhmän mahdolliset skenaariot, use-caset Järjestelmä ja use-case Ei-toiminnalliset vaateet (outo nimi, Jupsin huom.) esim. suorituskyky, MTBF, laatu, tietoturva Tarvevaihtoehdot Tila: esitetty, hyväksytty, sovitettu, validoitu Tarvittava implementointipanos Tärkeys: kriittinen, tärkeä, tarpeellinen (, kiva, tarpeeton) Implementointiriski: kriittinen, huomattava, normaali 23 Use cases Esim. std-kaupankäynnin vaiheet ja poikkeukset? Ostaminen Tarjous / vastatarjous Tilaus Tilausvahvistus Toimitus Maksaminen Valittaminen Reklamaatio Palautus Hyvitys Esim. vaikutus asiakassuhteeseen ja maksamiseen Mitätehdään? peritään, lykätään, tyrkytetään luottoa? Mitäeisaatehdäjamitätekemättäjättäminen 24 tarkoittaa? 12

13 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 25 Use Case: Collaboration diagram (Booch et al., 1998) 26 13

14 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 27 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 - 28 utopiaako? 14

15 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 29 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ätoimittajallejapyydäpäätös 6) odottaa toimittajan päätöstä +2vko; muistuta. Ack kirjoittajaa ja päätoimittajaa päätöksestä 30 15

16 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 31 T15 T8 T14 T13 Esim. jatkuu: Kaksi alisysteemiä: arvioija 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 32 16

17 Sama lentovarauksesta 1/2 (Daum & Scheller, 2000) 33 Sama lentovarauksesta 2/2 (Daum & Scheller, 2000) 34 17