Post on 17-Mar-2018
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