A writer’s guide to accompany the sample Middleware
Business Case
developed by the Internet2 Middleware Early Adopters Team
Discussion
DRAFT
Send comments to:
mwbuscase-comments@internet2.edu
Draft Contributors
Tom Barton, University of Memphis
Robert Brentrup, Dartmouth College
Louise Miller Finn, Johns Hopkins University
Jack Seuss, University of Maryland, Baltimore County
Lesley Tolman, Tufts University
Ann West, Michigan Technological University/Internet2
Renee Woodten Frost, Internet2/University of Michigan
Writer’s Guide for Creating a Middleware Business
Case
Both
The Writer’s Guide for creating a Middleware Business Case and the sample
Middleware Business Case are documents produced as part of the Internet2 Middleware Early Adopters program. Early
Adopters is a group of eleven institutions of higher education working to
provide a testbed for the deployment of middleware technologies.
Middleware, sometimes referred to as "software glue", is
a layer of software services between an institution’s network and its applications.
In today's Internet, applications usually have to provide these services themselves,
which leads to competing and incompatible standards. Middleware utilizes directory
software to provide services such as user identification, authentication,
and authorization. By promoting standardization and interoperability, middleware
will make advanced network applications much easier to use and facilitate
inter-institutional access. Directory services are at the core of middleware
services. The directory identifies people affiliated with the institution
and the roles they play within the institution (student, faculty, staff, guests,
alumni, parents, etc.). The directory often serves as an authentication service
or supports other authentication services. The basic concept of middleware
– providing identification, authentication, and authorization services - is
at the heart of all services we now deploy.
Purpose of the Writer’s Guide and the Sample Middleware
Business Case
The sample Middleware Business Case has been put together to
help higher ed institutions create a compelling argument for an institutional
investment in middleware. The document starts with a broad conceptual framework
for middleware – what it is and what it enables. It includes sections that
comprise a business case for such an investment, the specific uses of middleware
and the applications it enhances and enables, and the impact such an endeavor
is likely to have on an enterprise.
The assumption underlying the sample Middleware Business Case
is that a reader will use it virtually as is, or as the basis for writing
his or her own case, adjusting it to reflect the unique needs and realities
of his or her institution.
The Writer’s Guide is a “helper” document that provides additional
guidance to those wishing to use the sample Case for their own middleware
justification. The format of the Writer’s Guide follows the format of the
sample Middleware Business Case. Each section is explained; at times there
are examples provided that further illustrate a point in the case document.
Occasionally, instructions are provided on how to best use the sample Middleware
Business Case to create your own.
In addition to this Writers Guide, there is another supporting
document for project planning.
Audience for the Business Case
Who is your audience? The sample Middleware Business Case assumes
you are writing primarily for people who are responsible for the making of
strategic IT and funding decisions, such as CIOs, IT Architects, and IT Directors,
CFOs and other fiscal officers. The document is directed toward institutions
that are thinking about, or just beginning to implement middleware strategies.
With proper modification however, it can be used to target
technical staff residing deeper in the organization. How much you accent the
non-technical and the technical will depend on who you want to convince or
influence with the case. A glossary has been included in both the sample case
and this Writer’s Guide to help with the technical jargon that is used. Be
sure to add any additional terminology you may include on your own.
References
There are a number of resources available addressing middleware
in general, and directories in particular. Some good starting points include:
The Burton Group,
Network Strategy Service (www.tbg.com)
www.tbg.com
"The Enterprise Directory Value Proposition" v1,
23 Feb 1999, Jamie Lewis, Dan Blum
The Burton Group’s Research & Advisory Services, which
include the Network Strategy Service and Networks & Telecom Strategy Service,
are a premiere source of technology analysis for network planners. This site
offers a number of white papers and other information specific to directories
and directory-enabled IT infrastructures.
The Gartner Group
(www.gartner.com)
The Gartner Group provides strategic consulting services to
more than 10,000 organizations worldwide. This site is an excellent general
reference for a host of middleware topics.
Internet2 Middleware Website (www.internet2.edu/)
At this site you will find middleware tutorials, information
about a wide range of middleware-based initiatives happening at national and
regional levels in higher ed, as well as a library of applicable documents
and papers.
The Sample Middleware Business Case, section by section
Executive Summary
An Executive Summary is recommended. A commitment to designing
an infrastructure that uses middleware is significant. The issues of data
and resource management are sweeping – the audience for the business case
is broad (across), high (up the hierarchy), and diverse (technical groups
and business groups). You will want buy-in from many corners of the institution.
You’ll reach more people if you provide a concise and convincing executive
summary in addition to a fully realized case study.
I. Introduction
You will likely want to supplement the verbiage in the sample
case with institution-specific examples of problems that can be solved by
middleware, and how. Succinctly describe the state of affairs at your institution,
express the potential of a middleware investment and the changes it can make.
Reference the changes that must happen to fully realize middleware’s potential
(centralization, levels of data management and administration that may not
currently exist, e.g.) The focus of the Introduction is more inward than outward
(compared to a Statement of the Opportunity, see below).
II. Statement of the Opportunity
This section is intended to help the reader relate middleware
services to wider institutional interests by identifying a number of fundamental
issues affecting all of higher education, and briefly discussing how middleware
can support efforts that address these issues. The Statement of the Opportunity
is more outwardly focused (versus the Introduction), providing a broader context
in which one can see the strategic value of middleware, made clear in the
final three paragraphs of the section. A commitment to middleware should not
be undertaken lightly. A strong statement of opportunity declares the potential
benefits early on, engaging decision makers in a positive way.
III. Business Case for Middleware
Section III is intended for IT leaders, identifying in detail
the benefits and the costs of committing to a middleware strategy. This section
is the heart of the case, identifying at greater levels of detail the objectives,
benefits, specific uses and applications, and once committed to, the impacts
that using middleware has on an institution. You may choose to use only a
few of these examples to tie a middleware deployment to specific needs on
your campus (such as single sign-on), or list them all to show the full potential
a middleware services deployment can offer.
Seven Positive Effects
This
section provides a summary statement of the value of middleware technologies
– IT services provided more securely and more cost effectively.
Benefits
This
section follows on the previous by going into greater depth on specific enhancements
to common services made possible by middleware.
Specific Uses/Applications
This
section goes into even greater detail, itemizing 24 applications made better
or more manageable by middleware, grouped by service.
Impacts
This last section describes six key areas of impact for those
institutions prepared to make a commitment to a middleware strategy.
IV. Project and Financial Overview
It
is important to consider the capital and operational costs to fully understand
the impact this type of project can have as a foundation component within
an enterprise.
The
methods of securing funds for this project can vary from campus to campus
and will depend largely on the existing staff, their expertise and level of
commitment to other production systems. It is possible to absorb the cost
of this project into existing initiatives that are underway, or within ongoing
operational budgets. It can be submitted to management for funding as a standalone
project as well. This is a case-by-case decision and will depend largely on
local considerations such as funding availability and willingness to take
on new initiatives.
The
case provides details for both scenarios: seeking funding as a standalone
project, or for a project using existing resources.
The
sample case includes a budget for a “new initiative”, standalone project.
A full-fledged return on investment model has been included in this Writer’s
Guide to assist the reader with estimating an institutional ROI for his or
her own needs (see Appendix F).
V. Recommendation
The language of this section of the Generic Middleware Business
Case allows recapitulation of the key points of your case, with direct transition
to a recommendation of action, funding level, and start time.
Appendices
Following is a range of appendices. They are a mix of things
that you may find useful when constructing your case: how middleware is being
used at other schools, important, specific information about the different
types of directories, why directories are so important to middleware and how
to make a strong one, a section on risks and contingency plans, and a glossary.
Last is Appendix G, which is a sample ROI for the fictitious Alpha University,
using Business Layers’ ROI Calculator. All of these can be used as is, or
can be altered to accommodate changes you make to your case.
Appendix A: Institutional Examples
I.
Business
drivers
Johns
Hopkins University
This directory will not only offer
an electronic version of our institutional phone book, but will also provide
a centralized method for application providers to authenticate and credential
a user upon login, saving a duplication of account management efforts across
the organization. With the increasing need to secure our transactions using
digital signatures and data encryption, a central repository of user identity
information becomes critical. Finally, the need to start-up and shutdown
user accounts as people move in, around and out of the institutions is being
driven by an increasing need to more effectively manage our resources and
maintain a secure computing environment.
The University of Memphis is the lead
institution in the Tennessee Board of Regents system of higher education,
which has for many years been one of the poorest funded state systems in the
nation. Although few institutions do not perceive funding to be a leading
issue, the U of M has chronically faced comparatively severe and firm resource
barriers. Investing some of U of M’s limited resources in middleware has proven
to be very enabling and the technologies themselves fairly inexpensive to
operate. U of M’s total IT infrastructure requires a smaller skill set to
operate than it would without heavy reliance on middleware, and therefore
its operation can be undertaken by a smaller staff. The twin virtues of efficiency
and enablment are both the justification and the consequence of this approach.
University of Maryland,
Baltimore County
The University of Maryland Baltimore County (UMBC)
began its first online program in 1998. Once we start dealing with students
located in nationally and internationally, which never set foot on our campus,
we realized the necessity of making campus services self-service through
the web. In the spring of 1999, as part of our IT planning work, we met
with faculty on this online program and with others using technology enhanced
learning tools, to identify their needs. This resulted in three priorities:
-
Revamp our existing web-based administrative services and create
a web portal that would provide all services in one place for students.
-
Revamp our account generation process, which was online but required
students to show IDs when they picked up their accounts, to allow students
to create their account over the web and never have to set foot on campus.
-
Better integrate our course management tools with our institutional
systems to eliminate the work of creating and distributing accounts to
students and enrolling students into their appropriate courses. Creation
and distribution of accounts was identified as the major impediment by
faculty using these course tools in large sections.
Associated with this planning activity was a
review of our administrative business systems. Our SIS and HR systems were
developed on campus under a HP 3000 environment and were showing their age.
While we had good transaction capabilities, we had limited tools for reporting
and the systems were not integrated well in terms of data definitions. As
such, it was felt that UMBC should begin investigating other options such
as SCT, Oracle, and Peoplesoft for replacing these systems, now that we were
ready for Y2K. We anticipated bringing up a new HR system in 2002 and a new
SIS a year later.
In fall 1999, we launched our web porta, myUMBC.
This was extremely successful and we began to get inquiries for providing
access to myUMBC for alumni, prospective students, and parents. We knew this
would create a challenge to us to revamp our authentication and authorization
services. We rely heavily on a Kerberos infrastructure for authentication
to campus services. This system supplied authentication services for computer
lab workstations, modems, portal, email, shell access, and a number of other
services on campus. The issue for us was that many services we provide were
automatically granted once you had a Kerberos entry and we knew that we didn’t
want alumni dialing into our modems if they were given access to myUMBC. As
a result, we had to develop a finer level of control for accounts and develop
a set of global attributes that could be queried by any application service
to determine whether to allow that person access.
Directory services and middleware have been fundamental
to meeting our campus IT goals.
As part of its middleware strategy, Tufts is in the
middle of a “Next Generation Directory” initiative. This new directory is
driven by a set of policies and procedures used to build a database of people
associated with the University, providing the ability to effectively and securely
authenticate and authorize users in a digital world. This ability will be
an absolute necessity if the University is to provide evolving network-based
IT services successfully.
The Next Generation Directory is seen not just a replacement
of the current “white pages” directory. It is a reinvention of the processes
that Tufts uses to capture and disseminate information about people. The
power of this new directory lies not only in the directory itself, but in
the directory-enabled applications it facilitates. A properly designed directory
will permit any application - whether deployed by the central IT organization,
individual School or Division - to have controlled, secure, and reliable
access to data about people at Tufts University.
Developing the Next Generation Directory will require
the active cooperation of data and process owners across the University.
One of the committees formed to address institutional data management issues
is The Next Generation Steering Committee. It consists of key data owners
and consumers and will provide ongoing oversight to this initiative. As
the project evolves, Tufts believes that this group will be critical to
our mutual understanding of the “data lifecycle”, as a person applies to
Tufts, matriculates, graduates, and perhaps becomes employed by the University.
Participation from all parts of the University is vital to a comprehensive
understanding of the issues, and for developing the broad plans necessary
to meet these challenges.
The deployment of middleware supports
an institutional business plan at Dartmouth College to increase the number
of business transactions conducted in a secure manner, on both the Internet
and internal institutional networks. The objectives are to improve service
by reducing the time for action completion and reduce costs by reducing
the need for additional administrative personnel. A shared campus-wide middleware
infrastructure will simplify application development and avoid duplicating
the costs of authentication and authorization services.
Improved network based administrative
services meet expectations in the College community for the availability
of self-service applications. Network based services allow time and especially
location independence as faculty and students are frequently off campus.
Secondarily, middleware should reduce the "time to market" for
new purchases and deployments of network applications by providing standard
compatible interfaces to authentication, authorization, accounting and auditing
services.
In many ways, these types of services
are competitive advantages for attracting faculty, staff and students. They
may also be necessary to work with systems envisioned by the Federal Government
for Student Loans and Grants and Contracts applications and processing.
Appendix B: Directories
Defined
It is important to understand there are differences in directories.
These differences are categorized as:
- Application-specific
directories:These directories come bundled with, or embedded into, an application.
Examples are Lotus Notes name and address book, the Microsoft Exchange directory,
and Novell’s GroupWise.
- Purpose-specific directories:
The directories are not tied to an application, but are designed for a narrowly
defined purpose and are not extensible. An example is the Internet’s Domain
Name System (DNS).
- General purpose, standards
based directories: The directories are developed to serve the needs of
a wide variety of applications. Examples include LDAP directories and X.500
based directories.
Appendix C: Requirements
for a General Purpose Directory
- Scalability – the enterprise directory service
must be able to scale well as usage increases, and as transparently as possible
to the user community.
- Performance – the system must perform extremely
well in an environment where users are spread out geographically and the
majority of the transactions are read-only.
- Management and monitoring
tools – the system must possess a strong
set of administration tools, since the data will live in a distributed system
of servers. Maintaining the health of the system will be critical to its
success and tools to do this remotely are important.
- Messaging system interoperability
– the directory may perform the e-mail alias to hostname resolution to facilitate
mail relaying and delivery, as well as provide for single sign-on for messaging
applications.
- Server Platform – to achieve maximum performance at the enterprise level,
mid-range Unix based systems are highly recommended.
- Bulk loading of the data
- Since much of the directory information is maintained in legacy systems
such as Payroll and the student registration system, it will be important
to be able to receive updates to the directory very frequently from these
systems. The ability to receive and process bulk-loaded information securely
and quickly is very important in order to maintain data synchronization
between the directory and the various systems of record.
- API (application programming interface)
and SDK (software development kit) availability –
The system must be accessible using development tools that exist within
the mainstream toolkits of programmers today such as Perl, XML and comparable
products.
- Directory Schema – Industry accepted object classes such as Person and
inetorgPerson should be utilized as much as possible. At no time should
an industry prescribed attribute should be repurposed for organizational
use, rather an additional attribute added to the organization’s object class
to handle the data requirement.
- Adherence to industry standards
– The system must utilize recognized standards that have been developed
or are developing, such as LDAPv3 (lightweight directory application protocol),
DSML (directory service markup language), CIM (common
information model),
DEN (directory enabled networking), DHCP (dynamic host configuration protocol),
DNS (domain name service), RSVP (admission policy) and DiffServ (differentiated
services for bandwidth allocation).
- Auditing tools – The system must include robust, configurable auditing
tools so that performance information, usage monitoring and forensics can
provide invaluable information about the operation of the directory service.
- Protection from DOS attacks (and
others) – The
directory servers should be isolated as much as possible on the network
and live behind firewalls. IDS should be running on each directory server
to detect intrusions, with pager alerts sent to the support engineer(s).
- Read vs. Write operations
– write operations to the directory must require a higher level of authentication
than read operations. For example, a user must use a public key certificate
over a protected SSL connection in order to write data to the directory.
- Replication – Directory replication links
that are accessible to users are vulnerable to eavesdropping and tampering
and therefore should be sent over secure connections. SSL or a comparable
method should be used for the replication traffic. At no time should replication
traffic travel in the clear on a network segment accessed by users. Additionally,
physical security to the directory servers should be restricted to only
authorized personnel by a card key or biometric system.
Appendix D: Risks and Contingency
Plans
A strong middleware project plan will include a discussion
of major risks in the project and possible solutions to address those problems
if they should arise. Here are some of the risks and contingency plans already
identified by previous Middleware projects.
Incompatible application
demands on LDAP schema
Risk:
The complexities of the LDAP schema are substantial. It is desirable to use
common definitions to support interoperation. Individual applications (which
may be added later) may have conflicting requirements.
LDAP maintenance feeds
Risks:
Feeds of data elements from multiple “systems of record” need to be merged
into the LDAP directory. These can be complicated to synchronize and have
many operational considerations.
Development of Policy
Risks:
There are a number of substantial policy issues to address and these take
time to resolve with the various stakeholders in an academic institution.
Contingency Plan:
Significant efforts will be needed to involve and inform the various stakeholders.
Resolution of the issues may delay or limit the universal availability of
some services.
Support from the institutional data custodians needed
Risk:
If the data custodians are not involved in the planning, the trust of the
entire middleware deployment could be compromised. In addition, if the Institution
unknowingly shares personal data that is protected by FERPA, it could be named
in a lawsuit.
Contingency Plan:
Data custodians, if not involved as key project team members, must be kept
informed of project plans and proceedings.
Availability of Applications
Appendix E: Glossary
Authentication
- the process of establishing whether
or not a real-world subject is who or what its identifier says it is. Identity
can be proven by:
- Something you know, like a password
- Something you have, as with smart cards, challenge-response
mechanisms, or public-key certificates
- Something you are, as with positive photo identification, fingerprints,
and biometrics
Authorization
- the act of determining if a particular
right, such as access to some resource, can be granted to the presenter of
a particular credential
Directories
- the operational linchpin of almost
all middleware services. They can contain critical customization information
for people, processes, resources and groups. By placing such information in
a common storage area, diverse applications from diverse locations can access
a consistent and comprehensive source for current values of key data. In future
information technology environments, directories will be among the most critical
services offered.
Identifiers - an identifier is a function that
maps real-world subjects into name or character strings, so that distinct
subjects have distinct strings. A real-world subject may be a person, an object
(i.e.: a printer or a file), a group, or a department. A real-world subject
can have multiple identifiers. When campuses seek to interoperate, issues
will arise on the type of identifier that needs to be exchanged, and the forms
and policies for that identifier. Moreover, to the degree that identifiers
enable users to access other forms of electronic credentials, there may need
to be agreements and consistency between campuses about the policies associated
with classes of identifiers.
Early
Adopters - the campus test bed phase of Early
Harvest, pushing forward the deployment of core middleware at thirteen US
campuses. Based on this experience, Early Adopters will develop roadmaps for
other campuses to follow in their own deployments. Both Early Harvest and
Early Adopters are sponsored by Internet2 and received some funding from the
NSF.
IMAP – Internet Message Access Protocol,
a method used by many email client programs to interact with a mail server
to enable users to send and receive messages and manage their email folders.
IMAP’s chief distinction is that users may keep all of their mail folders
on a central server and so have location independent access to their email.
Internet2
- the research and development of advanced
Internet technology and applications vital to the research and education missions
of higher education. Over 170 U.S. universities, working together with partners
in industry and government, are leading the Internet2 project. Internet2 is
working to enable applications, such as telemedicine, digital libraries and
virtual laboratories, that are not possible with the technology underlying
today's Internet. As a project of the University Corporation for Advanced
Internet Development (UCAID), the Internet2 project is not a single separate
network, but rather joins member network application and engineering development
efforts together with many advanced campus, regional, and national networks.
http://www.internet2.edu
ISO – Integrated Sign On. Usually used
in reference to the web (a web ISO), this is a type of credential forwarding
mechanism that can be used to forward authentication credentials to participating
servers. Generally, upon first encountering a server participating in a web
ISO system, a user’s browser is redirected to an ISO server to authenticate.
A special cookie containing a resultant credential is cached for a limited
time in the user’s browser, which is then redirected back to the original
server. Participating servers are configured to first check for this cookie
to obtain the user’s credentials, effecting a single sign-on system.
LDAP
- Lightweight Directory Access Protocol.
A protocol that provides access for management and browser applications that
provide read/write interactive access to the X.500 compatible directories.
Middleware
- or "glue", is a layer of
software between the network and applications. This software provides services
such as identification, authentication, authorization, directories, and security.
In today's Internet, applications usually have to provide these services themselves,
which leads to competing and incompatible standards. By promoting standardization
and interoperability, middleware will make advanced network applications much
easier to use.
PKI
- Public Key Infrastructure. The software, protocols and legal
agreements that are necessary to effectively use digital certificates combine
to form a Public Key Infrastructure (PKI). A PKI has several components.
- A Certificate Authority (CA), that manages and signs digital
certificates for an institution
- Registration Authorities, operating under the auspices of the
CA, that validate users as having been issued certificates
-
·
PKI management
tools, including software to manage revocations, validations and renewals
- Directories to store certificates, public keys, and certificate
management information
- Databases and key-management software to store escrowed and
archived keys
- Applications that can make use of certificates and can seek
validation of others' certificates
-
Trust models that extend the realm of secure communications
beyond the original CA
-
Policies that identify how an institution manages certificates,
including legal liabilities and limitations, standards on contents of certificates,
and actual campus practices
POP – Post Office Protocol. An old and
simple method used by many email client programs to enable new mail to be
retrieved from a central mail server and stored on the user’s computer.
QoS - quality of service. Measure of performance
for a transmission system that reflects its transmission quality and service
availability.
RADIUS - Remote Authentication Dial In User
Service. A protocol for carrying authentication, authorization, and configuration
information between a Network Access Server (e.g., dialup server or wireless
access point) which desires to authenticate its links, and a shared Authentication
Server.
SMTP – Simple Mail Transfer Protocol. The
Internet standard means of transporting email from sender to recipient.
SMTP
AUTH – a means of authenticating the originator
(a user as they initially send an email) or relayer (an email transport system
along the route to the recipient) of an email message so that the sender of
the email can be ascertained. Some email client programs will automatically
and silently supply authentication credentials to an SMTP AUTH configured
outgoing mail relay, easing the deployment of applications requiring authenticated
email.
VLAN
- virtual LAN. Group of devices on one or more LANs
that are configured (using management software) so that they can communicate
as if they were attached to the same wire, when in fact they are located on
a number of different LAN segments. Because VLANs are based on logical instead
of physical connections, they are extremely flexible.
VPN
- Virtual Private Network, which Enables
IP traffic to travel securely over a public TCP/IP network by encrypting all
traffic from one network to another. A VPN uses "tunneling" to encrypt
all information at the IP level.
X.509 - This
specification profiles the format and semantics of certificates and certificate
revocation lists for the Internet PKI.
Appendix F: Sample ROI using the Business Layers ROI Calculator for Alpha University
Step 1 – Define your organization
For
the purpose of this document, we chose a mid-sized university, with a combined
mix of faculty, students and staff totaling 10,000 users of networked resources.
We used turnover rates somewhat higher than industry findings in the corporate
sector, since we have students and faculty which change annually as a matter
of doing business.
Appendix F: Sample ROI using the Business Layers ROI Calculator
for Alpha University (continued)
Step 2 – Define the IT Costs
To
define the cost of IT labor, we chose a conservative rate, which includes
salary and benefits combined. And, since many schools have a very thin IT
support staff, we chose a low number of staff members to handle the account
management tasks.
Appendix F: Sample ROI using the Business Layers ROI Calculator
for Alpha University (continued)
Step 3 – Define the Cost of Lost Productivity
Again,
these numbers will vary from campus to campus, but for the purpose of this
model, we estimated conservatively, to keep it as realistic as possible. Most
schools do not even consider the cost of lost employee productivity since
there is no driving bottom line that needs to be managed. However, lost productivity
should be considered and measured if a school wants to compete with for-profit
organizations that are now in the higher education marketplace.
Appendix F: Sample ROI using the Business Layers ROI Calculator
for Alpha University (continued)
Step 4 – Define the Cost of Faculty/Student/Staff
Inactivity
Appendix F: Sample ROI using the Business Layers ROI Calculator
for Alpha University (continued)
Step 5 – Define the Indirect Costs
When
trying to quantify the cost of security breaches, fraud and network sabotage,
we used a totally fictitious number, but stuck with the industry findings
for amount of IT staff time spent troubleshooting and providing user support
to incorrectly configured services.
Appendix F: Sample ROI using the Business Layers ROI Calculator
for Alpha University (continued)
Step 6 –Summary
Appendix F: Sample ROI using the Business Layers ROI Calculator
for Alpha University (continued)
Step 7 – Projected Savings if E-Provisioning
were Utilized
Appendix F: Sample ROI using the Business Layers ROI Calculator
for Alpha University (continued)
Step 8 – Cost of deploying a Business Layers
solution
Using
the Business Layers solution assumes the organization has a directory service
in place.
Appendix F: Sample ROI using the Business Layers ROI Calculator
for Alpha University (continued)
Step 9 – The Payback Period
It
is important to note that this model does not display the payback period for
the deployment of the directory service itself, however, that can be extrapolated
from the information provided.
