TJTSE54 Kehittämismenetelmät ja

arkkitehtuurit liiketoiminnassa

TJTSE54 Kehittämismenetelmät ja

arkkitehtuurit liiketoiminnassa

Prof. Jukka Heikkilä

Elektroninen liiketoimintaTietojenkäsittelytieteiden laitos

Informaatioteknologian tiedekuntaJyväskylän yliopisto

tel:+358 14 260 3240email: jups@cc.jyu.fi

2

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

3

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 combination of

• offerings• services• Applications

• Let us dig into this!

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 processintegration

• Have a look on ISA!

2. What are we talking about?• WSDL process definitions (in XML vocabulary)• BPEL execution logic & process engine

5

Yleisemmin:ISA-

framework:

Zachman, 1987

6

With WSDL/BPEL we are here… (adaptedusing Jonkers et al., 2004 framework on )

The domainof Gordijn, et

al., 2000

7

My observations

Corollary 1a. Network is not a design issue in the samesense it used to be– It seems to have moved up to the level of biz-

modelling (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

8

Another view on the biz-modelling

Proposals

Fullfilments

Commitments

Assessments

CustomerSupplier

ProcurementSales &Delivery

Provision Usage

Business relation(Post-Transactional)

Business relation(Pre-Transactional)

Capability&

Needs

Capability&

Needs

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 real-world system state.

• Reporting requirement”

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”

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

12

Integrated Architecture Fwk(Maes et al. 2000. p. 11; c.f. Mustikkamaa 2001)

Business As Is

IT As Is

Business Vision

IT Vision

IntegratedArchitecture Framework

Businessand IT

TransformationIT Enabled Enterprise

Vision, Strategy

Architectural design

Development, Change

Operation, maintenance

13

An example:Productarchitect

ureblueprint(Mustikkamaa, 2001)

1) Terminal domain

2) Network domain

3) Enabling technology/

platform domain

4) Application domain

5) Content domain

Telecom Network

Mobile Network

IP Network

Service Gateways

User, Service & Security Management

Application Management

System Management Content & Data Management

Product Platform

Self-care concept

Trading concept

Communication concept

Business support concept

Entertainment concept

Information concept

Content Gateways

Content 1

Mobilephones

Computers PDA’s

6) Business domain

Content 2 Content 3 Content 4 Content 5 Content N

Content provider

1

Content provider

2

Content provider

3

Content provider

4

Content provider

5

Content provider

N

Application Gateways

14

1) Terminal domain

2) Network domain

3) Enabling Technology/

platform domain

4) Application domain

5) Content domain

Telecom Network

Mobile Network

IP Network

Service Gateways

User, Service & Security Management

Application Management

System Management Content & Data Management

Information Systems Platform

Management applications

Product Development applications

Product Delivery &

Development applications

Sales & Marketing

applications

Customer Care a

plications

Billing applications

Content Gateways

Business data Product data Operation & manitenance

data

Customer data Event data

Mobile phones

Computers PDA’s

Business Data Management

Product Data Management

Operation Data Management

Customer Data & Event Management

Management process

Product Delivery

Management process

Delivery and Production

process

Sales & Marketing

process

Customer Care

processBilling process

6) Business domain

An example:IS archi-tectureblue-print

(Mustikkamaa, 2001)

15

Kauppapaikan komponentteja(c.f. Porra, 1999)

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äjilleuudelleenkäytettäväksi suunnattukomponenttituote. Standardoitu rajapintamäärää käyttöympäristön.

• Lisäkekomponentti on täydentävä, loppukäyttäjillesuunnattu valmiskomponentti (esim. Plug-init)

• Sovitekomponenttia käytetään, josvalmiskomponentti ei täytä kaikkiaohjelmistonkehittäjän asettamia vaatimuksia, niinse voidaan sovittaa näihin erityistarpeisiin. Muutokset tekee komponentin valmistaja (esim. Toimialakohtainen adapteri)

17

Kompo-nentti-tyypitsovel-tajannäkö-

kulmasta(Häkkinen,

1999)

Ongelma Valmiskomponentti Räätälöitykomponentti

Sovite-komponentti

Komponentinkäyttökelpoisuudenarviointi

Perustuu toimittajantarjoamaandokumentaatioon

Helppoa,komponenttitoimitettu asiakkaantarpeisiin

Helppoa,komponenttisovitettu asiakkaantarpeisiin

Komponentinkäyttöönotto

Perustuu toimittajantarjoamaandokumentaatioon

Helppoa, silläkomponenttitoteutettu sopimaanasiakkaanympäristöön

Helppoa, silläkomponenttitoteutettusopimaanasiakkaanympäristöön

Komponentin laatu Toimittaja takaa, muttavarmistettava itse

Voidaan määrittääitse laatukriteerit

Voidaan määrittääitse laatukriteerit

