Search keyword in element

(Enterprise) Reference architecture

A reference architecture is an abstract architecture in which a number of generic frameworks or building blocks are described. Organization-specific (domain and solution) architectures are drawn up based on reference architectures.
Repository element

ABB

Architecture Building Block.
Repository element

ABB Catalogue

Catalog of Architecture Building Blocks with which a number of services can be realized. The catalog functions as an additional form of navigation for future users
Repository element

ADM

Architecture Development Method.
Repository element

Aids for an Architecture Repository

In the previous chapters we discussed the different dimensions of introducing an Architecture Repository. In this chapter we discuss a number of tools that support and simplify the introduction of an architecture repository. We are working on this based on Sparx Enterprise Architect, a modeling tool for various modeling languages. This makes it extremely suitable for setting up Sparx Enterprise Architect as an architecture repository. The elaborations of these tools have all been developed based on Sparx Enterprise Architect.
Repository element

Ambassador

An ambassador (preferably at management) level is needed for the architecture and the use of architecture repositories. For example, for safeguarding interests, making and keeping resources available and involvement in the planning of activities
Repository element

Analyze required application functions

What are the relevant application functions to support the stated work processes. These can then be linked to modules in the architecture tool or to requirements (during a selection process).
Repository element

Application Architecture

A description of the structure and interaction of the applications as groups of capabilities that provide key business functions and manage the data assets.
Repository element

Application Architecture

Repository element

Application architecture Example

Repository element

Application landscape

Overview or basic map of the existing or future information systems, components and applications within the domain of architecture.
Repository element

Apply architecture templates

Standardization of architectural models simplifies the creation, use and evaluation of these architectures. The use of templates makes this standardization possible. Introducing and maintaining templates is therefore a work process.
Repository element

Applying architecture building blocks

Introduction Applying building blocks describes the design and definition of building blocks. Building blocks are introduced to an organization from the perspective of:
  • Reuse.
  • Decoupling
  • Generalization and specialization.
    • < li>Standardization.
  • Interaction between providers and consumers of information provision. concepts (currently applications and infrastructure, but this must also be applicable to business architecture).
  • Specification of costs and revenues.
  • Improve (accelerate) services.
    • li>
  • Information security.
This document consists of the following parts:
  • Model: describes the definition, characteristics and relationships of the concept building block and the associated specializations
  • ArchiMate viewpoints: development of the viewpoints for the building blocks. These viewpoints are composed of a limited set of ArchiMate elements and associations.
  • Examples of elaboration of the various building blocks within the ArchiMate viewpoints defined above
  • Sparx implementation, how this is done is implemented in Sparx and how it is communicated/published to the various stakeholders.
Repository element

AR overmodeling

Architectural models can always be more beautiful and detailed. This is often unnecessary and even undesirable. These overmodeled architectures must also be maintained and managed at a later stage. In addition, a detailed model is neither relevant nor clear for many stakeholders.
Repository element

ArchiMate

ArchiMate is an enterprise architecture modeling language that is used at a higher level of abstraction and is combined with other modeling languages such as BPM and UML for desired detail.
Repository element

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 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

  1. 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.
  2. The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time.
Repository element

Architecture

Abstract business object for different types of specialized architectures. The architecture is thereby enriched with a number of sub-dimensions.
Repository element

Architecture and modeling community

When applying modeling languages and working in a repository, it is very important that there is agreement on the modeling languages and the modeling and naming conventions. This can be achieved by developing a community where this capability is jointly developed and maintained.
Repository element

Architecture board

Depending on the type of solution, infrastructure or application architects participate in the architecture board.
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 Building Block

A constituent of the architecture model that describes a single aspect of the overall model.
Repository element

Architecture capabilities

The architecture capabilities define the parameters, structures and processes that support the management of the architecture repository.
Repository element

Architecture consumer

Different roles in the organization that use the artifacts produced by the architects and taken from the architecture repository.
Repository element

Architecture content producer

Producer of artifacts, data and information that serve as input for preparing architect artifacts (in the architecture repository).
Repository element

Architecture Continuum

A part of the Enterprise Continuum. A repository of architectural elements with increasing detail and specialization.
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

Architecture Domain

The architectural area being considered. The TOGAF framework has four primary architecture domains: business, data, application, and technology. Other domains may also be considered (e.g., security).
Repository element

Architecture Framework

A conceptual structure used to plan, develop, implement, govern, and sustain an architecture.
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 Landscape

The architectural representation of assets in use, or planned, by the enterprise at particular points in time.
Repository element

Architecture landscapes

The architectural landscape is the architectural representation of architectural concepts that have been deployed within the operational enterprise at a certain point in time. The landscape likely exists at multiple levels of abstraction to meet different architectural objectives.
Repository element

Architecture metamodel

The Architecture metamodel describes the organization-tailored application of an architecture framework, including a metamodel for architecture content and language.
Repository element

Architecture model

A model is a schematic and simplified representation of part of the (architectural) system. It is often developed in modeling languages such as ArchiMate or BABoK.
Repository element

Architecture Model

A representation of a subject of interest.
Repository element

Architecture models based on metamodel

The metamodel of the Architecture models and the resulting architecture products must match the context of the organization. This will often be based on one or more modeling languages. Within these modeling languages, a subset will often be developed for the context of the organization. In addition, it must be worked out how a combination of modeling languages is realized. This forms the basis for the metamodel of the architecture repository.
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 process and products based on Architecture repository

Repository element

Architecture process set up based on repository

The architectural processes are often designed to produce, review and deploy architectural documents. By using an architecture repository, the architecture products will change and therefore the architecture process must also be designed differently.
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

Architecture repository Book

Repository element

Architecture Repository Navigation

Repository element

Architecture requirements

The Architecture requirements and requirements collection provides an overview of all authorized architecture requirements and requirements that have been agreed with the stakeholders within the architecture board.
Repository element

Architecture team

Team that will use the architecture tool in the architecture processes. They are therefore not only stakeholders but also play an important role in the processes.
Repository element

Architecture View

A representation of a system from the perspective of a related set of concerns.
Repository element

Architecture Viewpoint

A specification of the conventions for a particular kind of architecture view.
Repository element

Architecture ViewPoints

Description of the organization's architectural viewpoints. See the architecture viewpoints section in this chapter.
Repository element

Architecture Vision

A succinct description of the Target Architecture that describes its business value and the changes to the enterprise that will result from its successful deployment. It serves as an aspirational vision and a boundary for detailed architecture development.
Repository element

Artifact

An architectural work product that describes an aspect of the architecture.
Repository element

Authorization on functionality and on modeling language

It is possible, preferably, to activate and deactivate functionalities per authorization role. Use should be simple, especially for roles that occasionally use the architecture repository.
Repository element

Baseline architecture

The baseline is an architecture that describes the current architecture of the system. It is often drawn up together with the target architecture, which is the desired architecture. In this way it is possible to gain insight into the differences between the desired and current architecture.
Repository element

Baseline document driven

When introducing an architecture repository, the architecture products will often be published in documents. Documents are characterized by the lack of connections to other documents and the architectural elements described therein. As a result, a joint, reusable and shared architecture description is lacking. This is often a reason to introduce a repository architecture
Repository element

Building block

