Part 2 of 3
In my last article, I identified a situation called The BusinessObjects Brain Drain. Practically speaking, the brain drain means that the brightest people from your favorite consulting partners and managed service providers have likely moved on to newer technologies like cloud computing, cloud data, AI, or newer BI tools such as Power BI and Tableau. You may have the same relationship with these organizations that you did three or even five years ago, but the staff that are taking care of your SAP BusinessObjects system are likely different people- and of a different caliber- than what you were used to when you first signed a relationship agreement.
The BusinessObjects Brain Drain is occurring in your own organization as well, again with the best and brightest moving to new roles in your organization or leaving the organization entirely.
The BusinessObjects Brain Drain may also mean that your SAP BusinessObjects platform has a reduced role in your organization. However, some of the use cases covered by your SAP BusinessObjects platform are still mission critical and it’s important to ensure that the platform continues to be managed well.
In this article, I want to review what kinds of documentation every SAP BusinessObjects team should have, whether your primary resources are in-house or outsourced. In many cases your service providers likely bragged about having a “center of excellence” so you should already have updated copies of the following.
System Architecture Diagram
Your BusinessObjects team should have an updated system architecture diagram showing all the servers in the SAP BusinessObjects landscape as well as peripheral servers such as the CMS, Audit, and Commentary database servers, popular unmanaged disk scheduling locations, and popular FTP/SFTP scheduling locations. The email server used for SMTP scheduling and its relevant parameters should also appear on this diagram. The system architecture diagram, or a document that accompanies it, should also document the ports opened on each server and what each port’s purpose is.
Backup and Recovery Procedure
The current backup and recovery procedure should be documented, describing how the critical components of file repositories and databases are backed up and how frequently. The procedure for recovery should not only be documented but tested on an annual basis.
Disaster Recovery Procedure
A generalized backup and recovery procedure is just the best practice in case of small mishaps like server or disk failure. Some organizations will require the creation and periodic testing of a full disaster recovery procedure. This procedure may look quite different in today’s cloud and hybrid environments than when everything was on premise in a physical data center. Many of the organizations that I’ve worked with do not consider analytics as “mission critical” so it doesn’t have the same level of urgency as operational applications.
SAP BusinessObjects Platform Support Tool
The SAP BusinessObjects Platform Support Tool should be a mandatory component for every SAP BusinessObjects organization. Not only should it be installed, but your organization’s SAP BusinessObjects product management team should be receiving summarized reporting each month.
Promotion Management
Organizations should have a document with screen shots describing common scenarios for using the Promotion Management feature in the Central Management Console. The exact details can vary from organization to organization and may differ depending on whether it’s a simple report migration or a more robust universe update.
Promoting universes isn’t just about the promotion management process, but also enforcing universe design standards and quality. Does your organization have a Universe Design Best Practices document? Does somebody at a minimum run the integrity checker against a universe and block promotion until any serious issues are addressed? Can a universe promotion be placed on hold for violating best practice?
Upgrade Management
Your organization should have an upgrade management process and test plan, documenting which features of the SAP BusinessObjects platform and which content should be tested before giving the green light for an upgrade. Testing for support packs (for example from SAP BI 4.3 SP3 to SP4) should be just as rigorous as version upgrades (for example from SAP BI 4.2 to 4.3). And let’s never forget that the introduction of a simple patch (for example from SAP BI 4.3 Patch 4 to Patch 5) can introduce a showstopper even though it may also fix something you’ve addressed in a support case. At a minimum, your organization’s existing upgrade process is going to be used at least two more times- for BI 2025 and BI 2027- and potentially more for patching.
Logical Security Model
It’s totally possible to build ridiculously complex security models using the Central Management Console. Yours may be treated as a spider web, with administrators reluctant to make changes lest a hungry spider bite them.
Unless you have a dedicated metadata management tool, the best tool for documenting a security model is a Microsoft Excel spreadsheet. You should document your group structure and folder structure as well as the built-in or custom access levels in use.
Bonus points should be assigned if you can put a business owner and a technical owner next to each top-level folder and next to each universe.
Metadata
If management is regularly presented with metadata, either obtained by a third-party product or by the ubiquitous yet clunky Query Builder, the process for creating the documentation (including any Query Builder queries) needs to be documented.
If your organization doesn’t already own a metadata tool for SAP BusinessObjects, it may be worth your consideration and budget. Moving forward, it is likely that portions of your existing SAP BI portfolio may be migrated to alternate technology or even retired. In both cases, metadata is going to guide the requirements for migration or retirement.
Your Thoughts?
With SAP committing to release SAP BusinessObjects BI 2025 and BI 2027, organizations that continue to depend on the platform are going to have to determine the best way to support it. What are you planning to do? Keep BI platform knowledge in-house, continue to use an outsourcing partner, or shop for a new outsourcing partner due to your frustrations about declining resource quantity?
Have I missed something important? What kinds of documentation ensure that your organization’s SAP BusinessObjects platform is well-run?
Resources
SAP BusinessObjects Platform Support Tool – https://support.sap.com/en/tools/diagnostic-tools/biplatform-support-tool.html
SAP BI 4.3 Platform Availability Matrix (has links to BI 2025 and 2027)