The handling of subsidy applications typically crosses several departments and organizations, each of them having their own heterogeneous applications and processes. As such, the automated processing has to overcome an immense interoperability problem. This problem is further complicated due to the continuous stream of changes in and the creation of new legislation. Therefore there is a need for an architecture enabling the orchestration and interoperability of cross-agency processes that is able to deal and able to adapt to ever-changing circumstances. In this chapter the development of a reference architecture based on the analysis of four different types of subsidy processes is presented. This reference architecture is used to ensure interoperability and to derive generic building blocks. The architecture is implemented and tested in practice by building a prototype based on web services technology. The evaluation shows that the reference architecture can be used to improve interoperability and adaptability. Adaptability can be realized using an architecture which is built from generic components and meets the conditions set by the architecture.
TopIntroduction
Organizations are collaborating and interacting more and more within networks of organizations (Milward & Provan, 2003). The creation of such a network requires interoperability to ensure that diverse systems and organizations are able to work together (Scholl & Klischewski, 2007). The obstacles to interoperability are not merely technical. In fact, the technology side may prove the least difficult to address, while the organizational, legal, political, and social aspects may prove much more of a challenge (Scholl, 2005). A truly interoperable organization or interorganizational network is able to access and reuse potential information under its control for various kinds of expected and unexpected purposes (Janssen & Scholl, 2007). Interoperability can be viewed as a challenge, capturing aspects ranging from technology to organization.
The Netherlands has a great variety of subsidy provisioning organizations and there is a large variety of different subsidies targeting all kind of groups. Most of the public organizations providing subsidies are very different in their organizational and operational approaches. This has resulted in many different kinds of applications supporting these processes. The landscape can be characterized by siloed applications, which work in isolation and hardly share or reuse functionality. Functionality is developed over and over again resulting in a huge duplication of efforts. Furthermore, these subsidy agencies share the common problem of being unable to adapt their systems quickly to new or changing legislation. This is caused by the systems themselves and the many different systems in use. The latter results in the need to update each system independently of other systems. Subsidy processes and supporting systems are tightly coupled and a change in one of them leads to a lot of organizational and operational costs and causes delays which are not desirable.
Nowadays, individual public agencies make their functionality and even complete business processes accessible using web services. More and more organizations make use of web services and web service technology to coordinate their cross-agency processes. These web services can be orchestrated to create a cross-organizational business process (Janssen, Gortmaker, & Wagenaar, 2006). Service-oriented architectures (SOA) are becoming the prominent paradigm for building enterprise information systems (Rezgui, 2007). The SOA paradigm offers many benefits to enterprises, and allows us to create Web services are modular, accessible, self-describing, implementation-independent, interoperable and reusable components that can be published and remotely invoked (Fremantle, Weerawarana, & Khalaf, 2002). SOA is expected to improve adaptability, as new processes can be build out-of-existing services. The basic idea is that by replacing, removing and/or adding components a process can be changed. Moreover, modules can be changed without affecting the other components if interfaces do not change.