Search for content

ArchiMate viewpoints

Here the viewpoints are described for solution architectures in particular, based on a different approach than the method with Viewpoints as described in the ArchiMate documentation. This is an elaboration of an organization that has determined a number of viewpoints for its own context. It is important that the viewpoints are related to each other. Within the viewpoints we work with:

Primary elements (green border), these are elements that in principle must be elaborated in these diagrams.

be used in these diagrams

It is important that we keep the number of concepts relatively limited and that the different viewpoints are related to the project package template for project or solution architectures.

Repository element

Architectural Style

The combination of distinctive features related to the specific context within which architecture is performed or expressed; a collection of principles and characteristics that steer or constrain how an architecture is formed.

Repository element

Architecture

The fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution.

The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time.

Repository element

Architecture Building Block

Statement An architectural building block is the logical definition of a functionality Description The abbreviation ABB is used for an architectural building block. An architecture building block describes the functionalities that are offered to a higher-level entity. An ABB describes WHAT is needed, without writing to a specific solution. The higher-level entity can be a service or a composite ABB. An ABB can be composed of one or more SBB. These SBB are the implementation of the functionality. In other words, the SBB realizes the ABB. Features

Description of a functionality

Description of the behavior of information provision elements without features of physical implementation

ABB is logical, without technical specification or brand names

Infrastructural and application layers are the most important application area in the current phase of this model.

Architecture building blocks are related to qualities, constraints and principles.

This is the framework within which, for example, a product manager can select a product.

When a product is at the end of the LCM, the frameworks in the ABB can be be used again to select a new product.

The basic principle is to prevent an ABB from being written to an available solution. This should therefore be solution and technology neutral.

Repository element

Architecture Governance

The practice of monitoring and directing architecture-related work. The goal is to deliver desired outcomes and adhere to relevant principles, standards, and roadmaps.

Repository element

Architecture Principle

A qualitative statement of intent that should be met by the architecture.

Repository element

Architecture principles

Overview of the architectural principles and possible constraints. With extensive collections of principles, a hierarchy can be introduced here, for example based on basic and derived principles. In the case of extensive collections, the principles are often visually represented in the form of a number of diagrams.

Repository element

Architecture Repository

The Architecture Repository is a software tool that stores key architectural inputs and outputs, including Architectures themselves, their constituent elements, standards, references, principles and the Governance Register. Regardless of the Architecture Framework or Architecture Language selected. An enterprise architecture repository is therefore a collection of artifacts that describes the current and intended enterprise landscape of an organization. The purpose of the enterprise architecture repository is to represent the organization's inventory of technology, data, applications, and business artifacts and to show the relationships among these components. This is achieved by creating diagrams and visualizations based on the contents of the architecture repository.

Repository element

Catalog

Statement A collection of logically related building blocks of the same specialization (service, ABB or SBB). Description A catalog is a collection or register of building blocks of the same type. It is often aimed at a specific field of work, such as infrastructure, geo, integration. A catalog often contains building blocks of the same specialization, i.e. services, architecture or solution building blocks. However, the building blocks within this will often also be composed. A catalog can be seen as a showcase of generic and reusable architectural products. When these building blocks are used by a project, a number of architectural requirements, principles and requirements are met. The advantage for architecture is that these building blocks are reused. The advantage from a project perspective is that the architectural principles are met and that implementation is standardized and can probably be done faster. Due to changes in the environment (projects, LCM, innovations), the content of a catalog will regularly be adjusted, expanded or made more detailed elaborated. A catalog and the entities included in it thus become a "living" ecosystem. Initially, a supply-driven catalog model will be used. Becoming with others. Every domain architect creates a building block catalog for his domain. At a later stage this will be adapted to a demand-oriented elaboration, the so-called showcase model. architecture) concept can be included in a catalog.
Catalogs are categorized based on a scope. (e.g., infrastructure, integration, geo).

Catalogs within a scope have an owner.

Catalogs are described in a registry (managed in Sparx Enterprise Architect and published to HTML and PDF documents)

Catalogs are often hierarchical or layered in design. On the one hand due to the division into Service, ABB and SBB, and on the other hand due to the design with composite building blocks.

Repository element

Clear source disconnect point

There is a clear (technical) decoupling point for integration between source (supplying party) and the D&A environment (receiving party). Quality of the data supplied (completeness, accuracy, timeliness) is the responsibility of the source. Integration is standardized and follows integration architecture principles.

Repository element

Core element

A generic entity has been created here that in principle includes all elements of the ArchiMate core, i.e. the business, application and technology layer. That is why reference is made to the overview panel of the viewpoints, which can be reached by double-clicking on the core element.

Repository element

Data Management Frameworks [Principle]

Data or information management principles set frameworks for change in the organization, often within projects within the data roadmap. Elaborated in the selection of existing standards such as DMBoK, ArchiMate. The frameworks are developed on the basis of principles based on the principles within the enterprise architecture.

Repository element

Foundation Architecture

Generic building blocks, their inter-relationships with other building blocks, combined with the principles and guidelines that provide a foundation on which more specific architectures can be built.

Repository element

