Could we re-engineer enterprise software to feel like consumer apps?

I remember the moment I was first told about apps on a mobile phone. What was a ‘mobile’ app? I soon learnt that apps excel at doing a particular task and who now can live without them (or their mobile)? As individuals, we take it for granted that if we don’t like one consumer app, we simply delete it and find another. We can do so because it’s easy to delete an app (at worst, we have to cancel a subscription) and signing up for a new app is equally easy (and often doesn’t cost anything). Consumer apps work on a standalone basis and rarely need to connect to other apps. We also don’t typically need to port data from the deleted app to the new app (although of course there’s an app to transfer my playlists from Spotify to Apple Music if I ever needed it).

Apps aren’t restricted to individuals. Businesses get it on the act too. Don’t like Webex? Cancel your subscription and open an account with Zoom instead (and save 15 minutes every time you want to host a group video meeting). Some of these apps (e.g. secure password storage and sharing app Lastpass) come with team or enterprise features, enabling administrators to control user accounts.

Apps are designed to provide the easiest possible journey to maximise adoption and ease of use. It’s a shame therefore that enterprise applications aren’t more app-like. Enterprise applications are deliberately designed by software vendors to be the very opposite, making it as hard as possible for you to change, for their own commercial advantage. Disincentives are created by;

• Up-front fees; enterprise software can cost millions in up-front capital expenditure (you didn’t believe them when they said the 2 year sales cycle was free of charge did you?)
• No try before you buy: sorry, they can’t let you experience how bad the software really is so they’ll tick every box in your RFP and tell you what you want to hear instead
• Ongoing licence costs: everyone is forced to pay for 100% of the roadmap changes that the software vendor deems are important even if 90% of their clients don’t need it
• High operating costs: Poor interfaces make not only for extensive training manuals at employee induction week but create hidden costs with every forced, unnecessary mouse click.
• Locking you in: If you haven’t already been crippled financially at contract signing, you will be when you realise absolutely nothing of any practical use comes out the box and that you’re dependent on the software vendor or their consulting friends to create the bespoke processes you need. You have no option but to code your intellectual property (IP), i.e your business processes inside their software which you can’t then take away with you.
• Committing you long-term: Multi-year contracts mean software vendors get a high valuation by guaranteeing to their shareholders that you’re the one that’s financially on the hook

The Total Cost of Owning Software

Heavy, unwieldy applications that cannot easily be changed create high IT costs (because nothing can be configured by the business) both in the form of Initial Cost of Ownership (ICO) and ongoing maintenance costs (TCO). But it’s not just the software cost. It’s about the cost of the people you need to employ because your legacy system is designed for inside-out businesses where your employee is still the workflow (instead of the customer (outside-in) or the machine). The tens, if not hundreds of millions spent by every enterprise each year on people is their Total Cost of Owning Software (TCOS) and the numbers are frightening.

Once you’re trapped, you’re trapped. Someone up the chain has bet the house, so once the business starts getting burnt, they’d rather the whole house burn down than admit the size of this mistake to the board. Better instead to wait 7–10 years and then safely say that your legacy system is no longer supported and you need to start replacing it. They can keep their job. Then they’ll repeat the same mistake all over again. There’ll be no shortage of software vendors and consultants rubbing their hands in glee. You succumb to the inevitable and brace yourself for another unfulfilling enterprise IT cycle. Legacy is like a lazy, fat dinosaur and it made you a slow-moving, sad sloth.

The power of abstracting enterprise software

But you say, what choice do I have? For those of you wanting to break free from legacy hell, I’m going to let you in on a secret. Abstraction. Remember that word, it’s one of the most important words you’ll ever need to know. I’m also going to let you in on a second secret. Thinking in terms of layers. Layer is the second most important word you need to know.

Ever thought about how your enterprise applications are jack-of-all-trades and master of none? Each enterprise app is like a box. Each box is;

• Heavy: it contains all your data, your processes, your rules, your application features.
• For your use only: Not that you’d want to, but it’s hard to share the box in case your customers or partners ever asked for a peak.
• All jumbled up: You can’t see what’s in the box — only someone in IT can get to the bottom of it.
• Closed: It’s real hard to get anything else in the box
• Difficult to move: Your box is probably stored inside the business (on-premise) and being a heavy box is hard to move anywhere else (like cloud).

