Reference enterprise architecture checklist

What should a basic reference architecture contain?

AdobeStock_216369782.jpeg

These are the artefacts I use when doing a reference architecture for larger organisation.

  • Business model canvas

  • Capabilities

  • Level 1 and level 2 processes

  • Key business objects

  • Key business metrics

  • Information components / groups

  • Architecture principles

  • Key actors

  • Critical business use-cases

  • Main applications

  • Business critical integrations

  • Main stakeholders

  • High-level organisation chart

  • Constraints

The purpose of the reference architecture is to be a long term guide for development and/or transformation in a business unit or on a higher level. It must fit the future business model and include both business and IT-aspects.

From these part, you can compose a number of views for different purposes and stakeholders.

Mind the gap

When you start a digital transformation you need to mind the gap. This us especially true if your are a traditional manufacturer who sells physical products and you will start to sell services directly to consumers.

Photo: Adobe Stock

Photo: Adobe Stock

There is a huge gap between business models from the past to the future.

This leads to another gap in the core processes when you do new things. You have to work different.

With different ways of working, you probably need new skills, so the organisation needs to learn.

Do you now think that your legacy IT systems are suitable for a new business model, new ways of working and users with new skills?

Mind the gap so you don’t stumble.

Maturity model example

Do you need maturity models to evaluate progress in capabilities and behaviour?

My wife Lotta got a wild horse three months ago and started the basic training with this in mind.

When you buy a ordinary horse, it have aquired a basic set of skills and could be handled by a new owner. On a scale from zero to five, you are on level two or three.

But with a wild horse, never touched by humans before captured, you start on level zero.

If you try to apply methods for traning a breeded horse to a wild horse will you fail. First of all, you have to build trust with the horse by just being near and not touch it.

After three months of daily traing, she was able to sit up an ride.

So the purpose with a maturity model is to understand where to start your ride to progress.

Not that different from digital transformations when you know what you are doing.

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

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.

Production CRUD.png

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

CRUD to IS-Service and LISC.png

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.