Recently we had the opportunity to visit Appian at its new headquarters, sitting appropriately at the apex of the Virginia Technology Corridor, at the top floor of the tallest building in Reston. From this vantage, Appian’s offices offer a lens on just how far they have come in the last decade, today representing the largest and most successful “pure play” BPM vendor, and possibly soon the first success story for an initial public offering (IPO) to come out of the BPM market.
Although Appian’s revenue figures are not public, its recent infusion of nearly $40 Million of private equity capital, assumed to be the single largest investment in BPM history, was done with a valuation of $350 Million by its investors New Enterprise Associates (according to a 9/11/14 article in the Washington Business Journal).
As Appian’s business has grown, so has its investment in product development, with 2014 marking a milestone year with the release of Appian 7.5 and significant advances particularly in the areas of mobile apps, data management, user experience and cloud delivery. On the latter, this year Gartner ranked Appian Cloud as a “Strong Positive” (its highest ranking) in the Gartner MarketScope for Business Process Management Platform as a Service. Notably, Appian was the only vendor to receive this ranking, with the rest rated as “Positive” or lower.
Validation at Appian World 2014
Earlier this year we saw validation of this momentum at its annual user conference,Appian World. Traditionally one of the best bellwethers of the BPM industry, Appian World offered a snapshot of not only the success of Appian, but also just how exciting and transformative the BPM industry is right now.
One of the first sessions was by CME Group, the world's largest derivatives market place who manages more than "$1 Quadrillion" in annual transaction volume (that is one thousand million million or one thousand trillion). CME states unabashedly and without reservation that they run their business on BPM (specifically Appian's BPM platform). In a relatively short period of time they had launched nearly 200 new products on the Appian platform, realizing faster time to revenue, and formalizing their focus on Customer Experience, for which they credit BPM for being uniquely able to deliver.
CME offered some valuable lessons for achieving measurable success which echo the best practices we always recommend: stick to quick releases, scale the team with the growth of the program's success (i.e., make the internal team part of a growing BPM-enabled portfolio of new applications and capabilities); develop a "metric culture" to ensure the results are measurable, and leverage customer engagement as the vehicle for gaining/maintaining management buy-in.
The latter point (focus on customers and growth) was perhaps most notable and a common theme throughout the event. CME spoke specifically on its focus of "BPM for Revenue vs Efficiency" – emphasizing that BPM isn't simply or foremost about saving money, rather it is about making money and growing the business. BPM is about the customer.
The BPM-based Application Platform in the “Age Of The Customer”
Earlier this month Forrester Research released a report entitled “Predictions 2015: The Age Of The Customer Is Set To Disrupt The BPM Market,” authored by lead analysts Clay Richardson and Craig Le Clair (among a few others). This report presents a change in traditional BPM market segmentation. Specifically, it argues for a shift away from characterizing BPM in terms of how it is designed (in Forrester’s terms “Human-centric” vs “Integration-centric” vs “Document-centric”) to instead splitting it according to whether the intended use is “Operations-centric” or “Customer-centric.”
This segmentation doesn’t imply that customers are not part of business operations. Rather, it suggests that BPM as a middleware platform, whether focused on content management or data integration or process automation, traditionally supported the operations side of business, and focused foremost on driving costs out of production and operations (read “process efficiency”). Yet in most cases these processes and applications were rarely touched directly by customers outside of the firewall.
In contrast, Forrester argues that in 2015 and beyond, BPM will be used increasingly for front-office versus back-office benefits, and will indeed be touched directly by the customer, and that customer experience teams and “design thinking” will displace the traditional “efficiency expert” orientation of process improvement teams and IT-centric roles traditionally driving BPM initiatives.
This shift represents not so much a change in direction, but more the expansion of BPM’s mission and potential benefits. As is evident across a growing number of proof-points, including those heard at Appian World from CME and others, today the most innovative, successful, and certainly the largest firms in the world run their businesses on BPM – specifically leveraging BPM as the fundamental application platform responsible 24/7/365 for generating revenue, managing the customer the experience, and enabling innovation.
Thus, if we view “Operations” and “Customer-facing” as the two distinct hemispheres of business activity – internal and external functions, together forming the whole – BPM is today addressing the entire organization. Yet as Forrester points out, this does require further evolution of BPM offerings. Notably, as roles involved in BPM shift from IT to business, the manner by which applications built on BPM must also evolve. In particular, this points to the emergence of “low-code” platforms that favor configuration over coding – with users building applications via drag-and-drop rather than sitting in front of a complier.
Although some have touted a “codeless” orientation, this is a bit of a non sequitur for building actual, mission critical applications. New capabilities can be introduced onto a BPM platform without requiring code, but the end-to-end delivery is going to require at least a modicum of coding at some point. Yet what modern application platforms such as Appian enable is a clean separation of concern, where most work is done through drag-and-drop configuration, and actual coding is kept to a minimum.
Iterative and Incremental Development (IID)
One of the most important measures for modern application development is support for Iterative and Incremental Development or “IID” – notably, the ability to develop and release applications in individual modules. This is the foundation of all Agile software development, from Extreme Programming (XP) to Scrum, with each focused on improving software quality and application design by closely aligning and validating the requirements of the customer (whether internal or external) through iterative releases of often 30 days or less.
Analysts such as Gartner heavily emphasize IID as a metric for evaluating application platforms and frameworks for application development. Yet what is perhaps the most critical measure, and one too often overlooked in analyst round-ups, is how the parts come together to form the whole. Specifically, how are individual releases combined and made to work together?
Part of this is the actual build and release process. For example, Appian allows for essentially a “one-click” build process once the BPM-based app has been designed and configured. Yet as development orientation shifts from monolithic applications to a more agile “app store” model, maintaining alignment and consistency between each app is essential. It is not a matter of simply performing regression testing or confirming they are compatible.
Delivering a Consistent User Experience
The User or Customer Experience (UX/CX) must be unified and consistent, requiring both common interfaces as well as continuity of underlying process, rules and data.
This is where the advantages of a BPM-based Application Platform such as Appian 7 are most pronounced. These enable a true model-driven development approach, which at the interface level extends the traditional “MVC” (Model–View–Controller) architectural pattern. This is accomplished in part by abstracting how data is managed from how it is viewed (the traditional MVC capability). But in modern, BPM-based application platforms, the traditional MVC pattern is extended through a common interface layer, which is controlled by the process state (e.g., the context of what is happening in the process at any given time).
Figure 1 – Alternative Approaches to Iterative and Incremental Development (IID)
This approach, which is closer to the more advanced Model View View Model or “MVVM” pattern, offers the ability to define how an interface looks in any instance with each new application, and ensures each view is appropriate to the context of the specific moment. Thus it is not a single, static view imposed on each application, but a data-driven and contect-driven view where the user has a consistent experience across multiple apps, as well as a personalized experience based on the device they are using or the task they are performing.
The way Appian delivers this capability is through "SAIL” – its new Self-Assembling Interface Layer. SAIL provides a framework for app construction to define how content and data are presented, according to the design objectives for the app, regardless of where it is accessed. Then, utilizing a “write-once, deploy-anywhere” model, the app can be deployed to and accessed from any desktop, web or mobile platform.
SAIL’s platform-independent ability is enabled through a fully declarative UI that allows for both the acceleration of app development, as well as a richer user experience by dynamically generating the apps native to each target platform. Thus apps can offer a consistent look and feel, while also leveraging the native platform capabilities (e.g., by deploying natively to iOS for Apple devices, while also natively to Android for those devices). SAIL offers a notable example of one defining attribute of modern application platforms, relating to what Forrester Research has termed “Four-Tier Architecture.” The concept of the four-tier architecture extends the traditional 3-tier architecture of App Server platforms, which was designed for PC desktops and Web apps, not multi-platform mobile devices.
In contrast, the four-tier architecture reflects how frameworks such as SAIL are designed for mobile and cloud, but foremost to be device and platform independent. It abstracts not only the Presentation, Application, and Data tiers (the traditional 3-tier model, nominally illustrated below) but introduces a fourth tier by separating “Presentation” into “Client” and “Delivery” just as SAIL does to enable device independence. This results in four new tiers: Client, Delivery, Aggregation, Services.
Figure 2 – Appian Delivers on the New “Four-Tier Architecture” Needed for Modern Applications
Appian fully addresses the four-tier architecture model as shown above, however, it is worth pointing out that it goes beyond as well. Forrester’s model remains relatively data-centric. It deals foremost with the need to have data presented in the way that makes the most sense for the platform on which it is accessed, as well as the fact that data can come from any source. This means data must be transformed and aggregated into a single composite for the user.
Appian SAIL delivers the first part of this, and Appian Records(discussed further below) offers the latter. Yet while Forrester presents this new architecture as a customer engagement platform, it stops short of addressing how the data is used. The BPM-based Application Platform is perhaps a better example of a true engagement platform, which deals not only with how data is accessed and presented, but also how it is used. This distinction represents part of the shift from data-centric to data-drivenapplications, or what is sometimes called a data-firstapproach.
Data-Driven vs Data-Centric
With traditional application development, most often you will find the orientation is framed around an e-form linked to a data table, where the data model is largely defined by the fields in the form. The application is designed from the perspective that user interaction is simply data entry. For example, an Order Entry application may likely be focused on completing an order, and where there is workflow within the app, it is based on what predefined fields are required to be completed. This is a data-centric approach, rather than data-driven or event-driven.
This type of data-centric scenario is what the first generation of BPM emerged to address. For example, the Order Entry task is just one step (or at most a handful of steps) in a broader process involving the customer, from sales to on-boarding to fulfillment of the order. So BPM initially offered (and in many cases still does) a process-centric approach to complete the various tasks involved in an end-to-end process, such as order-to-cash or procure-to-pay.
The process is not defined simply by the steps needed to complete the form, but is aware of how the data in the form is used to perform the process. These types of processes are deterministic, where all possible paths are pre-determined or known in advance, no matter how complex the pathways may be. The direction of the process is determined by the pre-defined path and current state, where state is determined by the preceding activity (e.g., where the process is relative to its completion).
Yet while process-centric apps offer an advancement over data-centric apps, modern BPM, and what we expect from a modern BPM-based Application Platform (such as Appian) is the ability to support data-driven and event-driven apps. Case Management apps, for example, are both data-driven and event-driven. In contrast with process-centric apps, Case Management processes are specifically non-deterministic, where the objective is known when the case starts, but the specific pathway for reaching it is determined by what happens at each stage – and in particular what data is captured and added to the case. Unlike the traditional BPM process where state is defined by a predetermined sequence of steps, the state of the case is determined by the content of the case and rules and policies applicable to it.
Appian has always been an event-driven and data-driven BPM platform. Appian BPM has from its earliest version been able to support the types of dynamic processes involved with case management. Cases evolve over time in the direction of achieving a goal, often in unpredictable directions, requiring the ability to jump forward, jump back, re-do or otherwise perform work in a sequence that can’t be determined in advance.
A case is different than a standard process – not just in regard to the qualities described earlier, but in terms of its overall lifecycle. It is typically longer-lived, as a case may be restarted at any time, or remain “living” in its current state for any duration until another event occurs.
Where an executed BPM process provides a transactional thread across various others systems (i.e., the order-to-cash example cited earlier), a case captures the context of “what happened” in a virtual case folder which serves as the long-lived system of record of the case. Knowledge captured during the performance of the case, because it is not simply following a predefined path, provides both a critical business record as well as a launch point for new tasks and sub-processes.
Launched in 2013, Appian Records is a capability which offers specifically that. An Appian Record provides full engagement of information within a BPM-based app, on any device (leveraging the dynamic generation capabilities of Appian SAIL). Users can browse and filter data from inside or outside Appian, including internal and external sources, using a single intuitive interface.
Processes can be launched from within a Record, or otherwise tracked and/or worked on within the same environment. A social interface allows apps built on Appian to facilitate better communication and faster problem resolution, by allowing users to discover, securely share, comment and collaborate on records, as well as to share comments and information with key stakeholders.
Appian Records extends this to full enterprise reporting, providing real-time views and reports on all Records, allowing users to make more informed decisions, with a single view across all data sources. Ad hoc tasks can be launched and associated with a Record, capturing the context and history of the Record lifecycle with reportable data.
Appian Records allow work to follow the worker, with the cohesiveness of a single environment (single point of access) whether on a smart phone, a tablet or desktop PC.
An example of an Appian customer leveraging Appian Records is Punch Taverns, a winner of the 2014 Global Excellence Award in BPM and Workflow, sponsored by BPM.com and the Workflow Management Coalition. Punch Taverns is one of the largest pub and tavern operators in the world (through a leasing or franchise type model) supporting over 4,300 locations across the U.K.
Punch Taverns uses Appian BPM to manage the rollout of every new location, with each pub representing a single Appian Record. Each pub is represented by a distinct Record for the entire lifecycle of the location – from initial startup to rollout to operation. Within there are milestones, sub-processes, reports (both historic and real-time), checklists and guidance or coaching for users. As shown below, the same data and same capabilities are available on any device, allowing mission critical information to be made available for workers at headquarters and in the field.
Figure 3 – Appian Records Provides Complete Management for the Rollout of Every New Punch Taverns Pub
By driving automation, mobility and data access, Punch Taverns reports that their overall business capacity increased by more than 25% without adding additional staff. They use the metric of current pub investment activities in the field at any time as a predictor of future revenue increases. For comparison, prior to the deployment of Appian (in 2011-2012) they were able to support £38M in investment across 400 pubs. After deploying Appian this increased by 28% in one year, allowing them to support £48.5m in investment across 476 pubs.
Other benefits include certain key processes (related to property management) increased in efficiency such that documents can be developed, signed and completed in 10 minutes compared to multiple days previously. Apps built and deployed on Appian have led to smarter, faster decisions and actions across the entire Punch Taverns business. As one key stakeholder put it, “Appian is enabling us to make a steep change in our business processes. This is allowing us to respond to an increase in regulation within our sector while improving our efficiency and speed.”
Traditional approaches to application development are typically far more procedural and programmer-centric versus Appian’s BPM-based Application Platform. Appian presents a declarative, model-driven development approach that favors configuration over coding. This orientation is often referred to by analysts as a “low-code” method, with the majority of capabilities enabled via drag-and-drop from a palette of BPMN elements, prebuilt services, and wizard-based configuration.
Appian presents a business-centric approach to application development that should be both familiar and favorable to BPM professionals, focused top-down on process, rules, user data and interaction (rather than data structures integration). By extending the transactional management of traditional BPM with the adaptable, data-driven and event-driven attributes of Case Management, Appian provides a formative BPM-based Application Platform to build apps that allow their customers (in the words of Punch Taverns) “to operate faster, with increased business results. What we were able to do completely changed our working processes.”