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.

Boardroom EA

I’m a board member in a local utility company so the question is if EA is relevant for me in this position? 

I would say no, as we talk about business plans, investments, risks, financial results and other KPI.

However, all these things are of utterly importance for those persons in the organisation doing EA related work, regardless of their title.

Why are you working with EA?

What is the main reason for you to work with Enterprise Architecture? 

Are you more into theory and your thing is how to describe models and improve architecture thinking? You are in good company.

Or are you more like me? I see EA as a valuable toolbox to solve business and IT problems, and with a better method I’m more productive.

Third option I can think of. You have a position as Enterprise Architect and you get more glory and rewards than your previous position. 

If you think of more drivers, please comment bellow.