Thinking in terms of layers

Let’s start thinking in terms of layers starting with the physical layer. This is where you store your box. Everyone is pretty cool nowadays about defaulting to storing stuff in the cloud (i.e. anywhere but your place) because tools like AWS are fundamentally better and more secure than you could ever do yourself. But hosting all your applications and data on AWS servers is still very expensive because you’re taking up a whole lot of space that you need constant access to. So why limit yourself at abstracting the box from your place to someone else’s? Go one step further and abstract some more. What if you only used their room when you needed it, so that you didn’t need the space all the time after all? Welcome to serverless architecture. Cloud just joined the sharing economy. I’m loving it.

The data layer. This layer is the most important but is also hidden. Even though it’s the most important layer, it’s the one you think about the least. You’ve focussed on what you can see, and therefore been prioritising application features (that frankly don’t move the needle). The question you have been asking until now is where the data is hosted. Software vendors (including modern SaaS applications) tell you what you want to hear. That you can choose between multi-tenant in the cloud or if you hold sensitive data can have a dedicated instance (on-premise or in the cloud). Nothing like an obvious binary choice to lull you into a bad decision and false sense of security. They tell you that you own your data. Technically they aren’t lying, but as you have zero control over it, can you really have ownership over something you can’t control? Your data is stored in a database model that your software vendor designed. Being a proprietary database model you probably can’t take a real good look at it, you probably can’t modify it and you certainly can’t import the rest of your data into it. That’s why, if you’re lucky, you’re thrown a bone and are told you can spend time taking your data out (and you’re supposed to be grateful to your existing vendor for this?). This explains why you have had to pay a whole lot of money on top of your core enterprise software to develop a data warehouse you control where you can re-structure the data and combine it with other data sources and use as you wish.

What’s the alternative? Why not take back control, go one step further and abstract the data right out of their application. Not sure what I mean? Develop the data equivalent of a single purpose app in the form of a logical data model, host it in the cloud and then have any application that wants to interact with your database do so via a database integration later. With all your data in one place it can talk to any other application. And whilst you’re at it, be sure to abstract the database integration layer that talks to that data from the data itself. That way if you want to swap one of those databases from say SQL to Postgres you can (without spending any money re-writing the queries you wrote to talk to the data). It’s abstraction that gives you control and therefore ownership.

Next layer up; your business process. This is where most of your intellectual property (IP) is held. Perhaps you have modelled your business process flow in an office productivity tool to visualise how work flows from start to finish. Processes consist of Tasks (fulfilled by a person or by a machine) and tasks consist of Data. Decisions (or rules) are applied against data. These tools aid with visual understanding but can’t orchestrate the process in the live environment. But don’t worry, your software vendor has assured you that your IP is contained within your instance of their system so you definitely own it. Only you don’t. Because again you don’t control it. And it’s messier than data. Your IT department takes your business process logic and retrofits it into a pretty dumb box that hasn’t been designed to support life’s complexities. So your IT team make valiant attempts at coding around this. It’s impossible however for anyone other than Brian in IT to see what’s going on. It’s also hard to change, and when you do something else inevitably break elsewhere. It’s impossible to re-use so you do the application code equivalent of copy/paste all over the place (rest in paste, Larry Tesler). As for your software vendor, they conveniently forgot to tell you that you can’t export any of your valuable IP to another application. Why would they, when their only interest is you keeping you (down)?

Abstract by design

So what’s the alternative? Our friend abstraction. Why not abstract the process logic, the process logic from the task logic, and the decision logic? Each can sit in a single purpose app. By documenting these in line with industry standards such as BPMN2.0 (for business processes) or DMN1.0 for (for business decisions), this business logic can be made visible to all, not just IT. It’s like having your very own internal Wikipedia. Everyone can contribute and make change happen. However, without real modelling skills you could just end up with big heavy processes or decisions models that whilst abstracted are too heavy and complicated to be understood. Again, abstracting one step further is key. Processes should be approached so as to be small enough to be a micro-service of their own (a very little re-usable box), which can be used like lego.

