Prequel to Dead Horse Theory

Oscar Berg just released a book where he used the dead horse theory in the modern office.

As a horse owner, who has taken away several horses, I can see the similarities with transformation projects.

Horses are big and fragile animals. They cost a lot of money every month and there is a huge effort to maintain them. If you can’t use them for anything, they will be a really expensive puppet for many years to come.

If your horse get an injury or get sick so you can’t ride, then you need to do rehab, but you can’t be sure of a positive outcome. If the injury doesn’t heal, the animal will continue to be in pain, and at some point you as a horse owner need to decide to take the horse away.

You often  invest lots of time in training a new horse, unless you buy a really expensive one, so just switching to a new when you have a problem is not a viable solution in the long term.

With Mimosa, the wild horse, the vets at the equestrian clinique didn’t give her any chances for survival when she got grass-sickness disease. Still, with the proper care, will-power and sheer luck, she survived. Some of our other horse were not so lucky.

The question for the steering group of a transformation program is the same as for the horse owner. Will it survive and give any value back, or should we let it die with our help?

Who are you going to call?

Digital in a physical world

Sometimes, it’s not that easy, for software developers and others in IT, to understand the implications of physical things.

Physical items, need to be manufactured, sold, shipped, sometimes installed and maintained in a very different way from software only products. When you add software to physical items, the level of complexity raise very much.

You also have to manage ownership of the physical products, if you sell them or subscribe them, i.e. renting out them. Then this must be combined with software updates and licenses over the lifetime of the physical products.

This is the complexity telcos had for very very long time, and manufacturing companies need to strive for to solve.

EA Case-study - Expanding your business

Can EA assist you in expanding your business?

The core business for the company in The EA case study have been film production. An idéa is now to grow and diversify into more business models, and as separate companies. The question is which capabilities should go into the new companies, and if we need more of them.

The suggested business models are:

• Film production

• Film distribution

• Provide crew to external productions

• Rent-out and sell equipment for film production

The challenge is here different legal entities and ownerships, that need to work together.

A summary of all previous articles can be found here: http://disruptivearchitecture.info/blog/2022/5/16/searching-for-oscar

Is an MVP the right approach?

I’ve got a excellent idea. Let us build a social network platform where we can connect to our friend. We start with a Minimum Viable Product to our customers.

Twenty-five years ago, this was a good idea, as we didn’t have Facebook. Today the expected functionality from the customers are much higher as they have something to compare with.

The same logic applies if we are to replace an old legacy system. An MVP built for a fraction of the existing business requirements is very difficult to suggest to the organization, as they have to do a lot of things manually.

What you have to do is to replace a seizable part of the existing application, with at least a functionality in pair with the old system.

Too many requirements, requirements, requirements?

Can you have too many requirements in a project? First of all, it depends on the type of project you are running.

Secondly if you have a complex business model, selling products & services direct to customers but also indirect sales, and you have both individuals and organizations as customers, in different geographic area on earth, don’t expect few requirements.

If you use an architecture mindset to manage a large set of requirements, the task is not overwhelming, even if some requirements are very much into detail. Have you ever been involved in tax regulations in multinational companies, you know what I’m talking about.

My way of structuring all requirement is to use the concept of business use-cases as a starting point. I group them into standard business capabilities or standard processes depending on what’s available in the sector, using either TM Forum or APQC.

Next, I use the detailed requirements to define variants of the business use-case to identify the complexity from the business model, e.g. differences for individuals and organizations, different tax rules in US and EU etc.

Finally identify duplicates of the requirements get when you collect the from different sources.

If you have extra time and tools, you can align the other artifacts, as information components, actors etc, in your architecture to the requirements.

Rinse and repeat for next area.