Digital's multi-vendor approach to customer's needs is apparent. They don't try to force a switch in platforms. Rather, Digital has organized a Multivendor Customer Services group to maintain similar systems to the common Sun/Netscape combination.

In addition, Digital caught a serious flaw in AppLogistics planning. AppLogogistics had planned on maintaining it's firewall in place in it's HQ data center even after the servers were shipped to Digital. However, they overlooked the obvious, the segment within Digital's location would need its own firewall service.

Netware File and Print Services:

Digital has a mixed message on AppLogistics Netware server. The Compaq 1500R equipment has been retired from Compaq's product line and it is Digital's recommendation to replace this unit with a Compaq 3000R.

However, they do admit that it has all the horsepower it needs to support the file and print services necessary. Since all upgrades remain a cost to AppLogistics the proposal carrier a hefty price tag.

We have to wonder, when is a legacy system like the legacy of an old dependable car? An old car might be well broken in, but it has no payments, doesn't need collision insurance and has likely had all the maintenance upgrades it will ever need. Since the goal of all of this is to save money we would have liked to see a graceful old age for this and similar systems.

We have to admit Digital's recommendation to upgrade is appropriate, conservative and places the interests of the user first ( perception of likelihood better up-time). However, we would have liked to see more imagination around this often overlooked but important topic - increasing the useful life of a given system.

AppLogistics' Lotus Notes Server:

Besides an upgrade to memory, Digital had no specifics for future plans for Notes. The mail server is currently handling the present workload. To their credit, Digital does plan on a transition plan to handle the deinstall/reinstall process with a minimum impact to the user community.

Although Digital does plan on defining complete details and areas of responsibility will be further in a due diligence period, there does not appear to be a clearly defined product group organized around the specific technologies of either Notes or Netware. This becomes clear as Digital describes their approach to the SAP market. After reviewing the documentation one would conclude that Digital is concentrating on application management. One would also hope this is not at the expense of basic network services and messaging.

The SAP application's abilities to build critical enterprise business systems is well known. That was the reason AppLogistics selected it. It also appears to dovetail with Digital's strategic alliances with SAP and Oracle, as well as their internal deployment of SAP applications.

After a due diligence review of the SAP installation, Digital proposes to take responsibility for AppLogistics' SAP Server operations in several phases. This includes confirming expectations and procedures for those phases of the application that will be managed jointly. Digital will perform a series of daily health checks on basic system, database and SAP parameters will be checked against agreed thresholds. Digital also maintains application level alerts for SAP within their Operations Management Center

Digital spent a considerable amount of effort analyzing the existing R/3 implementation. They made several pertinent and constructive recommendations. Primarily, they recommend separating the SAP application server from the database. In other worlds, placing it on its own server and replying on RPCs to communicate with the database. This has the dual benefit on providing an avenue for scalability as well as establishing a failover path. Finally reporting and decision support are segregated from transaction processing.

The details of Digital's recommendation were:

Digital recommends the three tiered system configuration for AppLogistics SAP R/3 implementation. We propose a separate database server and application server to spread the R/3 workload and establish a failover strategy. The database server would be configured to failover to the application server. The two servers would each have two 200 MHz CPUs and 1GB of Memory. The database server would have 40 GB of storage, which represents the R/3 database, mirrored. The application server would have 20 GB of storage to be used for operating system and R/3 overhead. Upgrades to the current Compaq 7000 should be made to the SAP application server to accommodate the recommended requirements for end user productivity. The acquisition of an additional Compaq 7000 would house the database server.

Our calculations were based upon the data supplied by AppLogistics. In addition we used the following assumptions.

A three-tier configuration (i.e., a separate database server and application server) is utilized to spread the workload more efficiently and to fill out a failover strategy

300 simultaneous users were interpreted to mean 100 concurrent (heavy) users. If this assumption is too low a more robust hardware configuration will be required.

The concurrent users perform their daily tasks in the R/3 modules as shown here: CO, and FI, (5 users each), MM and SD (45 users each).

The disk requirement was set at 20 GB and will be mirrored.

The data warehouse solution will be placed on a separate system from the R/3 application.

The application server will act as the failover machine for the database server.

Memory was increased to 1 GB for each server. [512mb in Statement of Objectives]

Digital reminds AppLogistics' management that infrastructure for the development/ quality assurance/ training machine for the R/3 project need to be available. Lastly, they provide a very diplomatic, gentle hint that NT may not scale and suggest a multi-operating system with cross-platform capabilities.

Pricing:

The obvious question when examining this quote is the proportion of the Help Desk price. It's fully %50 of total. AppLogistics only asked for a core data center and systems management server. While the inclusion of an optional service to provide a single point of management is laudable, the cost of the management in proportion to the cost of the service itself deserves additional inquiry on the part of AppLogistics.

Since AppLogistics finds it difficult to attract qualified technical staff in a tight market Digital proposes teaming on a project basis. They provided pricing for Contracted and Time and Materials services.

Digital as a Partner:

There are several key indicators in Digital's response that point towards a successful engagement.

Realistic scope: the Digital proposal does not try and promise things it would have to guess at or things that simply don't make sense. For example, AppLogistics is apparently happy with Netware file and print services. Digital did not try and alter that by proposing an switch in architecture.

The customer's solution: Essentially, AppLogistics got what it asked for not a solution based on what the vendor wanted to sell. To some vendor's this is a radical notion. Digital's response clearly indicates that AppLogistics will be able to buy hardware and software of their own choosing. There are "no requirements to purchase equipment from Digital or to purchase through Digital".

They reserve the right to innovate: Digital realizes that they need to work smarter. In order to make money at an outsourcing deal they will need to manage the servers efficiently. Therefore "Digital will be free to procure at its own expense any and all hardware/software/tools of its choice to support the provision of services to AppLogistics."

Personnel: a potentially difficult part of the process is AppLogistics desire to transition six staff members out of the organization. Digital recognized the potential for either problems or benefit. They propose to manage a fair and ethical treatment of these skilled personnel. This includes clarifying each employees future situation as soon as possible and providing comparable benefits, seniority vesting and quality of work life.