Quick Copy: Simple Elegance

The more full-featured Ratchet-X becomes, the more tempted we are to unduly emphasize the product's more “cool and complicated” features during demos. Now I’m not saying these features are not useful. No doubt they are or we wouldn’t have funded their development in the first place. However, this emphasis on the WOW features sometimes causes us to gloss over some of the other more mundane, yet equally as valuable features.

For example, have you ever used Ratchet-X to move data from one screen to another? While we spend a lot of time talking about integrating existing application screens with external data sources, we tend to down play the simple screen-to-screen copy feature. That’s unfortunate because virtually every Ratchet-X user indentifies this as a need, and yet we tend to demo this feature only after being asked.

So, for all of you who constantly enter data into multiple screens either for data entry purposes or launching queries in other desktop systems, I recommend you give the Quick Copy feature a look. Quick Copy is a simple feature that allows you to link fields on multiple screens so that data can flow between these screens in either direction. Simple, but pretty powerful when it comes to speeind up those pesky repetitive typing tasks.

Check Quick Copy when you get a chance. Better yet, give me a call and I’ll demo it for you.

Ratchet-X and Application Rationalization

Over the past two years or so, a number of consulting organizations have added “Application Rationalization” to their roster of services. Simply stated, application rationalization is the process by which an organization assesses its portfolio of application software and decides which applications need to be maintained, sunset or replaced. While this process may look different from organization-to-organization, the common goal is to reduce application bloat and functional redundancy thereby reducing overall IT cost.

Ratchet-X can be a very helpful tool during the application rationalization process. Often, applications are kept in production because they provide some functionality that can’t be added to a preferred system. Ratchet-X allows organizations to add or integrate that functionality into the preferred system quickly and easily thus allowing the redundant system to be sunset. Further, the rationalization process uncovers a slew of integration code and cron jobs that shuttles data between systems. Ratchet-X can help alleviate this web of spaghetti code by allowing organizations to deliver information normally moved in batch, to applications in real time at the point of need.

So, if you’re engaged in or considering undertaking an application rationalization project, keep Ratchet-X in mind as you evaluate system consolidation.

Document Enable Any Application With Ratchet-X

I recently received an email from a customer saying; “I’m amazed at how many places within our organization we’ve applied Ratchet-X beyond the original project.” We hear this all the time. Although I often make this point during customer presentations, it usually doesn’t set in until the customer lives and uses Ratchet-X for a bit.

One example where Ratchet-X is repeatedly applied beyond the original customer project is in the area of enterprise document management (EDM). Once customers realize that Ratchet-X is actually a piece of desktop middleware that brokers a “conversation” between application screen data and external data sources (and not merely an integration tool purchased to solve a specific problem), integrating applications into the customer’s EDM system is a natural fit.

Ratchet-X is now commonly being used as a way to both submit documents to, and retrieve data from, EDM repositories. On the capture side, Ratchet-X works best with images and forms since the information used for indexing the documents is often available in the integrated application screen. With regard to document retrieval, pretty much every application user can benefit by an onboard ability to instantly link to documents that relate to the entity referenced by the application screen data. Since Ratchet-X enables more applications, and by extension users, to leverage the EDM, the costs associated with purchasing and maintaining the EDM is justified over a much larger pool of users.

Not many products can claim they dramatically impact the ROI of the other products running within the organization. So try integrating Ratchet-X with your EDM back-end and let me know how it goes. Also be on the lookout for the release of Ratchet-X plugins that integrate into the industry’s most popular EDM products. If you’re thinking of doing such an integration, make sure you check with us to see if we have a plug-in for your EDM in the pipeline.

Twitter - I Just Don't Get It! Never Did, Never Will.

I know this has little to do with the purpose of this blog but I can't take it anymore. Today, I had yet another associate of mine invite me to track his every movement on Twitter. This comes just one day after telling another colleague that I refused to communicate with him exclusively through Pownce.

Does anyone over the age of 18 really need to know at this moment which friend is picking the nuts out of his teeth from the Snickers bar he just ate? The only reason I know it was a Snickers bar is because I received an urgent alert to that fact five minutes prior as he was unwrapping said Snickers bar.

Just because we have the technical ability to transmit every fleeting thought and the undertaking of every mundane task doesn't mean we should. But what do I know, I'm just a cranky old geezer with a little less time on my hands than some.

If you're connected to me via Twitter, you probably know that already.

What's New in Ratchet-X Version 3.5?

Good news for RatchetSoft users! Ratchet-X version 3.5 was released to the Ratchet-X Community last week. Here’s a review of what’s new.

Assembles
The most significant change in version 3.5 is the introduction of Assembles. While Ratchet-X has always had the ability to extract, paste and manage datasets that scan multiple applications and application screens, version 3.5 shifts the responsibility of supporting this feature from the plug-in developer to the appspace creator and the platform itself. As part of our ongoing effort to focus the platform on managing desktop data rather than mere application automation, we felt that multiple application and screen support should be something that the plug-in creator inherits rather than have to specifically plan for. This supports the philosophy of loosely coupling applications and data sources.

So now, if a plug-in requires data from an xmodel that spans multiple screens, it’s up to the appspace developer (the only person who really knows this to be the case for a particular application integration), to define that fact by instructing the Commander to create an assemble in the task list when the user executes the associated plug-in. Once the assemble is in the task list, it becomes much easier to be repurposed to other applications and sources. For more on assembles, check out the Ratchet-X documentation.

Macro Throttling
Appspace macros are created by the appspace author. This being the case, defined macro execution speed is usually based on the performance the appspace creator sees on his/her desktop. However, once the appspace is deployed, the macro’s execution speed may need to be altered to accommodate the performance of an end user’s workstation. This is the purpose for macro throttling. Macro throttling allows each individual end user to globally speed up or slow down the performance of macros executed on his or her desktop (five levels of throttling).

