[2342] in Enterprise Print Delivery Team
Re: Draft Response to Susan's Note
daemon@ATHENA.MIT.EDU (Rocklyn E. Clarke)
Tue Feb 26 22:10:55 2002
Mime-Version: 1.0
Message-Id: <p05010400b8a1fd551ddc@[192.168.1.101]>
In-Reply-To: <200202262303.SAA12474@fort-point-station.mit.edu>
Date: Tue, 26 Feb 2002 22:10:51 -0500
To: Enterprise Printing Delivery Project Team <printdel@MIT.EDU>
From: "Rocklyn E. Clarke" <rclarke@MIT.EDU>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Hi Dave,
This looks good to me. I only have two corrections:
1. Under ARCHITECTURE, in the 1st paragraph - change "Cost Objection" to
"Cost Object".
2. Again under ARCHITECTURE, in the 2nd to last paragraph - change "We'd surely
appreciation" to "We'd surely appreciate.
Thanks for the nice words about my role.
Rocklyn
-------
At 6:02 PM -0500 2/26/02, David F Lambert wrote:
>Team,
>
>Roger has reviewed this and is comfortable with it. Please send
>your comments ASAP to the list. I will forward Susan's note to the
>list in a minute. Thanks in adavnce...
>
>-Dave
>
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>Hi Susan,
>
>Thanks much for your note. It does help us understand your concerns
>around our new service and its implementation. The team felt some
>need to share with you some of our general thoughts on the project as
>well as acknowledge your response to our request for clarification.
>Some of what we've included below doesn't have much to do with
>your comments but we thought it might be useful for background.
>
>I believe the team and I have a reasonably good understanding
>of 'infrastructure'. For example, it seemed clear to me that SAN,
>fibre channel and enterprise backup were infrastructure issues.
>I'm much less clear around the level of interest ITAG has with
>architecture issues. One could view the structure of a program
>as an architecture issue but I doubt that's at a level of
>interest to ITAG.
>
>From a personal perspective, I would welcome an informal
>discussion with you around architecture issues. I'd like
>to better understand what criteria ITAG uses to determine
>its 'interest threshold'. I can imagine there might be a good
>list of criteria such as 'it touches enterprise data'.
>Just let me know when you have an hour available for a
>1-on-1. No rush.
>
>Please feel free to pass this along to ITAG or others. We feel
>there's no burning need to meet with ITAG but are certainly
>willing to do so if you feel there may be some value in doing so.
>
>SCOPE & CHARTER
>
>There was a scope change during the discovery work several years ago.
>That change was to limit the project to central printing only. Early
>in the discovery work it was clear we couldn't tackle the distributed
>printing issues in addition to the central printing needs in a reasonable
>timeframe.
>
>One meeting with ITAG was during discovery and one during delivery.
>We feel our charter & scope have remained virtually unchanged
>throughout the delivery project - provide a secure and authenticated
>central printing service for use by application servers, "power users"
>(users who initiate large volume print from the desktops for distribution
>to others), and desktops. Clearly, more detailed implementation
>issues developed and changed during delivery.
>
>INFRASTRUCTURE
>
>We've tried hard to adhere to infrastructure standards. You may recall
>the initial nod of approval to add kerberos to the native IBM clients
>with our Mac dev folks providing the coding in exchange for free
>kerberizing of their Windows clients by IBM. We started down that
>path briefly until we were informed this was not the optimum use of
>our Mac developers. We then pursued having IBM do all the client
>kerberizing work under a consulting arrangement. That effort was
>also pulled when we were told not to add another appl to the desktops.
>
>The team then focused on three authenticated submittal mechanisms -
>browser with SSL, KLP/R and special authentication mechanisms already
>blessed for 'trusted servers' such as SAP. We felt good about adhering
>to known and blessed solutions, despite the cost of building the
>customized browser interface.
>
>We weren't so thrilled that AIX was the only supported platform for
>the "enterprise" version of IPM. Good news may be on the way for
>the OS platform. We've heard unofficially that IBM has allocated
>significant dollars for porting the IPM server code to Linux.
>
>ARCHITECTURE
>
>The Cost Objection requirement has clearly ruffled some feathers. We're
>sorry that occurred. There may be a misunderstanding if it's believed the
>data is completely unvalidated or unused.
>
>The CO data is not used currently for charging purposes. Based on
>discussions with JDB and ISFT, the current funding model relies on
>existing IS bottomline dollars which supported the mainframe based
>printing. If additional use of the new service exceeds the existing
>budgeted dollars Jim suggested four approaches:
>1) fund additional growth via other internal savings
>2) request additional lump sum funding from new clients
>3) ask Curry for more bottomline funding
>4) invoke chargeback
>
>We've basically taken a snapshot of the existing clients' usage which
>has been bottomline funded. We did this exercise to determine a usage
>"baseline".
>
>The CO requirement was established to understand and track usage -
>especially as it relates to the baseline usage and related funding.
>Additionally, we felt a CO should be required in order to satisfy
>the needs around Indirect Cost Recovery. We also wanted users to
>be able to specify which CO should be associated with specific
>printing they perform. The original design included two CO
>validation steps using roles & the warehouse - is the CO valid and
>is the user authorized for the specified CO. The former is
>still planned for implementation in Release 2 of IPM@MIT.
>
>During delivery we discovered that key existing CAO central print
>users had no CO authorizations. We checked and were told that our
>implementation of SAP does not allow for $0 authorizations which
>would have been one mechanism for solving this newly discovered
>gotcha. Given the expected number of initial clients, we felt
>it was reasonable to continue to require a CO for usage tracking
>purposes. The COs would be reviewed manually via the monthly
>accounting/usage reports. This is less than ideal but does solve
>several problems for the near term.
>
>Please note our long-standing requirement of authenticated submission.
>Even if an inappropriate CO is used, with authenticated submission,
>we have the ability to identify the submittor. There are other
>more compelling reasons for the authentication requirement which
>I won't bother detailing here.
>
>Therefore, it should be noted that the CO data is used, and is
>validated - also noting the validation mechanism is not what we
>would prefer using. In Release 2, the CO will automatically be
>validated via the warehouse. We don't have a slick solution
>for the CO authorization issue yet. We'd surely appreciation
>any advice.
>
>I also need to acknowledge Rocklyn here. Since joining the
>delivery team, Rocklyn has been a strong proponent for fitting
>IPM into the existing architecture and infrastructure. He's
>been the primary force which drove our use of Moira, LPRng and
>Apache.
>
>WHY IPM OVER APS
>
>The team has received secondhand information questioning the choice of
>Infoprint Manager over the existing Athena Print Services. Below
>is a list of requirements identified during the discovery effort
>which is satisfied by IPM and not believed to be available with APS.
>
>Please note that a shared central printing service has requirements which
>are not needed or are less useful in a distributed printing environment.
>
>- User friendly interface for users for managing their queued requests
>- User friendly interface for operators
>- Ability to manage IPDS printers as well as Postscript printers
> to reduce overall capital costs
>- Support for electronic overlay forms
>- Page size information for queued files for print scheduling purposes
>- Current page count for actively printing file
>- Ability to start a file on page 'n'
>- Retention of printed files for reprints without resubmits
>- Ability to obtain accurate and detailed printer status information
