TJTSE54 Kehittämismenetelmät ja arkkitehtuurit liiketoiminnassa Prof. Jukka Heikkilä Elektroninen liiketoiminta Tietojenkäsittelytieteiden laitos Informaatioteknologian tiedekunta Jyväskylän yliopisto tel:+358 14 260 3240 email: jups@cc.jyu.fi
Components of a webstore (c.f. Porra, 1999) 2
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) 3
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 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 Toimittaja ja asiakas neuvotteluissa tasavahvoja Asiakas voi vaikuttaa kehityksen aikana, hankalaa 4
Komponentit arkkitehtuurissa (adapted from Häkkinen, 2000) There is a gap in here! Tieto Toiminto Verkko Aika Ihmiset Motivaatio Soveltamisala Yritysmalli Patternit? Järjestelmämalli Teknologia -malli Komponentit Toimiva järjestelmä Ohjelmistoarkkitehtuuri Sovelluskehys & k i lli komponenttimalli OHJELMISTO- KOMPONENTTI 5
Design Patterns (adopted from Gamma et al., 1995) Generic descriptions or templates of solutions to context specific problems It is described in: The goal and reason description in the form of intent Motivation, describing scenarios/use cases in which to use the pattern by combining problems and contexts Graphical representation (typically class or interaction diagrams), i.e. structure, participants, collaboration Implementation, Sample Code Known uses and related patterns Algorithms solve computational problems, patterns design problems 6
Design patterns (IBM, 2004) patterns identify the interaction between users, businesses, and data. patterns are used to create simple, end-to-end e-business applications. Integration patterns connect other patterns together to create applications with advanced functionality. Integration patterns are used to combine patterns in advanced e-business applications. Composite patterns are combinations of patterns and Integration patterns that have themselves become commonly used types of e-business applications. Composite patterns are advanced e-business applications. Custom designs are similar to Composite patterns, as they combine patterns and Integration patterns to form an advanced, end-to-end solution. These solutions, however, have not been implemented to the extent of Composite patterns, but are instead developed to solve the e-business problems of one specific company, or perhaps several enterprises with similar problems. Application and Runtime patterns are driven by the customer's requirements and describe the shape of applications and the supporting runtime needed to build the e-business application. Product mappings to populate the solution. The product mappings are based on proven implementations. 7
Patterns process (IBM, 2004) 8
Examples of Composite Patterns: Electronic Commerce (IBM, 2004) 9
Cntd 10
Cntd LOB = Line of 11
Cntd 12
Jups s opinion on patterns Patterns are computer practice, not science However, they seem to fill in the gap between business strategy and actual processes ran on information systems architectures. I.e., they are business model equivalent descriptions of the processes in their relationship with architecture and other parts of the business model The patterns are helpful and proven model conceptualizations of solutions on specific problem domains, Patterns have to be backed up by rigorous and tested components/algorithms and with careful analysis and abstraction of the problem domain. 13
Do we need the intermediate design 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 stds etc Functional conformity I/O, sequence of processes, delays/lead times Procedural conformity Quality stds and procedures, information sharing and disclosure Abstraction 14
The Antropomorphic Question? In the context of using components: Should I name the components as used or as part of design? What is the difference, then, between: Architecture? Process? Service? Pattern? Component? Probably, the processes are the ones to be described from different view points Probably, a joint subset of processes can be created as service components Probably, the architecture should be a superset of all potential processes using architecture 15
How did we get into this? Let us start with Yair Wand s design requirement (a series of articles in the 1990 s): The Structure of IS Representational model: Ontological expressiviness Ontological completeness Ontological clarity Construct overload Construct redundancy Construct excess State-tracking model Mapping requirement A one to many mapping must exist from the set of real-world system states into the set of IS states Tracking requirement When the real-world system changes states, the IS must be able to change from a state that corresponds to the initial real-world system state to a state that corresponds to the subsequent realworld system state. Reporting requirement 16
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 17
-, process- & ICTarchitectures (Versteeg & Bouwman, 2004) Architecture Supply Chain Domain Process Outsource Contract (SLA) Function Object Application Architecture Process Architecture Process decomposition Functional Architecture Function decomposition Data decomposition I T - supply domain Service Application Subprocess Function Object Shared Usable IT-Unit 18
-, process- & ICTarchitectures (Versteeg & Bouwman, 2004) Architecture Supply Chain Domain Process Outsource Contract (SLA) Function Object Application Architecture Generic Thin Client (browser) Interfacing Layer (macro flow predefined) Webservices server (Dynamic appl. Builder: SOAP, UDDI, WSDL) Dedicated Application Client (eg Siebel) Dedicated application (requestor control processes) Adapters Process automation Control & Aggregation Layer Service Application Classic Application Client (legacy) Workflow engine Case handler Process Architecture Process Service Event Workflow scripts Actor / Role Event (e.g. message) Process decomposition Procedure Activity (macro flow caseoriented) Use Case Task OPS supply domain I T supply domain Process Architecture Function decomposition Function Data decomposition Object (micro flow) IT-Service System Use Case Service 19
With WSDL/BPEL we are here (adapted using Jonkers et al., 2004 framework on ) The domain of Gordijn, et al., 2000 20
Process description standards OMG (Object Management Group) International, open membership, not-for-profit computer industry consortium Various de facto software analysis (UML), middleware (CORBA), architecture (MDA) and process standards (BMI, BPMN, BPMI) among others 21
Biz Modelling vs Biz Process Modelling (Grodijn et al., 2000) BM = Who is offering what to who and expects what in return? Value adding business actors involved? What offerings of the actors to which actors? Elements of offerings? Producing and consuming activities of offerings? Value-adding activities 22
Biz Modelling vs Biz Process Modelling (Grodijn et al., 2000) BPM = how the activities are carried out? Which operational activities are necessary? Functional vs. non-functional Who are the actors involved in the operations? Which activities are executed by which actors? Inputs and outputs necessary for activities? Sequence of activities Parallel activities Simplification 23
BizModelling generics (Grodijn et al, 2000) 24
BizModelling Generics (cntnd) Actor = toimija Independent economic entity actors End-consumer actors Value activity = toiminta Actor produces value in an activity By adding value to objects of value (inputs) By producing objecs of value (outputs) Value object = tuote Thing, product (good or service), experience of value to actor Value port = kanava Means of providing or requesting value objects. Interconnects actors. Value interface = tarjooma Groups in and out value ports for actor or for activity Has a valuation function (perceived value of the value exchange) Value exchange = liiketoimi Trade of a value object between value ports Value offering = arvolupaus 25
BizModelling (Gordijn, 2007) 26
BizModelling (Gordijn, 2007) 27
BizModelling (Gordijn, 2007) 28