Software Architecture for Evolving Environment

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

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! 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. 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 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 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. 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 STEP 2005, Budapest

8. An Application service, its primary gate and front-end gates application-oriented interface Application service user-oriented interface Primary gate Front-end gate Front-end gate Logically it can be viewed as a single application service 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 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) 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) 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 STEP 2005, Budapest

13. Identify services STEP 2005, Budapest

14. Register and analyze existing communication STEP 2005, Budapest

15. Design interfaces of the services STEP 2005, Budapest

16. Create screen prototypes and redirect the communication to them STEP 2005, Budapest

17. Create front end-gate and connect it to the underlying application App. FEG 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. 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 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. 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 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). STEP 2005, Budapest