Information object intended use

[Lauri Arra]

Hello community! Just wanted to post a question to hear your thoughts on something where I think I know the answer, but the outcome is still bugging me.

How exactly are information objects supposed to be related to Business Applications? Yes, I've read the documentation, but let's walk through a real example:

Let's say we have information object named 'Employee data' and on the SAP HR business app we create the first relationship to this object and note that SAP HR can read, write, create, and delete the data.
Next, we create a digital interface record under SAP HR and relate the information object to that digital interface. We then create a digital integration between this digital interface and Azure Active Directory - the idea being that Azure reads the employee data from SAP HR and creates the user objects.

What happens now? Should I create a relationship from Azure Active Directory and only assign 'read' operation for this relationship? As Azure creates its own user database, should I also create a new Information Object to identify this? Alternatively, should I only have one Information Object for employee data and use relationships to link it to every business application that is interacting with employee data and also every database catalog that is physically storing the data?

[Hendrik-Engler · Accepted solution]

Hi @Lauri Arra,

maybe following helps: An Information Objects represent the logical business information, not its technical implementations; hence you usually do not create multiple Information Objects (IO) describing the same data. Then you can pair this IO set with the Digital Interfaces (define how the IO flows in/out of an application) and the Digital Integrations (define how the data are exchanged between interfaces).

SAP HR ifor example s the system of record (SoR) for your employee data; therefore it should have Create, Read, Update, Delete (CRUD) permissions, so this is correctly filed on the IO mapped to your business application. Now you could define a digital interface for SAP HR which for example supports Read / Write operations and is related to the IO for employee data.

As Azure consumes the data (e.g. to create user accounts) you can also define the IO on the BA level and for example define the Read operation.

You now link both together via a digital integration, defining provider / subscriber BA information along the provider interface on SAP side being used for example and also map the IO here as the data are exhanged.

So overall you are already on the right track.

[Bruno De Graeve]

https://www.servicenow.com/docs/bundle/zurich-application-portfolio-management/page/product/applicat...

[Mathew Hillyard]

Hi @Lauri Arra 

In addition to the technical information given above, a practical example of the use of a Business Application and its related Information Objects is as the foundation for Privacy Management. Indeed this I think currently the only place in IRM where you can build an Entity type based on a predefined filter that returns either Business Applications or Business Processes linked to Information Objects that are in scope for privacy regulations (e.g. GDPR), and as a result you would typically scope privacy assessments to one of these two objects (Business Application or Business Process). Therefore, for a usable data model, there needs to be single source of truth for the type of data these systems store or use, hence a single Information Object represents a type of data item; these are then rolled up into Data Domains and are referred to by each object that uses or contains that type of data - just like a unique location is referenced by all the CIs in the CMDB in that physical place.

I hope this helps!
Mat