2

3
1

Who we are.
What we think.
Note From
Decisions Founder

Hi All,
Thanks for taking the time to download and read this eBook. This
is a very personal eBook for me because it explains what I have
dedicated my career to and why I chose to start Decisions with my
Co-Founders: Heath Oderman and Kevin Lindquist.

You will notice that this ebook is full of first person statements and
opinions. That is because this book is meant to communicate our
opinions about technology that influences product direction at
Decisions.

For customers and partners that we have had the privilege of meeting
in person - you might find some of this reminds you of what we
talked about over a dinner or drinks, but because we do not get to
sit down with each of you and explain what Decisions is all about, I
decided to write this so you can get insight into “what is Decisions.”

Hope you enjoy.

Carl Hewitt
Founder - Decisions.com
9/27/2016
Executive Summary
Most business software is defined by the problem it is trying to solve. Business
process and rule software is different because it is defined by ‘how’ a problem
is approached, and leaves the actual problem to be tackled to a person using
our tools.

This ebook is structured to help you get to know us - our history, our focus, and
most importantly the foundational ideas that guide our product development.

Decisions is a grand experiment to see if a better product can win. Decisions

does not have a large sales and marketing organization. We believe in our
product, and we think that companies and individuals will be won based purely
on the merit of the software.

We think about software and business a bit different than many of our peer
organizations.

- We think businesses can be built with a single focus on ‘better product.’

- We think the measuring stick of success is customers being successful
with a product.
- We think software needs to get smarter - and to do this tools need to be
available to allow business people to make changes.

This thinking comes from a history of trying to empower companies to make

better changes, more quickly.
 017
2

015
2

010
2
0 0
2 0

9 0
1 9

Decisions: A Brief History

While Decisions, LLC was started in 2010, the real beginnings date back to the
late 1990’s. Carl Hewitt, founder of Decisions, was CEO/Founder of a company
called OOP.COM. OOP.COM was focused on providing tools for developers to
create and reuse business concepts - business objects. This is now a common
design pattern, but was innovative in 1995.

Decisions - the thought process - started when analysis revealed that developers
enjoyed building reusable things - but not actually reusing them. Reusability was
important to Carl, and therefore OOP.COM, not only because it allowed systems
to be built faster, but also provided a place for one change to affect the behavior
of the entire system. By adjusting an object’s behavior - if reused - the entire
system would be affected.

If developers would not reuse… maybe tools should exist for non
software developers to assemble systems from ‘business objects.’
This was the idea that launched Decisions.
OOP.COM developed a product called CCP (Component Coordination Platform)
that allowed software components to be linked together by non programmers.
Programmers would build these components and business analysts would use a
graphical interface to assemble them to solve various tasks. CCP found success
in assembling voicexml based telephony applications.

In 2003, Transparent Logic was formed out of OOP. Transparent Logic focused
on rebuilding the ‘analyst assembled’ software concepts with a focus on the
tooling, making it much slicker and more intuitive. LogicBase (Transparent
Logic’s core product) focused away from telephony and onto business rules and
workflow. Transparent Logic (after 3 years of R/D and a newly released product
just getting initial traction) was sold to Symantec in 2008.

Decisions was founded in 2010 post the integration of the of the technology
and team into Symantec - with the added focus of providing automation that is
delivered in the browser (no client install) and an increased focus on a broader
range of business logic including dashboards and more advanced rule scenarios.

The goal of this team throughout all these generations has been the same: how
do we engage business users in understanding and configuring key business
logic? While the mission has remained unchanged, the understanding of how to
accomplish this has evolved significantly.

Decisions started with an initial focus on being an ‘embedded’ configuration

engine - to be the trainable brain within the next generation of business
applications. Our configuration technology has been used to provide automation
and intelligence in healthcare, finance, logistics, IT management, and education.

Once the core technology was created, we ‘embedded’ it ourselves into an

integrated business logic and process management suite. Our BPM and Rule
engine is used by companies of all sizes from the Fortune 500 to small/mid size
companies.
 ? ?

? ?

What problem are we trying to solve:

Decisions builds workflow and business rule technology. This type of technology
exists to facilitate business optimization. It’s kinda like duck tape - very useful
for a broad range of problems.