AutoSave/AutoBackup
In version 3.5, the Appspace Editor has both an AutoSave and AutoBackup feature. When Appspace Editor saves, it makes a backup of the previous version. Further, once you save an appspace for the first time, Appspace Editor will autosave a copy of your appspace based on a user defined autosave time interval.

In addition, there have been various changes to the the connector API and plug-in API to accommodate changes to the task list and assembles.

If you have any questions or comments regarding the new version, please gives us a call or drop me an email. Good luck with version 3.5 of Ratchet-X!

The Evolving Role of Organizational IT

I recently read two blog postings that touched on the future of organizational IT with regard to the rollout of new technology. The first entry encapsulated the view of venture capitalist Kevin Efrusy of Accel Partners. Kevin’s take is he is increasingly seeing technology sold directly to end users – the folks who pay for and receive the benefit from new technology. In fact, he’s putting his money where his mouth is by funding companies that deliver solutions users can find, buy and implement (or at least pilot), on their own.

The second posting was from Jeremy Geelan covering an interview he did with Rod Smith from IBM. Based on the posting title, the posting was supposed to be about IBM’s SMASH (secured mashups) project. However, the focus quickly switched to the concept of user empowerment. The idea being that organizations have pockets of non-technical users who are constantly looking for new technologies that can help them become more productive. He calls this group “shadow IT”. Cool name. No doubt, the concept of mashup and situational applications plays directly into the hands of these groups.

I strongly agree with both gentlemen’s sentiments. In fact, we see it ourselves everyday. While we spend a lot of time speaking with IT folks about how Ratchet-X can help an organization integrate the unintegratable, increasingly, we are brought into organizations by the end users who will directly benefit from a Ratchet-X implementation. Overall, I think greater user involvement in finding, evaluating and even piloting technologies is a good think. However, where there is opportunity, there is danger. While these user groups have the best of intentions in mind when seeking a solution, their views are often myopic and skewed towards their specific needs. This is totally understandable. Salesman are looking for tools that help them sell more, faster and better. They’re not in the business of worrying about what the folks in Accounting need. Nor should they be, that’s not their job. However, if they are bringing new technology into an organization, someone has to think about scale, integration, support and maintenance. This IT’s job.

IT’s role is changing in that in the past, requirements were developed and a solution was devised, products selected and rolled-out. Today, IT is often not hearing about these solutions until they’ve been piloted by shadow IT. Operating in this environment requires a shift in focus from deciding and selecting to sheparding and shaping. While IT does not want to discourage the valuable service shadow IT provides, it can’t let the process run amuck. IT must keep its head in the game and make sure these situational solutions are coordinated so they can be integrated and managed effectively. I often hear folks talk about a day when it won’t matter what disparate groups bring into the organization because everything will “just talk to each other through XML”. OK, when that day gets here, I’m all for it. However, until then, IT will needs to recognize its evolving role from systems dictator to user educator, guide and occasionally, bouncer.

Is Web 2.0 A Disaster?

I received my daily CIO Insight Quick Facts email today and was sucked in by the provocative subject line; “Is Web 2.0 A Disaster?” However, when I clicked the embedded link, the “disaster” trumpeted in the headline had quickly been downgraded to; “Web 2.0: To Good To Be True?” Note to editor…these two statements are not semantically the same. Regardless, the marketing ploy worked because I was compelled to read further.

The article opens with a Basex claim stating collaborative tools are costing businesses over a half a trillion dollars in lost productivity due to worker information overload. I didn’t read the actual Basex report (because it cost $199), so I can’t say for sure this number is hogwash but…

If companies are truly experiencing these kinds of losses due to too much information, I need to shift RatchetSoft’s focus and become a knowledge management and collaboration consulting company because the market opportunity is apparently huge. Information overload is rarely the fault of the technologies that deliver the information. It’s usually the fault of one or more of the following:

1) The group asking for the information doesn’t really know what they need. Looking for a needle in a haystack assumes you know what a haystack and needle looks like.

2) The collaboration solution is not implemented properly. Opening up the spigot and letting the data flow is just the easy part of knowledge management and collaboration. Filtering it for relevancy and making available at the right time is the hard part.

3) The information itself is of poor quality. Garbage in, garbage out.

Then the article moved on to the issue of security.

“Corporate executives also worry that Web 2.0 tools pose a security threat. Fifty-two percent of 472 executives say securing and protecting sensitive data was the top barrier to adopting the tools, according to a January poll by the Economist Intelligence Unit, a research and advisory firm, for business consultancy KPMG.

Is this news top anyone? In fact, the real news here is that only 52% of these executives see security an adoption barrier. Web 2.0 is no different than any other technology that involves information. Security has been, or at least should have been, a barrier to the adoption of every technology since the invention of the network. Bottom line is security good, hacking threats, bad, very bad. We get it. Nothing specific here to Web 2.0.

Finally, despite all the doom and gloom, the article concludes with some good news for Web 2.0:

“Three of four executives said they believe collaborative tools will foster innovation in their companies. And almost 70 percent agreed that Web 2.0 will help their people work more efficiently.”

So 70% of the respondents agreed that the half a trillion dollar loss in productivity is worth the increases in innovation? Uh, OK.

I read these kinds of articles all the time (maybe I need to get out more), and often come away asking myself; “What did I just really learn?” I’m not sure because it’s hard to decipher true insight amongst the headline hyperbole, contradictory statistics and often obvious observations by pundits. Dare I say there’s too much unfiltered information coming in. Hey, maybe there’s something to this.

SOA and Enterprise Mashups - Work On Your Pitch

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.

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!

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.