I've spent quite a lot of time on SAP NetWeaver Business Warehouse (BW)-related projects over the years and in...
the process have developed some strong recommendations for my clients. Here are my top five suggestions for SAP BW teams.
Don't use ABAP if you don't have to (and you usually don't)
My gut feeling is that 80-90% of the ABAP (Advanced Business Application Programming) I see in most SAP BW implementations is not necessary. This ABAP can take the form of anything from Business Explorer (BEx) user-exit variables and transformation rule routines, to expert routines and custom data loading programs.
Usually the justification for this ABAP is that it's easier than using standard functionality, faster than standard, or that SAP BW doesn't offer this functionality. Of these reasons, the last is the only one that is regularly valid. Custom code is rarely significantly faster than standard SAP BW functionality properly implemented, and the argument that it is easier (if it's true at all) is usually only true if you ignore long-term maintenance costs.
Even if ABAP is the only option, or is easier or better-performing, we need to remember that when implementing data flow or reporting semantics in ABAP we lose one of the biggest benefits of BW: a consistent semantic model of our data management system from which BW can work, and which we can use to understand and manage our data and our data management platform.
For example, in BW 7.4 on HANA, SAP BW runs many standard transformations differently than it did in BW 7.3. It will actually push down the transformation processing to HANA. This will result in a huge performance gain with no change to the logic of existing transformations, for supported transformations. But this kind of optimization can only work if you don't use ABAP routines in our transformations.
So, we must carefully weigh the use of ABAP routines against the cost in maintenance and our ability to reason about the BW semantic model. Be sure that using ABAP is really necessary, and that there is not another, standard way to accomplish the goal.
Have an architecture and development guidelines
Develop a consistent architecture and way of doing things in your BW system. SAP even provides a reference architecture tailor-made for BW based on the Layered Scalable Architecture (LSA) concept. A new version of the LSA, called LSA++, has been created to account for more recent developments like SAP HANA and the addition of virtual semantic layers like SAP BusinessObjects Universes. If LSA is too much, isn't to your liking, or you aren't using SAP BW as a true data warehouse, then come up with your own architecture in consultation with an expert and codify it in a document or set of documents under version control.
Having a consistent architecture codified in a document will help you keep your BW environment organized. It eases the on-boarding of new team members and developers, and it provides a consistent framework for development reviews.
Do development reviews
Don't assume development is done correctly just because it seems to work in your test environment. All development should be reviewed by a quality assurance (QA) expert familiar with BW and your architecture guidelines before release to production. But go further than this and involve the QA person in a structured way throughout the development process. That way you avoid a high-stakes QA review just before the project go-live, which can result in political pressure to "temporarily" allow non-compliant development to go live (hint: it's never really temporary).
Keep up on patches and versions
Keep your BW system up to date on support packages. I recommend lagging no more than two support packages behind the most recent, which will usually mean a support packages application and basic testing cycle every four to six months. Yes, applying support packages takes time and effort, but being on a recent patch will save time identifying and fixing problems that SAP has already addressed. It will also keep your ability to upgrade and patch your systems well-honed, and applying a smaller number of patches at a time will be less risky than waiting and applying them all at once.
Similarly, you should work to keep on the most recent release of BW, within reason. Once you are able to verify a release a stable for your activities, go ahead and upgrade sooner rather than later. Doing so will allow you to leverage new features and capabilities when your business needs them, and not have to wait for an upgrade project to finish.
Use your metadata
One of the great strengths of BW is that using it results in the system recording a very detailed model of your data and processes. You should use these records, this metadata, to inform you about key metrics like data quality (for example, are my master data text fields populated in all the required languages?) and system performance (how long do my nightly loads take now versus a year ago?).
To a large extent, BW's existing BW Statistics content will answer questions about data load and query performance, and SAP's Information Steward can help with more in-depth data quality management. But even if you don't have Information Steward, if you have more detailed questions, the metadata is probably already in the system. You just need to build standard BW reporting structures on top of it.
And remember -- don't use ABAP!