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.


Why Consultants Love SunSystems


There was a time, many years ago, when the future of SunSystems was uncertain, though everything looked wonderfully rosy at the time. Systems Union, the British company who developed the product, was still in friendly private hands, and sales were booming. SunSystems was the best (as it still is) international financial software system on the planet. Those of us whose lives depended on the product were prospering. Actually, Systems Union’s  P&L looked good. The problem, the company’s balance sheet, was probably one of inattention. The sails were billowing, the sun was shining. They just didn’t notice the rocks beneath the surface.

Resellers such as our company (LLP Group) enjoyed unusually comfortable payment terms and Systems Union’s dunning style was gentle and ineffective. It was a cosy, successful, touchy-feely company and we were all one happy family. They even took all of their employees on expensive foreign holidays, and, on one occasion, some of us resellers too.

They had also embarked on huge enhancements to SunSystems, both functional and technical. GUIs were new and improving rapidly (yes, we’re talking about many, many, years ago) and COBOL, which they were using them, was an impediment to some of this. All these development projects were late and ever more expensive programmers were being thrown into the development den.

And then there came huge devaluations in Asian currencies and debtor and cash values at Systems Union’s successful Hong Kong offshoot had to be revalued down. All in all, the balance sheet didn’t look good, however bright the operating profit.

So, many resellers looked for lifelines, just in case. We looked at SAP R3. As it turned out, this was an expensive and very instructive mistake.

barbie and ken

It would be wrong to suggest that I had thought of SunSystems as a toy. Its simple and elegant building blocks come in a relatively small kit, but, just as with Lego, you can build nearly everything with them. But I had certainly thought of SAP R3 as a ‘grown up’ product, and just as when we’re young we dream (foolishly) of getting ‘grown-up’ versions of toy cars, toy guns and Barbie dolls (or Ken), so I had assumed that our consultants would enjoy the upgrade to SAP R3, a chance to become adult in the ERP consulting world.

SAP was then trying (it still is, perhaps) to come down in the world by selling to mid-sized companies rather than only to the largest ones, so they leapt at the opportunity to work with a company such as ours who knew how do deliver projects in under hundreds and thousands of days.

So we sent out best SunSystems consultants on SAP R3 courses. This one would learn about the inventory control module, this one about the sales module, that one about the asset register, and so on. And therein lay the problem and the reason why our consultants, unexpectedly, hated the whole experience.

Their worlds shrank, and their horizons shortened.

The wonderful thing about working with SunSystems is that you can know the whole product, understand the whole of the company you’re working for, and design a complete solution. You can see from one end of an organisation to the other, from sales discount policy to the resulting debits and credits, and the management reports that international managers need. This wasn’t the case with SAP R3. You just couldn’t know everything.

And the style of the product turned out to be different too. It may be an imprecise analogy, but if SunSystems is like Lego, a small number of small components from which you can build just about anything, SAP R3 is more like a vast array of very large fixed-purpose machines that you have to put together, joining up all the wires and cogs and panels, unsure if they really fit together. The consultant who knows this machine, doesn’t know the others.

Those of us who work with SunSystems love its simplicity and the infinite possibilities that follow from it. Consultants can use their imagination to configure what the customer needs, albeit sometimes with workarounds (equally necessary in SAP R3 I believe). There’s no coding to do, unlike with SAP R3, and in any case coding isn’t possible.

Customers love it too. In some cases they’ve even ‘downgraded’ from SAP to SunSystems. In other cases, when they’ve grown and ‘grown up’ into SAP R3 they express nostalgia for the flexibility and relatively low cost of ownership of SunSystems.

SunSystems is an ideal consulting product. If you’re proficient in it it’s like a musical instrument on which you can play any tune. I’m happy to say that all of those SAP R3 consultants we thrust into adulthood are back in the SunSystems world, and all the happier for it.

See LLP International.

