Today I read a post by ebiz blogger Keith Harrison-Broninski about Mashups and process. He took a look at mashups from two perspectives represented by mashup tool vendors JackBe and NexaWeb.
(As an aside, do you think JackBe allowed him to evlauate their tool? Readers will remember that JackBe declined to let me evaluate Presto, as I've noted here and here.)
I'm in the middle of evaluating Dapper, and so far I really like what I see. I had to take time out to respond to Harrison-Broninski, however, because while I agree with most of what he says, I have to take exception to his conclusion.
Here is the money quote from his post.
...there are essentially 2 types of mashup: siloed and process-aware. For now, mashup tools are siloed. However, in due course they will become process-aware via integration with HIMS technology - and once this happens, the combination of [Human Interaction Management System] HIMS processes and mashup applications will be an extremely powerful way to leverage both Web 2.0 and your legacy infrastructure.
I'm very confused by this post because we've been saying for months that true business mashups are not only human-process aware, they are human-process centric. Mashing up the data is a great step forward. Mashing up visual and data elements at the glass is a very interesting technique, perhaps more relevant to the consumer world than the business world, but a useful technique nonetheless. However, these aren't business mashups. They are presentation and data mashups.
So what?
Hinchcliffe noted in a recent and widely cited post that there aren't yet killer mashup apps. I believe that's because we've concentrated only on putting the data and presentation components together and haven't put the results in the context of a business activity. I go into more detail in my response to Hinchcliffe, so I won't repeat myself here. The bottom line is that Harrison-Broninski has it exactly right about the need for human-centric process.
What he doesn't have right is his assertion that there are no process-aware mashup tools. He notes that BPM is a possibility, but thinks processes appropriate for BPM aren't really appropriate for mashups. Read his post for his perspective on the difference between BPM processes and HIMS processes. I'm not sure I agree with that conclusion since there are BPM vendors who have strong roots in human workflow. In fact, Forrester has an entire wave for Human-centric BPM. (I'd include a summary here, but then Forrester would insist on approving my post.)
Instead, I think the reason BPM tools haven't invaded the mashup market is because BPM practitioners haven't yet made the connection. (See my post on the subject.) Until that happens the tools won't evolve to make it easy to create mashup applications within a BPM context. I'm sure that will change, but for now read the comments from long-time BPM practitioner Sandy Kemsley.
Until the BPM tools do evolve, I'd like to point out that there are at least two process-aware mashup tools already on the market. The first is ActiveGrid, which I've already reviewed. The second is Serena Mashup Composer which has been released to the public this week. Both of these tools let users create mashup applications, and both enable mashers to define human workflow to put the mashups in the context of a business activity.
Go read Harrison-Broninski's post for an interesting discussion about the difference between BPM and human-centric applications. He makes a great case for mashups of the future incorporating HIMS. But don't think you have to wait for 'the future' for a business mashup construction environment. To steal the title of a very old movie shamelessly stolen in many, many marketing taglines, "The future is now."
Showing posts with label data mashup. Show all posts
Showing posts with label data mashup. Show all posts
Wednesday, December 5, 2007
Thursday, November 29, 2007
Coghead lets you build simple web apps, not mashups
A colleague of mine last week suggested that I review Coghead as a mashup assembly platform. I've been spending the week with them and can conclude that they are neither a good nor a bad mashup platform. In fact, they aren't a mashup platform at all.
Coghead allow its users to construct simple web applications based on a back-end database. Both the application and the database are hosted by Coghead itself. They have an on-demand pricing model that is quite reasonable, with the price of a subscription increasing with the number of database records. For simple web applications in the long tail of applications development, web applications that don’t need to mash either data or visual elements, Coghead could be a very reasonable solution.
On the surface, Coghead offers capabilities similar to ActiveGrid, but only on the surface. While ActiveGrid also lets users create a web application driven from a back-end database, unlike Coghead, ActiveGrid allow users to create mashups both by exposing services and by calling out to them.
Let's start with what Coghead can do. I found it very easy to construct web forms, create search result lists, define business logic and otherwise manipulate database records. I had a fairly sophisticated app up and running within a couple of hours of signing in. The documentation is excellent, and the tutorials instructive. You really don't need to be technical to create a Coghead application. As with ActiveGrid, it's helpful to understand how relational databases work, but not absolutely necessary as long as your application is simple and doesn't require complex relationships between tables.
There were a few things I didn't Like about Coghead. It was easy to get the web forms set up, but it wasn't easy to get them just right. I'd say that most form designers will spend 90% of their time tweaking the last 10% of the form. Form tweaking and other minor problems were just annoying. The most pressing problem with Coghead was its performance. I've got an excellent connection here at the office, and I had only a small app on Coghead, yet creating, updating, and deleting records was slow, slow slow.
All this is in the noise, however. Because Coghead is not, repeat not, a mashup construction platform, business or otherwise. The only content they aggregate, and by aggregate they actually mean replicate, is by way of a csv file. That's a good choice for a database integration conduit, but it isn't a mashup. It's replication.
You might be wondering about coglets. Surely, you might think, coglets enable mashup construction. At least you might if you were on Coghead’s site and read about coglets. And what about mashouts. Don’t they count?
Sorry. Coglets are by no means mashup fodder. Coglets merely create individual web pages to display fragments of your application's data. I can create a single page, accessible through a URL, to display a single record or to display a view. I can then embed the URL into another web page. That isn’t a mashup. That’s at best a portal and at worst just a custom web page with a lot of iframes.
Mashouts go in the other direction. Mashouts allow you to use data from the current form as variables in HTTP get requests. These requests get triggered from the web form's context menu. (Web forms with context menus...you gotta love AJAX.) The target for the request is another browser altogether. That's not even a portal. It's a link to another application.
Let’s look at an example.
Let's say I want to have an application that consolidates all the tasks I have assigned to me. Let's also say that I get tasks from a project management system that publishes a project plan to the web, my Outlook TODO list, and from an issue tracking system used by R&D to assign maintenance tasks. There are at least four ways I could interact with these different task lists. First, I could jump from app to app to app. That’s not a mashup. It isn’t even an integration, but it’s the sort of capability provided by mashouts. You can jump from a Coghead app directly to another app in another browser. It’s our old siloed applications we know and love so well.
Second, I could copy all the data from the three apps either into a single database, or designate one of the applications as the master TODO list. Then I could access all my tasks from a single repository, hopefully with two-way replication so changed TODO data can be fed back into the original app. That isn’t a mashup, that’s a replication integration, one that has all the inherent problems associated with replicated data. These sorts of integrations are enabled through Coghead’s csv import/export feature.
Third, I could create a web page where I pull the content from the three apps into the single page. In one frame I’d see the project tasks, in another my Outlook tasks, in a third my issue management tasks. This is what you get with coglets. That’s not a mashup, that’s a portal.
Finally, I could construct an application that aggregates the information from all three applications into a single unified GUI. I could reference the data but not copy it, so all three applications retain their single copy of the TODO data. I could create a unified GUI so that, unless I drilled down on a specific task, I wouldn’t even realize the data were federated across three repositories. Were I to take this approach, I’d have a mashup. Unfortunately, there are no capabilities within Coghead applications that support this approach. At least not yet. Their documentation says they will have REST services available soon, meaning that while Coghead could participate in a mashup, they still wouldn't be a mashup platform.
Bottom line: Coghead can certainly help non-technical users develop web-based applications in the long tail of applications development. For the 80% solution, Coghead makes it easy to create, deploy and even pay for those pesky applications for which there are no IT resources. It won’t be a mashup, but it could be enough for you.
Coghead allow its users to construct simple web applications based on a back-end database. Both the application and the database are hosted by Coghead itself. They have an on-demand pricing model that is quite reasonable, with the price of a subscription increasing with the number of database records. For simple web applications in the long tail of applications development, web applications that don’t need to mash either data or visual elements, Coghead could be a very reasonable solution.
On the surface, Coghead offers capabilities similar to ActiveGrid, but only on the surface. While ActiveGrid also lets users create a web application driven from a back-end database, unlike Coghead, ActiveGrid allow users to create mashups both by exposing services and by calling out to them.
Let's start with what Coghead can do. I found it very easy to construct web forms, create search result lists, define business logic and otherwise manipulate database records. I had a fairly sophisticated app up and running within a couple of hours of signing in. The documentation is excellent, and the tutorials instructive. You really don't need to be technical to create a Coghead application. As with ActiveGrid, it's helpful to understand how relational databases work, but not absolutely necessary as long as your application is simple and doesn't require complex relationships between tables.
There were a few things I didn't Like about Coghead. It was easy to get the web forms set up, but it wasn't easy to get them just right. I'd say that most form designers will spend 90% of their time tweaking the last 10% of the form. Form tweaking and other minor problems were just annoying. The most pressing problem with Coghead was its performance. I've got an excellent connection here at the office, and I had only a small app on Coghead, yet creating, updating, and deleting records was slow, slow slow.
All this is in the noise, however. Because Coghead is not, repeat not, a mashup construction platform, business or otherwise. The only content they aggregate, and by aggregate they actually mean replicate, is by way of a csv file. That's a good choice for a database integration conduit, but it isn't a mashup. It's replication.
You might be wondering about coglets. Surely, you might think, coglets enable mashup construction. At least you might if you were on Coghead’s site and read about coglets. And what about mashouts. Don’t they count?
Sorry. Coglets are by no means mashup fodder. Coglets merely create individual web pages to display fragments of your application's data. I can create a single page, accessible through a URL, to display a single record or to display a view. I can then embed the URL into another web page. That isn’t a mashup. That’s at best a portal and at worst just a custom web page with a lot of iframes.
Mashouts go in the other direction. Mashouts allow you to use data from the current form as variables in HTTP get requests. These requests get triggered from the web form's context menu. (Web forms with context menus...you gotta love AJAX.) The target for the request is another browser altogether. That's not even a portal. It's a link to another application.
Let’s look at an example.
Let's say I want to have an application that consolidates all the tasks I have assigned to me. Let's also say that I get tasks from a project management system that publishes a project plan to the web, my Outlook TODO list, and from an issue tracking system used by R&D to assign maintenance tasks. There are at least four ways I could interact with these different task lists. First, I could jump from app to app to app. That’s not a mashup. It isn’t even an integration, but it’s the sort of capability provided by mashouts. You can jump from a Coghead app directly to another app in another browser. It’s our old siloed applications we know and love so well.
Second, I could copy all the data from the three apps either into a single database, or designate one of the applications as the master TODO list. Then I could access all my tasks from a single repository, hopefully with two-way replication so changed TODO data can be fed back into the original app. That isn’t a mashup, that’s a replication integration, one that has all the inherent problems associated with replicated data. These sorts of integrations are enabled through Coghead’s csv import/export feature.
Third, I could create a web page where I pull the content from the three apps into the single page. In one frame I’d see the project tasks, in another my Outlook tasks, in a third my issue management tasks. This is what you get with coglets. That’s not a mashup, that’s a portal.
Finally, I could construct an application that aggregates the information from all three applications into a single unified GUI. I could reference the data but not copy it, so all three applications retain their single copy of the TODO data. I could create a unified GUI so that, unless I drilled down on a specific task, I wouldn’t even realize the data were federated across three repositories. Were I to take this approach, I’d have a mashup. Unfortunately, there are no capabilities within Coghead applications that support this approach. At least not yet. Their documentation says they will have REST services available soon, meaning that while Coghead could participate in a mashup, they still wouldn't be a mashup platform.
Bottom line: Coghead can certainly help non-technical users develop web-based applications in the long tail of applications development. For the 80% solution, Coghead makes it easy to create, deploy and even pay for those pesky applications for which there are no IT resources. It won’t be a mashup, but it could be enough for you.
Wednesday, November 7, 2007
ActiveGrid is useful for web-based application building, but like so many mashup tools, you've got to have a fair amount of technical know-how
You'll notice from the title that I'm going to review ActiveGrid by WaveMaker. I wanted to review either Denodo, JackBe or AlchemyPoint by Orchestr8, but both Denodo and JackBe declined to allow me to evaluate their software, and Orchestr8 needs to publish some more documentation before I can do a good evaluation.
Why couldn't I test drive Denodo or JackBe?
Denodo declined because they sell enterprise middleware that requires some hand-holding to install and understand. They don't allow web downloads at all, let alone downloads by potential competitors. They did offer me the chance to participate in a directed demo, but having been in the software business for a long time, I just don't trust demos. I need to dig in and get my hands dirty. I want to thank them for making the offer, however.
JackBe was more straightforward. Serena is a competitor, and they aren't knowingly going to hand over their software to someone who could have malicious intent. That would be me, I suppose.
Fair enough. I'll just have to sign up under a different email address and company name and get my hands on it that way. Perhaps I'll use my Second Life avatar. Better watch out for a download request from Chuck Malibu, JackBe. (Note: This is a joke. I would never do such a thing, even to support my blogging habit.)
So while I can't talk to you about Donodo, JackBe or AlchemyPoint, I can talk to you about a surprisingly interesting web application building tool called ActiveGrid. WaveMaker is the company name, although as little as a week ago the company name was ActiveGrid, just like the product name. I'm not quite sure why they changed their name, but as long as they didn't change the tools, this review should still be accurate.
What is ActiveGrid?
ActiveGrid advertises itself as a Web 2.0 platform (who doesn't?) allowing non-technical or business-oriented people to build their own AJAX-based RIAs and mashups. Some of that is true, and some is a bit of a stretch. It's true that you don't need a lot of technical know-how to build data-based applications with highly interactive AJAX-driven interfaces, although some familiarity with the workings of a DBMS is necessary. When I started to build mashups, well that required a bit more technical know-how, which I'll talk about later.
ActiveGrid's application model is based on a database with a web front-end driven by a BPEL process engine. It reminds me strongly of the old Access-driven applications we built back in the 80s and 90s. Start with a database, add some user interfaces and some Visual Basic to manage the business logic, and there you have it, a home-built application. Of course, ActiveGrid is quite a bit more sophisticated.
I used ActiveGrid to build an application that used the various RSS feeds and REST interfaces I defined in OpenKapow. (See my earlier post.) It was easy to assemble the screens as long as I used the defaults. They do a fairly good job of putting the widgets, data fields, etc. on the display in a visually pleasing way. They have a small selection of style sheets which were adequate. Of course, just as with QEDWiki, you can use your own style sheets.
Building ActiveGrid Web Pages is a Mixed Bag
I liked a lot of the page-building features. Selecting service fields to use on a page was quite easy. I didn't need to map the fields to page elements, ActiveGrid did all that for me. One very nice feature allowed me to take individual pages I created and, using AJAX techniques, quickly aggregate them into a single page. I liked that a lot.
Some things I didn't like about the page builder. What I want, and what most web-based application page building tools provide, is a visual modeling tool with a drag and drop interface allowing me quickly to mock-up the page. That's not how GUI development works in ActiveGrid. Setting up page formats reminded me strongly of the way we built XWindows/Motif interfaces back in the day. Trust me, it was tedious and time consuming.
BPEL for Page Orchestration and an Intuitive Event Model
ActiveGrid use BPEL for page orchestration, which is an interesting although unorthodox choice for an interactive application. BPEL is usually associated with the WS-* stack for web service orchestrations, not with human workflow. They've done a good job of making it work by unifying their service model. Everything is a service. A call to a RSS feed is equivalent to a SOAP call is equivalent to script is equivalent to a database call. It's an interesting approach and one that works well. I found their event model, which they use to control page flow, to be easy to understand and easy to use. They only have synchronous events, but that's a small price to pay for simplicity. BPEL supports asynchronous events, so perhaps they will them in the future.
For Mashups, Better Get Some Expert Help
Now let's talk about building mashups. ActiveGrid absolutely qualifies as a tool for building business mashups. They aggregate data and visual elements into a unified end-user experience within a process-centric framework. However, just because it is a business mashup tool, it doesn't follow that ActiveGrid is a tool for business mashers. In fact, I'd say that ActiveGrid requires quite a bit of technical savvy to create mashups. More savvy than we can expect from your average business analyst-turned-masher.
As I've hinted earlier, you can call many types of services from within ActiveGrid. A call to an RSS feed is equivalent to a SOAP call is equivalent to a database query. From my perspective as a business masher, I agree with this approach. Why should I care whether my service is REST, SOAP, RSS, POX or just a database call. Admittedly, I need to know the type of service when I import it, but after that it's just inputs and outputs.
But, and this is a huge 'but,' when it comes time to aggregate these services so they can be used to present a common interface, we come to a real problem area: Field mapping and parameter passing. I can only say that field mapping and parameter passing within ActiveGrid, well, sucks. It's likely not their fault. I don't know any application builder, especially one based on BPEL, that does a good job with field mapping and parameter passing. When I had to pass parameters into a service call, it took me quite a while to figure out how to do it. In fact, simply following the steps in their 'getting started' application to pass a parameter from one page to another was confusing and took me several tries before I understood what they were doing.
Let's just say that ActiveGrid didn't seem to take a lot of trouble to hide the complexity of the BPEL field mapping monstrosity from their end-users. No graphical drag and drop, no suggested mappings. Not even pop-up help so you could read the help and look at the interface at the same time. Just a lot of steps to define input variables, output variables and a really bad interface to define the logic that associates the two together.
Yuck.
Botom Line
Business mashers can use ActiveGrid to build web-based applications quickly and easily. With some understanding of how databases work, it's quite simple to build highly interactive and appealing applications. When you want to turn them into mashups, however, you'd better get some serious help from your applications development organization because it's neither quick nor easy.
Why couldn't I test drive Denodo or JackBe?
Denodo declined because they sell enterprise middleware that requires some hand-holding to install and understand. They don't allow web downloads at all, let alone downloads by potential competitors. They did offer me the chance to participate in a directed demo, but having been in the software business for a long time, I just don't trust demos. I need to dig in and get my hands dirty. I want to thank them for making the offer, however.
JackBe was more straightforward. Serena is a competitor, and they aren't knowingly going to hand over their software to someone who could have malicious intent. That would be me, I suppose.
Fair enough. I'll just have to sign up under a different email address and company name and get my hands on it that way. Perhaps I'll use my Second Life avatar. Better watch out for a download request from Chuck Malibu, JackBe. (Note: This is a joke. I would never do such a thing, even to support my blogging habit.)
So while I can't talk to you about Donodo, JackBe or AlchemyPoint, I can talk to you about a surprisingly interesting web application building tool called ActiveGrid. WaveMaker is the company name, although as little as a week ago the company name was ActiveGrid, just like the product name. I'm not quite sure why they changed their name, but as long as they didn't change the tools, this review should still be accurate.
What is ActiveGrid?
ActiveGrid advertises itself as a Web 2.0 platform (who doesn't?) allowing non-technical or business-oriented people to build their own AJAX-based RIAs and mashups. Some of that is true, and some is a bit of a stretch. It's true that you don't need a lot of technical know-how to build data-based applications with highly interactive AJAX-driven interfaces, although some familiarity with the workings of a DBMS is necessary. When I started to build mashups, well that required a bit more technical know-how, which I'll talk about later.
ActiveGrid's application model is based on a database with a web front-end driven by a BPEL process engine. It reminds me strongly of the old Access-driven applications we built back in the 80s and 90s. Start with a database, add some user interfaces and some Visual Basic to manage the business logic, and there you have it, a home-built application. Of course, ActiveGrid is quite a bit more sophisticated.
I used ActiveGrid to build an application that used the various RSS feeds and REST interfaces I defined in OpenKapow. (See my earlier post.) It was easy to assemble the screens as long as I used the defaults. They do a fairly good job of putting the widgets, data fields, etc. on the display in a visually pleasing way. They have a small selection of style sheets which were adequate. Of course, just as with QEDWiki, you can use your own style sheets.
Building ActiveGrid Web Pages is a Mixed Bag
I liked a lot of the page-building features. Selecting service fields to use on a page was quite easy. I didn't need to map the fields to page elements, ActiveGrid did all that for me. One very nice feature allowed me to take individual pages I created and, using AJAX techniques, quickly aggregate them into a single page. I liked that a lot.
Some things I didn't like about the page builder. What I want, and what most web-based application page building tools provide, is a visual modeling tool with a drag and drop interface allowing me quickly to mock-up the page. That's not how GUI development works in ActiveGrid. Setting up page formats reminded me strongly of the way we built XWindows/Motif interfaces back in the day. Trust me, it was tedious and time consuming.
BPEL for Page Orchestration and an Intuitive Event Model
ActiveGrid use BPEL for page orchestration, which is an interesting although unorthodox choice for an interactive application. BPEL is usually associated with the WS-* stack for web service orchestrations, not with human workflow. They've done a good job of making it work by unifying their service model. Everything is a service. A call to a RSS feed is equivalent to a SOAP call is equivalent to script is equivalent to a database call. It's an interesting approach and one that works well. I found their event model, which they use to control page flow, to be easy to understand and easy to use. They only have synchronous events, but that's a small price to pay for simplicity. BPEL supports asynchronous events, so perhaps they will them in the future.
For Mashups, Better Get Some Expert Help
Now let's talk about building mashups. ActiveGrid absolutely qualifies as a tool for building business mashups. They aggregate data and visual elements into a unified end-user experience within a process-centric framework. However, just because it is a business mashup tool, it doesn't follow that ActiveGrid is a tool for business mashers. In fact, I'd say that ActiveGrid requires quite a bit of technical savvy to create mashups. More savvy than we can expect from your average business analyst-turned-masher.
As I've hinted earlier, you can call many types of services from within ActiveGrid. A call to an RSS feed is equivalent to a SOAP call is equivalent to a database query. From my perspective as a business masher, I agree with this approach. Why should I care whether my service is REST, SOAP, RSS, POX or just a database call. Admittedly, I need to know the type of service when I import it, but after that it's just inputs and outputs.
But, and this is a huge 'but,' when it comes time to aggregate these services so they can be used to present a common interface, we come to a real problem area: Field mapping and parameter passing. I can only say that field mapping and parameter passing within ActiveGrid, well, sucks. It's likely not their fault. I don't know any application builder, especially one based on BPEL, that does a good job with field mapping and parameter passing. When I had to pass parameters into a service call, it took me quite a while to figure out how to do it. In fact, simply following the steps in their 'getting started' application to pass a parameter from one page to another was confusing and took me several tries before I understood what they were doing.
Let's just say that ActiveGrid didn't seem to take a lot of trouble to hide the complexity of the BPEL field mapping monstrosity from their end-users. No graphical drag and drop, no suggested mappings. Not even pop-up help so you could read the help and look at the interface at the same time. Just a lot of steps to define input variables, output variables and a really bad interface to define the logic that associates the two together.
Yuck.
Botom Line
Business mashers can use ActiveGrid to build web-based applications quickly and easily. With some understanding of how databases work, it's quite simple to build highly interactive and appealing applications. When you want to turn them into mashups, however, you'd better get some serious help from your applications development organization because it's neither quick nor easy.
Friday, October 26, 2007
QEDWiki is a great tool, but is it really for creating mashups?
Believe it or not, this post is a review of QEDWiki, the mashup development tool being promoted by IBM. QEDWiki’s current home is with alphaWorks, whose charter is to put new IBM technologies into the hands of developers. AlphaWorks helps IBM get products and ideas fleshed out before bringing them to market. IBM says that 40% of alphaWorks offerings end up in IBM products. The other very cool message is that IBM is willing to experiment and drop 60% of its alphaWorks research products by the wayside. Wouldn't you just love to have IBM's research budget?
AlphaWorks has many products available for download, but the one currently getting all the press in mashup circles is, of course, QEDWiki, part of IBM’s mashup starter kit.
Unsurprisingly, IBM claims QEDWiki uses a wiki metaphor to allow non-developers to build mashups. Just as with a wiki, end users can create pages, modify or copy pages if they have permissions, share pages and even put in links to jump from one page to another.
That's just what I did. It was very easy to create a page and drop in widgets. I tied the various page elements together so clicking on a selection in a feed changed the contents of a URL widget elsewhere on the page. I used a web service from StrikeIron to look up the city and state associated with a zip code, and even let QEDWiki build the form to ask for input. It certainly wouldn’t take a developer to understand and use QEDWiki. While usability still needs some work (there are odd refresh problems and widget placement issues) the tool itself seemed sound.
After I pulled in a number of feeds, added widgets, and constructed URLs based on widget contents I had very quickly created a visually appealing and functional…portal.
Yep, I said portal.
Here’s the problem. When I wanted to bring different data streams together, I had to do it elsewhere, not within QEDWiki. So I found myself running to Yahoo! or Kapow or even del.icio.us to create feeds. (OK, the del.icio.us feeds weren't, strictly speaking, mashed) Once I mashed the feeds I could drop them onto my wiki page, but I couldn’t use QEDWiki itself to mash the contents.
Here’s another problem. When I wanted to pull data from different web pages into a single unified end-user experience, I had to run over to Kapow to create the web service, then go back over to QEDWiki to use the service within my wiki page.
You might conclude from what I’ve said so far that I didn’t like QEDWiki. On the contrary. I liked it very much. Other than the aforementioned usability issues, it was very easy to get started and definitely was not a tool that required development know-how. Once I had mashed content elsewhere I loved being able to drop elements on the page and link them together. It was great to pull search results based on a dissected URL parameter list. It was a no-brainer to click on a feed item and have another widget populated with the data served up from the item's link. I don’t pretend to have tried every single feature, but the features I did use were excellent.
It just wasn’t a mashup. QEDWiki consumes mashed content. It displays mashed content. It does not itself help mashers create mashed content.
That looks like it is the responsibility of Mashup Hub. Mashup Hub is the other part of IBM’s mashup starter kit, along with QEDWiki. I’ve queued it up for review some time in the future, but just looking at the specs, it looks like a server to transform behind-the-firewall data into feeds. While that’s great functionality, it’s hardly new or innovative. Unless I hear otherwise, I'm going to drop it at the end of my eval queue.
Go ahead and give QEDWiki a try. I'm betting you will enjoy working with it. Don’t get rid of your other mashup tools just yet, however. You will definitely need them.
AlphaWorks has many products available for download, but the one currently getting all the press in mashup circles is, of course, QEDWiki, part of IBM’s mashup starter kit.
Unsurprisingly, IBM claims QEDWiki uses a wiki metaphor to allow non-developers to build mashups. Just as with a wiki, end users can create pages, modify or copy pages if they have permissions, share pages and even put in links to jump from one page to another.
That's just what I did. It was very easy to create a page and drop in widgets. I tied the various page elements together so clicking on a selection in a feed changed the contents of a URL widget elsewhere on the page. I used a web service from StrikeIron to look up the city and state associated with a zip code, and even let QEDWiki build the form to ask for input. It certainly wouldn’t take a developer to understand and use QEDWiki. While usability still needs some work (there are odd refresh problems and widget placement issues) the tool itself seemed sound.
After I pulled in a number of feeds, added widgets, and constructed URLs based on widget contents I had very quickly created a visually appealing and functional…portal.
Yep, I said portal.
Here’s the problem. When I wanted to bring different data streams together, I had to do it elsewhere, not within QEDWiki. So I found myself running to Yahoo! or Kapow or even del.icio.us to create feeds. (OK, the del.icio.us feeds weren't, strictly speaking, mashed) Once I mashed the feeds I could drop them onto my wiki page, but I couldn’t use QEDWiki itself to mash the contents.
Here’s another problem. When I wanted to pull data from different web pages into a single unified end-user experience, I had to run over to Kapow to create the web service, then go back over to QEDWiki to use the service within my wiki page.
You might conclude from what I’ve said so far that I didn’t like QEDWiki. On the contrary. I liked it very much. Other than the aforementioned usability issues, it was very easy to get started and definitely was not a tool that required development know-how. Once I had mashed content elsewhere I loved being able to drop elements on the page and link them together. It was great to pull search results based on a dissected URL parameter list. It was a no-brainer to click on a feed item and have another widget populated with the data served up from the item's link. I don’t pretend to have tried every single feature, but the features I did use were excellent.
It just wasn’t a mashup. QEDWiki consumes mashed content. It displays mashed content. It does not itself help mashers create mashed content.
That looks like it is the responsibility of Mashup Hub. Mashup Hub is the other part of IBM’s mashup starter kit, along with QEDWiki. I’ve queued it up for review some time in the future, but just looking at the specs, it looks like a server to transform behind-the-firewall data into feeds. While that’s great functionality, it’s hardly new or innovative. Unless I hear otherwise, I'm going to drop it at the end of my eval queue.
Go ahead and give QEDWiki a try. I'm betting you will enjoy working with it. Don’t get rid of your other mashup tools just yet, however. You will definitely need them.
Tuesday, October 16, 2007
Is BPM another form of business mashup?
I was going to write a review of QEDWiki today, but IBM’s recent announcement about their starter kit has made me decide to leave it until I can do some more investigation. Given the flood of articles and blog posts about IBM’s announcement, I’m sure nobody will miss that I’m going to post on something else.
Specifically, what does the BPM community think about mashups?
BPM and SOA have been joined at the hip for several years. With SOA, business processes could be deconstructed into participating services which could be re-assembled like LEGO® bricks and executed in a production environment. I believe, although many BPM advocates would disagree, that service orientation saved BPM as a discipline. Once an organization had SOA, BPM could be used to solve myriad business problems rather than just model them.
Given the BPM-SOA link, I was very interested to read this article published on BPM Institute’s site titled SOA And Mashups – What to use when by Dr. Raj Ramesh, a BPM and SOA implementation specialist. Interestingly and surprisingly, Ramesh believes that mashups and SOA are distinct techniques for solving business problems. He says, “The question then is whether IT should use SOA or should it use mashups?” Ramesh goes on to conclude that IT should use mashups if the application is a one-off, and SOA, with BPM as the consumer, if services have the potential for reuse.
Why was I surprised? SOA versus mashups is an apples-to-oranges comparison. He should have compared BPM and mashups instead. BPM, presentation mashups and data mashups are all SOA consumers. You might want to read Rich Seeley’s article on SOA consumption patterns for a quick overview of how mashups and BPM are related. Service orientation enables mashups, it doesn't compete with them.
In fact, I would argue that BPM based on SOA is itself a form of business mashup. BPM is process-centric, pulls together content from many sources and presents a unified view of the content to the process participants. Isn’t that a business mashup?
Earlier in the piece Ramesh said that, “SOA provides a methodical paradigm for a robust long-term architecture based implementation. Contrast these to mashups that are easier to develop but are a challenge to manage due to the immaturity of the tools.”
Clearly BPM practitioners don't yet see the relationship between BPM and business mashups. Too bad. With a little effort aimed at making their tools easier to deploy, BPM vendors could already be sitting on some pretty mature business mashup tools.
Specifically, what does the BPM community think about mashups?
BPM and SOA have been joined at the hip for several years. With SOA, business processes could be deconstructed into participating services which could be re-assembled like LEGO® bricks and executed in a production environment. I believe, although many BPM advocates would disagree, that service orientation saved BPM as a discipline. Once an organization had SOA, BPM could be used to solve myriad business problems rather than just model them.
Given the BPM-SOA link, I was very interested to read this article published on BPM Institute’s site titled SOA And Mashups – What to use when by Dr. Raj Ramesh, a BPM and SOA implementation specialist. Interestingly and surprisingly, Ramesh believes that mashups and SOA are distinct techniques for solving business problems. He says, “The question then is whether IT should use SOA or should it use mashups?” Ramesh goes on to conclude that IT should use mashups if the application is a one-off, and SOA, with BPM as the consumer, if services have the potential for reuse.
Why was I surprised? SOA versus mashups is an apples-to-oranges comparison. He should have compared BPM and mashups instead. BPM, presentation mashups and data mashups are all SOA consumers. You might want to read Rich Seeley’s article on SOA consumption patterns for a quick overview of how mashups and BPM are related. Service orientation enables mashups, it doesn't compete with them.
In fact, I would argue that BPM based on SOA is itself a form of business mashup. BPM is process-centric, pulls together content from many sources and presents a unified view of the content to the process participants. Isn’t that a business mashup?
Earlier in the piece Ramesh said that, “SOA provides a methodical paradigm for a robust long-term architecture based implementation. Contrast these to mashups that are easier to develop but are a challenge to manage due to the immaturity of the tools.”
Clearly BPM practitioners don't yet see the relationship between BPM and business mashups. Too bad. With a little effort aimed at making their tools easier to deploy, BPM vendors could already be sitting on some pretty mature business mashup tools.
Monday, September 17, 2007
Do we need business mashups?
I've been talking quite a bit about business mashups lately, and besides the standard, "What is a mashup?" and "Why did you have to call them that?" I've been asked whether we need business mashups. Aren't the mashups we already have good enough?
That's a good question, but to answer it I need to explain what other sorts of mashups are out there in the world. For simplicity's sake I will only talk about software mashups, not music mashups, video mashups or any other sort of mashup.
There are several types of software mashups, the most common being the consumer mashup, best exemplified by the many GoogleMap applications. GoogleMap applications range from calculating the distance of a lunchtime run to showing which hotels the stars frequent in Beverly Hills. Just to play around, I even created one myself, showing the good burrito joints near my office. If you're interested, you can take a look at many consumer mashups by visiting Programmable Web.
Other common types of mashup are “data mashups” and “enterprise mashups.” A data mashup combines multiple data sources into a new data source, such as combining the data from multiple RSS feeds into a single feed with a graphical front end. An enterprise mashup usually integrates data from internal and external sources. For example, it could create a market share report by combining an external list of all houses sold in the last week with internal data about which houses one agency sold.
Consumer and data mashups aren’t enough if you are trying to solve business problems. These problems generally have several things in common. They involve multiple stakeholders, they cross organizational boundaries, they interface with multiple back-end systems, and at the heart of every business problem is a process: a process for provisioning new employees, approving expense reports, or approving sales discounts.
Consumer and data mashups don’t provide the necessary capabilities to solve business problems. Business Mashups offer not only a unified experience, like consumer mashups, but have at their core a powerful process engine. This process engine lets you cross organizational boundaries and pull together stakeholders throughout your business. You get the right information to the right people at the right time so they can get the job done. No consumer or data mashup can do that.
So do we need another sort of mashup?
Oh, yes, we do.
That's a good question, but to answer it I need to explain what other sorts of mashups are out there in the world. For simplicity's sake I will only talk about software mashups, not music mashups, video mashups or any other sort of mashup.
There are several types of software mashups, the most common being the consumer mashup, best exemplified by the many GoogleMap applications. GoogleMap applications range from calculating the distance of a lunchtime run to showing which hotels the stars frequent in Beverly Hills. Just to play around, I even created one myself, showing the good burrito joints near my office. If you're interested, you can take a look at many consumer mashups by visiting Programmable Web.
Other common types of mashup are “data mashups” and “enterprise mashups.” A data mashup combines multiple data sources into a new data source, such as combining the data from multiple RSS feeds into a single feed with a graphical front end. An enterprise mashup usually integrates data from internal and external sources. For example, it could create a market share report by combining an external list of all houses sold in the last week with internal data about which houses one agency sold.
Consumer and data mashups aren’t enough if you are trying to solve business problems. These problems generally have several things in common. They involve multiple stakeholders, they cross organizational boundaries, they interface with multiple back-end systems, and at the heart of every business problem is a process: a process for provisioning new employees, approving expense reports, or approving sales discounts.
Consumer and data mashups don’t provide the necessary capabilities to solve business problems. Business Mashups offer not only a unified experience, like consumer mashups, but have at their core a powerful process engine. This process engine lets you cross organizational boundaries and pull together stakeholders throughout your business. You get the right information to the right people at the right time so they can get the job done. No consumer or data mashup can do that.
So do we need another sort of mashup?
Oh, yes, we do.
Subscribe to:
Posts (Atom)
