Keywords

1 Introduction

Although Web services and their associated tools and standards enable an implementation of SOA at infrastructural and technical levels, SOA does not have to be limited to these levels. The OASIS definition of SOA as “a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains” [39] emphasizes some characteristics of SOA shared with a set of organizations which mutually collaborate to achieve common or compatible goals. Collaboration among organizations enables them to gain and retain their competitive advantages, especially in highly dynamic and competitive business environments. Due to collaboration, organizations may focus on their core competences and offer high quality services to collaborating organizations, which, as a consequence, permits the whole set of collaborating organizations to provide competitive products and services on the market.

Moreover, application of SOA at the inter-organizational level enables collaborating organizations to work in a more user-centric manner, i.e., to focus on addressing particular needs of their customers in a personalized way. Services and SOA are appropriate for the implementation of user-centric collaborative organizations: the concept of a service, which is at the fundament of SOA, is defined by OASIS [39] as follows: “a service is the mechanism by which needs and capabilities are brought together”. In the context of collaboration among organizations, this definition of a service by OASIS focuses exactly on the matching of the needs of users and the capabilities of an organization or a set of organizations to answer these needs.

Although implementations of SOA at the inter-organizational, infrastructural, and technical levels share many common concerns, such as orchestration of services, reliability issues, and service instance selection, the SOA ecosystem at the inter-organizational level has two specific characteristics. First, the SOA ecosystem at the inter-organizational level is often highly regulated. For example, in the private sector, the pharmaceutical industry is highly regulated, so organizations operating in this industry have to encompass constraints following from the regulations into their collaboration with other organizations. In the public sector, the construction segment is highly regulated: many administrative procedures have to be performed prior, during, and after the construction of a building.

Second, the SOA ecosystem at the inter-organizational level is often a highly competitive and dynamic environment. In a globalized economic environment, organizations are often competing at a global scale. New organizations are created on a daily-basis, however, for instance in the USA, more than 50 % of them do not survive 5 years [62]. Therefore, new potential collaborators appear continuously, while many already collaborating organizations disappear.

In the case of the application of SOA at the inter-organizational level in highly regulated environments, the problem of flexibility of collaborative processes arises. In such environments, collaborative processes have to be modeled in a way supporting a large variety of cases, such as testing a new drug for flu on diabetic autistic children or conducting an administrative procedure to issue a building permit for various types of constructions like residential buildings, housing estates, shopping centers, roads, bridges, airports, levees, etc. In the case of the application of SOA at the inter-organizational level in highly competitive and dynamic environments, the problem of adaptation of collaborative processes arises. In such environments, collaborative processes have to be modified at run time to deal with unforeseen situations, such as organization withdrawal from collaboration or a natural disaster delaying construction work.

In this chapter, two main problems of the application of SOA at the inter-organizational level are addressed, namely, collaboration flexibility and adaptation. The CMEAP approach—Composable Modeling and Execution of Administrative Procedures—is proposed to tackle flexible administration procedures carried out in an automated manner. Adaptation of service protocols is proposed as an approach to support adaptation of inter-organizational collaboration.

The remainder of this chapter is organized as follows. In Sect. 2, basic notions used in this chapter are defined. Next, the importance and the characteristics of inter-organization collaboration are detailed in Sect. 3. Then, two approaches to computer support for collaborative processes are proposed in Sect. 4, addressing both the flexible automation of administrative procedures and the adaptation of collaboration processes. In Sect. 5, the application of SOA at the inter-organizational level is presented in the context of the construction segment, followed by two case studies detailed in Sect. 6. Finally, Sect. 7 concludes the chapter.

2 Basic Notions

The terms traditionally used in SOA can be used in context of collaborating organizations in the following way. In order to achieve their goals, organizations perform activities defined as closed pieces of work [69]. An activity may be a piece of automated work performed by an information system, e.g., a web service for creating invoices, a piece of work performed by a human, e.g., making a decision by a senior executive, or a piece of work performed by an organization, e.g., constructing a residential building. A set of partially ordered activities which realize an objective in a structured manner is called a process [69]. A process instance is a single enactment of a process. A process instance state is a representation of the internal conditions defining the status of a process instance at a particular moment. A process model captures the possibility to execute a given activity in a given state. In public administration, the equivalent term for the process is an administrative procedure or a procedure for short. Formally, the administrative procedure is defined as an ordered set of administrative activities carried out by a public office and other entities which aim at resolving a case through an administrative decision.

Information systems, humans and organizations involved in activities being a part of the process are called actors. A service is an access to a competence of an actor, called service provider, to satisfy a need of another actor, called service consumer, where the access is provided via a prescribed interface [44]. A service perceived by a service consumer corresponds to an activity performed by a service provider. A collaboration arises when two actors alternately and mutually play roles of service consumer and provider. Actors involved in collaboration are called collaborators. A process is collaborative if some actors involved in it are collaborators.

As a generic organizational structure supporting execution of collaborative processes, the concept of Collaborative Networked Organizations (CNO) has been coined by Camarinha-Matos et al. [9]. In this chapter, a Collaborative Networked Organization (CNO) is a network consisting of a variety of actors called CNO members that are largely autonomous, geographically distributed, and heterogeneous in terms of their operating environment, culture, social capital and goals, which conduct processes including at least one collaborative process in order to carry out a particular venture due to the demand from CNO clients.

CNOs may also be considered as structures aiming at “organizing and utilizing distributed capabilities under the control of different ownership domains”. Following the similarities between CNO and SOA characteristics, concepts underlying SOA may be applied at the coarser level of organizations within the context of CNOs:

  • service provisioning and delivery: services are provided by actors to other actors in order to be composed in complex processes;

  • service reuse: a given actor may provide the same service to many actors within the same or different CNOs;

  • service abstraction: the details of the implementation of services offered by actors are usually hidden from other actors, because the implementation of the core services is associated with the know-how capital that give an actor some advantages over competitive actors;

  • service discoverability: knowledge concerning services provided by potential actors is publically available, so that those actors may be identified as potential CNO members;

  • service contracting: services adhere to an agreement, as defined collectively by one or more contracts describing terms of service provision;

  • loose coupling and autonomy: business logic is encapsulated in services with the intention of promoting reuse; actors have control over the logic encapsulated in services; service loose coupling supports aggregation of services into complex processes with a few well-known dependencies;

  • service composition: a complex process provided by an actor is a result of composition of services provided by the actor itself or other actors; services can be composed in one of two ways:

    • service orchestration: collaboration among actors is controlled by one single actor acting as a coordinator responsible for assignment of activities and supervision of their execution;

    • service choreography: actors perform a complex process in collaborative manner, where synchronization of their efforts is based on inter-actor peer-to-peer communication;

  • service monitoring: services provided by actors are constantly monitored by service providers as well as service consumers in terms of conformance with contract terms; various methods are used to verify service executions including audits, acceptance protocols, key performance indicators, etc.

3 Inter-Organizational Collaboration

Organizations always perform their processes in a particular economic, legal, social, political and technological environment which has impact on their success. Current trends: globalization, development and proliferation of information technology, spread of social media, development of electronic, knowledge-based economy and rising competition, are followed by increased complexity, uncertainty, dynamism, turbulence and diversity of organization processes.

In the SOA approach, the environment mentioned above is referred to as a SOA ecosystem. According to OASIS, a SOA ecosystem is defined as “a network of discrete processes and machines that, together with a community of people, creates, uses, and governs specific services as well as external suppliers of resources required by those services” [40].

3.1 SOA Ecosystem at the Inter-Organizational Level

In this section, the concept and characteristics of the SOA ecosystem at the inter-organizational level are presented. A special emphasis is put on economic justification of inter-organizational collaboration and organizational forms supporting it.

3.1.1 Rationale for Collaboration Among Organizations

The main reason for collaboration among organizations is the need for competitive advantage. The first theoretical framework permitting to understand the fundamental need for collaboration among organizations has been proposed by David Ricardo [55] in his book Principles of Political Economy and Taxation. David Ricardo indicated the strategy of specialization as a way to boost efficiency of organization operation. Specialization means concentration of an organization on operations where it has comparative advantage and taking benefits from exchange of goods and services with other specialized organizations. Ricardo has explained that this approach is effective even if an organization is able to produce all the goods and services more efficiently than the other organizations. Ricardo legitimates the collaboration of countries and/or organizations, as a means to improve global efficiency.

The concept of comparative advantage has been extended by Porter [54] with the concept of a value chain. Competitive advantage is defined as an advantage over competitors gained by offering consumers greater value. A value chain is a set of activities related to production processes, marketing, supply, client support, etc. which all together lead to service provision or product delivery that has a value for a final customer. Basing on the value chain concept, two organization strategies leading to competitive advantage were proposed: cost advantage and differentiation. An organization develops a cost advantage by reconfiguring its value chain to reduce costs of as many stages of the chain as possible. Reconfiguration means making structural changes, such as adding new production processes, changing distribution channels, or trying a different sales approach. Differentiation stems from uniqueness and perceived value. An organization focusing on the activities it does best and creating innovative and unique products and services, naturally rises above its competitors. An organization can achieve a differentiation advantage by either changing individual value chain activities to increase uniqueness in the final product or by reconfiguring the entire value chain.

Barney [6] has proposed that “a firm is said to have a competitive advantage when it is implementing a value creating strategy not simultaneously being implemented by any current or potential player”. Focusing on the resources and attributes which provide the competitive advantage to an organization has a deep impact on its performance outcomes, and therefore, should be a fundamental aspect in every business strategy. As a consequence, organizations should specialize to gain a competitive advantage.

Strategy of focusing on the organization operation areas which provide the competitive advantage stressed by Porter and Barney should be a fundamental aspect of every business strategy. This approach leads to narrowing the areas of organization expertise and operation. Meanwhile, in current economy the production and service provision require a large set of skills and resources that a given organization is usually not able to handle efficiently. Thus, modern value chains cover not one but a number of specialized organizations, integrated with each other to perform activities defined within the value chain. Such collaboration creates an opportunity for efficient, cost effective differentiation at each phase of the value chain. Therefore, organizations should not only specialize, they should also integrate with other organizations by providing services to their clients, consuming services of the others allowing exchange of digital and material products.

3.1.2 Pervasive Services

In modern approaches to management of inter-organizational collaboration, the SOA paradigm plays a key role as a way to integrate heterogeneous information systems coming from different organizations [13]. Service orientation is emerging at multiple organizational levels in response to growing needs for greater integration, flexibility, and agility. The world economy is currently in an advanced stage of transformation from a goods-based economy to a services-based economy in which value creation, employment, and economic wealth depend more and more on the service sector [57]. Service-orientation is one of the largest applied paradigms with relevance to accounting, finance, supply chain management and operations, as well as strategy and marketing. The trend is especially significant, visible and economically justified in the sector of small and medium-sized organizations. Integrated, service-based collaboration permits such organizations to leverage the strategies of specialization, differentiation and cost advantage and to compete on the global market with large multinational organizations. The fact of strong service orientation of organizations is confirmed by the statistic data:

  • services sector accounts for 80 % of United States gross domestic product [17];

  • services play a similarly important role in all the OECD countries [16];

  • although, in 2009 in European Union due to financial crisis, services turnover fell by 8.5 % compared with the year before, it rebounded in 2010 increasing by 5.0 % [20] almost reaching the level from before the crisis;

  • global spending on software as a service (SaaS) will rise 17.9 % in 2013 to $14.5 billion, according to Gartner [30]; SaaS market growth will remain strong through 2015, when spending on the software is expected to reach $22.1 billion; North America is the most mature and largest SaaS market, expected to generate $9.1 billion in revenue this year, compared to $7.8 billion last year [30];

  • due to increasing spending on IT services in the healthcare, retail, and transportation sectors, the IT service market is forecast to reach an estimated US $1,147 billion in 2017 with a Compound Annual Growth Rate of more than 5 % during 2012–2017 [35];

  • companies that implement a service-oriented architecture are able to reduce costs for the integration of projects and maintenance by at least 30% [66];

  • in 2010, 32 % of individuals aged 16 to 74 from 27 member states of European Union have used the Internet in the last 3 months, for interaction with public authorities, i.e., using the Internet for one or more of the following activities: obtaining information from web sites of public authorities, downloading forms, submitting filled in forms [22];

  • in 27 member states of European Union in 2010, about 85 % of the 20 basic e-government services were fully available online, i.e., it was possible to carry out full electronic case handling [21];

  • according to the OECD data, in the year 2010, 82 % of businesses from 25 member countries and 42% of citizens from 26 member countries of OECD have used the Internet to interact with public authorities [43].

3.1.3 Supporting Organizational Structures

Efficient collaboration among autonomous organizations based on services is difficult mainly due to differences among them including geographic, legislative, and cultural differences, diverse markets of products and services, constant changeability of customers and suppliers, as well as changeability of law, technology and methods of work. This raises the question of the organizational structures supporting collaboration [11, 12]. In this context, the concept of CNO presented in Sect. 2 has been divided into a number of subtypes of organizational structures described in the literature and applied in practice, such as middle-age guilds, partners clubs, and clusters. The following organizational structures supporting collaboration among organizations have been intensively scrutinized:

  • communities of practice, defined as “a set of relations among persons, activity and world, over time and in relation with other tangential and overlapping communities of practice” [33],

  • virtual teams, defined as “a group of people who interact through interdependent tasks guided by common purpose” that “works across space, time, and organizational boundaries with links strengthened by webs of communication technologies” [34],

  • virtual enterprises, defined as “a temporary consortium of autonomous, diverse and possibly geographically dispersed organizations that pool their resources to meet short-term objectives and exploit fast-changing market trends” [15],

  • virtual organizations, defined as “a geographically distributed organization whose members are bound by a long-term common interest or goal, and who communicate and coordinate their work through information technology” [4].

The services available in the SOA ecosystem are contributing to business processes on markets of services having various forms and levels of formality. For instance, the service market may take the form of catalogs of organizations [18], service auctions [24], IT service parks [49], dynamic business networks [8], Web service ecosystem [7], B2B e-marketplaces [1] or public administration service platforms [27, 38]. Within these markets, service providers offer multiple services that customers can dynamically and on-demand bind into their business processes. The evolution in the area of service publication, discovery and usage recently has shifted from tight coupling of intra-organizational systems to inter-organizational coupling of partners (value chains) using well defined service level agreements to open market of services with new models of licensing comprising abstract processes and dynamic service selection and instantiation [45]. In this context, a concept of Virtual Organization Breeding Environment (VOBE, sometimes abbreviated to VBE in the literature) has been proposed to support dynamic partner and service selection and instantiation of CNOs. A VOBE is “an association of organizations with the main goal of increasing preparedness of its members towards collaboration in potential virtual organizations” [10]. VOBE allows potential collaborators to prepare their future collaboration with other VOBE members before a business opportunity occurs by publication of provided services and provision of other data useful for identification of collaboration chances.

While the concept of VOBE is currently widely accepted in the CNO research community, they vary in terms of the architecture and implementation. Existing VOBEs have been created in an ad hoc manner and have an infrastructure allowing limited support for efficient integration of VOBE members on business and technical levels. In this context, Service-Oriented Virtual Organization Breeding Environments (SOVOBEs) have been proposed as VOBEs organized systematically on both technical and organizational level around the concept of a service allowing SOVOBE members to collaborate better [52].

3.2 Complexity of Collaboration in the SOA Ecosystem

In this section, the heterogeneity and dynamism of SOA ecosystem at the inter-organizational level are described. Then, the concepts of dynamism, flexibility and adaptation are introduced as an approach to addressing the characteristics of SOA ecosystem by organizations.

