I don’t believe in the Cloud


There, I’ve said it. I know it’s a heretical view, but I’m no follower of fashion, whether sartorial, gastronomic, linguistic or professional.

the cloud

But it’s not a simple issue, and I will qualify my views very carefully.

I’m talking of course, of the IT Cloud, that somewhere-nowhere place where software and data are held for private or corporate use. I don’t doubt that it’s a safe, secure and cost-effective place, (and if it’s not yet those things, it could be). And I don’t doubt that when it comes to certain kinds of ‘utility’ applications – word processors, spreadsheets, simple databases, and so on – it makes it easier for people to share data and ideas. There are plenty of benefits when it comes to certain, limited, kinds of Cloud. My objections are confined to the Cloud as it’s promoted for business applications, a field I’ve worked in for more than 35 years.

Business applications are at the core of all medium-sized and large organisations all over the world. Without them things don’t get made, sales don’t happen, deliveries fail, customers become unhappy, profits don’t get calculated, and vital things don’t get bought or just don’t arrive in time. I’m not sure if they save on paper, but they save on labour, doing those repetitive, communicative and administrative things more accurately, consistently and rapidly than humans can ever do them. They reach out across the internet to enable us to order pizza from our living rooms, or buy tickets for flights from one continent to another. They touch are lives hundreds of times a day.

They are immensely complex. The largest of them, such as SAP or Oracle, contain millions of lines of computer code, and trillions of possibilities, and they’re developed by thousands of programmers over millions of man-days. The largest (and most expensive) of them also do absolutely everything that a company needs its business systems to do- from procurement and purchasing, engineering simulation, to distribution route-planning, payroll and career-planning.

The best of them are configurable and don’t need source-code modification to make them work well for a particular customer. Take Infor’s SunSystems, for example, a beautifully designed accounting system that is easily adapted for all sorts of purposes, or systems@work’s time@work, a professional services and expense management package that works for a wide variety of professional services organisations, from consulting and engineering, to law or oil and gas exploration. Neither system comes with source code, so ‘one size fits all’ and each organisation’s quirks are managed through configuration of the software’s parameters. My company – LLP Group – has worked enthusiastically with both of these products for more than twenty years. We love them, but except when life is very simple, I don’t seem them perching entirely comfortably on the Cloud.

The reality is that there is no core business system in the world that does all the mission-critical things that a company needs only through configuration (those vital things that enable it to be competitive). And there’s no core business software system in the world that does everything. There’s usually a need for the integration of several business systems –  time@work with SunSystems and Microsoft CRM, for example – to cover 95% of a company’s needs. Some of these systems, particularly those that bring a particular competitive advantage, may even have been written specifically for one company.

Integration is difficult to do in the Cloud. I take the Cloud, in this context, to be a place where a single instance of a business software system is installed and used by multiple organisations of different kinds – one software version, but configured differently for each organisation. That’s ‘cloud cuckoo’ Cloud in my experience, certainly if we’re considering those essential systems at the heart of a competitive business.

The Cloud is best when it offers either a peripheral function that isn’t mission-critical and is more or less standard across a wide variety of sectors (expense management, for example) , or a function that is essential but can be configured sufficiently to suit most organisations (CRM systems such as Salesforce, for example). But it’s no good for those idiosyncratic areas that make one company stand out from another or when an ambitious fashion-following IT or Operations Director says, ‘I want everything in the Cloud.’

I’ve seen Cloud implementations fail at the first hurdle, especially when it comes to the almost always necessary integration of multiple systems. Integration code is rarely usable by more than one organisation, and as soon as you need something special up there in the Cloud alongside the ‘one size fits all’ copies of your core business software, you’ve descended from the purest Cloud to something that’s merely ‘hosting’, because no one else can use the particular combination of software and integration code that’s been installed and developed for you.

And, even if you’re in the purest Cloud, you’re still vulnerable to what can seem like the arbitrary upgrade of the core software, which is entirely out of your control. Sadly, business software contains bugs, and most companies want to test very carefully before accepting a new version. In the purest Cloud you don’t have that option.

So, no, I don’t believe in the  Cloud. I love the idea that you don’t need your own IT department, that to others can be delegated the responsibility of procuring IT infrastructure, and of ensuring safety, security and performance. That’s hosting or the ‘private Cloud’. But when it comes to the mission-critical functions and very specific integrations on which your organisation depends – forget the Cloud in its most idealistic form.


SunSystems – To Be or Not To Be


At the recent Inforum conference in Paris (see Conferences) I was delighted to hear rumours on the grapevine that SunSystems is in the ascendant again in Infor’s firmament of software products.


