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?

Searching for Oscar

What is happening to the film production business described in the EA case study?

Even the best plans could be delayed, so the first theatrical premiere is scheduled to August- September this year.

Covid had a huge negative impact on the market last two years, so we are not yet on track from a business growth perspective, therefore the plans need to be updated.

The list of all articles below

1. Enterprise architecture case study

2. Motivation and business opportunity

3. Business model canvas

4. Benefits with EA for a startup

5. Business context

6. When frameworks meets reality

7. Production of film, video and TV

8. Business activities and roles

9. Information architecture

10. Sales process remake

11. Impact from GDPR

12. Finally an IT project

13. Size matters, but …

14. GDPR risk exposure

15. Project portfolio

16. Agile, but not agile

17. Architecture, or not?

18. Tell me a secret

19. Scenarios for infrastructure

20. Top-down or bottom-up?

21. From business to IT-requirements

22. End of life

23. Product portfolio update

24. Two and a half years later

See you at the red carpet.