3.2.1 Heterogeneity and Dynamism of the SOA Ecosystem

In the global economy, the SOA ecosystem is neither homogeneous nor static. Following Porter’s Five Forces theory [53], SOA ecosystem heterogeneity comes from supplier power, barriers to entry, rivalry among organizations, threat of substitute services and buyer power which are different in different business domains. Also, organizations operating in the SOA ecosystem are characterized by different readiness to personalize provided services, level of computer support in service provision, business models, organizational culture, level of formalization of collaboration and internal processes, geographical localization, ability to adapt to SOA ecosystem changes, etc. Dynamics of SOA ecosystem follow from constant changes in the set of organizations, individuals and information systems operating in the SOA ecosystem, changes in their operations and their results having impact on the whole ecosystem.

Complexity of collaborative processes directly follows from the heterogeneity and dynamic nature of the SOA ecosystem. Collaborative process actors constantly gain knowledge through the analysis of information concerning the process context. Moreover, actors learn from each other both explicit and tacit rules governing the execution of a collaborative process. As a consequence of the instantly gained knowledge, actors change the way they perceive the process, activities, semantics of the decisions being made, and the way these decisions have been made. Due to the usually long-lasting character of the collaborative processes, the set of collaborating actors and their roles change, so the set of actors having the holistic vision and understanding of the whole process may be small. Finally, similar instances of a collaborative process—e.g. having a similar goal, involving a similar set of actors, performed at the same time—may be interrelated, which means that the course of execution of one process instance and its result may influence the course of execution of another instance [44].

3.2.2 Run Time Modification of Collaborative Processes

Due to collaborative processes characteristics as well as dynamism and heterogeneity of the SOA ecosystem, it is hard to create a single correct executable model of a particular collaborative process that describes its execution from the start to the very end. Correct execution of collaborative processes require methods for easy and efficient modification of process models ruling collaboration or particular collaboration process instances, where the modification is potentially performed at run time. Such modifications aim to address the actual needs of actors involved in the process and actual context of collaborative process execution.

To precisely define problems related to process modifications, the concepts of process dynamism, adaptation and flexibility have been proposed [56].

Process Dynamism. Process dynamism means changing a process model. The change can be tiny, resulting from the need for corrections or improvements, or drastic, significantly altering the shape of the model. There are four main sources of dynamism: new technology, new management methods, new policies of the organization, and new legislation. Process dynamism is currently well supported by workflow management systems and business process execution engines that allow several versions of a given process, and their instances, to execute simultaneously.

Process Adaptation. Process adaptation means adjusting a process model for an active instance to exceptional circumstances that may or may not be predicted before starting the instance. Adaptation refers to one or possibly a few instances only and does not involve a permanent change of the process model. Process adaptation raises the question: if exceptional circumstances are predictable, why not include them in a process model? An answer is that including all exceptional circumstances in a single model would result in significant complexity and thus make the model difficult to understand and then to execute. For practical reasons, it is better to have a simpler model containing only the main paths, initiate all instances according to this model and, in the event of exceptional circumstances in a given instance, adapt the model for this instance only.

Process Flexibility. Process flexibility means the lack of the full specification of a process model, and constructing such a model uniquely and separately for each active instance at run time. The model is built from pre-defined single activities or sets of activities (fragments of a process), which are selected on an ongoing basis in accordance with the current circumstances occurred in the instance.

As the possibility of modification of collaborative process instances at run time plays a crucial role in the execution of collaborative processes in a SOA ecosystem, in this chapter a special attention is put on methods supporting process flexibility and adaptation. Collaborative processes requiring either flexibility or adaptation may be found both in the private and public sector. The level of regulations concerning a given process distinguishes processes that should be flexible from those that should be adapted. If such regulations are extensive and detailed, then constraints are strict, and the set of possible activities is finite, even if potentially large. Then, flexibility of processes is more appropriate. On the contrary, if the regulations concerning a process are vague and leave room for interpretation, which means that constraints set on a process are weak, then adaptation of processes is more appropriate than flexibility.

An example of a process to which flexibility is well-suited is a healthcare treatment process, highly regulated, independently whether a hospital is private or public. For each patient, the treatment process must be constructed step-by-step, based on current patient’s health state, and results of the previous treatment activities, while the further treatment activities can be selected from a set of available medical procedures following from existing medical knowledge, technology, and pharmaceuticals.

An example of a process to which adaptation is well-suited is a rescue process provided by emergency management centers which have developed procedures of rescue actions for different types of events. Specific activities, in particular the selection of the type and number of rescue units and the organization of collaboration between them, are always adapted to the circumstances of an event which differs from one another.

In this chapter we focus on processes arising in the construction segment, both in the public and private sectors. The legislation governing this segment is very detailed, complex, and spread among various legal acts. These acts can be divided into two main groups. The first group consists of general acts; for example, Administrative Procedure Code which specifies general rules, common for all administrative procedures regardless of the segment they apply to. These general acts are superior ones to the second group of acts, which have much more detailed character and specify rules of a specific class of procedures. For example, Building Code regulates details of a procedure for granting a building permit. Moreover, the course of each procedure can be influenced by acts which are not directly related to administrative procedures at all. For example, Civil Code regulates the issue of granting a power of attorney. If an investor applying for a building permit has appointed an attorney, in such case the administrative procedure must include activities arising out of the Civil Code. Therefore, flexibility is required to manage procedures (processes) arising in the public sector (public administration) for the construction segment. On the contrary, in the private sector of the construction segment, managing processes requires adaptation. Given a construction project, a general process model is predetermined, because it follows from the investment type, technologies planned to be used, legal regulations, etc. A detailed model of the process instance is, however, adapted on an ongoing basis to emerging exceptional circumstances arising during construction. Examples of such circumstances are: too low temperature preventing from pouring concrete or the discovery of an unexploded bomb on construction plot.

4 Approaches to Computer Support for Collaborative Processes

Two approaches to support flexibility and adaptation of collaborative processes are presented in this section. The Composable Modeling and Execution of Administrative Procedures (CMEAP) approach deals with flexibility of processes performed in public administration, while service protocols address the problem of adaptation.

4.1 Flexible Automation of Administrative Procedures

The concept of administrative procedure automation is based on two main assumptions:

  • Information systems take over the execution of all routine activities which are known in advance how to perform them. In administrative procedures, the routine activities are primarily associated with processing information contained in documents and registers, which is perfectly suited to be taken over by information systems.

  • Humans (clerks) released from the routine activities can entirely dedicate their time to making decisions based on information prepared and provided by the systems.

Defined as above, the automation of administrative procedures requires creating very detailed models of these procedures; such models are necessary to direct and supervise the work of information systems. The models must take into account all possible variants of procedure realization, and for each variant they must include all possible operational activities. This section includes the review of traditional approaches to process modeling and executing and outlines problems of applying those approaches to automation of administrative procedures. Then the CMEAP approach based on the concept of process flexibility is presented. As mentioned in Sect. 2, in the public administration area, the term administrative procedure (or procedure for short) is used instead of the term process.

4.1.1 Traditional Modeling and Execution of Administrative Procedures

One of the most common purposes of administrative procedure modeling is work standardization. Public agencies hire analysts to develop the optimal models of administrative procedures and then seek to ensure that their employees (clerks) always carry out the procedures according to those models. The purpose of the standardization is to guarantee the constant high quality of work regardless of the individual competence of a given employee. Currently, the most often used notations for creating work-standardizing models are: (1) EPC (Event-driven Process Chain) standard of ARIS (Architecture of Integrated Information Systems) methodology [5] and (2) BPMN (Business Process Modeling Notation) standard [42] developed by Object Management Group (OMG).

Nowadays, in most of public agencies the execution of administrative procedures is supported by workflow management systems [69]. Such systems store administrative procedure models (often referred as administrative procedure definitions), enable creating and managing their instances, and controlling their interactions with participants; e.g., clerks and information systems (e.g., public registers).

Workflow management systems can be divided into two categories: ad hoc and production [31].

The ad hoc workflow management systems do not make direct use of administrative procedure models. In these systems, work and its flow are performed and supervised by clerks who are responsible for activities ordering and making coordination decisions during the execution [23]. The ad hoc workflow management systems are capable of notifying about new work waiting to be done and when it is completed, of registering what was done, by whom, and when. A clerk must manually, outside the system, consult with the administrative procedure model how to do the work and to whom forward its results. The level of administrative procedure automation offered by the ad hoc workflow management systems is very limited.

A significant step towards the automation of administrative procedures was made with the advent of the production workflow management systems. These systems can be fed with models of administrative procedures and then they are capable of using these models to automate the execution of those procedures [23]. However, the production workflow management systems require the models to be created according to the monolithic approach. The monolithic approach means that a model has a form of a single end-to-end flow. The shape of the flow is defined and embedded in the model at design time and does not change during the execution. Even if the administrative procedures are modeled as a set of models and submodels, the submodels are invoked during execution according to the design.

Therefore, the monolithic approach to modeling makes it virtually impossible to create comprehensive administrative procedure models taking into account all possible execution variants of these procedures, and within each specific variant, all detailed operational activities which should be performed to guarantee that a procedure course complies with all legal circumstances applicable in the variant. This problem follows from the fact that the course of administrative procedure is regulated by the legislation. Two issues relating to the nature of the legislation significantly influence the form of administrative procedure models:

  • Complexity of administrative legislation: If the models of administrative procedures were supposed to include all the details reflecting all possible variants following from the provisions of legislation, they would have to be very complex.

  • The many-to-many relationship between models and legislation: one specific act has an impact on many administrative procedures, and thus on their models, while one administrative procedure depends on the provisions of many acts. As a consequence, any change in the text of any act entails the need to update models of all the procedures to which this act applies if the monolithic approach to administrative procedure modeling is applied.

Due to these problems, currently the models of administrative procedures are usually created at a high level of generality. Such models do not include detailed actions, and therefore they are easy to create, rather small in size, and slightly susceptible to updates reflecting changes in legislation. For example, at the beginning of most administrative procedure models there is an activity named “Check the completeness and correctness of an application and all required attachments”. A model containing such an activity does not specify the conditions under which the specific attachments are required, or what conditions should be met by these attachments. Also, another typical activity occurring in the middle of administrative procedure models is “Inform the relevant authorities of the action taken” or “Turn to the appropriate authorities for review and agreement”. The models containing the activities defined at a high level of generality remain valid even in the case of multiple changes in legislation.

Thus, the models created in accordance with the monolithic approach can be used to automate the administrative procedures using workflow systems [63], but such automation is very limited. Clerks are supported by workflow systems in monitoring the course of the procedures. The system can also indicate which activities to undertake and registers completed ones. However, the execution of the activities remains a responsibility of a clerk, who has to analyze and interpret the general specifications of activities contained in the models, and decide how to translate these specifications into low-level operational activities for different cases. In this way, a detailed model of the administrative procedure performed for a specific case is created ad hoc by clerks at run time. Therefore, this type of automation should be classified as the human-driven automation.

The main problem of the workflow systems is subjectivity. The course of a specific procedure depends on the individual competence and experience of a clerk who conducts it. There is a high probability that a less competent clerk will misinterpret a general activity specified in the model and as the result conduct the whole procedure in a wrong way. Similarly, courses of two discrete cases with the same conditions may significantly differ from one another just because they were conducted by two different clerks, although they should be identical.

As a response to the limitations imposed by the monolithic approach, Adams in [3] has proposed a concept of worklets. Based on the activity theory, he has assumed that each activity in a process can be performed in several different ways. The ways have been named worklets. The single worklet consists of operations needed to complete the activity it refers to. A worklet selection is performed at run time and is based on examining contextual information related to a given process instance. However, in the worklet approach it is assumed that there is a top-level process model ruling the selection of appropriate ways to accomplish activities. The approach introduces a relaxation of the rigid monolithic modeling, but does not eliminate its main drawback which is the necessity to create a model for a whole process in the end-to-end form.

4.1.2 CMEAP Approach to Flexible Automation of Administrative Procedures

In this section, a novel approach to modeling and executing of administrative procedures, called Composable Modeling and Execution of Administrative Procedures (CMEAP), is presented [59]. The approach enables generating models of administrative procedures consisting of all operational activities that must be performed for different cases due to the applicable legal circumstances. At the same time, the level of details in activity mapping is high enough that there is no need to interpret them by clerks, and thus it is possible to automate their execution within information systems.

In the CMEAP approach, modeling of administrative procedures based on the end-to-end monolithic approach is entirely abandoned. Instead of associating a single end-to-end model or a set of firmly connected models and submodels with the course of each procedure, the CMEAP approach is based on modeling legislative provisions in a form of elementary processes, decision rules, and domain ontology. The course of the administrative procedure for a specific case is dynamically composed from elementary processes based on current legal circumstances occurring during execution of that procedure. The legal circumstances are represented by instances of ontology concepts and recognized by decision rules. In this way, every execution of an administrative procedure has its own unique model, closely corresponding to the specifics of the case the execution applies to. Therefore, in the CMEAP approach, modeling of administrative procedures consists of creating elementary processes, modeling ontology, and defining decision rules.

An elementary process is a sequence of activities determined by legislation to be executed in a course of an administrative procedure and constituting an operational entity. Activities of the elementary process may be performed by humans, IT systems or both; i.e., humans assisted by IT systems. An example of an elementary process is checking whether the person in a photo intended to be placed in an ID card wears dark glasses and if so, verifying a disability certificate prescribing continuous use of such glasses.

The ontology is a conceptual model of a specific domain describing concepts of this domain [64]. The instances of ontology concepts are called facts and represent real or abstract objects from the domain which can be involved in the execution of administrative procedures. An example of a real object is an applicant named John Brown represented by the fact being an instance of the domain concept Applicant. An example of an abstract object is the legal capacity of the applicant John Brown represented by the fact being an instance of the domain concept LegalCapacity. The concepts in the ontology may have attributes describing their characteristics. The Applicant concept attributes are firstName, lastName and SSN, which for the applicant John Brown take actual values, e.g.: John, Brown and 518-84-4887, respectively. The LegalCapacity concept has an attribute type, which for John Brown’s legal capacity takes value full while other possible values are partial and none [58].

The decision rules specify legal circumstances which when occur during the course of an administrative procedure make necessary to execute a specific elementary process. The legal circumstances in the administrative procedure execution are represented by facts. A single decision rule is a structure consisting of two sections, the when section (often also called the if section) and the then section. The when section contains conditional expressions relating to the existence (or absence) of certain facts and to the attributes of these facts. The then section contains a set of actions. The conditional expression in the when section is considered to be true if there is a fact which attribute values are consistent with the values specified in the condition of the when section. The rules having the when section evaluated to the true value are selected to be fired. Firing a rule involves executing actions included in the then section. As the rules are independent of each other, it is possible to select more than one rule to be fired.

The CMEAP approach consists of the following logical components [59]:

  • Knowledge Base;

  • Composition Server;

  • Process Server.

The interrelation of the components together with their behavior is presented in Fig. 1.

Knowledge Base. The Knowledge base is a central repository storing knowledge artifacts of administrative procedures; i.e., elementary processes, ontology, and decision rules. The knowledge is divided into terminological and assertional one. The terminological knowledge includes elementary process models, ontology model, and decision rule definitions. The assertional knowledge includes instances of elementary processes, facts (instances of ontology concepts), and instances of decision rules.

Fig. 1
figure 1

Components of the CMEAP approach

Full size image

Composition Server. The Composition server is the main component of the system, supervising and steering all other components. The server is responsible for dynamic composition of administrative procedure courses. The server operates according to the following general algorithm.

