Low-Code Architecture Language — Low-Code & No-Code Exercises

1 / 5

An enterprise architect presents a slide titled "Core vs Edge Architecture for Low-Code." They explain: "Low-code belongs at the edge — not at the core." What does this mean in enterprise architecture terms?

The core vs edge framework is the most important architectural principle guiding responsible enterprise low-code adoption — it prevents the most common and costly mistake: using low-code for systems that require enterprise-grade engineering.

Core vs edge characteristics:

Dimension	Core system	Edge application
Examples	SAP ERP, Salesforce CRM, Workday HRMS	Expense tracker, onboarding checklist, approval app
Data criticality	System of record; authoritative source of truth	System of engagement; consumes core data
Transaction volume	Millions of transactions; high throughput required	Hundreds of users; moderate volume
Lifecycle	Years to decades; major upgrade cycles	Months to 2 years; frequent replacement
Development	Professional engineers, full SDLC, vendor support	Citizen developers, fusion team, low-code platform

Integration architecture:
Edge apps should never bypass the core — they must interact with core systems via officially published APIs (SAP OData, Salesforce REST API). Direct database connections from Power Apps to ERP databases are an anti-pattern that creates tight coupling and breaks when the core system upgrades.

Key vocabulary:
• System of record — the authoritative source of truth for a data entity (e.g. SAP is the system of record for purchase orders)
• System of engagement — an application layer that business users interact with, consuming data from systems of record
• Edge application — a departmental or process-specific app at the boundary of core systems; ideal for low-code
• Tight coupling — a dependency between two systems that breaks both when either changes; an architectural anti-pattern

2 / 5

A platform architect proposes: "We should use the strangler fig pattern to migrate our legacy monolith — starting with a low-code layer for the UI while the back-end is incrementally re-platformed." What is the strangler fig pattern?

The strangler fig pattern is a fundamental enterprise modernisation pattern described by Martin Fowler — understanding it is essential for architects discussing legacy system transformation at the intersection of low-code and traditional development.

How the strangler fig pattern works in a low-code context:

Phase	What happens
1. Facade	Build a routing layer (API gateway) in front of the legacy system; new requests can be intercepted and routed to new or old system
2. Parallel build	New low-code apps or microservices handle one bounded domain at a time (e.g. expense approval); legacy handles everything else
3. Traffic migration	Route the strangled function's traffic to the new system; validate in production with real users
4. Legacy atrophy	Each migrated function is turned off in the legacy system; legacy shrinks until it can be decommissioned

Why this is important for low-code architecture:
Low-code platforms are particularly well-suited to the strangler fig pattern because they can rapidly deliver edge applications (expense apps, approval workflows, reporting dashboards) that expose a modern UI while the legacy back-end continues to run — providing immediate user value without waiting for full re-platforming.

Key vocabulary:
• Strangler fig pattern — a modernisation approach replacing a legacy system incrementally by routing functionality to a new system one piece at a time; named after the strangler fig tree
• Big bang cutover — replacing an entire legacy system at once; higher risk alternative to the strangler fig approach
• Facade — an abstraction layer that hides the complexity of underlying systems; routes requests to legacy or new systems
• Bounded context — a domain boundary within which a particular model is consistent; the unit of decomposition in strangler fig migrations

3 / 5

An enterprise architect describes a governance model: "In our organisation, we use a citizen-led, IT-governed architecture. Business units build — but IT owns the runway." What does this model mean in practice?

The citizen-led, IT-governed model is the architectural operating model that distinguishes mature low-code enterprises from organisations where low-code has either stagnated (too much IT control) or created chaos (too little governance).

Responsibilities in the citizen-led, IT-governed model:

IT's "runway" responsibilities	Citizen developer's responsibilities
Environment strategy (DEV/TEST/PROD)	Identify the business problem to solve
Approved connector catalogue	Build the solution within the approved environment
DLP policies and security guardrails	Follow the training and governance requirements
CoE inventory and monitoring	Register solutions in the app catalogue
Training and certification programme	Own the solution lifecycle — including decommissioning

The "guardrail" metaphor:
IT builds the guardrails on the highway, not the traffic lights at every intersection. Guardrails (DLP policies, environment access control, security policies) prevent dangerous actions without requiring IT approval for every individual flow. Traffic lights (per-flow IT review) create the bottleneck that drives shadow IT.

