Role of the Repository

1633369525412.jpeg

As architects we use many models and produce/share a lot of artefacts (models, documents, presentations, plans, posters). We collect a lot of references and create many “working files” (such as notes, spreadsheets, outlines, templates). We share with other parties in business, I.T., vendors and advisors.

It is a daunting task to keep all of this stuff straight, to find it when we want it, to ensure that we have the right version. Difficult to make a consistent change across the various mentions of a particular thing, for example: a Business Unit has been renamed - how can we reflect that across all references in all the various models and documents?

We can of course build a library of documents, often a network drive or Sharepoint portal. This may start out well, but often quickly devolves into a large bucket. A better solution is to have electronic document management, where artefacts are stored, indexed, versioned, searchable and sharable with appropriate permissions. This can work well with appropriate discipline. It still suffers from the maintenance problem we mentioned. E.g. Updating things mentioned _inside_ models, presentations and other artefacts consistently.

This is where we need a proper repository. This may do document management too: the key difference is that a repository will manage _objects_. These can be course grained, such as the documents and models mentioned. They can also be fine grained, such as the things of interest inside the documents, models etc. A repository allows having the same object reflected in multiple models, documents, reports, matrices etc. This greatly facilitates impact analysis and maintenance to ensure consistency. It also allows integration of different domains or perspectives. For example, I can mention Business Objects (which derive from a Conceptual Data Model) in a Business Process Model, or a Requirement Specification for a Business Intelligence Dashboard.

To provide this sort of flexibility, the repository should allow customisation of meta models. I.e. we should be able to define: the concepts we are interested in, the relationships that they can have to other concepts, the properties that are important to a concept. Also, how we want to represent the information in various ways including: forms, reports, models, documents, matrices, etc. The repository solution should provides easy import from standard formats as well as APIs for easy integration to other tooling. Global search facilities and a strong security system are valuable too.

Our EVA toolset provides such a repository. The philosophy is that it's easy to capture information from a variety of sources: CSV, XML, Web Forms, Graphical Modelling; store it all semantically regardless of source; use it for analysis; and output in many forms: Query, Lists, Matrices, Visualisations, Graphical Models, etc.

Read more about EVA here.

#enterprisearchitecture #enterprisemodelling #repository #tools