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
What do people use something like Deki for? In short, it’s a wrap-up of middle-ware, “platform,” or “runtime” aimed at helping you create web sites and custom made applications in those web sites. Deki doesn’t so much provide the core functional components that’d be in these applications so much as provide the space for several different applications to integrate together into one view. (That said, it does include the “applications” of a wiki and document management.)
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.
nice take. puts me in mind of something i used to use as a negative- that is "veneerware"
but maybe veneerware's time has come.
Seems like the natural progression of Wikis and it seems JotSpot was doing this a couple years ago — before 'mashup' was so popular.
So, as portals (wikis, etc.) become more like workflow engines and BPM/BPA tools develop better web portals what's the best balance? Seems like doing both is a mistake. (i.e. Wikis have terrible workflow and BPMS have terrible interfaces.)
??
@Rusty Scupper
While there are some conceptual similarities between MindTouch and Jotspot these are only skin deep. The architecture of MindTouch Deki is dramatically different from JotSpot: http://mindtouch.com/Technology and, of course, JotSpot was closed source and targeting consumers and small businesses.
PS- Thanks for the write up…
@RustyScupper
"(i.e. Wikis have terrible workflow"
I have to disagree with you there – the point of a wiki is not to have workflow in the traditional sense. If you need workflow, there are other tools that do a great job providing it. A wiki is there to help a group of people who work on something together from the start, and therefore don't need workflow, approvals, etc. because they're seeing changes as a result of being subscribed to the wiki page to watch those changes, and making subsequent revisions as they see fit.
Tools that provide workflow (i.e. some CMSs, Intranets, etc.) and wikis are providing two different types of functionality that meet different needs. I think it's a mistake to confuse the two and conclude that wikis provide poor workflow. 🙂
Regards,
Stewart
Regards,
Stewart