Signs of model failure:
• Too much IT control → business teams give up on low-code, shadow IT using unapproved tools grows
• Too little governance → app sprawl, shadow IT proliferation, compliance incidents, unsupported critical flows

Key vocabulary:
• Citizen-led, IT-governed — business users build; IT controls the platform, security, and governance guardrails
• Guardrail — a governance control that prevents dangerous actions without blocking normal operations
• Runway — the platform infrastructure, policies, and enablement that IT provides for citizen developers to build on
• Operating model — the organisational structure and process framework governing how work gets done

4 / 5

During an architecture review, the panel shows a scenario and asks: "Should we use low-code here, or is this a case where we should not use it?" The scenario: a global financial services firm needs a real-time trading signal aggregation engine processing 50,000 events per second with sub-5ms latency. What is the correct answer?

Knowing when NOT to use low-code is as important as knowing when to use it — and being able to argue this clearly with specific technical reasoning is a mark of architectural maturity.

Why low-code fails this scenario:

Requirement	Low-code reality	Required architecture
50,000 events/second	Power Automate: ~100-500 cloud flow executions/min per tenant	Apache Kafka / Azure Event Hubs (millions/sec)
Sub-5ms latency	Power Automate: typically 1–5 seconds per run	In-process C++ / Rust / FPGA
Stateful stream aggregation	No native stream processing; stateless per run	Apache Flink / Azure Stream Analytics

Architectural anti-patterns this question targets:
• Using a business process automation tool for stream processing
• Confusing functional correctness ("it does the right calculation") with non-functional correctness ("it runs fast enough under load")
• Selecting a platform based on organisational familiarity rather than technical fitness

The right question to ask:
"What are the non-functional requirements (throughput, latency, availability, data volume) and do they fall within the platform's published operating envelope?"

Appropriate low-code use cases in financial services:
• Compliance exception approval workflows
• Regulatory reporting data collection forms
• Internal expense reimbursement and budget approval flows
• Client onboarding document collection apps

Key vocabulary:
• Non-functional requirement (NFR) — a quality attribute requirement (latency, throughput, availability) as opposed to a functional requirement (what the system does)
• Throughput — the number of operations processed per unit of time (events per second, transactions per minute)
• Latency — the time between a request being made and a response being received
• Stream processing — real-time processing of continuous data streams; requires purpose-built infrastructure

5 / 5

A solutions architect proposes: "For the new microservices platform, we want citizen developers to build orchestration flows in Power Automate that call individual microservices — effectively using Power Automate as the orchestration layer above the microservices mesh." Is this a sound architectural pattern?

Using Power Automate as a business process orchestration layer above microservices is a genuinely sound architectural pattern — it is deployed in production by large enterprises and reflects a mature understanding of the complementary strengths of each architectural layer.

Why this pattern works:

Layer	Responsibility	Changed by
Power Automate (orchestration)	When to call services; routing; approvals; notifications	Business / CoE team; no sprint needed
API Gateway	Auth, rate limiting, routing, versioning	Platform / API team
Microservices	Domain logic, data management, computation	Engineering team; full SDLC

Key design requirements for this pattern to succeed:
• Microservices must expose stable, versioned REST APIs with clear contracts (OpenAPI spec)
• Each microservice must be idempotent for POST/PUT operations (safe to call twice)
• Error handling must be implemented at the Power Automate layer for failed microservice calls
• Custom connectors must be pre-built and maintained by the platform team — not improvised by citizen developers directly
• The CoE DLP policy must approve the API connector used to call microservices

Anti-pattern to avoid:
Citizen developers calling microservice APIs directly with the "HTTP" connector without a governance-approved custom connector — this bypasses auth standards, rate limiting, and monitoring.

Key vocabulary:
• Orchestration layer — the layer responsible for coordinating the execution sequence of multiple services in a business process
• Choreography vs orchestration — in choreography, services react to events and coordinate themselves; in orchestration, a central controller (Power Automate) directs each step
• API contract — the agreed-upon specification of what an API accepts, returns, and guarantees; specified by OpenAPI definition
• Stable API — a versioned API that does not introduce breaking changes; essential for low-code consumer confidence