Scott's definition of Process Debt focuses on when our organizations fail to adapt to a changing business climate:
"If you rolled out a process two years ago and haven’t made any tweaks in the meantime, I believe you have acquired process debt – a steady, growing gap between what your software and processes are designed to handle, and what the reality of current business conditions requires."That steady, growing gap between what your software does and what your business needs is inevitable and inexorable. It's the real demon that business programmers need to slay.
My work is primarily with folks who are embarking on their first BPM project... I help them implement their first managed business process with as little pain as possible, and I always goad them to "just get it done". Process Applications aren't supposed to be pretty, and the longer it takes to build and deploy them, the longer it will be before your business realizes a return on their investment.
Despite preaching "just get it done", we mustn't forget that the process application that we are building today won't be what the business needs next year. The business universe is in constant flux, and our solutions will likely be dated as soon as they are deployed. We have to build our process apps with an eye to changing them in the future.
As Business Process Developers we really have to exert that extra effort to keep the linkage between each Process Requirement and how we have implemented that Process Requirement as clear as possible. If you can't pinpoint how a requirement has been implemented then you can't easily adapt your code when that requirement changes.
Even with a great BPM suite, it's really tempting to implement process logic "where ever you need it". For example, how many times have you embedded client-side JavaScript on a web page to implement a process rule? I'm certainly guilty of doing this, and I know better. If you aren't careful, your process logic will end up scattered across web pages, stored procedures, AJAX services, etc. Your BPMN diagram may be clean, but under the covers it's a mess.
Hidden process logic may be expedient, and it may even be necessary, but it's the single biggest obstacle to continuous improvement of your process applications. Be sure that you know where your process requirements are implemented, and put it in writing for those folks who will inherit your code down the road.
If we maintain a clear linkage between our process requirements and the "code" that implements those requirements, then the cost of adapting our process applications will be lower - and if the cost of adapting our process applications is lower we should be able to pay off those process debts a whole lot sooner.
Process debt will happen... it's up to us as developers to reduce the cost of addressing those debts.
No comments:
Post a Comment