Back to code again

I need a small application to support film production, but the barrier (effort) to write code have been to high. What I will try now if I can use AI for fast development, as I have a documented UI, API and a database schema with test data.

The solution architecture was tricky, but with this design, I assume the coding will be ”easier” than in the 90’s.

Business need

I need a better way to find out who has been participating in each film production, i.e. project, both in front of the camera and behind. In Film production, both the cast and crew are managed in Yamdu, but in separate modules. Then there are projects not in Yamdu, where we have crew and pay wages, e.g. Provide crew & equipment.

There are two reasons for this epic, better CV matching and answers to GDPR requests.

High-level design

The solution should manage a list of projects imported from Finance system, Role descriptions from the CRM system, cast and crew from Yamdu, plus manually entered Individuals with roles in projects.

The SQL database will be in Azure, and the schema will be based on TM Forum SID and their Open API specifications. Access control via Azure Entra and two factor authentication as this data includes PII.

I've created a draft UX for mobile, so this will the basis for a small web application, accessing the database.

.net as development framework, with an aim to use only open source products in the future.

Solution approach

Use of Copilot to set up environment and Claude assist in coding.

First PoC is without integrations, to verify. Then integrations to all internal systems via CSV-files.

My background in software development was more than 25 years ago, and then in Java, C, Fortran, Pascal and script-languages, with Oracle RDBMS (UNIX) and MS SQL-server (Windows).

Enterprise Architecture playground

Architects working together could sometimes be compared to small children in the playground. Totall chaos and one boy is grabbing the others childrens cars.

Still, if you are a grown up enterprise architect, you still need a playground or sandbox to learn and try out new things.

Very few enterprise architects are developers in their daily life, so the question is how you can experiment with new things outside development tools?

For me, my EA playground is my film production hobby, and the EA Case study a way to try out ways of working and new tools

Many of you are very focused on frameworks and tools, so I will now update the architecture documentation using new tools. The reason to this is a new legal entity in film production that have impact on the existing EA views.

Provide crew and film production is now one legal entity and film distribution is another entity.

I will use  a sandbox version of LeanIX to model the film production and film distribution business, to learn what you can do with the tools today.

What is your playground for Enterprise Architecture?

A physical sandbox

The last article about agile city planning was the joy of agile.

Now, we are in R&D mode, trying to learn how to create custom made platforms for the shadow station and the branch-line.

As this is something completely new for me, I've created a small diorama for experiments, e.g. a sandbox environment where I can learn, without messing up the larger layout.

This is the same reason, why you need a sandbox environment when doing something new with IT. A safe place to try and learn without messing up the large systems.

You can try new concepts within a limited cost, and scrap if it doesn’t work.

The same principle applies regardless it’s for creating contract tracks for feedback or doing an event based integration. If you haven’t done it before, you need a learning environment.

Information governance, why now?

A colleague asked me why information governance is more on everyone's mind now, compared to before. From my point of view, there are three reasons for this, but I would like to give some background information first.

When I begin my career as a programmer the mid 80's, I quickly learned the concept of garbage in, garbage out. Fast forward to the early 2000 when I begun using IAF v3, and modelling the information aspect in architecture. We already then talked about quality attributes for information and information ownership, but these topics were not prioritized.

Digitalization is the first main reason for increased need for information governance. With less people, and more integrations between systems, flaws in data quality will have more impact now, than when humans fixed the errors.

The second reason is regulations. More and more regulations are addressing data quality issues, from GDPR to DORA and everything related to cybersecurity.

Third, ever heard of AI? Without data quality, you are lucky if you get garbage out from your newfangled AI-solution, as it could get even worse, fast.

Here is the catch-22, try to do information governance without a proper information architecture? You appoint persons in your organization to have information ownership, without defining what this is. What you get is still garbage in, garbage out.

Learning from failures

If you work with EA, you could do a stellar job and but a strategy or transformation program would fail regardless of your effort. As an EA you don't walk alone, you work with teams in an organization. This role is not a one man/woman show.

Done more than 100 different assignments as an Enterprise Architect since 1998. Some shorter and some of them longer.

I have only a few really successful examples, but more grand failures. Mostly positive results when I have recommended stakeholders to close down large programs, or done due diligence to keep them confident to continue.

Learning from the failures is part of life as an architect. As a consultant, you often get those assignments nobody else would take, making it even harder to succed.

I often have a role as an external advisor, to give recommendations, and say what would go wrong if they don't follow my advice. If they neglect the advices, and the program fails, is this an EA failure or not?

If you don't have direct access to major stakeholders, CxO level or Business units in global organizations, then it's a bad sign from the start. Another mission impossible scenario is when all stakeholders have very different priorities.

Not invented here is another syndrome, especially when comming from the outside. A bad situation, becomming even worse if the chief architect is utterly incompetent.

In large transformation programs, failures are mostly related to the classic triangle of love. Budget, time and quality. As lead architect, you can recommend to close down, or help the program manager with prioritization and hopefully have the stakeholders to improve the pre-conditions.

If you want to do a career as an Enterprise Architect, expect huge challenges in your profession, and falling flat on the ground at regular intervals. If not your cup of tea, don't jump into the saddle.

Same when riding horses. You need to understand why you fall off, and learn from that.

Happy New Year to all of you.