Last week we talked with MindTouch’s Aaron Fulkerson about the new release of their Deki product, née DekiWiki. While Deki started out as an enterprise-ready wiki, Deki has evolved into more of a quick and easy business application development platform with linage in “mashups” and “composite applications.”
This new release - Kilen Woods (named after a Minnesota park)- adds in a workflow engine and many more adaptors to pull data into Deki from other sources.
What’s it for?
Good enough, lightweight apps, but don’t build a transactional app with it. This is for self- managed applications. If you think you need IT to manage it, you may need something else [such as a full blown Portal implementation]. –IBM’s Larry Bowden on IBM’s Mashup Center
The “applications” here are not advanced applications that you might consider stand-alone software. Instead, they’re primarily focused on custom built “workflows” that skew heavy towards presenting data and managing documents.
Indeed, as outlined by MindTouch several places (including this good interview from Bungee Labs), MindTouch’s intent is to provide everything: they just want to provide the connective glue that pulls best-of-breed, stand-alone applications and services together into one, integrated view.
So, for example, if you have to use 8 different web applications and services to get your daily job done, MindTouch is hoping that a layer of Deki can help meld those into one, unified feeling application you deal with (or, less than 8, at least).
The end goal is to wrap just enough process and workflow around raw data from multiple sources to get something useful.
As mentioned above, this is what you’d call a “composite application” or “mashup server.” That’s still a weird floorwax/dessert topping category that takes imagination and effort to apply to specific use cases. This doesn’t mean the software is bad: rather that it can be difficult to map it to customers waiting to pay someone to fix their problems. This is a classic middle-ware problem, esp. for new types of middle-ware that aren’t yet part of the canonical IT stack like, say, databases are.
You can compare the goals of usage to things like IBM’s QEDWiki, Quickr, or MashUp Center quoted about above. You can see also see how platforms like drupal can jimmy themselves into the same attention-space.
Deki’ed Out
Doing the quick diff, Aaron told us that the primary new stuffs are the addition of workflow management and several new adaptors for integrating 3rd party data into Deki. Those adaptors include: Salesforce, SugarCRM, Microsoft SQLServer, MySQL, Microsoft Access, Mantis, Trac, Bugzilla, SVN, and Atlassian Jira.
By “workflow” they mean providing the basic framework that allows multiple people to work on some data item, be it a chart, a request, etc. Combined with the adaptors, the idea is to wrap some mediated process around pulling data into the system and then doing something with it - beyond cut-n-paste, I guess.
Included, of course are the old document management features you’d expect, like centralizing the storage of documents with version control so you don’t email things around.
The other, over-riding principal of Deki compared to traditional content middleware platforms is a focus on being open and simple. Deki is built in a very web-native feeling way, trying to keep APIs and data as open and accessible as possible, pulling towards transparency in those processes, if not, human-understandability. This contrasts to systems that require binary protocols and APIs or overly complex Web Services schemes. That is, Deki has a REST-y feel to it rather than a WS-* feel.
While Deki is open source (GPLv2), there are “Enterprise” and managed hosted pricing plans for support and additional goodies. Check out the pricing here.
Disclaimer: IBM is a client, as are Microsoft and Atlassian.
Previous Topic
