It Pays To Be Virtuous
We write about enterprise mashups on a fairly regular basis. But we'll be the first to admit that we're not the only ones spending our nights and weekends noodling enterprise mashups. The Mashup Tribe is a very big and VERY busy group!
Today we're very proud to have one of the Tribe as a guest blogger. Mike Ogrinz is an enterprise architect at one of the largest banks in the world and, more important to our purposes, author of the upcoming book Mashup Patterns.
In the process of writing his book Mike has spent a lot of time considering enterprise mashup implementations, best practices, and theory. In this post Mike takes a look at the 'virtuous' nature of mashups...
I’d like to start this post by thanking the staff at JackBe for their support and encouragement while I worked on my book, Mashup Patterns (which will be available in March of this year). John Crupi, JackBe’s CTO and co-author of Core J2EE Patterns, had both the forethought to register MashupPatterns.com and the generosity to transfer it to me for my book’s companion site. I’m appreciative for the loan of this space to talk with you about what I think are some of the exciting aspects of mashups.
One interesting topic I explore in my book is something I like to call “The Virtuous Circle of Mashups”. It describes the process whereby mashups can be perpetually recycled and enhanced to build even more useful solutions:
Experienced software developers will look at this picture and think, “That’s almost the same basic cycle that we’ve been following since the idea of reusable code was invented. How is this different than re-using objects, component libraries, or third-party widgets?”
Under traditional reuse practices, there is no requirement that the consumers of reusable code are themselves reusable. So reuse is actually sort of a dead-end for the broader community. In my “day job” as an architect at a major financial services firm, I constantly come across commercial and open-source packages that liberally poach from the FOSS (Free and Open Source) world without giving anything back. This is where mashups break the mold. Mashups themselves are inherently reusable as the basis of new creations.
How many times have you used an application and thought, “It would be a great product if it only did this one other thing…”? Now imagine if you were empowered to make that enhancement yourself. And further, imagine when someone looks at your solution and can make the changes that make the solution perfect for them. This is a level of reuse and customization that is unheralded in the world of solutions delivery. Sure; I suppose you could make the claim that theoretically Open Source aims for the same goal. But did I mention that mashups also shift the focus away from IT personnel and closer towards end-users?
The rallying cry around application architecture has been “separate your business logic from your presentation logic” for a few years now. The idea was to keep the code that implemented business rules from getting mixed up with the code for creating the user interface. But the problem with this model is that both of these assets still remained locked within IT. The evolution of this idea is to give control of the business logic to the people who know it the best: business users! Mashup products like JackBe’s Presto are making this possible by enabling power-users to create their own products.
As exciting as this is, it’s only half of the solution. Empowering everyone within your firm to build their own solutions can have tremendous benefits, but also a number of dangerous consequences. I have seen end-users create Excel-powered solutions that sidestepped all of the best practices IT has painstakingly developed over the years. New versions are passed (and changed) from one user to another with little or no regression testing or auditing. Often, the same solution will be implemented many times over as coworkers re-work the same problems (unaware that a solution already exists). For mashups to succeed in the enterprise, they can’t just accelerate the mistakes of the past.
I believe that one answer to this dilemma is a centralized mashup “hub” or “repository”, where the community of builders can share, tag, and rate one another’s solutions. These “folksonomies” are a hallmark of Web 2.0 and lend themselves to brining a natural order to the decentralized development mashups enable. If traditional software reuse focused on the economies of scale, then mashups focus on the economies of collaboration. A central hub will give your enterprise mashup environment some of the advantages of Crowdsourcing, even if two employees never work on the same solution. The benefit of cooperative tagging and rating activity helps ensure that only the best (quickest, most stable, etc) solutions are remixed as the basis for new ones. You can even mix your internal components with an external repository (for example, programmableweb.com’s API-enabled mashup catalog).
Naturally, there are other critical product features and capabilities that firms will have to evaluate as they investigate this space. But in order to reap the benefits of The Virtuous Circle of Mashups, some type of community solution-sharing environment is critical.
We're flattered Mike has let us publish his thoughts. We hope and expect he'll be back in the future with more! Until then you can find more posts from Mike on mashups and mashup patterns at MashupPatterns.com.
