Okay, I made up “modularizing”, but I think it nicely fits the idea of this article.

I am a huge fan of the concept of abstracting functions — i.e. clearly defining what it is you are trying to accomplish with your various bits of software & hardware, defining clear categories for their functionalities, separating them, either physically or logically, and ensuring that everything communicates via clearly defined, standards-compliant interfaces and APIs.

During several early projects of mine, I noticed that the temptation was strong for managers to create all-in-one tools in order to sell the widest package of application functionality conceivable.  This is bad design, if only because different uses and scenarios can have different requirements; addressing these may have unintended network effects on other components of a product, thereby slowing down the whole analysis, development and QA process.

One of my clients has taken the path of a pluggable, modular configuration tool for some of their systems; this is a good model insofar as it allows clear access to different components from a single interface, but the components themselves are not interdependent.

For the purposes of this article, I’d consider using very basic distinguishing criteria like “network / communications device”, “end-user application”, “remote support tool”, whatnot — and in the scope of this article, “security device” and “other.”  I realize that these are fairly theoretical, academic distinctions, but it’s my firm belief that the idea applies in real life. Such a matrix can be multidimensional — criteria could include, on the one hand, what the application is used for, and on the other, how it is deployed or managed, OS type, manufacturer, etc.

For example, one of my projects involved the development of a small network security appliance for a specialized scenario (protecting proprietary devices subject to strong regulatory requirements.)  There was constant pressure from sales & marketing to avoid having multiple physical boxes; the field service types also wanted to prevent having to maintain additional distinct hardware.  This was a good example of when it was right to not listen to our customer and push them to accept the idea of having another little small piece of hardware; integrating the security into pre-existing products would have required a huge amount of adaptation, porting, maintenance, testing and other effort, over multiple architectures, teams, countries, whatnot.

“Security” is a compelling argument for the separation of protective functions from what’s being guarded; there may not be a clear, identifiable exploit that you are addressing, but, using the example of network defense, knowing that your authentication, detection, encryption and filtering tools are autonomous from each other reduces the possibility of single points of failure.  I’m not arguing for an eggshell model of security (crunchy on the outside, squishy on the inside), but it makes things much easier to be able to address an application server’s security requirements without the need to assume that whatever security you implement on an application level is all you will have.

An even more significant reason to keep things separate (physically, via dedicated, standards-compliant hardware, or virtually, via VMs) is cost reduction — support and development are simplified.  Despite the appearance of increased complexity from more components, if you are able to quickly and easily swap out a defective element, or create added functionality whose impact on an unrelated system is controlled through a standardized network interface or code API, you no longer have to worry about breaking things that should be out of scope for whatever it is you’re doing at the moment.