Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Channels ▼


Op/Ed: Applying Science to the Art of Systems Management

Jake Sorofman is vice president at rPath, a vendor of technology for virtualizing software applications and managing the lifecycle of virtual appliances and application images for cloud and virtualized environments. You can contact Jake at [email protected].

I had a recent conversation with an industry analyst who made a stark observation about the state of enterprise systems management. He suggested that the way enterprises construct and maintain software systems today is far more art than science.

His analogy was useful: "Can you imagine building an airplane without a blueprint?"

I, for one, cannot -- particularly as I write this at 35,000 feet.

But his point was clear: software systems are complex and -- in the world of IT operations -- we leave far too much to chance. We fly blind.

Systems are typically cobbled together based on an unrepeatable trial-and-error approach of "making stuff work." Once systems are deployed, there is no way to consistently know what is running inside -- and what impact changes will have.

So, changes are avoided altogether or made with a trembling hand.

Software updates are rarely welcomed events inside the datacenter because the law of unintended consequences is the prevailing force. But the reality is that change happens -- and it happens more frequently than ever as a result of two key factors:

  • The systems we deploy are more complex than ever -- an interdependent combination of application and infrastructure components that comprise each running system. These components evolve based on their own independent lifecycle, which means that systems are in a constant state of change -- and, often, conflict.
  • Release cycles are rapid and iterative. Agile (and other iterative development processes) makes application development more effective, but it places new burdens on IT operations which is forced to consume change more frequently than ever.

Both of these factors -- system complexity and the rapid pace of change -- are forcing IT operations to the brink. This presents IT leadership with three options:

  1. Throwing people at the problem -- which, of course, is a wholly unpopular option for resource-constrained, cost-conscious companies today. As a result, the old standby solution of increasing IT overhead to deal with complexity is often replaced by
  2. Automation of existing processes -- which is popular both in principle and practice, but it risks lulling IT into a false sense of security in what remains a fundamentally flawed process. The problem is the way we create systems in the first place; without a proper model to represent the system, its bill of materials and its specific dependencies, organizations are flying blind and automation simply causes bad things to happen faster. The better option, of course, is to
  3. Create software systems that are "correct by construction" -- much like complex aircraft are engineered from the start with a deep understanding of parts and interdependency, this approach is about constructing software systems from these same principles. Rather than treating systems as a black box, this approach builds a model that drives the entire lifecycle of the system -- enabling automated deployment and maintenance, taming complexity and putting to rest the law of unintended consequences.

Needless to say, my vote is for option #3.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.