QEDWiki, IBM, and "Situational Applications"
When people mention IBM, the most common mental picture is huge corporate IT. (that and Avery Books starring back at me from my TV demanding to know where the flying cars are) Their reputation for large IT projects borders on legendary. So prevalent is this mental picture that many people lose sight of the fact that IBM has been quietly innovating for the past 20 years. Everybody recognizes that they ushered in the era of the PC. Many people know that they started a little laser printer division that spun off into Lexmark Printers. Their ThinkPad laptops have been a badge of honor for hard-core developers for many years. Unlike other companies however, IBM doesn’t have the word innovate in their tagline. They do not wear it on their shirtsleeve. They chose to actually innovate instead of just championing it.
I was recently blessed with the opportunity to slip below the blue veneer. It was far from the corporate cube farm mentality I expected. What I found was interesting, it was fresh; yes, I’ll say it, it was innovative.
My encounter with IBM innovation came in the form of a phone call with Dan Gisolfi. Officially Dan’s title at IBM is “Certified IBM Executive IT Architect”. He works in the “Emerging Internet Technologies” department at IBM. Translated, that means that Dan’s job is to look at what is happening now and dream up what could happen next. One of the projects Dan is currently shepparding at IBM is QEDWiki. QEDWiki (which stands for “Quick and Easily Done”) is what Dan calls a “Mashup Enabler” and it was the subject of our discussion
For those of you who do not know what QEDWiki is, it is an “Application Wiki”. It started life as a Wiki IBM built from scratch on top of the Zend Framework. In addition to serving normal wiki pages, users (Dan likes to call them knowledge workers) can build working application pages. Simply click the QED button in the corner and you can then drag “widgets” (discrete pieces of code with both development and runtime rendering capabilities) onto the design surface. Each widget has a property sheet and allows you, where applicable, to bind it to other widgets or data sources. A simple example would be a contact list widget connected to a Google map widget. By attaching the two together, as you scroll your contacts in the list, the Google map widget will show you a map of the address of your contact.
I will admit that while QEDWiki is a cute packaging of ideas, I really did not see the value. Not being a huge wiki fan myself, I envisioned a wasteland of pages half-complete or incorrect, silently pleading for attention. In this case I completely missed the on-ramp to enlightenment. Dan was quick to get me back on the right road as he explained that this is where “Situational Applications” come into play. Since this was a new buzzword for me, I hit the brakes and made him backup and define it.
“Situational applications are a way for people with domain expertise to create applications in a very short time. Many IT shops have a backlog of small little projects that their customers want. If it takes 3 weeks to get to a project, the need is gone before the developer even starts coding. We want to give knowledge workers the tools to solve their own problems.”
With that cleared up we were back on track.
The core of the idea is that with the convenience of a wiki, knowledge workers can now assemble their own instant applications. This idea in itself is enough to strike fear into the hearts of many IT Directors I know. Empowering knowledge workers means releasing some control. The concept of losing the keys to the corporate IT gates is not one that many Directors want to espouse. However, this is another area where QEDWiki is innovative.
Many IT Directors still have nightmares about Lotus Notes and Notes Script “applications”. Yes, users could write them, however, at a certain point however, they become too complex for the average user to maintain. Thus they call in the already overworked IT department whose attitude is generally, “Hey, we didn’t write it in the first place.” QEDWiki sidesteps this issue nicely by giving the knowledge workers the power to create within a known universe of widgets. Recognizing that they are the domain space experts, QEDWiki allows them to design the applications they need at the moment by dragging widgets onto the design surface and hooking them together. The IT department retains control because they control the universe of widgets available. If the knowledge workers can only use the widgets written by or approved by the IT department then the IT department still has a great deal of control over the application and the data being processed.
On a deeper level, the IT department still has control over the services the widgets consume. Widgets have to talk to something to get the data they display or update. Be it, LDAP, a database or a web service, the widgets themselves consume and process data that has to come from somewhere. The IT department again is still the gatekeeper but no longer the gardener.
“QEDWiki allows companies who could not make the jump to SOA get started.” Dan explained to me. “Instead of focusing on the creation of service interfaces for disparate data sources, QEDWiki refocuses the discussion on the user’s application requirements at the glass. Starting at the UI level and drilling down, the mashup enabler can quickly identify the necessary service interfaces required to support the mashup. In other words, mashup enablers like QEDWiki are enabling technologies that help to create the demand for web services.
Many companies are looking towards Service Oriented Architecture but are having trouble justifying the move. Implementing a QEDWiki gives them the reason they need to start building out the services. These services will eventually be consumed by more than just QEDWiki.
One of the examples that IBM has built around QEDWiki is for a fictitious hardware store chain. Hardware store chains are affected by weather, rain means they need to make sure their stores have plenty of visquene and gutter repair supplies. Snow means make sure you have plenty of snow shovels and snow blowers. The demo, an “enterprise mashup”, combines a widget pulling data from the corporate ERP system to display each stores inventory, with a live feed weather widget. As each store is highlighted, the weather for that store’s area is displayed along with it’s relevant inventory. Managers can quickly decide to transfer inventory between stores or place orders with vendors. It’s not a far stretch to see how exposing these feeds as web services to their vendors, would help them predict their needs as well. Services created for one need begin to feed other needs as well.
All of the magic behind QEDWiki is built on PHP and the Zend Framework. IBM and Zend have an ongoing partnership to foster PHP development in the enterprise and this is just one example of how they are working together. Some of the code that IBM has developed for QEDWiki is in the process of being given back to the community in the form of contributions to the Zend Framework. The widgets themselves are PHP classes that are executed via AJAX to render themselves. Most of the widgets used in the demos had both a design-time and a run-time rendering. The result is stunning.
I watched in a demo built for the insurance industry as a widget was dropped on the design surface. As soon as a data source was attached (in this case an Atom feed of policies to review), the widget sprang to life displaying 10 policies. Next to it was dropped a policy viewer widget. As soon as it was bound to the widget containing the list of insurance application, the currently highlighted record was displayed for content validation as part of the actual human workflow associated with the ACORD-103 business transaction scenario. All this magic is real-time and it is all PHP. (Well, a little JavaScript thrown in there for good measure)
Could this be the future of application development? Delivering on the promise so long ago of OLE and OCX, QEDWiki breaks applications down into basic building blocks for knowledge workers to assemble and reassemble as they need.
The Web is the platform of choice today but tomorrow, who knows. Services can now be consumed by so many discrete applications and devices that I fully expect my refrigerator and my scale to form an ad-hoc application and start conferring behind my back to limit my dinner options. If they do, I know I’ll have SOA and “Situational Applications” to thank for my celery and peanut butter meal. And as I flip my scale over to yank out it’s wireless network card, I’m sure it will have the IBM logo on it.
Comments