in reply to IT decisions are driven by business needs

Figure out the impact of your project, make a risk analysis, then consciously determine which procedures aren't necessary in your project.

On risk -- decompose this into two factors. (1) Probability of an "incident" (inverse of frequency of incident over a period of time) and (2) impact of an incident (usually expressed in dollars). The product of those factors is the expected loss. Risk mitigation steps reduce either probability or impact. Thus, don't spend more on risk mitigation than the benefits gained from the reduction of expected loss.

Overall, nice post, though a bit off topic. I'll try to be more on topic by saying that I think that one nice thing about Perl's strong automated testing culture and tools is that it probably lowers the cost of some basic risk mitigation.

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

  • Comment on Re: IT decisions are driven by business needs

Replies are listed 'Best First'.
Re^2: IT decisions are driven by business needs
by jplindstrom (Monsignor) on Apr 14, 2007 at 10:43 UTC
Re^2: IT decisions are driven by business needs
by dragonchild (Archbishop) on Apr 14, 2007 at 19:56 UTC
    The topicality of this post has to do with how one perceives advice given. I addressed this in the middle of the post. If someone makes a suggestion (like use strict or don't backup your mysql database through a cgi script), it should be taken as a suggestion for an attempt to get to five 9's. If you don't need that level, then you should evaluate the advice in that light.

    There is also a perception that IT doesn't have to be subject to business concerns. Wrong! IT's only usefulness to a business is in how it supports that business. Nothing less and nothing more. It is only as we view IT's basis through the lens of business that we know how much or little is needed.


    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
      If someone makes a suggestion ... it should be taken as a suggestion for an attempt to get to five 9's.

      That's a little extreme, I think. Perhaps its better to say that suggestions have some implied context and one should consider whether that context matches one's own.

      For example, I don't consider use strict part of a five 9's regimen. I think it just has very low cost and high payback in time saved avoiding dumb bugs.

      -xdg

      Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

      "IT's only usefulness to a business is in how it supports that business."

      The usefulness for business lies in the eye of the beholder.

      Because IT structures in some sense separate the business logic from the business implementation via the IT process IT delivers insights beyond the pure usefulness in the day to day work. However usually this is ignored because IT is not a profit center, thus IT has to shut up and let the cash collectors speak.

      Thats way I support the view that some part of the IT should be IT for the ITs sake. The reason for such an approach is called Serendipity.