Architecture is simple

You start your work to identify what you provide to your customers:

• Products

• One time services

• Reoccuring products

• Reoccurring services

and then your customers:

• Individuals

• Organisations

• Retail

• Agents

With only two boxes from a business model canvas, we now have 4 * 4, i.e. 16 options to manage in our IT-systems. Then add four more customer relationships, four more channels and four revenue stream from a business model canvas. We now have 4 * 4 * 4 * 4 * 4 variants for selling our products, i.e. 1024 variants.

If you then add four different types of partners into the mix, you have 4096 variants to implement as end-to-end-flow in your IT-landscape, and this is just one country.

To resolve this complexity in IT for an existing organisation is a very complex task and requires lots of hard work.

Why a proof of concept?

Do we need to make a proof of concept before we start with something new?

If the concept is simple, like playing fotboll, you could just buy a fotboll and start to play. No worries as the cost is very low. Want to try a new, beer? By a bottle or two before you order a crate.

If you instead daughter want to have your own horse to ride, a proof of concept would be very wise, as the consequences if you fail us much bigger.

The next question is what you want to have proof of, and this need some serious thoughts. If we just get proof of our child can ride, we are not verifying the difficult things. Rinding is easy compared to maintain a horse 365/7/24. Therefore it’s the maintenance over time we need to have proof of before we buy her a pony.

If you have a new business model, it’s wise to try out in a small scale, so the proof of concept also works in the business world.

With IT, you can use a PoC to evaluate if a software package is feasible or not. The challenge here with COTS, like with a horse, is to measure the right things.

My recommendation is to verify the things that are hard to change afterwards and drives cost, as integrations, information model and non-functional requirements as performance, security etc.

But a proof of concept is not enough, you also need to look at the total cost of ownership for your IT system or horse to see if you can afford it.

Does agile work in Olympic Sports?

What happens if we use Olympic sports as example, where you start with the sport when you are young and win an Olympic medal as an adult. Does the agile approach with an MVP work?

It’s rather easy for a child to get a football and start playing. This is a very good example of an MVP. If she have talent and a desire to train, she can play in the championships when she is grown up. Small steps to a gold medal, in an agile way.

If your child want to win a gold medal in sailing, the stakes are a bit higher. The first boat is usually a one person sailing boot that even a child can manage. But the cost for the boat is higher than a football and the kid need additional skills like swimming. Not to forget the need for safe waters and maintenance off season.

If you instead of thinking of buying a horse for your offspring, then you agile approach will fail big. The concept of MVP will not work as the skills to manage a horse when not riding is far more demanding than putting the shoes on a shelf after game. If you don’t have the skills to manage the horse fully, then the health of both the rider and the horse are at stake.

This is why you have to think through the concept of what you need to succeed with a MVP.

A football works fine, a small sailing boot is on the verge of what a young teenager can manage on her own. But to buy a horse to a youngster to ride and to take care of if he or she, or the parents, doesn’t have any prior knowledge about horses is really a bad idea.

If you think that you can succeed with a digital transformation with an MVP, it’s time to re-think. It’s much more complex that taking care of a horse.

Do you need a new target architecture?

As usual my answer would be it depends. To say yes or no to this question I usally look at five different things.

• Changes to your business model

• Changes to your operation model

• From products to services and subscriptions

• Software becomes part of you services

• Regulatory changes

If any of these five business drivers are relevant for you, then you need an updated target architecture on Enterprise level.

Why you needed it? Main benefit is to identify the complexity of the changes when driving a digital transformation.

Question everything?

If you work as a Enterprise Architect, part of your job is to question how things are done today and make analysis of the findings.

But if you question everything, you will get in trouble regardless if your are an employer or contractor.

Don’t try to persuade your company that the world is flat when making a supply chain architecture.

If you question the latest presidential election results in US, the question is more if your analytical skills are tainted or your paid by some one else.

If you think Covid is caused by 5G networks and the vaccine contains microships, your future is probably more in narrative writing then in Enterprise Architecture.

If your client is a firm beliver in conspiracy theories, you don’t have a chance in hell yo make a proper analytic work.

On the other hand, if you question existing vendors and their solutions, this is often part of your job. If you have a new business model, it may be good to evaluate the options. A least to get a better deal from the existing vendor.