In the ArchiMate language, this corresponds with business objects, data objects, and artifacts, and the realization relationships between them. The distinction between logical and physical elements has also been carried over to the description of applications. Logical components are implementation or product-independent encapsulations of data or functionality, whereas physical components are tangible software components, devices, etc. This distinction is again useful in progressing Enterprise Architectures from high-level, abstract descriptions to tangible, implementation-level designs.
Note that building blocks may contain multiple elements, which are typically modeled using the grouping concept in the ArchiMate language. The ArchiMate language has three ways of modeling such abstractions. First, as described in [ 6 ], behavior elements such as application and technology functions can be used to model logical components, since they represent implementation-independent encapsulations of functionality.
The corresponding physical components can then be modeled using active structure elements such as application components and nodes, assigned to the behavior elements. Second, the ArchiMate language supports the concept of realization. This can best be described by working with the Technology Layer upwards.
The Technology Layer defines the physical artifacts and software that realize an application component. It also provides a mapping to other physical concepts such as devices, networks, etc. The realization relationship is also used to model more abstract kinds of realization, such as that between a more specific requirement and a more generic principle, where fulfillment of the requirement implies adherence to the principle.
Realization is also allowed between application components and between nodes. This way you can model a physical application or technology component realizing a logical application or technology component, respectively.
Third, logical and physical application components can be defined as specializations of the application component element, as described in Chapter 15 see also the examples in Section The same holds for the logical and physical technology components of the TOGAF Content Metamodel, which can be defined as specializations of the node element see Section The ArchiMate language intentionally does not support a difference between types and instances.
Similarly, a business process in the ArchiMate language does not describe an individual instance i. In most cases, a business object is therefore used to model an object type cf. For instance, each execution of an insurance application process may result in a specific instance of the insurance policy business object, but that is not modeled in the Enterprise Architecture.
The ArchiMate language separates the language concepts i. Different stakeholder groups may require different notations in order to understand an architecture model or view. The viewpoint mechanism explained in Chapter 14 provides the means for defining such stakeholder-oriented visualizations. Although the notation of the ArchiMate concepts can and should be stakeholder-specific, the standard provides one common graphical notation which can be used by architects and others who develop ArchiMate models.
In the remainder of this document, unless otherwise noted, the symbols used to depict the language concepts represent the ArchiMate standard notation. This standard notation for most elements consists of a box with an icon in the upper-right corner. In several cases, this icon by itself may also be used as an alternative notation. This standard iconography should be preferred whenever possible so that anyone knowing the ArchiMate language can read the diagrams produced in the language.
Nesting elements inside other elements can be used as an alternative graphical notation to express some relationships. This is explained in more detail in Section 5.
Joining the ArchiMate Forum enables you to actively support the use, dissemination, and further development of the ArchiMate Specification. The ArchiMate Forum is open to all Open Group member organizations that apply Enterprise Architecture in practice, or support its use and development. More about the ArchiMate Forum. The Open Group Forums and Work Groups provide members with a vendor-neutral environment where they collaborate with a world-class network of peers, and have early access to information that enables them to lead the development of standards, certifications, and best practices.
To represent the interests of your organization in these highly influential Forums and Work Groups, join The Open Group today. The document can be obtained from The Open Group Library here. The ArchiMate motivation viewpoints defined a set of example viewpoints for modeling the motivational aspects of an enterprise architecture.
The stakeholder viewpoint is used to model the stakeholders, drivers of changes both internal and external , and the assessments of these drivers, in terms of SWOT. It may also be used to model the links to the initial goals that address these concerns and assessments. These goals form the basis for the requirements engineering process, including goal refinement, contribution and conflict analysis, and the derivation of requirements that realize the goals.
The goal realization viewpoint models the refinement of high level goals into more specific goals, and the refinement of these specific goals further into requirements or constraints. The refinement of goals into sub-goals is modeled using the aggregation, while the refinement of goals into requirements is modeled using the realization.
The requirements realization viewpoint shows the realization of requirements by core elements such as business actors, business services, business processes, application services, application components, etc. Typically, the requirements result from the goal refinement viewpoint. The motivation viewpoint can be used to present a complete or partial overview of the motivation aspect by relating stakeholders, their primary goals, the principles that are applied, and the main requirements on services, processes, applications, and objects.
The ArchiMate strategy viewpoints defined a number of example viewpoints for use in modeling the strategic aspects of the enterprise. They can be used in modeling the high-level strategic direction and make-up of the enterprise. The capability map viewpoint presents a structured overview of the capabilities of the enterprise. A capability map typically shows two or three levels of capabilities across the entire enterprise.
Very often, capability map viewpoint is to be used as a heat map. The capability map viewpoint allows the business architect to create a structured overview of the capabilities of the enterprise. It can, for example, be used as a heat map to identify areas of investment. In some cases, a capability map may also show specific outcomes delivered by these capabilities.
The outcome realization viewpoint is used to show how the highest-level, business-oriented results are produced by the capabilities and underlying core elements. The resource map viewpoint shows a structured overview of the resources of the enterprise.
A resource map typically involves two or three levels of resources across the entire enterprise. It can be used as a heat map to identify areas of investment. The ArchiMate implementation and migration viewpoints are defined for modeling the management of architecture change, the transition from baseline to target architecture and relationships between programs and projects.
In the coming sections, we will go over all the ArchiMate implementation and migration viewpoints in detail. A project viewpoint is primarily used to shows the management of architecture change, which involves the modeling of projects to be managed, governed and delivered during the migration from baseline to target architectural.
The migration viewpoint entails models and concepts that can be used for specifying the transition from an existing architecture to a desired architecture. The implementation and migration viewpoint is used to relate programs and projects to the parts of the architecture that they implement. This view allows modeling of the scope of programs, projects, project activities in terms of the plateaus that are realized or the individual architecture elements that are affected.
We use cookies to offer you a better experience. By visiting our website, you agree to the use of cookies as described in our Cookie Policy. What are Example Viewpoints? Download Now. Name Perspective Concerns Organization Structure of the enterprise in terms of roles, departments, etc. Identification of competencies, authority, and responsibilities Information Structure Shows the structure of the information used in the enterprise.
0コメント