No doubt at this stage, some naysayer in your business says your company doesn’t have the skills so your team isn’t capable. I agree, but disagree. Don’t listen to them. They can hide/bury this complexity in code which you can’t open or see but there’s no getting away from the fact that it exists. So wouldn’t it be better to man-up and instead of investing more energy in legacy for so little value, invest in people instead, acquire the required skills in-house and free up your business potential? Breaking processes down into lego-sized chunks actually makes the re-skilling process easier anyhow.

Abstracting the process logic, rules logic and task logic into re-usable functionality means that you can swap boxes (or lego) in and out as you need. Approached in a standards-based way also means you can ‘export’ these little boxes of intellectual property to any other app supporting the standard. This is definitely going to make your enterprise software vendor sweat at the next renewal :-). Good.

Next layer up is your application layer. At this point your software vendor is in trouble. You’ve abstracted out the process, the data and the rules. But your software vendor still has a few tricks left. Their application has a user interface (UI) that your staff will use to either access the data (views) or interact with the data (tasks). Views are easy to abstract into your own app if you have abstracted the data out. Your basic needs are (let’s face it) basic and no different to anyone else in the world. You need an ability to search, filter and sort, see lists, drill down into an individual record and then see data presently neatly. Nothing complex there, but having freed your data you could actually (finally) create a view that has all the data you need in one place rather than having to go into multiple systems because your data is siloed :-). There are any number of vanilla Content Management apps (CMS) that could be pointed to your database to render both data and documents. Tasks aren’t much more complicated either, they’re simply data capture mechanisms that can be modelled in a single purpose app (form technology) and exposed in your CMS. The real leverage your legacy system has is that they support industry specific features. If you are an insurer creating a policy or processing a claim you’ll need insurance-specific functionality to calculate the price of that policy or calculate the value of that claim. When you see a sector-specific vendor solution you might think that there are too many of these functions for your domain to be able to use something vanilla. Why not phone a friend? I have abstraction’s phone number. He’ll advise you that you simply need to abstract these functions out into a set of smaller, neater applications. Stop thinking of applications as one big box that can’t be changed. Think in terms of smaller apps that could then be re-used elsewhere, such as embedding them in other apps! It’s the equivalent of tailor-making a perfect holiday where you are in full control and the wind is passing through your hair, as opposed to going on a package holiday where all get is Delhi-belly.

Hail the platform

The next layer (and final one for this article) is the integration layer. Closed applications (legacy and modern) are starting to open themselves up. But vendors didn’t reckon on getting a killer blow with the rise of platforms and eco-systems. So they will try and add boxes around their big box, call it a marketplace or eco-system and make you think they’re giving you what you need. Hopefully by now, you can see the fatal flaw in creating more boxes around a big box :-)). Until now (and you are going to really kick yourself when you this sinks in), you have already been busy adding lots of small boxes around your big box legacy system. Surprise, surprise that your enterprise software vendor has proposed a solution that brings about no real change. Plus ca change, plus la meme vie.

Meanwhile, your IT team was once a little baby but has now grown big and strong. He’s no longer asking for pocket money, and is being seriously bullied by the software vendors down the road. Developing all these point-to-point integrations was the toddler-equivalent of plastering spaghetti all over the walls. It’s getting harder and harder to separate those strands. And then comes a platform to give your man a get out of jail card. The platform comes with all of the integrations you need, and if you’re lucky, may allow you to request a new integration where someone else pays for integrating that capability so you don’t have to anymore. Only problem is if your man feels too big and strong to commit to working with another IT provider as an equal partner (the platform). Don’t listen to him. Re-assure him he’ll do just fine after a brief mid-life crisis but if necessary, abstraction also applies to abstracting out unhelpful attitudes (the ‘not invented here’ syndrome) and people.

Finally freed from legacy hell, enterprise can focus on their core business and leverage their newfound control of their data to develop the AI capabilities that will set them apart in the new data age. The combination of leveraging platform-as-a-service and abstracting enterprise software can finally make enterprise software as fast, easy and flexible as consumer apps. Now that’s something your board will thank you for raising however many millions you sunk into yesterday’s enterprise software contract. As they say nowadays, better to fail fast and to fail safe than to continue failing.