• Keine Ergebnisse gefunden

Existing architecture frameworks and architecture models

The theoretical part of the methodology does not develop an overall C-ITS architecture (3.2) completely from scratch but first analyses and reuses existing architecture models.

Several popular methods and models were selected for this approach, a slightly more de-tailed description of the core sources are provided in the subsequent subsections.

Referen-Figure 2.1.: Example for ArchiMate elements

ces and documents for further reading can be found in the respective subsections.

2.1.4.1. TOGAF

TOGAF is an enterprise architecture methodology and framework that was originally de-veloped by The Open Group. The TOGAF architecture was first published in 1995 and is originally based on the US Department of Defense Technical Architecture Framework for Information Management [Department of Defense, 2010]. From then on it was conti-nuously advanced by architecture experts and new versions are published regularly. The methodology is one of the most popular enterprise architecture standards and it is applied across different industries.

TOGAF provides a methodology to develop an architecture, the so called Architecture De-velopment Method, and a framework, in which the developed artifacts can be classified, the Enterprise Continuum.

TOGAF is owned by The Open Group consortium and free of use. The current version is 9.1, a detailed description is available online [The Open Group, 2011b] and in the corre-sponding book [The Open Group, 2011a].

2.1.4.2. Zachman Framework

The Zachman Framework is a classification schema for architecture artefacts. It provides a framework to formally structure enterprise architectures and their viewpoints. The Zach-man Framework was originally developed by John ZachZach-man in 1978. Since then it was extended and formalized.

The Zachman Framework has a matrix structure and consists of a set of rows and columns.

The rows comprise different viewpoints, starting on an abstract, high level going down to technical aspects. The individual rows are not independent, aspects from a higher row have implications on the lower row. Examples for rows are Business Model, System Model or Technology Model. The different columns have no specific attributes but contain funda-mental questions and the respective answers form a description of the system concerning this specific aspect. Examples are ’What’ – data; ’How’ – process flow and functions; ’Who’

– responsibility assignments.

The Zachman Framework does not provide a methodology to develop an enterprise ar-chitecture but only a structural framework for the different viewpoints and aspects of an architecture.

An overview sheet of the Zachman Framework is available online [Zachman, 1987].

2.1.4.3. Gartner

The Gartner approach was originally developed out of best practices in industry by sev-eral architecture experts. It comprises no specific methodology but a collection of various methodologies and their practical application. It is therefore closely linked to other archi-tecture methods, the core value in this context are the Gartner experts who support the customer in applying enterprise architecture know-how to its company.

There is no detailed material or formal description of the Gartner approach available – usu-ally experts are sent to the team that needs to develop the architecture, detailed descrip-tions are proprietary to companies that provide the Gartner architecture support. Some limited information is available in Bente et al. [2012] and Sessions [2007].

2.1.4.4. FGSV pyramid

The architecture task force (Arbeitsausschuss 3.1 Telematics) within the German FGSV (Forschungsgesellschaft f ¨ur Straßen- und Verkehrswesen) developed an architecture model which was published in 2012 [FGSV AA 3.1.4, 2012] . Experts from different German ITS companies, research institutes and universities were involved in the design and specifica-tion process.

The FGSV architecture proposal addresses different levels of detail (Framework Architec-ture, Reference ArchitecArchitec-ture, System Architecture) and in each level different viewpoints.

The viewpoints of one abstraction level (e.g. Reference Architecture) form a hierarchical pyramidal structure (see Figure 3.6) with the strategic (organizational) viewpoint at the top and the infrastructure (technical) viewpoint at the bottom. Inbetween are viewpoints called business process, information structures and technical services.

Practical application and implementation of the FGSV structure was done in the ITS frame-work architecture for public transport in Germany [Kieslich et al., 2013].

2.1.4.5. Open Distributed Processing

Open Distributed Processing (ODP) is a series of ISO standards initially published in 1998 ([ISO 10746-1, 1998]-[ISO 10746-4, 1998]). The ODP standards were developed by a joint initiative of several standardization organizations: ISO, IEC (International Electrotechni-cal Commission) and ITU-T (International Telecommunication Union - Telecommunica-tion StandardizaTelecommunica-tion Sector).

The ODP standard mainly addresses architectures of distributed systems. The methodol-ogy has an object oriented approach which is used as well to delimit the system: internal (enterprise) objects are part of the system and are specifically set up as mechanism to en-able or support the provision of a service via the considered system. External (enterprise) objects are involved in the system but not specifically set up.

ODP defines five different viewpoints, Enterprise, Technology, Information, Engineering,

Communication. Each of the viewpoints fully describes the system from the respective perspective. The scope of each viewpoint is described in detail in the standards. The viewpoints can be described in UML, details on the realization are described in ISO 19793 [2008]. An example for the practical application of the ODP standard are the Electronic Fee Collection (EFC) standardization activities in Europe [CEN 17573, 2009].

NOTE: Similar concepts like ODP are used in architectures developed for the US Department of Defense [2010] and the Concept of Operations for the use of ITS in the US [US Department of Transportation, 2011]. In both descriptions the initial concept described in the ODP standard was partially modified and adapted to the respective needs, mostly the viewpoints defined in ISO 10746 are preserved.

2.1.4.6. Standards

ISO 14813[2006] is a multi-part standard that addresses different aspects. In this thesis only part 5 on ’Requirements for architecture description in ITS standards’ is considered.

A short summary of the individual parts can be found in an overview over ITS standards [Williams, 2008].

Part 1: ITS service domains, service groups and services

Part 2-4: not applicable to ITS – focus on TICS (Transport Information and Control Sys-tems) = subset of ITS

Part 5: Requirements for architecture description in ITS standards Part 6: Data presentation in Abstract Syntax Notation One (ASN.1)

ISO 42010 [2007] Systems and software engineering – Architecture description is the core standard about architecture structures of systems. It proposes a conceptual meta-model that consists of the core elements of an architecture, the meta-model itself describes their relation. The meta-model is complemented by a generic description of best practices spec-ified as requirements. ISO 42010 strongly influenced the definition of viewpoints in an architecture.

2.1.4.7. Other

Besides the architecture models detailed in the previous chapters there exist a number of other architecture models and frameworks. The description of TOGAF additionally refers to a large number of other Enterprise Architecture Frameworks e.g. C4ISR tecture Framework, CORBA, Enterprise Architecture Planning, Federal Enterprise Archi-tecture, Federal Enterprise Architecture Framework, ISO/IEC TR 14252:1996, NCR Enter-prise Architecture Framework, SPIRIT Platform Blueprint Issue 3.0, TAFIM, TEAF [The Open Group, 2011a]. Various other sources provide additional lists of Enterprise Architec-ture Frameworks, e.g. Schekkerman [2006].

Those are not detailed here as they are not used in the subsequent methodology and be-cause the architectures listed there are either overlapping with the already mentioned En-terprise Architecture Frameworks or are of minor importance because they address very subject-specific fields. Partially, they were only modifications of other existing Enterprise Architecture Frameworks.