SunSystems is the best mid-market accounting system in the world. Those of us who have been around long enough remember the SunSystems advertisements that borrowed the Carlsberg idea from the 1980s – Probably (crossed out) the best accounting system in the world. We all agreed.


It’s not as large a product or as broad a product, as SAP or Oracle, nor as powerful when it comes to sheer volume, but if you want globally consistent reporting in reasonable time, with low statutory risk wherever you’re operating, there is no better system. Its simple architecture – a single ledger, unlimited parallel ledgers for budgeting and accounting adjustments, its powerful multi currency and reporting currency capability, easy integration and, above all, its transaction analysis capability, are ideal in their flexibility, and the system can be configured easily as a core system for global roll out.

Consider the alternatives:

SAP Business 1 – a broader product and better looking, but not deep enough to squeeze through the statutory and corporate reporting hoops that SunSystems slips through more easily, wherever you are in the world.

Dynamics NAV – a fabulously flexible product (programmable, in reality) and applicable across a wide range of businesses, but its financial modules don’t come anywhere close to SunSystems’.

Dynamics AX – ditto. And AX is even bigger and more difficult to implement consistently.

Great Plains – a nice product for the Anglo Saxon world.

Of course, if you need manufacturing, or complex logistics functions, or retail, or any specialist ‘business’ functionality closely integrated with financial modules then you’ll probably put this first and buy a fully integrated system.

But, if you’re happy with best-of-breed solutions, for example if you’re running a hotel using Micros Opera, or a financial institution with highly-specialised, often bespoke, software for your front-office operations – then SunSystems is the best choice.

‘Cloud’ is all the rage these days, but I see no reason why SunSystems cannot be deployed in the cloud or in private hosting environments.

Infor’s CloudSuite has for the last few years received more marketing oomph from Infor than SunSystems, and there’s no doubt that CloudSuite offers broader functionality. But is it deeper? Can it as easily be designed for deployment anywhere, both in the relatively benign regimes of Anglo Saxon accounting and in the accounting jungles of Italy, Greece, Russia, Brazil and other more challenging accounting regimes, where you need to run the obstacle courses of negative debits and credits, provisional journal postings, correspondence accounting, cash-based VAT reporting, etc. SunSystems overcomes all of these – not always easily, but it can do it when many cannot.

The rumours I heard at Inforum are that Infor is beginning to recognise that SunSystems has some unique strengths, and that CloudSuite Financials isn’t going to be an easy ‘upgrade’ for current SunSystems users.

Long live SunSystems!

On Integration – Developing Software with Integration in Mind


I’ve posted two articles on the challenges of systems integration, firstly on the advantages and disadvantages of Best-of-Breed and Fully Integrated Solutions, and secondly on how to approach integration if you’ve chosen Best-of-Breed.

See Systems Integration and Reducing the Risks.

This post is concerned with how software should be developed if integration is anticipated.


You can think of it in this way:

Systems respond to EVENTS by executing software PROCESSES that update DATA.

In a single ‘fully integrated’ system the ‘complete’ response to an EVENT is contained entirely in one system and is reflected in one set of DATA. ‘Fully integrated’ systems can thus always ensure a complete response to an EVENT or no response, but are rarely left in an incomplete state resulting from partial processing. Typically, databases roll back incomplete PROCESSES, and all the consequent DATA changes, if there is a failure at any stage. It’s all or nothing, if you want it to be.

Integrating best-of-breed systems, working with more than one database, makes it more difficult to achieve this kind of integrity. The failure of a PROCESS in one system can’t easily trigger the roll-back of a PROCESS in the other.

Integrating separate systems requires therefore that you should easily be able to identify the success or failure of each part of a PROCESS and identify and control each set of DATA changes that each PROCESS effects.

For example, suppose you’re a company that distributes imported goods and you’re obsessive about calculating the margin you obtain on each product (this may be for good statutory tax reasons, or simply because you are unnaturally pedantic). The cost of the goods you sell is determined by the price you pay for them, the duties you pay on importing them and the cost of transporting them to your warehouse. You only know the true cost of each product once you’ve received the invoices that make up all of these costs. But, in the meantime, you may have shipped them.

Let’s consider an EVENT such as the arrival of an invoice for transportation. If the calculation of ‘actual’ costs is automated then your system must carry out the following PROCESSES:

  1. Invoice Registration: The invoice is booked against supplier, tax and cost accounts.
  2. Accrual Reversal: If an accrual for this cost has been made earlier it must be reversed.
  3. Stock Value Correction: The difference between accrued and actual transportation cost must be calculated and allocated against all the stock items it is related to.
  4. Cost of Goods Sold Correction: If there are items to which this difference in cost relates that have already been sold, then the appropriate portion of this difference must be allocated to a cost of goods sold account rather than to an inventory account.

