A customer recently asked: “When and why is Decisions a better choice than custom development?”. This is not an uncommon question, and an important point of best practice when you consider Decisions as a part of your enterprise stack.

Why Decisions over custom development?

It is not really an apples to apples comparison, but the question from management is logical. What are the potential benefits in dollars, time or something of tangible value that Decisions will bring relative to custom development?

Our understanding is that currently you follow traditional .NET development cycles for every new application, and every change to existing applications. Especially in a financial services segment that is subject to continuously changing regulations and the potential for rapid changes from the business, IT can get bogged down with business logic updates that take time to code, review, test and translate with the business.

The mission of Decisions is to engage a new class of user – that doesn’t need to know how to code – to participate in the software design process for the rapid evolution and deployment of new business logic. This class of user may not design and deploy an entire application – but this class of user will be able to create new and change existing business logic in the form of business rules, business process and policy, and forms.

Where the project is business logic focused – routing data, collecting data, evaluating data, it could be as much as a 50-75% time savings. Where the project is more complex and requires custom database architecture, extensive front end design, and other sophisticated programming needs – it might be a 0% time savings, but it would be easier to change down the road.

This time savings and potential for easier changes and updates to the business logic comes from the use of Decisions visual development environments. A workflow designer where the user drags, drops, and configures new business processes without writing code. A rule engine where a user visually constructs statements of business logic as they would write them in a requirements document or draw them on a whiteboard. A forms designer where they drag and drop form components like buttons, dropdown lists, labels and other elements to create points of user interaction to collect data. All of these activities bring time savings in the form of less time translating requirements, and less code-level skill needed to accomplish the development tasks.

To help with this understanding, here are a few customer stories:

F500 Financial Services Customer – Uses Decisions to monitor and enforce SLA’s with their affiliate banks. Where limited custom development resources were engaged as they were available to build new additions to other systems – this customer replaced the collection, validation, scoring, and follow-up of their affiliate banks reports with an automated solution that let’s business analysts edit the rules and scoring mechanisms over time without engaging developers.

Leading Office Supply Retailer Customer – Uses Decisions as a logic layer to automate tasks related to provisioning new PoS systems for their retail locations. Where before it was a highly skilled and certified administrator who had to log into a Microsoft System Center console to get all of the work done, today junior team members can initiate the work and based upon rules (and where needed admin approval) the work can complete on its own resulting in significant time savings. This project started at Staples, and after its success Staples Canada engaged Decisions for the same services.

Other customers have similar stories of automating what used to be manual labor – or freeing up skilled developer resources to focus on solving complex and interesting problems instead of drudging through simple business requirement changes.

The honest answer to “how much time or money will this save me” is it depends. Hopefully this explanation can inform the potential in your business.

When is Decisions a better choice over custom development?

Most of the things where we do not add value are things that we tend to NOT use our technology for.

1. Marketing-driven, customer facing web applications.
2. Project with a very intense and dynamic UI (think of Facebook or Ebay’s websites).
3. Hardcore development (network socket programming).

There are some things where we are on the bubble. In these cases we tend to wrap up programming into pieces that can be re-used within our visual development environments.

Example: Creating a controller for a mainframe screen scraping application. You could get the data, parse the fields out, etc.; but the graphical model for this does not really add much value and easier to do in a real language. There are steps to parse the text, extract values, etc. If the code is built so it can be consumed by a step in a flow, you get the best of both worlds.

Decisions was designed as an environment to coordinate small pieces of reusable code. Because of this, finding elements that are better to be done in code is not invalidating the business relevance and efficiency of the graphical environment. Here are some rules of thumb we use to determine when a new step is usable.

• Would take many existing steps to accomplish the task
• The path to assembling these steps is not obvious
• Maintenance of the resulting logic is easier in a visual development environment than in code
• This concept is reusable in other flows and applications
• The concepts represented by the composition of many steps is not something that a business analyst would care about, know or understand
• Using steps would require execution paths that are not ideal for performance (ex: looping through 1M rows vs having steps to call a SQL query)

More Examples

Below are some basic examples of what this customer plans on using the product for:
· API Scripting to main data source (Web App)

· Writing data back to main data source (Web App)

· Make decisions off of data collected and calculations

· Connecting to SQL tables

· Creating dynamic end-user forms

· Initiate workflow based on form inputs

· Routing of forms

For each of these items is it better to develop custom or use Decisions, where do you get the biggest advantages and why?

API Scripting to main data source (Web App)

All flows and rules are automatically web service APIs when created in Decisions. Since to use the editor you already have the application server running there is no deployment consideration so going from the moment of starting to implement the rule to making it available as an API is only the amount of time that it takes you to write the rule of the flow. There’s no effort spent on API bindings or plumbing. That’s really not the point though. If your team is all developers and developers will maintain the API scripts, then code is a more natural design language for them to use. If you want people who do not write code to maintain the API scripts – the workflow, the rules – then Decisions provides a massive advantage.

Writing data back to main data source (Web App)

The fundamental question here, similar to the one above, is: do you want business minded people evolving and changing this mechanism or do you want this maintained by developers exclusively? Responding to the ever changing business world, regulations, and strategic initiatives is what matters so making sure you’re using tools that empower the team members you have available to make these changes is more important than picking a tool that allows you some shortcuts in implementation.

Decisions has built in integrations to databases, services, and other external systems that make the interactions with a main data source something that usually works in Decisions right out of the box. This means that Decisions can very quickly produce flows that can receive data and write that data to a main source. This can usually be done more quickly, or equally quickly to code directly, and more importantly – as you evolve this to include business rules, limits, tasks, etc Decisions ability to evolve sets it apart.

Make decisions off of data collected and calculations

Using Decisions Rule Engine and Workflows you can evaluate, branch, sequence and orchestrate logic that leads to different outcomes in your business process.

Connecting to SQL tables

Same as a previous answer – Decisions has built in integrations to databases, services, and other external systems that make the interactions with a main data source something that usually works in Decisions right out of the box. This means that Decisions can very quickly produce flows that can receive data and write that data to a main source. This can usually be done more quickly, or equally quickly to code directly, and more importantly – as you evolve this to include business rules, limits, tasks, etc Decisions ability to evolve sets it apart.

Creating dynamic end-user forms

Honestly, this is an area where we may be weak depending on your use case. If you want a targeted, efficient, action oriented form – we’re GREAT. If you want a really dynamic and form with pixel perfect design by today’s standards – you’ll probably want to develop your own forms and use our “external form” workflow steps.

Initiate workflow based on form inputs

User interaction is a primary method of kicking off a workflow. Along with API calls or scheduled jobs.

Routing of forms

You can use Decisions Rules and Flows to dynamically route forms based on conditional logic that is visually developed and understood. Your documentation is what is actually running.