Architectural Thoughts

Since the acquisition of Business Objects by SAP I’ve the pleasure to meet a substantial number of customers who have their SAP systems in place and want to add Business Objects Enterprise basically as an add-on onto the hardware they’re running SAP on. From their perspective, Business Objects is just an add-on to SAP, so why should it not be installed on the same hardware as any the SAP System?

Throughout this blog I’m going to collect some architectural thoughts about these and other issues, and I’ll keep them pretty short (as the blog is fed through my BlackBerry).

Now here’s the first, more architectural answer: Business Objects is a reporting environment that sees the SAP BW system as a data source just as any other data source it may take its data from. Just as you’d not exactly want to install Business Objects Enterprise on your Oracle Database server – already for availability reasons – it is likewise architecturally questionable to install Business Objects Enterprise on the SAP system.

The second answer is about performance: A Business Objects Enterprise System may likely be used by a large number of people to do ad hoc reporting. If this is the case, it can have a substantial performance impact. This is why Business Objects (should I say, Crystal) Enterprise was designed in a way that it can be spread across multiple boxes in order to balance the load and improve the availability.

Putting all on one box, alongside a system that may serve completely different purposes, does not sound, well, exactly clever.

Sales people think of Business Objects as an add-on that they can up sell. Technical people should think in different terms – from an architecture as well as from a performance perspective.