Making Dashboards an 'Everyday Thing'

I think 'Dash' is the operative part of the word 'Dashboard'. Dashboards are intended to give business leaders a quick way to assemble a dashboard for them to better manage and understand their business. But there's a catch: often the data needed to create a USEFUL dashboard is spread out in different places. And we all know that IT is often too overburdened to spend time to create customized, unique dashboards datasets for different business users.

Consider this post by Michael Vizard at ITBusinessEdge titled 'Executive Dashboards as a Service'. He defines the opportunity, the problem, and the solution in one succinct paragraph:

"In an ideal world, every business executive would have his or her own executive dashboard to craft custom reports using files regardless of the application in which they were created. The problem with that vision is that the typical IT department doesn’t have time to develop a custom executive dashboard for every user."

And this is precisely the reason why we created Mashboard, a new part of Presto 3.0 that allows you to quickly build dynamic dashboards by connecting different visual Apps together to create unique workspace dashboards. Yes, I said 'dashboard', 'dynamic', and 'you' in the same sentence. I promise I am not just leading you on.

Of course you can do this user-created-dashboard stuff only if you've conquered the oh-my-goodness-I've-got-data-everywhere problem first. So Mashboard is the front-end of of our App- and mashup-making Enterprise Mashup platform, which takes care of all that. So the dashboard lifecycle is simple: 1. make all kinds of data sources 'mashable' - spreadsheets, databases, web services, news feeds, etc.; 2. combine the mashables into enterprise mashups (created visually using Presto Wires mashup-maker); 3. make the mashup into a sharable, use-it-anywhere App (using Presto App Maker); 4. get busy with Mashboard.

Mashboard also has some special sauce of its own. Yes, it lets you do the dashboard basics: take your Apps and lay them out in a dashboard form (we call them 'workspaces'). Better still, Mashboard lets you connect Apps with each other to make them interactive. Mashboard also lets your share and re-use workspaces from other users.

You don't have to spend gazillion dollars and years of integration work to get all this. The emphasis is on an ease-of-use that an 'end user' would appreciate. And, of course, IT will like this because all this is done under their auspicious enterprise IT architecture and all guidelines, with their rules for security and governance enforced by Presto.

In my [humble but admittedly slightly-biased] opinion, we should have made dashboards into an 'everyday thing' a long time ago.

Read More...

Summary only...

Does Your SOA Need an Enterprise App Store?

