Skip to main content

Appian Technology

Marco2 Marco Pescosolido

Header (21)

Organizations win by their unique values and by how effectively they execute on them. The organization I am a part of at Appian manages, among other things, our technology stack. We value discovery and open design collaboration. We want to empower every engineer to move the architecture of our platform forward. So, taking some inspiration from ThoughtWorks, we created an app for that — our Tech Radar.

It’s a catalog of technologies — the ones we use, the ones we don’t, as well as those we are curious about. All our engineers can contribute to it at any time, and it’s visible to the entire company. We automatically schedule tasks to keep the information fresh and we regularly review updates so we are always alert to new technology and ready to steer our innovation efforts.

Should we try Kotlin? Maybe, maybe not — one thing is certain: being able to come here and get a crisp, effective review of what it is and how it might help Appian is powerful. Without it, most of us wouldn’t even know it exists.

Building this app in Appian took 15 minutes to get going and a few hours to customize for our needs. It runs on the web and as a native mobile app. It’s seamlessly integrated with the rest of our enterprise systems (two-factor authentication, employee records, feature management, and the continuing education courses we wrote about before).

If that sounds simple, it’s because we try very hard to make it simple. Our target audience is not the average developer, nor the exceptional developer that it normally takes to create robust, scalable, secure, great-looking software for the enterprise. It’s anyone who has a vision for a software implementation of the values they apply to their business.

As good as we are at scaling our agile practices, there’s just not enough development bandwidth to spare for things outside our core business — i.e. our platform. We write software for a living here at Appian, but if we had to build the Tech Radar from code, it would not exist today. We’d be forced to perform technology reviews the same way everyone else does them - whatever way that may be.

Now, software is not usually our customers’ business, but the choice they are faced with is exactly the same: conform their values to some off-the-shelf tool, spend millions of dollars building custom software, or run their business on good old paper, …er, I mean spreadsheets.

We are here to give them a much better choice. The Appian platform lets companies quickly create applications that help them excel at whatever makes them special. You could say that we let every company become a software company, without forcing them to make software their business.

We have an ambitious mission, which is reflected in our unique technology stack. While most software companies have their vision for some particular aspect of life or business to which they tailor-fit their technology stack, ours is all geared towards enabling our customers’ own vision for their business.

We leverage fantastic technology others have built as well as technology we’ve had to invent ourselves, right here at Appian. The rest of this article gives a walkthrough of our technology stack. It’s no Tech Radar, but a good overview nonetheless.

User interfaces.

Our platform exposes several environments, tailored to the different personas that interact with it. We have an administration console to manage the whole platform, a design environment to build applications, and three different user environments where custom applications live: a social interface for knowledge workers who use many apps on a regular basis, standalone sites for single-purpose use, and web components that can be embedded in any web page.

The user interface of all these environments is built on top of our patented SAIL framework. It is based on Functional Reactive Programming concepts, exposed to our designers via a non-threatening, hyper-productive interface designer. It’s pretty unique in that you get to change the structure and logic of the interface while using it live, just as users would.

Since day one, we made a bold, counter-current decision to make all our mobile clients native, in order to deliver the absolute best user experience. The promise to our customers is that they can easily build their interfaces once, and they will work and look great forever, on all supported web and mobile platforms.

We used to maintain three completely distinct clients, until some 20 engineers got together in 2015 to build an impressive prototype with React and React Native at our semi-annual hackathon, and now much of the core SAIL codebase is actually shared across all platforms, and our iOS and Android developers can focus on advanced mobile-first features.

Here’s a one-shot look at our front-end competencies:

That’s only part of the picture, since we also use best-of-breed libraries everywhere it makes sense — e.g. we do charts with Highcharts, and we let Tether position our tooltips and menus in our web client.

We are very proud to deliver an amazing user experience to our customers. In fact, we just finished a complete restyle of our components to keep up with UX trends. We do that on occasion, so our customers never have to. The results are astounding.


Like most applications, Appian applications need to store and access data. Unlike most software, ours is not designed with prior knowledge of the schema, query and transaction patterns, because our customers define all of that by their run-time usage of the platform. This makes for a unique set of interesting technical challenges, which we address with an equally unique data architecture.

