The dilemma that most enterprises face is that ‘time is money’. When we look at what is on the priority list for post upgrade activities and who is going to pay for it; the topic can get quite involved.
In an enterprise where business departments are internally billed for most IT activities; it will take less than 5 years for the business personnel to turn against any Data Warehouse and just stop using it. The business will invariably seek out and implement their own solutions, not supported by the IT department. This is directly traced back to the CIOs decision to reduce his IT costs by charging the business departments for almost everything.
There must be a clean distinction between charging the business for projects (aka direct changes in business process) versus the IT department constantly improving the implementation of the existing business processes (aka business as usual).
“not implementing post upgrade activities
means everyone in the enterprise pays the price”
In an enterprise where the support of a Data Warehouse is out-sourced to a partner enterprise; the ‘time is money’ topic still plays an overly significant part in the decision process and now has a lot of red tape attached to it (Agreements and SLAs).
Quite often the ‘time left over’ approach is used to prioritise the post upgrade activities. We have X hours available this month for this system, once we finish the break/fixes and high priority enhancements we will get into the post upgrade enhancements. This usually means that they never get started because there are always new high priority activities to evolve the current solution to meet new business process changes.
A lot of enterprises approach the post upgrade enhancements on new development activities that ‘occur from today onwards’. This approach is a good compromise that enables the new features to be leveraged. The downside is that the complexity and cost of supporting the Data Warehouse just went up due to an increase in the diversity of features used.
An Example: Update Rules to Transformations
Situation: BW v7 has been around long enough now that new support personnel have very little idea about the annoyances and techniques involved with BW v3 Transfer Structures and Update Rules. Every support ticket that gets raised against a data flow that has not been upgraded (to use Transformations) is a burden on the Enterprises bottom line because of the expected expertise required to support this feature.
Solution: Invest the time, effort and money to implement the lower priority post upgrade enhancements and shift the expected expertise away from the outdated functionality.
Advantage: The data flow capabilities are a lot more flexible when using BW v7 DataSources and Transformations to build your enterprise data warehouse. The developers and support personnel will grumble less. [Hopefully].
Domino Effect: When you only use BW v7 DataSources and Transformations you are also opening up the door to leverage other DataModel techniques like the Semantically Partitioned Objects (SPO) on DataStores. This makes archiving easier and naturally reduces the Hana memory footprint during data loads. Developer guidelines are also easier to define, document and learn as there are only a limited number of features in a Transformation available for tweaking.
First Choice Has to Be the Long Term Benefits
When an enterprise decides to ‘use the new post upgrade features in new development efforts only’; they are failing to consider the full impact across all the teams involved in the enterprise data warehouse. This includes the ability to extend the life expectancy of the existing hardware as a result of improved efficiencies.
This highlights that the topic of implementing post upgrade activities will always struggle to see the light of day, unless an IT resource is dedicated to the task. Stated another way; a position needs to be created for ‘IT Enhancements’ in parallel to the current Business As Usual (BAU) focus of ‘Business Enhancements implemented by IT’.
Welcome to the dream …