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.

Are you in debt?

In the same way we have different types of financial debts, we have different technical debts.

One example is when running an unsupported version of an ERP system on unsupported infrastructure. You can’t just upgrade anymore, as it’s gone to long time since you did it before. This is a more manageable debt to pay, as your only option is to get an new updated ERP-system. E.g. tearing the house down an build a new one instead.

A much worse scenario is when you have a legacy COTS solution, with lots of custom development. A typical example is SAP R/3 where you often made additions that made it very difficult to upgrade to new versions. Here, the complexity of custom code with a COTS solution adds a lot of debt, making it much harder to repay.

The third scenario is when you are in control of you debt, or at least think you are. If you have the source code and developers, then it should be easier to manage the debt. In some ways, yes, in some ways no.

One issue is that you will be forced by the business to maintain the software forever, because you can. The other issue us that you often focus on small changes to support the business, but never have the time or resources for a architectural refactoring. The cost of replacing the old legacy compared to the current running costs is much much higher, making the business move such decisions into the future forever.

What kind of debt does your organisation have?