Frameworks and guidelines register

Developing and managing a framework and guidelines register, such as a list of data principles, standards and possibly data requirements related to the enterprise principles.

Repository element

Goals and needs

Architecture models for the elaboration of stakeholders, goals, needs and principles surrounding the introduction of an architecture repository within an architecture team.

Repository element

Organization strategy

Description of the goals and drivers of the organization. If desired, expanded with a model of principles and/or requirements.

Repository element

Prescriptive architecture

The framework-setting architecture is of great importance for steering the change in an organization to transform from the baseline architecture to the target architecture. Setting frameworks is often developed on the basis of architectural principles or nowadays also called binding architecture agreements. You can also find the description of the viewpoints because they can also be considered as setting the framework.

Repository element

Principle

Repository element

Principle

Applied principles from the (government) reference architectures and the own {Organization} and project specific principles

Repository element

Principle

Naming Conventions Usage: Short title Code in attribute Alias For example: Reuse for purchase for customization

Repository element

Principle

Architecture Principle.

Repository element

Principle-Goal-Matrix

Repository element

Principles

Repository element

Quality

The quality of data and information is actively managed and improved throughout the entire life cycle - Rationale Data and information is the raw material for business processes. Good quality ensures greater efficiency, reliability and compliance for everyone involved. The quality of data and information is crucial for making the right decisions. - Implication Quality management is assured throughout the entire life cycle of data and information. Focus on 'First Time Right' (Lean principle) and where necessary a control/review step.

Repository element

Requirement

Requirements are the descriptive characteristics that are provided in the building block by the provider or requested by the provider. Consider:

Requirements.

Principles.

Constraints.

Functional qualities.

Non functional qualities.

Repository element

Service

Statement Services are the description of a combination of functionalities and services between provider(s) and customer(s). Description Services are a form of encapsulation of the functionality and implementation of a composition of building blocks. Services, just like ABB and SBB, are used as a means of communication between provider and customer to indicate which service will be provided by the provider to the customer. Services can also be defined internally within the organization (also in a provider and customer context), for example infrastructural services for an application service or customer. A service can be a composition of a building block that implements functionality within the ICT landscape. In addition, a service can consist of providing more structured (ICT) work processes in relation to the above-mentioned IT landscapes, for example a service desk. In this document we have limited the scope to that of the ICT architecture, ICT work processes are not elaborated here but are certainly relevant within other parts of the organization (service management). This building block model can be applied in several ways if desired and not only in the IT field. Here we limit ourselves to ICT architecture. Services can be composed of underlying services. In addition, they can be composed of one or more architectural building blocks. These compositions can create constellations of building blocks that ensure standardization of reusable applied services. Consider a standard application server with services (such as backup and restore) and ABB (for example relational storage) Services are related to requirements, constraints and principles. This is preferably elaborated to indicate which needs are met from a customer perspective and which are not. There is a lot of confusion around the term service. To avoid a discussion about the definition with each composition of persons, the term service is chosen, which is based on the characteristics below. In addition, a list of synonyms has been formulated that refer to the same characteristics below. Characteristics

A repeatable activity or behavior that is requested to be performed.

A service offers one or more solutions to ICT needs that are understandable to the customer.

Combination of an implementation of a functionality in one or more ABBs.

Possibly in combination with one or more ICT work processes as a service.

Services are offered to customers by providers.

Services have a commercial and a financial (cost) aspect.

Services have conditions for use and/or implementation.

Repository element

Solution Building block

Statement A solution building block is the physical implementation of a functionality developed in one or more ABB. Description For a solution building block, the abbreviation SBB is used. An SBB describes the implementation with which a functionality is realized. An SBB offers this implementation to a higher-level entity. In our model, an SBB is an implementation of ABB or of a composite SBB. It is relevant here that a distinction is made between architectural layers. For us, the infrastructural and application layers are the most important areas of application. An SBB at application level can therefore be a composition of SBBs at both the application and the infrastructure layer. SBB are related to qualities, constraints and principles. This is preferably elaborated to indicate which requirements are met from an implementation perspective and which are not. This in combination with the model of qualities within the ABB and the requirements as developed at service level provides a complete description of the features offered by a service. Features

SBB is a physical implementation of one (part of) or more ABBs or functions.

Technical and product specifications are known.

Brand and supplier names are known.

An SBB can often be replaced by another product or implementation.

Repository element

Convention conceptual datamodel
This diagram is a viewpoint for developing a conceptual data model. This viewpoint indicates which types of object types and connector types can be used when drawing up a conceptual data model. A few principles apply to the conceptual data model:

Conceptual data model is for multiple stakeholders (including non-ICT professionals) and should be simple in design.

Conceptual data model has been developed in ArchiMate (business layer).

Only the stereotypical Business Object is used for the conceptual data model.

The conceptual model has a hierarchical structure based on domains.

If this reduces the complexity, multiple diagrams can be created for a domain.

The conceptual model is related to the logical data model. See the hybrid meta data model for this.

The conceptual model can be related to, for example, the other data management business functions within Example.

