English | EN 
As is the case for finding business solutions going back to the early days of computers, a major decision point for stakeholders and leadership is whether to use something that can be purchased or build it “in-house” even if that means an external service group doing the work. Organizations have paid money just to help make the decision that is effectively an impactful one that has an undeniable inherent value sometimes much higher than envisioned.
To be sure, due diligence should call for looking at “all the options” on the table but seems to be happening more recently is that the process is potentially quicker thanks to experience and the abundance of information available to make those decisions quickly even if we do not pay someone to help us do it. That is definitely the case in the Low CodeNo Code world where the Power of the Cloud and years of innovation, practices and new products give us a starting point further along the path while still allowing flexibility to bring along the goodies that are still sitting in the traditional development avenues.
But with the new convenience comes new things to think about that can be just as critical and impactful and the reason for this short blog to help put things in perspective. Some of it will certainly sound familiar for decision makers with purchasing power. Some will be nuanced as hopefully the takeaway pieces from this article that will fill in those few gaps.
To start, we should agree that when we say Low Code No Code (LCNC), we mean creating solutions within fixed frameworks that are optimized to be used by developers who do not need the traditional coding skill set but, rather, apply business knowledge and acumen to manipulate the tools to service requirements. I want to make it clear that traditional developers can and do use Low Code No Code tools and, in fact, may be the authors of those tools which they use to help themselves be more productive. But let’s also make clear that the key to true LCNC platforms is a “democratization” of the feature set that allows for the business user at just about any level to potentially create solutions at any level, with speed, quality and high maintainability fulfilling many of the important tenets of Proper Enterprise Architecture patterns and practices. The solution specifically might require the “Rocket science” expertise to build (e.g. App to Launch Rockets) but the point is that the building of the bits should not.
With that in mind, the first obvious ones especially for industry focused solutions is to see if there is already some product that focuses on specific tasks such as HR, Retail, or Manufacturing organization apps for things like benefits, Sales Tracking or Scheduling but know that it does not end there as the product may have enough of a short coming to justify something “in house” or custom. Two decision factors here: First, there may be too much functionality in the product where in perhaps two out of 100 features are likely to be used and where a lot of brainstorming is still not enough to “employ” those other capabilities. The Second is not enough capability where the product solves only a small part of the problem but needs a lot of help (or add ins or customization itself) to get through to a minimally viable solution point. I still find myself falling back to tried and true analysis tools like SWOT (Strength, Weakness, Opportunities, Threats) or Rose, Thorn, Bud charts to get a fix on these and something like that should be done if at least to confirm what may already be known and understood.
Remember that some systems you can buy may not be obvious choices because features may be deep in the system hidden in plain sight as in knowable only by professionals who specialize in their use (the case for tools like Dynamics 365 and their specialized areas in areas like Finance and Operations, Supply chain or Customer Relationship Management to name a few) Even straight forward Low Code systems from the likes of Service Now, Salesforce, etc. have powerful “ready to go” solutions for problems that should not be discounted quickly and, thanks to a trend of competitors playing nice with each other actually integrating well in more cases. My direct anecdote here are from the connector features in Microsoft’s Power Platform to these very same “competitors” (SAP, Sales Force, Service Now, etc.) that effectively allows for buying into the solution deep enough to solve most of the problems and using the other tools to fill in the gaps. What’s important here is to get the balance in determining what could have been done with least effort with one tool and what the upkeep of that solution would look like when put up against licensing costs.
Speaking of licensing, we can close for now on the one huge decision point which is on how the organization wishes to pay for their problem to be solved over and above the more direct cost. Building means creating assets which have value that can be managed with the same financial patterns as property and where the operating costs can be more predictable when picking LCNC products with fixed fees. Buying a solution does not mean owning them in the case of commercial products which are typically, in this case, services configured to fulfill business needs. The former allows for flexibility in moving towards a future while the latter runs the risk of getting things “stuck” in a pattern than may not age well or even be appropriate when business conditions change. Related to that is the solvency of the vendor LCNC or straight up Commercial product. Several organizations I work with consider that as its own risk that needs to be hedged against even if it means getting a less capable tool set.
What’s next? I have hopefully given folks a few more things to think about in their solution evolution and evaluation and perhaps an assurance that even though we do need to be thorough in our analysis, things have changed enough to make that easier. Ironically the very same LCNC tools that we are evaluation are also useful for making that evaluation which will be a subject for a (not so far into the) future blog. I look forward to a discussion on this from folks out there!
