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. Classic scenario is that you do your prototyping, system setup and design, and just initial first pass validation in the development landscape in the appropriate client.
When it comes to development environments a consistent pattern has emerged where the Basis team will trip over buckets of dollars to save a few pennies by either painfully sizing the Development environment, or, at some point in the project they will pull so much hardware from Development for other parts of the landscape that the system just barely limps along. And sometimes it doesn’t even limp or crawl, it just dies!
For some reason they and the client project management are unable to see that the cost of software licensing and consulting time in comparison to hardware makes even the best stuff really cheap. And I mean absolutely dirt cheap by comparison. Even the vaunted “heavy iron” hardware from some of the top tier vendors is still comparatively cheap.
However, along with the relatively inexpensive hardware there is a second area that trips projects up and is probably the trigger for a lot of the hardware cost–, poor developer coding and poor database skills.
Even though these issues exist, and hardware is “relatively” cheap, after over 20 SAP projects I’ve seen a consistent Basis pattern that drives me berserk. They KILL the Development environment’s performance when it is still needed for ongoing project or support efforts.
For some reason the folks in Basis never seem to understand the impact on the overall project when they do this. The Development environment (in my opinion) does not have to have the same super-high-availability, ultra-redundancy, supercharged performance parts that the production environment does (but yes, it should generally be the same family of hardware for consistency purposes), but it should run well!
For all you Basis gurus out there, have you ever considered what the actual cost to the company is of saving a couple dollars in pulling every bit of memory, processor, hard disk, and anything else you can get from that box actually costs your SAP project in real terms? Okay, I’m fine with temporary pulls where you have to wait for replacement parts because the production system needs a boost, but come on, long term?
For companies that have “Basis” consultants who can’t seem to get the hardware properly tuned you may not have a qualified consultant.
SAP is resource intensive, but it is quite capable of working in a distributed environment where you have a separate application server and a separate database server. Or for that matter, 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 has any idea 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 hard dollars AND in terms of risk to your project and company):
- Transactions become so slow that high priced consultants are literally sitting around waiting to process. Multiply that by the number of consultants, and the number of transactions, and the amount of time. It can add huge $$$$ unnecessary cost to your project in wasted time and effort.
- There is additional time wasted by the consultants bugging project management, the basis group, the client, etc. This is a distraction waste that not only eats additional billable time, there are real costs associated with lost opportunities of those key individuals working on other pressing issues.
- There is the “frustration factor” as well that unnecessarily creates a poor working environment for any kind of performance. 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. Then try to re-establish that momentum! Good luck!
- End-users are given 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.
- 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 (once you are operational). More wasted time and frustration.
- Knowledge transfer is compromised in a painfully slow development environment. Especially by 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 creates a more intense “valley of despair” as it is referred to in Change Management. And that “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 and not as wide.
You get the point. I’m sure if I spent more time pondering it there are lots more reasons. But this has got to be one of the absolutely dumbest practices I have ever seen consistently carried out on SAP projects. I’m 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 in an efficient manner. So, the next time you are tempted to gut that Development landscape ask yourself, how much hardware can you take that will NOT negatively affect the landscape and would it be more cost effective to buy more hardware?
Contact me today through our site contact form ( http://www.r3now.com/contact ), phone, or e-mail.
- development environment
- enterprise software development enviroment recommendation