A year ago, I wrote about business strategy and Generative AI, and with AI agents, there is another twist to this topic.
Instead of thinking of how you can improve your business model, you should also have a look at the value proposition and customer segments you loose when your customers start using generative AI.
This is something that today is a reality in the film industry and related areas.
We all been using the analogy of city planning when explaining enterprise architecture. What would happen if you instead did city planning without planning, just running agile?
Welcome to the world of model railroading.
This tabletop layout was built on the kitchen table ten years ago, but didn't survive the internal politics. If you build a layout you need to align with all the stakeholders in the family, and even if the table sounded like a good idea in the first place, it was not.
How did this cityplanning start then? Very agile, and the next articles in this series will describe the mindset behind Schrittweise, e.g. step by step.
If you think this is only toys for children, then try to do 100% autonomous operations of several trains and cars on your physical model railroad layout, without accidents.
How do you practice risk management in your daily life?
As a typical Swede, I'm renovating the house during the summer vacation. This year, high up on the roof.
The question we asked ourselves in the spring was about the risks when doing cleaning and painting, and the cost for different alternatives.
When I was much younger, I used ladders to climb up, but they were sold with a previous house twenty years ago.
After breaking my ribs several times, plus a broken back, I concluded that a new ladder wasn't a good option.
Renting a skylift is not that cheap and with the Swedish summer, you can't plan sunny days ahead.
Therefore we settled for a movable scaffolding unit, reaching up 7 m from the ground. Added extra stabilizers, as it's high up when you are standing there.
Feels resonably safe from a risk perspective, don't you agree?
We also have the location of the house and weather conditions to think about.
We are very close to the sea, and some days during the summer, the wind more than 16 m/s.
How will you adjust your risk management approach when it's you who will be working on the highest platform in high winds?
When you are a software developer, writing code is like walking in a maze. With an agile mindset, this is even more true.
As you don't have the perspective from above, you often end up in dead ends. Result, either go back and redo or create a mess with a chainsaw.
In the nightmare projects, it feels like somebody is chasing you with the chainsaw.
The more experienced you are, the more of high-level view you get, anticipating those dead ends before you choose that path.
When you are an experienced Enterprise Architect, you see the whole labyrinth clearly from above, and will be the pathfinder during the transformation.
This article is part of my EA case study.
We need to be better of knowing who is participating in film productions, both cast and crew, with the objective to improve both proposals and planning of productions.
Before we develop some bespoke software in the cloud, we need to do some information modelling.
Don't overwork is a good rule, and three architecture artefacts from IAF would be a good start. They are:
Business term
Information objekt
Data entity
The callsheet includes information of who should be where and when, and is essential for daily work.
Source: https://beverlyboy.com/blog/20-free-call-sheet-templates/
Every business term in the example above here should to be modelled in an information model, before implementing in a database or used in integration. Bear in mind that is is only one variant of a call sheet.
We have decided to use the TM Forum information models as a baseline for our work. Party Management specifications is part of SID, and used in this example to define information objects.
Source: TM Forum Specification Party Management TMF632
A Party is either an Individual or an Organisation. A Party can have zero, one or more PartyRole. A Party can have zero, one or more Contact information. A Contact information could be e-mail, mobile etc.
Using the model, a producer is an Individual, with the PartyRole of a producer, who has a name and a telephone number as Contact Information.
Integration with Yamdu
The production system we use, Yamdu, can export a CSV file with all actors, contact information and information related to physical appearance as well as personal preferences.
Each column in the table is an attribute to the data element actor from an integration perspective.
Some information here are categorized as sensitive PII in GDPR and access must be restricted.
An actor is a PartyRole in the in information model. The actors contact information and the agent can also be modeled using standard model.
The challenge here is that TM Forum doesn't support physical appearance, e.g body height, for individuals, and we have to make extensions to the model and API's.
Azure SQL-server
We have setup an Azure environment, with separate servers for development, test, staging and production.
In the SQL server, we have to define tables, views and joins as usual.
The premise is to start with the basic objects in the model, e.g. Individual, Organisation and PartyRole and create tables.
As an Individual can have several Party roles, we should at least create an additional table with two attributes, PartyRole and Individual.
An Individual can belong to more than one Organization so this relationship creates need for one more table with the attributes of an Individual and an Organization.
Another decision is if we should use a separate table for physical appearance with attributes for each of columns in the CSV-file or if it's better to use value-pairs for these attributes. Pros and cons with both approaches.
Non-functional requirements as performance, security, legal regulations etc will also impact the design of the schema.
Without an understanding of the business terminology and use of information modelling, it's very hard to make av flexible IT-solution within a reasonable time.
When running Agile projects, you can't skip this part, unless you like to redo a lot of work at a later stage.
The fact that one person can belong to several companies is one paper a very small requirement, easily overlooked, but will create a huge impact in both UX- and database design. Not mentioning the massive changes in code, in different modules, if implemented afterwards.
You can leverage AI as a tool, but in the end, this is still design with trade-offs. Often the decisions are based on both business and IT-knowledge.
