http://searchsoa.techtarget.com/answer/Wheres-the-ROI-in-a-public-API

One issue not covered in the book (which Dan and I briefly discussed) is the resistence to API development I have seen in large organizations. For example, management will argue:

“I can’t afford to take the time to expose our team’s assets! We have to meet the requirements of our specific business users”
-or-
“I can’t risk our systems slowing down because other teams are leveraging our API”

These are comments straight out of silo-ville. This is an example of management thinking more about protecting a fiefdom of data and functionality rather than working for the good of the entire firm.

Yes – there are instances where security or “mission-critical” issues override the desire for an API. But in my experience the amount of systems that could potentially be opened up is far greater. A closed application inventory hampers innovation and -by extension- is a negative impact on the firm.

Dan’s book takes on the API issues at a non-technical level, and has been useful in helping me educate managers to see the benefits of opening up their products to outside collaborators.

Item 1: Microsoft Re-Enters the World of Mashups

I totally did not see this one coming. After Microsoft shuttered Popfly, its own mashup environment, I had assumed their flirtation with mashups was over. Yet from out of nowhere comes ExcelMashup.com, a platform for mashing together excel workbooks and public APIs.  Clearly Microsoft has not abandonded mashups and now sees Excel as a means to drive their creation. I recall a 2008 Web 2.0 Expo talk given by John Musser, founder of ProgrammableWeb, where he predicted Enterprise Mashups would be the Excel of our era. In his prescient way, it looks like John might have been closer to the truth than he thought!

Item 2: An Enterprise-worthy Open Source Mashup Tool

The good news continued with the release of Convertigo’s Enterprise Mashup Server Community Edition (press release )

I have always felt that the mashup community needed to get traction with the open-source community in order to be successful in enterprise environments (I had high hopes for the Open Mashup Alliance). Obviously, people could always manually connect various APIs and code an interface around the results, but even a small amount of tooling can accelerate this process dramatically. And using a mashup product like Convertigo CE can expose this discipline to a much broader class of non-developer. Convertigo CE has 4 main functions:

• Connectors — for any SQL, REST, SOAP, RSS, ATOM or Microsoft Excel file;
• Sequencer — combines, orchestrates and exposes new REST, SOAP or JSON services;
• Gadgetizer — feed portals with services and widgets for Microsoft SharePoint, Oracle Web Center, IBM WebSphere portal or any open source portal;
• Mobilizer — build and deploy cross-platform mobile native or web applications for iOS, Android, BlackBerry and Windows Mobile.

I used an earlier version of Convertigo (along with tools from JackBe and Kapow) at a Web 2.0 presentation I gave on mashups and it was very powerful. I plan on testing the Community Edition and posting an in-depth review in the future.

Item 3: If This… Then That…

