Wednesday, December 4, 2013

7 layer burrito architectures and it's drawbacks

As I talk to different companies, there are places that exhibit what I have dubbed the "7-layer burrito" architecture. Of course, this name comes from the 7-layer burrito that Taco Bell sells.

As a food item, it's delicious. As an infrastructure or software architecture, it's not advantageous for an organization.

A 7-layer burrito architecture is an infrastructure architecture that has added layer upon layer of systems because:

1) There was not time to refactor or refactoring was not done completely.
2) There's a new technology that is "cool", so they must have it.
3) A belief that more layers are better - "bigger is better".

7-layer burrito architectures, of course, does not mean exactly 7-layers. But, if any organization goes to 7-layers, it should rethink what they're doing and focus on minimizing.

Personally, I like simple. The lesser the number of layers:

1) The less time spent maintaining and up keeping of each layer as new versions come out. Including testing, debugging, and fixing integrations.
2) More time is available from the team to work on value-added items.
3) The speed to debug and fix production issues is faster because there are less layers to roll through to find the root cause.
4) The speed to process and deliver information is faster.

If any organization does have a 7-layer burrito architecture, they do need to rethink why it is there and find ways to minimize it. Else, the organization can become bloated and slow down throughput tremendously.

At AcceleWeb, our architectures are simple. We have no more then 3 layers of infrastructure to support our sites, and believe that these days, very few organizations need more then 5. As the number of layers increase beyond 5, the architecture gets derailed by complexities in handling each addiitonal layer.

I would love to hear from others their thoughts.




No comments:

Post a Comment