This is weblog 7 of the series on the use cases of the Switch and Enhancement Framework. Here you get a basic understanding of the third use case: the Enhancement Package strategy of SAP ERP 6.0.
As a reader of this series you have by now understood the basic concepts of both the Enhancement and the Switch Framework. I have covered most of the new concepts in the weblogs 1 to 5 that explain how to create some modification free enhancements and how to make your enhancements switchable. In weblog 6 I have explained how the reintegration of the SAP Industry Solutions into the ERP core works and in which way it is supported by the framework. You find a list with links to all weblogs of this series at the bottom the SDN Wiki page on the Enhancement Framework. On the same page you find also links to all weblogs of my other series that go more into the technical details of the Enhancement Framework.
In this weblog I tell you
The Enhancement Package Strategy is a new way to get new functionality on top of the current ERP release. It offers you a dimension of choice insofar as you can now choose which new functionality you want to install and which new functionality (this may be a subset of the one you have installed) you want to activate. The technological base of this strategy are technologies for optional installation and optional activation of handy, digestible software pieces that are tailored to your business needs. The activation of the new functionality is empowered by the Enhancement and Switch Framework. And the good news for you is: Understanding how this technically works will not require you to master any new concepts. As far as the Enhancement and Switch Framework is concerned you have already mastered all the important concepts and structures.
To the extent that the Enhancement Package Strategy relates to software installation and its management, it is not enabled by the Enhancement and Switch Framework, but by the SAP Solution Manager and the well known and now improved transaction SAINT. I will only sketch this part of the new process in my weblog, because it is out of the focus of my series.
Regarding the installation of new ERP functionality customers had only two options up to now:
Both options have their advantages, but unfortunately, also important drawbacks:
On the one hand, most customers need new functionality for new users, for new roles, and new business scenarios, and so they are interested in getting new, innovative processes. This is a strong motivation for an upgrade and convincing argument against staying on the same release. But, on the other hand, there is a strong desire on the customers part, a desire to keep a stable core in order to minimize system downtime, in order avoid changes in IT processes and the related training costs. So customers try to avoid a larger functional upgrade in the system except for the processes where they really need new functionality. This is because an upgrade causes a lot of work, and if the customer has a lot of modifications, the effort required by an upgrade still increases tremendously.
Enhancement Package strategy provides a solution to this problem: The aim of the Enhancement Package strategy is to have innovation without disruption. This is the promise:
The customer can stay on one stable release and still get new functionality. The process to get new functionality is driven by business needs, not by technology requirements. The customer can choose when he wants to have the new functionality. While the classic upgrade was like substituting all the furniture in your house by new ones, the Enhancement Package strategy means to substitute and to add only new pieces where you need them. And this is far more natural: If you want a new TV set, there is no need to touch any other pieces of furniture.
The simple principle of the Enhancement Package strategy is that you get only what you need and to avoid any further impact on your system. This way it causes far less work, and it offers you the choice you want to have, while in an upgrade you had to take it all.
The new functionality comes in small digestible pieces, so-called Business Functions. You can choose which Business Functions you want to use and then you install only these portions of new functionality. After the installation your system is exactly the same as before. The mere installation of new functionality does not cause any functional changes in the system. This is because all new functionality is encapsulated by switches and so the installation of new functionality is decoupled from its activation. This way, an administrator can install functionality you want on weekend, and in the months to come the relevant specialists can activate each Business Function separately as it fits your business needs and planning.
At the bottom, the new strategy brings three major changes:
The content of the Enhancement Packages can be pigeonholed into four categories:
The figure below gives you some impression of the new features that come with the Enhancement Packages, the areas these features cover, and when these packages are scheduled to be delivered:
It is planned to deliver about one Enhancement Packages a year. The installation of the functionality is voluntary. This is the basic difference between Enhancement Packages and support packages:
Still, there are some internal limitations that are meant to reduce the complexity. So each component of ERP can either be on Enhancement Package level 0 (no enhancement package installed) or the highest Enhancement Package level that is available for this component. And there are dependencies between the Enhancement Package level and the Support Package level, insofar as installation of parts of a particular Enhancement Package may require some patch level in your system. But these are only some minor restrictions of the general freedom the Enhancement Package strategy offers.
So much for the conceptual differences between Enhancement Packages and Support Packages. But despite of these differences, there is a way in which you profit from installing an Enhancement Package and Support Packages in one go. The figure below highlights the difference between the traditional and the new innovation life cycle. In particular you should note the different schedule for installation of Support Packages in the traditional and the new world:
In the traditional world there were upgrades, which required major efforts, and in between the customers installed the support packages. In the new world, with the new Enhancement Packages, SAP recommends to install
in one queue of the well known transaction SAINT .
By following this installation procedure you will learn that the additional effort you need for installing an Enhancement Package in addition to support packages is pretty small, but, of course, depends on the technical details. This way the combined installation of support packages and Enhancement Packages will save you a lot of time an effort. You might compare this to installing new office furniture in the same time slot in which the office is painted. Obviously, this procedure will save you quite some time in comparison to painting the office in one month and the installing the new furniture in another month. Choosing the first alternative you will save a lot of time. In a way, you might say, that this way of organizing things reduces the downtime of the office, that is the time, when you cannot work in the office. In the same way, the combined installation of support packages and an Enhancement Package at the same time will help you to reduce the effort you need to patch the system and to get new functionality.
As I have already explained, the technology that empowers the Enhancement Packages covers two areas:
Though the installation technology is not enabled by the Enhancement and Switch Framework, I will spend a few words on the technical details of this topic and on how this part of the process is realized in general.
The first step is always to decide which Business Functions you need. There is one central point to get all the information about Enhancement Packages and their content. It is the page with the alias erp-ehp in the SAP Service Market Place . There you find all the Business Functions and the detail knowledge about the functionality contained in a Business Function.
For every process there are links to documentation, presentation(s), release-notes, dependencies, and the test catalogue (a list of preconfigured acceptance tests):
After you have made up your mind which Business Function(s) you need, you choose the relevant units in the Maintenance Optimizer, a tool in the SAP Solution Manager. In fact, you do not really choose Business Functions, but units called Technical Usages. These units comprise of many Business Functions. Their aim is to reflect interdependencies among Business Functions. It is these Technical Usages that determine the component versions you need to install. But why are there technical usages? In particular, there may be cross-stack dependencies, because some Business Functions on the ABAP stack may require additional Portal-, BI-, and PI-content. So a Technical Usage is a more comprehensive unit. But these are technical details that mean no real exception to the rule that you choose a functionality you want. And this surely is a point my colleague Christian who is far more familiar with the ERP Enhancement Packages than me will probably explain in more detail in his The specified item was not found. or the weblogs he will publish later.
The Maintenance Optimizer gives you also a list of all Support Packages you must also install together with the Business Functions you want. This is necessary because, in general, a particular Enhancement Package requires the installation of the relevant Support Packages. You need not care about any details of this, because the Maintenance Optimizer does it all for you. The next figure shows a part of a screenshot from this tool. It is there, that the Support packages you need for the Technical Usages are calculated:
Depending on your choice the tool calculates a stack containing the Business Functions you want plus the relevant Support Packages needed for them. As far as components in the Application Server ABAP are concerned, you can import the Technical Usages (containing the Business Functions you have chosen) and the Support Packages necessary for this in one queue using the well-know transaction SAINT you are familiar with.
So much for the technical details of the installation.
When an enhancement package is installed, the relevant software components are enhanced and updated. This is why the customer has to run regression tests after he has installed an Enhancement Package - even if no business function has been activated yet.
It is then up to you, your business needs, your organizational constraints, and the projects you want to set up, which Business Functions you activate. The same is true for the time: You activate the Business Function when it suits your needs, and you activate only the Business Functions you want.
All the new functionality is encapsulated by switches. This means there is no functional change of existing functionality before you activate the new Business Functions. So the runtime behavior of your system does not change before the activation, and there is no need to train users in any way before. You determine the point in time, when some changes are needed.
Imagine that you need some functionality contained in the new Order-to-Cash Scenario. You install the relevant Business Function, but all the users in your company can still work with the old processes in the way they are used to. It is only after you have activated the new Business Functions that the new functionality is available and that you must train your users.
If you activate only this Business Function that contains the new Order-to-Cash Scenario, you need not expect any other changes. This means, that users working with other functionality can work in the same way as they did before. They need not change anything in the way they work and your company need not train them. You must train only the users of the new scenario. There are no side effects when you install a particular Business Function. You look in the Service Market Place on the relevant page (alias erp-ehp), inform yourself about the new processes that are part of the Business Function you want to activate. And then you can be sure that only these processes change in the system. All other processes stay the same.
The tool to activate the relevant Business Functions is again the transaction SFW5, the Switch Framework Transaction. The next figure shows you a screenshot of this transaction:
Depending on the IS solution you have chosen or on whether you are working with a pure ERP system the transaction SFW5 shows you a list of all the Business Functions that are installed on your system. The tool provides you also links to the relevant information sources such as documentation, release notes, test catalogue, and the dependencies. The last point is something I have not mentioned so far: A Business Function may require the functionality of another Business Function. This is a property that the developer of a Business Function defines when creating or maintaining the relevant Business Function. If a Business Function depends on some other Business Function you find this information under the relevant link in the SFW5.
So after you have made up your mind about the Business Functions you want to activate and once you know the relevant dependencies, you activate all these Business Functions by selecting "Planned Status On" in the Switch-Framework transaction. You can then press the Button "Check Changes" to evaluate if you have made a consistent choice. If the result of the check is ok, you activate the changes, a job in the background is started, and when it is finished, all the Business Functions you have selected are available in the system.
From a more technical perspective this means: Before you have activated the relevant Business Function, all the code of the new Business Function that is encapsulated by switches it not compiled. So it is simply not part of the ABAP load at runtime. This way, it is not available, and it cannot influence your system in any way. Functionality that is switched off has no impact at all on the performance of your system. So there is no reason to be afraid that Business Functions that are switched off or not activated might harm or slow down your system in any way. Functionality that is switched off does not exist at runtime in a very literal sense. Once you have activated a Business Function and the relevant job is finished, the new functionality is fully available at runtime.
If you have read the other weblogs of my series, you surely have already a very definite idea of how the switching is technically realized. You know how the encapsulation of all new functionality by switches works, if you have understood the concept of a Business Function that I have explained in the weblog on the reintegration of the SAP Industry Solutions and in the weblog before which centers around the topic of switching in general.
The Business Functions I have talked about in the context of the Enhancement Packages just are the Business Functions that I have introduced as a central concept of the Switch Framework. From a technical perspective a Business Function consists of a lot of enhancements and other switchable elements. They are all assigned to switches, either directly or by assignment of the switch to the package. All these switches are then, in turn, assigned to a Business Function and this is it. So we have first the Enhancement Package as an assembly of Business Functions:
Let us now drill down on a single Business Function:
You see every detail looks the way you are accustomed to from the weblog on the Industry Solutions. There is only one notable difference. The Business Functions belonging to an Industry Solution still need a Business Function Set as a unit they belong. In contrast, the Business Functions belonging to an Enhancement Package need not all comprising unit to organize them.
So there are less different levels you need to understand the hierarchy of objects involved in the switching of Business Functions in an Enhancement Package:
At the top of the hierarchy are the Business Functions. Each Business Function may be assigned to one or many switches. And a switch may be assigned to one or many Business Functions. Again the switchable elements are uniquely assigned to their switch. This applies both to the elements that are directly switchable and to those that are switched by their package.
Obviously the hierarchy is pretty the same as the one for the Industry Solutions that you have seen in the last weblog with the only notable difference that the top level is missing. The Business Functions in the Enhancement Packages do not need a Business Function Set to organize them.
By now you should have understood the basic facts about the Enhancement Package Strategy of SAP ERP 6.0: Its basic aim is to enable innovation without disruption. You can stay on one stable release and still get new functionality. The functionality comes in small, digestible pieces, called Business Functions.
You can choose which Business Functions you want to install, and which Business Functions you want to activate. The installation is separated from the activation. There are no functional changes or changes of existing UIs in the system before you activate the Business Functions you have installed.
The tools to enable the optional installation are the Maintenance Optimizer in the SAP Solution Manager and the well-known transaction SAINT in the application server ABAP. The optional activation is brought about by the Enhancement and Switch Framework.
All new functionality is encapsulated by switches. These switches control enhancements and other objects such as Dictionary appends by assignment to the package and other objects such as Dynpro elements directly. These switches are bundled in Business Functions. This way the user needs only care about business requirements. All the complexity is hidden by the Switch-Framework.
The central point of information about all the content an Enhancement Package is in the Service Market Place under the alias erp-ehp.