As others have said within this community and across the wider tech industry, Cloud is no longer on the horizon, whether you are looking at Infrastructure, Platform or Software as a Service (I/P/SaaS), it’s here, it’s real and it’s embedded.
In a previous TRAG blog, https://www.heug.org/p/bl/ar/blogaid=3986, we looked at some planning and project considerations for a SaaS implementation and now we will continue the theme with a look at some high level technical considerations, again with the focus on SaaS. This will be followed up by more specific technical issues in a later blog, so please keep a weather eye out for that.
We’ve tried to make these considerations as vendor agnostic as possible but have taken some specific examples from implementations of the Oracle Financials Cloud product at the University of Derby as well as the Oracle CX Cloud Suite at the University of South Australia. The intention being that you are able to apply this kind of thinking and experience to any SaaS implementation at your own institution.
Right from the off, procurement is likely to be substantially different to the process for an on premise solution. With a solution like PeopleSoft, you buy an off-the-shelf product but have the ability to customise it to meet 100% of your business requirements. With SaaS you are buying into adopting best practice – and for HCM and Finance, that is across other industries, not just Higher Ed. The focus of procurement should therefore be to gain as much insight as possible into the product and assess how it might impact your current business processes. It’s highly likely that a simple two hour demo will not provide enough of the necessary insight.
Migrating your legacy data is a very large and difficult part of a SaaS migration. Scoping what data you need is one part of the equation, the other being do you need to store any remaining legacy data for compliance/reporting purposes?
Data Migration in itself is a complex and difficult process. Oracle tend to load data with a File Based Data Import file (FBDI) which is a series of excel spreadsheets mapped to underlying tables. The high level process is therefore to scope the data you need, identify where the data sits in your current database and create csv files matching the columns in the FBDI file. In addition you may need to map values from old to new, e.g. new account coding for a Finance implementation. Finally, there is the load of data into the SaaS system which you can perform yourself or pay for Oracle to do.
Data loads will take several iterations and each of these should see an increasing success rate for the data imported. It is very important for your line of business to review the imported data for consistency at each iteration to check direction of travel.
In a SaaS world, the environments and releases are managed by your vendor. The vendors are going to be using DevOps practices to provide regular releases on a rapid cadence. This will impact how you manage change. You are on the vendor’s schedule which may sound daunting but does have advantages in terms of more regular functionality improvements. In addition, all customers move together meaning any unforeseen bugs are likely to be addressed very quickly.
This regular release cadence means you must have a robust testing strategy and this should involve automation if at all possible. You may decide to focus only on a “top 10” business critical business processes rather than try and keep up with testing the entire suite. Another option would be to invest in change impact analysis and focus testing efforts accordingly.
When applying change, the start point should probably be a live-like environment with the current code line, configuration and data in place. This means requesting a Live to Test refresh and because of the ever growing number of customers on the product, you need to be on top of your refresh request schedule. Oracle are open to requests 6 weeks in advance of a refresh so there’s some diary management required.
Another thing to note is that for Oracle releases are quarterly but there are monthly bug fixes available. If you need to take one of these then you continue with the monthly release cadence until the next quarterly update at which point you can revert to quarterly only.
Whilst you can extend a SaaS product with PaaS, within the SaaS product itself, you can’t customise the code line. Configuration to some extent becomes the new code. Configuration is how you tailor the product to your particular needs. You should strive to configure in as standard a way as possible to avoid “configuring yourself into a corner”. Configuration Management takes on new meaning – your path to Live, how you test configuration changes and your process to make them live. Then there is communication of changes to users and training for any major changes.
Oracle do provide update safe “flex-fields” to allow you input, validate, store and view data specific to your implementation. Again consideration should be given to any data migration, testing and training impacts.
So there’s a lot going on from early procurement, right the way through to go-live and beyond. The likelihood is that you will decide to go with an implementation partner and it is crucial they have an understanding of your current eco-system/HE as well as being highly preferable if they are skilled in your current product set. This is particularly important if you need to engage a partner for data migration and/or integrations. Your partner should have strong and deep knowledge of your legacy product, otherwise you face significant effort with data migration and integration.
A good partner will also be able to offer advice on best practice, industry standard configuration and where it is sensible to tailor the product. They should also be robust in challenging you to update business processes to allow adoption of best practice. They should also be capable of assisting with your ongoing strategy for managing SaaS products, especially if this is the first move for your institution.
In closing, there are many benefits to be realized from the Cloud but any migration to SaaS needs careful thought and change management within the institution. In the next blog on this topic we’ll take a look at more detailed implementation considerations such as email delivery - Sender Policy Framework (SPF)/ DomainKeys Identified Mail (DKIM) entries/Domain-based Message Authentication, Reporting and Conformance (DMARC), single sign-on, TLS and sub-domains.