The answer to ‘why Decisions was created’ is boring at one level - because
its reason for existing is the same as any software business. Actually, if you
read a white paper from ANY business software provider, you are going to hear
the same things: Lower cost of ownership, faster change, more agile, more
adaptable, more targeted user experience, higher profit, happier customers, etc.

These problems are very real. Hordes of developers are trying to solve them
every day. The difference is the approach that we take to this.

Slick pre-built cloud applications help get work done and are up and running
fast. These applications lack the ability to conform to custom rules and business
processes beyond basic configuration. They often do 80% of what is needed,
and they do that 80% from nearly day one. However, that last 20% is critical
because it represents the things that your organization does different. Maybe
the missing piece is something that is a competitive advantage. Maybe it
facilitates a historical organization structure that is not in a position to change.
Maybe it’s some automation that makes your processes efficient. It’s difficult
or impossible to change fundamental logic, workflow and rules in this class of
products.

On the other hand, you have custom applications, facilitated by slick development
frameworks, which allow functionality to be exactly what you need; however,
these tend to not anticipate future needs and are hard to change once in place.
This approach is the most costly.

Workflow / Rule platforms seem to solve this problem - but often stray to one
of two extremes:

1. T
 o be easy to use, they are constrained to solving only simple ‘human
focused’ workflow.

2. T
 o automate real, complex business problems, tools really require a
development background to do anything. Programming is required -
often even to do simple things.
Decisions is in the business of automating … well … business. This not only
means human focused stuff (forms, communication, routing, etc.), but also
backend rule logic, data processing, dashboards, reporting, and legacy system
integrations. Solutions built in Decisions need to be (you guessed it): Easy to
change. Faster to build. Agile, etc, etc, etc. We believe that we’ve found the
sweet spot between being simple enough and solving very complex, enterprise
problems with the following two principles:

- Uncompromising focus as to ‘which skillset’ is required to do this

automation.

- Solutions to straightforward projects are simple without compromising

on solving difficult rule and integration intensive - problems.

The marriage of business rules and process automation is very complimentary

- and also unique. While there are companies that offer both a rule engine
and bpm, these two parts tend to be thought of as separate entities and not
fully integrated. In Decisions, you can use the rule engine or process engine
without leveraging the other, but these products are built on the same set of
base technologies and with the same focus on non programmer creation and
configuration.

In short: the ‘what’ decisions does is covered in other ebooks and all over our
site. The ‘why’ and ‘why is it different’ is the focus of this ebook.

Our Principles - How we make Decisions:

Building a software product is about making literally hundreds of thousands of
both small and big decisions. These decisions eventually form both what the
product does as well as what its limitations are. It’s easy to make a mistake - a
decision that either distracts from or hinders what you are trying to do. Undoing
these decisions is time consuming and costly.

The decisions span a broad range of areas.

- Which technologies do we include/build on?
- Do we build this feature on the client side or server side?
- What do we do next?
- How to we present a concept?
- Etc, etc, etc.

There are a number of questions that we ask, debate, argue about when making
these decisions. While this is not a complete list, it should give you a reasonable
insight into what is important, what drives us, and why Decisions exists.
Does it support central product objectives?
Obviously, the first gate is ‘does it make us a better rule engine and/or
workflow engine’

Here are our objectives in a bit more detail:

- Smarter Workflow Interactions: leveraging business rule engine.

- Active Business Logic Management and Execution: (leveraging workflow
concepts). This is a natural marriage and the central theme of all Decisions
offerings.
- Easier Integration: Automation of systems and rules is as important as
traditional user based workflow systems.
- Actionable Data: Reports and dashboards must be actionable. Users need
to be able to interact with data no matter where it is.
- User Friendly: Users might interact with the system in a variety of ways.
While the default interaction paradigms provided by product must be
good (or great), we have to facilitate meeting users where they are (even
if that is by custom coded forms, email, text messages or telephony).

Is it usable by (non programming) business analysts?

Decisions exists to allow non programming resources to be able to create, evolve
and understand business rules, workflow, forms and reports. Because of this, the
second question is always, ‘Will a business analyst be able to use this?’

There are shades to this question, however:

