There are three main types of changes to BlueWorx that the Accenture BlueWorx Product Team will provide:

  • Support Packs - Support Packs (SP's) are cumulative so the first installed is effectively the customers base release. SP's contain all changes from previous SP's - i.e. you can skip SP's and apply a later one and it will contain all changes included in previous releases. These changes can be consequential in nature and, depending on the degree of change since last application update, can result in the following:
    • Review and change of affected processes and BlueWorx configuration options
    • Review and reapplication of Customer Enhancements
    • Full unit and end to end testing
    • Change Management communication with end users
    • Redeployment of the application to end users (for example if new Add Ins or Libraries are included)
  • Bug Fixes - Bug Fixes are specific to out of SP releases and must be applied as either a transport containing specific cumulative fixes or instructions for the repair of standard BlueWorx (Soltius) SAP Classes/ Tables or Neptune Applications. On later application of SP's, which will contain cumulative bug fixes and new features, any changes can then be reset to to standard.
  • Manual Config - These are non code related changes which relate to changes to be made to BlueWorx config or BlueWorx related SAP config.

Details of these changes are provided in the section BlueWorx Releases (access restrictions apply).

Customer Enhancements and Impacts

Customers can maintain their own enhancements to the SAP back end logic via Classes and front end logic and visuals via the Neptune Application Designer. Such enhancements have a good degree of isolated from the BlueWorx updates, meaning that BlueWorx updates will not overwrite the customers updates. However BlueWorx product changes can impact on customer enhancements, the degree of impact depends on what has been changed. The BlueWorx Product Team will highlight in the release notes the changes and then the customer and partners should assess the appropriate impact and planning for implementation. 

As with any changes to standard software, we advocate good and proper review and control of changes, based on justifiable business reasons and with the understanding that any changes to standard creates technical debt. 

How the Process Works

Accenture's Product Development Team provides the standard product in cumulative support packs and, at internals, bug fixes. Customers can choose to apply bug fixes, if they are critical or wait for support packs. Regardless of the intent to change we strongly advocate (and detail further in our implementation guide) the use of Neptune enhancement applications linked to customer classes referencing the BlueWorx provided class/es. Any changes made to standard are therefore isolated to these amended classes and, except for repairs, not to the source class. This keeps, as much as we are able, a clear understanding on what's been changed. The following diagram summarises how this process works:

Using this same concept, some BlueWorx customers choose to provide slightly different application versions to different user groups. For example one group of users might get simplified notification screens, no materials, etc, while another group gets to see everything.

Multiple Development Streams

If you have multiple BlueWorx development enhancement streams underway then you may wish to separate these so that your developers are working independently and so that they disrupt the core application as little as possible during the development process. Here is a concept of how to achieve this:

Developers use separate temporary classes and applications to ensure separation and management of changes. This approach also means that the support for the application is productive use is disrupted as little as possible. With multiple developers you still need to be mindful that you are working with a snapshot. The limitation of this approach is that it can not apply to SAP DDIC objects whose change is immediate.