Record of reference change over time

Post Reply
bowenm187
Posts: 1
Joined: 08 Feb 2012, 13:01

Hi

As part of a team that supports many applications across a multinational company I am looking at the viability of using EA tools to document the systems, how they inter-relate and which functional groups they support. Rather than trying to "boil-the-ocean" we have started by looking at a particular project to identify integration options between various systems that support our purchasing function. We are interested in which data objects are stored in which systems and how the data flows.

The problem I am having is how to represent how the system that acts as the record of reference changes over time. For example considering something as simple as the date for start of production of a product. This would initially be defined in our Market planning tools as an expected product launch sometime in the future. This then is taken into the quotation system where the customer defines it more accurately. During product development the date may be revised by the Programme management team.

I am looking for some guidance on how this information could be recorded. We are interested in identified how the specific data objects move from system to system and which one acts as the record of reference at the various points in the product lifecycle.

Regards

Mark
User avatar
jonathan.carter
Posts: 1087
Joined: 04 Feb 2009, 15:44

Hi Mark,

Thanks for your post - your approach to using the tools makes perfect sense.

Let me tackle your last point first.

With our Information and Data Pack (which is part of the core Meta Model in Version 3), we manage Information and Data separately but together and this works well for Data Management activities.
As Version 3 is imminent (and covered in the Information and Data Pack) I will describe how this is captured with that meta model. We capture the the Information that is exchanged between Applications, on the arcs of the Static Application Architectures. Each of these arcs enables us to capture the Information that is being provided by a particular application being moved to another application. In the context of that relationship (Application Provider to Information Representation Relationship), we can specify which Data elements are involved, in the context of that exchange of Information. Here, we can capture which data elements are being used, how they are delivered and what are they being used as - by which I mean that we can understand that, e.g. a Customer ID is being used as an Order Reference. This sort of thing is particularly important when dealing with packaged applications and enables us to uncover any potential for data consistency issues.
We have some Views in the Information and Data Pack that show how data is moved between systems and these will be part of the new Version 3 Essential Viewer.

On your first - and main - question about Systems of Record, we updated the System Of Record field on the Data Object to enable multiple systems to be identified as the SoR. While this may not be ideal from a data management perspective, we have to be able to capture the real world.

Rather than manage plans and change within what we call the Core Meta Model (the Business, Information, Application and Technology elements), we define what we need to do in the Strategy Management part of the EA Support Meta Model and how we are going to make those changes in the Change Management section. Having these here enables us to construct plans and roadmaps covering multiple elements.

To capture the sorts of change / evolution of your data management architecture, we would define Strategic Plans to change the System of Record for a particular Data Object, with the associated systems - including the target dates. We can then relate the Programmes and Projects that will make this happen to the Strategic Plan (with relevant Project start / end dates that might need to be different to the Strategic Plan dates) and we can (if we need to) define any dependent Strategic Plans (e.g. implementing the new target SoR application). These can then be pulled together in a Roadmap, which captures the architecture states at each milestone, e.g. System A is the SoR in state 1 and System B is the SoR in state 2. The Strategic Plans that we have defined are mapped to the arc(s) from state 1 to state 2 to describe how we will move from one state to another.

If we need to understand that System B has superseded System A, we can define this supersession relationship on the Application Providers (or any instance of any class, for that matter) but note that this is about B superseding A in terms of the functionality (in the case of an Application Provider) and is probably not specific enough for talking about Systems of Record. However, having said that we would be interested to know that B has superseded A, especially if A is the SoR for, e.g. Customer data. We would then see (especially in the Views) that perhaps we need to revise our Customer SoR now that System A has been superseded.

I have tried to give you a comprehensive overview of what's available. Let us know if you have any further questions or comments.

Jonathan
Essential Project Team
Post Reply