Ty Shewmake, CTO at VeilSun, discusses part 2 of his approach to no/low-code governance and how to establish an effective no/low-code governance framework in this three-part series.
In part 1 of this blog series, I talked a little bit about what’s new and exciting in the no/low-code development world.
Having been in IT since 1990, I’ll tell you—it’s truly a breathtaking time to be in this business.
At the same time, I alluded to the fact that governance probably needs to play a larger role in most organizations’ no/low-code transformation.
While I’d never personally desire (nor advocate) a return to the days of the Systems Development Life Cycle (SDLC) used since the 90’s, we can use parts of it as a basis for rational governance in the world of no/low-code.
Use the best, toss the rest.
How to Think About Governance
More and more people ask me to explain why they should care about governance in this brave new no/low-code world.
It’s a good question—and often leads to this conversation…
The democratizing effect no/low-code has had on cloud app development has been stunning—and hundreds of thousands of business apps exist today that certainly would not without no/low-code. People always get that, but at the end of a bit deeper conversation, most begin to understand that governance is key to no/low-code success for many organizations.
I often start this conversation by comparing web development without governance to asking the neighbor’s 14-year-old to work on your car’s brakes. It’s doable—just not advisable.
Here’s why: there are 4 main “gotchas” that are part and parcel of most no/low-code transformations we see. We’ve seen a ton of them, and they mostly all look the same. They’re the monster under the bed but can be relatively easily slain by “The Sword of Governance.”
The “Gotchas”
At its best, a no/low-code governance framework sets simple, realistic, and achievable “bumpers” that keep organizations from falling victim to gotchas in these 4 areas:
- Design
- Security
- Currency
- Maintainability
Are there more areas that apply? Sure. However, if you get these 4 right you’ll probably be successful.
Design (or “It’s ALIVE!”)
Just because a new no/-low-code app works great supporting 1 department, 10 users, and 1 business objective, doesn’t mean it’s designed the way it needs to be to support 5 departments, 150 users, and 8 objectives.
Quickbase apps grow. Quickbase apps grow fast. And, Quickbase apps grow deeply into organizations.
An app that begins its life as fixed asset tracker can become a business-critical ERP system before you know it—that’s the incredible promise of Quickbase and no/low-code development.
However, it’s also the reason that no/low-code apps need to be designed and architected the right way from the start. You simply never know where they’ll end-up.
A single developer or natural builder working in a vacuum can create a stunningly well-designed application —or a basket case that just works. And, it’s impossible to tell the difference unless somebody is actually looking at how the app is built—as it’s being built.
Many organizations that skip this step are quietly building an expensive redevelopment backlog that must be addressed at some point. Pay the small tax now (during development) to have experts review your builders’ and developers’ work to ensure your apps are properly designed from the ground up.
This will save you tons of money in the long-run and can likely ensure the success of your no/low-code transformation effort. No/low-code apps that are reliable and fast are successful – those that are not are unsuccessful.
Slow or unreliable no/low-code apps will sink any no low-code transformation.
Security
As a 25-year CTO, the thing that always keeps me up at night is the fear of a data release. Whether you’re Target or Bob’s Grocery—waking up and seeing your financial data, customer list, or payroll information plastered all over the web (or even rumored to be all over the Web) can be a reputational/financial disaster.
No/low-code apps are software. Software MUST be secure.
The ease with which Quickbase can connect to internal legacy systems and the external world is stunning. It also means that we have to understand that with connectivity comes responsibility. We must realize that security requires thought, expertise, and oversight to safely connect systems (as it always has).
However, because IT often does not understand no/low-code, or doesn’t have the time to mess with it, they fear it.
As a result of this fear, some organizations (especially those with IT organizations) have simply “turned off the faucet” when it comes to allowing no/low-code connectivity. Rather than allowing their no/low-code apps to attain their full business potential and ROI by incorporating legacy system and external data, they simply prohibit them from accessing any corporate or external data.
This head-in-the-sand approach reminds me how the mainframe folks at the large bank I worked at in 1992 talked about the new client-server Linux and .NET “toys” the youngsters were all excited about.
IT should (and must) be involved in no/low-code oversight and security—because that’s where the expertise is. However, they need tacklers instead of blockers in terms of data access. Quickbase has a stunning array of tools that can harden your no/low-code apps. IT should understand them, advocate, and supervise their use.
From Active Directory integration; to SSO; to its amazing role, app, form, and field-level security; Quickbase has you covered with configurable security. On top of that, their enterprise platform security addresses network, operating system, and a myriad of other Web app attack surfaces, which were previously something that kept this CTO on his toes over the last 25 years—things I don’t even have to think about now.
The fact is, if your Quickbase apps are not far more secure than your full-stack apps, you’re not using Quickbase’s security tools to their fullest capability.
Ideally, organizations with no/low-code apps should bake-in a security review of every application on a scheduled basis, and whenever a change is made to an app or a connected system. These activities don’t have to be onerous, most of the time security issues are pretty evident—but you have to look and test to find vulnerabilities.
Review. Test. Repeat.
Currency
Have you ever heard (or said) this “Why can’t the old ‘ABC’ app do it—the new ‘XYZ’ app can?”?
Across an organization, and over time, no/low-code apps proliferate. That’s a great thing! However, as time goes on, there is an inevitable widening feature-set and builder expertise gulf between earlier-developed no/low-code apps, and those developed more recently.
As you know, Quickbase is constantly adding new features, functions, and improving ways to get things done in the platform. At the same time, new builders always learn how to do things better and more efficiently as they gain experience and add new skills.
Over time, this leaves you with app “haves” and “have nots”—earlier apps that work but lack many of the new efficiencies and features of more recently built apps, as well as those built earlier in a builder’s career as he/she was just learning versus those built later after gaining more experience and expertise.
I know, when I look at apps I personally built 6 years ago, I almost always say “ugh—why did I build it that way?” As I gained experience, my newer apps are invariably better than my older apps. Across 3 apps, this is not a big deal. Across 20, it is.
This can leave an organization with a significant, hidden redevelopment backlog if it’s not addressed on an ongoing basis—with apps being incrementally improved, updated, and feature-refreshed over time.
An organization’s older apps are no less important simply because they’re older. In fact, most of the time the apps developed first and early are those that were (and are) the most critical to the business. No/low-code organizations should assess their currency gaps and treat their existing apps with the same love they shower on new web app development.
Maintainability
Easy to build, easy to break?
No/low-code apps can be (and should be) a breeze to maintain. However, in the absence of context and history in an app, a builder diving in to make a change can be a very scary thing.
Honestly, most no/low-code apps we see are built without any documentation—forcing the original builder to remember the “why’s” and “what’s” of their development, while leaving anyone coming in afterward to maintain an app at a loss.
This is another situation that only worsens over time, and one that reasonable governance can obviate.
You Gotta Have a Plan
So, what to do? OK, so you’ve got 25 apps. You don’t have a real good bead on build or design quality. You have no clue as to which apps include which of Quickbase’s features, improvements, or efficiencies. You’re not quite sure you’re comfortable with security.
If you hear that monster under the bed—fear not. There’s hope.
In part 3 of this blog, I’ll provide a framework we at VeilSun are using to freshen-up governance in our clients to help them maximize the ROI of their no/low-code investment. It’s a lightweight, sensible way to approach your planned or ongoing no/low-code transformation that can ensure its long-term success.
VeilSun is a professional services firm that has helped hundreds of organizations over the last 12 years successfully navigate their no / low-code transformations. VeilSun Low-Code Enterprise (VLE) service is a new framework that provides a quick-start to small and large organizations embarking on (or enmeshed in) their transformation.
Contact us any time to chat about your organization’s no / low-code transformation.
