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

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.

Advantage with Privacy

Are there any advantages with privacy?

View the discussions with Rober Willborg and Casimir Artmann.

This episode was recorded at Mindpark in Helsingborg, Sweden

See more episodes from Architecture Corner at https://youtube.com/c/architecturecorner

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.

Microservices Fad or Trend?

When talking to clients and the architecture community the term microservices is gaining traction and attention. So, what are microservices?

“[…] self-contained piece of business functionality with clear interfaces, and may, through its own internal components, implement a layered architecture” (https://en.wikipedia.org/wiki/Microservices)

The definition above is theoretical and leaves the field open for interpretation on how develop an architecture based on microservices. However, this kind of approach is not new if you have been working with IAF (Integrated Architecture Framework).

Many architecture frameworks take a top down approach when creating the architecture. They start with a high level approach and decompose down to the level required to document what the architecture consists of, much like in the figure below.

The main drawbacks of this approach are:

1. It’s not that easy to define and analyse solution alternatives, as thinking is guided and influenced by the hierarchical structure that is being created and the political arena in the company.

2. The structure makes it harder to think out of the box, since each process leads to stow pipes and no room for shared services.

3. The architect is implicitly combining the ‘what’ and the ‘how’ question, because the definition of the structure along with the definition of the requirements. Making it difficult to isolate the service without running into a redundancy issue with multiple services that do the same thing but are separated by the process. For example Purchasing has the service “review claim” and Sales process also has a “review claim” service. Here there is a risk of creating redundant services in a large and complex organisation.

IAF takes a different approach.

• Firstly, we define the services at the level of detail required without explicitly putting them into a hierarchical structure.

• Then we define grouping criteria that are based on the architecture principles.

• After that we create components by grouping the services into components based on the grouping criteria. The figure below visualizes the IAF approach.

OK – Claudio this sound theoretical can you give me a practical example? Sure: read Casimirs blog http://disruptivearchitecture.info/blog/2019/12/16/ea-case-study-top-down-or-bottom-up that describes a hands-on example of the topic discussed above.