Each step involves updating transaction tables, and if all these PROCESSES are occurring in a single integrated system then either they all succeed or they all fail, and the database either reflects a complete response to the EVENT or no response at all.

But if your finance system is separated from your manufacturing system then some of these PROCESSES must be carried out in one system and some in the other (and parts of some in both). It’s likely also that they will take place at different times (if there is ‘batch update’ of one system by the other rather than immediate update). It doesn’t matter for the moment which. In consequence it is possible that taken together the systems may reflect a partial response to an EVENT.

When developing systems that must be capable of handling partial failure in response to an EVENT the following approaches are wise:

  • Ideally there should be an explicit database table that identifies for each uniquely identifiable EVENT the PROCESSES that have been completed successfully and which are therefore fully reflected in the system’s database. Ideally such tables are present in the system that is sending and the system that is receiving. In reality, it is the state of the data that implies whether a PROCESS is complete, and it is rare to find an explicit table that records this separately, but it would certainly be useful. However the success of each PROCESS is recorded, the changes in data associated with each PROCESS should be easy to identify.
  • Transaction data that have been processed by an interface program must be marked as such.
  • All modifications to data that imply additional interface processes should be handled with a full audit trail. Ideally a modification to a transaction involves the insertion of both a reversal of the earlier transaction and a new transaction.
  • All transactions should have a field that identifies the order of events. Ideally this should be a date/time stamp. This enables execution of interfaces in the correct sequence, as well as the unwinding of PROCESSES if required.

If these safeguards are observed reconciliation and correction should not be too difficult.

System integration isn’t easy and there is no reason to believe it will get easier. There are still no standards for the description of data to which all system developers and integrators can refer. This is no surprise. Data are not objective objects which can be explored and described without reference to purpose, context and culture, and they never will be. They are not like the objects of material science; they are human artefacts.

Over the last decades I have witnessed a number of false dawns with regard to ‘easier integration’. These usually turn out to be useful advances in technology but rarely make functional integration any easier.

Two weeks ago I read an article on Data-centre Software in The Economist (Sept 19th 2015). That’s what made me think about integration issues. The article mentions Docker, a successful startup that’s making it easier and more efficient to move applications from one cloud to another. Laudable, clever technology, but, as far as I can tell, it represents no progress in the more difficult task of integrating business processes. Those of us who do such work can be assured of work for many decades to come.

There but for the Grace of God….

Perhaps a software designer should rejoice at the discomfort of his or her rivals (we all enjoy the thrills of schadenfreude from time to time), but I couldn’t help feeling that ‘there but for the Grace of God go I’ when I read this scathing account by Lucy Kellaway of her experience with Oracle’s iExpenses.

Doing Expenses is Truly Loathsome

She speaks for many when she writes:

There is something about doing expenses that has always been loathsome, even in the old days when all you had to do was fill in a few columns on a sheet of A4. There is the dispiriting matter of emptying pockets and handbags in search of missing receipts – as well as the existential uncertainty about what it is OK to claim for.

I remember seeing a survey saying that many office workers would rather scrub the company’s lavatories than do their expenses. I’d go further still. Not only would I rather scrub loos, I’d rather have a root canal.

Designing business software isn’t easy at all, and sometimes you strive with all the imagination you posses to design and build something that’s easy to use, and still end up creating a monster. Software designers are often people like me who’ve spent their careers programming software, or configuring other kinds of business software, generally for those forgiving kinds of people who work in accounting or other administrative departments. They’re nice people – and nerdy.

What we fear the most is ‘ordinary people’ or, worse still, ‘children’, who aren’t technical experts and rely on their instincts. They’re like the child who points out that the emperor had no clothes. And expenses software is the kind of software that ordinary people have to use.

But we must listen to ordinary people. If you’re a software designer you must let others help you with the graphical and logical design (what happens next when you click this or that button), and you must embrace that appalling moment when you put your software into the hands of someone who doesn’t know it at all, isn’t a software expert and isn’t someone predisposed to be kind to you, such a parent or a partner (perhaps your own children are the best candidates in this respect). You must watch what they do and force back the thought that they’re stupid or that it’s obvious what they ought to do. You have to be horribly humble, accept criticism and start again, if that’s what’s needed. It’s hard to bear.


I like to think that Lucy Kellaway would like our expense@work system more than she likes Oracle’s iExpense, and I’d welcome the opportunity to show it to her. But if you’re afraid of a journalist, think of the 650 MPs who use expense@work for their Parliamentary expenses in the UK. A more demanding and terrifying set of users you cannot imagine, but they seem to put up with it, more or less (well, they have to!).