COPYRIGHT © 2016-2017 by Michael Herman, Toronto Canada. All rights reserved.
In the Linkedin ArchiMate group, Gunther BONNARD recently asked the following question (January 20, 2017 Inauguration Day):
Managing Master Data With ArchiMate
I am looking for an easy way to manage Master Data (Business Objects) with ArchiMate. I was wondering which association to use to link MD with the business capabilities in charge (“accountable”) of the MD and the same problem to link data object that realize the MD with the application (that create the MD). …any ideas?
…with the following additional clarifications:
How can I model that a business object “belongs” to a capability or a data object is under the responsibility of an application component? I have this issue because I need to manage what is the “master” of the data (without using functions) …
For example, I would like to model that:
– the business object Client belong to the business capabilities CRM
– the application SalesForce is the master of the data object Client …
What follows is more of an approach than a definitive answer. Please add your feedback, questions, and comments at the bottom of this article.
- Start by exploring the context of the question …a simple business analysis task. What is the scope of what Gunther is talking about? …key concepts or objects, important relationships, etc.
- Ask clarifying questions.
- Start sketching the context in ArchiMate. “Learn to think in the ArchiMate language” …like learning to think in a second or third language. (Archi makes this easy to do or use a commercial modeling tool.)
- Go beyond the boundaries of the immediate problem to help ensure you understand the broader context. It will make your eventual answer more correct and increase its longevity and utility.
- Are you answering the right question?
- Think of physical or real-life examples. Then create higher-level abstractions.
- Your sketch doesn’t have to be perfect or “correct”. It needs to be what you need it to be to help you think about and answer your question.
- It is the “thought process” that is forced to take place while you are creating your sketch that is the most important activity of the overall process (like whenever you’re forced to write something down on paper or on your device).
Here’s the ArchiMate 2.1 sketch I came up with:
Figure 1. Master Data Management: Ownership and Responsibilities (Sketch 1)
Don’t work on your sketch for “days”; at most an hour or a couple hours. That’s why it’s called a sketch.
My Thought Process
These are the questions and notes that came to mind while I worked on the above sketch:
- Need to maintain clarity between the concepts of Master Data and Master Data Definitions (aka Master Data Management and Master Metadata Management, respectively). Gunther is asking about Master Data in his posting – not Master Data Definitions (even though they are closely related). I should have asked a clarifying question about this to get confirmation.
- Typically, Salesforce applications are not traditional applications built by traditional application and technology roles BUT for this example, we’ll assume they are.
- Salesforce applications are not Software Components. They are configuration artifacts stored in and processed by the Salesforce platform to realize Application Functions (and Application Services) and custom Data Objects.
- Salesforce has a strong underlying concept of Master Metadata Management (even if they don’t use this term). It’s the core of the platform (IMHO).
- Customer is one class of Master Data data. “Customer 123” is a Master Data data instance. Create this sketch using classes of Master Data data – not instances (unless you’re creating a secondary view to show an example of Customer Master Data data instance).
- Business Roles are associated with Business Capabilities
- which in turn aggregate Business Processes
- that access Business Objects
- “ArchiMate 101”
- Revisit the question while you’re creating the sketch: Should Business Capabilities own Master Data? My answer to this question was: No. I think Business Capabilities can be associated with classes of Master Data.
I believe Business Roles (and Business Actors assigned to these roles) should own Master Data. Master Data is created and managed by Business Processes but it is not owned by these Business Processes. I believe this contradicts the definition of (or purpose for) having Master Data. - Classes of Master Data are defined by Master Data Definitions. Sketch these as Technology Artifacts UNLESS you are trying to model a Master Data Management/Master Metadata Management application. If you’re doing the latter, no problem but I don’t think that this is directly related to Gunter’s original question.
- Modeling a Salesforce “Org” as a Software Component is a bit of a stretch but it’s the best choice I could come up with. Salesforce Org’s aren’t software.
- The Business Capabilities and Business Roles you choose (and classes of Master Data) and their interrelationships will be specific to a particular company.
Once you’re happy with your detailed sketch, then you can use ArchiMate derivation to work backwards to create more focused (smaller) views that more specifically illustrate the answer(s) to your question.
If you want to do a full RACI treatment, then consider an approach like the one illustrated in this article: ARMs for Metadata-Driven LOB apps: SharePoint 2013/SharePoint 2016.
Homework: Data Lakes
- What if Customer was an aggregated, virtual Master Data class drawn from multiple applications and data sources both inside and outside your organization? …rather than a single data source or application? How would you represent this in your ArchiMate sketch?
That’s my 2 cents (Canadian). 🙂
Michael Herman (Toronto)
Parallelspace Corporation
mwherman@parallelspace.net
*ArchiMate is a registered trademark of The Open Group.
Hyperonomy Digital Identity Lab™ - hyperonomy.com 