Organizational Viewpoint

The organizational viewpoint is the top layer and most abstract description of a system.

To detail this viewpoint the previously excluded methodologies (section 3.2.4) will be ex-amined closely as they might provide additional and valuable input for a more precise description. Organizational aspects are deduced from those methodologies, both from the theoretical (Top Down Approach) as well as the practical (Bottom Up Approach) per-spective.

3.3.2.1.1. Organizational Viewpoints – Top Down Approach

Valuable input for the Top Down Approach is provided by different theoretical architec-ture models. TheODPstandard ISO 10746 [1998] calls the organizational viewpoint ’en-terprise viewpoint’, which does not only allow for a description of strategies and policies but as well the different roles, responsibilities and organizational cross references. ODP provides definitions for key aspects of an organizational architecture amongst others are the definition for roles, responsibilities and actors. Those definitions are used in this doc-ument (detailed definitions see chapter 2).

Besides those definitions ODP does only provide a very abstract concept of an organiza-tional (enterprise) viewpoint which states the need for policies and rules, roles, their link to responsibilities as well as relationships between roles (e.g. through contracts). Exam-ple applications are given in the Annex of the standard. Another practical application of the ODP standard is the Electronic Fee Collection Architecture Standard ISO / CEN 17573 [2010]. The ODP standard itself does not name any roles. No methodology for the devel-opment of an organizational viewpoint is provided.

Rather problem oriented is the abstract description of roles in ITIL (IT Infrastructure Library) v3 [ITIL, n.d.]. ITIL is used in practice for IT service management in various businesses and provides guidelines, best practices and support for the deployment and operation phase. This includes business processes, organizational structures and tools.

One aspect described in ITIL is a set of roles, covering the whole value chain from de-veloping a service strategy, service design, service transition, service operation to service improvement. The roles which are part of ITIL are arranged in the aforementioned groups [Kempter and Kempter, 2016]. In CEN/ISO 17427 [2013] the different roles of ITIL were analyzed with regard to C-ITS and a subset was selected for the organizational viewpoint described in the standard. Additionally, some roles were merged and restructured to bet-ter reflect the requirements of C-ITS. (For details see Appendix D.)

AlthoughTOGAFwas selected for the definition of the frame structure of the overall ar-chitecture and was the basis for including organizational aspects as a separate viewpoint, no detailed blueprint for an organizational viewpoint is included. Nevertheless, TOGAF provides as part of the model the so-called Architecture Development Method (ADM) [The Open Group, 2011b, Part II ADM] which provides a tested and repeatable process for de-veloping architectures. The method bases on an iterative multi-phase cycle. By running through the various phases an architecture framework and architecture content is devel-oped and defined. Each phase in the cycle consists of the same sequence of steps which are processed with focus on the topic addressed in the respective phase of the ADM cycle. In phase B of the ADM cycle the business architecture is developed. It starts with a so-called baseline description that should as much as possible depend on existing architecture de-scriptions for the considered system. Depending upon the available material either in a top down or bottom up process the business processes are identified. Therefore a structu-red analysis, a use case analysis and process modeling might be undertaken to describe the business abstractly in the corresponding models, structures and processes. Additionally, actors, roles, objectives, functions and other aspects of a business architecture are iden-tified and analyzed. (A detailed description is available in the TOGAF book [The Open Group, 2011b, chapter 8].)

The GermanFGSV architecture is similar to the concepts described in TOGAF. Organi-zational aspects like policies, strategies, roles and responsibilities are covered in two dif-ferent viewpoints: ’strategy’ and ’(business) processes’. The ’strategy’ viewpoint describes the scope of the system, its objectives and strategy. The ’(business) processes’ comprise the roles and responsibilities. Additionally, the ’(business) process’ viewpoint describes the functional decomposition of the system, interfaces and the information model, this part of the viewpoint in fact overlaps with the functional viewpoint (see next section 3.3.2.2) and is not considered to be relevant for the organizational viewpoint.

Though various organizational aspects are covered in the two viewpoints no detailed ex-planation or approach to develop a description of those aspects is provided.

3.3.2.1.2. Organizational Viewpoints – Bottom Up Approach

In contrary, for the Bottom Up Approach the results of various C-ITS projects are consid-ered. An organizational architecture was part of the work program of theSafeSpotProject.

In fact, two deliverables with a preliminary and final organizational architecture [Manfredi et al., 2008, 2010] were developed.

The SafeSpot approach mainly bases on a methodology already applied in ARTIST, the na-tional Italian ITS Reference Architecture [Isola, 2003]. ARTIST derives the organizana-tional

