EA case study: Example of a data product

What is a data product? 

 The concept is still a bit fussy, and we will use the EA case study to create three different examples of data products. For this article, I asked my colleagues Anders Friis & Daniel Hellerstedt for help.

 "A data product is a reusable data asset, built to deliver a trusted dataset, for a specific purpose. It collects data from relevant data sources — including raw data — processes it, ensures data quality, and makes it accessible and understandable to anyone who needs it to meet specific needs."

Examples 

We have previously talked about business events that triggers some process flows.

One of them is related to the need to report information about individuals according to GDPR. Today, this is a manual procedure but with a larger number of actors in our productions, there is a need for automation, thus the hypothesis to use data products. 

Yamdu: General information about an actor.

The second example relates to generic financial KPI’s from APQC. 

  • Cost to perform the process " invoice customer" per invoice processed

  • Personel cost to perform the process " process customer credit" per $1000 reveune

The third example are KPI’s more targeted towards film production budgeting and productivity.

  • Scheduled pages of manuscript per day of filming and size of crew and cast

  • Hours of pre-production, production, and post-production per minute of ready film and budget size

Information sources

The main source systems for crew and actors is Yamdu, but the service doesn't have an API. This platform is also the source of the bulk of the information related to film productions. Instead you can export and import csv-files about productions, schedules, actors, crew etc. 

Yamdu is the second production system we have, and before that, we used StudioBinder. The interface for data product should then be system agnostic, so if we change systems in the future, the interface should be the same.

As we have several sources for personal data, our approach for solving this must take this into consideration. Future expansion should include both Servera that is our CRM-system and Visma that is used for both finance and time reporting. Including Microsoft Office 365, we have four major platforms, plus a huge number of specialized applications for film production. 

What I as a user would like to have as an MVP, is a service that delivers the productions an individual have participated in, and in what roles. E.g. a very simple data product that contains both information about an individual and the data related to the production, thus more than master data. The data product should then be able to be extended to other types of personal information.

The information for productions can have very high confidentially and be very sensitive to individuals. Therefore, security and privacy are very important.

Design considerations

We are using Azure AD & Office365 and have a cloud first strategy, therefore the logical platform for our data products is Microsoft Azure. 

As we need to use batches to retrieve information about individuals from both Yamdu, Visma and Servera, and the individuals not necessarily are present in Azure AD, we need to store the information somewhere else. Same principle goes for other types of information.

The question is if we should go for a master data approach where we have all master data for parties, (customer, actors, crew, suppliers & partners) in one place, production related information somewhere else, and use the data mesh to combine, or use one big datastore for everything.

Information about individuals is present in several business capabilities, e.g. Sales, Finance, HR and Film production, but information about film production is limited to the latter capability. 

This is why my recommendation is to create a solution based on data mesh, even if our sources from the beginning only are in one capability.

When looking at open standards for information modeling and API’s, we select TM Forums models and Open API’s as we are part of Telecom, Media and Entertainment sector.  

Our business processes are mainly based on APQC for broadcasting, with some improvements in sales and production processes to better fit with our business model.

Next, MVP for a data product.

Nobody remembers a coward

I say to my colleagues that I don’t like risks at work.

This  may be a contradiction, as my risk tolerance compared to other persons are much higher.

At home & play, I’m riding difficult horses, been skiing off pist, scuba diving in caves, walking & skiing alone in the mountains,  off- shore sailing,  driving motorcycles and tried parachute jumping.

The owner didn’t want to ride her.

With these personal activities, I try to evaluate the probability and the consequences of something going wrong. A helmet and a safety west will minimize the damages when you fall. Don’t jump into the water if it doesn’t feel good. Follow the tracks if you are alone so somebody could find you etc.

The issues with large IT projects are that a lot of people are ignorant of the risks, and don’t take any actions to either avoid them or mitigate them.

What kind of risk do you dare to take, at work and at play?

Prequel to Dead Horse Theory

Oscar Berg just released a book where he used the dead horse theory in the modern office.

As a horse owner, who has taken away several horses, I can see the similarities with transformation projects.

Horses are big and fragile animals. They cost a lot of money every month and there is a huge effort to maintain them. If you can’t use them for anything, they will be a really expensive puppet for many years to come.

If your horse get an injury or get sick so you can’t ride, then you need to do rehab, but you can’t be sure of a positive outcome. If the injury doesn’t heal, the animal will continue to be in pain, and at some point you as a horse owner need to decide to take the horse away.

You often  invest lots of time in training a new horse, unless you buy a really expensive one, so just switching to a new when you have a problem is not a viable solution in the long term.

With Mimosa, the wild horse, the vets at the equestrian clinique didn’t give her any chances for survival when she got grass-sickness disease. Still, with the proper care, will-power and sheer luck, she survived. Some of our other horse were not so lucky.

The question for the steering group of a transformation program is the same as for the horse owner. Will it survive and give any value back, or should we let it die with our help?

Who are you going to call?

Digital in a physical world

Sometimes, it’s not that easy, for software developers and others in IT, to understand the implications of physical things.

Physical items, need to be manufactured, sold, shipped, sometimes installed and maintained in a very different way from software only products. When you add software to physical items, the level of complexity raise very much.

You also have to manage ownership of the physical products, if you sell them or subscribe them, i.e. renting out them. Then this must be combined with software updates and licenses over the lifetime of the physical products.

This is the complexity telcos had for very very long time, and manufacturing companies need to strive for to solve.

EA Case-study - Expanding your business

Can EA assist you in expanding your business?

The core business for the company in The EA case study have been film production. An idéa is now to grow and diversify into more business models, and as separate companies. The question is which capabilities should go into the new companies, and if we need more of them.

The suggested business models are:

  • Film production

  • Film distribution

  • Provide crew to external productions

  • Rent-out and sell equipment for film production

The challenge is here different legal entities and ownerships, that need to work together.

A summary of all previous articles can be found here: http://disruptivearchitecture.info/blog/2022/5/16/searching-for-oscar