EA case study - From business to IT requirements
The challenge we sometimes have as architects is how to go from a business process to requirements for IT, either for standard software & SaaS or bespoke solutions.
Business processes
This example is based on APQC processes documentation for Broadcast. The activities are relevant for production process within the Capability Production. The number in parenthesis after each activity is a APQC reference number
Shoot material/create content (13210)
Live feed/live air stream (13211)
Label raw content (13212)
Review and log footage (19891)
Record re-takes (19892)
Record second unit/B-roll footage (19893)
Verify technical quality of recordings (19895)
Transfer recordings to post house (19896)
Disassemble sets and lights (19898)
Return props (19899)
Restore location (19900)
Load out production resources (19901)
Transport production resources from location (19902)
Limited set of business activities within Production
Activities creates and use information
Let's take the first activity Shoot material/create content as an example. We record the individual clips on a memory card or disk, but it’s more information captured during the take. There could be separate audio recordings and we need to keep track of scene, shot & take and other information for use in post-production. We often have a script supervisor who take script notes about continuity between shots and other details.
It is still very common on set to use a physical clapperboard and taking script notes manually, so the question is how to improve with IT?
As we can’t develop our own software for camera and sound equipment are we limited to what the vendors offer for solutions. It’s possible with newer sound recorders and high-end cameras to add metadata to the recordings, so they later on can be used in post-production. This metadata should also be used to label raw content and when review and log footage.
If we list these activities and map the to information objects we see that this is a requirement for an number of business activities.
Requirements for IT
So for new equipment and software, manage metadata about reel/scene/shot/take is a requirement or an IS-service in both pre-production, production and post-production. If our technical equipment or applications doesn't support this requirement, the consequence will be more time for manual work and a source of errors
We also create some Logical IS Components to assist us in the work. Based on our architecture principles, if possible these components should be align with standard type of solution for this type of business. E.g. Camera equipment, Sound equipment and Non Linear Editors.
If we look at our technical equipment we regularly use, the Sony FS5 & FS7 cameras doesn’t support metadata. Our default sound recorder Zoom F8 supports metadata for scene/shot & take.
If we use mobile iOS applications MovieSlate8 or Logger can we capture script notes in a format readable by other software. With a utility program for MacOS is it possible to match add metadata from a slate or sound recorder to clips from camera, if we have timecode. (not included in picture)
The cameras, Sony FS5 & FS7 doesn’t have time code by default, but we can record a signal from an external device, thus getting a time code for sync. The Zoom F8 sound recorder have support for time code so there is no issues.
The NLE we use (FCP/X) have support for metadata via iXML
Lessons learned
What is the lesson learned from this rather technical example?
You need to have business knowledge and understand the information created and used in the different business activities.
You have to be able to identify solutions that supports your information needs (to a resonable cost).
You have to look at several types of information needs so that you don’t end up in a dead alley, only supporting a limited set of needs.
Some of the IT-based solutions for film productions are only available on MacOS and/or iOS, which differs very much from other businesses.
When you have a need for develop your own solutions, this is a different architecture story for next article.