Hal Merritt writes:
>The chances of a SLA impacting problem does not change
>in the slightest. Now, the potential cost of fixing such
>a problem does increase once 'support' ends. And that
>cost might include both clock time as well as money.
I have a much more nuanced view of "SLA," and I think it's the correct one.
That is, if as you say -- and I agree -- your time to resolution (TTR) goes
up once support ends, then that fact could certainly impact your SLA. As an
aside, TTR is usually bounded by the time it would take for a crash program
to get current software releases.
If you think about a service bureau, outsourcer, or other similar company
providing IT services according to an SLA, it's very common indeed for the
agreement (contract) to include progressively more costly penalties as TTR
drags on. And those penalties tend to follow a curve -- the penalties may
start out "minor" but get really serious as time goes on.
But back to the OP. I think it's impossible for us to estimate business
risk precisely here. Perhaps we can agree on the following about risk:
1. It's non-zero.
2. It jumps some level upon leaving support.
3. It increases over time after leaving support.
4. It increases at an increasing rate over time ("acceleration") after
leaving support.
Also:
5. It would be a very good idea to get something documented in writing,
placed in front of the appropriate people and in the appropriate files.
(This is the "more information=good" principle.)
6. It would be a very good idea to mitigate risk at least to some degree. I
gave the simple example of ordering no charge software releases; that
should be a no-brainer. There are many other examples, and hopefully my
example is not the only one applied.
Now, I don't think any of us could attach numbers to these risk metrics, at
least not without knowing much more information -- and likely way too much
information for a public forum. But one clue that makes me nervous is the
word "revenue," that these are evidently applications which keep revenues
flowing into the city. As I said, those wouldn't be the *first* application
functions where I'd want to go without support. Accounts receivable (AR)
ranks right up there in the pantheon of important business functions.
- - - - -
Timothy Sipples
IBM Consulting Enterprise Software Architect
Specializing in Software Architectures Related to System z
Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific
E-Mail: [EMAIL PROTECTED]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
