What's Wrong with Traditional Development?

A customer recently asked why they should choose a BPM approach like ours over a pure Java-based solution. I think it boils down to a few key factors.

A lot of customers I work with chose our BPM over traditional, code-based development.  While our SmartBPM is certainly not the solution for all application projects, I have sure seen it work for process- or rule-driven applications that must manage large amounts specialization, or applications that must change frequently and repeatedly. Here’s what I have observed:

  • Traditional development doesn't "directly capture objectives". Traditional coding starts with business requirements that must be translated into specifications and then implemented by programmers (who often know little about the business). SmartBPM collects business objects directly in a format that business users understand: process flows, rule forms, WYSIWYG screens. The result: requirements are immediately executable, the business can see what they are getting, and you get to application faster and more accurately.
  • Traditional development lacks unified process and rules.  Traditional approaches leverage code or an embedded process engine (i.e. JBoss jBPM) to hold procedural definitions and another engine (a BRE, more code) to hold declarative business rules, and thus require human programmers to manage the relationship and interface between the two (When during the process should rules be called? Where do rule changes need to be implemented?). SmartBPM puts these in the same engine, allowing rules to be automatically executed when the data requires, and "auto-positioning" rule changes wherever they required.
  • Traditional development lacks situation specialization.  The "coarseness" of traditional code (the class and the method) means that specializations for customer, product or channel must be accomplished by complex chains of if-then-else logic, or by copying full object classes and maintaining multiple copies of the same logic.  In either case, manual positioning and coding of specializations is required.  SmartBPM understands that business must specialize their processes and rules across customers, products, geography and channels, and supports a granularity of rule definitions that allow these delta's to be "dropped-in," with the engine incorporating as needed into your process, rules and even your screens and integration points.
  • Traditional development locks in an architecture choice. Traditional code is designed for a specific architecture: if you want to run your application as a series of services, you must decide early own what your entry points will be, because re-engineering services later on requires expensive rework.  SmartBPM allows you to model your business requirements and deploy in any architecture that makes sense: if you need a process exposed as a service, it can be; if you need it on the web, it can be.
  • Traditional development means you have to build things that don't help your business. If you want to build a process-driven application, there are components (state management, persistence, work list displays, etc.) that you will have to build.  You will need to design and implement a database model and persistence layer.  You will need to build or implement a portal framework.  SmartBPM provides all of this for you, so you can focus on the goal of your application: managing and automating your business process to deliver productivity and customer satisfaction.
  • Traditional development isn't built around user intent. Traditionally built UI's lack and understanding of user intent: either restrictions are "separating business logic from the user interface" result in interfaces that do not understand the rules and process of the application, or business rules are hard-coded into JavaScript elements, making the application fragile and harder to change.  SmartBPM drives an intent-driven user interface that dynamically incorporates rule and process logic, without the need to custom-code it into the user interface.
  • Traditional development isn't self-monitoring or self-documenting. Traditional application monitoring focuses on the technical aspects of the application, but have little ways of tying that monitoring to the real business function and no way of documenting the logic that is buried inside of the application code.  SmartBPM is not only auto-documenting from its model-driven requirements, it is able to tie is automated self-monitoring to the core business processes that drive the application.

It's no surprise that SmartBPM has been proven faster than traditional development.  Not only is SmartBPM faster and easier to change, but it results in applications that do more than just "manage" a process, but are able to drive process automation.