The first phase of the algorithm is the analysis of facts which emerge at a given moment of administrative procedure execution. Based on the analysis results, there is made a choice of decision rules to be fired. Firing a rule involves executing actions included in its then section. The result of executing a single action can be asserting, updating or retracting a fact (a change of facts in general), or selecting the elementary processes which should be executed at this stage of the administrative procedure execution.

If a change of facts has occurred as the result of firing a rule, the Composition server goes back to the fact analysis phase and checks if this change has evaluated any rules to be fired. The loop is repeated until the facts and rules reach the stable state; i.e., there are no rules evaluated to be fired.

Process Server. If some elementary processes are selected as the result of firing rules, the Composition server triggers the Process server to execute them. The tasks included in the elementary processes can be divided into four types:

  • Interactions with public registers;

  • Processing electronic documents;

  • Executing human tasks;

  • Operating on facts.

Interactions with public registers include accessing and processing information collected in these registers. A public register is a collection of information on citizens, businesses, things, or entitlements. Examples of information collected in the public registers are: date of birth, marital status, date of death, names of persons entitled to represent a company, lists of decisions issued by public authorities. Examples of the decision lists are the following: a list of building permits issued, a list of professional licenses authorizing their holders to deliver certain types of services, details of a local spatial development plan. According to legal circumstances that occur in the course of an administrative procedure, interaction with public registers include updating existing data, inserting new data, or reading data for further use in the course of the administrative procedure. In the latter case, data retrieved from the public register are inserted into the Knowledge base as assertional knowledge.

Processing electronic documents includes an analysis of their content. In order to make such analysis feasible, electronic documents must have a structured form; i.e., the semantics of each piece of information included in them must be precisely specified. The appropriate technology here is XML Schema [65]. Information retrieved from electronic documents can be fed into public registers and/or can be inserted into the Knowledge base as facts, because this information is an essential source of legal circumstances relevant in the execution of the administrative procedure and therefore it can affect its further course.

Human tasks represent activities to be performed by humans (clerks). In an ideal electronic government based on the administrative procedure automation, human tasks involve only non-routine activities, i.e., those that cannot be implemented as a software package executed by a computer system [68]. The principle activity of this type is decision-making. Currently, however, human tasks, also often include routine activities which, due to technical problems, cannot be implemented as software. These activities include processing of paper documents or unstructured electronic ones, and processing data in public registers which do not have interoperable interfaces for external IT systems. As the process of replacing paper documents with electronic ones is progressing and the number of public registers with interoperability capabilities increases, human tasks will involve a declining number of routine activities.

Operating on facts includes tasks of technical nature related to reading, inserting, updating, and deleting facts from the assertional part of the Knowledge base.

If as the result of executing an elementary process, a change in facts occurs, the Composition server proceeds to the first phase of the algorithm. The composition of the whole administrative procedure model completes, and so the execution of the procedure, when the whole system reaches the stable state; i.e., when there are no more elementary processes selected for execution as a result of firing rules, and when there are no more changes in facts as a result of executing elementary processes.

4.2 Adaptation of Collaborative Processes

Efficient computer support for CNOs involving private organizations has to take into account the characteristics of collaboration introduced in Sect. 3. Methods effectively supporting collaboration in the private sector must exhibit the following characteristics:

  • support for adaptation: computer support for collaboration should allow actors to adapt to new situations. Adaptation should enable modifications of the set of actors, the set of activities, the set of services, and their ordering. The adaptation method should provide means to restrict possible modifications that may be applied during an adaptation process;

  • a prescriptive approach: computer support for agile collaboration should rely on prescriptive models. Such models define constraints on the sets of actors, activities, services, their relationships, and potential changes of these sets during adaptation;

  • a computer supported approach: according to the computer supported approach, information system provides tools for human actors to make decisions, instead of making decisions on behalf of them, in opposition to the automated approach. The decision making should remain under responsibility of human actors, due to the influence of social norms and tacit knowledge on decisions, which are elements that may hardly be taken into account by information systems;

  • a collaborative approach: adaptation of collaborative process models itself should be conducted in a collaborative manner.

The above characteristics constitute a foundation for definition of requirements concerning methods supporting three main phases of collaborative process execution: (1) specification of a collaborative process model [50], (2) instantiation of a collaborative process model [46] and (3) adaptation of collaborative processes instances [50].

Below, specific requirements concerning methods supporting each of the above three phases are defined. Then an approach based on the concept of service protocols is presented.

4.2.1 Requirements for Computer Support for Collaborative Processes

Specification of a Collaborative Process Model. Two aspects of collaborative processes in CNOs have to be addressed to tackle unpredictability and emergence that arise during CNO operations. The unpredictable aspect of CNO collaborative processes refers to the difficulty to plan in advance a partially ordered set of activities to reach an expected goal. The emergence aspect of CNO collaborative processes refers to the influence of the process instance execution on the process instance itself and/or the process model. To address these two aspects, the following main requirements for computer support for methods supporting modeling collaboration are defined:

  • separation of activities implementation from the process model: a collaborative process model should include potential interactions among collaborators, however, the interactions should be decoupled from implementation of the activities performed by collaborators. As a consequence, activities of a given collaborative process model may be implemented in different ways, using different technologies, or different locations/hosts;

  • modeling shared responsibility: in a collaborative process, responsibility for execution of activities is shared by different actors. Collaborative process model should express the responsibility of service consumers for invocation of services as well as the responsibility of service providers for the execution of services;

  • constraints on actors: collaborative process model must support the definition of constraints on actors, both service providers and consumers. Constraints on actors can be then used as means to define the obligations that an actor has to fulfil to participate in the collaborative process. Constraints on actors should concern different aspects of actors such as their competences to perform a given activity;

  • relational constraints: due to the importance of social aspects in CNO operation, collaborative process models have to support the definition of relational constraints between actors. Relational constraints concern activities that may be performed only by actors with appropriate relations with other actors. Computer support for collaborative processes should treat relational constraints as an integral part of the model of collaboration processes;

  • reusability: a collaborative process model should be reusable in a similar way as a class models a set of objects in object-oriented programming: different instances of a collaborative process may rule different CNOs.

Instantiation of a Collaborative Process. During collaborative process instantiation, a set of actors and services is selected. Proper selection of actors and services determines to large extent the success of CNO operation [47]. The specific requirements for a method supporting instantiation of a collaborative process are the following:

  • continuous instantiation: the selection of actors and services should not refer to the whole collaborative process at once at the beginning of CNO operation. Instead, in order to address unpredictability and emergence of collaborative processes, instantiation should be performed throughout the whole CNO operation;

  • multi-stage approach: as the selection is not performed for the entire collaborative process at once, the selection process itself should be divided into stages, where each stage concerns the selection of a subset of actors and services;

  • multi-criteria analysis: a method supporting collaborative process instantiation should encompass the constraints concerning actors, services and relations among them that are captured in the collaborative process model;

  • analysis of correlations among different instantiation processes: the results of selection performed at previous stages should be considered during the next stages of the selection process. For instance, if a selection is performed for an activity “cleaning of construction site” it might be useful to consider who was selected to perform preceding activity “building demolition”, as particular techniques used to demolish a building may force special cleaning techniques;

  • collaborative approach: the selection of actors and services requires the involvement of people potentially belonging to different organizations, having different experience and knowledge, who are able to analyze and decide about the pertinence of the choice of given actors and services;

  • dynamic set of selection process actors: the set of collaborators who are selecting actors and services, referred to as the selection process participants, may change over time.

Adaptation of Collaborative Processes and Their Instances. When a situation faced by collaborators imposes changes on the model ruling their collaboration, adaptation has to be performed. Specific requirements for methods supporting the adaptation of collaborative processes and their instances are the following:

  • adaptation as a collaborative process: adaptation of a collaborative process is a collaborative process itself. The CNO collaborative process, referred to as the adapted collaborative process, is modified by another collaborative process, referred to as the adapting collaborative process;

  • dynamic set of adapting process actors: a set of actors adapting a collaborative process, referred to as adapting collaborators, may change over time. This set consists of freely defined set of actors including actors executing the adapted collaborative process, referred to as adapted collaborators;

  • weak coupling between adapting and adapted processes: the coupling between the adapting and adapted collaborative processes should be weak, i.e., no constraint should be set on the overlapping of the sets of adapting and adapted collaborators;

  • structured collaboration: the collaboration within an adapting collaboration process should obey rules that limit the activities that may be performed by a given adapting collaborator at a given moment. Rules may originate from social norms, collaboration techniques, or collaboration culture;

  • modeling multi-faceted changes: the model of adapting collaborative process should allow adapting collaborators to define the changes they propose to tackle the situation being a reason for adaptation;

  • support for contextual change propositions: adaptation of collaborative processes should encompass the contextual character of change propositions. Contextual information about a given change proposition improves the understanding of the reason for the submission of the change proposition;

  • reusable models of collaboration during adaptation: a given model concerning collaboration during adaptation should be generic enough to be applied in various adaptation situations.

4.2.2 Support for Collaborative Processes in Existing Approaches

Different approaches to modeling and management of processes has been proposed in the literature. Existing approaches do not satisfy the requirements imposed on methods supporting collaborative processes [50] due to the following features:

  • static set of process actors: in the existing approaches, experts in process modeling and experts in a given knowledge domain collaborate at design-time to define process models. Next, these models are instantiated and performed by the employees of the organizations in which the process models have been deployed. Employees participating in the process instances are knowledge domain experts but are rarely involved in the definition of the process model, each situation requiring a modification of the process model is tackled by a set of experts in process modeling that occasionally consult knowledge domain experts. Such approach imposes limits on efficient adaptation mechanism as changes in the process cannot be performed only by actors actually performing the process;

  • singular service consumer: in the existing approaches, a single service consumer and multiple service providers are assumed. For instance, the execution of a BPEL process consists in the invocation of service provided by various service providers but the BPEL engine executing the BPEL process is the only service consumer [41];

  • limited constraints: in the existing approaches, process models focus on the set of activities and their partial ordering. The concept of role is used to limit the execution of a given activity to actors with appropriate rights. The role definition is usually limited to a label associated with a set of activities that may be performed;

  • unsupported social aspects: although in the existing approaches the importance of social aspects in collaborative processes has been largely studied, existing methods of process modeling still lack support for relational constraints. Most process modeling languages and notations do not provide designers of process models with means to explicitly capture social requirements concerning actors in process models;

  • one-time instantiation: in the existing approaches, the instantiation of a process consisting of the assignment of actors, activities, and services is done at once for the whole process and this assignment cannot be modified at run time.

4.2.3 Service Protocols

While CMEAP is proposed as an approach to support flexibility in administrative procedures, service protocols are proposed as an approach to support adaptation of collaborative processes in a dynamic environment.

As a preliminary remark, service protocols are different than communication protocols: although communication protocols define message formats and rules for the exchange of messages among computer systems, service protocols focus on three aspects of human-to-human interactions: processes, service-orientation, and social aspects.

A formal model of service protocols and their adaptation may be found in [50].

Specification of a Service protocol. A Service protocol consists of three elements: a process model, a service-oriented summary of a process model, and a service network schema.

As mentioned in Sect. 2, a process model defines a set of partially ordered activities to be performed during process execution.

A service-oriented summary of a process model provides a representation of the activities of the associated process model in SOA terms, independently of the process modeling language, e.g., BPEL or BPMN. In a service-oriented summary, each activity of the process is associated with a service represented by a service description. A service description is a triplet defining the “who” (the service consumer), “what” (the service interface), and “whose” (the service provider) part of the activity.

Information about service entities, i.e., service providers, service interfaces, and service consumers, are captured in a service network. A service network is a set of linked service entities, i.e., service providers, service interfaces, and service consumers. Service network aims at capturing properties and relations among service entities. In the proposed approach, a service network is the source of service implementation used to instantiate service protocol.

A service network schema is a graph that restricts the set of potential service entities that may participate in a service protocol by defining constraints on nodes and arcs [51], as predicates. Constraints imposed on nodes, i.e., isolated actors and service interfaces, are referred to as classes of service entities. Constraints imposed on arcs are called social requirements. The constraints should be taken into account when selecting service entities, i.e., actors and service interfaces, during instantiation of the collaborative process model. A service entity is an instance of a class of service entities iff it satisfies all the constraints defined by the class of service entities.

The concept of service protocol may be applied at four levels that differ mainly with regard to the availability of information concerning the chosen service consumers, providers, and interfaces:

  • at the abstract level, a service-oriented summary provides a service-oriented representation of a collaborative process model, a service network schema provides constraints on service entities and social requirements, and both the service oriented summary and the service network schema are linked to associated service descriptions (from the service-oriented summary) with classes of service entities (from the service network schema);

  • at the prototype level, service entities of a service network are associated with both service elements of the service-oriented summary and the classes of service entities of the service network schema. At the prototype level, the service network provides only a partial implementation of an abstract service protocol, as some elements of the service-oriented summary and some classes of service entities of the schema may not be associated with any service entity of the service network;

  • at the executable level, the service network associated with both the service-oriented summary and the service network schema provides a complete implementation of an abstract service protocol: all the service elements of the service-oriented summary and all the classes of service entities of the schema are associated with service entities of the service network;

  • at the instance level, an executable service protocol is enacted. At the instance level, service entities defined at the executable level consume and provide services modifying the state of the process model.

Service protocols address the requirements concerning methods supporting specification of collaborative processes. Service protocols provide a prescriptive model of collaboration: specification of the allowed partially ordered set of activities is provided by the process model, with their representation as service descriptions in the associated service-oriented summary, while the choice of the service elements is restricted by the service network schema. Four levels of abstraction cope with the requirements of reusability and separation of activity implementation from the process model. Service network schema encompassing classes of service entities and social requirements satisfies requirements concerning constraints of actors and relations as an immanent part of the process model. Finally, by distinguishing the roles of service consumer and service provider in service description associated with activities, service protocols tackle the problem of modeling responsibility for service invocations and execution.

Instantiation of a Service Protocol. A service protocol is instantiated as a result of a selection process of service entities from a service network according to the constraints defined in a service network schema. The selection of appropriate service entities is done from among all the service entities existing in the service network, where selected entities must be instances of appropriate classes of service entities and satisfy relational constraints defined in the service network schema.

The selection process consists of a set of stages, possibly overlapping in time, where each stage aims at identifying service entities being instances of a subset of classes of service entities defined in a service network schema.

The execution of the selection process encompasses:

  • the definition of stages, i.e., classes of service entities to be instantiated in each stage,

  • the execution of all defined stages,

  • if applicable, as selection process proceeds, i.e., subsequent stages are executed, redefinition of the set of stages.

Every stage of selection process consists of four phases:

  1. 1.

    constraints modification: if needed, possible modification of constraints defined in the service network schema;

  2. 2.

    contractor analysis prior negotiations: a set of acceptable potential collaborators and their services is created for each class of service entities;

  3. 3.

    contractor analysis during negotiations: a set of potential collaborators created in phase 2 is updated on a basis of negotiations conducted with them;

  4. 4.

    stage conclusion: the best service entity for each class of service entities is selected and, if applicable, final collaboration conditions are set.

In each phase, collaboration is performed. The collaboration takes form of negotiations, i.e., an exchange of offers concerning possible assignment of a particular service entity to the class of service entities. Negotiations are restricted to selected CNO members. Actors involved in the selection process are CNO members, actors supporting selection process, and organizations being potential new service customers and service providers in CNO collaborative process. Supporting institutions may include domain experts, public administration unit representatives, legal and technical advisors, non-government organizations. Collaborators selecting service entities for the service protocol are generally different from collaborators executing the service protocol being instantiated. Some collaborators take part only in the selection process. At the same time, some CNO members are excluded from the selection process. Finally, some of collaborators takes part in both. The set of collaborators may change depending on selecting process stage and a set of classes of service entities being instantiated.

