Initial Time to Build? Vision to Release in Days? Those Aren’t Relevant Measures for Business Agility!
I routinely receive emails, tweets and snail mail from IT vendors that focus on how their solution accelerates the creation of business applications. They will quote executives and technology leaders, citing case studies that compare the time to build an application on their platform versus others. They will make the claim that this speed to release proves that their platform, tool or solution is “better” than the competition. Further, they claim that it will provide similar value for my business’ application needs. The focus of these advertisements is consistently, “how long did it take to initially create some application.”
This speed-to-create metric is pointless for a couple of reasons. First, an experienced developer will be fast when throwing together a solution using his or her preferred tools. Second, an application spends years in maintenance versus the time spent to build its first version.
Build it fast!
Years ago I built applications for GE in C. I was fast. Once I had a good set of libraries, I could build applications for turbine parts catalogs in days. This was before windowing operating systems. There were frameworks from companies like Borland that made it trivial to create an interactive interface. I moved on to Visual Basic and SQLWindows development and was equally fast at creating client-server applications for GE’s field engineering team. I progressed to C++ and created CGI-based web applications. Again, building and deploying applications in days. Java followed, and I created and deployed applications using the leading edge Netscape browser and Java Applets in days and eventually hours for trivial interfaces.
Since 2000 I’ve used BPM and BRM platforms such as PegaRULES, Corticon, Appian and ILOG. I’ve developed applications using frameworks like Struts, JSF, Spring, Hibernate and the list goes on. Through all of this, I’ve lived the euphoria of the initial release and the pain of refactoring for release 2. In my experience not one of these platforms has simplified the refactoring of a weak design without a significant investment of time.
Speed to initial release is not a meaningful measure of a platform’s ability to support business agility. There is little pain in version 1 regardless of the design thought that goes into it. Agility is about versions 2 and beyond. Specifically, we need to understand what planning and practices during prior versions is necessary to promote agility in future versions.
How many first releases for an application?
An application has one “release 1″ and is then maintained for years. If you want to measure the value and agility of a solution platform, make sure you evaluate the work involved to maintain, extend, enhance and refactor within the functionality provided by that platform.
Here is an argument I make to application teams when designing a solution. Faced with a decision between coding a hard-to-maintain solution quickly versus investing extra up-front time to build an easier-to-maintain solution, I argue that the up-front time will consistently pay back significantly. Why? Because we spend far more time fixing and extending applications than initially building them.
The same idea applies to a user interface (UI). Spending more time on a easier-to-use UI that speeds up a user will pay for itself many times over since the user repeatedly uses the UI versus the one-time investment in designing and building it. If I take 2 extra developer person-weeks to save 24 users 5 seconds on an interaction that they each have 20 times a day, it is paid for after 120 days and is returning a positive ROI from then on.
Most people seem to accept this reasoning, yet continue to get excited about how fast an initial release can be created.
My take
As I said earlier, I’ve used a lot of platforms to create applications. My consistent experience, from heavy-weight single-language programs to SOA-based multi-product integrated applications, is that without appropriate up-front design work, the perceived speed and agility created by a fast initial release is quickly nullified when work begins on release 2.
Further, there is no best platform for developing applications. Instead, there will be several options that make sense for any organization. The choice must be driven by the business and IT strategy, competitive environment, operating model, current organizational capabilities, and existing infrastructure. Multiple platforms will serve well, assuming that commitment and alignment throughout the organization (governance) is in place. No application platform will work well without such business commitment and alignment.
My guidance for choosing and advancing the appropriate application platform is to evaluate the entire life-cycle effort, not just the initial application creation process. Work with vendors to carry out a proof of concept or pilot that goes beyond an initial version and advances through to a release 2. This will expose many potential pain points.
Here are few such pain points I’ve seen arise after a euphoric release 1: what happens to in-flight processes when we update a process definition; how much control does the business have over changing the application look and feel; how are XML message schema changes applied across the different SOA components; and how are the artifacts across all the technologies coordinated as a release within a source code control environment? These are the sorts of hard problems that are painlessly skipped when pursuing release 1.
I’d appreciate your thoughts on application design and development. What is your experience with fast application releases and longer term application maintenance? Is there a complete platform or mitigating approach you’ve found that simplifies refactoring and artifact maintenance without requiring investment in up-front design work, standardization and careful coordination?
Tags: BPM, efficient coding, Information Systems, programming