- What is the learning curve (wish this was always zero, but that is not the
case)?
- Is there a way to build it in such a way that it more resembles another
features in the product?
- Should we expose this feature out in such a way that it is more of an
administrator or technical user configuration option?

All Decisions designers are built on the pattern of ‘assembly’. Small pieces are in
a toolbox and are assembled or arranged in a designer representing a business
concept. These designers provide feedback about the configuration, what is
missing, and validity. They also provide tools to watch/test these configurations.

It’s assembling, not programming

assembling means, at very minimum, no code.
Many tools claim to be codeless, but often this means that there are scripts,
configuration files, structured English, business domain language, and other
facades that merely redefine what code is. It’s ‘code for business people’ instead
of ‘code for software developers.’ In these tools, order to perform a step in a
workflow/execute part of a rule/get data for a report, there is a window where
instructions need to be typed (SQL/JavaScript/Structured English, etc.) – still
that is coding.

There are other products that exist that are actually codeless. However, this is
often accomplished by limiting the types of problems that can be solved. For
instance, creating a form that can be saved and edited might be able to be built
in a tool that requires no coding - but can’t limited in terms of doing complex
validation against external services, complex routing or storing in legacy systems.

Providing a codeless set of design technologies is not enough. These tools must
be able to be understood and usable by non software developers. There are
many aspects of this, but some of them are:
• Designers are visual and built with a maximum amount of feedback and
assistance. This includes attributes like: drag and drop components, the
visual assembly of items, immediate visual feedback of what is missing or
invalid and more.
• Testing or a preview of the results needs to be fully integrated and a click
away. The ability to see how a rule runs, what steps a flow will take given
data and interaction, how a form will respond to a user, and what a report
looks like is critical.
• Deployment needs to be automated or automatic.
• Management should be fully integrated. Backups, change notes, versions,
and comparison tools.
Our thinking is inspired by more mature industries. The examples are everywhere -
most of us feel very comfortable ‘assembling’ things that are well designed, even
though the individual components may be black boxes themselves. Consider
the following example: Installing a gaming system, dvd player or tv is able to be
done by almost anyone that does not have a fear of electronics. Components
that are a mystery as to how they work (how does that silver disk produce those
sounds and sights) can be integrated by normal people. The plugs fit only in the
right holes and there is clear feedback when things are and are not working.

Is it better than writing code?

Almost every company that buys a rule or workflow engine considers ‘writing it
from scratch’ as an option. Products like ours are designed to produce similar
or better results than opening up an IDE and starting to write code.

For the types of problems that we are designed to solve - will the feature produce
The question is, for the types of problems that we are designed to solve, will the
feature produce outcomes that is at least as good, if not better, than as creating
it custom? Will it create an outcome (or product?) that is much less effort with
features that are too expensive or difficult to complete in custom development?

We are software developers - and actually like to write code - and have sometimes
recommended that customers write something from scratch (where we are not
the ideal fit for the problem being solved).

Does it scale?
Our platform is often deployed in high transaction and ‘big data’ environments.
New features, steps and patterns are considered in the light of how it will work
in these types of environments.

When adding features that might impact performance, we run extra automated
stress tests to ensure that the performance goals our customers have set are
met.

Is it optional?
Each feature - by its very nature - increases the complexity of the product.
Ideally, new features that are added are ‘extra configuration’ that can be done
rather than ‘new required steps’ that must be done.

Additionally, some organizations want to use a limited subset of the features

and options that are available to the business analysts using the designer
technologies.

Our goal is to minimize the set of steps it takes to get things working and provide
layers of prebuilt functionality to create highly optimized (smart) interactions
and rulesets that can be built on this easy foundation.

How does it impact end users?

In some cases – especially in workflow process automation – allowing the analyst
to create user interactions is important. Additionally, some organizations or
applications require overall management of basic elements of a user interface
like user authentication, hosting of dashboards, providing a service catalog for
user requests, etc. These elements, while useful, are supporting elements to the
underlying designers.
The presentation of the user experience is often dictated by a number of factors
including: how do the users want to interact with the application, what other
software is involved, the different types of users and the technology they have
available and more.

The decision to use or not use user interface components provided by the
optimization tool should not force a compromise in terms of the value that the
tooling provides.