The collaboration among actors takes place on two levels:

  • among CNO members and actors supporting selection process—appears in all phases;

  • among CNO members and organizations being candidates for service consumers and service providers—takes place in phases 2–4.

In the proposed approach, a service network contains information about service entities and their relations, including for instance organization competences, legal status or formerly performed projects. In case of service interfaces, information may include service average execution time or service cost.

The submission of offers by selection process participants in phases 2 and 3 are supported by an appropriate decision supporting tool encompassing the selection process participants’ needs specified as:

  • individual preferences: optimal values, reject values and weights referring to classes of service entities and social requirements used in selection process stage;

  • individual fitness functions: functions taking into account potential collaborator characteristics and selection process participant preferences used for ranking service entities and their sets according to required satisfaction levels.

The definition of preferences and fitness functions allows the service entities best suited for a particular class of service entities to be automatically suggested. Social requirements are also taken into account for the suggestion of a set of service entities matching a set of classes of service entities. Different tools may be used for this purpose. For instance, a genetic algorithm may be used for generation of the best acceptable service entity sets ranked according to a fitness function.

The approach proposed above addresses the requirements defined for CNO instantiation. The concept of stages encompassing instantiation of a subset of classes of service entities addresses the requirement of continuous instantiation and multi-stage approach. Requirement of multi-criteria analysis is satisfied by analysis of classes of service entities and relation constraints supported by decision support mechanism that does not make decision on behalf of the selecting collaborators, but generates suggestions, improving the efficiency of selection. Analysis of relations existing in a social network allows correlations among different instantiation processes stages to be analyzed. Finally, the above approach to service protocol instantiation tackle the problem of collaborative processes: the selection process is performed by a number of participants being CNO members or not, where the group of selection process participants is dynamic.

Adaptation of a Service Protocol. The model of adaptation of service protocols proposed in this section is based on the concept of a meta-protocol [50]. A meta-protocol is a compound of two service protocols: adapting and adapted ones. An adapting service protocol rules the collaboration between adapting collaborators aiming at defining the changes to be applied to an associated adapted service protocol.

To address the requirements of a dynamic set of adapting collaborators and weak coupling between adapting and adapted processes, analogously to the selection process the set of adapting collaborators is in general different from the set of adapted collaborators. Some collaborators are adapted, but not adapting ones. Other collaborators are adapting, but not adapted ones, while yet other collaborators are both adapted and adapting ones. During adaptation of service protocols, adapting collaborators confer about changes that may be applied to the adapted service protocol to tackle the situation faced by the adapted collaborators.

The adapting collaborators collaborate according to the adapting service protocol. An important type of activities in adapting service protocols are activities applying change propositions to the adapted service protocol, referred to as adapting actions.

Adapting statements are activities performed by the adapting collaborators during the execution of the adapting service protocol instance, aiming at the definition of an adapting action. The execution of adapting statements may be considered as a negotiation concerning potentially many change propositions.

A change proposition differs from an adapting statement. A change proposition defines a potential change to be applied to an adapted service protocol instance. An adapting statement defines the position of an adapting collaborator about an adapting proposition: in an adapting statement, an adapting collaborator may submit a change proposition for discussion, another adapting collaborator may reject this change proposition.

The collaborator performing an adapting statement may express his/her opinion concerning the change proposition that may take different forms such as: commenting, acceptance, rejection, supporting, and abhorring. The set of available forms of expressing opinions is limited by the adapting service protocol. The possibility to express a given opinion is controlled by the adapting service protocol. The possibility to express acceptance of a given change proposition may be limited to a few adapting collaborators having appropriate power of decision.

The opinion of a given adapting collaborator concerning a change proposition may be justified within an adapting statement. The explicit justification for the opinion of his/her author with regard to a given change proposition improves the collaboration because it reduces the misunderstanding of other adapting collaborators with regard to the adapting statement. Although the proposed model of adaptation of service protocols does not define a set of adapting statement types, each type of adapting statement in an adaptive service protocol should provide support for expressing justification. The proposed model of adaptation of service protocols does not assume a given structure for adapting collaborators’ justifications. In some applications, a justification may be an unstructured plain text document. In other applications, it may be structured, and contain multimedia such as illustrative video or audio recordings.

An adapting statement may contain a list of links to appropriate information for a good understanding of the adapting statement by collaborators.

Adaptation of service protocols exhibits the characteristics of methods effectively supporting collaboration in the private sector mentioned in Sect. 4.2. First, adaptation of service protocols allows collaborators to adapt to new situations by applying changes to the adapted service protocol instance, which is the first feature, i.e., support for adaptation. Second, meta-protocols constraint the interactions among adapting collaborators by enforcing the adapting service protocol to be respected, which is related to the requirement of a prescriptive approach. In the proposed approach, meta-protocols support the adaptation process, but do not make decision on behalf of the adapting collaborators, addressing the requirement of a computer supported approach. Finally, the proposed method is collaborative, conforming to the fourth required feature of methods effectively supporting collaboration in the private sector.

5 SOA in the Construction Sector

The PEOPA and ErGo systems are technical implementations of theoretical concepts presented above. PEOPA is a system supporting execution of administrative procedures, while ErGo is designed to support collaboration among private organizations. Both systems have been developed for application in the construction sector.

In this section, first characteristics of the construction sector justifying usage of the SOA approach and other concepts presented in previous sections are introduced. Second, real-estate construction investment lifecycle is described. Then, a nature of interactions among major players in the investment process and the nature of administrative procedures performed in this sector are presented. Finally, functionality of PEOPA and ErGo systems is described in detail.

5.1 Characteristics of the Construction Sector

In this section, selected characteristics of the construction sector, especially important for real-estate developers, are presented, starting with the complexity of the construction investment lifecycle and ending with the heterogeneity of real-estate developers. In the presented characteristic of the construction sector, the term “real-estate developer” is used as an orchestrator of the development process, i.e., an organization that makes a land or a building suitable for commercial, industrial, or residential purposes, delegating the construction activities to subcontractors.

5.1.1 Complexity of the Construction Investment Lifecycle

A development process concerns the construction of new buildings on a purchased plot of land. The development process is complex and consists of many phases. It differs from one construction investment to another, some phases being optional. However, a common structure can be established: a preparation phase is followed by a construction phase, an operation and maintenance phase, and an estate selling phase.

Preparation Phase. Each development process starts with the preparation phase. The ultimate goal of the preparation is to obtain a construction permit for the construction phase. In the preparation phase, a real-estate developer identifies and acquires a plot of land, potentially supported by a financial institution. The acquisition of the plot of land involves the former owners of the plot and the real-estate developer as well as public agencies, e.g., a cadastral agency. The acquisition is often based on topographic surveying services, aiming at gathering data about the contours of the terrain, as well as the land features. Geotechnical surveys are also often required to evaluate the quality of the ground, which influences the price of the plot of land.

When the plot of land has been bought, a construction project has to be developed. Architects are usually responsible for the design of the blueprints of the buildings. However, the preparation of a construction project usually involves many other organizations, mainly public agencies that have to delivery certificates, opinions, and permits. An example is the involvement of the Department of Transport and Roads that have to approve the part of the project concerning the connection of the developed property to the existing road network. The city of Vancouver mentions the following set of departments, work groups and staff consulted when necessary for advice concerning construction permits: Area Planner, Heritage Planner, Industrial Lands Planner, City Drug Policy Coordinator, Social Planning, Housing Centre, Building Processing Centre, Fire and Rescue Services, Environmental Protection, Licenses and Inspections, Legal Services, Police, Vancouver Coastal Health, Park Board [14].

When the construction permit is delivered by the appropriate local public agency, the preparation phase is over and the development process evolves to the construction phase.

Construction Phase. The goal of the construction phase is to build buildings according to the construction permit delivered during the preparation phase.

In the construction phase, real-estate developers do not build themselves. They delegate all the construction-related activities to subcontractors. The role of real-estate developers is to coordinate construction activities performed by subcontractors. Real-estate developers are therefore considered as service consumers, while their subcontractors as service providers.

During the construction phase, a large variety of specialists with various competences are needed to build or renovate the buildings: electricians, plumbers, carpenters, masons, excavators, drywall hangers and painters. These specialists are usually contracted by real-estate developers with short-term contracts. Even in middle-size projects, real-estate developers often sign a dozen contracts with a given subcontractor. As a consequence, the management of all the contracts signed during the construction phase is often a complex task.

The construction phase ends when the building is ready for occupancy, i.e., after the delivery of the certificate of occupancy by the appropriate authority. The delivery of the certificate of occupancy is usually preceded by a series of inspections, e.g., fire alarm and elevator inspections.

Operation and Maintenance Phase. The goal of the operation and maintenance phase is to assure that the built facility performs the functions for which a property was designed and constructed. The operation and maintenance phase is optional.

In the operation and maintenance phase, real-estate developers manage day-to-day activities needed for proper functioning of the building. Operation and maintenance activities include janitorial, cleaning, lift maintenance, and waste removal activities.

Activities are usually outsourced to organizations specializing in a given type of activities. As a consequence of the wide spectrum of activities to be performed during the operation and maintenance phase, the real-estate developer usually has to contract activities from a large number of organizations providing different services. Besides day-to-day activities, a set of activities related to the rental of commercial space are performed during the operation and maintenance phase, especially for commercial investments, e.g., malls and warehouses. The management of rental contracts as well as tracking the issues reported by the renting organizations is the core aspect of the operation and maintenance phase. In the case of large malls in which the number of renting organizations exceeds one hundred, the management of rental contracts is a complex task. Similarly, capturing, updating, and resolving reported customer issues is also a crucial and demanding activity.

Selling Phase. The goal of the selling phase is to transfer the ownership of the built estate property from the real-estate developer to new organizations, as in the case of commercial properties, or individuals, as in the case of residential properties. The selling phase is optional.

In the operation and maintenance phase, the real-estate developer aims at providing potential buyers with information regarding the estate property. Potential buyers usually investigate the estate property prior to signing the property transfer contract. The investigation process is usually referred to as “due diligence”. Real-estate developers are involved in the preparation of property condition assessment (PCA) to assess the value of the estate property. Ten areas are covered in PCAs: the building site, the building envelope, structural elements of the building, interior elements, roofing systems, HVAC (Heating, Ventilation, and Air Conditioning), plumbing, electrical systems, vertical transportation systems, life safety systems. An important part of PCAs concerns the costs of immediate and necessary future repairs. PCA reports provide precise information about the state of the estate property. Therefore, PCAs are often a basis for price negotiations and financial planning.

Besides the assessment of the value of the estate property, assessment of the financial results of the operation and maintenance phase for a given estate property is the key information for potential buyers that need to estimate the profitability of the estate property. As a consequence, appropriate documents concerning financial aspects have to be prepared, such as annual audited and unaudited financial statements, budgets, financial forecasts, external and internal auditors’ reports, schedule of prepaid expenses, schedule of guarantees, last annual cash flow statement. Due diligence in a commercial property transaction often “include securing a title insurance policy regarding the ownership of the property and the encumbrances to which it is subject, and requiring the owner to secure an attornment from each tenant establishing agreement as to lease terms currently in force, and to research the zoning laws applicable to the property, building code compliance of the premises, the existence of any special assessments of property taxes applicable to the property, and the sales price history of the property” [67].

In the selling phase, the real-estate developer has to address a variety of aspects related with the estate property to be transferred. As a consequence, the real-estate developer has to collaborate with many individuals and organizations providing a wide spectrum of competences. Managing the documents generated during the due diligent process is a complex task, often supported by IT systems, such as virtual data rooms [36].

5.1.2 Heterogeneity of Real-Estate Developers

The construction investment market, in which real-estate developers play a central role, is highly heterogeneous. Its manifestation is the heterogeneity of real-estate developers themselves, both in terms of volume and use of IT systems to support the construction phase.

During the realization of the ITSOA project [25], the use of information systems supporting the realization of investment processes in the construction sector has been evaluated in a survey [32]. The evaluation focuses on real-estate development organizations operating in the Greater Poland (in Polish: “Wielkopolska”). The evaluation clearly confirms the heterogeneity of the construction investment market.

The survey was conducted electronically between May 1st and June 30th, 2011 via two communication channels: on appropriate professional Web sites and on the telephone. Among 37 filled survey forms, 9 survey forms (24 %) were filled online, and 28 by phone (76 %). Among 78 contacted organizations, 28 organizations (36 %) completed the survey.

The target audiences of the survey were subcontractors, builders, construction suppliers and other organizations related to building construction sector (renovation, contracting, construction, building, and home building industry). The survey had been prepared for managers working on all levels of organizational structure that had a direct or indirect impact on the shape of the investment process, e.g., scope of activities to be performed, set of subcontractors to be selected, supervision of the process execution.

Most of the polled persons are construction engineers, the remaining ones being estate agents, assistant managers, chairman of the board, project managers, main directors, secretaries, directors of sales, supervisors, financial analysts, accountants, work managers and specialists.

The number of employees in the polled organizations ranges from 3 to 280, so the survey was conducted mainly among small and medium real-estate development organizations.

In the years 2009–2011, the number of investment processes performed by the polled organizations ranged from 1 to 600 depending on the organization size. Most of the polled persons declares that the main type of investment processes concerns family houses and housing estates but do not exclude other types of investments.

The average number of subcontractors varies depending on the type of investment processes: from 1 (especially for single houses) to 50 (especially for whole housing estates). The number of permanent subcontractors is similar among polled organizations, usually up to 5.

The heterogeneity of the construction investment market concerns also the information systems used to support the construction phase of development processes. As a result of the evaluation, two groups of organizations are distinguished with regard to the information systems they use to support the construction phase of development processes:

  • a group consisting of 29 out of 37 (78 %) organizations that declare that they use only basic office software packages, e.g., Microsoft Excel, Word and Project;

  • a group consisting of 8 out of 37 (22 %) organizations that declare that they use information systems tailored to the management of investment processes.

The first group consists of small and medium size development organizations which mainly use Microsoft Excel, Word and Project for project schedule, verification and supervision of works, contracts and orders preparation. On a scale from 1 to 4, a rate of 4 meaning the higher level of suitability and usability, these tools have been rated 3 or 4.

The second group consists of rather medium development organizations (from 30 to 60 employees) which use various tailored IT solutions for the five operational areas taken into account in the survey: investment process planning, subcontractor selection, investment process execution management, communication with subcontractors, and contract management. The financial capacity, the number of realized investments (above 20), the size and complexity of faced situations of the organizations of the second group explain a wider adoption of IT tools by them. The list of information tools mentioned by the polled organizations is varied as follows:

  • Primavera: 1 of 37 (2 %) organizations, a Project Portfolio Management system (PPM) by Oracle,

  • Cobra: 1 of 37 (2 %) organizations, a program for scheduling by Deltek,

  • Korab: 1 of 37 (2 %) organizations, an in-house developed program to evaluate subcontractors,

  • Symfonia: 1 of 37 (2 %) organizations, a program for subcontractors maintenance, Customer Relationships Management systems (CRM): 2 of 37 (6%) organizations, a complex platform for all the partners of the investment process,

  • Autocad: 5 of 37 (14 %) organizations, Archicad: 1 of 37 (2 %) organizations, Comos: 1 of 37 (2%) organizations, Nemeczek: 1 of 37 (2%) organizations, Emerwin: 1 of 37 (2 %) organizations, CAD programs for project design and drafting,

  • Forte: 2 of 37 (6 %) organizations and Norma Pro : 3 of 37 (8 %) organizations, programs for costing, analyze and preparation of cost estimates,

  • CalcDesc: 1 of 37 (2 %) organizations, an in-house developed program for investment process management.