Statement A building block is a defined and recognizable architectural concept that meets an information provision need. Description A building block is described in this document an abstract concept that has been developed into three concrete specializations: service, ABB and SBB. Within our definitions, building blocks are seen as synonymous with an architectural pattern. The three specializations have a hierarchy. In our model, a service is the highest level of abstraction, within which Architecture building blocks are recognized which are implemented by one or more solutions building blocks. An important characteristic of building blocks is that they can be composed. This composition can be done in two ways:
  • A building block is a composition of building blocks of the same specialization (for example a service is composed of one or more subservices)
  • A building block is served by a composition of one or more building blocks from the underlying layer (for example a service is realized by multiple behavioral elements in an ABB.
  • Composite building blocks are seen as synonymous with an architectural pattern within our definitions.
The composition of the specializations is developed for the specializations of the building blocks. The composition within building blocks can consist of several layers. However, it is desirable that the number of levels of building blocks within a specialization (Service, ABB or SBB ) remains limited. If a catalog becomes too complex due to the number of layers and building blocks, it is better to split a catalog. Features
  • A building block has a defined boundary and is recognizable as a specific architectural concept.
  • A building block is reusable.
  • A building block is loosely coupled.
  • A building block can interact with one or more other building blocks of different types.
  • A building block is part of a catalogue.
    • li>
  • Template for a delivery that meets a combination of requirements and wishes.
  • A building block can consist of other building blocks and therefore becomes a composite building block.< /li>
  • A building block can be part of a composition (composite building block).
  • Building blocks can be recursive and in that case they are composed.
Repository element

Building Block

A (potentially re-usable) component of enterprise capability that can be combined with other building blocks to deliver architectures and solutions.
Repository element

Business Architecture

A representation of holistic, multi-dimensional business views of: capabilities, end-to-end value delivery, information, and organizational structure; and the relationships among these business views and strategies, products, policies, initiatives, and stakeholders.
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

Business Architecture

Repository element

Business Architecture Example

Repository element

Business process

Elaboration of the business and work processes relevant within the architecture. Including a detailed description of the activities carried out therein.
Repository element

Capability Architecture

A highly detailed description of the architectural approach to realize a particular solution or solution aspect.
Repository element

Capability Increment

A discrete portion of a capability architecture that delivers specific value. When all increments have been completed, the capability has been realized.
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

    Communications and Stakeholder Management

    The management of needs of stakeholders of the Enterprise Architecture practice. It also manages the execution of communication between the practice and the stakeholders and the practice and the consumers of its services.
    Repository element

    Configuration tool prior to architectural model

    An architecture tool is often already configured and set up if the (meta) model of the architecture has not yet been determined. The metamodel determines the design of the tool and the functionalities within the tool.
    Repository element

    Configured modeling tool architecture repository

    the introduction of an architecture repository, the associated (modeling) tool will need to be configured and set up so that the modelers can effectively work together on the architecture model and the products.
    Repository element

    Created models can be validated against the associated metamodel

    The metamodel determines the boundaries of an architecture. (Automated) validation of whether a (sub)architecture complies with the metamodel is desirable.
    Repository element

    Current architecture

    Repository element

    Data Architecture

    A description of the structure and interaction of the enterprise’s major types and sources of data, logical data assets, physical data assets, and data management resources.
    Repository element

    Data architecture

    Overview or basic map of the existing or future data objects, datasets and databases within the domain of architecture.
    Repository element

    Data Architecture

    Data architecture of an architecture repository. This is relatively simple in design in this document and only involves a conceptual data model. However, the conceptual data model does provide an overview of relevant concepts within an architecture repository.
    Repository element

    Data architecture Example

    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

    Deduplicate repository

    Duplications can easily occur in the repository, despite the messages generated by the IDEA AddOn. This process describes how to de-duplicate in an architecture repository in which multiple modelers work together.
    Repository element

    Deliverable

    Naming Conventions Usage: Singular noun. For example: Architecture, Roadmap
    Repository element

    Demo Case Solution architecture {project}

    Dit sjabloon is een package en diagram structuur voor een architectuurdocument, bijvoorbeeld een solution - of project start architectuur. Hierbij is in de diagrammen een koppeling gemaakt naar een viewpoint uitwerking zodat modelleurs ondersteuning krijgen bij het uitwerken van het model. Desgewenst kan dit package gekopieerd worden in EA om het projectspecifiek te maken. Vervolgens kan er een document van gegenereerd worden. Maak daarbij gebruik van de IDEA AddOn waarin je in de package helper een zoek en vervang actie kunt uitvoeren
    Repository element

    Deployment architecture repository

    By using an architecture repository, a new architecture approach is introduced that makes the architecture process and the products more efficient. These goals are related to the outcome achieved by the capabilities. Diagram is based on the ArchiMate Motivation extension.
    Repository element

    Describe baseline and target

    What is the baseline (document-oriented architecture) and the target (architecture repository).
    Repository element

    Descriptive architecture

    The descriptive architecture as the name suggests describes the architecture. This is based on the target architecture and the baseline architecture. Within this package you often see an elaboration of the various dimensions of the organization based on subpackages to structure the descriptive architecture according to domain, layers and other organization-specific divisions. In this book a division based on a layer division for the organization
    Repository element

    Determine package structure

    Despite the many navigation and search options available in an architecture repository, a logical layout is a good way to provide modelers and reviewers with structure. Packages are used for this in Sparx Enterprise Architect. The (tree) structure of the packages in a repository is therefore an important part of setting up an architecture repository.
    Repository element

    Determine relevant parts repository

    Determine functionalities, components and modules in the architecture repository relevant to the organization.
    Repository element

    Determine requirements

    Generic and specific requirements when deploying an architecture repository in the organization.
    Repository element

    Determine roles

    Which business roles are involved in the introduction of the architecture repository and its future use in the organization.
    Repository element

    Determine stakeholders

    We have interests and concerns surrounding the use of an architecture repository.
    Repository element

    Determine work processes

    Work processes supported by an architecture repository.
    Repository element

    Development teams

    If architectures are implemented in custom solutions, the developers of these custom solutions will, on the one hand, provide frameworks and guidelines for the architecture and, on the other hand, they will be consumers of the architecture artifacts and implement them in functioning solutions.
    Repository element

    Domain architects

    Domain architects are responsible for the established architecture based on a classification of domains. These can be domains based on domains within the organization or domains within the architectural structuring.
    Repository element

    Domain architecture

    domain architecture describes an aspect or part of the enterprise or reference architecture. Aspects can be layers or aspects, but also domains within the architectural field or the organizational structure.
    Repository element

    Drafting architecture

    Architectures are developed at various levels, where sub-models are selected and combined into an architecture. This can be a project, domain or reference architecture.
    Repository element

    Enterprise architect

    Role ultimately responsible for the overall architecture for the entire organization. So has both a global and an abstract scope on the architecture and the use of the architecture repository.
    Repository element

    Enterprise Architecture

    Highly abstract description of the entire organization from an architectural perspective. Often based on an existing framework.
    Repository element

    Enterprise Architecture

    This is the established architecture of organization. It often includes the elaboration of the baseline architecture and sometimes also of the target architecture. It is important that the classification should be based on a consultation function. Architects use this as a register of the architecture for requirements inventories, but also for consulting the architectural landscapes and the frameworks within the architecture.
    Repository element

    Enterprise Continuum

    A categorization mechanism useful for classifying architecture and solution artifacts, both internal and external to the Architecture Repository, as they evolve from generic Foundation Architectures to Organization-Specific Architectures.
    Repository element

    Escalation to team manager

    The solution architect must offer the solution material to the model manager so that it can be determined what will be part of the baseline architecture. If this occurs after a number of requests to supply the material, it will be escalated to the team manager.
    Repository element

    Example BPMN Checklist

    Short checklist for modeling business process architecture with BPMN
    Repository element

    Example Checklist ArchiMate

    Short checklist for modeling enterprise architecture with ArchiMate
    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

    Gap

    A statement of difference between two states. Used in the context of gap analysis, where the difference between the Baseline and Target Architecture is identified.
    Repository element

    Generic support functions

    Generic functionalities that are often relevant to all stakeholders for the architecture repository,
    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

    Governance log

    The Governance Log provides an overview of architecture governance activities across the enterprise.
    Repository element

    Hierarchy

    With a more extensive enterprise architecture, it is necessary to create a hierarchy to categorize the different architectures. The hierarchy often consists of a number of diagrams that represent the enterprise architecture based on different classifications and navigation paths.
    Repository element

    IDEA AddOn

    The IDEA AddOn is an open source AddOn to support modeling activities within Sparx Enterprise architect. The IDEA AddOn offers functionalities that are missed in the standard functionalities of Sparx Enterprise Architect. Particularly for architectural modeling and aspects of an architecture repository, a number of functionalities are present in this IDEA AddOn.
    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

    Improve proposals

    A list of proposals, in the form of requirements and requirements for the architecture to be drawn up. But also for the metamodel or the modeling conventions of the architectures to be developed.
    Repository element

    Information system architecture

    Description of the aspects of the tooling when working with an architecture repository. On the one hand the required functionalities and on the other hand a list of various available tools.
    Repository element

    Infrastructure architecture

    Elaboration of the existing ICT infrastructure such as servers, operating systems and infrastructural components. Nowadays often equipped on the basis of cloud-based infrastructures.
    Repository element

    Integrality

    Completeness is important to give the various stakeholders a complete picture of the (sub)architecture or the solution. This is only possible by creating explanatory texts for diagrams and the elements in these diagrams.
    Repository element

    Integration architecture Example

    Repository element

    Integration for REST/JSON/XML

    In a modern application landscape, an architecture repository is not separate from other registers. Integration with other registers such as a CMDB based on modern message-oriented integration is desirable.
    Repository element

    Inventory architectural domain

    With project architectures in particular, the inventory of the baseline, impact of the project, the requirements of the various stakeholders and the solution directions to be selected is an important work process.
    Repository element

    Inventory document

    An inventory document describes the aspects that are relevant when mapping a complex architecture, for example the baseline or target architecture. It is part of the analysis and modeling to establish an architecture.
    Repository element

    Joint metamodel

    The architecture repository works with a shared and established metamodel, including the modeling conventions. This prevents dialects and differences in the models within the repository.
    Repository element

    Legislation and compliance

    I regard legislators and compliance institutions as invisible stakeholders. However, they set frameworks for the architectures within the organization. This makes them highly relevant stakeholders. Consider, for example, the GDPR.
    Repository element

    Logical

    An implementation-independent definition of the architecture, often grouping related physical entities according to their purpose and structure.
    Repository element

    Logical application model

    Description of the available or desired application functions within the scope of the architecture. Usually related to the description of the application landscape.
    Repository element

    Logical Application model based on Master data

    Example of a logical architecture model for a registry or MDM module. Provides an example of how you can combine application functions, interfaces and services in ArchiMate to describe the desired requirements. If you look at an architecture repository from the perspective of master data, you can actually use a number of building blocks to describe functionalities, application services and interfaces in a generic way.
    Repository element

    Management

    Management indicates what the goals and drivers are of the organization. The frameworks for architecture arise from this. In addition, management determines the order of the architectural work to be carried out.
    Repository element

    Management (architecture)

    Description of the architecture of the IT management organization, including the processes, roles and events known within it. Often based on an existing framework.
    Repository element

    Management organization

    From an architectural perspective, management organization is important for providing frameworks and guidelines regarding the management of the various artifacts and described in the various architectures.
    Repository element

    Matrices

    This section contains a number of matrices to easily see connections between the different views of the architecture of a repository. These matrices are based on ArchiMate concepts with which the relationships based on ArchiMate elements and connectors are presented in a two-dimensional matrix.
    Repository element

    maturity of the team

    Because working with an architecture repository is based on standardization and reuse, this requires discipline from the modeling team in terms of modeling conventions and collaboration. This is only possible if the team works together and views the repository as a joint product.
    Repository element

    Meta modeler

    When using an architecture repository, it is important to determine what and how the architecture is modeled. To this end, a metamodel is drawn up by this role. This includes the modeling conventions, cross-language conventions and design of the repository.
    Repository element

    Metamodel

    Metamodel consists of a list of various modeling languages relevant to architecture, including a number of submodels and languages. On this basis, the organization can make a selection of the architectural languages and sublanguages relevant to them. In the development of the tools, such a metamodel based on simplified viewpoints in ArchiMate is developed as an example.
    Repository element

    Metamodel

    The metamodel describes the model of the architectures. This is often based on an architectural modeling language such as ArchiMate. These architectural modeling languages have also been developed in a metamodel
    Repository element

    Metamodel

    A model that describes how and with what the architecture will be described in a structured way.
    Repository element

    Metamodeling

    A metamodel is important for an architecture in general and essential for an architecture in a repository. Because the metamodel forms the framework for the architecture, it must be developed and maintained in a work process.
    Repository element

    Model elements have a life cycle and status

    Every element in the repository has a life cycle of creation, use, mutation and archiving, including iterations. Due to the many connections that exist in an architecture repository, every modeler must have insight into the life cycle phase of an entity. To this end, agreements must be drawn up about the use of these elements based on the phase.
    Repository element

    Model manager

    Responsible for the use and deployment of the models in the architecture repository. Has a coordinating and controlling task for all modeling roles involved in the architecture. Monitors the consistency of the architecture repository and provides modellers with information and training on the use of the architecture repository.
    Repository element

    Modelers have agreement on the architecture products and processes

    The architectural process and products are also joint in a joint environment. Therefore, there needs to be agreement on these artifacts within the modeling community. To this end, consultation forms must be set up to obtain and safeguard this agreement.
    Repository element

    Modeling architecture

    Architecture largely consists of drawing up models of the domain in question, often using a standardized (meta) model.
    Repository element

    Modeling Convention

    In addition to the use of a modeling language, additional requirements and definitions are drawn up around the Architecture models and products. They are frameworks for architects who develop different types of architectures.
    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

    Modeller

    Creates models in the architecture repository such as building blocks, solution architectures and base plates etc.
    Repository element

    Monitor architectural model

    Drawing up architectures is usually done by several different stakeholders. In addition, work in architecture is not always project-based. This can cause the architectural model to become inconsistent. Reason to prevent these inconsistencies by monitoring the architectural model in a process.
    Repository element

    Object model Building blocks

    The object model describes the building block concept as defined within the architectural process. Building blocks are communicative concepts between architects themselves and between architecture and the various stakeholders such as developers and administrators. In addition, also internal services and possibly external stakeholders such as suppliers or chain partners. The model consists of a limited set of concepts with mutual relationships. This model has been developed into an ArchiMate business object diagram. The concepts in the objects and definition diagram are then worked out in detail and thus describe the frameworks of the building blocks.
    Repository element

    Objects

    Listing of all objects within the architecture sorted by type and name.
    Repository element

    Objects enterprise architecture

    It is considered a good practice to separate the elements from the diagrams in a large enterprise architecture. It is possible to separate the objects into the different subpackages of the enterprise architecture. It has been decided to do this in the root package of the enterprise architecture. In this example, a division has been made for subpackages per ArchiMate layer and/or element type. Various other layouts are possible. Determine here the classification that works well in the context of your own organization. Sorting the elements by element type in a comprehensive collection also works well for some organizations.
    Repository element

    Optimize architectural processes

    By using an architecture repository, work processes can be centralised, described and automatically supported by the available functionalities.
    Repository element

    Organogram

    Description of the structure of the organization based on business roles and/or actors. Often based on an existing enterprise architecture framework.
    Repository element

    Overview of building blocks

    In many architectures, building blocks are an important part of the introduction of standardization and reuse. Here too, a design in the enterprise architecture in the form of a number of collections of building blocks that an architect can use when developing solutions to ensure that a solution contributes to the path to the target architecture. This package will also have a classification in the form of subpackages and/or the use of diagrams for the building blocks present within the organization. Navigation and overview diagrams will often be used for this. See also the section on applying building blocks within an architecture.
    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

    Physical

    A description of a real-world entity. Physical elements in an Enterprise Architecture may still be considerably abstracted from Solution Architecture, design, or implementation views.
    Repository element

    Physical data model Sparx

    It seems strange to cover the database structure of a Sparx Enterprise Architect repository in a book about repositories. However, working with an architecture repository will also mean that the content must be accessed in a way that is not available in the formats already present in the tooling. That is why we discuss here the tables that contain the most essential data for accessing of the repository contents. Please note that the number of tables in a Sparx Enterprise Architect includes many more tables.
    Repository element

    Place identified entities in package project2production

    The modeler places the diagrams, packages and entities that he/she considers relevant for use as generic entities in the production package. This means that the entities can be used by other modelers in their own solutions and diagrams. This makes the elements part of the baseline architecture.
    Repository element

    Plateau

    Naming Conventions Usage: Noun For example: Baseline, Transition, Target Architecture
    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

    Presence of standard enterprise architecture modeling languages

    The most important architectural modeling languages are configured in the architecture repository so that diagrams can be drawn up within the modeling languages based on the languages and the properties relevant to that language can be set.
    Repository element

    Principle

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

    Principle

    Architecture Principle.
    Repository element

    Privacy

    Specific aspect architecture focused on data privacy where privacy measures are described within the structure of the other domains.
    Repository element

    Project managers

    Changes in the organization are often introduced into the organization on a project-by-project basis. Projects determine the planning and execution of the architecture work and make use of the architecture artifacts. The projects set requirements for the support from architecture and the products to be delivered by the architecture.
    Repository element

    Propagating and degrading architecture

    Parts of specific architectures such as project or domain architectures may have a generic character, making reuse desirable. This means that parts of these project architectures will propagate to a more generic architecture such as a reference architecture or architecture building block. Demotion from generic to specific is also possible.
    Repository element

    Provide 0.9 version to architecture board

    Offering the 0.9 version of the solution architecture/PSA to the architecture board.
    Repository element

    Publication of architectures and architecture documents

    The content of an architecture repository must be made available to the various stakeholders in multiple forms.
    Repository element

    Publication to documents (PDF/DOCX)

    Generation of (part) architectures in the form of documents. Consider project and reference architectures for stakeholders who do not have access to the architecture repository content.
    Repository element

    Publish architecture documents

    Subarchitectures must be able to be delivered in a format that allows stakeholders without access to the repository to easily familiarize themselves with the models. This includes Word and PDF documents that are compiled from the Architecture Repository,
    Repository element

    Publish architecture to HTML

    Partial models are accessed via HTML pages. This makes it possible to use partial models in an attractive format with easy navigation for stakeholders with little knowledge about modeling tools.
    Repository element

    Publishing architecture

    Not every stakeholder can and wants access to the models via complex modeling tools. There is often a need for simple access with an intuitive navigation structure to the (partial) models.
    Repository element

    Qualities

    Standardized non-functional requirements, called qualities, can be developed for the functionalities in an architecture repository.
    Repository element

    Reference architectures

    The Reference Library provides guidelines, templates, patterns, and other forms of reference material that can be used to accelerate the creation of new architectures for the enterprise.
    Repository element

    Requirement

    A statement of need that must be met by a particular architecture or work package.
    Repository element

    Requirements overview

    Overview in the form of a collection of the requirements of the various stakeholders within and outside the organization. Often elaborated on the basis of the motivation extension within ArchiMate. The summary can be done in the form of a list, a matrix or a number of graphical representations of the requirements. See also the elaboration of the solution architecture repository in a previous chapter for a number of examples.
    Repository element

    Requirements target architecture

    A specialization of an inventory within the architecture is drawing up the requirements for the target architecture for the various stakeholders within and outside the organization within which the architecture is drawn up.
    Repository element

    Reuse

    When using architectural documents you often see that partial models are copied. In an architecture repository this is not necessary and use can be made of existing (partial) models in the repository.
    Repository element

    Reuse of (partial) models

    Essential part of the repository, existing sub-models can be used for (project) specific models. This provides an important advantage compared to document-driven architecture.
    Repository element

    Reviewer

    In addition to drawing up architectures, there are also roles that review and approve the architecture artifacts. For example, by testing for quality, feasibility, but also on the application of the modeling conventions and the organizational metamodel.
    Repository element

    Reviewing and validating architectures

    Within architecture repositories, multiple views of an architecture can easily be created. These views can be made specific to different stakeholders in the review process. In addition, there are functionalities available in a repository to support the review process. This makes the review process easier for both the modelers and the reviewers
    Repository element

    Reviewing architecture

    Established architectures must be reviewed by a number of stakeholders for feasibility, content and elaboration of the architecture.
    Repository element

    Roadmap

    An abstracted plan for business or technology change, typically operating across multiple disciplines over multiple years. Normally used in the phrases Technology Roadmap, Architecture Roadmap, etc.
    Repository element

    Roles in team insufficiently assigned

    When working in an architecture repository you see that certain roles are necessary to introduce collaborative working. However, in the context of the organization, this role must be sufficiently embedded in the team.
    Repository element

    Searching

    Especially in large Architecture Repositories, a simple search based on various parameters and combinations is necessary. This also has added value in smaller repositories.
    Repository element

    Sectoral reference architectures

    Sectoral reference architectures have already been drawn up within some sectors, such as the reference architectures within national and international governments (EU). The architectures established within it are a precondition for the architectures within your own organization.
    Repository element

    Security

    Specific aspect architecture focused on data security where security measures are described within the structure of the other domains.
    Repository element

    Segment Architecture

    A detailed, formal description of areas within an enterprise, used at the program or portfolio level to organize and align change activity.
    Repository element

    Select modules and configuration

    Based on the relevant application functions, determine which parts of the tool need to be configured in order to effectively use the tool as an architecture repository.
    Repository element

    Select tool for architecture repository

    The first step in designing a tool as an architecture is which tool or combination of tools are we going to use. In this example, Sparx Enterprise Architect is further developed and explained as a tool.
    Repository element

    Selection of architectural languages

    For the metamodel of the architecture, a number of modeling languages are often chosen in which a metamodel and modeling conventions have already been developed.
    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

    Service-Oriented Architecture

    An architectural style that supports service orientation.
    Repository element

    Set goals

    Update the list of goals to be achieved by introducing working with an Architecture repository.
    Repository element

    Setting up architectural collections and libraries

    An architecture repository needs some form of classification. The form of classification used is different for every organization. To this end, there must be an option to choose a particular format for the repository AND be able to easily change it at a later stage if desired.
    Repository element

    SOA

    Service-Oriented Architecture.
    Repository element

    Solution architect

    Depending on the project and domain classification of the organization, a project or solution architect will be responsible for the architectural development of one or more projects that achieve a conversion from the baseline to the target architecture.
    Repository element

    Solution Architecture

    Solution architecture or project architecture describes a project that introduces a change in the enterprise. This architecture describes (a series of) the changes between the baseline and the target architecture.
    Repository element

    Solution Architecture

    A description of a discrete and focused business operation or activity and how IS/IT supports that operation.
    Repository element

    Solution architecture example

    This template is a package and diagram structure for an architecture document, for example a solution or project start architecture. A link has been made in the diagrams to a viewpoint elaboration so that modelers receive support with the viewpoint diagrams when developing the model. If desired, this package can be copied in EA to make it project specific. A document can then be generated from it. Use the IDEA AddOn in which you can perform a search and replace action in the package helper. This can easily be copied as a starting point for developing a new solution. The detailed example of such a template can be found as a resource in the existing example architecture repository.
    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

    Solution architectures

    These packages develop the solutions that currently implement the change of the organization from the baseline to the target architecture. Depending on the size of the organization, you will find several descriptions of solution architectures here.
    Repository element

    Solution Building Block

    A candidate solution which conforms to the specification of an Architecture Building Block.
    Repository element

    Solution library

    The Solutions Landscape presents an architectural representation of the Projects and SBBs that support the Architectural Landscape and that are planned or implemented by the enterprise. They therefore form the connection between the Baseline and Target architecture.
    Repository element

    Solutions Continuum

    A part of the Enterprise Continuum. A repository of re-usable solutions for future implementation efforts. It contains implementations of the corresponding definitions in the Architecture Continuum.
    Repository element

    Specific ETL to consumers

    special ETL process to transform specific data from the source to the master data. For example, consider an ETL process based on XMI, AMEF or BPMN exchange formats from the architecture repository to the consuming information systems.
    Repository element

    Standardization models and processes

    Models in the architecture repository can (and should) be standardized in the architecture repository. This is done on the basis of an established metamodel. If this metamodel is available in the architecture repository, (automated) validation of architecture models becomes relatively easy.
    Repository element

    Standards

    The Standards Information Base (SIB) establishes the standards that new architectures must meet, which may include generic architectural languages and frameworks, industry standards, selected vendor products and services, or shared services already implemented within the organization.
    Repository element

    Standards Information Base

    A database of standards that can be used to define the particular services and other components of an Organization-Specific Architecture.
    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

    Strategic Architecture

    A summary formal description of the enterprise, providing an organizing framework for operational and change activity, and an executive-level, long-term view for direction setting.
    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

    Supplier

    More and more organizations are opting for standard solutions for the design of the various architectures. In this case, the supplier of these solutions involved is a stakeholder from the perspective of supplying certain solutions and a customer of the architectural artifacts.
    Repository element

    Support architecture collaboration

    Particularly in situations where the different stakeholders do not physically work in the same space, working with collaboration functionalities such as chat and discussion or review functions is desirable. But this can also have added value in other situations.
    Repository element

    Support drawing up architectural models

    Creating models and views is a core functionality of an architecture repository. This should therefore be supported as much as possible with intuitive functionalities.
    Repository element

    Support element details management

    For elements in the architecture repository it is necessary to be able to easily consult and modify details of the elements. In addition, in certain situations it may be desirable to add your own element details to the details of elements.
    Repository element

    Support for approval of work processes

    Architectures are an important input for (ICT) projects and therefore relevant for many stakeholders. Approval of these architectures by, for example, an architecture board or a Lead Architect is therefore necessary.
    Repository element

    Support metamodeling

    Defining metamodels is important when using an architecture repository. On the one hand, this is done by making a selection of standard modeling languages, on the other hand, this can also mean defining your own modeling language.
    Repository element

    Support model exchange

    An Architecture Repository does not stand alone in an application landscape. Data must be exchanged to and from the architecture repository. Model transformation is almost always necessary.
    Repository element

    Support navigation

    Architecture Repositories quickly become extensive (many elements, diagrams and connections). That is why there must be functionalities that make it possible to easily find relevant sub-models. This is relevant for all stakeholders.
    Repository element

    Support reviewing architectures

    Many stakeholders are involved in architectures, these stakeholders must be consulted whether they agree with the elaboration within the architecture. A (standardized) review process is necessary for this.
    Repository element

    Support work processes

    A number of work processes can be defined for drawing up and managing architectures, for example for modeling, reviewing or approving. The repository must adequately support the various processes.
    Repository element

    Target architecture

    The target is an architecture that describes the desired and future architecture of the system. It is often drawn up together with the baseline architecture, which is the desired architecture. In this way it is possible to gain insight into the differences between the desired and current architecture.
    Repository element

    Target Architecture

    The description of a future state of the architecture being developed for an organization.
    Repository element

    Target repository driven

    The aim of architecture when introducing a repository-based architecture is to create an environment where the architecture model and the various architecture products are jointly worked on to address the imperfections of the document-driven architecture. This shared environment is called an architecture repository.
    Repository element

    TargetArchitecture

    Repository element

    Taxonomy of Architecture Views

    The organized collection of all architecture views pertinent to an architecture.
    Repository element

    Team manager

    Team manager of the architecture team or lead architect, manages the team and is the chairman of the architecture board.
    Repository element

    Technology Architecture

    Repository element

    Technology Architecture

    A description of the structure and interaction of the technology services and technology components.
    Repository element

    Technology architecture Example

    Repository element

    To enterprise architecture

    If the project that delivers a solution is completed, the baseline architecture within the enterprise architecture will change, which is the final end result of a solution or project. Therefore, the concepts present in the models of the solution architecture will have to be elaborated in the baseline architecture after delivery. The models must be adapted accordingly to the new situation or the new baseline architecture. This must be carried out in a controlled process step in the architecture process in which the model manager or custion is often involved. This package is therefore a kind of conduit through which the solutions are placed, indicating that they can be integrated with the baseline architecture in the enterprise architecture packages.
    Repository element

    Towards Solution/Enterprise Architecture

    As with the solution architectures, it is possible that sub-models developed in the personal packages become part of a solution architecture or the enterprise architecture. Here too, a folder to realize a controlled architectural process with which sub-architectures are transferred to the architectures with a different (determined) status under the responsibility of the model manager.
    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 Architecture

    A formal description of one state of the architecture at an architecturally significant point in time.
    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

    Use of templates for architectures and architecture documents is possible

    Templates make it possible for modelers to use standardized models, and the amount of work required to draw up models is also reduced, so it is a form of reuse.
    Repository element

    User friendliness and navigation

    This checklist is used to ensure that the models in the repository are easy to find for different stakeholders and that they are given a logical order in the diagrams to get an idea of the solution or the established architectures.
    Repository element

    User organization

    User organization indicates which requirements, wishes and limitations exist regarding the artifacts to be developed within the architecture and the resulting implementations to the target architecture.
    Repository element

    Validate architecture

    Reviewing architecture is mainly about the content of the architecture and in this process it is mainly about handling the metamodel and applying the modeling conventions.
    Repository element

    Versioning of architectures

    Repositories contain various functionalities that enable version management of architecture (components). This makes it easy to visualize the differences in this version
    Repository element

    View

    Architecture View.
    Repository element

    Viewpoint

    Architecture Viewpoint.
    Repository element

    Viewpoint Library

    A collection of the specifications of architecture viewpoints contained in the Reference Library portion of the Architecture Repository.
    Repository element

    Web viewer

    Web architecture interface for retrieving architecture models in a visual representation selection and representation functionality
    Repository element

    Workareas and projects

    Package in which modellers or teams can create their own elaborations of sub-models, or sub-elaborations of a solution. Within these packages, the modelers have a personal package in which they are free to choose their own layout and develop elements and diagrams. Please note: it is important that agreements are made about the reuse of elements that are present. It is often not allowed to reuse elements present in these personal packages, for example in solution architectures and not at all in enterprise architecture models.
    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

    Working under architecture

    Architecture contributes to a more agile and cost-conscious IT. Frameworks are established by the domain architects and passed on to the teams. Solutions are determined in collaboration with the teams...
    Repository element

    WorkPackage

    Naming conventions Usage: Verb in the imperative mood followed by a noun (singular), for example: Describe architecture, Build application
    Repository element

    A web publication platform for an ArchiMate model

    Web based enterprise architect repository for publishing an architecture on the web
    Content WPP-AddIn

    Enterprise Architect as tool for a Data Platform

    Many organisations are investigating the possibilities of Big Data solutions, for example the Dutch and German Electricity Transport System Operator TenneT. Introducing Big Data is new and traditional approaches are of limited use. Think about introducing data-lab functionalities, innovative and agile approaches, new technologies like NoSql or Hadoop. How are you going to support these activities in an organisation as an architect and how can Enterprise Architect support you in adding architectural value. In this session we will discuss a reference architecture for the TenneT Data Platforms, modelling techniques, architectural patterns and agile approaches all supported by the use of Enterprise Architect. You will see examples of big data patterns, solutions and templates based on ArchiMate.
    Content Architectuur

    Enterprise Architect for an Enterprise Architecture

    How to build an enterprise architect based on ArchiMate and Enterprise Architect
    Content Repository

    Enterprise Architect for an Enterprise Architecture handout

    This summary is a presentation of the EA User group conference in Brussels with an overview of how an ArchiMate based repository can be introduced. This gives for example a description of the role of a repository custoduian
    Content Architectuur

    Integrated Data Entity Architecture (IDEA)

    Introductie IDEA
    Content IDEA-AddIn

    Interview with Len Epp about Architecture Repository

    Interview about the Architecture Repository publication.
    Content Repository

    Session recordings of EA Global Summit 2024

    EA Global Summit 2024 with presentation about architecture repositories
    Content Sparx

    Architecture domains

    Description of the various parts or domains of a repository architecture. This is a generic and not complete model, but serves as a starting point for developing the organization-specific domain model. Please note that this own domain model must closely match the design of the organization. Which domains are relevant in the architecture of your own organization. Adjust this list of generic domains to achieve a correct overview . This model is therefore included in the step-by-step plans at an early stage.
    Repository diagram

    Architecture languages and frameworks

    This overview contains an extensive list of possible (partial) modeling languages. Use multiple languages sparingly. Some of ArchiMate is probably necessary. See also the examples in the documentation of modeling languages via the websites that exist around these modeling languages. The Model Wizard within EA is also suitable for further explanation. This is not an exhaustive list and may be developed differently in the context of specific organizations. This diagram provides a detailed description of the most important sub-models and diagram types to provide an idea of the scope and level of detail within the modeling languages.
    Repository diagram

    Baseline and Target architecture

    Model from the baseline architecture (document driven) to the target (repository based) with a list of the required deliverables. This is based on a number of ArchiMate concepts in the implementation and migration modeling layer.
    Repository diagram

    Business object model

    Overview of the business objects relevant when working with an architecture repository. A brief definition is given for each business object in the description.
    Repository diagram

    Business process with an architecture repository

    Work process for a repository-based architecture. This includes a number of general steps, such as developing a metamodel for the architecture. It also contains a number of specific matters such as the design of the tooling. This diagram only includes the business process description. Please note that in the example repository a link has been made with other components in the solution architecture. This includes assigning the business roles for these business processes. These are then developed into a number of more detailed diagrams.
    Repository diagram

    Business roles with an architecture repository

    Description of the roles within an architecture repository approach. This is therefore more detailed than the overview of stakeholders. In this model, the project members or roles will also be selected. A number of generically named roles. Roles do actively participate in the activities for the introduction of the AR. Please note that this is often organization specific in nature. Therefore, feel free to adapt this model to your own context. In this diagram, the roles are related to a number of stakeholders in the model.
    Repository diagram

    Capabilities and goals of a repository

    Around an architecture repository, an organization can define a number of capabilities and goals to determine a starting point for introducing this change in the architecture capability within the organization. This defines a point on the horizon for the target architecture.
    Repository diagram

    Checklist project2production modelmanager

    Checklist with checks that must be taken if you want to determine components within an architecture. This is an important part of the architecture process because, just like architecture documents, (part) architectures have a status. In a repository, a process must be followed for this, just like with document-based architectures.
    Repository diagram

    Conceptual data model

    Conceptual model of relevant data objects based on a Sparx model but made generic with architecture-wide definitions.
    Repository diagram

    Deduplicating

    When working in an architecture repository, validating models is a step in the work process. A duplicate is easily introduced, especially in an architecture repository of some size. Preventing duplicates and deduplicating afterwards in the presence of duplicates is therefore a functionality that is desirable in a modeling tool to support model validation.
    Repository diagram

    Detail business process architecture modeling

    In the detail of the business process for architectural modeling, a number of connections are made clear. Which business objects are relevant to this process (in both reading and writing), which roles are involved in this detailed process.
    Repository diagram

    Detail business process architecture modelling automation

    When developing and managing the architecture in the models and documents, keeping the repository consistent is a challenge within a repository. With a document-driven approach, keeping things consistent is actually impossible. When working with an architecture repository and using tooling, opportunities arise to automate or largely support, especially iterative, tasks. There are important advantages to be gained for architectural teams. It is therefore recommended that careful consideration be given to which activities can be automated and what requirements there are for the modeling team.
    Repository diagram

    Example ABB basic wordprocessing

    Example of an Architecture Building Block starting from the application catalog of building blocks. This provides a recognizable example of office automation and part of it, namely word processing as a service that can be offered to parts of the organization.
    Repository diagram

    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

    Ice cream manufacturing

    For the application landscape Giovanna wants to develop a supporting technology architecture The technology solution is a Cloud based Infrastructure as a Service in Azure It is typical that a Virtual Machine is designed for a windows application and a relational database For a webbased implementation webforms via HTTP is used Create an ArchiMate diagram of this technology architecture
    Repository diagram

    Implementation & Migration advanced

    Create a model for the baseline and target architecture for introducing a standardized application landscape Define one plateau in the middle Give these architecture relevant names Describe how to get from the baseline to the target Create an ArchiMate diagram of this implementation layer
    Repository diagram

    Implementation & Migration basics

    Create a model for the baseline and target architecture for introducing a standardized application landscape Define one plateau in the middle Give these architecture relevant names Describe how to get from the baseline to the target Create an ArchiMate diagram of this implementation layer
    Repository diagram

    Integration viewpoint

    Goal : Providing insight into links between the application and the patterns used from the reference architecture. System integration. Obliged : Only in the case that a link between applications must be established and this does not fit in the previously mentioned application view. An integration view can be realized by copying the chosen integration pattern from the reference architecture and then providing the implementation in application components, interfaces, etc.
    Repository diagram

    Logical application model

    Enumeration and hierarchy of relevant application functions when working with an architecture repository. In other words, necessary functionalities for a tool to be selected for a repository.
    Repository diagram

    Logical application model architecture repository

    This logical application model views the architecture repository as a master data registry and names the relevant application functions and interfaces that are relevant from the master data perspective and therefore also for an architecture repository. Each element is briefly described and provides an idea of which elements are relevant in its own context. Because in the initial situation of introducing an architecture repository, not all concepts will be relevant. However, with further development of working with an architecture repository, the register will increasingly fulfill a master data function in the application landscape of the organization.
    Repository diagram

    Meta modeler role

    The meta modeler plays a role in drawing up a metamodel for architecture, selecting modeling languages and drawing up organization-specific modeling conventions. This role is very important in carrying out a number of activities in the architectural work process. In addition, the meta modeler realizes a number of capabilities that are necessary for modeling in an architecture repository.
    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

    Modelmanager role

    The model manager plays a central role in the operation of an architecture repository. This role is very important in carrying out a number of activities in the architectural work process. In addition, the model manager realizes a number of capabilities that are necessary when introducing and working with a work process based on an architecture repository.
    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

    Navigation example architecture

    Dit navigatiediagram biedt een overzicht van alle architectuur onderdelen voor de introductie van een werkwijze met een architectuur repository.
    Repository diagram

    Objects and definitions

    The building block model consists of the generic entities building block and catalog. These form the basis of a reference architecture. Catalogs are groupings of building blocks within a specific domain. Multiple catalogs will be created that are related to each other and overlap within the visualizations. The advantage of the design of working with catalogs and building blocks is:
    • Registers are created of reusable architectural components aimed at a specific field of work.
    • The use of building blocks brings standardization and encourages reuse of architectural configurations.
    • Building blocks makes the architecture and development process easier.
    • Architectural product catalogs aimed at specific professional fields are being developed. This has a positive influence on the service provided to the rest of the organization.
    The building blocks have three specializations, the definitions of which have been worked out in detail. These descriptions are elaborated in the paragraphs below. If relevant, additional information has been added to this elaboration, such as links to Togaf and examples of the implementation of these architectural concepts The model uses a pragmatic model with regard to the associations between Service and SBB. From ArchiMate perspective, the route from service is via ABB to SBB. This is characterized by the fact that the functional aspect is well embedded in the building block model. When publishing these models, a possibility is sought to generate reports and web pages that do not contain data relevant to the model for non-architecture stakeholders, which may mean that in a number of situations the ABBs do not have to be developed. Applying the direct association between service and SBB in the modeling does not meet the viewpoints.
    Repository diagram

    Overview viewpoint

    Goal : A high-level overview of the project or landscape at level 1. This shows in 1 diagram what the project or concern is about. The details come in the underlying views. Not required : Depending on the complexity and size, this view is necessary in a complex architecture.
    Repository diagram

    Planning viewpoint

    Goal: Providing insight into the things that a project realizes. This view is essential for the PPM process, which aims to gain insight into which project is working on which component of the architecture at which time. Obliged Use the ArchiMate implementation layer for this. This project view is mandatory to indicate which project is working on which application or technology element. For example:
    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

    Repository sections

    A definition of an architecture repository is given within Togaf and in the Sparx Enterprise Architect documentation. These are designated as generic components as relevant to an Architecture Repository. Try to estimate which specific components you think are relevant to your organization. You can remove the others from the diagram for your own context if you wish. In addition, you can expand or detail these components depending on the context and complexity of your own organization.
    Repository diagram

    Requirements

    This is a list of common requirements for an architecture repository. If there are organization-specific requirements, add them to this model. If there are requirements in this overview that are not relevant to the organization, remove them from this diagram.
    Repository diagram

    Stakeholders

    A number of generically named stakeholders. Stakeholders have concerns and requirements for the use of an architecture repository. However, they do not necessarily have to be a participant in the project that introduces the architecture repository. Please note that this is often organization specific in nature. In this model only a number of generic stakeholders are named. Therefore, feel free to adapt this model to your own context so that it corresponds to the stakeholders relevant within your 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

    Step by step plan tool configuration

    A number of activities are relevant when introducing an architecture repository and the associated design of the tool. The activities are described here in a step-by-step plan in an ArchiMate diagram. The order is based on Sparx Enterprise Architect and can be done in a different order if desired.
    Repository diagram

    Technical layer advanced

    For the application landscape Giovanna wants to develop a supporting technology architecture. The technology solution is a Cloud based Infrastructure as a Service in Azure It is typical that a Virtual Machine is designed for a windows application and a relational database. For a webbased implementation webforms via HTTP is used Create an ArchiMate diagram of this technology architecture Extend the model with a legend and coloring and eventually a standardized layout
    Repository diagram

    Technology viewpoint

    Goal: Providing insight into the underlying infrastructure of an application. Mainly use the building blocks from the reference architecture infrastructure. Obliged: The size obviously depends on the infrastructure component of the project and whether it can be sufficiently completed with standard building blocks.
    Repository diagram

    Tools architecture repository

    List of available tools for use as an architecture repository. This is not an exhaustive list of architecture repository tools. Gartner produces a magic quadrant of these tools every year. It is strange that Sparx Enterprise Architect does not appear in these quadrants. For more details, see also https://www.gartner.com/reviews/market/enterprise-architecture-tools . In this document an elaboration has been chosen based on Sparx Enterprise Architect. However, a number of steps and the model elaboration correspond to the elaboration in this document.
    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

    Viewpoint building blocks basic application layer

    Primary concepts In the application layer, the three specializations of the building blocks can be relatively easily related to an ArchiMate element, namely:
    • Service <-> Application_Service
    • ABB <-> Application_Function, as already mentioned, another behavioral element can also be used here
    • SBB <-> Application_Component
    ArchiMate relationships can be defined between the elements:
    • Service <-> ABB: Realization
    • SBB <-> ABB: Assignment
    • xBB <-> xBB: Aggregation
    The last association, aggregation, is particularly important because it allows composite building blocks to be put together. In addition to the associations mentioned, several types of associations can be selected, such as dynamic associations. When developing the views within this viewpoint, you are free to apply these additional associations, provided they are elaborated in the general viewpoints already present. Secondary concepts In addition to the primary elements and associations, two elements and associations are relevant, but not in all architectural domains. These are:
    • Data_Object, for example within the integration architecture, data objects are necessary for describing, for example, reusable message definitions within a building block.
    • Application_Interface, also within the integration architecture, for the implementation of, for example, a web service, this concept is necessary as an additional ArchiMate element within the xBB modeling.
    Repository diagram

    Viewpoint Building blocks technology layer

    Primary concepts In the technical layer, the three specializations of the building blocks can be relatively easily related to an ArchiMate element, namely:
    • Service <-> Technology_Service
    • ABB <-> Technology_Function, as already mentioned, another behavioral element can also be used here
    • SBB <-> System_Software, Node, Network, Device, Path and other technical active structure elements.
    ArchiMate relationships can be defined between the elements:
    • Service <-> ABB: Realization
    • SBB <-> ABB: Assignment
    • xBB <-> xBB: Aggregation
    The last association, aggregation, is particularly important because it allows composite building blocks to be put together. In addition to the associations mentioned, several types of associations can be selected, such as dynamic associations. When developing the views within this viewpoint, you are free to apply these additional associations, provided they are elaborated in the general viewpoints already present. Secondary concepts In addition to the primary elements and associations, elements and associations are relevant, but not in all architectural domains. These are:
    • Technology_Interface, also within the integration architecture, for the implementation of, for example, a web service, this concept is necessary as an additional ArchiMate element within the xBB modeling.
    An introduction of an artefact is only relevant in certain sub-areas (geo). In other cases, a language with more detail will be used, such as UML class diagrams or XSD models. In the latter case, an association is made between the modeling language concepts via a trace.
    Repository diagram

    Aids for an Architecture Repository

    In the previous chapters we discussed the different dimensions of introducing an Architecture Repository. In this chapter we discuss a number of tools that support and simplify the introduction of an architecture repository. We are working on this based on Sparx Enterprise Architect, a modeling tool for various modeling languages. This makes it extremely suitable for setting up Sparx Enterprise Architect as an architecture repository. The elaborations of these tools have all been developed based on Sparx Enterprise Architect.
    Repository package

    Applying architecture building blocks

    Introduction Applying building blocks describes the design and definition of building blocks. Building blocks are introduced to an organization from the perspective of:
    • Reuse.
    • Decoupling
    • Generalization and specialization.
      • < li>Standardization.
    • Interaction between providers and consumers of information provision. concepts (currently applications and infrastructure, but this must also be applicable to business architecture).
    • Specification of costs and revenues.
    • Improve (accelerate) services.
      • li>
    • Information security.
    This document consists of the following parts:
    • Model: describes the definition, characteristics and relationships of the concept building block and the associated specializations
    • ArchiMate viewpoints: development of the viewpoints for the building blocks. These viewpoints are composed of a limited set of ArchiMate elements and associations.
    • Examples of elaboration of the various building blocks within the ArchiMate viewpoints defined above
    • Sparx implementation, how this is done is implemented in Sparx and how it is communicated/published to the various stakeholders.
    Repository package

    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

    Architecture ViewPoints

    Description of the organization's architectural viewpoints. See the architecture viewpoints section in this chapter.
    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

    Data Architecture

    Data architecture of an architecture repository. This is relatively simple in design in this document and only involves a conceptual data model. However, the conceptual data model does provide an overview of relevant concepts within an architecture repository.
    Repository package

    Demo Case Solution architecture {project}

    Dit sjabloon is een package en diagram structuur voor een architectuurdocument, bijvoorbeeld een solution - of project start architectuur. Hierbij is in de diagrammen een koppeling gemaakt naar een viewpoint uitwerking zodat modelleurs ondersteuning krijgen bij het uitwerken van het model. Desgewenst kan dit package gekopieerd worden in EA om het projectspecifiek te maken. Vervolgens kan er een document van gegenereerd worden. Maak daarbij gebruik van de IDEA AddOn waarin je in de package helper een zoek en vervang actie kunt uitvoeren
    Repository package

    Descriptive architecture

    The descriptive architecture as the name suggests describes the architecture. This is based on the target architecture and the baseline architecture. Within this package you often see an elaboration of the various dimensions of the organization based on subpackages to structure the descriptive architecture according to domain, layers and other organization-specific divisions. In this book a division based on a layer division for the organization
    Repository package

    Enterprise Architecture

    This is the established architecture of organization. It often includes the elaboration of the baseline architecture and sometimes also of the target architecture. It is important that the classification should be based on a consultation function. Architects use this as a register of the architecture for requirements inventories, but also for consulting the architectural landscapes and the frameworks within the architecture.
    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

    Hierarchy

    With a more extensive enterprise architecture, it is necessary to create a hierarchy to categorize the different architectures. The hierarchy often consists of a number of diagrams that represent the enterprise architecture based on different classifications and navigation paths.
    Repository package

    Information system architecture

    Description of the aspects of the tooling when working with an architecture repository. On the one hand the required functionalities and on the other hand a list of various available tools.
    Repository package

    Logical Application model based on Master data

    Example of a logical architecture model for a registry or MDM module. Provides an example of how you can combine application functions, interfaces and services in ArchiMate to describe the desired requirements. If you look at an architecture repository from the perspective of master data, you can actually use a number of building blocks to describe functionalities, application services and interfaces in a generic way.
    Repository package

    Matrices

    This section contains a number of matrices to easily see connections between the different views of the architecture of a repository. These matrices are based on ArchiMate concepts with which the relationships based on ArchiMate elements and connectors are presented in a two-dimensional matrix.
    Repository package

    Metamodel

    Metamodel consists of a list of various modeling languages relevant to architecture, including a number of submodels and languages. On this basis, the organization can make a selection of the architectural languages and sublanguages relevant to them. In the development of the tools, such a metamodel based on simplified viewpoints in ArchiMate is developed as an example.
    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

    Object model Building blocks

    The object model describes the building block concept as defined within the architectural process. Building blocks are communicative concepts between architects themselves and between architecture and the various stakeholders such as developers and administrators. In addition, also internal services and possibly external stakeholders such as suppliers or chain partners. The model consists of a limited set of concepts with mutual relationships. This model has been developed into an ArchiMate business object diagram. The concepts in the objects and definition diagram are then worked out in detail and thus describe the frameworks of the building blocks.
    Repository package

    Objects

    Listing of all objects within the architecture sorted by type and name.
    Repository package

    Objects enterprise architecture

    It is considered a good practice to separate the elements from the diagrams in a large enterprise architecture. It is possible to separate the objects into the different subpackages of the enterprise architecture. It has been decided to do this in the root package of the enterprise architecture. In this example, a division has been made for subpackages per ArchiMate layer and/or element type. Various other layouts are possible. Determine here the classification that works well in the context of your own organization. Sorting the elements by element type in a comprehensive collection also works well for some organizations.
    Repository package

    Overview of building blocks

    In many architectures, building blocks are an important part of the introduction of standardization and reuse. Here too, a design in the enterprise architecture in the form of a number of collections of building blocks that an architect can use when developing solutions to ensure that a solution contributes to the path to the target architecture. This package will also have a classification in the form of subpackages and/or the use of diagrams for the building blocks present within the organization. Navigation and overview diagrams will often be used for this. See also the section on applying building blocks within an architecture.
    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

    Physical data model Sparx

    It seems strange to cover the database structure of a Sparx Enterprise Architect repository in a book about repositories. However, working with an architecture repository will also mean that the content must be accessed in a way that is not available in the formats already present in the tooling. That is why we discuss here the tables that contain the most essential data for accessing of the repository contents. Please note that the number of tables in a Sparx Enterprise Architect includes many more tables.
    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

    Requirements overview

    Overview in the form of a collection of the requirements of the various stakeholders within and outside the organization. Often elaborated on the basis of the motivation extension within ArchiMate. The summary can be done in the form of a list, a matrix or a number of graphical representations of the requirements. See also the elaboration of the solution architecture repository in a previous chapter for a number of examples.
    Repository package

    Solution architecture example

    This template is a package and diagram structure for an architecture document, for example a solution or project start architecture. A link has been made in the diagrams to a viewpoint elaboration so that modelers receive support with the viewpoint diagrams when developing the model. If desired, this package can be copied in EA to make it project specific. A document can then be generated from it. Use the IDEA AddOn in which you can perform a search and replace action in the package helper. This can easily be copied as a starting point for developing a new solution. The detailed example of such a template can be found as a resource in the existing example architecture repository.
    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

    Solution architectures

    These packages develop the solutions that currently implement the change of the organization from the baseline to the target architecture. Depending on the size of the organization, you will find several descriptions of solution architectures 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

    To enterprise architecture

    If the project that delivers a solution is completed, the baseline architecture within the enterprise architecture will change, which is the final end result of a solution or project. Therefore, the concepts present in the models of the solution architecture will have to be elaborated in the baseline architecture after delivery. The models must be adapted accordingly to the new situation or the new baseline architecture. This must be carried out in a controlled process step in the architecture process in which the model manager or custion is often involved. This package is therefore a kind of conduit through which the solutions are placed, indicating that they can be integrated with the baseline architecture in the enterprise architecture packages.
    Repository package

    Towards Solution/Enterprise Architecture

    As with the solution architectures, it is possible that sub-models developed in the personal packages become part of a solution architecture or the enterprise architecture. Here too, a folder to realize a controlled architectural process with which sub-architectures are transferred to the architectures with a different (determined) status under the responsibility of the model manager.
    Repository package

    Workareas and projects

    Package in which modellers or teams can create their own elaborations of sub-models, or sub-elaborations of a solution. Within these packages, the modelers have a personal package in which they are free to choose their own layout and develop elements and diagrams. Please note: it is important that agreements are made about the reuse of elements that are present. It is often not allowed to reuse elements present in these personal packages, for example in solution architectures and not at all in enterprise architecture models.
    Repository package

    Links 2 Tags

    Archimate Architecture repository Architectuur Architectuur document Architectuur repository Big data Bpmn Data architectuur Data kwaliteit Data management Data modelleren Database Document Enterprise architect Grafendatabase Idea Image library Intervisie Logisch applicatie model Matrix Mdg Metadata Metamodel Modelleren Releasemanager Repository Sparx enterprise architect Sql Stappenplan Time aware modelleren Tips en tricks Training Videokanaal Viewpoint Webvideo Werkproces Whitepaper Wpp

    Copyright © Interactory Template by ColorLib

    Ingelogd als 1 | NL