The 10 top challenges facing enterprise mashups

The 10 top challenges facing enterprise mashups

Summary: The promise of remixing existing online services and data into entirely new online applications in a rapid, inexpensive manner, often referred to as mashups, has captured the software industry's imagination since the release of first major example, HousingMaps.com, in early 2005. Since then, mashups have offered the potential to finally make widespread software reuse a reality, enable SOA initiatives to achieve positive ROI, and radically drive down the cost of application development while satisfying large applications backlogs that plague organizations almost everywhere.

SHARE:
TOPICS: Software, IBM
26

The promise of remixing existing online services and data into entirely new online applications in a rapid, inexpensive manner, often referred to as mashups, has captured the software industry's imagination since the release of first major example, HousingMaps.com, in early 2005. Since then, mashups have offered the potential to finally make widespread software reuse a reality, enable SOA initiatives to achieve positive ROI, and radically drive down the cost of application development while satisfying large applications backlogs that plague organizations almost everywhere.

Applying mashups in a business settings is often referred to as "enterprise mashups" and recently we've finally begun to see the tools emerging to bring real mashup capabilities to consumers, business users, and IT professionals.

However, though anecdotal evidence seem to abound -- there are a good number of stories about businesses creating isolated mashups here and there -- and mashups are again getting placed on hot tech trends lists for 2008, we're clearly still not yet seeing the flood of mashup-based apps inside of organizations despite their consistent and steadfast growth on the consumer Web.

ProgrammableWeb's mashup graphs (left of page) currently reports that over 2,400 mashup-based apps currently exist.

The public Web of course has been a global laboratory for innovation for 15 years and it's not surprising that experimentation and creativity in such a large pool of resources of people and services would generate some interesting outcomes like the several thousand mashup applications currently available. But the question has been: Where is the same result inside our organizations? Those same organizations that often desperately need software to solve a business problem for which software simply isn't available -- at least without extensive customization -- because the typical business problem's unique, situational nature. In previous posts I've discussed how spreadsheets are often the only end-user development tool available to the average person to meet this need today.

Enterprise Mashup Challenges

So what exactly is holding back enterprise mashups from becoming a more popular phenomena inside our organizations? This has been in contrast to many other aspects of Web 2.0 inside the enterprise, where openness, network effects, and radical power and simply are often driving extremely fast uptake and adoption of new apps and technologies. By many indications, mashups -- particularly in the enterprise -- have so far fallen short of their potential and the question is why?

I've discussed this with a various people in the mashup community and analyzed a number of the leading mashup platforms and have boiled the outstanding challenges down to 10 points I believe are the biggest obstacles. Some of these challenges are counterintuitive and some of them might be self-evident to those that are struggling to enable them but nevertheless are still major issues. But given that SOA, composite apps, Web services & open APIs, and widgets are all receiving significant venture capital and corporate investment in 2007 and heading into 2008, the enterprise mashup space is poised for tremendous growth by all other indications. If only we could discover and resolve with the remaining barriers for their creation and use. Here are what seem to be the biggest issues with widespread adoption of enterprise mashups:

