The problem isn't always a lack of technology. Sometimes it's the difficulty of changing what we've already built.
Tuesday, 10:14 a.m. An operations manager notices a small issue: the form her team uses needs a new field. She doesn’t want to overhaul the entire system or launch a new application. She just needs to capture a piece of information that isn’t currently recorded so she can make a better decision next week.
In theory, it should be a minor adjustment. In practice, she opens a ticket, explains the requirement, waits for someone to prioritize it, answers questions, goes through development, testing, and deployment, and—if all goes well—several weeks later the change goes live. By then, the process has already changed again.
This scenario is common because many organizations digitized their processes using a fairly rigid approach: every new need translates into a software modification. That approach worked as long as the business changed at a reasonable pace and the number of systems was limited. Today, a company may have CRM, ERP, marketing platforms, e-commerce, service tools, analytics, portals, and dozens of specialized applications; however, a surprising portion of operations still relies on emails, spreadsheets, and small manual tasks that exist precisely in the gaps that none of those systems addressed.
The usual reflex is to buy another tool or request another custom development. But perhaps the problem isn’t a lack of software. Perhaps the problem is that we’ve built processes that can only change when someone reprograms them.
Why do we continue with manual processes if we invest in technology?
Let’s consider a simple sales approval process. A salesperson requests a price exception, their manager reviews it, Finance validates the margin, and, depending on the amount, management may also need to approve it. On paper, it seems like a stable sequence, but it rarely stays that way for long. Tomorrow a new customer category appears; then the approval limit changes; next, automatic margin validation is added; later, the business wants to send notifications via Teams instead of email; and finally, it’s decided that certain exceptions don’t even require human intervention.
If each of these changes requires going back to the source code, opening a project, reserving development capacity, and deploying a new version, the company doesn’t just have a speed problem. It has an architecture problem. The process is too tightly coupled with the implementation that supports it. Changing a business rule means modifying the solution, as if the two were inseparable.
That’s where Low-Code start to get interesting—but not for the reason typically highlighted in sales pitches. It’s not simply about “programming with less code” or allowing anyone to build applications by dragging and dropping boxes. That interpretation falls short. The real value lies in shifting part of the change from custom development toward configurable components: flows, rules, forms, data models, integrations, and experiences that can be adjusted without rebuilding the entire solution.
Platforms such as Microsoft Power Platform, Mendix, OutSystems, Appian, and Salesforce take different approaches, but they share an interesting idea: visual and configurable elements can handle much of the repetitive work, while code is reserved for what truly requires specialization.
When a rule changes, the goal should be to adjust a single part of the process—not to rebuild the entire system.
This even changes the conversation between Business and Technology. In the traditional model, Business explains what it needs, and Development translates that need into software. In a well-governed low-code architecture, part of the solution can be modeled much more closely to the language of the process: if this happens, validate that; if the amount exceeds a certain limit, request approval; if information is missing, halt the flow; if the customer belongs to this category, use a different route.
The developer doesn’t disappear. Their work shifts toward areas where they add much more value: architecture, security, complex integrations, extensions, performance, governance, and reusable components.
Who Should Use Appian? From C-Level Executives to Operational Teams
There’s an important difference between digitizing a process and making that process adaptable. Digitization can mean taking what happens today via mail and building an application that replicates it exactly. That improves the experience, eliminates some manual tasks, and perhaps provides traceability. But if, six months later, any adjustment again requires a major overhaul, we’ve created a digital version of the same problem: the process remains expensive to modify.
An adaptive process is designed with the expectation that rules will change—not because the organization is disorganized, but because the business learns. New products, markets, regulations, segments, channels, exceptions, and ways of working emerge. A sound architecture assumes that what seems permanent today likely isn’t—and therefore separates, as much as is reasonable, the logic that changes frequently from the components that should remain stable.
The difference may seem semantic until a hundred small changes accumulate. In an organization where everything is development, every improvement competes for the same technical capacity. The backlog ends up filled with perfectly valid requests that aren’t big enough to become strategic projects, but aren’t small enough to be ignored either. At that point, the cost isn’t just in programming hours; it’s in the missed opportunity while the process waits.
Low-code can reduce that friction when used for the right use cases: internal forms, approval workflows, operational applications, portals, automations, case management, field data capture, orchestration between systems, and experiences that need to change frequently. Not because these solutions are necessarily simple, but because many share patterns that a platform can abstract and reuse.
Adapting to Disruption: Defining Processes Before Automating
Here’s another common mistake: thinking of low-code as an island. You buy a platform, build a few applications, and create an ecosystem parallel to CRM, the ERP, and the rest of the operation. That might speed things up in the first few months but create a huge problem later on.
The goal shouldn’t be to replace every existing system, but rather to use Low-Code as a layer that helps connect, extend, and integrate what already exists.
Let’s suppose that the ERP remains the system where orders and accounting reside; the CRM stores customers, opportunities, and sales activities; e-commerce manages the product catalog and transactions; a customer service platform handles conversations; and a low-code application coordinates a returns process that spans all of them.
The application doesn’t need to become the new ERP or copy all the data from the CRM. It can simply consume the necessary information, apply business rules, request approvals, and return results to the systems that already own each piece of data.
Low-Code works best as part of the ecosystem: connecting capabilities without trying to become the entire ecosystem.
That approach requires something that is sometimes overlooked when Low-Code is presented as “easy”: good architecture. You must decide where each piece of data resides, which system is the source of truth, which rules belong to the process, which integrations should be synchronous or asynchronous, what happens when a service doesn’t respond, how permissions are managed, and what changes a user can make without compromising operations.
A visual platform doesn’t eliminate these questions. On the contrary, when it allows for faster development, answering them correctly becomes even more important.
The issue of governance also arises. If every department starts creating applications without standards, we risk replacing “shadow IT” based on spreadsheets with “shadow Low-Code”—composed of duplicate workflows, ad-hoc connectors, conflicting rules, and applications that no one knows who maintains. Democratization without governance does not create agility; it creates technical debt at a different pace.
That’s why mature implementations typically establish environments, roles, reusable components, connection policies, data conventions, monitoring, and a clear model for deciding when a use case can be built by a functional team and when it should involve professional developers.
Low-Code is not an alternative to professional development; it is another layer of the enterprise development model.
Does Appian replace your current system or enhance it?
The term “Low-Code” can give the wrong impression: if there’s less code, perhaps the solution is more limited. Sometimes that’s true; other times it isn’t. The actual limit depends on the platform, the design, and the problem we’re trying to solve. Tools like Power Platform, Mendix, OutSystems, Appian, or Salesforce allow you to combine visual building with APIs, custom components, and traditional code.
That combination is precisely what makes the model so compelling: starting with a high-level abstraction and drilling down to the code when the situation calls for it.
The right question isn’t “Can we do this without writing code?” That obsession can end up forcing a platform to solve problems it wasn’t designed for. The most useful question is:
“What part of this problem actually requires custom code?”
If a significant portion of an application consists of data capture, rules, approvals, notifications, and standard integrations, it may not make sense to develop all of that from scratch just because the remaining part contains specialized logic.
There are also scenarios where a traditional solution will still be the best choice: high-volume transactional engines, highly specialized algorithms, specific performance requirements, digital products where the code is a central part of the competitive advantage, or architectures with requirements that a low-code platform cannot reasonably meet.
Choosing low-code for everything would be just as naive as writing everything from scratch.
What’s valuable is to stop framing the conversation as a battle between Low-Code and Pro-Code. Organizations need a portfolio of capabilities. Some components will be SaaS, others will be configurations within the CRM or ERP, some will be Low-Code flows, and others will be custom-developed services.
A mature architecture isn’t tied to a single technique; it uses each one where it reduces complexity without compromising the future.
Appian and Its Impact on Business Automation
There’s a simple way to check if our architecture is working: observe what happens when the business requests a small change.
If modifying a rule, adding a validation, or incorporating a step requires mobilizing too many people, deciphering code that no one wants to touch, and waiting for a disproportionately long deployment window, the technology is dictating its own pace to the business. It may work perfectly, but it has become a rigid structure.
If, on the other hand, the parts that change frequently are modeled in a configurable way, the systems communicate through clear integrations, and there is governance in place to evolve the solution without losing control, change no longer feels like an exception. It begins to become part of the operation.
The value isn’t in building a final version. It’s in creating a foundation that can continue to change.
And that’s probably the most interesting aspect of low-code. For years, we’ve measured digital projects by how quickly they went into production. Perhaps we should add another metric: how easy it is to modify what we’ve already put into production.
Building quickly matters, but a solution that’s delivered in three weeks and then takes three months to adapt isn’t truly agile. Initial speed can be an illusion if every new version turns into a project all over again.
Digital transformation shouldn’t be about accumulating applications either. A company can have fifty tools and still be working with processes that are difficult to change. Maturity emerges when technology becomes a platform for experimenting, adjusting, and improving the way we operate without having to rebuild everything from scratch every time.
That’s why perhaps the next software request should start with a different question. Instead of:
“What application do we need?”
we could ask:
“What part of this process needs to be able to evolve?”
The answer might lead us to purchase a tool, develop a service, configure the CRM, build an automation workflow, or use low-code. The important thing is that the decision starts with the process itself, not with the software catalog.
Because a company doesn’t need every new idea to end up as yet another system. It needs an architecture where ideas can become changes, changes can be tested without disruption, and processes can continue to grow without every improvement having to start from scratch.
It’s not about having more software. It’s about building an operation that can change, improve, and grow as fast as the business does.
Beyond Modeling: How to Turn Processes into Something That Actually Gets Done