In this article, we explain the basics of Enterprise Model maintenance.
Introduction
Enterprise Model (EM) describes the structure and dynamics of the entire corporate ecosystem including business processes, systems and technologies. When linked with a knowledge base and supported by the processes, the model will justify any effort spent on its creation and maintenance as it would address the need of immediate access to critical information needed for critical decision making, problem tracking, learning and other purposes.
EM is stored as a data, not documents. Therefore, it is available for queries and drill-downs. The users of the model may use the model to understand how any intended improvements or changes would impact the people’s roles, systems, processes or technologies.
Like in the Business Analytics area, when the data is kept up to date and is consistent, cohesive and valid, it becomes possible to use automation for producing repeatable reports, charts and dashboards.
When EM is stored in a centralized database it provides many advantages, as the data can be accessed by one or more Enterprise Architecture tools as well as any additional analytics and reporting tools. We have experience with both file-based storage and database storage including Microsoft Azure and Amazon Cloud.
Production of the Model
The model requires a producer, custodian, and the governance:
EM Producer / Modeller
EM can be created by a collective effort of Solution Architects as they work on their solutions. Business Analysis may also contribute. The parties use a modeling language like ArchiMate 3.0 to model the requirements and the architecture. Therefore, the Solution Architect as a modeller is the primary producer of the model. The architects work in their sandboxes until the work is ready to be promoted into the Enterprise Model. The model can be created with specialized tools that collect data from various sources across the organization such as content databases, spreadsheet, corporate media, etc. That data gets validate and imported into the model.
EM Custodian
Once EM is seeded, it is expected to keep evolving. This requires administration and maintenance. EM Custodian’s role could be within Enterprise Architecture or a separate role within Delivery organization. EM custodians own the model, control the access to any critical information and ensure that the model is available, up to date and can serve its purpose.
EM Governance
Building and maintaining of an EM is a collective effort, which involves building a large model while the work is done in a version-controlled environment. This requires EM governance which can be done by a technical committee of Architects and contributors e.g. Architecture Working Group (AWG). AWG is responsible for the rules of the architecture design process and model’s creation, and the group ensure that any significant changes to EM are reviewed prior to becoming fully socialized.
EM governance is responsible for the following:
Model’s structure and general content;
EA tools;
Model’s imports and exports;
Content ownership;
Model content’s quality;
Access rights and authorization for changes and updates;
Engagement rules for Architects and subject matter experts (SME) into model’s creation and maintenance;
Reusable components and patterns;
Conformance to the standards.
Maintenance of the Model
Model maintenance is the responsibility of the model custodian(s), and it includes the following activities:
Version Control;
Imports and Exports;
Mergers and Splits;
Model Publishing;
Archiving;
Model Refactoring;
Element Cataloguing;
Producing templates for output documents;
Automated scripts;
Access control
Version control
Version control allows tracking any changes in the model such that you can compare the versions; you can roll back the changes or recall specific versions for viewing. For example, while working on a model, a certain part of it undergoes a change. Those changes cannot be immediately made available as the work can be incomplete and the model’s integrity can be compromised hence making it unusable. For this, the ‘branch and merge’ techniques are used. Modellers are working on their designs in a sandbox which is a branch-off the base model, which is often called ‘trunk’. Once the design or a part of it has been validated and approved, then the branch must be merged back with the trunk. New versions of the model as well as the versions of changed elements get produced.
Using these techniques requires that the modellers rigorously follow the rules. Those rules are defined as part of the solution architecture workflow.
Imports and Exports
It is possible to import and export models in order to re-use the models. Depending on the tool, various formats can be supported e.g. CSV format (Comma Separated Values). All data objects are identified by unique identifiers so that they could refer to an element or relation in the other models. The data can also be exchanged in an Open Group Exchange file format, which is XML.
Mergers and Splits
Model’s mergers and splits are the results of model maintenance activities. For example, splitting a single model into sub-models may be required when distributing the work among various groups when the overlaps between sub-models could be either low or stable. It can be feasible to organise the work based on the organization’s capability map. For example, one sub-model could address a company’s financial capabilities while the other could be related to the product warehouse. The decisions on model mergers and splits are a subject of the model’s governance.
Model Publishing
Model publishing is a process of making the model available for use by people and tools. For this, the model must be validated, and any discovered issues must be resolved. A change log or change statement can accompany the model being published.
The model can be published for the modellers and for other audiences:
An announcement get published that model has a new version;
Change log has a record that explains the change;
A website / portal complemented with any recurrent reports get re-generated by the scripts that can be run based on either a pre-set schedule or on demand.
Archiving
Archiving a model is important to reduce business continuation risks. When EM resides on the cloud, it is usually a responsibility of the cloud provider to archive any data which resides on their infrastructure.
Model Refactoring
Refactoring is a process of making changes required to resolve model’s structural inefficiencies, ambiguities or various violations e.g. naming conventions. Refactoring does not change the meaning of the concepts and does not affect the solutions; it usually includes such changes a renaming of elements or moving the elements between folders. As many elements of the model can be affected during the process, it is recommended to have “model freeze” time periods and avoid any updates until the refactoring is ether complete or can be safely paused.
Element Cataloguing
EM is an inventory of architecture-defined models and views that reflect all the details of organization’s ecosystem. However, various parties across the organization may want to have their own catalogues that would match the way the work is organized in their departments. For example, a catalogue of products and services can be managed differently if compared with the EM. However, establishing a data exchange channel would help with keeping the model and the catalogue in synch. This may involve extract, transform, load (ETL) tools and/ or scripting.
Producing Templates for Output Documents
Enterprise Architecture tools can export models into various formats including custom templates. For example, based on your model, you can set various properties for the layout of the template: content structure, format, selection of the view, object properties to be included into the output, and white labeling options. The generated output could be viewed, printed, and exported into a variety of formats such as HTML, PDF, Microsoft PowerPoint, and Microsoft Word. Some Enterprise Architecture tools can produce a complete interactive website which contains a model structure, property tables for the model elements, and the views.
Creating Automation Scripts
Model maintenance assumes an extensive use of tools and scripting:
Model validation, version compare, and finding design-specific discrepancies and violations;
Executing queries to acquire data for ad hoc reports;
Automated reporting which can involve various reporting tools typically used in Business Intelligence and Analytics;
Production of auto-generated design documents.
Access control
Different segments of the model may require different permissions, especially when the work is distributed among multiple teams and sensitive information is involved. That can also be a reason to consider a model split. It is model custodian’s role to grant the necessary access permissions based on knowledge of the model’s structure and content.
Learn More…
Comments