The arrival of desktop interoperability presents an incredible opportunity to break the cycle of slow enterprise software development. It also improves the productivity and satisfaction of users. Smart desktop technology is powerful, and with great power comes great complexity—and therefore risk.Your mission critical users simply won’t tolerate software that doesn’t work. The solution? A focus on solid engineering.
As a Chief Innovation Officer or Head of Digitization, you’re in a tough spot. You know desktop interop can improve and bring tremendous value to your business. You understand the future of enterprise software consists of some kind of interop software linking legacy tech and new applications. But how do you implement desktop interop without hurting your business?
At Finsemble, we’ve learned that risk can be removed with thoughtful architecture.
What makes a smart desktop so complicated?
When you launch a smart desktop, you’re actually launching dozens of independent parts. A runtime, services, modules and dozens of components make up your user’s workspace. At launch, all these services and components must start successfully and in the right order. In an improperly designed system, if one component or module fails (or is slow to come online) then all the components that depend on it can fail. A cascade of failures from one small problem can cause the entire application to not start. Architectural weaknesses can cause a host of problems, but for this post we’re focused on that most dreaded support call: when a user’s application won’t start.
Smart desktops have more moving parts than traditional desktop software. It’s easy for any given service or component to become a weak link that takes down the entire system. This problem is exacerbated because smart desktop components are often built by disparate developers on different teams or even different companies.
Finsemble engineers discovered how important startup architecture is through first hand experience in the field.
Finsemble‘s initial startup architecture was based on the idea of a dependency graph. Each component was only required to specify its direct dependencies. With this information, Finsemble compiled the complete dependency graph which was fed into Finsemble’s boot process, starting all the modules in the right order.
This approach seemed to make a lot of sense. It resulted in optimized boot times and a loose coupling, but field testing showed a different reality. The system as a whole was only as strong as the weakest link. It turned out that a single component could cause the entire system to fail. Worse, when a single component failed to load, all of its dependent components would also fail to load, creating a mountain of errors to sift through when debugging. Additionally, as new services were added to a growing system, dependencies also had to be updated. If a dependency was missed, then race conditions could emerge that were hard to diagnose. The dependency graph approach was fragile, and wasn’t the top-grade solution we were looking for.
A single source of truth: boot sequence.
We went back to the drawing board. In particular, we looked to other mission critical systems with complex startup systems for inspiration. Rockets and the UNIX “init” process provided us with a better approach. They employ the simple concept of a “boot sequence” – a series of well defined and ordered stages where modules come online.
Finsemble 5.0 now employs a boot sequence: a single source of truth for how the system should start.
With a boot sequence, it is generally unnecessary for modules to register specific dependencies. Instead, modules simply assign themselves to a particular boot stage. If a critical module fails, the system produces output that identifies the specific failure. When a non-critical module fails, the system logs the issue but continues on.
Each stage of the boot sequence is named and has a clear purpose. This makes it easier for developers to understand where to run their modules. There’s no need to consider every possible dependency—just pick the stage that is intuitive. 
Elimination of a dependency graph eliminates the weakest link problem, making the system more reliable, but it also makes it easier to understand the root cause when something does go wrong. New, easy-to-use instrumentation tools make debugging a snap. We’ve paid attention to what’s needed in the field when working under pressure on mission critical systems. Diagnosis can be made on the spot, and then a simple config change can turn off a misbehaving service so that users can get back to business without a code change.
Improve your project’s chances of success with thoughtful architecture.
Desktop interop is the best thing that’s happened to enterprise software in decades, but without solid architecture, your project may not get off the ground. This new technology brings new challenges, and vendors must acknowledge that a more disciplined approach is needed than is often taken when working in JavaScript on the web. A rigorously designed boot sequence is just one of the ways we’re bringing serious engineering discipline to our customers.
Learn more about Finsemble’s boot sequence, including startup stages, in our Finsemble documentation.
As you consider building a solid architecture for your smart desktop, have you thought about the framework that you’ll build upon? Download our guide to PWAs vs Electron for Desktop Interoperability to better understand the considerations for choosing a foundation for your smart desktop.
