OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

pki-lowercosts message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [pki-lowercosts] Action items


I don't think we should go through the
extensive effort involved in developing an
elaborate cost model and spreadsheet. I think
a simpler analysis based on five or ten interviews
would probably suffice for our purposes.
And I'd like to shepherd our resources carefully
to make sure we can accomplish our goals.

Why do I think a simpler cost analysis would
be sufficient? First, PKI deployment costs
are changing fast. A sophisticated model will
quickly be obsolete. Second, I think we're
more likely to find best practices by simply
asking for people to bring them forward than
by constructing elaborate models. So I think
the main purpose of a cost analysis for us
at this point is item 2) below: getting a
rough idea of where the big costs are so we
can make an intelligent decision about how
we can help reduce those costs.

I want to save most of our effort and resources
for what I think is the more important part of
the Lower Costs subcommittee's mission: to work
to *actually lower costs*! What do you think?

Thanks,

Steve

Arshad Noor wrote:
> An observation and some comments:
> 
> 1) About 5 years ago, I ran the Server Consolidation practice for
>    Sun Professional Services for the West Coast.  One tool we used
>    to help customers make the decision to go forward with a
>    consolidation effort was the Total Cost of Ownership Analysis.
> 
>    The TCO Analysis was a sophisticated spreadsheet model that asked
>    approximately 100-120 questions, plugged the info into the
>    spreadsheet and created tables and charts that showed whether the
>    customer could get a positive ROI from the effort.
> 
>    The most important element of this model was a database that Sun
>    procured from Gartner Group; the database had raw data from dozens,
>    if not hundreds of companies, in various industries/geographies and
>    their reported costs of operations.  The information supplied by
>    Sun's prospective customer was compared against this database to
>    extrapolate their future TCO if they did the consolidation.
> 
>    This analysis, with the right sales program, got us 3 of the 5
>    Fortune 500 customers we approached in the first 3 months.
> 
>    What we need to do is something similar from OASIS - i) a very
>    comprehensive questionaire that addresses all associated costs
>    of the PKI; ii) a voluntary effort on the part of all companies
>    that own a PKI, to anonymously report their costs with some
>    demographic data about them to account for region costs, etc.,
>    and iii) a spreadsheet that allows potential PKI deployers to
>    determine what they can expect from their own deployment.
> 
>    However, what is more important is that the database of raw data
>    must be kept updated for changing times, new industries, etc.  This
>    is something for OASIS (perhaps the PKI subcommittee) to determine
>    if this is within their charter or not.
> 
> More below.
> 
> Steve Hanna wrote:
> 
>> Ann,
>>
>> Good question. Here are several reasons I think
>> we want to understand the cost model better:
>>
>> 1) To inform deployers what to expect. However,
>>    I don't think this is a very good reason,
>>    since the costs of deploying PKI have been
>>    changing fast and probably will continue
>>    to do so. This suggests we should ask on the
>>    survey *when* someone deployed PKI (as well
>>    as what parts of the deployment were outsourced).
>>
>     Agreed, Steve.  We must ensure that the cost models show recent
>     PKI deployments, which cost very different from PKIs built
>     even 5 years ago. Secondly, it is also important to distinguish
>     between the core PKI deployment, and things that companies do
>     as an additional activity, because "the PKI is going to change
>     these things, so it makes sense to do it with this project
>     anyway" and the whole thing gets lumped into the PKI budget.
>     Building access is one example; the pilot application making use
>     of the PKI is another.
> 
>> 2) To understand which areas we (the Lower Costs SC)
>>    should focus on in trying to reduce costs.
>>    After all, that's our SC's charter.
> 
> 
>     Agreed again.  Fixed costs, variable costs, operational costs -
>     the information should clearly show where the impact is on a
>     company's budget.
> 
>>
>> 3) Maybe to identify certain organizations that have
>>    found ways to "beat the odds", keeping certain
>>    costs lower than average. Ask them how.
>>
>     Depends on what costs.  While people may be willing to offer
>     some information on startup costs, it is highly unlikely they'll
>     offer details about TCO - after all it would be to their
>     advantage to keep such information from their competitors if
>     they can.
> 
> Arshad Noor
> StrongAuth, Inc.
> 
>     
> 
>> Those are my ideas, anyway. Actually, I guess they're
>> also yours (at least, 1 and 2) since you cited them.
>> But I agree. I'd like to hear from others. And I agree
>> this is an important question.
>>
>> Thanks,
>>
>> Steve
>>
>> Terwilliger, Ann wrote:
>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> David,
>>> It looks good.
>>>
>>> Something to consider is what do we plan to do with this model?  Do 
>>> we plan to publish it (suitably sanitized) to make current or 
>>> prospective PKI implementers aware of the things that must be 
>>> accounted for in a PKI (policies, support staffing, maintenance, 
>>> etc.) and associated potential costs?  Are we trying to identify 
>>> areas where we might be able to provide some sort of guidance, etc. 
>>> to enable PKI implementers to do some functions in a more 
>>> cost-effective manner?  Or if there something else that we have in 
>>> mind?  The answers to these questions might help us know what kind of 
>>> guidance to give to the consultants developing the survey (as in how 
>>> to structure the questions).
>>>
>>> my two cents.....
>>>
>>>  -----Original Message-----
>>> From: Skyberg, David [mailto:dskyberg@rsasecurity.com]
>>> Sent: Friday, August 06, 2004 9:51 AM
>>> To: PKI Lower Costs
>>> Subject: [pki-lowercosts] Action items
>>>
>>>
>>>
>>> Hi all,
>>>
>>> Here’s the first cut at the action items for the contractor.  Feel 
>>> free to comment prolifically. :-)
>>>
>>>
>>>
>>> The current action item of the sub committee is to develop a cost 
>>> model for PKI.  The principal mechanism to accomplish this is a 
>>> survey which will be administered within the TC first and then taken 
>>> to a larger audience outside of OASIS.  Following a list of 
>>> activities to be contracted out in support of this effort:
>>>
>>> *        Draft the survey
>>>
>>> Work with the sub committee members to draft a survey.  The sub 
>>> committee will approve the survey before the survey is conducted.
>>>
>>> *        Survey Phase 1
>>>
>>> TC members will be the target of the first phase.  The contractor 
>>> will conduct the survey with all willing TC members.
>>>
>>> *        Phase 1 analysis
>>>
>>> The contractor will provide analysis of the survey results and 
>>> coordinate feedback from the TC on the survey itself.
>>>
>>> *        Refine the Survey
>>>
>>> The contractor will edit and refine the survey based on the feedback 
>>> from the TC, the analysis of the phase 1 results, and guidance from 
>>> the sub committee.
>>>
>>> *        Identify second phase targets
>>>
>>> The contractor will coordinate input from the TC as to likely 
>>> candidates for the second phase survey.  The subcommittee will 
>>> approve the final list.
>>>
>>> *        Survey Phase 2
>>>
>>> The contractor will conduct the survey with the
>>>
>>> *        Report analysis of results
>>>
>>> The contractor will report analysis of the results to the sub 
>>> committee in a format suitable for reporting to the TC.
>>>
>>>
>>>
>>
> 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]