Repository diagram
Convention logical datamodel
This diagram is a viewpoint for developing a logical data model. This viewpoint indicates which types of object types and connector types can be used when drawing up a logical data model. A few principles apply to the logical data model:

Logical data model is for all stakeholders (ICT professionals and non-ICT professionals) and must be understood by all stakeholders after an explanation of the metamodel.

Logical data model is developed in UML Class Modeling.

For the logical data model, only the Class and Enumeration stereotypes are used.

The logical model has a hierarchical structure based on abstract and concrete entities with a specialization connector.

For a logical domain, multiple diagrams can be created if this reduces complexity.

The logical model is related to the parent conceptual model and to the underlying physical data models. See the hybrid meta data model for this.

Repository diagram
Convention RDBMS datamodel
This diagram is a viewpoint for developing a physical data model for SQL Server RDBMS. This viewpoint indicates which tables, constraints and columns can be used when drawing up an RDBMS data model. A few principles apply to the RDBMS data model:

Physical data model is for ICT (Database specialists).

SQL DDL statements can be generated from the Physical data model.

Naming conventions for the database platform (SQL Server/Oracle) serve as the basis for the Naming Conventions.

The associations show the database details for the referrer and primary keys.
Repository diagram
Example XBB requirements and constraints PIM
This example shows in a simple manner how the characteristics/requirements can be made transparent based on requirements, constraints, qualities and principles. This example shows how the characteristics of the different xBB can be mapped based on ArchiMate concepts. This will soon become an important mechanism in the various xBB catalogues. In addition to this approach, the characteristics can also be elaborated via the internal characteristics of the entities in EA. Such as requirements, constraint and scenario. Finally, there is the option to use tagged values. The working group has determined that making associations between ArchiMate concepts is preferable. If an elaboration with ArchiMate concepts is insufficient and you want to rely on internal properties or tagged values, this must be short-circuited.
Repository diagram
Motivation basics
For the application landscape Giovanna wants to set up a few principles This is to reduce ICT costs and to simplify the IT landscape Think about principles like application rationalization etc Create an ArchiMate diagram of this motivation architecture
Repository diagram
Motivation viewpoint
Goal: To provide insight into the principles related to elements in order to ultimately determine the right to exist of these elements. In addition, it provides insight into which solutions implement the same principles. Not required Use the motivation elements of Archimate for this. The principle element is included there. This can possibly be supplemented with requirements/constraints to indicate the implications. The principle can be linked to an Outcome, where the rationale in the association from principle to Outcome is described. In addition, if desired, the complete motivation can be elaborated in principles, drivers, etc.
Repository diagram
Principles architecture repository
Summary of a number of architectural principles relevant when working with a repository-driven approach. Please note this diagram is a simplified representation. A relationship has also been established in the repository, for example with the stakeholders and the goals. However, these are not shown in this part but can be found within the elaboration of the matrices for the motivation of using an architecture repository. Please see the sample repository where you can find all the relationships between architectural elements.
Repository diagram
Viewpoint Building blocks and requirements
An important additional dimension when describing the xBB are the characteristics that are relevant to the communication between the provider of the xBB and the customer. This extra dimension focuses mainly on the characteristics that an xBB does or does not meet. These can be restrictions, rules or principles. The viewpoint uses three ArchiMate concepts from the motivation extension:

Principle, often derived from national government reference architectures.

Requirements, requirements and (non-functional) quality aspects.

Restrictions are requirements that usually apply to the SBB, for example aimed at certain programming paradigms or languages.

For the associations between the motivation elements and the other elements, association, influence and realization can be used. With realization you can establish a positive relationship between the core elements and the motivation elements. Influence is then reserved for a negative influence from the core elements to the motivation elements. In this model, only the viewpoint building blocks within the application layer have been elaborated. Naturally, the same as described above applies to the viewpoint on the technical layer.
Repository diagram

ArchiMate viewpoints
Here the viewpoints are described for solution architectures in particular, based on a different approach than the method with Viewpoints as described in the ArchiMate documentation. This is an elaboration of an organization that has determined a number of viewpoints for its own context. It is important that the viewpoints are related to each other. Within the viewpoints we work with:

Primary elements (green border), these are elements that in principle must be elaborated in these diagrams.
< li>Secondary elements (orange border) are elements that may be used in these diagrams
It is important that we keep the number of concepts relatively limited and that the different viewpoints are related to the project package template for project or solution architectures.
Repository package
Architecture principles
Overview of the architectural principles and possible constraints. With extensive collections of principles, a hierarchy can be introduced here, for example based on basic and derived principles. In the case of extensive collections, the principles are often visually represented in the form of a number of diagrams.
Repository package
Goals and needs
Architecture models for the elaboration of stakeholders, goals, needs and principles surrounding the introduction of an architecture repository within an architecture team.
Repository package
Prescriptive architecture
The framework-setting architecture is of great importance for steering the change in an organization to transform from the baseline architecture to the target architecture. Setting frameworks is often developed on the basis of architectural principles or nowadays also called binding architecture agreements. You can also find the description of the viewpoints because they can also be considered as setting the framework.
Repository package

Links 2 Tags