Both groups use the Internet to seek subcontractors. They communicate with subcontractors via email, telephones, Skype or face-to-face. Most of the subcontractors are selected on the basis of former collaboration or recommendations by partners of the real-estate developer.

5.2 Characteristics of Collaboration in the Construction Sector

Four characteristics of collaboration during the construction phase have to be taken into account to support agile construction for real-estate developers: long-term dynamic collaboration, continuous process instantiation, document-based process execution, and the important role of social aspects.

5.2.1 Long-Term Dynamic Processes

In the construction phase of development processes, collaboration processes last long time and are characterized by high dynamics. The construction phase of a development process usually lasts months, often years. During the construction phase, various collaboration processes among the real-estate developer and its subcontractors usually take place, often in parallel. A good example is the construction of a skyscraper. Subcontractors responsible for electrical systems are working on lower storeys of the skyscraper, while subcontractors responsible for roofing systems are working on the top of the skyscraper. Moreover, the duration of collaboration processes varies. The installation of electrical systems starts when the foundations are built, to settle the main cable infrastructure, and ends at the end of the construction process when the final customers provide information about the type of outlets they have chosen for their property. Collaboration processes are also highly dynamic: subcontractors often work simultaneously on various construction sites to increase their profitability. As a consequence, it is quite frequent that a subcontractor has to be replaced by another one because of scheduling incompatibility with the real-estate developer construction schedule. Moreover, exogenous factors, e.g., weather conditions or law modification, also increase the dynamics of collaboration by enforcing changes to tackle new situations. In the construction phase of development processes, adaptation is not an exceptional case but a normal procedure.

5.2.2 Continuous Process Instantiation

As a consequence of the long-term and dynamic character of collaboration during the construction phase of development processes, the selection of subcontractors is performed in a continuous manner during the whole construction phase. The selection of subcontractors concerns only activities to be performed on a short-term horizon, usually during the next three months. When adaptation is the normal case and interactions potentially last years, it is not appropriate to select all the subcontractors for all the activities at the beginning of the construction phase. The selection of subcontractors in a continuous manner permits to limit the risk of inadequacy of the selected subcontractors to new situations. Otherwise, a subcontractor selected at the beginning to the construction phase may be inadequate to execute its activities due to the difference between the planned situation and the current one.

5.2.3 Document-Based Process Execution

In the traditional approach to project management, the scheduling of projects is usually supported by Gantt or PERT charts. A Gantt chart captures the activities to be performed, their start and end dates, and their potential dependencies on other activities. A PERT chart captures as a labeled graph activities to be performed, the time required to perform each activity, and the dependencies between the activities. A classical use of PERT chart is the reduction of critical paths to shorten the total duration of the project.

In the construction phase of development projects, most real-estate developers do not use either Gantt or PERT charts. More generally, no formal model of the process is established. The main reason for the lack of formal process modeling is the shared ubiquity of implicit knowledge: real-estate developers and subcontractors know the activities to be performed to build a given edifice, from their experience, practice, and know-how.

Instead of Gantt and PERT charts, the activities to be performed by a subcontractor for a real-estate developer, as well of the terms of the collaboration are defined in contracts. Contracts may therefore be considered as a basic document modeling the execution of the construction phase of development processes. Contracts are potentially modified bilaterally by appendices that modify certain terms of the collaboration.

Finally, progress payment claims are a common means to check the correct partial execution of a given activity.

Therefore, the execution of the construct phase of development processes is mainly driven by three types of documents: contracts, appendices, and progress payment claims.

5.2.4 Importance of Social Aspects

The importance of social aspects is the fourth characteristic of interactions during the construction phase to be taken into account to support agile construction for real-estate developers. First, social aspects influence the choice of subcontractors for the execution of activities during the construction phase. As an example, a trusted or recommended subcontractor is usually preferred over another subcontractor that is less trusted or that has not been recommended.

Second, social aspects also affect the interactions among the real-estate developer and the subcontractors during the execution of the activities. As an example, a subcontractor that would be an authority on a particular construction technique would probably be more superficially inspected for the progress payment claims than a subcontractor that has already been in conflict with other subcontractors.

5.3 Administrative Procedures for the Construction Sector

Realization of vast majority of construction projects requires a number of administrative procedures to be carried out by public agencies. The main legal acts regulating the course of administrative procedures in the construction sector is Construction Law, Master Planning Law, and Administrative Law regulating the general course of all administrative procedures. The number, type and scope of these procedures depend on the nature and extent of investments to be erected. The most often conducted administrative procedures related to the construction sector are presented in this section.

The interaction between a real-estate developer and public administration takes place mainly in the preparation and construction phases, and relatively rarely in the operational and maintenance phases. In the preparation phase, the most important administrative procedure is the issuance of a decision on a building permit. Another procedures that occur frequently in this phase are for obtaining a planning decision and a decision on environmental conditions. The most important administrative procedure in the construction phase is aimed at issuing an occupancy certificate.

5.3.1 Building Permit

For the majority of construction projects, construction works can start only on the basis of a final decision on a building permit. The decision on the building permit is issued by a competent public authority at the request of the investor, and after carrying out the relevant administrative procedure. An investor who fulfills the conditions for obtaining a building permit, may request the issue of a separate decision on approval of the construction project, prior to obtaining of a building permit. The decision on the construction design approval is valid for a specified period of time but not longer than one year.

The decision on a building permit expires if the construction work does not commence within 3 years from the date when the decision became final, or if the construction work is interrupted for more than 3 years.

In the Construction Law, there are certain types of investments specified that can be realized without a building permit. Some of these investments require that competent public authorities have to be notified about the intention of their commencement. The construction work can be started if within 30 days after the notice, the authority does not raise any objections, and no later than 2 years after the date of the work commencement declared in the notice.

Before submitting an application for the issuance of a building permit, the investor is often required to obtain additional permits, opinions and arrangements required by specific regulations. Obtaining these documents may require carrying out administrative procedures by appropriate public authorities. As a result of execution of each of these procedures an appropriate administrative decision is issued which establishes the specific circumstances of these permits, opinions and arrangements.

If the area of an investment is contained in the local master plan then the building design must be in strict compliance with the terms and conditions specified in the plan and the building permit should be issued in accordance with the plan. A local master plan should describe the function of the land, requirements for general public areas and planning conditions including all restrictions imposed by law.

If no master plan is adopted for the area where the investment is planned, a planning decision must be obtained as a result of an administrative procedure performed by an appropriate public authority. In this case, a final building permit must be issued according to the planning decision. A planning decision specifies the investment type and detailed planning conditions.

5.3.2 Planning Decision

A planning decision for a given area may be issued only if all of the following requirements are fulfilled:

  • at least one neighboring plot which can be accessed from the same public road is developed in a way allowing to specify requirements for new buildings,

  • the area has access to a public road,

  • the existing or planned infrastructure is sufficient for the planned investment,

  • the area does not require consent to change of purpose of agricultural or forest lands to non-agricultural or non-forest,

  • the decision is compliant with other specific regulations, such as the Environmental Law, the Monument Protection Law.

A planning decision may concurrently be issued to several applicants. When one of the applicants obtains a building permit based on the planning decision, then the planning decisions issued to the remaining applicants become invalid. A planning decision may also become invalid when a new local master plan is adopted for the area covered in the decision and the plan imposes requirements different from those imposed by the decision.

An administrative procedure for issuing a planning decision may by suspended for no longer than 9 months from the date of submitting the application. The authority resumes the procedure and issues a planning decision when:

  • within 2 months from the date of the suspension, the municipal council does not adopt a resolution to proceed with the preparation of the local master plan, or

  • during the suspension of the procedure no local master plan is adopted.

However, if the application for a planning decision concerns an area for which there is a duty to adopt a local master plan, the administrative procedure is suspended until the adoption of the plan.

5.3.3 Occupancy Certificate

After the completion of the construction work for an investment for which a building permit is required a competent authority must be notified. The investment can be used if within 21 days after the notice, the authority does not raise any objections. In some circumstances specified in the Construction Law, before an investment can be occupied a final decision on a certificate of occupancy is required to be issued if: the investment required a building permit and it is categorized as an object that requires such certificate, or the use of a building is to take place before all construction work is finished. The competent authority shall issue a decision on the occupancy certificate after a mandatory inspection. The purpose of the inspection is validation of the construction in accordance with the provisions and conditions of the building permit. The validation includes:

  • compliance with the design of a building plot or land;

  • compliance with the design of a building;

  • construction products particularly important for structural and fire safety;

  • in the event of the imposition in the building permit of a requirement for demolition of existing buildings not intended for further use or temporary buildings, the fulfillment of this requirement, if the demolition deadline specified in the permit has already passed;

  • cleaning up the construction site.

An investment, for which an occupancy certificate is mandatory, may also require a notification of other public authorities, such as State Sanitary Inspectorate or State Fire Service. The lack of a position of the authorities within 14 days from the date of receipt of the notice is considered as they do not have any objections or comments.

5.3.4 Decision on Environmental Conditions

Before a planning decision or a building permit is applied to, it may be necessary to assess the environmental impact of an investment. The assessment is required for the investments which may have significant impact on the environment or a protected area of Natura 2000 [19]. The assessment of the environmental impact is performed through an administrative procedure for issuing a decision on environmental conditions. If a competent authority finds the need to conduct the environmental impact assessment, an investor is obliged to prepare a report on the planned investment’s impact on the environment. The decision also is issued if the authority does not find it necessary to assess the impact on the environment.

The environmental impact assessment for an investment can be carried out twice:

  • in the context of an administrative procedure for issuing a decision on environmental conditions, and

  • in the context of administrative procedures for a planning decision and a building permit; reassessment of the environmental impact is required in three cases:

    • if the requirement for the reassessment is specified in the decision on environmental conditions;

    • if the investor has applied for the reassessment if changes in conditions for the investment implementation are necessary;

    • if the authority carrying out the procedure has found that changes have occurred in the planned investment design relative to the findings of the decision on environmental conditions.

The environmental impact assessment is required for the investments which:

  • could always have a significant impact on the environment;

  • could potentially have a significant impact on the environment, but only if the obligation to assess the environmental impact has been determined by the authority competent for issuing decisions on environmental conditions.

The environmental impact assessment is also required for the investments that are not classified as having a significant impact on the environment, but may have a significant impact on a Natura 2000 site and are not directly related to the protection of the area and not the result of this protection.

5.3.5 Demolition Permit

If there is an existing building in the investment area the investor must obtain a permit for its demolition. If the building is entered in the register of historical monuments, a demolition permit may be issued after obtaining a decision of the Chief Conservator of Monuments, acting on behalf of the minister competent for culture and protection of national heritage. In relation to buildings not listed in the register of historical monuments, but included in the communal records of historical monuments, a demolition permit is issued by the competent authority in consultation with the regional conservator of monuments.

5.4 PEOPA Platform for Flexible Administrative Procedure Automation

In this section, the PEOPA platform is presented. The platform implements the CMEAP approach for flexible administrative procedure automation depicted in Sect. 4.1.

Fig. 2
figure 2

Architecture of the PEOPA platform

Full size image

The general architecture of the PEOPA platform is presented in Fig. 2. The PEOPA platform consists of the following main components:

  • Modeling environment;

  • Knowledge base of administrative legislation;

  • Administrative procedure execution server;

  • Administrative case portal.

5.4.1 PEOPA Modeling Environment

The PEOPA modeling environment is a graphical tool used by process analysts to model administrative procedures. The models are developed based on the legislation analysis and consultation with lawyers and employees of public offices. According to the assumptions of the CMEAP approach, the models are represented in the form of the following types of artifacts: elementary processes, decision rules, and ontology concepts (fact classes).

The modeling environment has been implemented as a set of plugins for the Eclipse platform [61]. The primary component of the modeling environment is the PEOPA perspective. The main window of the modeling environment is presented in Fig. 3.

Fig. 3
figure 3

The main window of the modeling environment

Full size image

Modeling artifacts are organized into projects. Creating a project is facilitated by a wizard presented in Fig. 4. The project contains source folders named Processes, Rules, and Ontology, one folder for each type of artifacts.

Fig. 4
figure 4

Example definition of a fact model

Full size image

Processes source folder is used to manage elementary processes. Elementary processes are modeled using the BPMN Modeler, which is a tool to graphically define models in BPMN 2.0 standard [42]. The modeler is presented in Fig. 5. The main part of the modeler window is filled with a canvas for creating models. On the right side of the editor there is a palette containing BPMN elements that can be dragged onto the canvas.

Fig. 5
figure 5

Elementary process modeler

Full size image
Fig. 6
figure 6

Definition of an example decision rule unit in the general Drools language (left part) and in a domain specific language (right part)

Full size image
Fig. 7
figure 7

Fact class wizard

Full size image

Rules source folder is used to manage units of decision rules. The decision rule unit consists of a set of decision rules associated with a particular legal issue; for example, individual’s legal capacity. The editor with sample definitions of decision logic for determining an individual’s legal capacity is presented in Fig. 6. The decision rule units are defined using a rule editor for the Drools rule engine [28]. The definitions of the rules may be specified in the general Drools language or in a language specific to a given domain.

Ontology source folder is used to manage ontology concepts, i.e., fact classes. The fact class is defined using a wizard. The wizard used for defining a fact class concerning legal capacity of an individual is presented in Fig. 7.

A fact class consists of attribute definitions. Each attribute definition specifies a name and a type of an attribute. An attribute can be of a simple type or a reference type that refers to another fact class. In the example, the fact class LegalCapacity is composed of three attributes:

  • individual: an attribute of a reference type that refers to Person fact class; denotes an individual which the legal capacity concerns,

  • type: an attribute of the String type; denotes the type of legal capacity; can be full, restricted, or null which means the entire lack of legal capacity,

  • incapacity: an attribute of a reference type related to Incapacity fact class; denotes an incapacitation status.

As a result of using the fact class wizard, the definition of a fact class in the form of a JavaBean component is automatically generated.

5.4.2 PEOPA Knowledge Base of Administrative Legislation

The PEOPA Knowledge base of administrative legislation is the implementation of the CMEAP approach Knowledge base.

The functions of the PEOPA Knowledge base are delivered to other components of the PEOPA platform through the service interface. The interface is implemented in Web services technology. Service interface allows remote access to the Knowledge base functions regardless of the IT infrastructure used to implement this access.

The service interface of the PEOPA Knowledge base consists of the following web services:

  • KnowledgeBaseService web service;

  • KnBaseAccountService web service;

  • KnBaseAddressService web service;

  • KnBaseAgencyService web service;

  • KnBaseDocumentService web service;

  • KnBaseEntityService web service;

  • KnBaseProcedureService web service.

The PEOPA Knowledge base has been implemented in Java 7 using the following frameworks:

  • Axis 2 framework for web service interface [60],

  • Hibernate 4.1.4 library for object-relational mapping [29],

  • SQL Server database for permanent data storage [37].

The KnowledgeBaseService web service delivers operations for managing decision rule units and definitions of elementary processes.

The KnBaseAccountService web service delivers operations for managing user accounts and privileges.

The KnBaseAddressService web service delivers operations for managing addresses and contact data.

The KnBaseAgencyService web service delivers operations for managing public administration agencies, clerks, and positions.

