SmoothSpan Blog

For Executives, Entrepreneurs, and other Digerati who need to know about SaaS and Web 2.0.

SaaS, Mashups, and Web Software: The Rub is Customization

Posted by Bob Warfield on October 17, 2007

I was reminded today of the customization conundrum as I read Dion Hinchcliff’s post on the 10 Top Challenges Facing Enterprise Mashups.  This brings me to a confession I need to make:

I’ve always been uncomfortable with mashups.

Yeah, I know, they are hot, hot, hot right now.  And you can do cool things with them.  But they are largely reductionist and not transformative.  They don’t create much new; rather they are filters on what exists.  It’s like the DJ mixing/dubbing scene:  are DJ’s really creating much new music by remixing other people’s work?  Yes, it’s fun and interesting, but it isn’t quite as satisfying as genuinely new music.

Mashups are a lot like scrapbooking.  It’s way cool to build scrapbooks, and a lot of people love it.  But the real deal is the photography.  That’s creating content and not just framing it.  Even Photoshop has a much more profound effect on photography than scrapbooking because it is tranformative.  These things are missing from the mashup world so far.

Dion points to a lack of business success stories with mashups even though they’ve been around for a long time and there are tools aimed precisely at that world.  In his view business has an even greater need for customization than consumer mashups because most business problems are unique in nature.  There may not be something out there you can simply filter to get your answers.  You may have to do further processing, transformation, and creation to get a useful answer.

Interestingly (to me anyway, given my Quattro Pro background), he points to spreadsheets as tools that fit better for businesses.  Spreadsheets often serve as ad hoc mashup tools for structured data.  I’ve cut and pasted many a record from applications like and others into a spreadsheet so I could work on the data and transform it into something more useful.  For a particular kind of data, they’re extremely powerful, and they enable mere mortals to do the most amazing things.  At the same time, it’s a very manual exercise.

Dion lists 10 challenges, and a number are related to this customization issue:

1.  No common assembly model.  What’s the metaphor to be?  How do users think of assembling the data?  Are we pouring content into boxes on a web page?  Are we calculating on a grid as spreadsheets do?  Are we filtering lists like a database?  There are a lot of models out there.  Each one is different, and there has been no agreement on the One Best Assembly Model.  Doesn’t this have to be customized into the application?  Maybe there isn’t a One Best Assembly Model because the examples I’ve given are all pretty different.

2.  Widgets over API’s.  Regular users can’t handle API’s, but they can deal with Widgets.  Yet, there is no “Universal Widget API” that let’s us mix, match, and mashup Widgets at will.  This sounds like another customization angle to me.  Dion wants end user customizability with bite-sized Widgets as components so as to avoid API’s.  It’s a graphical user-friendly self-service SOA architecture.  I like it!

3.  Management, Versioning, and Security Issues.  Dion breaks these out as several of his 10, but I see them all as what I call the Business Trust Fabric.  It’s all about being able to put in place and enforce the set of policies that make up a particular organization’s Trust Fabric.  It’s why doing Web 2.0 things to the satisfaction of business is hard.  Most consumer web apps have a very minimal trust fabric that is not customizable.  Businesses are not one size fits all here.  They each have fairly unique policies that the software must implement in these areas.  Once again, it is a customization issue around whether the software can be customized to the particular flavor of Trust Fabric a business wants to implement.

4.  Accessing the Data:  A comment on the post points out a reality: 

most of the “data” in the enterprise is heterogeneous, siloed, complex, and beyond the reach of 99% of the mashup developers. 

Accessing the data is a task that we could enable the so-called mashup developers to tackle.  That’s part of what BI tools do, and some are pretty good at ad hoc queries.  What I find is that this just isn’t enough.  To borrow the old cliche, I want information not data.  Often, I find myself using a spreadsheet to transform data retrieved with BI-style tools into information.  The logic can be complex.  Anyone who has crunched numbers knows the drill.  One number is quarterly, one is monthly, you want average daily, yada, yada.  Lots of customized processing to get the data into a state where it even makes sense to mash it up.

