Good old days

Is software development different today, compared to the good old days?

Today, you often have three main scenarios when starting major programs.

1. Build on what you have

2. Buy something new, COTS and/or SaaS

3. Build something new from scratch

Build on what you usually works well, until there are major changes to your business model, or the technical debt becomes too huge.

For many years, I've seen option two and option three fail miserably. We have our own share of them in Sweden, most recent one being Millienum health care system that was cancelled by two different regions. [edit] Classic waterfall project where the politicians stepped in and closed.

But I've also seen a number of programs developing subscription billing systems going down the drain. The question is why, because they were running agile, not waterfall development style.

Back to late 80's when I got the task to implement a material production system at a manufacturing site, replacing paper. No existing IT-systems, no COTS and cloud computing was somebody’s else mainframe.

The first thing I had to do was to collect a hard hat and safety shoes, so I could go out in the factory and see what really happened in real life. As a manger, I both did a budget and motivate the investment, as well as installing the minicomputers running VAX/VMS and plan a local fibre network.

The requirement work we did was very process oriented, starting with identifying how the people worked at every station in the factories. Then designing a SQL-database and UX for terminals to support the workflow. Used consultants to write most of the code, but we wrote interface code for API communication in C and embedded SQL. It even worked in year 2000, avoiding the millennium bug.

Fast forward until today.

A fair share of the software developers I met recent years have no clue about the business and how things are done. They often don't care about budgets or the cost of development and maintenance. They are highly specialized on a few tools and frameworks, and often competent in their area.

But the problems with major programs starts, but not ends, with requirements.

Lack of requirements, or incomplete requirements. If you starting a new digital business from scratch, and doesn't need to be profitable the first ten years, the your can run agile. If you have an existing business, and try to replace you legacy systems, the skateboard to car analogy doesn't work. Period.

Garbage in - garbage out is next. Information models more or less non-existent in today’s agile world. Very few software developers have the skill or the mandate to a proper information model. The consequences are delays, building up technical debt and lack of data quality.

Today's computers are fast, and this also makes non-functional requirements a forgotten topic. Lack of those will result in bad data quality, technical debt and problems with compliance to regulations.

Finally a word about stakeholder commitments. There are often to many layers between the guy or girl who present the budget to the guy who writes code, or the person who will use the system. Neither is anybody accountable for the whole.

Back in the good old days, we could have the whole team around a large table in the lunchroom, sipping coffee and smoking cigarettes, and I was accountable.

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.