The KnBaseDocumentService web service delivers operations for managing administrative documents, digital images of administrative documents, and metadata describing administrative documents.

The KnBaseEntityService web service delivers operations for managing entities of administrative procedures.

The KnBaseProcedureService web service delivers operations for managing administrative procedure hierarchy and instances of administrative procedures.

5.4.3 PEOPA Administrative Procedure Execution Server

The PEOPA Administrative procedure execution server is the implementation of Composition and Process Servers of the CMEAP approach presented in Sect. 4.1.

As in the case of the PEOPA Knowledge base, functions of the PEOPA Execution server are delivered through the service interface implemented in Web service technology.

The service interface of the PEOPA Execution server consists of the following web services:

  • AuthorizationService web service;

  • CaseInfoService web service;

  • HumanTaskService web service;

  • ProcedureRuntimeService web service;

  • DocumentService web service;

  • CommentService web service.

The PEOPA Knowledge base has been implemented in Java 7 using the following frameworks and components:

  • Axis 2 framework for web service interface [60];

  • JBoss Drools decision rule engine [28];

  • Activiti process execution engine [2].

The AuthorizationService web service delivers operations for authorizing clerks within the system.

The CaseInfoService web service delivers operations for retrieving detailed information about cases, retrieving a list of cases on the basis of certain criteria, retrieving information about documents and comments attached to a case, retrieving information about tasks performed within a case.

The HumanTaskService web service delivers operations for managing tasks intended to be performed by a clerk.

The ProcedureRuntimeService web service delivers operations for managing applications for conducting administrative procedures and managing instances of administrative procedures.

The DocumentService web service delivers operations for creating, retrieving, updating and deleting administrative documents, their digital images, assigning documents to tasks and instances of administrative procedures.

The CommentService web service delivers operations for creating, retrieving, updating and deleting comments and assigning them to tasks and instances of administrative procedures.

In the course of administrative procedures, the PEOPA Execution server may need to interact with the local and national public registers. Such an interaction is conducted by means of enterprise service buses available on the intranet of public administration.

5.4.4 PEOPA Administrative Case Portal

The PEOPA Administrative case portal is a web tool intended for public clerks to manage execution of administrative procedures. The portal delivers functions for performing the following main activities:

  • registration of an application,

  • attribution of an application,

  • starting a new case by the launch of a new administrative procedure,

  • executing an administrative procedure in order to settle the case,

  • browsing completed administrative procedures.

Within execution of administrative procedures, the portal delivers the following operational functions:

  • claiming and carrying out human activities (tasks),

  • delegating activities to other employees,

  • reading notifications about the status of administrative procedures and results of executing non-human activities by the system,

  • displaying XML documents in a human-friendly manner,

  • editing XML documents in electronic forms,

  • entering and displaying comments for administrative procedures and individual activities,

  • creating documents and uploading their digital images.

All clerks using the portal must have their own password-protected accounts. Each account is linked to a set of privileges specifying which functions the account owner is granted to perform.

The following sections present details of portal functions.

Registration of an Application. Launching an administrative procedure begins with registration of an application submitted by an applicant—an individual or a representative of a company. Figure 8 presents a form for registering application (Rejestracja wniosku–Application Registration). Registration usually takes place in the Filling Office. Using the form, the office employee enters metadata describing the application being submitted and indicates the department the application will be forwarded to for further processing. The form includes a box for attaching a file containing the application and its attachments written in the XML format. This option is used when the application is submitted electronically through an e-government web portal and due to technical limitations there is no direct connection between the portal and the PEOPA platform.

Fig. 8
figure 8

The form for registering an application

Full size image

Once completed and approved, the data entered in the form are stored in the system.

Attribution of an Application. Once registered, the application is forwarded to the department indicated during the registration. It appears on the list of applications for attributing. This list is visible for an employee of the department who is granted the privilege for attribution. Such an employee is usually a person occupying the position of a department manager. The form for application attribution is presented in Fig. 9 (Dekretuj wniosek–Attribute Application).

Fig. 9
figure 9

The form for application attribution

Full size image
Fig. 10
figure 10

The main screen of the portal displaying for a clerk with executing administrative procedure privilege

Full size image

There are two types of attribution: to a department and to selected employees. The choice depends on the method used to organize work in a department. Attribution to a department means that all employees receive the possibility to pick up the attributed application. Attribution to selected employees means the arbitrary limitation of the number of employees who receive such a possibility. A special case of the latter attribution type is selecting one employee only. In this case, the manager deprives the employees of self-management capabilities and arbitrarily takes decisions on workloads.

Starting a New Case. After being attributed, an application is removed from the list of pending for attribution and appears on the list of pending to initiate a case. The case can be initiated by a clerk with appropriate privilege only. Figure 10 presents the main screen of such a clerk (Podjęcie nowej sprawy–Starting a new case; Sprawy w toku–Ongoing cases; Zadania do wykonania–Tasks to be performed; Sprawy zakończone–Complete cases). In addition to starting a new case, the clerk may also perform other tasks, such as displaying a list of ongoing cases, displaying a list of tasks to be performed, and displaying a list of completed cases.

After selecting Podjęcie nowej sprawy (Start a new case), a list of applications attributed to a clerk is displayed. The list includes information about the application title, the date of submission, and the type of attribution. The icon in the right-most column informs a clerk if the application has been attributed to a department, or to several employees, or to the current one only. Figure 11 presents a list of applications ready to be picked up to start a new case, including one application attributed to several clerks (Pozwolenie na budowę na os. St. Batorego 29 w Poznaniu–Building permit for 29 St. Batorego Street in Poznan City).

Fig. 11
figure 11

A list of applications waiting to be picked up by a clerk to start a new case

Full size image

After picking up an application from the list, detailed information is displayed as well as a button to start the case (Fig. 12, Podejmij sprawę–Start the case).

Fig. 12
figure 12

The details of an attributed application

Full size image

Pressing the Podejmij sprawę (Start the case) button gets displayed a form to enter data for creating a new administrative procedure for the case. Such a form is presented in Fig. 13 (Dane sprawy–Case description).

Fig. 13
figure 13

The form to enter data for creating a new administrative procedure

Full size image

After creating a new administrative procedure, a screen with four tabs gets displayed. The Szczegóły sprawy (Case description) tab contains description of the case the administrative procedure is executed for; the Przebieg (Course) tab—a list of tasks to be performed by a clerk within the procedure; the Teczka (Case folder) tab—folder for documents attached to the case; the Komentarze (Comments) tab—comments submitted by clerks on the case. The screen is presented in Fig. 14.

Fig. 14
figure 14

The screen for managing an administrative procedure

Full size image

Executing an Administrative Procedure. The execution of an administrative procedure is performed using the Przebieg (Course) tab presented in Fig. 16. The tab contains a list of tasks. There are two types of tasks: human tasks assigned by the PEOPA platform to be performed by a clerk in the specific moment of procedure execution and notifications of actions taken by the system, in particular the automatic execution of activities.

Figure 15 presents a task Wyświetlenie formularza z wnioskiem o wydanie pozwolenia na budowę i zatwierdzenie projektu budowlanego (Display a form for an application for a building permit and approval of a construction project). For this task, there are three tabs: Szczegóły zadania (Task details), Załączniki (Attachments), and Komentarze (Comments). In the Szczegóły zadania (Task details) tab the content of the task is presented. The Załączniki (Attachments) tab includes a list of documents and their digital images attached to the task, and the Komentarze (Comment) tab includes a list of comments on the task. In the task discussed here, in the Szczegóły zadania (Task details) tab there is a form displaying the submitted application. The form could be unfilled; thus a clerk’s task would be to fill it with data from a paper application. In the discussed task, the form is completed with data retrieved from the XML document included while registering the application.

Fig. 15
figure 15

The task “Display a form for an application for a building permit and approval of a construction project”

Full size image

After completing the task Wyświetlenie formularza z wnioskiem...(Display a form for an application...), the system updates the task list. The updated list is presented in Fig. 16.

Fig. 16
figure 16

The list of tasks to be performed by a clerk

Full size image

After selecting the first item from the list presented in Fig. 16, a notification of the automatic execution of tasks by the system is displayed. This notification is shown in Fig. 17.

Fig. 17
figure 17

Notification of the automatic execution of the task

Full size image

After selecting the second item from the list presented in Fig. 16, a task Sprawdzenie poprawności merytorycznej wniosku z terminologią ustawy Prawo budowlane, a także czy wniosek dotyczy inwestycji liniowej (Verify if the application is aligned with the terminology of the Building Code and if it refers to the line investment) is displayed. The task is presented in Fig. 18.

Fig. 18
figure 18

The task “Verify if the application is aligned with the terminology of the Building Code and if it refers to the line investment”

Full size image

Depending on the answers provided by the clerk within the task Sprawdzenie poprawności merytorycznej wniosku ...(Verify if the application is correct), the system determines the further course of the procedure until submitting the final decision which indicates the end of the procedure.

5.4.5 Summary

The PEOPA platform, presented in this section, uses the CMEAP approach to compose an administrative procedure model in a flexible manner. The resulting model is closely tailored to the legal circumstances of the case the procedure is conducted for and provides a detailed map of all administrative tasks that need to be performed within this procedure. This makes it possible to automate the procedure in two dimensions: selection of activities and execution of activities. Automation of selection means that the PEOPA platform using terminological knowledge stored in the Knowledge base replaces a clerk in interpreting the law and making decisions on activities to perform on a given stage of the procedure. Automation of execution means that the PEOPA platform replaces a clerk in the operational execution of activities. Automation of selection is an inherent feature of the CMEAP approach and thus the PEOPA platform, automation of execution is largely derived from the technical and legal circumstances: the access to public registers in online manner, ability and willingness to use the electronic documents, etc.

The use of the PEOPA platform also significantly reduces the complexity of the administrative procedure models compared to the traditional monolithic approach. Thus, the process of updating models in order to reflect the changes in legislation is much easier; i.e., in the case of a change in a legal act, instead of modifying a number of administrative procedure models, merely a single or few elementary processes have to be altered. In this way, the updating process becomes less time consuming, less expensive, and less prone to errors. Furthermore, the replacement of the monolithic models of administrative procedures with the elementary process models corresponding to specific legal aspects contributes to elimination of inconsistencies in representations of the same aspects in various monolithic procedure models.

5.5 The ErGo System for Support of Collaborative Processes

In this section, the ErGo prototype which implements service protocols and adaptation tools for real-estate developers is presented.

5.5.1 Overview of the ErGo System

