The future: Cloud

Unit4 has long been committed to developing its Cloud offering - but that's not to say that this development doesn’t benefit on-premise deployments as well.

 

By way of illustration, as far back as 2012 (release Version 13), Unit4 introduced support for internet printing protocol. This was an early step to moving away from the physical server.

 

Until this update, if you wanted to print from Financials, you had to hook your printer off the back of the server where the software was deployed. Now you can print to any printer in the world that has an IP address, just configure it up as a printer – it’s that easy.

 

In Version 14 (2017) Unit4 removed the desktop as well as desktop-based integration capabilities. At this time, the company also introduced multi-factor authentication with the Unit4 identity server. All the while improving feature function, delivering products, looking after the architecture, working towards the Continuous Release model, and building Cloud readiness.

 

At this time Unit4 also started assessing the existing integration capabilities. The problem was that many of these capabilities were not suitable for Cloud as they were based on tables on the desktop. Table link, for example, the batch input that ‘everybody’ uses, wouldn’t work in the Cloud. So Unit4 developed a Cloud integration for Table Link.

 

The company also introduced safer hashing algorithms. By evolving its thinking, Unit4 is delivering a product that is not just feature-rich but is also firmly focused on keeping users safe, current, and up-to-date with technology. This is an ongoing commitment for Unit4, with improved cost of ownership and REST APIs coming up, a step forward from the previous SOAP APIs.

 

Next Unit4 plans to look at Office 365 Web, because (as of publishing) you still must have a desktop add-in integration for Excel. The company is also looking at containerized deployment and so on.

 


2020 and the arrival of Continuous Release

“With our new architecture in place - and the old database and schema restrictions a thing of the past - we’ve got the ability to roll out new and improved functions very rapidly. So why not formally commit to doing this - frequently and regularly?”

 

From early 2020, Unit4 now releases Financials by Coda updates every three months. And given the sheer volume of new challenges finance departments have had to face over the last three years or so, the timing of this could hardly have been more relevant.

 


10 years ago

At about this time, Unit4 switched to EAR files (Enterprise Archive files) as a deployment methodology for the software. Starting with the web tier and then the application tier, the use of EARs meant deployment could be achieved much more rapidly.

 

This led to a reappraisal of the company’s software architecture (Why have we got separate tiers for both our software and servers - and how can this be rationalised?”)

 

The result was a new, single-tier structure, with the deployment of the software being the same whether it’s on-premises or cloud. This was yet another leap forward in terms of easier software deployment and upgrade.


15 years ago

How can we get new and potentially highly useful functionality into the hands of our customers faster? This was the perennial problem faced by enterprise software providers at the time, and Unit4 was one of the companies committed to optimising roll-out schedules.

 

The introduction of service packs facilitated quicker routes for delivery (far more efficient and less invasive than new version releases). Inroads were also made into a quicker and easier installation.


20+ years ago

At this time, Unit4 was releasing software versions for Coda (as it was then known) and its other enterprise offerings approximately every three years, with maintenance releases approximately every six months.

 

Responsiveness to customer needs was always a key part of the company’s ethos. As such, Unit4 was heavily invested in responding to what were known as SARs (special ad-hoc requests): a huge but important undertaking for the company’s maintenance and engineering teams.

 

As was the norm for enterprise software at the time, installation of Coda was a manual and heavily time-consuming process: a vast difference compared to today.