Distributed in a box (DIB)

Okay so I just made up a new acronym. I am speaking EAI terms today but it also applies to SOA (At least it should or could maybe I don't know). EAI architecture can come in many flavors. Some examples would include fully distributed, hub and spoke, bus, fully centralized or some combination of them all. This mainly has to do with where you place your software components including messaging components, enrichment services, business logic etc. A lot of influence will come from the vendor and how they have architected their platform. Another influence will be the skill set and maturity of the IT organization. Fully distributed is more difficult to manage while fully centralized is easier to manage. Or is it?

One lesson that I have learned the hard way is that a fully centralized architecture can quickly become very difficult to maintain. This is especially true if you experience a lot of early on success and start growing rapidly. What kind of problems you ask? Maintenance including patching, upgrades, code deployments and application co-dependencies where adequate separation of services has not been done (of course distributed can have this problem too).

The concept I'm getting to here is loose coupling. It really becomes very important with large environments with lots of services. This term has been around for a while in the EAI space (and now in the SOA world). It's not only how you distribute your components but how those components relate to and or depend on each other. The more dependency, the more brittle the architecture becomes. Of course in reality this is not always as easy to achieve as folks might think.

There are some contributing factors that can stall a distributed architecture. 1-The cost of the software that you have to deploy. Large environments with lots of endpoints can quickly add up if you are being charge by the processor. 2-The management instrumentation of the software. Was it designed with distributed administration in mind? Do you have to log in to a hundred different endpoints to manage the infrastructure? 3-Ownership of target systems. Yes believe it or not sometimes getting software installed on systems is difficult when you don't own them. Or the software is not considered a core part of the system. 4-And of course your developers ability to architect their solutions in a loosely coupled way. Once again the maturity of your organization can play a big role in that.

There is no clear cut answer to all of this. These decisions will always have to vary by company. I think the more distributed you can become, the more reliable and less brittle you infrastructure will be.

So what is DIB other than something I just made up? It's the concept of distributing your architecture within a centralized server cluster. You get some of the benefits of a centralized architecture while also getting some of the benefits of a distributed architecture. It is by no means a perfect solution but it does help overcome some (but not all) of the inherent problems with a centralized architecture and a fully distributed architecture. And we all know of course that architecture is all about trade offs.