BP3's Ivan Kornienko, Director of User Experience, and Scott Francis, Co-founder and CTO, presented at bpmNEXT 2015, the premier event for BPM vendors to present the latest and greatest from their development teams.
We’re Scott Francis, CTO of BP3, and Ivan Kornienko, Director of User Experience
[update slide with our awesome mugshots]
We’re likely the largest independent BPM services provider in the world now,
With headquarters in Austin, TX and offices in London, Kiev, Sydney, and Lisbon.
But we’re also the company that invests in user experiences. Our brazos ui, demonstrated here, is now the #1 UI on IBM BPM and we’re bringing our brand of BPM to other BPM platforms.
But the reason we attacked user experience is that we’re after the best CUSTOMER EXPERIENCE, which has also led us to write software targeted deeper in the BPM stack
Overall solution complexity is summarized by the Neches Score. The more complex the solution, the higher the Neches score.
Let's say we are tasked with a project to build a new a BPM application. The solution must meet a specific set of business and functional requirements to be fit for use. The budget is tight so we must keep costs down.
First, finding the right platform is a challenge since BPM has been around for a while and there are many excellent options. Different vendors offer a variety of features and approaches to solve similar problems. More than one correct answer is out there.
Next, the experts. We could fill the entire team with top consultants from the appropriate field but then we'd likely run out of money before a line of code was actually written. Our team must be made up of new BPMers in addition to those that have been doing it for years.
When the solution is built, it's easy to access success, when it's a clear failure. Missing basic requirements, will likely stop it from getting through UAT. Of course with iterative development and frequent business contact this is an unlikely outcome.
A more likely outcome is that the completed solution meets requirements and seemingly does everything the business needs. The issues may just surface over time. Poor performance. Awkward UI design. Difficulty adding new features or maintaining the existing ones.
So - How can Neches help here? By programmatically examining the BPM solution code against a set of best practices and antipaterns, curated by BP3 consultants that have been building similar applications for over a decade.
This allows us to find specific code bits or configurations that adversely impact the solution performance, make it difficult to use and a challange to test due to inconsistent UIs, or a struggle to maintain. Simply put we are examining the solution implementation complexity.
Refactoring a completed, production-ready solution is expensive and time consuming. There is lots of code, a variety of patterns, and many excuses ... or perfectly valid reasons why things were done a certain way and not according to best practices.
Worse yet, it's nearly impossible to end up with an ideal solution for the business since the foundation is likely flawed due to all the poor practices building up over time. A complete rebuild is really the best course of action at this point.
The good thing is that all this bad code isn't introduced all at once. It builds up over time gradually growing in to something unfixable. When poor assumptions or untested designs are not evaluated and corrected as they are introduced the seeds or poor user experience are planted.
This is why the right time for Neches analysis is at the end of each iteration. Issues identified by Neches early on in the development lifecycle are easy to fix. Developers can investigate and resolve Neches findings from a given iteration before the end of the following one.
To accommodate this use case Neches is available in the cloud, accessible to anyone in the world, and provides instant feedback. The feedback - or as we call it findings - is also structured specifically for BPM solutions and is transferrable from vendor to vendor.
Each Neches finding breaks down in to one of 4 categories, from the bottom up. The Process and business Models, User Interfaces, Exposed and consumed Integrations, and Documentation. These categories are defined to cover all parts of a BPM solution.
Moreover, each finding is assigned a severity. A high severity finding means the underlying issue needs to be fixed immediately. A low severity finding won't adversely impact your solution, but it could grow in to something unmanageable over time
Overall solution implementation complexity is summarized by the Neches Score. The more complex the solution, the higher the Neches score. This Score is used to anonymously compare similar solutions to one another to determine the relative quality of the implementation.