TJTSE54 Kehittämismenetelmät ja arkkitehtuurit liiketoiminnassa

Transkriptio

1 TJTSE54 Kehittämismenetelmät ja arkkitehtuurit liiketoiminnassa Prof. Jukka Heikkilä Elektroninen liiketoiminta Tietojenkäsittelytieteiden laitos Informaatioteknologian tiedekunta Jyväskylän yliopisto tel:

2 Tasapainoilua strategian, prosessin ja komponenttien välillä (Allen & Frost, 1998) 2

3 And the suggested solution is: Models, Architectures and Platforms 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 e -system is a combination of offerings services Applications Let us dig into this! 3

4 Remember WSDL/BPEL? 1. What has changed since the start of Architecture Era? In SOA: levels of abstraction between services (data, application, process) for process integration Have a look on ISA! 2. What are we talking about? WSDL process definitions (in XML vocabulary) BPEL execution logic & process engine 4

5 Yleise mmin: ISAframe work: Zachman,

6 With WSDL/BPEL we are here (adapted using Jonkers et al., 2004 framework on ) The domain of Gordijn, et al.,

7 My observations Corollary 1a. Network is not a design issue in the same sense it used to be It seems to have moved up to the level of bizmodelling (see 2) Corollary 1b. Procedure modelling in ISA is divided in two: - Modelling of functions/operations (CheckCreditCard, c.f. Ville) - Modelling of process flow (if maksutapa., c.f. Ville) Corollary 1c. The columns of the model are transposed into abstraction layers - Abstraction layers are defined as componentized services - WSDL interfaces with entry and exit points 7

8 Another view on the biz-modelling relation (Pre-Transactional) Capability & Needs Supplier Proposals Customer Capability & Needs Commitments Provision Sales & Delivery Fullfilments Assessments Procurement Usage relation (Post-Transactional) 8

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

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

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

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

13 1) Terminal domain Mobile phones Computers PDA s 2) Network domain Telecom Network Mobile Network IP Network Service Gateways An example: Product architect ure blueprint (Mustikkamaa, 2001) 3) Enabling technology/ platform domain 4) Application domain 5) Content domain Self-care concept Application Management Content 1 Trading concept User, Service & Security Management System Management Product Platform Application Gateways Communi cation concept support concept Content Gateways Entertain ment concept Content & Data Management Informati on concept Content 2 Content 3 Content 4 Content 5 Content N 6) domain Content provider 1 Content provider 2 Content provider 3 Content provider 4 Content provider 5 Content provider 13 N

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

15 Kauppapaikan komponentteja (c.f. Porra, 1999) 15

16 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) 16

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

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

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

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

21 Patterns process (IBM, 2004) 21

22 Examples of Composite Patterns: Electronic Commerce (IBM, 2004) 22

23 Cntd 23

24 Cntd LOB = Line of 24

25 Cntd 25

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

27 Liiketoimi-, prosessi- ja ICTarkkitehtuurit (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 27

28 Liiketoimi-, prosessi- ja ICTarkkitehtuurit (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 28

29 A way of managing business processes and building systems utilizing layered BPM/SOA Concepts Intra-/Inter-Organizational Processes Flow Process Management Rules Process Management Service 1 Service 1 EAI, middleware Corporate Systems & Components ERP, CRM, PDM Legacy Systems Other Corporate SW Components Service 1 External Vendors & Partners Systems & Components Traditional Monolith Systems with implicit business process management, rules and services and bad connectivity. Service Oriented Architecture / Web Services Systems /software level Old Way 29

30 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 stdsetc Functional conformity I/O, sequence of processes, delays/lead times Procedural conformity Quality stds and procedures, information sharing and disclosure Abstraction 30

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

32 And in inter-organizational setting, everything gets more complicated!!! ITKE50 32