The ErGo system (http://ergo.kti.ue.poznan.pl/) [32] is an implementation of technical infrastructure supporting operation of SOVOBE and a proof of feasibility of the implementation of IT systems supporting the execution of collaborative processes in an adaptive way. The ErGo system—from the Greek word (“ergo”), meaning “task”, “work”—aims at supporting the collaboration between a real-estate developer and its subcontractors during the construction phase of a development process.

The ErGo system takes into account the characteristics of the interactions between a real-estate developer and its subcontractors during the construction phase. Interactions are modeled as service protocols.

In the ErGo system, processes are modeled as a set of contracts between the real-estate developer and subcontractors. The execution of the contracts is further monitored with KPIs. If the realization of a development process meets an obstacle, the real-estate developer or a subcontractor may start adaptation, i.e., may initiate a discussion concerning the modification to be applied to the set of subcontractors and/or the contracts related with the investment.

5.5.2 ErGo Applications

The ErGo system consists of six applications tackling various complementary aspects of the construction phase of development processes. The first application—ErGo Organizations—is responsible for the management of the description of organizations and their competences. The second application—ErGo Services—is responsible for the management of the description of business services provided by organizations. A real-estate developer manages all the contracts with subcontractors with the third application—ErGo Investments. The subcontractor contracting process is supported by the fourth application—ErGo MatchMaker. Templates for various types of development processes are defined in the fifth application—ErGo Investment Types. Finally, the sixth application is m-ErGo, a mobile application tailored to the need of construction managers working on the construction site.

ErGo Organizations. The ErGo Organizations application allows users to manage the description of organizations, especially their competences. Choosing the right organization to perform a given activity is not an easy undertaking. All the competence requirements have to be satisfied by the chosen subcontractor to avoid cost increases, missing deadlines or even breach of contract. A precise description of competences of organizations is an important element for the management of development processes.

The functionality of the ErGo Organizations application is organized as follows: first, a group of functions provides users with means for registering new organizations and updating the data concerning already registered organizations. Second, another group of functions allows users to manage the competences of organizations, based on the competence model proposed in [48]. Third, another group of functions gives users means for retrieving organizations satisfying a set of requirements concerning either their profile or their competences. Finally, the ErGo Organizations application provides functions for searching and filtering registered organizations.

A screen capture of the ErGo Organizations application is presented in Fig. 19. Users select an organization from the list of organizations on the left side. Detailed information about the selected organization is then displayed in the central panel. Competences of the organization are available on the associated tabbed panel. Organizations can be filtered out with the Search field on the top.

Fig. 19
figure 19

Main panel of the ErGo Organizations application

Full size image

ErGo Services. The ErGo Services application allows users to manage the description of the services provided by organizations. The list of services that organizations provide is an important element of the description of organizations. The choice of an organization as a subcontractor depends on the services the organization provides. The goal of the ErGo Services application is to support the management and search of services provided by organizations.

The functionality of the ErGo Services application is organized as follows: first, a group of functions provides users with means for registering new types of business services and updating the already registered ones. Second, another group of functions provides users with means for managing the business services provided by organizations registered in the ErGo Organizations application. Third, another group of functions allows users to retrieve organizations satisfying a set of requirements concerning the business service they provide. Finally, functions for searching and filtering business services registered in the ErGo system are provided by the ErGo Services application.

A screen capture of the ErGo Services application is presented in Fig. 20. The graphical user interface of the ErGo Services application is part of the ErGo Organizations application. For a given organization, details concerning the business services provided by the organization are available on the “Services” tabbed panel. Services can be filtered out by name and/or description.

Fig. 20
figure 20

Main panel of the ErGo Services application

Full size image

ErGo Investments. The ErGo Investments application allows users to manage contracts for the construction phase of development processes. In the context of service protocols, the ErGo Investments application is based on an implementation of prototype service protocols and instances of service protocols modeling development processes in their construction phase. During the construction phase of a development process, the sequence of activities to be performed is usually not explicitly specified in advance. Moreover, a development process is usually not entirely determined when its construction phase starts. Activities to be performed during the construction phase of a development process are usually not planned ahead for more than three months.

The ErGo Investments application allows users to control the realization of the construction phase of a development process in a seamless manner, by providing means for continuous preparation of contracts, appendices and progress payment claims.

The ErGo Investments application enables the adaptation of development processes. In the ErGo system, and in the ErGo Investments application in particular, adaptation is a collaborative task: potential modifications of the execution of the development process are discussed by stakeholders of the development process. The discussion consists of an exchange of adapting statements among stakeholders. An adapting statement is related to a contract, a progress payment claim, an appendix, a group of contracts, and an investment.

Fig. 21
figure 21

Main panel of the ErGo Investments application

Full size image

Adapting collaborators express various types of positions in their adapting statements: a change proposition is rated, commented or extended. Rating and commenting positions are useful to ease the final decision about the execution of a change proposition: a high rating of a given change proposition may influence the decision maker responsible for the execution of change propositions.

The functionality of the ErGo Investments application is organized as follows: first, a group of functions provide users with means for registering new contracts, appendices, and progress payment claims, and updating the already registered ones. Second, another group of functions provides users with means for managing KPIs. Third, another group of functions provides users with means for adaptation. Finally, the ErGo Investments application provides functions for searching and filtering contracts, appendices, and progress payment claims registered in it. A screen capture of the main panel of the ErGo Investments application is presented in Fig. 21. In the middle of the panel, a table presents the data concerning development processes (e.g., “Budynek mieszkalny–Głogowska 199”, ang. “Residential building–Głogowska 199”), groups of contracts (e.g., “Dach–pokrycie, obróbki, detale”, ang. “Roof–covering, treatment, details”), contracts (e.g., “Umowa UM/88”, ang. “Contract UM/88”), appendices (e.g., “Aneks AN/44”, ang. “Appendix AN/44”), and progress payment claims (e.g., “Protokół PR/43”, ang. “Progress Payment Claim PR/43”). On the right side of the table, information, including financial information, concerning the progress of the associated elements is displayed. At the top, a list of buttons allows a user to access the details of a selected element in the table, to add new development processes, new contracts, new appendices, and new progress payment claims, depending on the user’s rights.

Fig. 22
figure 22

Discussion about a contract in the ErGo Investments application

Full size image

A screen capture of the discussion panel of the ErGo Investments application is presented in Fig. 22. The presented discussion concerns the contract labeled “Contract 1/DW/2010” of the development process “Żurawieniec 4”. The adapting statements of the adapting collaborators are referred to as “Offers” in the ErGo Investments application. The first adapting statement has been submitted by Jan Kowalski. The change proposition consists in modifying the start date of the contract to “2010-09-30”. The change proposition was positively rated by 9 collaborators who had clicked on the “Approved” icon 

figure a

. The change proposition was negatively by eight collaborators who had clicked on the “Disapproved” icon 

figure b

. A user with appropriate rights accepts the change proposition by clicking on the “Accept” icon 

figure c

, or rejects it by clicking on the “Reject” icon 

figure d

.

ErGo MatchMaker. The ErGo MatchMaker application allows users to select subcontractors during the construction phase of development processes. In the context of service protocols, the ErGo MatchMaker application provides means to select appropriate actors to instantiate service protocols modeling development processes in their construction phase.

The ErGo MatchMaker application supports continuous selection of subcontractors, where the selection is performed in a collaborative way by persons directly responsible for the realization of the investment process. A user selects organizations that can perform required activities, then aggregates the chosen organizations. Both single organizations and groups of organizations are potentially discussed with other collaborators. The discussion concerning the chosen organizations and groups of organizations is structured in an identical manner to the ErGo Investments application.

Internal discussions concern the potential subcontractors and the terms of the contracts to be negotiated with the chosen organizations. Internal discussions are followed by external discussions in which the representatives of chosen organizations are involved. The goal of the external discussion is the negotiation of the final terms of the contract. When the external discussion ends with a satisfying compromise, the contract is signed and its representation is added to the ErGo Investments application.

In the ErGo MatchMaker application, the selection process of subcontractors is based on a set of requirements concerning a group of organizations to be contracted. The requirements are defined in templates of development processes, referred to as “investment types”. An investment type is an abstract service protocol. Requirements used by the ErGo MatchMaker application are based on the service-oriented summary, the service network schema, and the mapping functions of the abstract service protocol. As an example, an investment type for the construction of residential buildings defines requirements concerning the architect and electricians, and their relations. These requirements are captured in the service network schema. A screen capture of the ErGo MatchMaker application is presented in Fig. 23. The presented panel allows users to discuss a group of potential subcontractors. On the top of the panel, a description of the group of activities to be contracted and the associated development process is presented. In the middle of the panel, a table presents the activities to be contracted and the organizations that have been proposed as potential subcontractors. In Fig. 23, only one organization, i.e., “Dekoratornia”, has been proposed as a potential subcontractor for the building of a reinforced concrete slab. Negotiations are ongoing with the chosen organizations. At the bottom of the panel, another proposition has been submitted by Jakub Flotyński.

Fig. 23
figure 23

Partner selection in the ErGo MatchMaker application

Full size image

ErGo Investment Types. The ErGo Investment Types application allows users to manage investment types. In the context of service protocols, the ErGo Investment Types application is based on an implementation of abstract service protocols modeling development processes in their construction phase. An investment type is an abstract service protocol. The service-oriented summary, the service network schema and the mapping functions of an abstract service protocol are further used by the ErGo MatchMaker application as a set of requirements for the selection of subcontractors.

An investment type contains also groups of contracts, referred to as “category groups” in the ErGo system. Groups of contracts usually cover a set of activities to be performed at the same stage of the construction phase, e.g., roofing related contracts. The subcontractor selection process supported by the ErGo MatchMaker application usually concerns a group of activities to be contracted within a given group of contracts.

The functionality of the ErGo Investment Types application is organized as follows: first, a group of functions provides users with means for registering new investment types and managing already registered ones, including managing groups of contracts, requirements, and contract templates. Second, another group of functions provides other ErGo modules and applications, e.g., ErGo MatchMaker and ErGo Investments, with access to investment types.

A screen capture of the ErGo Investment Types application is presented in Fig. 24. In the presented panel, an investment type concerning the construction of a residential building is presented. The investment type for residential building contains five groups of contracts (e.g., “Fundamenty”, ang. “Foundations”), three requirements (e.g., the first requirement concerns the architects), and three contract templates that can be used to contract activities from subcontractors.

Fig. 24
figure 24

Edition panel of the ErGo Investment Types application

Full size image

m- ErGo. The m-ErGo application is devoted to mobile devices and is tailored to the need of construction managers working on the construction site.

Most activities associated with the construction phase of a development process are performed at the construction site. The m-ErGo application provides access to a wide range of functions of the ErGo system that are useful on the construction site, from accessing information about a particular contract, to signing a progress payment claim issued by a subcontractor.

After successful login, user accesses information concerning development processes, e.g., the start and end dates of a given contract, the list of progress payment claims. Users granted more rights, such as construction managers, may flag a progress payment claim as acceptable after an on-site inspection.

Besides accessing information concerning development processes, a user may also assess the work of an organization described in the ErGo Organizations application. After an on-site inspection, a user ranks an organization and justifies his/her ranking with an appropriate justification. Ranking information is useful for future selection processes of subcontractors.

Finally, a user of the m-ErGo application can monitor the execution of the construction phase of development processes with KPIs. The m-ErGo application provides a user with access to the values of his/her KPIs and notifies the user if KPIs have reached values beyond their acceptable thresholds. A screen capture of the main panel of the m-ErGo application is presented in Fig. 25.

In the main panel, the four areas covered by the m-ErGo application are presented: information concerning development processes is accessible via the first menu position, i.e., “Twoje inwestycje” (ang. “Your investments”). The second menu position, i.e., “Protokoły do podpisu” (ang. “Progress payment claims to be signed”) leads to the list of pending progress payment claims. The third menu position, i.e., “Ocena organizacji” (ang. “Organization assessment”), leads to a panel allowing a user to assess an organization. The fourth menu position, i.e., “Wskaźniki efektywności KPI” (ang. “Key Performance Indicators”) leads to a list of available KPIs and their values.

Fig. 25
figure 25

Main panel of the m-ErGo application

Full size image

A screen capture of the panel allowing a user to flag a progress payment claim as acceptable is presented in Fig. 26. In the presented example, the progress payment claim “PR/37” is flagged as acceptable (by clicking on the “Accept” button 

figure e

) or flagged as non-acceptable (by clicking on the “Reject” button

figure f

).

5.5.3 Summary

The ErGo system, presented in this section, enables agile construction support for real-estate developers. Supporting the construction phase of development processes requires a different approach to project management than the one implemented in most project management information systems based on Gantt or PERT charts. Gantt and PERT charts are unnecessary with regard to the ubiquity of shared tacit knowledge concerning the sequence of constructing activities to be performed to build a property. In the ErGo system, contracts, progress payment claims, and appendices are at the core of the modeling of interactions between a real-estate developer and its subcontractors. Such an approach is fully aligned with the culture and the customs of the construction sector. As a consequence, the ErGo system is more comprehensible to real-estate developers and subcontractors than traditional project management information systems.

Fig. 26
figure 26

Signing a progress payment claim with the m-ErGo application

Full size image

The application of service protocols to the construction phase of development processes allows real-estate developer to orchestrate larger development processes. Without an appropriate support for the interactions among the real-estate developer and its subcontractors, the real-estate developer, especially small and medium size one, cannot efficiently orchestrate large development processes which requires the management of too many contracts. In the ErGo system, abstract service protocols and modeling investment types define and group contracts to be negotiated, signed, and executed. Appropriate KPIs support the management of a large number of contracts by monitoring the state of all the contracts of a given development process.

Adaptation of service protocols addresses directly the needs for agile interactions between the real-estate developer and its subcontractors. In the construction sector, changes of the interactions between the real-estate developer and its subcontractors are frequent and usual. Adaptation of service protocols enables the real-estate developer to rapidly react to new situations, e.g., bad weather conditions, an excavator breakdown, and an unavailable partner. As a consequence, adaptation of service protocols supports the construction phase as a means leading to a better respect of deadlines and budget concerning construction activities.

6 Case Study for in the Construction Sector

6.1 Administrative Procedure for Issuing Building Permit

In this section, the CMEAP approach is applied to develop a detailed model of the administrative procedure for issuing a building permit. This procedure is a universally understandable example for readers from different countries, because it is one of the most widely spread administrative procedures for citizens and businesses. The model of this procedure was created under the Polish legislation, but most of the laws governing the course of this procedure are similar to the laws in other countries [26]. The CMEAP approach is general and, therefore, can be applied to any administrative procedures governed by the laws of any country.

6.1.1 Procedure Specification

The building permit should cover an entire construction project. In the case of construction project involving more than one object, the building permit may, at the request of the investor, apply to a selected object or a group of objects. In this case, the investor is obliged to submit the plot or land development plans for the entire construction project.

An application for a building permit should be submitted along with the following attachments:

  • four copies of the building design, including the opinions, approvals, permits and other documents required by specific regulations;

  • the statement confirming the investor’s right to dispose of the real estate for building purposes;

  • the planning decision, if required under the provisions on planning and spatial development.

The building design should meet the requirements specified in the planning decision, if such a decision is required. The scope and content of a building design should be tailored to the specifics and nature of the project and the complexity of the construction work. The building design should contain the following documents:

  • the plot or land development design, drawn on an up-to-date map, including: specification of the boundaries of the plot or land, location, contours and layout of existing and planned building objects, technical infrastructure network, sewage disposal or treatment, communication system, and arrangement of green areas, and indicating the characteristic elements, dimensions, ordinates and distances between the building objects, in relation to the existing and planned buildings in the surrounding areas;

  • the architectural and construction design, specifying the function, form and structure of a building object, the energy and environmental characteristics and proposed the required technical and material solutions for demonstrating the principle of adopting the building object in relation to existing buildings;

  • if necessary, statements of appropriate organizational units on the supply of energy, water, heat, gas, sewage collection and the conditions for connecting the object to the water, sewage, heat, gas, electricity, telecommunications, and road networks,

  • the statement of a competent road management unit on connection capabilities of the plot with a public road in accordance with the regulations on public roads;

  • if necessary, the results of geological engineering surveys and geotechnical conditions for the foundation of building objects.

Prior to issuing a decision on a building permit or a separate decision on approval of the building design, the competent authority should verify:

  • compliance of the building design with the provisions of a local master plan or a planning decision, if there is no local master plan, and with the requirements for environmental protection, in particular those specified in the environmental decision;

  • compliance of the plot or land development design with regulations, including the technical and building provisions;

  • completeness of the building design and the required opinions, approvals, permits and checks, and the information on safety and health protection, as well as other documents submitted along with the application;

  • preparation of the building design by a qualified person.

If any infringement in the documents attached to the application is found, the competent authority imposes an obligation to remove the indicated deficiencies, with a deadline for their removal. After its expiry, the authority issues a decision to refuse approval of the building design and issuing a building permit.

The competent authority issues a decision declining a building permit and approval of the building design if at the plot or land designated for the development, there is a building object under a demolition order.

If the application and all attached documents are complete, correct and complying with the provisions, the competent authority is obliged to issue a decision on a building permit and approval of the building design.

A detailed model of the administrative procedure for issuing a building permit is composed of 60 elementary process models, 30 decision rule units, and 50 fact classes. To illustrate the CMEAP approach, selected parts of the administrative procedure model focused on specific legal aspects are presented in the remainder of this section.

6.1.2 Case Study

In this case study, an investor submits an application for a building permit and approval of the building design of a residential building to a competent authority. The investment is characterized by the following circumstances:

  • The area of investment is not included in a local master plan.

  • The investment area covers an area entered in the communal records of historical monuments and is not included in the register of historical monuments.

  • The investment is located in the vicinity of a Natura 2000 site.

  • There are exemptions from technical and building regulations in the building design.

In the presented case, the competent authority in the course of an administrative procedure has to cooperate with other authorities of the public administration, as shown in Fig. 27.

Fig. 27
figure 27

Collaboration of public authorities within an administrative procedure for issuing a building permit

Full size image

Lack of Local Master Plan. If the investment is located in an area not covered by a local master plan, a planning decision has to be obtained by an investor and attached to the application for a building permit. In this case, a final building permit must be issued in strict compliance with the terms and conditions specified in the planning decision. Therefore, before making a decision on a building permit the competent authority has to verify compliance of the building design with the requirements specified in the planning decision.

The elementary processes related to the lack of a master plan are the following:

  • Checking if the investment area is covered by a local master plan and verifying if a planning decision is attached, if required.

  • Verifying the compliance of the building design with the provisions of a planning decision.

Investment Area in Communal Records of Historical Monuments. Carrying out construction works related to a building object or an area entered in the register of historical monuments requires obtaining a permit to carry out these works, issued by the competent regional conservator of monuments. The conservator’s permit has to be obtained by an investor and attached to the application for a building permit.

In relation to the building objects not listed in the register of historical monuments, but included in the communal records of historical monuments, a building permit or the permit to demolish a building object should be issued by the competent authority in consultation with the regional conservator of monuments. The conservator of monuments is obliged to issue the opinion regarding the application for a permit to build or demolish a building object within 30 days from the day when it was received. Failure to express an opinion within the time limit is considered as lack of objections to the design solutions presented in the application.

The elementary processes related to the fact that the investment area covers an area entered in the communal records of historical monuments and is not included in the register of historical monuments are the following:

  • Checking if a building object or area is included in the communal records of historical monuments.

  • Applying to a competent regional conservator of monuments for approval of the building design.

Impact on a Natura 2000 Site. If the authority competent to issue a building permit finds that the investment could potentially have a significant impact on a Natura 2000 site, the investor is obliged to submit the application for issuing a building permit along with the documents required for the impact assessment to the regional director of environmental protection for agreement.

The regional director of environmental protection, after receiving the documents examine whether the investment project may have significant impact on the Natura 2000 site. If the regional director of environmental protection recognizes that the investment will not have significant impact on the Natura 2000 site, it waives the need of the assessment. However, if the director recognizes that the investment may have significant impact on the Natura 2000 site, it issues a decision on the obligation to conduct the impact assessment. In this decision, the regional director of environmental protection obligates the investor to prepare and submit a report on the impact of the investment on the Natura 2000 site and defines the scope of the report.

Next, the regional director of environmental protection makes a request to the authority competent to issue a building permit for ensuring an opportunity for public participation in the impact assessment. The authority carries out public consultation to collect comments and requests on the impact of the planned investment on the Natura 2000 site. The regional director of environmental protection analyzes the collected material and issues a decision on the agreed conditions for the investment or refuses to agree the conditions if the investment can have significantly negative impact on the Natura 2000 site. The authority examines the decision and based on the analysis of the collected evidence issues a decision on a building permit.

The elementary processes related to the fact that the investment is located in the vicinity of a Natura 2000 site are the following:

  • Checking if an investment area is located in the vicinity of a Natura 2000 site and application to a competent regional director of environmental protection to examine whether the investment may have significant impact on the site.

  • Carrying out public consultation to collect comments and requests from on the public on the impact of the planned investment on the Natura 2000 site.

  • Verifying the compliance of the building design with the decision of the regional director of environmental protection on the investment’s impact on the Natura 2000 site.

Exemptions from Technical and Building Regulations. In particularly justified cases, an investor can realize an investment according to a building design with exemptions from technical and building regulations. The specific needs of the investor, unusual shape of the plot, or other circumstances may make it impossible to realize an investment, for example, with maintaining appropriate distances from neighboring plots. To solve such problems the investor may obtain approval for the requested exemptions from regulations from the authority competent to issue a building permit.

To obtain the approval the investor has to justify the need for the exemptions and provide the proposals of substitutive solutions. The approval of the exemptions requires receiving an authorization from the minister, who set forth the technical and building regulations. The application for an authorization is submitted to the minister by the authority responsible for issuing a building permit, and the minister’s authorization is addressed to this authority. If the exemptions apply to regulations set forth by various ministers, an authorization must be obtained from each of them. The minister may grant an authorization upon the fulfillment of additional requirements.

After receiving an authorization from the minister, the competent authority shall either refuse or grant the approval for the exemptions from the regulations. The authority is not bound by the authorization granted by the minister, because the authority is obliged to investigate and comprehensively consider each particular case.

The elementary processes related to the fact that the building design contains exemptions from technical and building regulations:

  • Checking if there are any exemptions from technical and building regulations in the building design.

  • Applying to the competent minister for authorization to accept the exemptions in making a decision refusing or granting the approval for the exemptions in the building design.

6.1.3 Ontology

Based on analysis of the legal acts related to the selected aspects, the ontology of concepts has been designed, as presented in Fig. 28.

Fig. 28
figure 28

Ontology of concepts related to the selected legal aspects of the administrative procedure for issuing a building permit

Full size image

In the course of the administrative procedure for issuing a building permit the instances of the ontology concepts (facts) are created. The facts represent legal circumstances occurring during execution of that procedure for a specific case. The selection of elementary processes to be executed is carried out by the decision rules that are activated based on the analysis of the facts.

6.2 Construction Process for Residential Building

6.2.1 Case Study 1: Clearance of a Construction Site

Assume that a real-estate developer company, named DevHouse, is planning its next investment. DevHouse currently owns a plot of land with an old abandoned oil refinery in ruins. DevHouse intends to build a residential building in this plot of land.

First, DevHouse should obtain a loan from a bank to finance the investment. To ease the whole procedure, DevHouse wants to focus on banks with which it has already collaborated. Therefore, DevHouse plans to negotiate a loan with banks at which it currently has an account, and from which it has got former loans. However, DevHouse would like to avoid a next loan from a bank from which it already has a current loan. Also, banks proposing interest rates higher than 5.5 % for a 3-year loan should be rejected.

Second, DevHouse needs an architect to develop the construction plans. The major requirement concerns past and current collaboration. As the residential building is a strategically important investment for DevHouse, the architect had to develop at least five projects for DevHouse in the past, but is currently developing no more than two projects.

Third, DevHouse needs the plot of land to be cleared. The developer does not want to be in charge of the clearance process. The architect should be responsible for identifying a site preparation company, which will supervise the preparation activities, i.e., demolition and rubble removal. The two companies that will perform the preparation activities, i.e., a demolition company and a debris hauling company, should be known and trusted by the architect. Moreover, they should be able to collaborate efficiently. The remaining activities required to build a residential building, e.g., foundation construction, masonry, carpentry, are not taken into account in this example.

The ErGo system supports DevHouse in definition of tasks to be performed within the construction process and specification of the described requirements. DevHouse uses ErGo Investments application to define a set of predicted activities to be performed. Using ErGo Investment Types functionality DevHouse can also assign particular requirements that a particular organization, i.e., a bank, must satisfy. Requirements defined with the use of ErGo Investment Types concern also services of organizations. In this case requirements concerning interest rate can be included. Finally, social requirements can be defined among classes of actors, i.e., acquaintance among architect and demolition company. Information concerning the number of actors envisioned for a particular activity is also captured in investment type, i.e., two companies performing the preparation activities. In this way abstract service protocol is developed. Then DevHouse creates new construction process in ErGo Investments application. Among information provided as a description of investment, DevHouse must indicate previously developed investment type as a basis for the construction process. Activities that do not have any requirements assigned may be defined both in ErGo Investment Types or ErGo Investments application. The advanced functions supporting partner selection available in the ErGo MatchMaker application are available only for activities with defined requirements concerning actors.

Although a classical case in the construction sector is described in the this case study, a set of issues related to this case are still to be addressed.

Multiple Service Consumers. In Case Study 1, a process consists of not only various service providers but also various service consumers. In Case Study 1, the first service consumer is DevHouse that is seeking for financing from banks. The second service consumer is the architect who needs a site preparation company to supervise the cleaning of the plot of land. Finally, the site preparation company itself is a service consumer when it consumes the demolition and rubble removal services provided by a demolition company and a debris hauling company.

The ErGo system allows various organizations to be assigned as service customers. The assignment is performed manually, i.e., organizations are selected from ErGo Organizations application database by users or are indicated by system on a basis of requirements defined in investment type. Analysis of organizations in terms of requirements satisfaction is implemented in the ErGo MatchMaker application. Information concerning service consumer and service provider assigned to the activity is stored in ErGo Investments application in a form of contract regulating conditions of service provision and signed by both actors.

Constraints on Actors. In Case Study 1, a process model may define that each individual playing the Real-estate Developer role may perform the “negotiate a loan” activity. A real estate developer may negotiate a loan if financing is needed. However, if the investment may be fully financed by the real-estate developer from its own resources, then a loan (and the associated negotiations to obtain it) may be avoided.

In Case Study 1, a constraint on an actor being a real-estate developer may state that its number of investments has to be greater than ten. Any real-estate developer with a lesser number of investments should not be allowed to participate in the formerly presented process. Similarly, banks proposing interest rates higher than 5.5 % for a 3-year loan should be rejected.

In the ErGo system, the definition of a constraint concerning actors and their associations with activities is captured in ErGo Investment Types application.

Relational Constraints. In Case Study 1, the choice of an architect is limited by relational constraints: the architect should have at least five former projects performed for DevHouse, but currently performing less than two projects. Similarly, the choice of a bank is limited by relational constraints: DevHouse is interested only in banks at which it has a bank account, had already obtained a loan from those banks, and currently has no loan from them.

In the ErGo system, the definition of relational constraints is captured in ErGo Investment Types application. Information concerning constraint is used in ErGo MatchMaker application during evaluation of possible partner groups. The information concerning constraint is available to users throughout the whole collaborative process of partner selection.

6.2.2 Case Study 2: Removal of Dangerous Chemicals

Assume that the real-estate developer company DevHouse has obtained the financial resources from MoniBank. The construction of the residential building can start with the clearance process of the plot of land with the old oil refinery.

The site preparation company PrepSite supervises the preparation activities, i.e., demolition and rubble removal. The demolition company Demolisher is responsible for the demolition activity, while the debris hauling company CleanIt is responsible for the rubble removal. These three companies are known and trusted by the architect in charge of the project, Archibald Tex.

During the first three weeks, the clearance process proceeds without any major perturbation. During the fourth week, CleanIt identifies presence of many barrels of hydrofluoric acid in the ruins. Hydrofluoric acid is a dangerous corrosive and a toxic chemical substance, involved in many explosions and industrial accidents. The removal of hydrofluoric acid is a specialized activity that CleanIt is not able to perform without putting the security of the construction site and its vicinity in jeopardy.

The new situation requires a new plan for the removal of hydrofluoric acid. A special working group, consisting of DevHouse, PrepSite, CleanIt, and Archibald Tex, is formed to work it out. The working group invites a safety inspector of the Occupational Safety and Health Administration to provide guidance concerning regulations about chemical removal. Moreover, following Archibald Tex’s recommendation, the working group asks an expert in industrial chemicals for a security audit with regard to environmental pollution.

In the security audit, the risk of major irreversible damages for the environment is clearly demonstrated. As a consequence, the working group decides that a new collaborator specializing in dangerous chemical removal has to be contracted by DevHouse. The architect requires the chosen company to be a collaborator of PrepSite, CleanIt, and Demolisher. CleanIt suggests securing the barrels and continuing the site clearance. The safety inspector informs that under existing regulations the demolition activity should be momentarily suspended until the hydrofluoric acid is removed from the construction site. Moreover, a certificate delivered by the Occupational Safety and Health Administration testifying that a company has the appropriate competences concerning dangerous chemicals is required to manipulate hydrofluoric acid.

The ChemOver company, a certified specialist company in dangerous chemical removal, is identified as satisfying the requirement of the architect, i.e., ChemOver is a former collaborator of PrepSite, CleanIt, and Demolisher. Moreover, after a round of negotiations, DevHouse accepts to contract the dangerous chemical removal service provided by ChemOver, as the terms, including the price, offered by ChemOver were aligned with the expectations of DevHouse.

Following the safety inspector’s legal advices, the demolition activity is suspended. Then, after signing the contract with DevHouse, ChemOver removes the dangerous chemicals. With the construction site finally clean from hydrofluoric acid, CleanIt and Demolisher have come back to finish the clearance process of the construction site.

In the ErGo system, adaptation of the service protocol, i.e., modification of a set of activities envisioned in a construction process, can be performed in the ErGo Investments application. The adaptation process takes the form of discussion (cf. Fig. 22). The functionality of the application allows the participants of the construction process to communicate and propose changes in the construction process. Once new activities are created, it is possible to launch partner selection process for these activities that later can be conducted in the ErGo MatchMaker application. The ErGo MatchMaker functionality encompasses negotiations among process participants. At every stage new participants can be assigned to negotiation and can contribute to the ideas. Possible organization and their services that are considered to be assigned activities in the construction process are identified from among organizations and services stored in ErGo organization and ErGo services application respectively. If needed organizations can be assigned to activity directly in the ErGo Investments application, no decision support is provided then to users. Assignment of organization to activity results in creation of contract.

Adapted and Adapting Collaborators. In Case Study 2, the set of adapted collaborators consists of DevHouse, Archibald Tex, MoniBank, PrepSite, CleanIt, and Demolisher. These collaborators are all engaged in the construction of the residential building. The set of adapting collaborators consists of DevHouse, Archibald Tex, PrepSite, CleanIt, the safety inspector, and the expert in industrial chemicals.

Some collaborators are adapted, but not adapting collaborators: MoniBank and Demolisher. These collaborators are not involved in the adaptation of the service protocol in which they are participating. MoniBank is involved in the construction process as a financial institution but not in the adaptation process concerning the hydrofluoric acid removal.

Other collaborators are adapting, but not adapted collaborators: the safety inspector and the expert in industrial chemicals. These collaborators are not participating in the service protocol they are adapting. The safety inspector is involved in the process of defining a solution for the hydrofluoric acid removal, but he is not involved in the construction process.

Other collaborators are both adapted and adapting collaborators: DevHouse, Archibald Tex, PrepSite, and CleanIt. These collaborators are involved in the adaptation of the service protocol in which they are participating. DevHouse is involved in the construction process, as the real-estate developer, and in the adaptation process concerning the hydrofluoric acid removal.

The functionality of the ErGo system encompasses definition of roles for system users. Roles define set of function that the particular user may use when interacting with the system. For instance, it is possible to define the role allowing contribution in discussion concerning contract terms but forbidding signing the final version of the contract. The functionality also encompasses the possibility of granting and revoking rights to access the adaptation process for some users or roles.

The adaptation encompasses functionality and data offered by ErGo Investment application, ErGo Investment Types application and ErGo MatchMaker application. Chosen scope of functions is available also through the m-ErGo application. For instance, construction supervisor visiting the construction site and experiencing slow motion of ongoing works, may immediately start adaptation process and suggest changes in the planned starting dates of activities.

Modeling Changes. In Case Study 2, the safety inspector submits a change proposition concerning the modification of the process model, suggesting the insertion of a new activity “dangerous chemical removal” before the “demolition” and “clearance” activities. The safety inspector may have provided references to the legal articles regulating dangerous chemical removal from construction site as the reason for the change proposition.

In the ErGo system suggestions concerning changes in the construction process are made in form of offers submitted as a part of discussions. Each offer may be described with contextual information in a form of link to referring resources or in a form of attached files. When discussion participants reaches consensus agreed changes are visible in a construction process in the ErGo Investments application. Discussions are performed in ErGo Investment application. If a discussion concerns selection of new partner or services for construction process, it takes place in ErGo MatchMaker application.

7 Conclusions

In this chapter, it has been demonstrated that SOA is a valuable architecture not only at the infrastructural and technical levels but also at the inter-organizational level. SOA-based inter-organizational collaboration is systematically organized around the concept of a service, with organizations mutually providing and consuming services, finally aiming at providing their customers with advanced, but personalized end-user services. As a consequence, application of SOA at the inter-organizational level allows organizations to work in a more user-centric manner, and therefore gain and retain their competitive advantage due to focusing on their core competences.

The solution based on SOA proposed in this chapter supports two main problems of inter-organizational collaboration, namely, flexibility and adaptation. Both the flexible automation of administrative procedures and the adaptation of collaborative processes are tackled by the solution proposed in this chapter. As a consequence, in the context of inter-organizational collaboration, appropriate advanced SOA-based tools and applications, such as the PEOPA platform and the ErGo system, improve efficiency and effectiveness of collaborating organizations in highly regulated and competitive environments.

In globalized competitive environments, business sustainability is a major problem. Business environments in which inter-organizational collaboration is fostered by appropriate advanced SOA-based tools and applications are more competitive and supposedly more innovative, which helps to reduce business failures, and thus to increase business sustainability.

The main contributions of this chapter are the following:

  1. 1.

    An in-depth rationale for a service-oriented approach to inter-organizational collaboration.

  2. 2.

    Two SOA based methods: the CMEAP method supporting flexibility, and a method for the adaptation of service protocols supporting process adaptation.

  3. 3.

    Two prototype systems, the PEOPA platform and the ErGo system, implementing the proposed methods for the needs of collaborators in the construction sector, followed by a case study illustrating how the prototype systems may support construction processes.

Among future works, performance of the proposed methods, especially their scalability, is still to be evaluated, which is of high importance for open SOA ecosystems in which the number of service providers and consumers is not known in advanced while potentially high.

Further support for flexible automation of administrative procedures should aim at developing appropriate solutions for continuous updating of elementary processes in accordance with the ever changing legislation. It is an open question whether these models should be developed by legislative bodies, e.g., as attachments to the legal acts, or should be developed and distributed by independent third parties on a commercial basis.

Another challenge when it comes to the administrative procedure automation is the issue of discrepancies in operating practices in various public agencies, to implement the same legal provisions. These discrepancies can arise from different organizational structures, various IT infrastructures, and different technical capabilities to access public registries in different agencies.

Support for adaptation of collaborative processes may be further extended by supporting change propagation. Research on change propagation would enable knowledge sharing among groups having similar collaboration patterns. A key research problem concerning change propagation is to understand under which conditions the changes made in one instance of a given service protocol can be propagated to other instances of the same service protocol with a different implementation.