1. Software Architecture for Evolving Environment Jaroslav Král, Michal Žemlička Charles University, Prague {jaroslav.kral,michal.zemlicka}@mff.cuni.cz

2. 25th September 2005STEP 2005, Budapest2 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!

3. 25th September 2005STEP 2005, Budapest3 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.

4. 25th September 2005STEP 2005, Budapest4 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

5. 25th September 2005STEP 2005, Budapest5 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

6. 25th September 2005STEP 2005, Budapest6 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.

7. 25th September 2005STEP 2005, Budapest7 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

8. 25th September 2005STEP 2005, Budapest8 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

9. 25th September 2005STEP 2005, Budapest9 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

10. 25th September 2005STEP 2005, Budapest10 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)

11. 25th September 2005STEP 2005, Budapest11 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)

12. 25th September 2005STEP 2005, Budapest12 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

13. 25th September 2005STEP 2005, Budapest13 Identify services

14. 25th September 2005STEP 2005, Budapest14 Register and analyze existing communication

15. 25th September 2005STEP 2005, Budapest15 Design interfaces of the services

16. 25th September 2005STEP 2005, Budapest16 Create screen prototypes and redirect the communication to them

17. 25th September 2005STEP 2005, Budapest17 Create front end-gate and connect it to the underlying application FEG App.

18. 25th September 2005STEP 2005, Budapest18 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.

19. 25th September 2005STEP 2005, Budapest19 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

20. 25th September 2005STEP 2005, Budapest20 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.

21. 25th September 2005STEP 2005, Budapest21 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

22. 25th September 2005STEP 2005, Budapest22 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).