Similar issues plague SaaS for business.  Delivering customization is hard.  If you have to roll in the traditional multi-million dollar Services engagement to get a SaaS product customized, it’s a non-starter.  Delivering self-service customization is also very hard.  Dion touches on some interesting ways to approach the customization issue for non-techies, but I don’t know that I’ve seen a SaaS solution yet that dealt with the problem.  In most cases they either prohibit customization, or allow very little (for example, you can add your own fields and make cosmetic changes, but the overall app is fixed).  This has limited SaaS to domains where minimal customization is acceptible.

SaaS and Web 2.0 software vendors that hope to satisfy business users and solve real business problems need to find a way to address the issue of self-service customization.  They need to find ways of letting these users go beyond canned apps and mashups of data to create and transform.  Mashups are a very limited type of customization.  A lot more mechanisms need to be available before we can see real progress.  I recently chatted with an entrepreneur who is working on a product related to this area, and plan to run an interview soon.

7 Responses to “SaaS, Mashups, and Web Software: The Rub is Customization”

  1. […] unknown wrote an interesting post today onHere’s a quick excerptNo common assembly model. What’s the metaphor to be? How do users think of assembling the data? Are we pouring content into boxes on a web page? Are we calculating on a grid as spreadsheets do? Are we filtering lists like a database? … […]

  2. mishon8 said

    Thanks Bob. We stuggle with this ourselves so its good to know we are not alone.

  3. […] Rants)Who Doesn’t Love Java? (You’d Be Surprised! -and- Part 2 of the Tool/Platform Rants)SaaS, Mashups, and Web Software: The Rub is CustomizationThere May Be a Bubble, But It Isn’t a Casino EconomyAboutAmazon Beefs Up EC2 With New OptionsIf You […]

  4. tps777 said

    I am curious if the data modeling capabilities (of virtualized data sources) found in some virtual directories would help solve the problems with custom coding here? I know that in other applications this has solved many issues.

    anyone have any experience or thoughts?

  5. smoothspan said

    Tps777, you’re on to something. Customizing the data model requires a couple of things. First, it has to be defined in metadata. This allows a level of indirection and management of the system that is tractable in a multitenant world. Mechanisms need to be available at a minimum to add new fields, and ideally, to add new objects.

    Second, the “language” used to access the data must be cognizant of the metadata, but hide that fact from users so they feel like they’re actually customizing their own private instance. This means various ways of modifying the SQL submitted by UI or in a customization scripting language transparently behind the scenes.

    When properly implemented, these mechanisms can be highly transparent for users, as evidenced by the Salesforce Force platform.



  6. kshaw78811 said

    Many people don’t quite get why mashups are important. After all, combining data that already exists is not really creating value right?

    Not quite. I agree that business value is somewhat lacking when mashups only aggregate data. That’s because the data aren’t actionable in the context of a business activity. Pretty pictures aren’t enough, regardless of how cool they are. We don’t understand what it means to have a killer business mashup application, so of course we don’t have killer business mashups.

    I’ve written a response to Hinchcliffe’s blog entry in my own blog, Monster Mashups. In it I address the question of why there are no kiler applications, which to my mind is the most pressing problem we have getting in the way of widespread enterprise adoption of mashup techniques.

    I hope you find it useful to read.


    Kelly A. Shaw, Ph.D.
    Serena Software

  7. smoothspan said

    Kelly, I enjoyed your article, but my takeaway from it mostly underscored my view here:

    They are largely reductionist and not transformative. They don’t create much new; rather they are filters on what exists.

    You present that essential idea slightly differently when you say:

    The data aren’t enough. The data must be actionable and solve an actual business problem.

    Making the data actionable in business requires transformation not just combination. It require business logic, and not just presentation logic. At best, enterprise mashups seem to be another path to what common BI tools do with databases. It’s useful, but solutions are much more useful. It generally takes more than a mashup or BI tool to get to a solution.



Leave a Reply

%d bloggers like this: