Search for content

ADM

Architecture Development Method.

Repository element

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

Architecture Development Method

The core of the TOGAF framework. A multi-phase, iterative approach to develop and use an Enterprise Architecture to shape and govern business transformation and implementation projects.

Repository element

Business architecture

Description of the business architecture for a method with an architecture repository. A number of business processes and roles are being developed for this purpose. Because working with an architecture repository is a transition to a different working method within the architecture team, the business architecture is therefore an important part to work out in detail. The reason is that a successful enterprise architecture can determine the success or failure of the introduction of an architecture repository.

Repository element

Data quality issue with data object

Issue registration for quality issues within a repository. An ITIL-based method is often used for this issue registration.

Repository element

Data Quality Release [Workpackage]

Especially when introducing complex and impactful measures, working with releases based on a release plan and a structured method of implementation is necessary.

Repository element

Deploying building blocks is relatively simple

Building blocks can be developed as templates within the repository. By using copying building blocks or relating specific parts to these building blocks, a working method with building blocks can be easily introduced.

Repository element

I'm special so not for me

You regularly see in architecture teams that a number of architects do not find it necessary to participate in an architecture repository initiative. This is an anti-pattern and will prevent acceptance of a repository-based method at some point. Try to prevent this as much as possible.

Repository element

Method

A defined, repeatable approach to address a particular type of problem.

Repository element

Modeling community

The modeling community is responsible for making a number of working agreements, such as: ul> The modeling community does this by:

Ensuring the design and conventions for the repository

Developing architectural and modeling conventions

Provides training regarding the repository design and the modeling method

Review developments

Stimulate communication and interaction within the community

Inside the modeling community should jointly introduce the above-mentioned working agreements. Depending on the structure and culture of the organization, different scenarios can be chosen to achieve this Intervision session The modeling community jointly determines what the conventions surrounding modeling are. Within intervision sessions, all participants can submit topics, examples and modeling problems that are discussed and based on discussion, a joint decision is made about the method to be followed and, if desired, the adapted modeling conventions Characteristic of the intervision session are

On a regular basis a session organized for all modellers

In these sessions the various participants bring in questions, solutions and suggestions

Works well in small teams

Model manager Another scenario is that a model manager role plays a pioneering role in introducing a modeling community. The model manager is more active and the modeling community is more passive. Characteristics of the model manager are:

Model manager determines bottlenecks and chooses a solution approach

Sometimes a model core team is deployed for support

Model manager coö ordinates describing the decisions in the repository or help pages

Works well with large teams

Repository element

Modeling convention for data architecture

This is an example of modeling and naming conventions that can be used within an architecture repository. This elaboration is an example of how to develop a metamodel and its conventions. In this case for a data architecture development. The metamodel has been developed based on the DMBoK framework. This means that part of the framework has been developed and the others have not yet. Here, particularly from the point of view of the data architect, is an elaboration of modeling conventions and architectural models. Working with meta data requires a white paper on metadata modeling methods.

Repository element

Overview of landscapes

Overview of the architectural landscapes that have been developed. Often based on multiple diagrams and classified on the basis of the layers in the core model of ArchiMate, if desired, further divided into domains in an organization or architecture. In this document, the overview of the landscapes is classified and classified. This can be done on the basis of packages and one or more diagrams within them, but the use of a naming convention for the diagrams is also an adequate method. It is necessary that the architects can easily find the concepts within the established architecture. On the one hand in the package structure and on the other hand by using search and sorting functionalities.

Repository element

Package structure

Example of a project structure based on the status of different submodels. What is characteristic of this is that the repository has a different layout for each phase. This approach indicates that the package structure does not have to be a limitation. When introducing an architecture repository, a discussion can arise about the package structure about what the correct format is. Keep the following suggestions as a starting point:

The package layout can change for each part of the architecture repository

The package structure can easily be changed if the working method is developed. changing insights

Determining the layout is often managed by the model manager or custodian for the generic architecture components

In work or project package structures, the modelers have more freedom in the design.

For solution architectures, use a template as a starting point.

Take into account the transfer of architectural concepts in a phasing and life cycle in the package layout.

The package structure should be aimed at the modelers who work with the architectural models. Users of these models must be supported in other ways, for example by navigation diagrams.

Repository element

Sipoc

SIPOC is a simple modeling method for modeling business processes, objects and roles. A number of examples have been given. Copy one of the diagrams and adapt it to the new SIPOCs for a company-specific elaboration.

Repository element

Solution Architecture Repository

Architecture model for an architecture repository approach. A number of generic architectural components have been developed in this model. On the one hand, this serves as an example for an architectural development. On the other hand, it can be expanded with organization-specific organizational components of the architecture. This makes it a starting point for an organization-wide architecture. This chapter has been elaborated on the basis of a number of architecture components that are relevant in a solution architecture. The same procedure was followed for the introduction of a method with an architecture repository. In fact, we apply an "eat your own dogfood" approach here.

Repository element

Step-by-step plans

In this document, after the solution for working with an architecture repository has been developed, a number of generic step-by-step plans are developed. These step-by-step plans provide a team with guidance on which activities need to be carried out to realize the transformation from a document-driven method to a repository-driven method. The step-by-step plans in this document consist of a number of generic activities for the introduction of an architecture repository. However, these steps can easily be extended in the specific context of your own organization. Elaboration is based on the order of developing the architecture and then a step-by-step plan for introducing the tooling of the architecture repository.

Repository element

Supervise architecture implementation

When introducing an architecture, the implementation must be guided on several levels. This includes the introduction of a metamodel, the modeling methods and the use, configuration and selection of the tools.

Repository element

t_method

Repository element

t_operation

Modeling behaviour of classes for example methods or operations

Repository element

Train modelers and reviewers

Ensure adequate training of those involved so that they have knowledge of the chosen modeling methods, the possibilities of the architecture repository and the functionalities in the chosen tool.

Repository element

Transition document to repository

the limitations in a document-driven architecture method are chosen by the organization to introduce a repository-based method.

Repository element

Working on the basis of a repository

Working in an architecture repository requires different skills than working with architecture documents. Architectural documents are often realized with office automation. Working in an architecture repository often requires specific tooling and a new working method. In addition, there must be awareness of the characteristics of a repository. Consider, for example, duplicates and the reuse of architectural (partial) models and concepts.

Repository element

Goals architecture repository
What are the goals of introducing an architecture repository into an organization. This section defines a number of generic goals, goals that apply to most organizations that are switching from a document-driven architecture method to a repository-driven approach.
Repository diagram
Modeling community
When introducing an architectural process based on an architecture repository, working with a modeling community becomes necessary. This community must ensure that a number of preconditions are introduced to ensure that the working method with an architecture repository realizes the goals and needs of the architecture team. When working with a repository, the metamodel and a collective view around the modeling techniques applied within the team are particularly necessary. In this view you can see that the modeling community is considered a collaboration of a number of architectural roles within the organization.
Repository diagram
Step by step plan architecture
Introducing an architecture process based on an architecture repository is actually an organizational change. It consists of a number of sequential activities. These sequential activities are generic in this document, but can easily be adapted and expanded to your own context. This step-by-step plan describes a number of steps that you can follow to approach the introduction of an architecture repository in a structured manner. The chapter on tools for introducing an architecture repository explains a number of supporting concepts and methods later in this document. This diagram details the various steps (with underlying diagrams) to arrive at a working method for an architecture repository.
Repository diagram
Viewpoint building block multi layer
This is a discussion board for the situation where a service on the application layer is elaborated in a number of ABB and SBB on the application layer. The ABB application is then completed by the functionality and implementation and ABB and SBB within an infrastructural service. In this image, an example has been developed based on the ArchiMate notation method in which the infrastructural building blocks support the ABB application via a service. This makes the model relatively extensive, but based on the ArchiMate viewpoint.
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
Business architecture
Description of the business architecture for a method with an architecture repository. A number of business processes and roles are being developed for this purpose. Because working with an architecture repository is a transition to a different working method within the architecture team, the business architecture is therefore an important part to work out in detail. The reason is that a successful enterprise architecture can determine the success or failure of the introduction of an architecture repository.
Repository package
Modeling convention for data architecture
This is an example of modeling and naming conventions that can be used within an architecture repository. This elaboration is an example of how to develop a metamodel and its conventions. In this case for a data architecture development. The metamodel has been developed based on the DMBoK framework. This means that part of the framework has been developed and the others have not yet. Here, particularly from the point of view of the data architect, is an elaboration of modeling conventions and architectural models. Working with meta data requires a white paper on metadata modeling methods.
Repository package
Overview of landscapes
Overview of the architectural landscapes that have been developed. Often based on multiple diagrams and classified on the basis of the layers in the core model of ArchiMate, if desired, further divided into domains in an organization or architecture. In this document, the overview of the landscapes is classified and classified. This can be done on the basis of packages and one or more diagrams within them, but the use of a naming convention for the diagrams is also an adequate method. It is necessary that the architects can easily find the concepts within the established architecture. On the one hand in the package structure and on the other hand by using search and sorting functionalities.
Repository package
Package structure
Example of a project structure based on the status of different submodels. What is characteristic of this is that the repository has a different layout for each phase. This approach indicates that the package structure does not have to be a limitation. When introducing an architecture repository, a discussion can arise about the package structure about what the correct format is. Keep the following suggestions as a starting point:

The package layout can change for each part of the architecture repository

The package structure can easily be changed if the working method is developed. changing insights

Determining the layout is often managed by the model manager or custodian for the generic architecture components

In work or project package structures, the modelers have more freedom in the design.

For solution architectures, use a template as a starting point.

Take into account the transfer of architectural concepts in a phasing and life cycle in the package layout.

The package structure should be aimed at the modelers who work with the architectural models. Users of these models must be supported in other ways, for example by navigation diagrams.
Repository package
Sipoc
SIPOC is a simple modeling method for modeling business processes, objects and roles. A number of examples have been given. Copy one of the diagrams and adapt it to the new SIPOCs for a company-specific elaboration.
Repository package
Solution Architecture Repository
Architecture model for an architecture repository approach. A number of generic architectural components have been developed in this model. On the one hand, this serves as an example for an architectural development. On the other hand, it can be expanded with organization-specific organizational components of the architecture. This makes it a starting point for an organization-wide architecture. This chapter has been elaborated on the basis of a number of architecture components that are relevant in a solution architecture. The same procedure was followed for the introduction of a method with an architecture repository. In fact, we apply an "eat your own dogfood" approach here.
Repository package
Step-by-step plans
In this document, after the solution for working with an architecture repository has been developed, a number of generic step-by-step plans are developed. These step-by-step plans provide a team with guidance on which activities need to be carried out to realize the transformation from a document-driven method to a repository-driven method. The step-by-step plans in this document consist of a number of generic activities for the introduction of an architecture repository. However, these steps can easily be extended in the specific context of your own organization. Elaboration is based on the order of developing the architecture and then a step-by-step plan for introducing the tooling of the architecture repository.
Repository package

Links 2 Tags