And when I came to design our own products – time@work for professional services management, and expense@work for expense management – I took inspiration from SunSystems and not SAP. I designed it as a set of building blocks, like Lego.

SunSystems and Manufacturing – A Transylvanian Tale


Imagine Transylvania in 1997, a part of Romania still largely populated by vampires and werewolves. It’s a place that’s bitterly cold in winter, scorching hot in summer, and most terrible of all, it was then a dark corner of the world where accounting was done largely on paper by huge armies of accountants, and a place where manufacturing planning systems were entirely unknown.

Welcome to my accounting department….


Imagine, also, that South African Breweries (SAB), a newly acquisitive international brewer, had acquired Ursus, in Cluj Napoca, one of Romania’s best-known breweries.


Acquisitions at any time, and in any place, are a cultural nightmare, but international acquisitions are the most difficult, especially in emerging markets. The nominal cost might be attractive, but the challenge can be almost unmanageable.

The first step in any acquisition is to establish reliable financial systems, but the brewery’s army of accountants couldn’t tell SAB what they really wanted to know about Ursus, at least not in a timely, GAAP-compliant way.

What they really needed was a flexible financial system that could meet Romanian statutory requirements and report intelligibly to their South African headquarters. Given that SAB manufactures beer, a large system such as SAP or Oracle might be the obvious choice because they do manufacturing, sales, purchasing and distribution as well as accounting. But there wasn’t a hope in hell, nor in Transylvania, of implementing such complexity. And local financial software systems were fit only for the undead nature of Romanian statutory accounting, not for the sophistications of GAAP reporting.

So we, LLP Group, and our recently formed subsidiary in Bucharest got the job of implementing Infor’s SunSystems and of making it work in a manufacturing environment.

Manufacturing accounting is all about calculating the cost of finished goods. A finished item, such as a labelled bottle of beer, comprises packaging  and content. Content, in turn, comprises this and that – water, sugar, yeast and whatever else goes into a bottle of beer. There’s a bill of materials that describes the component parts of every item, and the cost of labour and machinery involved in producing it. Most companies calculate a ‘standard cost’ for each item and component based on estimated costs of components and labour, and in many countries it’s perfectly permissible to value stock on the basis of standard costs, as long as the actual costs vary within reasonable limits.

But not so in Transylvania. The law demands that ‘actual’ costs be calculated, or the next best thing, a rolling average of actual costs. You can do this in SunSystems, using a T-code for each finished or semi-finished product, crediting a production account with all the products that come out of the production process at standard cost, debiting all the materials and labour consumed at standard costs. Purchase price variances, and manufacturing variances emerge, that must then be allocated against materials consumed at the next higher level in the bill of materials, and materials still unused.  It’s an intricate calculation, and one that even manufacturing systems didn’t do well in the 1990s, but to do it in SunSystems takes more courage that knocking on the door of Dracula’s castle.

It helps, of course, if the number of finished and semi-finished products is few, and in the end the packaging materials were more complicated than the beer itself. It helps, too, if you know manufacturing systems, and we used Fourth Shift, a small but powerful manufacturing system, solely for the definition of bills of materials and the calculation of standard costs. It doesn’t help, though, if inflation is running rampant and you have to recalculate your standard costs several times a year.

But we made it work, or rather my colleague Jiri Stiller, now manager of all of LLP Group’s operations in Central and Eastern Europe, did it, spending a year in Romania, in Cluj Napoca and Bucharest. He wore garlic next to the skin and never went out after dark, but as far as I can tell, his blood is still human and he’s very much alive.

SAB used SunSystems for many years, but eventually moved to their standard software system – SAP. Romania has changed too, and Cluj Napoca is now a pleasant, modern, easy city, where you needn’t fear vampires nor accountants.

SunSystems is a wonderfully well-designed financial system. Its unified ledger and transaction analysis concept makes it one of the most flexible and versatile in the world. It can do almost anything, even in Transylvania.

NOT Jiri Stiller – at least not during the day.




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.