Methods for the specification and verification of business processes - - PowerPoint PPT Presentation

Methods for the specification and verification of business processes MPB (6 cfu, 295AA)

Roberto Bruni

http://www.di.unipi.it/~bruni

06 - Evolution

1

Object

2

Overview of the evolution of (Information Systems inside) Enterprise Systems Architectures

Ch.2 of Business Process Management: Concepts, Languages, Architectures

Guiding principles

3

Modularity and information hiding (encapsulation, interfaces, reuse, maintainability, response to change)

Software Architecture

4

Definition: A software architecture defines a structure that organizes the software elements and the resources of a software system.

Gartner’s hype cycle

5

A hype cycle is a (branded) graphic representation of the maturity, adoption and social application of specific technologies

B r e a k t h r

• u

g h P r

• d

u c t l a u n c h P r e s s i n t e r e s t O v e r

• e

n t h u s i a s m U n r e a l i s t i c e x p e c t a t i

• n

s F a i l t

• m

e e t e x p e c t a t i

• n

s Q u i c k l y b e c

• m

e u n f a s h i

• n

a b l e T e c h n

• l
• g

y b e n e f i t s e m e r g e T e c h n

• l
• g

y b e n e f i t s a r e w i d e l y a c c e p t e d

Early systems (architectures)

6 Programming interfaces Physical data independence Advanced user interfaces Monolithic applications developed from scratch Porting required redevelopment Data dependency and consistency issues Application code and (textual) user interfaces still entangled Data management as a primary concern Human interaction made easier

Enterprise Applications

7

OS + DBMS + GUI + Networking capabilities = more and more elaborate information systems could be engineered Typically hosting enterprise applications (customers, personnel, products, resources) Next steps: from individual to multiple information systems (needs integration)

Individual enterprise application

8 Lack of Integration! Data redundancy! Data dependencies!

Changes

9

Changes were hard to implement! Hard to track data dependency and replication Any modification of an application was a complex and error-prone activity, with domino effect (e.g. change of customer address format)

ERP

10

Enterprise Resource Planning (ERP) systems were developed to deal with the increasing complexity of changes Basic idea integrated database that spans most applications, separated modules provide desired functionalities, accessed by client applications

Enterprise resource planning systems

11 I n t e g r a t e d a n d c

• n

s i s t e n t ( c e n t r a l i z e d ) d a t a b a s e T w

• t

i e r c l i e n t

• s

e r v i c e r e m

• t

e d a t a a c c e s s h u m a n r e s

• u

r c e s f i n a n c i a l s m a n u f a c t u r i n g

E R P

CRM and SCM

12

New types of sw entered the market around 2000 Customer Relationship Management (CRM) systems Supply Chain Management (SCM) systems Goal to support the planning, operation, and control of supply chains, including inventory management, warehouse management, management of suppliers and distributors, and demand planning Problem: different vendors, separately developed

Siloed enterprise applications

13 C u s t

• m

e r R e l a t i

• n

s h i p M a n a g e m e n t S y s t e m S u p p l y C h a i n M a n a g e m e n t S y s t e m Lack of Integration! Data redundancy! Data dependencies! (on a larger scale and complexity than before) Connected on local network, but not logically integrated Data Integration would provide valuable information

A sample scenario

14

Customer calls Call centre personnel can only access the information stored in one system Call centre personnel is not aware of the full status of the customer Customer (doesn’t care about siloed structure) does not feel well served, becomes upset, expects a better service

Heterogeneity

15

Heterogeneity of data and their attributes (syntax and semantics difficulties) calls for Data Integration Examples corresponding data fields with different names (e.g., CustAddr vs CAstreet), fields with the same name but different meaning (e.g. Price: with or without taxes? unitary?)

Integration

16

Manual integration is possible, but: it consumes considerable resources it is error-prone cannot foreseen all applications in advance (reimplementing functionalities in an integrated way would just postpone the problem) Solution Enterprise Application Integration systems as a new middleware

Enterprise Application Integration

17

Definition: Enterprise Application Integration (EAI) is defined as the use of software and computer systems architectural principles to integrate a set of enterprise computer applications.

Point-to-point integration (of silos)

18 M i d d l e w a r e t e c h n

