Let’s take Tesla - famous for selling electric cars that have range and performance. Tesla cars are pretty  good at autonomous driving – and it owes this ability to data! For example, on a snowy day, when snow covers the road so that you cannot see the painted lines or even the signs, the autonomous driving model can still do a near-perfect job of driving the car. The reason that a Tesla car can do that is that Tesla cars collect so much road data which is stored on centralized servers at Tesla. This data is shared among all Tesla cars which use this data together with other technologies such as machine learning and artificial intelligence to make better decisions. Even though you can program a car to self-drive, you need rich, accurate data to make optimal decisions.  You never know what can happen on the road ahead! So, does Tesla only sell cars? Or will they become the holder/sharer of the road data for other car and trucking sector producers. Just as Google, Apple, and Garmin (among others) generate and monetize road data, so may Tesla.

F-16 Falcon is another example worth exploring. The F-16 is an amazingly capable military fighter jet, but given the design of the jet, it cannot fly without computers that take instrumentation data from sensors and then continually adjust avionics outputs. These adjustments are made in micro- or milliseconds, by processing millions or even billions of instructions. These instructions and decisions are solely driven by enormous quantities of real-time instrument data and non-instrument data.

As we all know, good data can result in good decisions - and bad data almost always results in bad decisions. In certain industries, people manually clean up data to optimize its integrity. Since applications depend on good data, data needs to be perfect or near perfect. So where does a business process management system like FlowWright play in all this? At the end of the day FlowWright is in the driver’s seat: automating data collection, making decisions based on data, and acting on internal and external systems through integrations.

For organizations around the world, FlowWright executes and facilitates 100’s millions of process tasks and decisions every day. FlowWright executes processes in the background using its engine services and child processes – and sometimes companies choose to publish FlowWright processes into memory, making use of FlowWright’s real-time Microservices.

Data is king: decisions are made based on data. Twenty years ago, a process automation platform used the limited process data available to make decisions or to execute actions, and that was the whole ballgame. But today, process automation platforms go further: they re-use old data to analyze and optimize processes. One such feature in FlowWright is the Critical path algorithm which computes the longest path through connected workflow steps. In the case of FlowWright, processes not only have nodes and timing, but also have milestones – basically combining two dissimilar but related types of workflow steps: a node may contain either length of time or (in the case of a milestone) refer to a specific date/time. FlowWright’s algorithm computes critical path using a meta model instead of a direct model containing the longest path. By using a meta model, FlowWright is able to calculate the critical path for any start date and determine the longest path. This meta model also comes in handy when running a process: there are 2 critical paths 1) a design time critical path, and this critical path is based on the configured values of nodes or tasks, and 2) the runtime critical path that is based on runtime values. Both paths are computed based on decisions, but the driver of these decisions are the data from the meta model.