Motivation for the Article and Statement of the Problem
Enterprise architecture management in e-government has been frequently discussed and operated at a highly technical level so far. An extremely compelling method for deriving e-government application landscapes appears to come from business. In order to understand business in the administrative context, it is necessary to record and to differentiate business process areas and organisational correlations. In a business process model for the e-government area, it is possible to differentiate the following process areas according to Walser (2008) and Walser and Riedl (2009): policy-making processes, operational business processes, strategic business processes for the two aforementioned process categories, and support processes and processes in the area of interoperability (extending business processes across administrative units in hierarchical, vertical or network form). The discussion of political or policy-making processes is therefore difficult and problematic, because political activities are less transparent, less straightforward, and more complex, than operational administration processes, for example. Moreover, until now there has been no clear and reliable model for explaining policy-making processes and procedures, which may vary depending on national state systems. In order to discuss the architecture, therefore, it was necessary to find a concept or model which is as simple as possible, and the components of which can be converted into enterprise architecture. This is the case with the policy cycle concept.
It is very likely that enterprise architectures for organisational units which are specialised in making policies on a federal level are more dominant and more differentiated than those on the member state or municipality level. However, the mechanisms among administrations, executive, legislature, and stakeholders as well as voters on all three levels, federal, (member) state, and municipality, can be considered to be similar, even if – from an institutional point of view – they are not as extensively developed. From this perspective, it may seem obvious to consider an independent generic architecture model for policy-making organisations of public administrations which involves all possible stakeholders, based – for instance – on a stakeholder model of a policy domain. An interoperability concept should be implemented between operational administration information systems and policy administration information systems. Policies may be (but do not have to be) based on information input from the operational administration level.
Thus the notion of forming the architectural concept in conjunction with the policy cycle is a new subject, as is addressing the generic enterprise architecture topic in administrations. Little literature is available. Only few convincing solutions for the issues to be addressed have been visualised or realised in practice. Apart from the policy cycle concept (Lasswell, 1956, 1971; Héritier, 1993; Everett, 2003; Howard, 2005) – which is considered to be controversial due to its practicability – no empirically verified and unique concept of policy-making organisations exists that could serve as a basis for the specification of architectures. In addition, the stakeholder concept (participants of the political process) needs to be considered in order to distinguish political processes of an administration in terms of cooperation. Currently, only a few aspects of the policy cycle are discussed via certain keywords in e-government: e.g. e-participation, e-voting, e-citizenship. All these concepts need to be properly distinguished from the operational administration work through an appropriate architecture discourse and must be put in a binding framework. However, interfaces do exist between operational administration and policy-making, e.g., in the data area. (Electronic) elections and votes require citizen data which is managed and maintained by operational administrations. Thus, the architectures of both policy-making and operational administration are explicitly linked with one another, and so the understanding of the political process, its participants and involved institutions, as well as the dependencies among the system elements, forms the focus for analyzing the requirements for an enterprise architecture for policy-making organisations of public administrations. The advantage of the policy-cycle framework is that, thanks to its simplicity, it is relatively easy to implement in applications. This is a good reason to adopt it as a template for discussing enterprise architecture management in the policy-making administration domain. Some essential and influential parameters must be considered with regard to the creation of architectures for policy-making organisations of public administrations. Namely, the political process as a whole has no clearly defined owner; the different phases of the policy cycle are owned rather by various and changing participants. It is therefore difficult to determine an “owner of the enterprise architecture”. The political process is characterised by a kind of “free floating” or power play of different interest groups and by various policy aggregation and specification stages. This impedes the clear assignment of responsibility for the process or parts thereof. The same applies to responsibilities for possible applications, with the exception of core administration applications supporting the political process. Thus, the entire architecture-addressing infrastructure does not necessarily have to be provided by federal government. Instead, different infrastructures are possible and indeed more feasible; however, it should be possible to link them in an intelligent way with the focus on interoperability in stakeholder networks. An initial conclusion is that the architectural concept should be open, similar to the organisational setting, and with facilities for ad-hoc interoperability. Enterprise architecture for a policy-making organisation of a public administration may also be considered from the perspective of the four views or levels of the TOGAF framework of the Open Group (2004): business architecture, application architecture, system architecture and data architecture.
The question of modularising the diverse areas for processes, data, and applications as well as for systems forms the focus of the four TOGAF architecture domains, for the purpose of overcoming intricacy issues. Another question is whether modularisation should be primarily based on domains. This can be realised in compliance with the different business, activity, process or application areas of the policy-making organisation.