We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.
Start a Discussion
SOA
user-pic

Can You Have Too Much Infrastructure Integration?

Vote 0 Votes
As James Staten of Forrester writes on ZDNet, How Much Infrastructure Integration Should You Allow? "There's an old adage that the worst running car in the neighborhood belongs to the auto mechanic." The same is true of IT, he say.  So can you have too much infrastructure integration, and if so, when do you know it's too much?

7 Replies

| Add a Reply
  • I had to read the article, because the question really is about integration of infrastructure or converged infrastructure, and not about integration infrastructure (e.g. ESBs, BPEL engines, etc.).

    I lean toward the standardization side of things, and I believe that most organizations lean in this direction as well, with a small number of server platforms from a single vendor with a standard configuration. It just makes things more manageable, makes better use of your resources. I'd have a hard time believing why the typical business (outside of technology businesses) would see any benefit in continuing down a path of "tinkered" infrastructure. While this may be a clear trend at the core infrastructure level (servers, networks, etc.), it's definitely not the case at a software infrastructure level. We'll see whether the cloud movement impacts that. Going to a PaaS or IaaS provider certainly has the potential to limit choices in this space.

  • Can you have too much of a good thing? Of course you can, ask any parent of a child who hears the ring a ding ding of that summer time ice cream truck. Kids would eat those goodies every day all day, without hesitation. However, just as in the case of having too much sweets, there is a way to think and deal with infrastructure goodies as well.

    In order to determine of there is too much of anything, we need a way of figuring out (framework) whether that thing (infrastructure integration) is needed in the first place. That framework is the Necessity Model. We need to look at infrastructure integration from a perspective of necessary and sufficient characteristics. Necessary characteristics are those things without which you are ‘guaranteed’ to fail. Take, for instance, oxygen. Without it, you will die (fail at living). Sufficient characteristics, on the other hand, are those things, if collectively taken together, can ‘lead’ to, but not necessarily guarantee, success. There is much more to living than just oxygen. Some say you need happiness, money, relationships, etc. The list is pretty long.

    So, when looking at infrastructure integration, we should ask the question, “what characteristics of integrating my infrastructure are necessary (I will fail without them) and sufficient (might lead me to success)?? For those items that are necessary, there can not be “too much of them’ because by definition you need them to succeed. However, for sufficient items, ones that potentially lead to success, to much of them can be excessive, leading to wasteful spending and effective solutions.

    Here is a practical application of necessity and sufficiency. It is necessary to define the data supply chain for an enterprise integration program. Not doing so will cause data impedance mismatches, leading to higher probabilities of data inaccuracies (a failure). On the other hand, adding additional redundant servers beyond those necessary to meet continuity of operational characteristics (e.g., N+1), while sufficiently enabling higher than mandated availability characteristics, is excessive from the necessity standpoint. Thus wasteful and time consuming, leading to operational ineffectiveness.

    So, the next time you are presented with some infrastructure integration goodies, just like the neighbor kid chasing after that ice cream truck, stop and ask the question, “Do I really need this?? For those integration things that are truly necessary, indulge yourself.

  • Not sure where Mr. Staten worked, but where I worked in internal IT departments we didn't have the liberty of tinkering at a large scale. Sure, we hacked around with our own machines from time to time or might have a lab. But all the complexity in a data center is a function of an un-architected/un-engineered approach to infrastructure.

    Now onto the QoD.

    Integration is great. Being able to pull a component off-the-shelf and meld it into your infrastructure is a huge benefit. I think the level of integration and vendor singularity needs to be balanced with openness. Utopia cries for a unified architecture with one vendor running the whole stack. Reality, however, throws heterogeneity in our faces. Vendor A's stuff is going to have to work with Vendor B's stuff. Ironically, I think products that boast openness are more attractive to customers. They don't feel locked in and "owned" by a vendor.

    The openness story permeates all domains of enterprise architecture. Not only does an infrastructure benefit from it but also applications. At my company we use Beehive for collaboration. Its an integrated stack for email, IM, and ECM. But because of its use of open standards, I have Windows, Mac, iPad, and Android platforms all able to access my Beehive assets. I'm compliant to corporate standards, yet I have some freedom to vary my experience. I think that is what customers want. And in some cases they will need it based on business demands (and not the trivial example I provide).

    Regardless of the vertical domain I think there will be a mix of vendors in the data center at all levels of the architecture. That is where openness needs to prevail. One of the key tenets of the Internet are open standards. There is no reason not to take advantage of the Internet philosophy in the data center.

  • To me this goes back to the centuries old adage "Too much of a good thing".

    So yes, there could be a point of "too much infrastructure integration" might actually be detrimental to business objectives (meeting SLAs, for example).

    BTW, I see "Integration" and "Standardization" as different topics. You can absolutely have one without the other.

  • One may have too much integration in general, but in this specific case the "infrastructure integration" is worth and welcome.

    The principle behind is modularisation and standardisation of the data centre infrastructure in the context of the increasing adoption of Virtualisation and Cloud Computing.
    The Virtualisation abstracts the operation of infrastructure from a user point of view making possible abstract computing platforms of any size, while the Cloud providers take these large platforms and assemble them in powerful computing centers offering easy to interconnect and manage Cloud infrastructure services.

    There must be created though standards for cross-vendor interconnection of computing blocks.

    An example of "infrastructure integration" is the "data center in a container" recently announced. I would call it the Data Centre Appliance.

  • It depends on HOW the integration is performed. As the author points out, wanton tinkering and experimentation satisfies creative urges but does not a good business strategy make. Left uninhibited, this style of integration produces rat nests that ensnare IT organizations and cripple business.

    Done intelligently, though, integration can catalyze quantum leaps in innovation and advancement. Borrowing from Todd, Eric, and Adrian, openness and standardization are key. Eric suggests adopting the "Internet philosophy." Spot on -- it is the embodiment of infrastructure integration. Can you have too much of the Internet?

  • I've been out of pocket for quite some time but I couldn't resist replying here...

    I have a quick answer.. Yes... without a strategy and governance, you can easily have too much infrastructure integration without consistency and control.. you get the proverbial tangled web of integration that's difficult to manage, leverage, and maintain.

Add a Reply

Recently Commented On

Monthly Archives

Blogs

ADVERTISEMENT