"Rapid Application Development" and "Extreme Programming" are buzzwords for new ways to deliver software that meets initial user requirements and continues to improve based on customer feedback. These approaches turn the IT department into an agile and forward thinking service provider.
The typical approach to software selection - requirements definition, an RFP process, pilots, implementation, integrated testing, and go live - can take 18 months and by the time the software is in use, the initial requirements may have changed. For some applications, the notion of rapidly prototyping a solution then iteratively releasing new versions can deliver more functionality faster than traditional approaches. Given the budgets, staffing, and integration challenges challenges facing most IT departments, the notion of an agile response to organizational imperatives is challenging. Is there a disruptive technology solution to this?
However odd this sounds, the answer may be Facebook.
A case in point. BIDMC is enhancing its external website and is currently preparing an RFP for online giving software. At 8am last Sunday, our BIDMC CEO, Paul Levy, created an online giving page using the Facebook Causes application
It's already been used by hundreds of people and the funds are beginning to roll in.
The IT department did not need to be involved, other than to offer support that the experiment was safe, secure and worth doing.
Facebook is a perfect example of a rapid application development platform that empowers users to help themselves. It includes tools for creating of groups, forums, multimedia uploads, viral marketing, fund raising, and group mailing lists using any web browser, on any operating system, for free.
Should CIOs embrace it as a short term solution to many of the user requests for collaboration technologies?
The answer is yes, with caveats. Facebook is not a HIPAA business associate nor covered entity, so protected healthcare information should not be placed on Facebook. There is no service level agreement/quality of service guarantee, so it may be go down without notice (unlikely, but possible). It does not integrate with enterprise single signon based on Active Directory or LDAP.
However, these issues are not real barriers to supporting the ad hoc collaborations that are often needed by organizations to start projects, create a social network of internal staff, or support a discussion forum.
Should CIOs try to replicate Facebook functionality on internal portals? For some circumstances that involve patients, the need for a guarenteed application availability, and integration with existing systems, the answer is yes. But for others, there is an important reason why Facebook should be considered as part of rapid application development:
So many people are using Facebook at this point (60 million), that many users will resist using any other social networking software. They may even demand Facebook in lieu of corporate solutions so that all social networking activity - inside and outside the office - is integrated in one place.
In my next generation of portal frameworks, I will support our own versions of all the Web 2.0 functionality (forums, wikis, groups, multimedia uploads) that is in Facebook, but I will also ensure that Facebook itself is used strategically. Staying agile and responsive to my customers requires that I embrace Facebook, not resist it.
No comments:
Post a Comment