Does "live prototyping" signal a resurgence in systems development?
One of the great pleasures I get from running the InTEP forum is being privy to the emergence of new trends within the CIO community. These insights usually come from my one-on-one meetings with members when I try to understand what's on their agenda and what topics will be pertinent sessions for InTEP in the year ahead
The latest trend I believe is happening is a renaissance in systems development. When I first heard this was occurring late last year, I was decidedly sceptical. Heavens above, it was only a few years ago when the corporate world was embracing comprehensive ERP suites with gusto. Then, and for quite some time afterwards, the mantra was that packaged software represented demonstrable solutions that could be quickly up and running. The wisdom was that if the business had to change to fit the system processes embedded in the package then so be it.
I think that for many CIOs this still holds true for mission critical applications. With such apps the requirements are usually so complicated and comprehensive that there is too much uncertainty in building something from scratch, especially when a package already exists that might be a reasonable fit to your requirements. Of course, IT's lamentable track record with major systems development has also added to business caution. However, the type of development that I'm starting to witness is in a different league. Often the system being constructed is a niche business application to fit the specific needs of one operating unit.
The scenarios I keep hearing about from CIOs are remarkably similar, such as the case of the CIO who described the process as "live prototyping". Typically, this CIO will use something like an informal cup of coffee as an opportunity to meet with their business counterparts on a regular basis to better understand some of the problems they are facing. Often these discussions uncover a niggling irritation in some business process. The CIO then gets some fairly loose support to investigate a potential response from IT. Then a business analyst brainstorms the problem with the end users and draws up a rough systems specification. From this a developer, typically using a tool such as .Net or J2EE, develops a preliminary prototype of the potential application.
This can take no more than two or three weeks. However, the user is then able to work with the developer to refine the application to something that then meets their true needs. Often this dialogue uncovers one or two other "nice-to-have" features. In traditional IT development nothing causes more paranoia than scope creep. Yet in the type of systems I am witnessing it seems much less of a problem. From conception to conclusion a tailor-made system can be available in well under six months.
I can see that some readers may well be losing some sleep over this approach. These people are probably having nightmares about islands of applications and disparate data definitions. They may be wondering whether we are in danger of going back to the bad old days when IT built applications willy-nilly in response to business requests with no thought about how these all tied together? However, despite these reservations I believe live prototyping promises much for IT. Such systems are a manifestation of IT being responsive to a business request. They foster dialogue between end users and IT staff. End users have no problem taking ownership of these systems because they asked for them in the first place. Finally, they get IT out of its cost-cutting quagmire and allow the department once again to contribute positively to enhancing the business.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.