Komponentinkustannukset(toteutus, käyttö jaylläpito)

Kaikki kustannuksetedullisia verrattuinaperinteiseenohjelmistoon ja muihinkomponenttityyppeihin

Toteutusvalmiskomponenttiaja perinteistäohjelmistoa montakertaa kalliimpi,käyttö ja ylläpitoedullista

Toteutussuhteellisenedullinen, käyttö jaylläpito edullista

Juridiset seikat Toimittajallaavainasema sopimustenmäärittämisessä

Asiakasavainasemassasopimuksenmäärittämisessä

Toimittaja jaasiakasneuvotteluissatasavahvoja

ISA-mallinMotivaatio-sarake

Asiakkaanvarmistettava itsedokumentaation avulla,hyvin hankalaa

Asiakas voivaikuttaa kehityksenaikana, hankalaa

Asiakas voivaikuttaakehityksen aikana,hankalaa

18

Ohjelmistoarkkitehtuuri

Toimiva järjestelmä

Komponentit

Teknologia -malli

Järjestelmä- malli

Yritysmalli

Soveltamisala

Tieto Toiminto Verkko Aika Ihmiset

Sovelluskehys & k i lli

OHJELMISTO- KOMPONENTTI

Motivaatio

komponentti-malli

Komponentit arkkitehtuurissa(adapted from Häkkinen, 2000)

There is a gap in here!

Patternit?

19

Design Patterns(adopted from Gamma et al., 1995)

• Generic descriptions or templates of solutions to contextspecific 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, patternsdesign problems

20

Design patterns (IBM, 2004)

• Business patterns identify the interaction between users, businesses, and data. Business patterns are used to create simple, end-to-end e-business applications.

• Integration patterns connect other Business patterns together to createapplications with advanced functionality. Integration patterns are used to combine Business patterns in advanced e-business applications.

• Composite patterns are combinations of Business patterns and Integrationpatterns 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 Business 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 problemsof one specific company, or perhaps several enterprises with similar problems.

• Application and Runtime patterns are driven by the customer'srequirements and describe the shape of applications and the supporting runtimeneeded to build the e-business application.

• Product mappings to populate the solution. The product mappings are basedon proven implementations.

21

Patternsprocess

(IBM, 2004)

22

Examples of CompositePatterns:

Electronic Commerce (IBM, 2004)

23

Cntd

24

Cntd

• LOB = Line of Business

25

Cntd

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 informationsystems architectures. I.e., they are business modelequivalent descriptions of the processes in theirrelationship 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.

27

Liiketoimi-, prosessi- ja ICT-arkkitehtuurit (Versteeg & Bouwman, 2004)

Functio

nal

Arch

itecture

Process

Arch

itecture

Business Architecture

Applica

tion

Arch

itecture

Business Process

Business Domain

Business Function

Business Object

Supply Chain

Service Application

Datadecomposition

Functiondecomposition

Processdecomposition

Function Object

Shared Usable IT-Unit

Sub-process

I T -supply domain

OutsourceContract(SLA)

28

Pro

cess

Arch

itecture

Pro

cess

Arch

itectu

re

Application

Arch

itecture

Business Architecture

Process Service

Business Process

Business Domain

Business Function

Business Object

Supply Chain

Service Application

Workflow engine

Case handler

Datadecomposition

Functiondecomposition

Processdecomposition

Function Object

Business Actor / Role

Business Event

Event (e.g. message)

Business Activity

(macro flow case-oriented)

Business Procedure

(macro flow pre-defined)

BusinessUse Case

SystemUse Case

IT-Service

Service

Task(micro flow)

OPS supply domain

I T supply domain

OutsourceContract

(SLA)

Workflowscripts

Web-services server

(Dynamic appl. Builder: SOAP, UDDI, WSDL)

Generic Thin Client

(browser)

Dedicated Application

Client

(eg Siebel)

Dedicated application

(requestor control processes)

Classic Application

Client

(legacy)

Process automationControl & Aggregation Layer

Interfacing Layer

Adapters

Liiketoimi-, prosessi- ja ICT-arkkitehtuurit (Versteeg & Bouwman, 2004)

29

A way of managing business processes and building systems utilizing layered BPM/SOA

Concepts

11 22 33 Intra-/Inter-OrganizationalProcesses Flow

Service 1 Service 1 Service 1External

Business Process Management

Business Rules

Corporate Systems & ComponentsERP, CRM, PDMLegacy Systems

Other Corporate SW Components

Vendors & PartnersSystems & Components

Old WayTraditional Monolith Systems with implicit business process management, rules and services and bad connectivity.

Business Process Management

Service Oriented Architecture / Web Services

Systems /software level

EAI, middleware

30

Do we need the intermediatedesign 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

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

32

And…

• in inter-organizational setting, everything getsmore complicated!!!– ITKE50