Anyone who has implemented SAP for any period of time has seen the classic three-tier system environment. You have a Development landscape, QA landscape, and then a Production landscape. In a classic scenario, you do your prototyping, system setup and design, and first-pass validation in the development landscape for the appropriate client.
When it comes to development environments, a consistent pattern has emerged where the Basis team will ignore the potential for large profits to save a few pennies. In this case, they may either painfully size the Development environment, or at some point in the project, they may pull so much hardware from Development for other parts of the landscape that the system just barely limps along. In some scenarios, the system doesn’t even limp or crawl– it just dies.
For some reason, they and the client project management cannot see that the cost of software licensing and consulting time makes even the best hardware seem inexpensive. Even the “heavy iron” hardware from some of the top-tier vendors is still comparatively cheap.
However, along with the relatively inexpensive hardware, a second area can trip projects up and is probably the trigger for a lot of the hardware costs: poor developer coding and poor database skills. They destroy the Development environment’s performance when it is still needed for ongoing project or support efforts.
Often, the Basis team does not see how this impacts the overall project. In my opinion, the Development environment does not need to have the same super-high-availability, ultra-redundancy, supercharged performance parts that the production environment has (but yes, it should generally be the same family of hardware for consistency purposes). Even then, it still needs to run well.
As a general rule of thumb, “Basis” consultants who can’t seem to get the hardware properly tuned may not be qualified. SAP is resource intensive, but it can easily work in a distributed environment where you have a separate application server and a separate database server. For that matter, SAP can handle multiple application servers where you can either load balance, or have one set of users logging into one app server and a different set in another.
On top of that, SAP provides a significant number of performance monitoring tools– if your Basis consultant knows how to use them. They can evaluate custom program processing times, long database query times, search for SAP OSS notes for performance, and a whole host of other options. Most often I have found that major processing problems are because there aren’t a lot of SAP Basis consultants who really understand database administration well enough to know how, when, or why to build custom indexes, or when to have a custom program reviewed for efficiency and performance improvements. Those are just a few of the reasons SAP Basis resources struggle with maintaining decent system performance.
Here are some of the costs (both in hard dollars and in terms of risk to your project and company):
- Transactions become so slow that high-priced consultants have to wait to process. Multiply that by the number of consultants, and the number of transactions, and the amount of time. This wasted time and effort can add unnecessary cost to your project.
- Consultants have to spend even more time bugging project management, the basis group, the client, etc. Not only does this eat away at billable time, but these key individuals lose opportunities while working on other pressing issues.
- The frustration factor also unnecessarily creates a poor working environment. If you’re a project manager that believes in trying to develop momentum in the pace of your project, watch how fast a choked-up Development environment can kill any momentum you build.
- End users receive a bad impression when they access a Sandbox or other development area to try out other transactions. User acceptance is compromised, and the rumor mill starts about how badly the system runs.
- Once you are operational, the ability to test run “what if” scenarios, or other types of trials in a safe environment before trying it in a production system, is compromised. More wasted time and frustration.
- The painfully slow development environment also compromises knowledge transfer– especially for any extended users who want to work in a safe environment before, during, and after go live. If the system is slow enough, they just won’t bother. This poor knowledge transfer creates a more intense “valley of despair” (as it is referred to in Change Management). A “valley of despair” is the productivity drop off that occurs right after go live and continues for some period of time. Effective knowledge transfer makes that “valley of despair” more shallow.
You get the point: ignoring significant costs to pinch pennies is a poor practice. I’m sure if I spent more time pondering it, I could find even more reasons. To be clear, I am not opposed to stripping hardware from a Development environment, but the minute that Development environment’s performance negatively affects the people who use it, the Basis team is not effectively carrying out their project responsibilities. And that main responsibility is to ensure a technical landscape that supports the project and the company efficiently. The next time you are tempted to gut that Development landscape, ask yourself, “How much hardware can I take that will not negatively affect the landscape, and would it be more cost effective to buy more hardware?”.