I just came across a great question that Peter Schoff recently asked on the eBizQ forums: 'How Would You Describe SOA in One Sentence?'. In response, fellow eBizQ pundit Joe McKendrick tweeted out "App Store for Enterprise" and then followed up those 25 characters with an interesting blog post, 'SOA in One Concise Sentence'. (Take a minute to give it a read, I'll wait right here for you.)

How neat! But I am sure that for a topic as large as SOA, and considering how passionate many people are about SOA (both lovers and haters), Joe's comment is sure to cause some concern. In fact, as you can see from the blog above, you'll notice some people already disagree with Joe. A comment by Peter Kretzman in the forum counters with this:

"SOA is nowhere close to an 'app store for the enterprise.' It's plumbing, not faucets. There is no 'app store for the enterprise' per se: that's a holy grail that's been sought for decades now. SOA is a mindset, a way of creating bunches of loosely coupled individual programmatic services that can be combined into applications. The notion of 'app store' implies that an SOA service is standalone (it's not, for the most part), or that users can mix and match and update them on their own (they might to some small degree, but most applications will still require planning, architecting, design, build, test, and deployment.)"

I am not going to argue with Peter here. However, I would like to try to explain what's happening in practice and why Joe's tweet makes sense, at least from one perspective.

Let's start with Peter's last statement: "Most applications will still require planning, architecting, design, build, test, and deployment." True. However, you don't always have the luxury of weeks or months anymore. Business often needs answers in hours and days. Apps are a perfect solution for releasing bite-sized features that work cohesively to provide a small set of integrated experience for the user. And Enterprise Apps bring the consumerization of this Apps phenomenon by combining the conciseness, portability and agility of Apps and enterprise mashups, and yet still leveraging the systemic qualities (security, scalability, etc.) of the existing enterprise architecture that has been set in place due to all the hard IT work (SOA or not) over the years.

So without getting philosophical about SOA, if one were to get more pragmatic, we really should consider ways we can meet user requirements by providing Apps in the enterprise. If there was a way to make existing data sources within the enterprise easily mashable, and yet not break any SOA or enterprise architecture rules in place, then that takes us one step closer to bringing the data to the users who need it when they need it. And once they are mashable, it becomes easy to 'mix-and-match' (as Peter puts it), without spending tons of time and effort on the planning, architecture, design, test and deployment.

As an enterprise software architect myself, I think this new approach is not disrupting to any underlying architecture, SOA or otherwise, but merely building on top and complementing it to make things happen quicker for business. And if you agree such mix-and-match is possible, it is natural to say you can put an App 'face' on it. The result is an Enterprise App Store full of Enterprise Apps.

So, while people may agree or disagree about "App Store for Enterprise" being SOA, there is one thing that is beyond a doubt in my mind: Enterprise Apps and the Enterprise App Store can bring SOA to the users. The Enterprise App Store provides a great solution to leverage all the IT infrastructure built in the name of SOA and finally make it useful to the business, bridging the last mile if you will. Holy grail sought after for decades it may be, but it is all here right now.

Read More...

Summary only...

Using Enterprise Mashups to Save Billions

I just came across a post from Joe McKendrick on ZDNet Blogs that caught my eye - Study: Increase data usability, save billions. Here's an excerpt:

"Researchers say data usability can be improved by focusing on the following factors:

• Intelligence of data “can be improved through the accuracy of the prediction, trends analysis, recommendations and profile matching/associations made by the associated applications. For example, what percentage of recommendations made by a business intelligence application results in cross-selling?”
• Remote access to data and applications is essential in an increasingly mobile workforce.
• Sales mobility “involves the ability of salespersons to use portable devices and applications to exchange information related to all aspects of a deal or transaction with a customer.”
• Improvements in data quality will result in improvements that “may come through better and timely decisions (which may increase customer satisfaction, loyalty and hence revenues), as well as fewer errors and rework, lower working capital requirements, faster receivables, etc. (which will lower costs).”

A 10 percent improvement can add up to big dollars. Researchers determined that if a median Fortune 1000 business (36,000 employees and $388,000 in sales per employee) increased the usability of its data by just 10 percent, it would translate to an increase in $2.01 billion in total revenue every year, or $55,900 in additional sales per employee annually." – End of excerpt

I find this is very interesting. But the question is how do you go about achieving this.

1. You don’t want to be spending millions to save millions.

2. You don’t want to take years to achieve these goals.

If you can afford to do either, then I suggest, you read no further. But if you don't have millions and don't have year, I'd like to share an alternate approach.

To me, enterprise mashups have been at this for a few years. Take remote access to data and applications for instance. It is dead easy for us to create a new enterprise mashup that wraps the existing data and applications, creates a specific usable view of that data, and then expose this mashup as a Web Service (SOAP or REST), using Apps to your end users and customers. This does not take years, it can be done in hours and days today.

Consider mobility. You want to not only create a more usable view of data, but in turn ensure that this data is available for your mobile users to interact with wherever they are via any portable device. This too is fairly easy to achieve using enterprise mashups.

Basically, enterprise mashups create that agility layer in your enterprise architecture to deliver concise, specific, usable data and applications to your users, without disrupting your current enterprise architecture. This new agility layer can respond rapidly to new business needs by changing the enterprise mashups and creating new enterprise mashups when required.

Enterprise mashups don’t solve the traditional problem of data cleansing in the traditional way…Extract/Transform/Load (ETL). That’s the whole point. Most customers can’t afford (time or resources) to cleanse data that way. I think that enterprise mashups thrive when conventional solutions become expensive and time consuming.

Read More...

Summary only...