I saw an interesting example the other day of where the world of physical construction (i.e. building a building) and the digital world of enterprise architecture diverge. Normally, we use the physical world as an example when describing the merits of enterprise architecture. We equate EA to city planning, and "building architecture" to applications. This helps us bridge the gap that our business users and some of our technology partners find difficult to cross.
Right next door to my office building, a new sky scraper is going up. We've been watching the demolition, the site prep, and the steel girders being placed with childlike anticipation. You'd think we were 8 years old playing with a giant Erector Set. Well, one part of the new building will have a large ballroom and this has caused an interesting problem for the architect. Imagine a steel skeleton for a tall building with floor upon floor of vertical posts supporting horizontal I-beams upon which the floors and ceilings will rest. Now imagine that you want to remove one of the vertical posts, so that you could construct a larger-than-normal room, such as a auditorium or ballroom.
Of course, you wouldn't remove the vertical posts in that one spot for all floors, you just do it for the one floor that has the ballroom. Therefore the next floor up, would have a vertical post in the location where you had removed it on the floor below. This causes a problem. By removing the vertical post on (let's just say) floor 4, there is no support under the vertical post on floor 5. The architects for the building solved this problem by placing a VERY LARGE, horizontal I-beam; longer, thicker, wider, and stronger under the vertical post that has no support. While this may be difficult to visualize through narrative description, the point is that the architect designed something bigger and stronger in a critical support place to ensure stability of the entire structure.
Our team began comparing and contrasting similar strategies in the digital or application architecture space and found an interesting non-parallel. Often times, a component of an application must support more than its share of the load, such as a controller servlet for example. In these cases, we tend not to create something bigger, longer, or heavier, rather we do the opposite; we create the lightest-weight component we can. In these cases we create code that quickly determines what to do, and then hands off the work as fast as possible. At some abstract level we imagine that both the bigger, badder I-Beam and the tight controller code could be described as distributing load, but superficially it would seem that the solution in the physical world is oppositional to the digital environment.
Can you think of other examples like this?