Enterprise Architecture: it's like measuring the coastline

[Capgemini's Integrated Architectural Framework]

I've made the mistake once again: underestimating an enterprise's business and process flow while looking at it from a conceptual or logical point of view, before hitting what we call the physical layer. Call me an idiot please, yes you can

Let me use a few metaphors and make this an easy one to understand. I'll follow the model above

My client sells candy. Red, green and blue. My client can order candy themselves when they run empty, but certain customers (the bigger ones) can also place orders via my client.
Also, candy can be returned. Sometimes something is amiss and then candy gets deposited in stead of ordered. Of course that has to be investigated, so that deposited candy gets shipped to HQ where it's scrutinised as objectively as possible

I've got several of these clients, who want to combine this part of their business. Shipping back and forth candy is a costly business when you handle extremely large volumes, and sometimes candy goes bad, but more likely you'll pay shiploads of inventory when it's on your stock list versus the factory's

So. I started off. Had talks with all clients, business as well as Chief Architects, and I worded and visualised their AS-IS processes and the information flows belonging to that. Needless to say, it's my task to complete the integration architecture needed to do the job - pretty much down to the last penny. Somehow people don't like surprises

Conceptually, it looked boring. Candy in, candy out. Duh. Few clients, a few shippers, a few labs checking "complaint candy" and that was it

Logically, it became a bit of fun. The information flows from the clients took shape, there was some interesting KPI's regarding cut-off times so the same information traveled via different schedules. Some customers even could order square blue candy in stead of the regular ones, and those had special shippers and complaint candy labs as well - wow the picture became quite a bit bigger

Then, I moved from the logical layer to the physical one - and found myself in pain quite soon

I found out that I had talked to only a few parties involved: I hadn't included the shippers and the labs. As it turned out, every client was not only using different shippers and labs, but they were using different shippers and labs for almost every kind of candy too. So, the picture didn't fit on A3 anymore. One information flow of one client ordering red, green and blue candy became 3 delivery interfaces, three pick-up instructions, and worst: three delivery confirmation interfaces, three pick-up confirmation interfaces, etcetera

Of course all the clients used different shippers and labs for their candy, so with every other client, the base interface amount doubled.
I started with 6 logical interfaces.
Those became 18 functional ones. A logical interface is e.g. an order, a functional one is a candy purchase order, a candy delivery order, a candy pick-up order.
Technically, they became even more: There was a purchase order request, a purchase order confirmation, a purchase order acknowledgment, etc.
Physically, a canonical model was involved, so 3 incoming technical interfaces needed to be translated into one canonical one (that's 3), and the canonical one needed to be translated back into at least one, at the most three, outgoing interfaces (that's 3).
End score: 225 interfaces

A great Enterprise Architect told me years ago that Enterprise Architecture is like measuring the coast line: the closer you get, the longer it gets - and the more work, time and money is involved. But also, the better you can estimate the amount of time and money needed to do the job