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

Transkriptio

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

2 Prosessi (Turban et al., 2002) 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 subset, or superset of offerings services applications 3

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

5 Viitekehyksiä prosessien ja komponenttien yhteensovittamiseen 5

6 Yleise mmin: ISAframe work: Zachman,

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

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

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

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

11 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 support concept Entertain ment concept Informati on concept bluepri nt (Mustikkamaa, 2001) 5) Content domain 6) 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 11 N

12 1) Terminal domain Mobile phones Computers PDA s 2) Network domain Telecom Network Mobile Network IP Network IS Service Gateways 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 12

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

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

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

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

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

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

19 Patterns process (IBM, 2004) 19

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

21 Cntd 21

22 Cntd LOB = Line of 22

23 Cntd 23

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

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

26 Liiketoimi-, prosessi- ja ICTarkkitehtuurit (Versteeg & Bouwman, 2004) Architecture Supply Chain Domain Process Outsource Contract (SLA) Function Object Application Architecture (macro flow predefined) Webservices server Generic Thin Client (browser) Interfacing Layer (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 26

27 Liiketoimet yli kanavamallin relation (Pre-Transactional) Capability & Needs Supplier Proposals Customer Capability & Needs Commitments Provision Sales & Delivery Fullfilments Assessments Procurement Usage relation (Post-Transactional) 27

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

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