When I’m not building enterprise systems for financial institutions, I’m wiring up my house.
My hobby is home automation. I live in a fragmented ecosystem where lights speak Zigbee (a low-power wireless mesh network), a doorbell runs on Wi-Fi with a closed cloud API, and a temperature sensor speaks Bluetooth. I use Apple HomeKit as the main orchestration hub, but because most smart home hardware isn’t natively HomeKit-compatible, I run a server in my closet with Homebridge — the translation middleware that makes it all work.
Jargon Lookup: Homebridge Homebridge is a lightweight Node.js server that emulates the Apple HomeKit API. It acts as a universal translator, taking signals from unsupported smart home brands and wrapping them in a data structure that Apple devices can understand.
It’s a brittle, asynchronous mess that requires constant monitoring, healing, and graceful error handling.
But here’s what I’ve found: managing a fragile home automation stack has made me a better enterprise architect. The parallels are closer than you’d think — making a €15 Wi-Fi bulb turn on when a €200 smart lock disengages isn’t that different from making a legacy core banking mainframe trigger a real-time Anti-Money Laundering (AML) workflow in Appian.
1. The Myth of the Single Ecosystem
Every salesperson will tell you: “If you buy our entire stack, it all works together perfectly.” In smart homes, that’s Philips Hue. In FinTech, that’s the “all-in-one core banking system” myth.
The reality is that every modern financial institution (and every smart home) is an accidental hybrid ecosystem. You’ll always have best-of-breed tools from different decades that have zero native reason to speak to each other.
In my house, I can’t make a specialised irrigation controller work natively in HomeKit. In a bank, you can’t make a 30-year-old legacy mainframe speak directly to a modern mobile payment gateway.
The answer is the same in both cases: design for decoupled architecture. Stop focusing on point-to-point connections (irrig_controller -> HomeKit) and start building bridges (legacy_ledger -> API Gateway -> Appian). In practice, this means middleware, message brokers, and standardised data exchange formats like JSON — translation layers between systems that were never designed to talk to each other.
2. Event-Driven is the Only Way to Scale
When I first started, I used the polling anti-pattern. Every minute, I had Homebridge ask my thermostat, “What’s the temperature?” It was useless noise that wasted CPU cycles and occasionally overwhelmed the thermostat’s cheap Wi-Fi chip, causing it to drop offline.
The backseat driver asking “Are we there yet?” every 60 seconds (Polling) kills system performance. True scale requires Event-Driven Architecture (EDA).
Jargon Lookup: Event-Driven Architecture (EDA) A software design pattern where decoupled applications asynchronously publish and subscribe to “events” (changes in state). Instead of a system constantly asking “did anything change?”, it simply waits to be notified the exact instant a change occurs.
If you’ve got an Appian process polling your payment gateway every 60 seconds asking, “Did the SEPA (Single Euro Payments Area) transfer clear?” you’re suffocating your infrastructure.
Now, I use asynchronous events: The second the thermostat registers a change from 21°C to 22°C (the Event), it fires that change data into HomeKit. This is the same idea I wrote about in Breaking the Low-Code Monolith. Stop scheduling database polling jobs. Instead, implement Webhooks and message streams. Let the payment rail tell you when the transaction settles, allowing your core business processes to react in real-time without the monolithic lag.
3. The Brittleness of “Bridges” (Handling Failures)
My doorbell bridge occasionally gets stuck. When this happens, it doesn’t crash HomeKit; it just stops sending camera feeds to my phone. If I hadn’t built in a heartbeat check, my first warning that my security system was down would be when a package went missing.
Your integrations are the weakest point in your infrastructure. When (not if) the connection to your external KYC (Know Your Customer) identity verification provider times out, the customer onboarding process can’t halt.
You have to design for resilience and safe fallbacks:
- If your API Gateway times out, have you configured the low-code platform to retry that critical AML check with an exponential backoff?
- If the real-time identity verification API is offline, have you designed a fallback process that automatically routes the application to a secure asynchronous queue for manual compliance review?
- Are you proactively monitoring your integration health (the Heartbeat Check), or are you waiting for frustrated customers to report that their account creation failed?
4. Automation Requires a “Source of Truth”
If my smart speaker tries to run a scene called “Good Morning,” but my presence sensor currently says “Sleeping,” something has to decide which one wins. In a smart home, the hub needs a single, coherent status of the entire property — a source of truth.
Same thing applies in enterprise. When you use low-code platforms as orchestration engines in banking, Appian needs to be the source of truth for the business process, even if it’s not the source of truth for the financial data.
The primary financial data (like settled ledger balances) lives in your core banking system. But the process state — “Fraud Investigation Pending,” “Loan Origination Approved” — has to live in Appian, reflecting the aggregate reality of all connected systems. If your process models can’t cleanly resolve conflicts between disparate data sources, you’re automating compliance risks, not efficiency.
Architecting Silence
The ultimate goal of both home automation and enterprise architecture is the same: silence.
When an orchestration layer is built correctly, the business logic just flows. The KYC check passes, the cross-border payment routes, the ledger updates. Nobody notices. It’s only when the architecture is flawed that things get noisy — maintenance windows, manual reconciliation, compliance audits.
Sometimes, to build resilient systems for a financial institution, you first have to practice on your living room lights.
Further reading
- Breaking the Low-Code Monolith: Guide to Event-Driven Design — The deeper dive into why polling is killing your system performance, and what to do instead.
- Designing Enterprise APIs in Appian: Beyond the Basics — How to build the translation layers between systems that were never meant to talk to each other.
- Surviving the Appian Health Check: How to Separate Signal from Noise — On monitoring what actually matters and ignoring the rest.
If any of this sounds like your setup — fragile integrations, polling where you should be listening, no clear source of truth — get in touch. I like talking about this stuff.