How easy is it for us to expose to developers

to extend and change?
All of the business user designers are based on the pattern of ‘assembly.’ Taking
pre-built pieces and tying them together, arranging them and even in some cases
providing wizards for non technical people to build new ones (like integrate with
a database).

These pieces include:

- Flow steps
- Rule verbs
- Page and form components
- Reporting data sources and filters
- Integrations
- etc

Who builds these pieces? Software Developers!

Decisions provides thousands of these pieces out of the box, and most customers
never have a need to ‘write code’ to build their very own pieces.

Decisions own software developers add these pieces to the product using the
same SDK that we make available to our partners and customers.

Putting tools in the hands of business analysts is not an ‘anti developer’ move.
It is allowing them to control their own logic and processes without involving
software developers to make changes that could be done by the business.
Developers are needed to both extend the capability of the platform and
often build or integrate the designer capabilities with other software packages
and applications. The SDK/API for the design tools needs to be central to the
technical architecture. All interesting elements need to be able to be extended
or replaced using this SDK.
In the case of the Decisions Platform, software developers can:

• Access all services via API’s. (REST, WCF, Webservices)

• Add 3rd Party Libraries
• Extend Designers
• Create New Flow Steps
• Create Rule Verbs
• Create New Data Sources (reporting)
• Create New Filters (reporting)
• Create or Expose New Form Controls
• Create or Expose New Dashboard Elements
• Create or Expose New Data Structures
• Create New Business Services
• Add Actions to Existing Entities
• Access the core Decisions Development Framework (DDF) that includes
things like an aspect oriented programming framework, an object relational
mapping, cluster aware caching, and much more.

By providing tooling to the business analysts to make appropriate changes

within the application, not only will those rules and process changes happen
more quickly, but development resources will be freed up to focus on other
issues rather than spending so much effort making business logic changes.

Does it force us into a starring rather than supporting role?

The tools and designers in the Decisions Platform are architected in such a way
that they can be both a foundation of an application and a contributor to an
application or process. All elements need to be able to be used independently
of the other elements (forms outside the portal, rules outside flows, dashboards
embedded in other portal technologies, flows without user interactions) as well
as be able to be combined as appropriate.

While all of the elements are useful in some business applications and problem
domains, they might not be useful in your problem domain or business. The
underlying structure of these tools needs to account for this.

Can it live both in the cloud and on premise?

Many applications are moving to the cloud, maybe even most applications are
moving to the cloud; however, for a variety of reasons on premise software is
often required or unavoidable. While the benefits of centralizing the management
and administration of applications are clear, not all organizations or applications
are there. Decisions was built for the cloud and it was built for on premise
environments. The exact same software that runs in the cloud can be hosted on
premise or in your own managed servers at other public cloud providers. The
choice of where you run the workflow/rule engine is up to you.

Additionally, we recognize that even if you a run in the cloud, a safe and robust
mechanism is needed to allow secured access to on premises resources. Very
few organizations have all systems running in the cloud and accessible – even if
this is their strategic direction.
Conclusion: Carving out
a space in the middle.
There is a balancing act to trying to be the ‘product in the middle’.

There are a set of companies in our space who care only (or seem to) about
operating in big, enterprise, complex environments. Their product directly
seems to be about supporting every new protocol, standard and enterprise
architecture. These products take tons of trained people to deploy and maintain.

The other end of the spectrum is companies whose focus seems to be on creating
the simplest development/deployment experience. These companies produce
really nice looking tools that are easy to use, very quick to learn - but are very
limited in the range of solutions they support. There is something valid about
their target - many business problems do not have any real complexity to them
and simple tools can do a lot (this is why Excel - and clones - are still the most
valuable business IT software ever created)

Decisions wants to be in the middle. We play in big enterprise systems (we

recently did a proof of concept where we had to process 100M medical claims
in a day) yet want to allow systems to be created and deployed quickly - with
customers often having something running in production in 1-2 days after initial
installation.

Our mission:
To create a set of Business User accessible technologies that allow business
users to create and evolve critical business logic. To have these tools to be as
easy to use as technologies that are targeted only at simple business problems
and operate in the most demanding environments and transaction loads.
2017