Development Mindset when utilizing ILINX eForms

Those familiar with software development should know the Waterfall software development methodology very well. For those who don’t, it’s basically this:
1. Perform discovery/gather requirements
2. Build out the solution based on the requirements provided
3. Perform User Acceptance Testing (UAT)
4. Correct issues found during testing and resubmit for UAT
5. Repeat steps 3 and 4 as necessary
6. When the solution is accepted, prepare to move it into Production and do so
7. Support as necessary post-Production deployment

As a rule, we try to stay close to this approach when working through customer engagements, and regardless of the product we’re implementing it usually works very well. If you look at the majority of our product catalog and the wide range of services we provide for other products in addition to our own, it is apparent that we (like any good software company) prefer not to reinvent the wheel, and as such lean more towards configuring or adding to an existing product over building a new one when the opportunity to do so presents itself.

Following this logic, we tend to have a limited software development presence in projects, instead focusing more on implementation of business rules within existing systems rather than building systems around the rules themselves. This tendency moves us even more towards efficient utilization of Waterfall, as if we can get all of the business rules up-front, implementing them in the target system usually becomes a fairly linear process no matter what that system is.

Waterfall also holds strong when scripting is utilized to accentuate larger processes being coordinated by an ECM product, such as Validation scripting in Kofax Transformation Modules or the Client-Side Scripting engine introduced in (as of this writing) ILINX Capture’s latest release. Where it starts faltering for us is if we take that coordinating ECM product, reduce it to a barebones framework and instead rely on the scripting engine as the main avenue for getting things done. As it happens, we have a product that, among other things, does just that: ILINX eForms.

By making the above statements, I am not in any way implying that ILINX eForms is an inferior product; the decision to rely heavily on scripting actually makes it one of the most powerful and comparatively feature-rich ECM tools around. Rather, the problem here is the approach to using it. When you get into a solution where you have near-full control of an application’s UI in addition to everything else, more customer interaction is required during the solution development step than Waterfall calls for (which is minimal, if any). Seemingly innocuous attributes such as field placement, font type/size/style, field label names, etc, can lead to excessive backtracking and time lost if the first time the customer can note something is wrong with them is when they are supposed to be performing user acceptance testing (or worse, when they are supposed to be receiving training on the solution itself). You have control over all of these aspects and more in ILINX eForms, and as such, configuration of a solution in it tends to lean far closer to developing a custom application in Microsoft Visual Studio than it does towards, say, configuring a batch profile in ILINX Capture:

Also as such, keeping the customer and their subject matter experts informed of the solution’s layout and non-business rule functionality via frequent demonstrations that perforate short, intense, goal-driven development cycles throughout the development process/steps becomes the most efficient way to minimize backtracking at future project steps while efficiently building the solution the customer wants, even if it isn’t exactly what they wrote down.
If this sounds familiar to some, it’s probably because frequent customer demonstrations and short, intense, goal-driven development cycles are both hallmarks of the Agile software development methodology. I wouldn’t go so far as to say ILINX eForms falls fully into the must-use-Agile category, but at the same time, following strict Waterfall can and will produce timing issues (not to mention the possibility of the always-embarrassing customer demo/training-turned-design session taking place, if it’s the first time the customer is seeing the form). The best solution, as is usually the case, is to blend the two: Follow the standard Waterfall design, but parse out the solution development step into easy-to-achieve goals and demonstrate them to the customer as they are achieved. That way, you get instant feedback on user experience issues, the customer has an idea of how things will work well before UAT is supposed to take place, and you aren’t assaulted with a pages-long list of formatting and functionality issues upon UAT completion.

Jesse Kinney
Systems Engineer
ImageSource, Inc.