Dependent on BusinessObjects?
I work with clients who need to modernise their business intelligence, reporting and analytic estates, helping them to standardise on cloud data products such as PowerBI and Fabric.
The last few months have seen a significant rise in SAP BusinessObjects enquiries, driven by a convergence of issues, which organisations must now face:
- Older BusinessObjects versions are out of support. 4.1 and 4.2 are still common, with support no longer available from SAP.
- We don’t want to touch BusinessObjects. The environment is fragile, and we cannot risk disrupting the service it provides.
- Our BusinessObjects experts have left the business or have retrained in modern products. We have little expertise left.
- BusinessObjects is running on legacy hardware (virtual or real) which has not been touched in years. We have issues in support status for the product and the operating system.
- Finding BusinessObjects expertise on the open market is difficult. These people are rare, expensive and busy.
I see BusinessObjects performing a number of roles. Critically, these tend to support the Finance and Operations functions. Reports are relatively static (i.e. not subject to frequent change) and those departments have become totally dependent on them over a period of years.
I also see niche requirements satisfied by Web Intelligence (Webi) or Crystal Reports, sometimes being embedded in other bespoke applications. These are tightly coupled, needing considerable time, effort and expertise to disconnect and modernise.
What are your options?
- If you are an SAP house, running ERP or CRM, you are invested in the SAP ecosystem and will find advantages when running BusinessObjects and the SAP roadmap analytic products and services.
- For organisations without a significant SAP footprint, there is little incentive to remain using BusinessObjects, and alternatives should be sought. Keep reading to understand your modernisation options.
How can I modernise?
The steps below relate to those organisations who want to move away from BusinessObjects to a more suitable, modern replacement.
1 The first step is to have a complete catalogue of the reports and dashboards provided by BusinessObejcts in your organisation. This may be well documented, but experience shows this is rarely the case. Your environments will need careful analysis and assessment to determine which artefacts are used vs those which are dormant. The catalogue will include universes, data sources, reports and other relevant assets.
2 The catalogue should be organised by business subject domain or data source to allow some high-level view of the overall problem. This information helps to determine priorities, complexities, dependencies, ownership and consumption within the business. This informs the scale of the problem.
3 Understanding the size of the BusinessObjects estate helps to determine an estimate of the requirement to migrate to an alternative solution. For shorter migrations, the organisation may proceed, at speed, with the migration effort. For larger challenges, it may be necessary to provide an interim solution.
4 For those larger BusinessObjects implementations, the migration will be lengthy. Interim support for the existing estate will be required during the migration process. BusinessObjects 4.3 is supported through 2025, with extended support available through 2027. An upgrade of the existing estate will be required, which should be treated as a separate project. Note that upgrades are not recommended “in-situ”, which means that a completely separate infrastructure is required — new licenses, new servers, new operating systems, and new networking config. This is a sunk cost, which sadly, seems unavoidable if support is required. Make best efforts to keep this cost to a minimum.
5 Plan the migration of reporting assets based on priorities established with the business. It is rarely possible to migrate all BusinessObjects content in a single “big bang” approach. Phases should be devised to incrementally migrate content from BusinessObjects to the target analytic platform. The first phase should be constrained in terms of scope — i.e. don’t take much content in the first round, as intricacies and unknowns will be unravelled, which will inform the migration process for later phases.
6 Migration allows the legacy BusinessObjects reports and the new analytic platform to run in parallel, which simplifies QA and testing. Stakeholders and users should be involved in the test process. When complete, ensure the legacy reports are restricted, so users work exclusively in the new platform.
BusinessObjects assets can sometimes be included in other applications. I see this where the product was selected as the reporting solution for bespoke systems within businesses. The reporting asset is surfaced in a window within the application. This presents complexities in the migration process. The method of integration needs assessment, including how parameters are passed between the application and BusinessObjects. Sometimes, the bespoke application has little documentation or support, which adds another layer to the complexity. Application modernisation (AppMod) techniques can be applied to reduce or mitigate these challenges.
About the author
Jamie Steele is a Data Consultant here at Version 1.
