You have a problem with your business where some critical part of it is very manual labor heavy and prone to mistakes. The ACME Inc ERP suite doesn’t quite suit your needs. In addition, you have a stellar product idea that will surely take you to the 21st century and sales will soar! 

Should you hire me to solve your problems? Probably not. Custom software is expensive. It’s “thousands of euros per week per developer*” expensive. Tell your employee who is smashing those Excel buttons to suck it up and keep smashing, that’s what he is paid to do. You can press those buttons an awful long time if automating it costs 200k€. Align your business processes so that mistakes are detected. Adjust your business model so that ACME features are enough. Buy that ready made solution and live with the limitations. Here me to figure out how to get the most out of what you have.

Ok fine, you did your ROI calculation and it tells you that a custom solution will give you the edge on the market you are looking for. So what’s next? You gather your requirements and send an offer to us. We evaluate it, figure out how it can be done and come up with an offer.  We were lamenting about this process with our CEO Juha that our industry hasn’t progressed at all in the past 15 years - on the contrary we have probably gotten worse. We don’t often do a good enough job convincing the customer of the value of what we are truly adding. He promised to write about this in more detail, so make sure to follow us and check it out!

But back to the topic and my role in the process - architecting solutions.

Architecting solutions

We’ll try to figure out what kind of solution works best for you. The running joke among software architects is the classic: the answer to every question is “It depends”. React or Angular? NoSQL vs SQL? Serverless? AWS or Azure? Java or Python? It depends. Depends on what? The short answer is whatever your requirements are balanced with your capabilities and your budget. 

The long answer is that it is a tedious task of evaluating the suitability of solutions, line by line, feature by feature. There are more formal methods for this, but they are often not deployed in this process, there just is not enough time and resources to do it that thoroughly. Coming to a solution is a process that involves all kinds of trade-offs. Should you just keep what you have and improve upon it? Should you choose some COTS (Common-Of-The-Shelf) software to solve your problem, what kind of compromises are you staring at? It for example might entail not having any way to import your existing users, so you need to manage that some other way. It has no synchronization to your accounting and so on. The list is endless. If we do pick some product, then we need to figure out what kinds of integration requirements it will involve.

On top of requirement management we will balance your existing software landscape. If your existing solutions are written in Java, I will not pitch Django, I’ll replace that with Spring for example. There’s also the outside world to consider from tool maturity levels, security considerations to availability of developers. Clojure might be perfect for your use case, but if there’s no one to maintain it, is it really?

Of course there’s always the ROI to consider. Living with that ACME ERP might be still a better choice, perhaps with some workarounds tacked onto it. We will evaluate this possibility as well. Changing is always a risk, as many software products look perfect on paper, but scratching the surface reveals a myriad of issues. They might lack any customization options. Their pricing model  can be full of  “10€ for one user, 100k€ for two” types of traps. They might not have any support. It boggles the mind on what kind of feature hole products have, even things that have been in the market for years. Changing from one core solution to another is always painful, since whatever issues the old one had, your business learned to live with them.

This evaluation is done with limited knowledge of both the requirements and the product(**) and with a severe time constraint. We rely on documentation, which can be outdated, missing critical details or woefully misleading of the actual capabilities. In-house experience of picked solutions is worth their weight in gold, but often not available. Same goes for a consultant with experience with your business domain and special tooling. They will be aware of the biggest traps, for example if have a requirement that a system needs an ECommerce product, just looking at a feature matrix some features might be listed as  “yes”, but what it leaves out is that it’s a massive pain to actually use or it was bubble gummed in by a single intern who left the company when school season started again.  I suggest spending extra on this kind of help if possible, it will always pay off. These are lessons that don’t need to be learned again by your development team. But in the same vein, it might not be worth it to hire that specialist full time - competent developers will pick up these nuances fast. 

I’m often amazed at how bad a job documentation of various software products do at actually describing the problem they are actually trying to solve. The marketing jargon is so thick that you need to dig into the developer documentation for hours just to figure out what the product actually does. There’s often no mention how it is better compared to just sticking to “the old boring tech”. They overpromise and underdeliver and quite frankly don’t understand the capabilities of the old industry proven stuff, or whatever the motivation for the product was is totally irrelevant for you. All the advertised features work just as well with the old, but they fail to mention that you lose years of feature build-up when you switch.