• l
• g

y ( d e d i c a t e d s y s t e m i n t e g r a t

• r

s )

N−1

X

i=1

i = N(N − 1) 2

N x N hard-wiring problem! Too many interfaces to develop! Does not respond well to changes! (Reprogramming an interface requires considerable resources, typically)

Message Oriented Middleware

19

Message-Oriented Middleware offers some execution guarantees, such as message delivery (e.g. persistent message queues are used) Still, the main problem remains: changes in the application landscape require changes in the communication structure The Client exploits an Integration Application to

• perate on all systems

Message-oriented middleware

20 Messages must be encoded and decoded Point-to-point connection problem does not diminish that much C

• p

e r a t i

• n

r e a l i z e d i n t h e i n t e g r a t i

• n

a p p l i c a t i

• n

Response to Change

21

Message-oriented middleware reduces in part integration efforts and gives important run-time guarantees Still cooperation is hardwired in a particular application (the Integration Application) No explicit process model that can be documented, communicated, and changed when necessary In the end, response to change is not improved

Hub-and-Spoke

22

The Hub-and-Spoke paradigm is based on a central hub and a number of spokes attached to it The Application Integration middleware represents the hub, and the applications to be integrated represents the spokes Interactions between any two applications must pass through the hub

Hub-and-spoke integration

23 Configuration and management of adapters and message brokers can become cumbersome F r

• m

N x N t

• N

i n t e g r a t

• r

s M e s s a g e b r

• k

e r s P u b l i s h / s u b s c r i b e m e c h a n i s m

EAI implementation pitfalls

24

70% of all EAI projects fail (2003). Most of these failures are not due to technical difficulties, but due to management issues: Constant change Shortage of EAI experts Competing standards Loss of detail: Information unimportant at an earlier stage may become crucial later Conflicting and emerging requirements Data protectionism

From (data-models and) data-integration To (process-models and) process-integration

25

Value Chains and Process Orientation

26

Two major factors fuelled business process management Value chains as a means to functionally break down the activities a company performs Process orientation as the way to organize the activities of enterprises

Workflow component

27

Definition: a single-application workflow consists of activities and their causal and temporal

• rdering that are realized by one common

application system.

Multiple-application workflow system

28

Definition: a multiple-application workflow contains activities that are realized by multiple application systems, providing an integration of these systems.

System workflow

29

Definition: a system workflow consists of activities that are implemented by software systems without any user involvement.

Workflows fit well with hub-and-spokes EAI

30

Limitations in workflow management

31

Technical integration problems: Scarcely documented applications Different levels of granularity Tight coupling of applications (direct invocation)

Enterprise service computing

32

Main idea: Business functionalities exposed as services Services are equipped with usage information Customers can find services and use them

Services

33

Definition: Services are loosely-coupled computing tasks that can be dynamically discovered and invoked over the network. Each service comes with a service description that can be published in service registries by the service provider. Service registries can be queried by service requestors. Service descriptions provide a level of detail that facilitates service requestors to bind and invoke them.

Service-oriented architectures

34

Definition: Service-oriented architectures (SOA) are software architectures that provide an environment for describing and finding software services, and for binding to services.

Service-oriented architectures

36

Service enabled application system

37 s e r v i c e s p e c i f i c a t i

• n

m u s t b e d e c

• u

p l e d f r

• m

i m p l e m e n t a t i

• n

a n d l e g a c y s y s t e m s t a n d a r d i n t e r f a c e

Composite service based application

38 I n t r a

• c
• m

p a n y w e l l

• e

x p r e s s e d a s b u s i n e s s p r

• c

e s s e s L

• c

a l r e g i s t r y M a n u a l s e a r c h ( a b s e n c e

• f

d y n a m i c m a t c h m a k i n g )

Advantages of SOA

39

Reuse of functionality at coarse level of granularity New applications can be built with less effort Existing applications can be efficiently adapted to changing requirements Reduced maintenance and development costs

Products as services

40

Corporations are increasingly perceived by the set

• f services they provide

These services exposed to the market can be realized by enterprise services (provided by the back-end application system) Also services provided by third parties can be integrated so that better end used services can be provided to the customer

42

Business-to-business value system

43

Business-to-business processes

44