To handle our simplest workloads we integrate with traditional RDBMS technology. Given that our software defines and consumes schemas dynamically, we tend to get much deeper into the guts of data access frameworks than most development teams. We support all of MySQLOracleSQL ServerDB2, which takes quite a disciplined approach and a robust testing pipeline.

We use Elasticsearch for more advanced queries — e.g. for text search, to track dependencies between design objects for instant impact analysis, to capture and report on performance stats so our administrators and designers can be alerted to performance hotspots, and more. We just keep finding good uses of this technology.

For real-time transactional + analytical workloads, we turned to Kx. Their technology was originally built for what is possibly the most demanding database application of all, real-time analytics for financial securities trading. It’s crazy fast, completely dynamic, and it comes with a vector-oriented functional programming language to do arbitrary data processing.

We also store some of our data directly onto the filesystem. To implement redundant, highly available storage we leverage GlusterFS. Documents uploaded to our built-in document management system are stored this way.

With data spread over and replicated across multiple different systems, we had to create various synchronization mechanisms, depending on the type of consistency guarantees required in each case. E.g. for durable transaction log distribution we leverage Kafka, and for leader election of high-availability replicas we use ZooKeeper.


Services and integration.

Most components of our platform run as independent services. Some we built ourselves (e.g. our identity and document management services), others are third party tools we include into our cloud deployment (e.g. antivirus software) and cloud services we integrate with, e.g. Firebase for push notifications. Services we deploy typically expose API and management endpoints, which we have been building using Netty, though we are also trying out Vert.x and it’s been fun.

Our customers can also integrate with any number of services available in their own enterprise stack, from SAML IdPs, to any REST and SOAP web services, to legacy enterprise software and even custom systems. For the vast majority of integration scenarios, our designers look no further than our visual integration tools (to both call and define HTTP-based endpoints). For all else, they use built-in connectors or what we call Smart Services, i.e. pluggable units able to retrieve and transform data or make updates.

Smart Services are made available in our business process designer as well as in our “expressions language” — a spreadsheet-formula-like language ubiquitously available to configure the most disparate aspects of our platform. The expressions language can be run embedded in other services or as a standalone service itself. For example, our public docs use an expression evaluator on AWS Lambda to let designers try sample expressions live.


Development and deployment infrastructure.

As high level an overview of our technology stack as this is, it would be lacking if it did not include some detail about our development and deployment infrastructure.

The basics: we host our source code on GitHub, we do much of our development in IntelliJ IDEA, and most of us love Sublime Text. We build with Gradle and we are already using its newest build cache feature. Our development setup runs services in Docker containers, so we can share pre-built ones and only re-build what has changed locally.

We run most of our tests (half a million of them) on every push, which is quite a lot — we set up Jenkins in a multi-master configuration, so it does not blow up. We collect all kinds of build, test, and deployment metrics for analysis and reporting, using Grafana. E.g. we report on outdated libraries, so we can more easily prioritize the work to keep our codebase up to date with third party dependencies. We automate all our infrastructure configuration and provisioning using Ansible and Terraform.

We created great tools to make us better engineers. We have a reaper job that automatically detects and quarantines fragile tests, and then assigns technical debt tickets in JIRA to the teams responsible for them. We do test runs on automatic merges of candidate branches to detect probable conflicts as early as possible. We have a bot that reads codebase metadata to tag relevant design docs, checklists, and code reviewers on pull requests.

Finally, we have built fully automated workflows to run instances of Appian on AWS. We stand up new sites daily on the latest master and multiple standard configurations, as well as on demand on any fork/branch and custom configuration — very handy for testing and debugging. All of this is managed on our own corporate instance of Appian. What can I say, kicking off a test site from my mobile phone never gets old.

The technology stack of a software company says a lot about it. Some of the technologies mentioned here have indelibly sculpted our DNA, others may only be on our radar through their transient fame. I hope that by providing a glimpse into our mission, our culture, our tools and our processes I have conveyed not just a list of more or less familiar technologies, but a sense for what will always make our own technology special.


Written by

Marco Pescosolido

Marco Pescosolido is Vice President of Engineering at Appian.