The top 10 challenges facing enterprise mashups in late 2007

  1. No commonly accepted assembly model. The reason that spreadsheets are still so enormously successful is that they are really a highly capable functional programming environment. A spreadsheet has an easily understood visual grid model that can hold data of many different kinds that can then be processed by cell references and user written formulae turning hours of previously tedious work into automatic processes. Spreadsheets are largely intuitive, easy to learn, and used by millions of people on a daily basis. It's been so successful that some mashup tools actually use them as their preferred model, most notably the pretty interesting Instacalc and BEA's AquaLogic Data Services Platform that offer good consumer and enterprise example respectively, though there are other players as well. Spreadsheets offer a mashup fabric in a model that is already proven and generally accepted by consumers and business users virtually everywhere.But most mashup tools take a different tack and either reinvent the wheel by offering completely new and unfamiliar types of models, some simple and some quite sophisticated but virtually all of them foreign to anyone who is not a developer. And of course the issue is if mashups remain a developer only phenomenon the larger bulk of their business value will be lost. If only developers could process data with computers, we'd still be in the era where personal computers were primarily used by the few people with coding skills. Spreadsheets liberated computers to be used for number crunching by the masses and mashups have the potential to liberate the browser for software creation by the masses. The big question is who will hit upon the right model that will provide both an incredibly easy on-ramp that also supports the creation of useful business applications but one that can support sophisticated applications and be easily maintained and supported over time.Is the spreadsheet model for mashups the answer? It's too early to tell, but with IBM's QEDWiki and Serena's functional flow model in their business mashup product for end-users, we've seen compelling alternative models. So the jury is out on the best mashup model, and when that jury finally comes in -- in the form of the mashup platform that gets fast uptake -- we'll have a much better sense of which direction is best.
  2. An immature services landscape. Mashups are predicated upon the ready preexistence of ready-to-use Web services and network APIs which are ready to be used to build on top of. Though many of the leading Internet firms have extensive Web services divisions that offer much of their data and products up through feeds that can be plugged into browser-based mashups, the reality is that the rest of the Web has been somewhat slow to follow. It's just now becoming well-known that APIs can greatly reinforce the value of a Web application and allow it to be reused hundreds or thousands of times in other products, leveraging a form of Jakob's Law.But for now, even in organizations that have SOA initiatives in advanced stages, not nearly enough information and functionality is currently "Web-enabled" via feeds and services and hence can't be leveraged inside a mashup application canvas. Products such as Kapow and other Web-clipping tools have put a decent dent in this problem recently, but we have a way to go before we have enough ready Web services to feed our mashups. The good news: There are a lot of high value APIs that do exist on the open Web today and increasingly inside our organizations particularly in the form of RSS that can unleash the mountains of data and functionality lying largely fallow inside most businesses today.
  3. The splintering of widgets. One of the most exciting phenomenons on the Web today has been the advent of widgets; mobile Web parts that can be used by anyone with a cut and paste. Web widgets actually form the basis of a primitive yet highly end-user friendly mashup model and have been gaining enormous popularity as a quick look at the widget gallery on WidgetBox shows us. It's the user remixable Web at its best and widgets are distributed and used by millions of people a day.It also turns out they are the other key ingredient to mashups along with Web services/APIs but they are uniquely significant because they are entirely end-user friendly whereas most APIs require much more technical savvy to use. Consequently, widgets make a compelling and ubquitious packaging system for mashup functionality, particularly since most widgets also provide automatic API connectivity back to its originating site (for example an eBay listing widget connects back to eBay from a mashup or Web page live to pull auctions from the API.) However, the widget world is very informal and there are no official standards (yet) and widgets have been co-opted by countless companies and named badges, gadgets, modules, and other things. Some of these companies, particularly Microsoft, Google, and a few others, have been imposing their own gadget models that allow businesses to plug into their ecosystems of users but largely keep their gadgets captive.The real issue is that mashup creators need to have access to the Web's full inventory of functionality and the different widget models are fostering silos of widgets that it's not likely most mashup creators will have full access to with their tools. The solution? A simple, open standard for widgets. Are we likely to get it? Not soon unless someone with authority, in a manner similar to the way RSS 2.0 was created and spread, steps up to the plate.
  4. Management and support of end-user mashup apps. If enterprise mashups unleash hundreds of new applications inside an organization, then who will catalog them, support them, maintain them, and fix them when they break? The IT department? The business units? Using what tools? This is an objection I frequently get from enterprise IT about their fears that mashups will bring back the horrors of having unsupported Microsoft Access-based apps running loose in their organization, though much more widespread because of their collaborative, open, network-distributed nature. This is a genuine challenge and the best mashup platforms have some answers to this baked in but there is lots of room for improvement.
  5. Deep support for security and identity. The most useful enterprise mashups will have access to a user's private individual data and other corporate information protected by security and identity systems. Consumer mashups are challenged in a similar way since it's hard to provide vital function if a user isn't willing to trust a mashup with the user IDs and passwords necessary to obtain the data from the back-end services guarding the information the mashup needs to function.The common enterprise solution to this, Single Sign-On (SSO), has not made it fully to the mashup world and the problem is only exacerbated if a mashup is also meant to be used by many types of users including consumers, partners, and suppliers which will all have their own identity requirements and infrastructures. Initiatives like openid are helping but are not a complete solution. Like widget models, this too needs a leadership figure to definitely resolve for the industry or many types of useful mashups are not and will not be possible in the near future.
  6. Data quality and accuracy. This is the classic "truthiness" problem Nick Carr brought up way back when mashups first began to get attention and are still a critical issue as far as enterprise mashups are concerned. How do I know if the data displayed in a mashup is correct I'm often asked? Particularly in many types of applications, the veracity of data is paramount yet in a browser-based mashup, who is to say where the data really came from and if it's fresh. Formal IT systems have an advantage in this regard, at least for now, because they have controls to ensure they are the system of record. However, the recent advent of reputation systems and provenance indicators can help but there's lots more work to be done here so that users can be sure of what they are looking at, where the data came form, how it processed, and how recent is it?
  7. Version management. When users can tweak, recombine, share, adjust, and otherwise change a mashup on-the-fly in "edit mode", how does a business deal with issues of consistency and change management when so many more versions of applications exist than before. Fast rates of change are increasingly becoming the norm both on the Web and in our organizations and mashup platforms that don't directly have features to support and enable rapid changes in mashup applications will be bringing to their customers as many issues as they solve. IBM's QEDWiki stands out again as a model where mashups are automatically versioned, just like a wiki page, so that even the mashup can be mashed up again and its clients pinned to particular version. Several of the most recent mashup platforms are making this kind of capability a priority and by the end of 2008, mashup platforms that don't support version management robustly will likely have serious issues gaining an audience.
  8. Awareness and realization of the potential of mashups by the businesses community. One other problem, probably not helped by the term 'mashup' itself, is the general awareness of the business value of mashups and their potential to solve tough business problems by providing faster, cheaper access to the right information and IT capabilities than ever before. The fairly immature state of tooling doesn't help but a lot more has to be done to educate and bring awareness to the general business community and educating them that an important new model for software is emerging. Businesses should be aware of the potential that smart, appropriate application of mashups in many business problems can bring by unleashing productivity, increasing institutional knowledge, and creating new business opportunities and outcomes that simply weren't possible before. Prior to mashups, there was generally few ways to buy or create a custom software application in a timely, inexpensive manner.
  9. Low levels of support by major software firms. Though open source software tends to power the public Web, a large percentage of the infrastructure running businesses today, especially in medium to large organizations, are still largely based on commercial software. And commercial software vendors have been slow to provide explicit support for an enterprise mashup friendly environment. What's lacking? A number of things including support of Web-Oriented Architecture, offering application functionality in useful API forms, "widgitized" content and functionality, offering rich support for RSS feeds and notification, mashup security solutions, and other related topics. This ensures that enterprises have a lot of work to do on their own before mashups are commonplace in their organizations.The good news, Service-Oriented Architectures are growing more common that understand mashup approaches, which strong prefer standards that support easy consumption in the browser, will help but commercial software needs to be much more mashup friendly. Why are commercial software firms slow to support mashups? Part of it is the typically slow pace of commercial software development as well as a wait and see attitude by many to see how mashups impact their business models, particularly around professional services and integration.
  10. Few killer demo mashups. Because of many of the issues above, particularly around security, clearly useful business mashups can be hard to find. Where is the mashup that shows the average user an easy-to-use combined view of all of their calendars: home, business, and mobile? How about the app that allows someone to wire together data from the data warehouse, local SOA, and enterprise content management system? These are still to hard to create for the reasons in the list above and until compelling stories emerge from businesses that have reached the tipping point, enterprise mashups will, like the SOAs that power them, remain a fascinating idea for most but not a significant business motivation.

