I read an article today on SeachSOA.com entitled; “Enterprise Mashups, SOA’s Killer App?” While I totally agree with the sentiment of the article (that business users could care less about SOA), I’m a bit surprised that this is a revelation to anyone. The bottom line is business users don’t care about technology for technology’s sake. They only care about the relevant and tangible solutions a technology delivers. And while we technologists know how SOA translates into shorter times to value and more agile systems, business users don’t want to hear pie in the sky promises. They want to see quick and powerful results.
Regardless of whether it’s ultimately enterprise mashups or some other by product of SOA, it’s incumbent upon those who introduce new technologies into an organization to be smart marketers. As smart marketers of technology, we should keep the following points in mind when trying to secure business user buy in:
1) Know your audience. All too often, technologists get caught up in the technical details that turn themselves on yet forget about the wants, desires and needs of the person whose appetite they seek to whet. The CFO and data entry manager have very different views of the world. Be mindful of these differences and tailor your pitch accordingly.
2) Sell Specific Benefits. While we technologies love to extol the virtues of agile systems and straight through processing, business people’s eyes tend to glaze over when we use such general terms. Find out what’s important to them and then discuss the technology within that context.
3) Don’t Oversell. Business users are a pretty skeptical bunch. They’ve been sold a bill of goods before and have been left holding the bag. SOA and enterprise mashups are pretty powerful concepts that don’t require hyperbole to get others excited as well. Keep your pitch relevant, specific and on point and the rest will follow. Don’t flip the Bozo bit.
Common sense, yes. Commonly performed practice by technologists…not so much.
When I first learned about SOA, it reminded of the first time I learned about ODBC (Open Database Connectivity). I thought to myself that embedding in my applications and reports the ability to hit virtually any data source regardless of vendor or platform was going to be a game changer for business users. However, I also knew that merely telling them about a software driver that enabled a programmer to access multiple databases via native programming language access calls would be greeted with cricket calls. The best way to generate enthusiasm was to show them the power of ODBC from within the report writers and Excel spreadsheets they already used. It’s one thing to tell a business user what a given technology will do for them, it’s another thing entirely when you can show them.
I remember one business manager saying to me after a demo; “…so you’re saying this ODBC thing allows me to run a report that accesses our daily sales from the field and inventory levels in our warehouse in real time using the tools I already know instead of waiting for a weekly download and import. WOW!”.
SOA and enterprise mashups in one form or another will represent one of these WOW moments for business users if we present them in terms they understand and within a relevant and important context.
Tuesday, January 29, 2008
Friday, January 18, 2008
Integrating Ratchet-X With Other Mashup Tools (Microsoft Popfly, Yahoo Pipes, etc.)
We received a question on our support forum today that had to do with integrating Ratchet-X with other mashup tools such as Microsoft Popfly, Yahoo Pipes and others. Since we received this question a number of times before, I thought it wise to blog about this topic in some detail.
The first logical question one should ask is; “Why in the world would I want to integrate mashups that I create using other tools with Ratchet-X? Isn’t Ratchet-X a competing mashup tool?"
Let me address the second question first. There is no doubt that based on the broad definition of mashup, Ratchet-X can also be considered a mashup tool. I certainly believe this opinion and reflect it in the way we promote Ratchet-X. However, it is not a mashup tool in nearly the same sense that the aforementioned tools are. You use Popfly and Yahoo Pipes to create “new” applications from existing mashups, services and function parts. The end result is a rapidly created new user interface tailored to the specific needs of the user. That’s great! That’s not what Ratchet-X does. Ratchet-X enables users to mash existing services and function parts into existing applications without having to create a new or alternative user interface. That’s the whole point of the product. We believe that while there is a significant market brewing for mashup tools that empower developers and users to rapidly create new applications from existing stuff, we also believe the vast majority of the world wants functionality mashed into the applications they already use – their systems of record so to speak. Given this premise, we do not compete with other mashup development platforms. In fact, we compliment them. This leads me to answering the first question regarding why one would integrate mashups with Ratchet-X.
This question is answered in two parts. The first part is easy. Once you create a mashup using any one of these mashup development tools, in the end, it is still an application like any other. This application has a user interface, performs its function and is static. So as the users' needs change, the mashup must either be modified or cloned and modified to accommodate these new requirements. If the user of the mashup is also the mashup author or has the prerequisite skills to make the changes, great! The changes should be made directly to the mashup.
However, there are two issues of concern. The first being you can see how this can quickly run amok as the number of versions and permutations of versions grows – along with the support headaches. Second, I believe the vast majority of end users using mashups for the foreseeable future will not have the skills required to modify the mashup to accommodate their changing needs. If this is the case, users are left fending for themselves waiting for IT resources to free up and get to their project. How many developers place modifying existing code as a high priority item? Not many. I certainly wouldn’t.
So the user now has an application that needs to have functionality added to it and they do not have the skills or the stomach to modify the application. Well, that’s why we created Ratchet-X. This use case is no different for a mashup application then it is for any other application. Create the appspace, define the regwins and snippets and link to xmodels.
The second scenario is a little more interesting. Say I create a Popfly mashup that returns data that I’d like to integrate into an existing application. Can I use Ratchet-X to get the data out of the mashup interface and into my application of record? Absolutely! All you need to do is create an appspace that profiles both the Popfly results screen and the system of record data entry screen and run the results through Commander’s Task List. Here’s a simple example. Let’s say I create a Popfly mashup that returns a detailed stock quote for a ticker symbol. Assuming I’ve created the appspace described above, when the Popfly results screen is displayed, I can tell Commander to copy the data to Commander’s task list. I can then go to the task that contains the data in the task list and paste it into the system of record screen. In two clicks, I’ve moved the data from Popfly to my other application. And the best part about it is that neither application has any idea that it just exchanged data with other. That’s pretty neat!
The first logical question one should ask is; “Why in the world would I want to integrate mashups that I create using other tools with Ratchet-X? Isn’t Ratchet-X a competing mashup tool?"
Let me address the second question first. There is no doubt that based on the broad definition of mashup, Ratchet-X can also be considered a mashup tool. I certainly believe this opinion and reflect it in the way we promote Ratchet-X. However, it is not a mashup tool in nearly the same sense that the aforementioned tools are. You use Popfly and Yahoo Pipes to create “new” applications from existing mashups, services and function parts. The end result is a rapidly created new user interface tailored to the specific needs of the user. That’s great! That’s not what Ratchet-X does. Ratchet-X enables users to mash existing services and function parts into existing applications without having to create a new or alternative user interface. That’s the whole point of the product. We believe that while there is a significant market brewing for mashup tools that empower developers and users to rapidly create new applications from existing stuff, we also believe the vast majority of the world wants functionality mashed into the applications they already use – their systems of record so to speak. Given this premise, we do not compete with other mashup development platforms. In fact, we compliment them. This leads me to answering the first question regarding why one would integrate mashups with Ratchet-X.
This question is answered in two parts. The first part is easy. Once you create a mashup using any one of these mashup development tools, in the end, it is still an application like any other. This application has a user interface, performs its function and is static. So as the users' needs change, the mashup must either be modified or cloned and modified to accommodate these new requirements. If the user of the mashup is also the mashup author or has the prerequisite skills to make the changes, great! The changes should be made directly to the mashup.
However, there are two issues of concern. The first being you can see how this can quickly run amok as the number of versions and permutations of versions grows – along with the support headaches. Second, I believe the vast majority of end users using mashups for the foreseeable future will not have the skills required to modify the mashup to accommodate their changing needs. If this is the case, users are left fending for themselves waiting for IT resources to free up and get to their project. How many developers place modifying existing code as a high priority item? Not many. I certainly wouldn’t.
So the user now has an application that needs to have functionality added to it and they do not have the skills or the stomach to modify the application. Well, that’s why we created Ratchet-X. This use case is no different for a mashup application then it is for any other application. Create the appspace, define the regwins and snippets and link to xmodels.
The second scenario is a little more interesting. Say I create a Popfly mashup that returns data that I’d like to integrate into an existing application. Can I use Ratchet-X to get the data out of the mashup interface and into my application of record? Absolutely! All you need to do is create an appspace that profiles both the Popfly results screen and the system of record data entry screen and run the results through Commander’s Task List. Here’s a simple example. Let’s say I create a Popfly mashup that returns a detailed stock quote for a ticker symbol. Assuming I’ve created the appspace described above, when the Popfly results screen is displayed, I can tell Commander to copy the data to Commander’s task list. I can then go to the task that contains the data in the task list and paste it into the system of record screen. In two clicks, I’ve moved the data from Popfly to my other application. And the best part about it is that neither application has any idea that it just exchanged data with other. That’s pretty neat!
Wednesday, January 9, 2008
Semantic Coding - Whose Job Is It?
Pete Warden covered Ratchet-X on his blog this week. While Ratchet-X was prominently featured, the real thrust of his posting has to do with the semantic coding of content and screen scraping. I think Pete’s most salient point is the following:
“The promise of the semantic web is that it will allow your computer to understand the data on a web page, so you can search, analyze and display it in different forms. The top-down approach is to ask web-site creators to add information about the data on a page. I can't see this ever working, it just takes too much time for almost no reward to the publisher.”
I strongly agree with this point. Publishers will only code their content and services with metadata if there’s something in it for them. Unfortunately for most publishers, the rewards are not commensurate with the effort. And for those willing to put in the effort, what semantic schemes should they use?
At RatchetSoft, we break the semantic issue down into two bases components; access and meaning. Ratchet-X goes a long way in solving the “access” issue by creating a user-focused method for accessing data sources by leveraging established accessibility standards (MSAA and MUIA). These methods are much more reliable and stable than traditional screen scraping techniques.
The “meaning” issue is a bit more challenging. On that front, we shift the semantic coding responsibility to the entity that actually reaps the benefit of supplying the semantic metadata. So, if you’re a user that wants to add new features to existing application screens, you have a vested interest in supplying metadata about those screens and data sources so they can be processed by external services. If you are a publisher who has a financial interest in exposing data in new ways to increase consumption of data, you have a strong motivation to semantically code your information.
While I’d love to see broad adoption of one semantic scheme, I don’t see this happening any time soon. This is why our Ratchet-X product not only allows plug-in authors to supply metadata about their content (via xmodels), we also allow end users to supply metadata about the data sources they frequently use. While allowing both publishers and consumers to supply metadata about data sources poses some potential conflict and duplication related risks, it also allows us to shift the responsibility of coding to the party that receives the benefit.
“The promise of the semantic web is that it will allow your computer to understand the data on a web page, so you can search, analyze and display it in different forms. The top-down approach is to ask web-site creators to add information about the data on a page. I can't see this ever working, it just takes too much time for almost no reward to the publisher.”
I strongly agree with this point. Publishers will only code their content and services with metadata if there’s something in it for them. Unfortunately for most publishers, the rewards are not commensurate with the effort. And for those willing to put in the effort, what semantic schemes should they use?
At RatchetSoft, we break the semantic issue down into two bases components; access and meaning. Ratchet-X goes a long way in solving the “access” issue by creating a user-focused method for accessing data sources by leveraging established accessibility standards (MSAA and MUIA). These methods are much more reliable and stable than traditional screen scraping techniques.
The “meaning” issue is a bit more challenging. On that front, we shift the semantic coding responsibility to the entity that actually reaps the benefit of supplying the semantic metadata. So, if you’re a user that wants to add new features to existing application screens, you have a vested interest in supplying metadata about those screens and data sources so they can be processed by external services. If you are a publisher who has a financial interest in exposing data in new ways to increase consumption of data, you have a strong motivation to semantically code your information.
While I’d love to see broad adoption of one semantic scheme, I don’t see this happening any time soon. This is why our Ratchet-X product not only allows plug-in authors to supply metadata about their content (via xmodels), we also allow end users to supply metadata about the data sources they frequently use. While allowing both publishers and consumers to supply metadata about data sources poses some potential conflict and duplication related risks, it also allows us to shift the responsibility of coding to the party that receives the benefit.
Subscribe to:
Posts (Atom)