Software Confederations An Architecture for Agile Development in

Software Confederations An Architecture for Agile Development in the Large Jaroslav Král, Michal Žemlička, Michal Kopecký Charles University, Prague {Jaroslav. Kral | Michal. Zemlicka | Michal. Kopecky}@mff. cuni. cz 1. 11. 2006 J. Král, M. Žemlička, M. Kopecký: ICSEA '06

Content of the Presentation • Comparison of Agile development and development in the large • Software confederations – the way of development in the large with respect to agile development requirements • Issues of the approach • Conclusions 1. 11. 2006 J. Král, M. Žemlička, M. Kopecký: ICSEA '06 2

Agile development • Oriented to maximal satisfaction of user needs and requirements • Keeps track whether requirements are really met • Incremental – Supports users with new versions of software and/or its parts » Needed tight cooperation between users and developers 1. 11. 2006 J. Král, M. Žemlička, M. Kopecký: ICSEA '06 3

Development in the Large • Large projects are usually precisely planned • Mainly monolithic applications – based on object-oriented analysis and design • The main development phases (specification, analysis, design, coding, testing, delivery, maintenance) are often separated; provided by different groups of people 1. 11. 2006 J. Král, M. Žemlička, M. Kopecký: ICSEA '06 4

Monolithic Systems • Developed as a single logical unit • Often based on holistic approach expecting that it is possible to handle arbitrary complex systems • The systems are typically first analyzed, then designed and encoded (with some possible repetitions) » Support for later changes is restricted 1. 11. 2006 J. Král, M. Žemlička, M. Kopecký: ICSEA '06 5

How to Apply Agile Development to Large Systems? • Let us take the inspiration from control systems – the large system should be broken to smaller autonomous parts cooperating together. Such systems are called service-oriented (or more precisely software confederations). 1. 11. 2006 J. Král, M. Žemlička, M. Kopecký: ICSEA '06 6

Service-Oriented Systems • Composed from smaller elements – services • Types: – Alliances – web services (W 3 C) • partners are searched for; low-level interface – Enterprise Service Bus • services are tightly coupled (know each other) through low-level complicated interface – Confederations • closest to control systems • partners are known; high-level user-oriented interfaces 1. 11. 2006 J. Král, M. Žemlička, M. Kopecký: ICSEA '06 7

Software Confederations • Virtual peer-to-peer network of autonomous services (components) • Services are used as black boxes – The services are aware of each other – Detailed knowledge of internal functionality is not needed » System can easily integrate legacy and thirdparty systems » applicable (not only) for e-government, information systems of international enterprises, of health care networks, … 1. 11. 2006 J. Král, M. Žemlička, M. Kopecký: ICSEA '06 8

Software Confederations • Can benefit from the use of proprietary standards – User oriented declarative (coarse-grained) messages – Based often on XML » Users can understand messages sent between individual services » Possibility to perform operations manually 1. 11. 2006 J. Král, M. Žemlička, M. Kopecký: ICSEA '06 9

Software Confederations: Structure • Service types in software confederation – – – P FEG IS DS A PM P A Application Services Front-End Gates A Portals Data Stores Infrastructure Services Process Managers 1. 11. 2006 PM J. Král, M. Žemlička, M. Kopecký: ICSEA '06 10

Application Service • Provides some basic (atomic) functionality of the system • Can be even a legacy or third-party system • Can have its own direct interface • It makes with its front-end gates one logical entity. 1. 11. 2006 J. Král, M. Žemlička, M. Kopecký: ICSEA '06 11

Front-End Gate • Purveys an interface of an application service to some group of users • Transforms user-oriented coarse-grained interface visible for other to the imperative fine grained interface of the application component • There can be more front-end gates for one application component targeting different group of users 1. 11. 2006 J. Král, M. Žemlička, M. Kopecký: ICSEA '06 12

Portal • Serves as an interface to the system as a whole. • There can be more portals – typically they serve to different groups of users (e. g. one for intranet and one for extranet) 1. 11. 2006 J. Král, M. Žemlička, M. Kopecký: ICSEA '06 13

Data Store • Can serve as data/command media • It can be useful to reorder incoming service requests – e. g. for optimization or priority issues. • Allows to use batch processing – it is important for integration of many legacy or third-party systems. 1. 11. 2006 J. Král, M. Žemlička, M. Kopecký: ICSEA '06 14

Infrastructure Service • Generalization of front-end gates or portals • Serves as post office – Sends service requests only to components able to understand them – Routes messages – Balances the load of services able to perform the same task • May interconnect different middleware implementations 1. 11. 2006 J. Král, M. Žemlička, M. Kopecký: ICSEA '06 15

Process Manager • Specific services orchestrating other services into a support of a business process • Allows process owner to control the process (define it, start it, change it, stop it) • May support different process flow control techniques 1. 11. 2006 J. Král, M. Žemlička, M. Kopecký: ICSEA '06 16

Flexibility in Software Confederation • The structure of software confederation allows to change: – Business processes (changes of the running processes by process managers; changes of future processes by adding or changing process templates) – Individual services (replacement or change of the application and changing the front-end gates) 1. 11. 2006 J. Král, M. Žemlička, M. Kopecký: ICSEA '06 17

User-Performable Changes • The fastest reaction on user requirements are performable by user themselves: – They can react on unexpected or rare situations – They can also change the business process 1. 11. 2006 J. Král, M. Žemlička, M. Kopecký: ICSEA '06 18

Support of Agile Development by Confederations • The whole task is decomposed to smaller ones – agile development for them is well known • The parts have user-understandable interfaces – It is important in the development phase – It is crucial for the modification of business processes by users • Privileged users can instantly influence the processes within the system 1. 11. 2006 J. Král, M. Žemlička, M. Kopecký: ICSEA '06 19

Issues • Quite new concept for many developers, influences the whole development process – Requires shift in the thinking of developers • Time to train new developers needed • Re-qualification of current developers is often difficult • Lack of quality development tools » Switch from OO to SO in the whole will take years 1. 11. 2006 J. Král, M. Žemlička, M. Kopecký: ICSEA '06 20

Conclusions • Software confederations are very flexible and have all features needed for agile development – Development in tight cooperation with users – Parts of the system are manageably small changes can be applied in reasonable time – Features of the system can be developed and shipped individually and incrementally – User-oriented interfaces and messages are easily understandable and often self-documenting – Services can be often clustered to achieve scalability 1. 11. 2006 J. Král, M. Žemlička, M. Kopecký: ICSEA '06 21

Questions? • Send all questions to: Jaroslav. Kral@mff. cuni. cz or Michal. Zemlicka@mff. cuni. cz or Michal. Kopecky@mff. cuni. cz 1. 11. 2006 J. Král, M. Žemlička, M. Kopecký: ICSEA '06 22