You might think I paint a bleak picture of the enterprise mashups world and nothing could be further from the truth. The last couple of years have taught us an enormous amount about what is possible and what needs to be changed. Most of these items above will likely be addressed in some form or another in the next year or two. Even solving a couple of the key issues will change the software development landscape considerably. In the meantime, I'll do my best to provide a front-row seat to the unfolding story of what appears to be the next major new software development model.

Are you building mashups or using widgets and feeds in your business? Tell your story in TalkBack below.

Topics: Software, IBM

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

26 comments
Log in or register to join the discussion
  • Awesome piece, Dion

    There is something about the disruptive nature of mashups that is unsettling, alarming. So, even if you work though many of the technical issues you've so elegantly pointed out above, you still have to triumph over an even more challenging one-- the territorial one. Collaboration on a wiki with word docs is not the same thing as mashing up live data from disparate parts of the company to achieve your personal objectives. Someone has to agree to it. So, it's back to "it's not about (just) technology" with mashups too. Even though we clearly are maturing with enterprise 2.0, the cultural issues are still the bugaboo impediment.
    Susan Scrupski | ITSinsider
    • Good point! - that issue is rooted deep in visceral self interest - NT

      NT
      raycote
  • RE: The 10 top challenges facing enterprise mashups

    You are missing the big problem: security. JavaScript is designed as a scripting language for HTML. But HTML pages are NOT secure containers for potentially untrusted applications. Any JavaScript on the page can navigate the entire page DOM and subclass any system function. In other words, every JavaScript on the page must be completely trusted. No enterprise IT professional in their right mind would allow this to happen.
    billappleton@...
  • 4 more challenges and some ideas...

    Great article about the 10 challenges! And thanks for including Serena (the company I work for) in it.

    I have a few challenges I would like to raise?

    1) [b]Lack of collaborative features[/b]. I agree with your comments about version management; you?ll be pleased to know that we have a very robust solution thanks to our 25+ year heritage in that space. However, I?ve seen very few Mashup tools that allow for multiple people to work on a Mashup. It?s almost like going back to the earlier days of Excel or Access where it was indeed a personal productivity tool rather than a collaborative one. Clearly version management is required to make that happen, but there?s a lot more?think simulation, testing, staging, etc.
    2) [b]Lack of quality directories of Mashups[/b]. It?s true that programmableweb.com is a good source of them, but it?s hard to believe that only 2,400 Mashups exist in the world. My prediction is that we?ll see many directories come (and go) in the next few years in order to satisfy the desire for ?Mashers? to publish and, very importantly, consume/re-use. Today though the lack of directories makes ?Mashing? somewhat of a re-inventing the wheel exercise. Also, I think that Mashups would be more of a hot topic in the business community (to your points 8 and 10) if they were seen as simple applications that either exist and can be re-used or be easily built, and less of a simple development tool that allow you to build from scratch. Serena will introduce a Mashup Exchange early next year that I believe will set a standard for this kind of directory. It will have a lot of ?killer? Mashups.
    3) [b]Lack of focus on Mashup deployment[/b]. We hear so much about how easy it is to build a Mashup, but what about deploying them? How does one account for the difference between development environments and deployment environments in an enterprise scenario? How can ?Mashers? be shielded from that and yet be certain that what they build will run? In other words, Mashups servers/services need to be enterprise-aware to do that. Serena Mashup Server has this capability today. And, what if ?Mashers? want to deploy with the same ease that they developed? What could be easier than deploying a Mashup to the cloud where one subscribes to a ?runtime service?? Serena will have that capability in early 2008.
    4) [b]Lack of governance[/b]. You mention data governance and I absolutely agree. But in a world of connected web-based services, there?s a high likelihood of one not being available or able to respond in a timely fashion. Does a ?Masher? need to take that into consideration and program around it? If so, one would argue that they?re now operating like professional developers? This issue is in many ways an expansion of my third point, and it calls for a robust server/services platform that takes care of issues like these without burdening the ?Masher.?

    Rene Bonvanie
    Serena Software
    rbonvani@...
  • Its all about the data!!!

    When is comes to enterprise mashups, everyone get so excited about the "online services", but forgets that most of the "data" in the enterprise is heterogeneous, siloed, complex, and beyond the reach of 99% of the mashup developers.

    How anything can be called enterprise mashup without enterprise data from SAP, data warehouses, mainframes, custom applications, and more is beyond me.

    To get this data you need data services that virtualize, abstract, and federate these disparate sources into a form that is easy for mashup developers to consume.

    If enterprises really want to benefit from mashups, then they will invest in a virtualized data layer of abstacted data services that access, combine and deliver key enterprise data. Once you have these services and layer in place, you can rapidly combine them to form an array of composite applications and mashups.

    Only then will the top 10 challenges above become relevant.

    Middleware exists today from BEA Systems and Composite Software that can provide this infrastructure in just a few weeks.

    BEA Aqualogic Data Services is great if you are already a BEA shop and you are very XQuery centric.

    Use Composite's Information Server if you want to used SQL and XQuery and if you have a lot of packaged apps such as SAP, Oracle E-Business, Siebel, etc.

    - Bob Eve
    Robert_Eve
    • You hit the nail on the head!

      Your points are right on. It is all about the data availability and how it can be combined in useful variations to support the information requirements of different audiences.

      The housing example and eBay both combine "chunks" of standard data sets into "containers" and while there are probably some challenges to present them, an Enterprise Widget example would probably have to access ERP/CRM data and report/derive results and present back simply for the user, like with a dashboard. Then all the other ten challenges come into play.
      davisblair62@...
  • RE: The 10 top challenges facing enterprise mashups

    Excellent story, Dion!

    What you and your commenters are dancing around is something I've been uncomfortable with about mashups for a long time. Fundamentally, they don't do anything but combine existing content. To really add value, the content has to be transformed to create new content.

    Yes, there are issues of accessibility and conformance to policy and security, but that all exists for BI access to the data as well, and there are mechanisms to deal with these problems available from that world.

    Yet, what's missing, save for the lowly spreadsheet, is the tool to really transform the data so it becomes information. How many of us have done that cut and paste into a spreadsheet to perform that chore? And yet, the spreadsheet isn't the final destination or assembly model either.

    These problems extend well beyond mashups and into most kinds of web software (including SaaS) when business wants to get involved. It boils down to the difficulties of creating self-service customization and SOA's.

    More on my blog:

    http://smoothspan.wordpress.com/2007/10/17/saas-mashups-and-web-software-the-rub-is-customization/
    BobWarfield
  • RE: The 10 top challenges facing enterprise mashups

    #11: The name. Don't know what it is about the word "mashup" but it makes me wince every single time I hear it.
    Ginevra
  • Thank for rewiring my brain on Web 2.0 issues! - NT

    NT
    raycote
  • RE: The 10 top challenges facing enterprise mashups

    Hi Dion, great article, and I appreciate the mention of InstaCalc :).

    Regarding your first point (common model), I think making the interface consistent with existing models is hugely important. For example, in Instacalc I support equations that look like "sales * cost", "sales * cost = " and even "= sales * cost".

    The last format, with the equals sign in the front, has been used by spreadsheet users for decades and you can't throw away or ignore those built-in habits.

    You might think this limits creativity, but constraints can actually give you a starting point which you can tweak (still retaining user's mental model) and improve over time. I think existing, successful models have something going for them so are generally a good starting point.

    Anyway, interesting article!

    -Kalid
    kalid@...
  • RE: The 10 top challenges facing enterprise mashups

    Nice article. Have you seen RSSBus (http://www.rssbus.com)? It aims to make Enterprise mashups more simple by using RSS as the base technology.
    justforkicks@...
  • RE: The 10 top challenges facing enterprise mashups

    Another problem with mashup makers (especially the enterprise kind) is that they try to be a generic environment, where users can create any type of mashup "application". The problem is that the more general a tool is, the more abstract it becomes, and the harder it is to use - and it becomes more of a development tool than a line of business tool. I think that once we start seeing mashup makers targeting specific audiences, then we'll see an uptick in their adoption.

    Jacob
    http://www.exeedtechnology.com/exeed-blog
    jacob@...
  • RE: The 10 top challenges facing enterprise mashups

    Great post.

    I think many of the challenges are either already being overcome, or they are on the roadmap to solve. See <a href="http://businessmashup.blogspot.com/2007/10/how-close-are-we-to-overcoming-10.html">my post</a> on the subject.

    I look forward to the debate.

    Kelly A. Shaw
    kshaw@...
  • RE: The 10 top challenges facing enterprise mashups

    I really like the way you are describing the problems....really wonderful work..

    I hope for converging SOA and mashup , enterprise can be try solve these challneges.

    I am having an session on upcoming SOA world conference on convergence of SOA and Mashup and what will be an ideal mashup platform for soa enabled enterprise.
    fractal78@...
  • RE: The 10 top challenges facing enterprise mashups

    Dion, have you checked out MindTouch Deki Wiki? It's an
    open souce mashup platform. http://
    wiki.opengarden.org/Deki_Wiki/Release/Hayes
    awcroft
  • RE: The 10 top challenges facing enterprise mashups

    I think we'll see more mashup capabilities finding their way into the enterprise as part of the self-service customization toolboxes of SaaS platforms as they continue to expose more power over application design and behavior to end-users. Mashup capabilities are particularly promising when woven into the fabric of platforms such as Force.com but standalone mashup platforms seem kind of oxymoronic and I think they???ll have a tough time finding a big audience.

    More here:
    http://blog.rollbase.com/2007/10/self-service-customization.html
    rollbase
  • RE: The 10 top challenges facing enterprise mashups

    We at Corent Technology are meeting all ten of those challenges. I know bold statement, but we are and we are doing it with partners as well as an Architecture first approach.

    We have just finished a week at the OpenText LivelinkUp 2007 where we announced our Enterprise Mashup products we call Agile. See http://www.agiletaxonomy.com to see what we mean.

    Our products take our Service Oriented Architecture On Demand Integration Creation and eXtension platform (ODICX)and mashup with the OpenText Livelink Enterprise ECM platform to augment and extend Livelink using our widgets that are integrated into the Livelink UI.

    Here are our answers to your ten challenges:

    1) No commonly accepted assembly model. True enough, but we believe an SOA with our Mule/ESB and integrated with our partner Elixir Technology http://www.elixirtech.com, we offer the Enterprise Service Bus and Loosely Coupled Component Services as a "commonly accepted assembly model"

    2) An immature services landscape. Also true, but we believe our SOA based on Mule/ESB makes this more mature and common and since we are not only OpSource compatible any SaaS vendor using our platform will be as well.

    3) The splintering of widgets. That's why we generate a plethora of widget and gadget output options including WebEx Connect Widgets, Google Universal Gadgets, Yahoo Widgets, Vista Widgets, OSX Widgets, Opera Widgets, and JSR-168 Portlets all centrally served and automatically updated.

    4) Management and support of end-user mashup apps. We sell our services as a service OR install our platform and we provide remote service and support. We do NOT sell widgets separately for download and installation

    5) Deep support for security and identity. As deep as you can get. The Mule/ESB offers both security and identity management and if you run on OpSource or run on our Mule/ESB in your own world we can adapt the Authorization and Authentication service to meet your needs from SSO to LDAP.

    6) Data quality and accuracy. With both the ODICX platform and our BI partner Elixir Technology, we federate all data sources to ensure both quality and accuracy, we shun data replication and to transformation on the fly.

    7) Version management. We use a metadata repository for all On Demand Applications, Widgets, Gadgets, and mashups that is managed as a WebDAV repository for ease of customization as well as version control.

    8) Awareness and realization of the potential of mashups by the businesses community. Oh yes we know, and we started with Livelink with some 300+ of the Fortune 500 as clients, and 3,500+ enterprises of all sizes worldwide this is a good start. WebEx Connect Marketplace will reach millions in early 2008 and we intend on providing our Agile Taxonomy product to mashup with all the vendors in the ECM marketplace by end of next year. That should get plenty of attention.

    9) Low levels of support by major software firms. True enough, and precisely why we won't be selling stand alone widgets or gadgets. We will use partners like OpSource to support our SaaS as well as our customers that build their own SaaS on our ODICX platform. We will then have 7x24x365 tech support, online help and flax demos, webinars and a rich well documented AJAX/JSON/REST api.

    10) Few killer demo mashups. We intend on fixing this problem...We will have a WebEx Connect Widget and Google Universal Gadget that will itself allow our customers to Create, Update and Delete their own Widgets, Gadgets and even cross deploy from one platform to another and employ their own schema, derive from legacy application schemas, virtual elixir data sources, WSDL web services, SalesForce.com Dashboards and S-Controls and JSR-168 Portlets and iFrame widgets everywhere else.

    Mike Oliver
    CTO, Corent Technology
    http://www.corenttech.com
    moliver@...
  • Mashups=Exploration, ???=Exploitation

    Comparing mashups with spreadsheets is appropriate...people tend to use spreadsheets for exploratory analysis (though my father-in-law used Lotus 1-2-3 for a complex production scheduling application in the early 80's). Mashups have the same kind of probing, exploratory flavor.

    Enterprise-strength capabilities tend to focus on reliable execution (what Tushman calls "exploitation").

    What may be needed is a means of easily transitioning some "mashup apps" (or portions thereof) from the exploratory/innovation domain into a more governable framework. Or a way of partitioning the "discovery" portion of the mashup app so that the user (decision maker) can judge the reliability of what's being seen.

    See Michael Tushman's (HBS) writing on "ambidextrous organizations" for a discussion of this dynamic at the strategic level of an organization.

    Walter R. Smith
    wrsmithzdnet
  • The difference between a hobby and a job?

    Would people like to spend time working or living? Do people enjoy their job more than their families or social life? These are the real questions that Mashups must answer first.

    Think about it this way. Tell someone they have to fit 50 hours of work in a 40 hour week. If you assume that they don't normally slack off and that they actually "do" 50 hours worth of work, where can you save 10 hours? Once you've answered that then you have a potential Mashup.

    I enjoyed reading this story; it was very interesting; however, I think the 10 items listed are peripheral to the core issue(s). If an Enterprise "sees" a dramatic productivity increase via a Mashup then they will invest accordingly. Once many Enterprises see the benefit they too will invest and so on and so on. If I could provide a Mashup that granted wishes then every Enterprise would invest in the idea.

    Some others mentioned that data is the root of Mashup adoption or exclusion. I agree, but I also think that data consolidation can have negative consequences as well...most users don't need "easy" access to an abundance of data...all they need are the results...I shouldn't need to determine ROI by analysing an abundance of data...just give me the ROI!
    THEE WOLF
  • RE: The 10 top challenges facing enterprise mashups

    It was really great write. What follows this ? what is end of the tunnel ? Is there any light ?

    I guess SOA + Mashup = Enteprise mashup ...

    Mashup need SOA's support for framework , std. driven data source , security etc.

    SOA need mashup for realizing ROI.

    SOA and Mashup's symbiotic relation will fuel the rate of adoption of mashup in enterprise.
    fractal78@...