Systemic Issues of Software Confederations Jaroslav Král, Michal Žemlička Charles University, Prague

Problem SW support of decentralized organizations like international enterprises and/or state or municipal administration. Some of the activities (probably all) are already supported by legacy systems. But these services are not integrated. They do not collaborate.

“Modern” Solution The first solution given by young and „predatory“ consultants is to build from scratch a wonderful big (and monolithic) object-oriented system with lots of new technologies. It is no feasible solution!!!

Monolithic Approach: Technical Issues Huge monoliths are very difficult to develop: the complexity of the development grows super linearly with size. -> In some cases the complexity is too high, such system are practically impossible to develop within budget, schedule and quality. They are hard to modify and maintain. They need stable requirements for several years of development, sometimes and for all its life-cycle.

Monolithic Approach: Unsolvable Crucial Systemic Issues Collaboration of independent/autonomous bodies (e.g. business partners). Collaboration of autonomous subunits. Support for decentralization.

Real Life Requirements Adaptability: react on the steady changing structure (divisions/offices can join and leave the whole). Robustness. Low education costs. Security. Feasibility.

Adaptability Requirements Possibility to adapt the system in a seamless way to changes in the structure of an enterprise/organization (i.e. when e.g. a division is sold or purchased). Possibility to add new features. Support of varying set of clients (business partners, clients, citizens, institutions, etc.)

Robustness Breakdown of any component should not force breakdowns of other components. If an application component is not down, its services should be available at least for its local users.

Solution: Software Confederation The system is composed from autonomous components (often standalone applications providing some services) forming a peer-to- peer network. The system should behave from outer view like one whole – it should have one common interface.

Software Engineering Advantages of Software Confederations Robustness Easy to maintain (modify, enhance) Composed from rather autonomous parts from various sources Open Good for incremental development Enable specific development techniques

Structure of SWC The user interface is transparent UI G G G User interface UI should be an autonomous component G – (basic) gate

Implementation Dependency of Gates If a gate G provides the full functionality of its component C, G must disclose at least the implementation philosophy if not implementation details (OO one or SQL oriented one) of C. Consequence: If the implementation philosophy of C is changed all the components communicating with C (partners) must be modified. But the set of partners can vary and unknown new partners can occur. Consequence: The modification of partners is a very difficult (if not unsolvable) task

Front-End Gates (FEG) Make an alternate access to an application component (via its basic gate) May hide the implementation details and philosophy of given component Serve also as a wrapper to legacy or third party systems They must be message transducers  they can be based on the same tools and paradigms as UI. They can redirect messages, so they serve as Communication switches.

Component And Its Gates Front-end gate Basic gate Kernel Front-end gate LCLC LCLC L1L1 L2L2 Autonomous component Other components

Structure of SWC (3) UI FEG G G

Types of Autonomous Components Application components – provide main functionality of the system. Front-end gate components – enhance the middleware services. User interface – hides the internal structure of the confederation.

Domain Oriented Interface If the interface is problem domain oriented (instead of implementation oriented as it is now rather common), it is usually possible to do changes in the implementation of the components without any need to update the components communicating with it. It is often true even if the component is replaced by an another one (provided by an another vendor)

Confederation: Systemic Issue Confederative architecture supports: –Organizational structures of (large) enterprises –Enterprise integration/fusion/coalition-decentralization –Multiple message formats –Integration of third party products and newly developed components –New programming techniques used in the development of real time systems or based on properly coded knowledge on the properties of components

Conclusions Problem of integration of several legacy or third party systems or also newly written applications is substantially simplified in software confederations: the autonomous components can provide their services and can use services of the other applications using front-end gates and wrappers. The interface should be and can be problem domain oriented

Conclusion (2) SWC offers a great flexibility hence support the flexibility of enterprise structure. It is the main step towards making software a good engineering product.