The Cliff
Can we avoid building?
Note: Originally published at The Slip Box.
A back office app running on a single Microsoft SQL Server can push out a ton of value. Excel is a veritable swiss army knife for data wrangling and internal tooling. Plenty of shops are using OBIE. Not this OBIE. This OBIE. Some of these processes are never going to “web scale”, their teams don’t need to hire developers, and it’s perfectly fine to buy solutions for what we’re doing. After all, these tools are not core to our business.
And the tool trudges on, day after day, adding value, inching closer to The Cliff. Eventually, there comes a time where the business wants to connect the tool to another application, or automate data sharing, or the data outgrow the tool. The team realizes that meeting the challenge will require a big rewrite, a migration to a new platform, or some other painful and costly undertaking. The reasons for this vary based on what the problems are, but The Cliff remains.
Now, the team needs to inch their way back from the precipice, or find a way to survive the fall. We’ll discuss some patterns for when you back off, and some others for when you take the plunge and decide to rebuild your tool as a “real” application.
Backing Off
Backing off means that we will double down on our strategy. This might mean restrictions like “no hiring developers”, no straying from the golden path, no migrations, and so on. In many cases, this means buying something extra.
Low/No Code
One solution can be Low/No Code programs, like Retool (Nocode), or Frappe (Lowcode). Over the past few years these tools have been building their business at The Cliff. They allow teams to build their own interfaces, applications, or automations, and often they’re enough to address the challenges that brought us to the cliff. Need to refactor the Magic Complex Excel Workbook into a “real” application? This might be a way out.
Caveat emptor: eventually Low/No Code can bring us right back to the cliff. For example, it is notoriously difficult to convert a Nocode app into a “Yescode” app.
Robotic Process Automation (RPA)
RPA looks like AutoHotKey, or macros, taken to the maximum possible level of polish. An RPA developer helps a business user collect the clicks, button presses, and rules-based decisions of a business process and consolidates them into a “bot”. Again, sometimes the problems that bring us to The Cliff can be solved by something like RPA. The main appeal is that you can develop bots with RPA tools like UiPath or Automation Anywhere without a big development team.
Taking the Plunge means we think we can fashion a parachute, stick the landing, aim for the bushes, or whatever else it takes to survive building a product in-house. Jumping off of a cliff sounds scary and dangerous, the way down can feel like it takes forever, and you can survive with the right tools and approach.
The Strangler Pattern
Originally developed for decomposing monoliths into smaller services, the Strangler Pattern can help us move features out of our tool. To use the example of the Magic Complex Excel Workbook, we can pull functions (or in the dire case *macros*) out of the workbook and into our solution. Better discussions of the pattern than I could write are available, such as StranglerFigApplication by Martin Fowler. I’ll just stress that this approach depends on the ability to insert yourself between the end users and the tools.
Teams that decide their tools are worth packaging as a product don’t exist in a vacuum. If the team is contemplating this as the very first undertaking of its kind at that company, then that is a very special animal indeed. Luckily, there just so happens to be Dr. Mik Kersten, and his wonderful book Project to Product.
Assuming you aren’t “the first one through the wall”, there is hopefully some institutional knowledge, maybe some PMO resources, and some policy in place. If we put these things together they start looking like an onramp for our team to get their tool into the product process. Even better would be to find a Product Platform. A collection of APIs that are approved within the enterprise and that help us take care of things like authentication, or monitoring, can make it much easier to develop the solution.
I think we’re also beginning to grind The Cliff down, and at some point in the 20s I hope we grind it down into a ramp. This could look like a lot of different things:
- Tools like Airtable, Metabase, and Superset have been heralded for exactly this. Can enterprise make it easier to transition from back office tool to enterprise app by adopting modern data architectures?
- Bureaucracy to the rescue. Tools like ServiceNow and Power Platform can deliver supercharged bureaucracy that might even be susceptible to some standardization.
…and many others. Overall I’m optimistic that The Cliff will grind down. Failing that, bet on the companies with great parachutes.
