Casos de Uso y Escenarios 141

In order to put the guideline into practice, a modeling language is needed to provide a uniform representation for diagrams that describe enterprise architectures. The uniform representation offers an integrated architectural approach to explain and illustrate the multiple architecture domains together with their relations and dependencies. ArchiMate is an EA modeling language which is open and independent to enable enterprise architects to describe, analyze and visualize the relationship among business domains in an unambiguous way. It is an Open Group standard which has evolved to be fully aligned with the TOGAF® standard (The Open Group, 2012).

There are five main primary components of the ArchiMate language as defined by Iacob et al. (2012), namely framework, abstract syntax, language semantics, concrete syntax and viewpoints. The (conceptual) framework consists of rows and columns, which represent layers and aspects respectively, to classify architectural phenomena. The framework is a subset of the Zachman framework and defines how the enterprises are structured. An abstract syntax is in the form of metamodel which contains the definition of the languages. It characterizes the construct of the language and the relationship to other language constructs. Therefore, it is possible to

21 Page show the dependencies between different layers, domains and views of the enterprise architecture. This results in a coherent perspective instead of isolated diagrams.

The language semantics defines the meaning of each language construct and relationship type. The semantics must be very intuitive so that it could be understood even by someone with a novel IT familiarity. A concrete syntax is presented in terms of a visual notation. This type of syntax describes how the language constructs which are defined in the metamodel are presented graphically. Viewpoints are similar to the concept of diagram types in UML. Viewpoints are more flexible because there is no strict regulation in dividing the constructs into viewpoints. Thus, concepts could be used in several different viewpoints. The Figure 4 below illustrates how the components are related to one another.

Figure 4: Components of ArchiMate Approach (Iacob et al., 2012)

In its evolution, ArchiMate includes core concepts and two extensions to accommodate the concerns of modeling concepts for the architecture artifacts description with regards to business goals, architecture principles and requirements (motivation extension) as well as projects, programs, migration, transition architecture and gaps (implementation and migration extension). The Figure 5 below shows the metamodel of implementation and migration concepts. A work package is a collection of actions to fulfill a unique goal in a specified timeframe. It has a clear start and end date, as well as set of goals and results. The work package concept can be used to illustrate various levels of abstraction, for example projects, sub-projects, tasks within a project, programs or project portfolios. Therefore, from concept perspective, a work package is very similar to business process in a sense that it has a set of causally related tasks, aiming to produce a well-defined result. However, unlike a business process, a work package is a “one- off” process which means that its existence is obsolete once the results have been reached.

22 Page Figure 5: Implementation and Migration Extension Model (The Open Group, 2012) For example, to illustrate the work package concept, the Figure 6 below shows a program to rationalize the application portfolio as a work package. The program consists of two projects executed consecutively, one after another, shown also in the form of work package. The first project is executed to integrate the back office system (excluding the CRM systems) and then, the second project is performed to integrate the CRM systems.

Figure 6: Work Package (The Open Group, 2012)

Deliverables are the products of work package and could be in the forms of reports, papers, services, software, physical products or intangible results like organizational change. A deliverable could be the implementation of (a part of) an architecture. They are the precisely- defined outcomes of work packages or when projects are completed. A deliverable is an architectural work product that must be specified contractually, reviewed formally, agreed and signed by stakeholders.

Plateau concept is defined as relatively stable state of the architecture that exists during a limited period of time. The concept is to support the various architectures described for different stages in time. Plateau could represent baseline architecture, target architecture and transition architectures that show the enterprise at incremental states reflecting periods of transition between the baseline and target architectures. Transition architectures enable individual work packages to be grouped into managed portfolios and programs to illustrate the business values at each stage. The order of the plateaus could be modeled by using the triggering relationships. The Figure 7 below shows an example how plateau concept is used to depict the various enterprise architecture states to model the migration from baseline to target architecture. The possible alternate transition architectures are also shown.

23 Page Figure 7: Plateau (The Open Group, 2012)

Gap concept is linked to two plateaus to represent the difference between the two. The plateaus could be between baseline and target architectures or between two subsequent transition architectures. Therefore, a gap is defined as an outcome of a gap analysis between two plateaus. The summary of the extension concepts with regards to implementation and migration phase could be seen in table below:

Table 2: Implementation and Migration extension Concept (The Open Group, 2012)

Concept Definition Notation

Work Package A series of actions designed to accomplish a unique goal within a specified time.

Deliverable A precisely-defined outcome of a work package.

Plateau A relatively stable state of the architecture that exists during a limited period of time.

Gap An outcome of a gap analysis between two plateaus.

