[2339] in Enterprise Print Delivery Team
Draft Response to Susan's Note
daemon@ATHENA.MIT.EDU (David F Lambert)
Tue Feb 26 18:03:47 2002
Message-Id: <200202262303.SAA12474@fort-point-station.mit.edu>
Date: Tue, 26 Feb 02 18:02:36 EST
From: David F Lambert <LAMBERT@MITVMA.MIT.EDU>
To: Enterprise Printing Delivery Project Team <printdel@MIT.EDU>
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
