Posts Tagged ‘jackbe presto appstore’
…and is it ready for you?
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.