architecture from the functionalities needed to develop and deploy the considered sys-tem – including deployment, procurement, legal framework and implementation aspects.

The approach bases on an analysis of value chains of different services, functionalities are grouped to so-called macro-functionalities which are attributed to stakeholders as homog-enous ’packages’ [Manfredi et al., 2008]. SafeSpot identified through this process a set of roles (according to the SafeSpot definition of a ’role’¹), their detailed description including the whole approach can be found in in D6.3.1 [Manfredi et al., 2008] and D6.3.2 [Manfredi et al., 2010]).

Additionally, organizational schemes for different scenarios and business models were de-veloped by the project. Examples for generic and service specific organizational schemes are depicted in the final Safespot organizational architecture [Manfredi et al., 2010]. The generic process for the identification of roles developed in SafeSpot may be applied to other scenarios. Therefore, both the approach as well as the results (generic roles) shall be picked up in the description of the organizational viewpoint of the C-ITS Reference Archi-tecture (see section 7.1.3).

The FRAME project did not develop an abstract organizational viewpoint but provides in its framework a large number of potential actors involved in ITS and C-ITS. A detailed description of all actors can be found in D15 part 6 [Bossom et al., 2011, Table 1], the visu-alization of the system and its involved actors is provided in the FRAME Browsing Tool [Frame, 2011].

The set of actors itself does not allow to derive any organizational structures including roles and responsibilities but it may be useful to check the results from applying the orga-nizational viewpoint against FRAME. Therefore, this huge conglomeration shall come to use when the basic organizational structure (section 7.1) is developed and a validation is outstanding.

As can be seen from the overview in Tables B.3 and B.4 no other existing architecture from the Bottom Up Approach provides a detailed description of the organizational viewpoint that needs to be considered. The listed examples only slightly touch the underlying orga-nizational structures.

The theoretical analysis of organizational architectures of existing projects and initiatives is complemented by aBottom Up analysis of selected service’s processes, the individual process steps and the corresponding actors. This complementing activity is deduced from the approach applied in Safespot and a detailed description can be found in Appendix D.

It starts with the description of the underlying processes of a selected service. The de-tailed process description is used to identify different tasks and actions that arise during the operation of the selected services. In parallel, actors involved in the process and its steps are identified. Based on the assignment of actors, actions and tasks are grouped and bundled logically. On the other side possible structures for the different tasks and actions are derived from the task and action assignments of real implementations. Both results together are used to identify the maximum number of required interfaces within a process

1definition in D6.3.2 [Manfredi et al., 2010]: role is a set of homogeneous functionalities that need to be performed in order to realize the system

i.e. the maximum number of action or task bundles that might occur in the implement-ation of the selected service. This structure is the basis for the definition of roles – they now need to be named and described, responsibilities (deduced from the original tasks and actions) are assigned. The resulting roles and responsibilities can be matched with theoretical organizational structures to fine-tune the list of roles.

This analysis provides additional input for the detailing of the organizational viewpoint as it provides a potential structure of roles and responsibilities based on a specific service.

(This procedure was developed as part of the Standard ISO 17427 [2013] that describes the organizational architecture for C-ITS.)

3.3.2.1.3. Results and Conclusion Organizational Viewpoint

The additional aspects from other architecture methodologies and projects which were not selected for the frame structure in section 3.2.4 finally provide a valuable contribution to a deepened and more precise definition of the organizational viewpoint. The non-selected theoretical methods help to focus the scope of this viewpoint’s description. Additionally, a closer analysis of the results from the Bottom Up Approach projects, which were excluded in the previous step, showed that they will provide a valuable basis for the concluding validation and verification of the practical methodology application’s results.

Finally, merging the results of this part with the definitions from the previous part leads to the following more precise definition of theorganizational viewpoint scope: The orga-nizational viewpoint describes the strategic goals and objectives as well as the rules and policies applicable in the system. In line with this business focused orientation the organi-zational viewpoint describes the roles and responsibilities for the system, comprising not only the individual roles but as well the link between the different roles. Methodologies like ODP additionally allow to focus the organizational viewpoint on C-ITS itself by cle-arly setting the system boundaries (for details see [ISO 17427, 2013]).

The theoretical methodologies from the Top Down Approach are only capable of provid-ing the scope and boundary conditions for the viewpoint description. More practical gui-dance is provided from the Bottom Up Approach. In short, the following steps are taken to develop an organizational viewpoint:

1. The strategic goals, objectives, rules and policies are defined by the stakeholders and responsible persons from the strategic and political level

2. The roles and responsibilities are identified through the Bottom Up Approach and afterwards are cross checked with the results from various existing projects

A detailed description of the practical application of these steps can be found in section 7.1.