On the Road to Implementation
Before we close out discussions on designing and implementing the SAP Data Center, it’s important to look at how everything up to this point needs to be sustained. SAP deployments progress in phases or “waves”—each wave brings with it another collection of data center resources that must be planned for, installed, configured, and managed. For example, most new deployments start with bringing in the Technical Sandbox and Development systems. Later, the Test, QA, Integration, Staging, Training, and other environments are introduced to the Data Center. Eventually, the Production and Disaster Recovery systems are phased in as well.
Planning for SAP Data Center Operations
Before most of the SAP Technical Support Organization staff involved with setting up the SAP Data Center walk away, I need to cover some details related to managing the SAP Data Center. At this stage in the SAP project, we are more concerned with day-to-day and similar “tactical” operations than anything else. The strategic operational needs of the deployment will be addressed fully later.
I assume that an SAP-aware Enterprise Management Application has been deployed. That is, I assume that software agents are loaded on each SAP and SAP-related infrastructure server, and that a Management Console has been put in place to manage all SAP Data Center resources. I also assume that your Operations and SAP Basis teams have been trained on how to fundamentally use this all-important management tool, with the understanding that the learning curve is still pretty sharp over the next month or two.
In my experience, good SAP computer operations start with not only the use of an enterprise application, but also with paper-based daily and weekly checklists. Why the reliance on paper and pencil in this age of automated computing, and after spending tens of thousands of dollars on an SAP monitoring tool? Three reasons:
These paper-based checklists will force SAP Operations to learn how to effectively monitor an SAP environment, using SAP-native tools like SAP CCMS—the same source of monitoring and management data leveraged by the popular SAP enterprise management suites.
These checklists provide backup, should the Enterprise Management tool be unavailable (or the rolled-up or alert data unclear to the marginally experienced SAP support team).
After a completed checklist becomes mandatory during shift-turnover, these checklists encourage accountability; they force the operations team to actually do the job of monitoring your mySAP solution.
Eventually, the paper-based checklists tend to lose their effectiveness from a training/knowledge perspective. At that point, the SAP Operations team often puts them back on the shelf, to be dusted off again later by new-hires and other new members of the support staff as they come on board. Some of my customers, though, continue to use their checklists long after their Enterprise Management tool is in place and functioning correctly, and the operations team is ramped up. They simply modify the checklists to better reflect the operational needs of the organization, or add the discrete tasks from the SAP checklists to the tasks and responsibilities of a larger-scope document maintained by the Data Center staff. And other accounts continue to use these checklists simply because they are effective; they still force a certain level of accountability, as long as the SAP Data Center Manager requests that they be used.
| ▸ | To learn much more about operational and systems management activities in regards to SAP Data Center Operations, see “Back to SAP Operations,” p. 503 in Chapter 14. |
Special Considerations When Deploying the Technical Sandbox
The first time SAP is installed in the Data Center will likely be in the Technical Sandbox (“sandbox” or “crash and burn system”) or similar testing environment. Oftentimes, the sandbox will look nothing like the Production system is expected to look. In the haste to get something running quickly, many SAP implementations introduce what can only be described as a stripped-down version of what will ultimately grow to be the actual Technical Sandbox.
The sandbox provides valuable hands-on experience to the SAP Basis, DBA team, and the SAP Operations team. It allows each of these technical groups the opportunity to see an SAP installation in action, and begin to realize the fruits of everyone’s labor up to this point. Further, it allows the entire SAP Technical Support Organization the chance to verify what it already should suspect as “holes” in the organization (these holes are addressed later in Chapter 12). Specific SAP components like Enterprise Buyer Pro and Enterprise Portal require knowledge and expertise in areas outside of simple SAP Basis installations, for example.
As the SAP Data Center grows and matures, the Technical Sandbox will grow with it. As a result, the following needs arise:
Every SAP component needs to be installed and tested in the sandbox prior to installing it elsewhere. Thus, because it’s unlikely that anyone wants to maintain a sandbox with multiple SAP instances, robust tape backup/restore capabilities need to be introduced in the Technical Sandbox eventually.
Every layer in the SAP Solution Stack must be represented within the sandbox. For instance, if a Web component like ITS (Internet Transaction Server) or Web Application Server will play a part in the Production system, it also needs to be represented in the Technical Sandbox.
Finally, the SAP Operations team should begin to grow comfortable with managing and maintaining SAP, as I discussed earlier. This can be accomplished in a number of ways. For example, Operations should begin their “career” in SAP monitoring by starting with the Technical Sandbox. I’m talking about more than the SAP-aware Enterprise Management console. Other hardware/software-specific management consoles, like Insight Manager, HP Openview, Windows 2000 Performance Monitor, UNIX command-line performance utilities, and so on, provide must-have snapshot-in-time and historical trend-analysis value.
With the knowledge gained in performing the preceding tasks in support of the Technical Sandbox, the SAP TSO will be better positioned to address the needs of the next truly critical system within the SAP landscape—the SAP Development environment.
Special Considerations When Deploying the Development System
When the development system is installed and in place, for all intents and purposes it becomes a productive system—not for end users in the traditional sense, but for the expensive Functional experts and SAP ABAP programmers who will customize this system for many months to come. Therefore, the Development system needs to be treated like a Production system with respect to the following:
Downtime— Bringing down the development system is unacceptable without plenty of warning. That is, a schedule for planned downtime must be developed, to address various operations and administrative tasks. These might include performing backups, executing client copies and refreshes, and so on. Why? First, because the SAP Functional experts and ABAP programmers are not cheap, and their time is therefore valuable—without a development environment, these folks will only sit idly by, still billing hourly fees that can easily add up to tens of thousands of dollars for the entire development team. Second, because downtime results in implementation schedule slips, and costs even more down the road.
Monitoring— A proactive approach to monitoring the development system needs to be put in place immediately, both to minimize unplanned downtime and to quantify that the development system is performing well.
Backup/Restore— It is absolutely critical that the work being performed by the development team can be safely backed up to tape, and preserved offsite in the case of a disaster. Why the seriousness? Because the work that goes into the development system to prepare for a productive system can easily equate to many millions of dollars in productivity.
By now, you should be well into your SAP implementation. In the next chapter, I will step back and discuss in detail the SAP Basis installations particular to most of the popular SAP components—R/3, BW, APO, CRM, EP, and more.