Spend Performance Management is a SAP’s next generation analytical application covering the procurement analytics and performance management space. It has been built with proven SAP technologies. The backend of the application resides on top of standard BW, that’s where the data model gets deployed. The user experience is managed through the Adobe Flash based rich client user interface.
The reliance of the application on standard BW allows our customer to leverage the in-house IT investments or implementation partner expertise on the long standing BW technologies.
Here is an overview architecture diagram:
The BW content is structured is depicted in the diagram below. There are three “data layers”, the inbound layer, which is more of a staging layer, the detail layer which stores data with source system transactional granularity and with some data enhancements through BW transformations and the reporting layer which has all of the Spend specific cubes.
The source of the diagram above is SAP help site, BI Content Documentation. Pls visit for additional details.
It is now possible to access a lot of business solutions including a wide variety of analytical applications outside your firewall. This might include your hosting provider, your BPO partner, a generic cloud (PaaS + custom app), a commodity cloud (technology cloud + your custom app deployed on it) or a specialized business solution cloud (like SAP’s Business by Design).
Many/most of the analytical solutions tend to use a rich client user experience. The front end accessed by the business user is typically made up of technologies like Adobe Flash, Microsoft Silverlight etc which plug into the business users internet browser. And because of these rich clients, these applications stream down a good chunk of data from the server (typically a OLAP/BI server) which is okay, from a network lag performance point of view, as long as the server is closer by (on premise). But when these analytical applications move to the cloud, the impact on performance from the resulting network lag could very well be the deal breaker.
But we love the cloud because it lets us scale and lets us focus on our core competencies. So how do we make this work?
Well, good old terminal servers to the rescue. What I am suggesting is not novel or new. Terminal servers have been in use inside and outside the firewall for a very very long time. But they are perfect for our rich client analytical applications.
So how would terminal servers help?
As long as the terminal servers are located in close proximity to the analytical server, and the rich client user interface is actually being rendered in the terminal server itself, then all that the business user’s machine is replicating is a bitmap type image and the delta changes that will occur as the user navigates around the application. This is considerably less volume compared to streaming all that data through the network, over the firewall(s) and on the client machine. Additionally, the terminal server could pack a more powerful punch in terms of hardware than the user’s client machine and might be actually faster.
So is this solution perfect?
Yes and no. Two things to consider:
1) Rich client applications often times provide a visually stunning user interface. The terminal server might botch up this beautiful imagery.
2) Even though the actual analytical report execution and result set rendering might be faster, there might be screen image replication lag which might potentially be a damper on the usability.
It nevertheless makes a good discussion point to bring up with your cloud partner.
