SmoothSpan Blog

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 Salesforce.com 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.