Industry connections and an emphasis on experience make Staffordshire University graduates among the most employable in the UK. A leading university for digital technologies, it is always building on its proud computing heritage and strong reputation for computer games courses.
How appropriate, then, that the forward-thinking finance team at the university are connecting with the digital cloud world and moving to Oracle Fusion with the assistance and direction from trusted advisors, Namos Solutions, a leading Systems Integrator and Managed Service provider of Oracle E-Business Suite and Oracle Cloud Applications. Keen to get on board with modern best practices and data-driven intelligence built into the Oracle cloud applications, the Finance team firmly embrace the concept of achieving a modern and sustainable campus.
So, what makes an Oracle Fusion implementation different to an on-premises implementation, what are the challenges that this presents, and how have the project team met those challenges and ultimately mastered them?
Data migration
Let’s start with data migration. Gone are the days of developing custom code to transform and load data into the appropriate interface tables or directly calling Applications Programming Interfaces (APIs) to load data into all the appropriate fields in the Oracle database. In Fusion, Oracle provides a set of custom File Based Data Interface (FBDI) Excel templates for most of the data objects you need to load. You simply fill in the appropriate fields in the template, click the button provided in the template and the data gets neatly zipped up on your computer. You then select the appropriate load program in the Fusion Enterprise Scheduler, select the file you just zipped and, ‘hey presto’, the data gets loaded in to the Oracle tables and a nice html load report pops out for you to review.
Sounds simple enough but – and there are a few buts – all is not entirely as it seems. Staffordshire University currently runs Oracle E-Business Suite R12. The Finance team are very adept at using the Excel-for-Apps query tool to extract data from the R12 system and also know their data really well. The challenge comes when trying to match the fields in the FBDI templates to those in the source system.
In Fusion, Oracle provides a set of custom File Based Data Interface (FBDI) Excel templates for most of the data objects you need to load.
If your source system is Oracle R12, it would have been good to have a mapping provided by Oracle to go from R12 data to Fusion data, but no such luck. Luckily, the Finance team were quickly able to identify all of the relevant fields in R12 for the supplier loads, all named slightly differently but still a pretty good match.
During the first data migration cycle, supplier data was loaded with a success rate of over 99%. All well and good, but the news is different with regard to the customer data load.
For loading customer data, there are two templates, one for Organisations and one for Persons. Organisations is a five-tab template, so not too bad, but the Persons template has 19 tabs. And guess what? The majority of ‘customers’ in a university system are students so are, therefore, of type Person. The issue is that, in order to load all of the relevant connected data for a single customer (for example, profiles, locations, party sites, profiles, contacts, etc), each of those data objects is on a separate tab of the template and needs the relevant references and IDs in the correct field on each tab to link back to the data on the other tabs for the same customer. If any one of the reference fields that link the data together is not correct, the data will either not load at all or will only partially load. To produce the relevant load template for around 3,000 students in the current data set has been a labour of love, with many long hours and weekend working to get it all synched up.
For those requiring such a migration, make sure that there is enough time in the plan to accommodate this work.
There is no short-cut and it consumes resources very quickly. The university team have had quite enough of filling in a cross-referenced 19-tab spreadsheet and won’t be sorry when the production load is complete, and they don’t have to look at it ever again!
The other data migration challenge is that there’s not an FBDI template for every data object.
Data object challenge
The other data migration challenge is that there’s not an FBDI template for every data object. For Employees, for example, there is an Oracle ADF Desktop Integration (ADFdi) Excel template that needs to be downloaded from the Fusion server. The load process is like FBDI, but the ADFdi template allows you to upload the data into the appropriate interface tables and then automatically kicks off the import job to load the data into the base tables. It works fine after a bit of massaging and data formatting, but it would be good to see some consistency here and have the same process for all data objects.
So, Staffordshire University has found that data migration is different in Fusion, but what else? Let’s talk about integration with other systems and building interfaces to Fusion. There is a similar message to the data migration one here, in that gone are the days of building lookup tables in the Oracle database and writing custom code that sits on the Oracle server. None of that is available now.
The integration approach adopted by Staffordshire University and Namos is to work with a third-party provider, Justransform. Justransform has built its own integration platform which is deployed on Oracle Cloud Platform as a Service (PaaS) and provides prebuilt connectivity to all the Oracle Fusion APIs.
This takes away the dependency on a diverse technical development team which suits both the university and Namos very well.
The concept is that you provide a file format to Justransform, together with a mapping to the Oracle APIs you wish to use to accomplish the interface task you are performing, and Justransform will build the necessary mappings and make the API calls within its platform. For interfaces inbound to Fusion, you get to the source system to deposit a file using sftp or https post to the Justransform outbox directory and the Justransform processes will make the appropriate calls to get the data into Fusion. For interfaces which are outbound from Fusion, you provide Justransform with a BI Publisher SQL-based report to pick the relevant data and Justransform will run the report to extract the data from Universal Content Manager, gather the data in the correct format and deposit it in the Justransform inbox for the target system to collect it from there.
The integration approach adopted by Staffordshire University and Namos is to work with a third-party provider, Justransform.
In addition to the pick and go formatting piece, Justransform can transform and derive data on the fly to provide the complete data set required for a successful interface.
For example, on the Staffordshire University Fusion project, the Finance team have subtly changed their chart of accounts to include a new department code segment. None of the source systems has this department code available, but there is a known one-to-one mapping from one of the other account segments which the source systems do have available. Therefore, when creating invoices in Fusion from the source systems, for example, by using a lookup table stored on the Justransform platform, the correct new eight-segment account code combination can be derived prior to making the appropriate API calls to create the invoice in Fusion. So, no changes are required to the source systems to accommodate the new account code segment and this has significantly reduced the project costs in terms of development and testing time.
So, the upside is no need for technical development, but it does mean that the functional team need to be very familiar with the Fusion APIs. The functional team also need to have some API testing skills. Namos has been able to call upon consultants who are skilled in the use of SoapUI, which is the tool selected to test the API calls.
The university’s current R12 system has 18 existing interfaces and, after review, 17 of these have had to be recreated in some shape or form to allow Fusion to function the way that the Finance team want it to. Not all of the new interfaces are lift and shift, as the Finance team have reviewed their processes and have changed them to take advantage of some modern efficiencies. Also, for one interface in particular, the processing which was built in R12 to extract recurring invoices for onward transmission is not repeatable in Fusion.
The Namos team worked to understand the actual requirement for this interface and have designed a new more streamlined process which does the job in Fusion.
The university’s current R12 system has 18 existing interfaces and, after review, 17 of these have had to be recreated in some shape or form to allow Fusion to function the way that the Finance team want it to.
So, interfacing to and from Fusion is a different challenge to that in R12, but it is certainly not insurmountable. In fact, by introducing a pre-built platform such as Justransform, you could say it has become much simpler due to the reduced dependency on technical build teams. But does it all work? We’ll have to get the end of the Systems Integration Testing to be sure of that.
The final Fusion challenge that had to be mastered is how the project timetable needs to be scheduled around Oracle’s quarterly release updates. In Fusion world, you don’t get to choose when you apply the latest quarterly patchset to your environments. The dates for the updates are determined in the contract you sign when you purchase the Fusion product.
Each quarter, the development environment(s) in your Point of Delivery (POD) will be upgraded a week before your production environment is upgraded.
I understand that in some exceptional circumstances the upgrade may be delayed slightly on request, but only by the matter of a week or so.
The good news is that the university will always be on Oracle’s latest patchset. Therefore, any calls to Oracle Support won’t lead to a lengthy patching exercise to get to the latest patchset, as has sometimes been the case in the past.
The downside is that the cutover plan and User Acceptance Testing (UAT) now need to take those quarterly releases into consideration. So, for example, how inconvenient would it be if the gap between the start of your UAT testing and your go-live date was more than three months. So, you carried out your UAT testing on a particular version of Fusion and then, prior to go-live, you get a quarterly patch release applied to your production environment which you hadn’t tested.
At Staffordshire University, the project timetable has been specifically engineered to ensure that the Fusion system will go live in 2019 on the same code base as was tested in UAT.
You are, therefore, going live on a different patchset from the one that you tested in UAT. I’m not sure too many businesses would be happy to take that risk!
At Staffordshire University, the project timetable has been specifically engineered to ensure that the Fusion system will go live in 2019 on the same code base as was tested in UAT.
That is a big tick in the box for any audit team keeping an eye on process as well as reducing the business risk.
Once the next Fusion release gets applied shortly after go-live, Namos will still be on-site providing hyper-care and so will be able to quickly deal with any issues that arise, working closely with Finance and Digital Services to resolve those.
So, have Namos and the university Finance and Digital Services teams fully ‘mastered’ the cloud yet? That remains to be seen, and probably not until go-live. I think it would be fair to say that the teams have mastered some elements of the cloud so far, but I am sure there are further challenges just around the corner. Given progress to-date, there is every reason to suggest that those future challenges will be met and mastered in their own good time. Stay tuned for the next instalment, which will cover those next achievements.