Some specific information might need to be derived from the EA to accommodate certain interest of a user. To deliver this, a view concept is defined as a part of an architecture description that addresses a set of related concerns of one or more users. A view is specified by means of a viewpoint which describes how a view should be developed content-wise. Different users have different interests, operate with different concepts, have different views and need different viewpoints. In other words, a view is what a user sees from an EA and a viewpoint is from which perspective a user is looking from (Iacob et al., 2012).

According to IEEE-STD-1471-2000 (Hilliard, 2000), a view is “a representation of a whole system from the perspective of a related set of concerns” and a viewpoint is “a specification of the conventions for constructing and using a view; a pattern or template from which to develop individual views by establishing the purposes and audience for a view and the techniques for its creation and analysis”. Since viewpoints focus only on particular aspects of the architectures, they communicate only the related concerns of specific users groups. What to be included and

24 Page what to be excluded in the view depend on the relevancy and argumentation with respect to a user group’s concerns.

According to TOGAF, a view is the representation of a related set of concerns, of what is seen from a viewpoint. It could be represented by a model, not necessarily be visual or graphical in nature, to depict stakeholder’s interests. Thus, a viewpoint is a definition of the perspective from which a view is taken. In other words, a view is what we see, and a viewpoint is from which angle we are looking from.

With regards to implementation and migration extension, three viewpoints exist: project viewpoint, migration viewpoint and implementation and migration viewpoint. The project viewpoint is mainly used to model management of architecture change from baseline to target state enterprise architecture. The process has significant impacts on the strategy (medium or long term) as well as the subsequent decision-making process. The interested stakeholders of this project viewpoint are (operational) managers, enterprise and IT architects, employees and shareholders. Project viewpoint is suitable to see the relation between the business goals and programs or projects. It allows having an overview that all business goals are sufficiently covered by the current portfolio.

The migration viewpoint is used to model the transition of architecture change from baseline to target architecture. The user groups (stakeholders) of these migration viewpoints are enterprise architect, process architects, application architects, infrastructure architects and domain architects, employees and shareholders.

The implementation and migration viewpoint relates programs and projects to the areas of architecture that they implement. This allows modeling the programs’ scope and activities in terms of the realized plateaus or affected enterprise elements which are indicated by annotating the relationships. Implementation and migration viewpoint could be related to business goals through programs and projects to parts of architecture. Therefore, analyzing the consistency between project dependencies and dependencies among plateaus or architecture elements is possible. The related stakeholders using this viewpoint are (operational) managers, enterprise and IT architects, employees and shareholders.

To characterize the content of a viewpoint, ArchiMate defines the following level of details (Iacob et al., 2012):

● Details. The views on this level focus on one layer and on a small portion of the architecture where many details are given. Typical stakeholders are domain architects (software engineers to design and implement a software component) and process owners (responsible for effective and efficient process execution).

● Coherence. The views at coherence abstraction level cover either multiple layers or multiple aspects yet in less detailed form. Multiple layers or aspects viewing allow stakeholders to focus on architecture relationships such as process-use-system or application-uses-object. Typical stakeholders are operational managers who are responsible for a collection of IT services or business processes.

25 Page ● Overview. The overview abstraction level addresses both multiple layers and multiple

aspects. Typical stakeholders are enterprise architects and decision makers such as CEOs and CIOs.

Based on the ArchiMate® 2.0 specification, all of the viewpoints related to the implementation and migration extension fall in “overview” level of abstraction. This means that multiple layers and multiple aspects should be covered by the views supporting the viewpoints. The general stakeholders interested in these viewpoints are mostly the enterprise architects.

Apart from the perspective of abstraction levels, the views and viewpoints are also classified from the purpose of views. There are three main types of the purposes of the views, as listed below. However, the classification does not necessarily mean that a viewpoint or view under a category cannot be used for another purpose. Some decision support viewpoints may also be used to communicate architecture to particular stakeholders as well when necessary.

● Designing. To support architects and designers in the design process from initial sketch to detailed design.

● Deciding. To assist managers in the decision making process by offering insight into cross- domain relationship, typically through projections and intersections of underlying models, but also by means of analytical techniques. Typical examples are cross reference tables, landscape maps, lists and reports.

● Informing. To inform any stakeholders about the enterprise architecture in order to gain understanding, obtain commitment and convince the opposing stakeholders. Typical examples are illustrations, animations, cartoons and flyers.

All of the three viewpoints under implementation and migration extension are supported by all of the three views’ purposes above. For example, analyzing potential overlap between project activities and dependencies would contribute to designing process in doing the transformation planning. Showing the significant consequences of the migration architecture on the strategy (project viewpoint) would provide crucial information for subsequent decision making process.