Welcome to our blog. This is an archived post, most of our knowledge and advice remain valid but some material or links may be outdated. Click here to see our most recent posts.
This is the eight blogpost in the Data Management series. We have covered many capabilities that are associated with Data Management, ranging from Governance and Stewardship to Business Intelligence. In each posting we briefly touched upon the modeling aspects using ArchiMate. Here we tie these together and cover a “way of modeling” based on ArchiMate, but leveraging BiZZdesign Architect’s strong visualization capabilities to make diagrams that are appealing to a wide range of stakeholders.
From a modeling perspective, the challenge is to create enterprise-wide, integrated models that link between
The roles, processes and means from the field of Data Management that support the business
In a manner that is (visually) appealing and understandable for a wide range of stakeholders.
ArchiMate as a modeling language is well suited for the modeling task. The default notation, however, can be tuned to improve communications. One of the major advantages of using a language with formal semantics lies in its analysis capabilities: concepts and relations have a formal meaning making it easier to precisely express different aspect of the enterprise. This contrasts with e.g. PowerPoint or Visio-like models where we often see that models are “vaguely the same but precisely different”.
Concepts and relations
We have chosen a simple approach where we have mapped the topics of this blogpost series on ArchiMate as a language and updated its graphics for communication purposes. We summarize our findings here:
Governance: Integral, enterprise wide governance is key to success and the role of the data steward is crucial: s/he is responsible for data quality in a specific subject area. Data stewards co-ordinate their work in a data council which is jointly responsible for the information landscape. Here we see a data council (which is modeled with a BusinessCollaboration) with several Data Stewards (BusinessRole). Each Steward is responsible for one or more information areas (BusinessObject)
Information versus data: Several Entities are pertinent in the context of a Subject Area and several systems may manage Data Objects that realize (part of) the information that is pertinent to these Entities. Here we see a decomposition of the Customer information area into its Entities (BusinessObject). We also see their actual manifestation in the IT space: the Data Objects (DataObject) that realizes these Entities as well as the systems (ApplicationComponent) that manage them.
Mastering key Entities: Having a single “360 degree” view of key Entities is often seen as a critical factor for business success. This is the space of MDM: Master Data Management. We want to see how (Field of) Data Objects are used to form this golden record. Here we see three Data Objects with their Fields (also modeled as a DataObject) that form the basis for a golden record.
In practice you often will want to model the actual application functions that modify data to form the golden record. This is straight forward in ArchiMate. Here we chose to modify the AggregationRelation to denote the data transformation at the level of the Data Objects. The same approach can be used at the Field-level.
Business Intelligence (BI): The field of BI is special in the sense that many organizations depend on their data warehouse (EDW) for advanced analytics that drives the business. Getting to grips with lineage of data, the sources that feed into these reports etc. is a challenge. Given the importance of intelligence, we updated the notation of BI-related systems (ApplicationComponent) and BI-related data / reports (DataObject) as follows:
Meta Data: Meta data is what ties everything together. Keeping track of business meta data (stewardship, processes where information is used, required qualityetc.) and technical meta data (table structures, last modification dates etc.) is a daunting task. In ArchiMate as a language and BiZZdesign Architect as a tool, meta-data is modeled in various ways including:
Objects and relations (see e.g. the way we model Stewardship in this blogpost)
Documentation of objects and relations
Properties of objects
Visualization it then boils down to something like this:
Here we see an Entity and its manifestations in DataObjects (including golden record) as well as the requirements associated with this Entity and related business functions.
Switching between visualizations
To top it all off, we end this post with an illustration of what it means to “switch between visualizations”. Below is a diagram with the notation as proposed in this blog:
When this view is translated to standard ArchiMate (which is a trivial matter in most tooling), the result is:
This posting wraps up the DM-series. If you have any suggestions or questions, feel free to contact us or leave a comment. We are very enthusiastic about this approach, and hope to hear your feedback!
SUBSCRIBE TO BIZZDESIGN'S BLOG
Join 10.000+ others! Get BiZZdesign's latest articles straight to your inbox. Enter your email address below: