Software Architecture for Evolving Environment

Jaroslav Král, Michal ŽemličkaCharles University, Prague{jaroslav.kral,michal.zemlicka}@mff.cuni.cz

25th September 2005 STEP 2005, Budapest 2

Changing Requirements on IS

Companies/organizations evolve during time – they join, split, change structure, restructure their business processes, etc.

Laws change Techniques change Partners change Standards change too …

The IS must adapt to all these changes!

25th September 2005 STEP 2005, Budapest 3

Problems

Current development techniques (object orientation, object-relational and relational databases) do not support enough radical run-time changes (reconfigurations) of the system.

Radical change of an application or a system (even single application upgrade) is a risky and costly operation. These problems should be reduced.

25th September 2005 STEP 2005, Budapest 4

Idea

The IS should have a flexible structure Individual subsystems supporting

basic operations of the supported institution should not change (unless it is necessary for its basic functionality). They should retain their local interface and functions used by local users.

Interfaces of the subsystems should be user-oriented

25th September 2005 STEP 2005, Budapest 5

Software Confederation

Virtual peer-to-peer network of autonomous applications (services) where every peer know (is aware of) its communication partners.

Typical examples: e-government IS of a large or distributed enterprise

Examples of systems being not confederations: e-commerce Monolithic applications

25th September 2005 STEP 2005, Budapest 6

Application Components

They provide the real functionality of the confederation

Often legacy or third party systems Typically preserve their original

interface and users and provide additional functions for the users of the whole confederation

Must be equipped with a special interface (primary gate) to be integrated into the confederation.

25th September 2005 STEP 2005, Budapest 7

Front-End Gates

Serve as providers of user-oriented interface of application components

Transform user-oriented requests (messages) to application-oriented messages and respective transform the answer for the requests.

Single application component can be equipped with several front-end gates.

Similar to connectors in Enterprise Service Bus offered by several software vendors

25th September 2005 STEP 2005, Budapest 8

An Application service, its primary gate and front-end gates

Application

service

Primary gate

Front-end

gate

Front-end

gate

Logically it can be viewed as a single application service

application-oriented interface

user-oriented interface

25th September 2005 STEP 2005, Budapest 9

Data Stores

Services/components having properties of data store from structured design (or DFD)

Allow to use more complicated communication between services than simple message queues – human control of the communication inclusive.

Can solve some problems with timeliness, accuracy, or availability of some data.

Have been successfully used in some applications

Indicate that service orientation is a paradigm different from object orientation

25th September 2005 STEP 2005, Budapest 10

Process managers

Control the flow of business processes (or, more precisely, allow to control BP to its owner).

There may be different (business) process managers following different business process methodologies (workflows, Petri nets, business rules, or simply fulltext instructions)

25th September 2005 STEP 2005, Budapest 11

Portals

Provide user interfaces to the whole system

There can be different portals for different groups of people.

They correspond to portals known from web

Similar to front-end gates Should be designed as one of the

peer (as a service)

25th September 2005 STEP 2005, Budapest 12

Implementation Strategy

Register and analyze communication of people requesting individual services within supported organization

Design interfaces of individual services Create screen prototypes of the

services providing the interfaces Create primary gates connecting the

user-oriented interfaces to the underlying applications

25th September 2005 STEP 2005, Budapest 13

Identify services

25th September 2005 STEP 2005, Budapest 14

Register and analyze existing communication

25th September 2005 STEP 2005, Budapest 15

Design interfaces of the services

25th September 2005 STEP 2005, Budapest 16

Create screen prototypes and redirect the communication to them

25th September 2005 STEP 2005, Budapest 17

Create front end-gate and connect it to the underlying application

FEG

App.

25th September 2005 STEP 2005, Budapest 18

System Evolution

If a part of an enterprise has to be sold, the supporting information system must be split. If the IS is a confederation, the splitting operation is simple.

When new parts are acquired, they are connected as new services and incorporated in portals and business processes

It opens new opportunities for support of SCM and CRM.

25th September 2005 STEP 2005, Budapest 19

System Evolution (2)

When business processes of the organization are to be changed, it is necessary to reconfigure only default business processes in the business process repositories. Most users using only one service need not to be aware of such a change

25th September 2005 STEP 2005, Budapest 20

Experience

Discussed architectural principles have been used in development of several control systems developed by Prof. Král. All such projects were successful and used for many years without significant maintenance. Also in the case of replacement of cooperating information system.

25th September 2005 STEP 2005, Budapest 21

Experience (2)

Discussed technique has been used in integration of agendas of a municipal office by a single master-degree student.

Similar experience with control systems using the confederative experience has also Prof. Kopeček from ZČU Plzeň, Czech Republic

25th September 2005 STEP 2005, Budapest 22

Conclusion

Discussed architecture supports smooth evolution of the system with minimum influenced users

Even when building such system the conversion from existing systems is usually smooth as many legacy applications can serve as application services (and their users feel that they still have “their” system).