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.

[lpruit2]

Greetings @Lauri Arra! Really great question. Looking forward to other people's reply as the Information Portfolio capabilities within Enterprise Architecture is very interesting to me. I was surprised to see how, in my opinion, the Information Objects were designed to be reusable objects that can be associated with multiple other records. 

[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 · Accepted solution]

hello @Lauri Arra Thanks for the question.
When we build the possibility to link Information Objects to Digital Interfaces (DINTF) and Digital Integrations (DINTG), we had the idea that nor the DITNF or DINTG can have a link to an Information Object, if it cannot be derived from the parent Business Application.

Image your HR App. It can have 3 Information objects: Employees, Contractors, Locations. Within that system, all CRUD operations are allowed.
There could be one DINTF that provides read and write access to the Employees and Contractors data. Here we can document that both objects only are intended for read/write(update) access, not for deletion or creation.
We can have two different DINTG: a) ServiceNow requires Employee data. In this scenario you can link the same Info Object to the HR-ServiceNow DINTG and flag it as read-only usagae, and the Contractors could be used within another DINTG where the data is read but also sends updates.
The intent was to document on each level which Info Objects are being used/data exchanged and which CRUD Operations are done.
Does this help ?

[Lauri Arra]

Thank you, it really does help to hear the thought process behind this and big thanks for the data model shared in your other reply! The scope you explained is now very clear and together with @Hendrik-Engler 's confirmation above on the logical vs technical distinction I'm confident I'm not doing anything wrong. The only part which leaves room for some consideration is if the user account data is something we want to track separately (it's logically different than employee data + it warrants attention) and then and only then would a new "User accounts" IO be created where AD/Entra ID is the system of record - never replicate the "Employee data" IO.

Thank you both for the useful replies!