The last announcement comes in the spirit of web-based mashup creation tools like Dapper and Yahoo Pipes. “If This then That” (http://ifttt.com) is a new site that provides a way to mash services together to perform simple, specific tasks. For example, “IF it is going to rain, THEN send me an SMS”. The condition would use a weather API to check the forecast for your area, and then an SMS API to send you a notification if needed. These types of simple automated tasks are the equivalent of the parameciums of the mashup world, and yet the site is hugely popular and tens of thousands of these tasks have been created by the community. As I wrote in my post, “Dumbing-down Mashups: A Good Thing?” the spread of simpler mashup products like ifttt is ultimately what allows a more complex ecosystem to develop. Non-developers will be casually drawn to a site like ifttt at home, fall in love with it, and ultimately demand similar capabilities in their workplace.

Bollen analyzed the text of daily Twitter feeds (9.6 million in total) over a nine-month period in 2008 with two mood-tracking tools. One simply measures whether the daily tweets were positive or negative. The other tool sought to measure human mood states by categorizing tweets under six terms equated with different mood types: calm, alert, sure, vital, kind and happy.

He claims that using this technique allowed him to anticipate Dow stock prices 3-4 days later with 87% accurracy. I havent looked at the study in detail, so I don’t know if he’s measuring the overall movement of the DOW, or specific issues.

Mining Twitter sentiment seems to be all the rage. Streambase recently announced a feed based on Twitter sentiment, and Thompson Reuters’ Open Calais has offered similar features for a while now.

What’s news here is not that these techniques are being applied.. I wrote about a similar mashup last June. No; the thing I think is interesting is that you are now seeing this approach become mainstream.

I’m certainly not the first person to advodate this approach, but I gave clear examples in Mashup Patterns (back in 2009) of using this technique to get “Advance Knowledge of an Industry’s Performance” and to “Spot the Underlying Causes of Trends in the Housing Market”. Besides market performance, I wrote about how firms could use these techniques to uncover issues that might threaten the reputation of their brand (or of a competitor’s).

Between Innovation and Commoditization lies a Competitive Gap

Like most innovations, there is an “S” curve that takes you from humble beginnings to ubiquity. The gap in-between these points is where you can create a competitive advantage. I think this latest news demonstrates that Leading Indicator mashups are nearing the right side of this chart.

Firms are perpetually caught in a struggle between experimenting with new products and tools that can give them an edge in their market, and playing catch-up with companies that have proven-out new ideas and deployed them more quickly.

What’s interesting about Mashups is that while some applications of the technology are clearly moving to the commodity stage, many others are not. And “Enterprise Mashups” as a discipline unto itself is definitely still down to the right of the chart.

“Managing Innovation” may seem like an oxymoron, but firms should recognize this maturation curve and try to move items along it more quickly. This helps maximize the time they can enjoy the competitive advantages the new technology yields.

For the “Leading Indicator” pattern, I think that window is closing quickly (if it’s not already closed). But there are still large problem spaces where mashups can offer new and valuable solutions that will help you leap ahead.

http://searchsoa.techtarget.com/podcast/Application-mashups-and-data-migration-in-the-cloud

It’s a short discussion of some of the risks of using external SaaS and Cloud services, and how mashups can help.

Part of the inspiration for that article came from my own mobile-mashup experiment. I’m in the middle of writing an iPhone app which exposes a neat mashup I wrote. So I’ve been busy tinkering away on my new Mac, the first computing device from Apple that I’ve purchased in more than 20 years.

By the way, if you want to get up-and-running on iOS or Android devices quickly, I strongly recommend you take a look at Appcelerator’s Titanium framework.

Another product I came across while deciding what technology to use to build out my idea was something new called Moofwd. What is it? Well, according to their web site, it’s a mashup development environment and a rich-client platform that  supports Blackberry, Android, iPhone, WindowsPhone 7 & Java devices.

They dont seem nearly as mature as Titanium (which is not specifically targeting mashups but nonetheless comes with some examples out-of-the-box) but I have reached out to them to learn more about their offering. After spending a couple of posts on the failure of mashup companies, it’s good to see some fresh blood trying to carve out a niche for themselves.

I’ll take a closer look at both products in the future and share some more of my experience building my first iPhone mashup as well as the infrastructure I had to put in place behind it.

You might argue that end-users shouldn’t know or care about mashups. Were mashups fit to be created only in the corridors of IT, I could agree with this view.  But part of the power of mashups is giving control to end-users to craft their own solutions. This is never going to happen if mashups dont get more recognition.

To help improve the visibility of mashups, I concluded my talk by proposing a set of open “Made with Mashups” icons I am releasing under the Creative Commons license. Lest we forget, many of the technologies we take for granted today raised their awareness by taking a similar approach:

 My hope is that by starting to brand our mashups, we can increase the general level of awareness of mashups, regardless of the underlying implementation technology. Please browse over to this page to view the complete collection.

Seriously though; it was a great experience. But I was always aware that these agencies had tons of data and no real efficient way to manage it all.

I recall one “document scanning” project solely to help the USDA organize all the written letters they received. Another time I was shown giant paper ledgers used to track the history of foreign loans made by the agency. Apparently, they couldn’t be entered into spreadsheets because of all the mathematical errors they’d accumulated over the years. The government seemed immune from information revolution if only because it had such difficult managing what it already had.

But in just a few short years things have changed dramatically. Information that was previously locked away is now open for exploration – and exploitation! I’m really excited about what projects like The Sunlight Foundation are doing with these resources. I haven’t made as much personal use of data.gov as I’d like, but I’m planning on it. It’s fun to revist old haunts, especially when things are better than when you left.

They were one of the original “do-it-yourself” API tools a few years back before switching their model to contextual advertising. I wasn’t thrilled to see the change in focus, but at least they kept Dapper up and running.

 Marshall Kirkpatrick has written an excellent article about discovering Dapper, and the effect it had on him. He barely mentions ”mashups”, but you get a great sense of how empowering the technology was for him.

He also mentions NeedleBase in passing, a free hosted tool that I admit I haven’t used much. In practice, it sounds very similar to Connotate, a commercial mashup product whose “Intelligent Agents” learn what to scrape by example. Alas, NeedleBase is a product of ITA Software, a travel search/software firm that was acquired by Google back in July. The product is still available, but Google doesn’t exactly have a good track record in the mashup space.

I see a clear trend away from “mashups”, and towards “data harvesting”.  Marshall’s uses of Dapper are clearly in the “Harvest” category, and NeedleBase describes itself as “a revolutionary platform for acquiring, integrating, cleansing, analyzing and publishing data on the web”. Even venerable Kapow Technologies no longer mentions the word “mashup” on their homepage, but you can read plenty about acquiring data from the web.  

What does it mean? Marshall makes a good argument how about technology that is too innovative for the current marketplace often doesn’t gain the traction it needs to succeed. I think we are seeing a slight “dumbing down” of mashup technology/terminology to a few simple use cases that people can easily grasp. Once they understand how these tools can give them easy access to a wealth of new information, they will start combining the various pieces and “mashups” will finally gain broad acceptance as a solution paradigm.

But that’s just the path for the teeming masses. If you’re reading this, you’re probably ahead of the curve and looking beyond scraping to mashups’ more powerful capabilities. Most firms have barely (if that!) begun to exploit the potential of mashups, and I see that as a chance to gain a competitive advantage. You can wait until mashups are mainstream (again) or you can use this time to build an enterprise app store, create propreitary information streams, and make your IT department more productive. Will you wait until your peers seize this opportunity, or will you use this time to jump ahead of them?

Last week JackBe announced the latest version of their flagship mashup product, Presto 3.0.  Perhaps the most interesting part of this press release is the line:

The new release provides a platform for creating internal Enterprise App Stores

But what does it really mean to have an “internal App Store”?

Let’s back up for a second. In Mashup Patterns, one of the core features I said was important to consider in a mashup platform was the capability for “publication and promotion”. That is, the ability to take mashups and push them out into the community for use (and reuse) and to support things like rating and tagging, Otherwise, your firm’s mashups  languish in the hands of their creators, and it’s likely that people will duplicate one another’s work for lack of visibility into what’s already been done.

Platforms like Presto and IBM Mashup Center already had this capability when MP was written. The latest version of Presto is  actually more of a “widget store”, since most of the “apps” I saw demonstrated were fairly basic. However, I really like the ability of users to assemble their “apps” onto a custom dashboard (in JackBe parlance a -groan- “mashboard”). The lines between collaboration sites like Sharepoint, decidicated portal products, and mashups are clearly blurring.

Apple has made  the  ”App Store” a popular meme, and at first I thought this was just smart re-branding by JackBe to pick it up. But after discussing some of my enterprise’s requirements with the JackBe team, I realized that a lot of my concerns about “empowering end users” were finally being addressed.

Here’s the big problem…
 In my day job, I work in a highly regulated industry (finance). I like the notion that we can use mashups to allow end-users to create their own solutions. But what happens when a user takes 2 or 3 seemingly innocuous bits of information and combines them into something that requires greater security than the constituent parts? If you’d like a public example of this issue, have a look at pleaserobme.com. The site (now retired) took public twitter messages (like “I’m having coffee at Starbucks”) and combined it with public profile information to determine when a person was far away from their house. Innocent pieces of public information combined to achieve scary results.

What happens when your end-users create similarly radical applications and publish them? Do you need a special team tomonitor the app store every second of the day to look out for these problems? JackBe solved this problem by introducing workflow into the Publication process. Something I did not consider when I first discussed the idea, but which I now consider a necessity. As Apple has shown us (for better or worse) a formal approval process is the key to ensuring the quality and integrity of what’s in the Store. Now, your enterprise can allow its users to create solutions but you also have a control mechanism in place to make sure that appropriate security, audits, and other controls are in place before they are released to a wide audience.

Now that I’ve spent some more time thinking about the App Store, I have a few other requirements that I think will be important for an enterprise implementation:

• Let me skin it
  An enterprise will naturally want to make its app store conform to its corporate style/branding
• Track Application Usage
  Move beyond simple rating functionality to actually track and meter which apps are getting the most usage internally. This might complement some way to compensate people who have created popular mashups
• Meter API usage
  A popular mashup might over-tax the resources of an underlying API (especially if it was never designed to serve a large audience) so provide things like an API key, or the ability to limit # of calls, etc. Many public API providers (eg Google) already require you to sign up for a key; the app store should allow this type of management
• Surface errors in a meaningful way
  Suppose a mashup uses 3 different systems under the covers, and a user only has access rights to 2 of them. A simple failure message isn’t going to help them out. They need to understand how to contact the administrators of that 3rd system and request appropriate access. At a minimum, apps in the store need to clearly document the APIs used, but the store should also provide hooks for better error reporting

Some of these features (like Usage Tracking) can actually be mashed-in manually via your own custom APIs, but I’d like to see them natively supported.

JackBe deserves  congratulations on their latest release and forward thinking. Their App Store is a welcome addition, and I can’t wait to see how it evolves over future versions.

Alcatel-Lucent Acquires Leading Web 2.0 API Repository ProgrammableWeb
“Alcatel-Lucent today announced that it has acquired ProgrammableWeb, the technology industry’s universal source for Web APIs (application programming interfaces) used by application developers to build web, mobile, and other connected applications that serve consumers and the workplace.”

I know John Musser, founder of ProgrammableWeb.com as a result of our mutual interest in mashups, our joint membership in the New York CTO Club, and from having written/collaborated on a few articles (also here and here) for PW back when my book was released. He’s a great guy who has done a lot for this new paradigm. I personally have used PW’s API and News RSS feeds to provide content for this site from its inception. John is apparently staying onboard to “continue to oversee the repository’s operation”; I hope is able to keep the site independent and objective with its new corporate oversight and structure.

So, it’s great to see some money being made in the mashup space, but I have to admit my first reaction  was, “Lucent?!?!”. Let’s face it, it’s not like they’ve even established a toe-hold in the mashup space when you consider what major players like IBM, Microsoft, Google, and Oracle have done (and in some cases, un-done). Why would Lucent suddenly enter the space in what seems like such an unconventional manner: Buying a mashup directory instead of new tools or services?

The press release gives us a window into their thinking:
“If you look at any organization that launches an API, you quickly realize that the one thing the most successful APIs have in common is a vibrant developer ecosystem,” said Laura Merling, vice president of Alcatel-Lucent’s global developer strategy. “Our goal is to protect the uniqueness and independence of ProgrammableWeb as an API repository and developer resource, while adding beneficial technologies and service provider relationships to the mix for everyone’s benefit.”

It seems that Lucent also was attempting to build a PW competitor of sorts with it’s Open API Service. Acquiring PW and its resources is a great way for them to build our their API repository by leveraging the work already done by John and his team.

Thinking about this deal, I can’t help but recall what Yahoo! looked like in the mid 90′s.
Back then, Yahoo was a simpler place, dedicated mostly to web-search against an index that was almost entirely hand-assembled. If any of us had the chance to acquire Yahoo! back then at a reasonable price (I have no idea what Lucent paid for PW, btw) wouldn’t we have jumped at the chance?

Fast-forward to 2010, and PW today is to mashups and APIs what Yahoo was 15 years ago to search. Lucent is clearly betting that API directories will experience some similar level of growth, and in this acquistion they saw a key opportunity for  getting in on the ground floor.

In the Search arena, we eventually saw many of the dominant players ousted and new giants emerge. Will we see the same in the mashup directory space? ProgrammableWeb only has about 2000 APIs in its directory. And like Yahoo!’s, it is a directory that is largely manually assembled. It’s logical to assume someone will eventually figure out how to automatically assemble similar content (perhaps using mashups!)

Will Lucent be able to keep ProgrammableWeb from suffering a decline like Yahoo’s? If the answer is “Yes”, PW could become the next Google when it comes to APIs and mashups.