Mashups and "The Future of Work" in Enterprise 2.0

[As a preface to this blog, I think I should take a moment and introduce myself. I am JackBe’s CEO and co-founder. Until today, I have been leaving the blogging to some of JackBe's better known (and more loquacious) team-members. However, as Enterprise Mashups continue to garner more and more attention, I've come to the conclusion that the global Enterprise Mashup conversation might benefit a bit from my perspective on occasion.]

---

Harvard professor Andrew McAfee, originator of the term 'Enterprise 2.0', has introduced another wonderful set of ideas in his latest blog entitled The Great Decoupling. Andrew’s blog is a discussion about MIT’s Tom Malone’s book The Future of Work, which deals with information flows and decision rights and how these are impacted in enterprise by technology.

McAfee mentions that (and Malone’s book details) that information can now more freely move about in a company due to the ease of communication and cost-effective nature and availability of broadband internet access and processing power. He then goes on to explain the phenomenon of “lateralization” replacing “centralization” when analyzing information exchanges and uses drawings (like the ones pictured here) to explain the differences.

McAfee makes the point that:

“Malone’s theory, however, goes much farther than just outlining how information flows change. It also predicts how decision right allocations will change as a result. His thesis is a simple and powerful one: decision rights will also become more lateralized as information costs plummet, leading to greater power and autonomy at lower levels within a hierarchy -- in short, greater decentralization.“

Why is this at all interesting to me (and you), you ask? Well, all of this seems to certainly be relevant to the nature and definition of mashups. After all, a mashup is the result of taking disparate and highly available pieces of information and “mashing” them together to create a new piece of information. In essence Malone seems to be describing, among other things, the reason why mashups have arisen and the importance that mashups have in today’s IT environment.

However, McAfee’s knowledge about enterprises and how they work lead him to disagree with the practical nature of some of Malone’s ideas. McAfee makes it a point to highlight how new rules about distribution and access to information as well as the possibility to interact with it will need to be put in place in order for these ideas to be implemented in enterprise.

“Most of what I’ve seen recently strongly indicates that the sudden near-disappearance of information costs is bringing up a fascinating and consequential set of questions for organization designers and corporate leaders. They now have the freedom to place decision rights where they wish without being hampered by information costs. What are the long-term consequences of this great decoupling? Rather than a steady rise in decentralization, I think we’re going to see an extended period of innovation and experimentation. I think Malone might well be right that the "market share [of centralized management] is likely to decrease," but I also think there will be strong movement in the opposite direction -- toward more centralization of some decision rights—and a lot of very interesting hybrid models, some so interesting that they’ll look like science fiction.”

In essence McAfee is making the point that for enterprises, a hybrid model needs to be put in place. One in which information is available as long as proper governance, auditing and tracking can be established. Simply put, without the possibility of governance, no enterprise will formally allow nor motivate such an exchange and hence the decentralization of decision rights cannot occur.

This is very similar to the point that JackBe has been making about the need for enterprise IT infrastructure to evolve so as to be able to establish and enforce the necessary governance and create an environment of trust. JackBe's own John Crupi and Deepak Alur have gone to great lengths (like here and here) to make and illustrate the point that the difference between consumer and enterprise mashups has to do with the fact that consumers can have free access and free rights, but enterprises must have the ability to create and manage their circle of trust.

JackBe's enterprise mashup experiences in dealing with many large enterprises to deploy enterprise mashup solutions makes it clear that the hybrid model that Andrew McAfee describes is required. Furthermore, we believe that all enterprise IT stacks will need to evolve to ensure that these new capabilities can be put in place. Fortunately for us, we saw this coming and have created an Enterprise Mashup Platform that strongly focuses on governance and trust issues, and one that is complementary to existing platforms.

The future is here!

Read More...

Summary only...

Who is Person of the Year at your Company?

When it comes to software, these are interesting times for both techies and non-techies alike. Witness Time Magazine's Person of the Year for 2007: "You". This is a savvy reference to users' interaction with "the new Web" or "Web 2.0", with...

"...community and collaboration on a scale never seen before. It's about the cosmic compendium of knowledge Wikipedia and the million-channel people's network YouTube and the online metropolis MySpace. It's about the many wresting power from the few and helping one another for nothing and how that will not only change the world, but also change the way the world changes.

The tool that makes this possible is the World Wide Web. Not the Web that Tim Berners-Lee hacked together (15 years ago, according to Wikipedia) as a way for scientists to share research. It's not even the overhyped dotcom Web of the late 1990s. The new Web is a very different thing. It's a tool for bringing together the small contributions of millions of people and making them matter. Silicon Valley consultants call it Web 2.0, as if it were a new version of some old software. But it's really a revolution."

Wikipedia, YouTube, MySpace. Exciting stuff to be sure. Not to mention Flickr, Google Maps, Twitter, Pandora, Last.FM, digg, del.icio.us and the multitudes of other Web 2.0 sites out there. Hard to argue with the idea that these sites are changing the way we interact with technology and the resulting benefits. But one important aspect of this "revolution" that the Time feature fails to point out is that this transformation is currently restricted almost entirely to the consumer space. The benefits of this "world-changing" experience largely disappear as these same users enter their corporate workplace each day and use their business applications.

In the workplace, instead of sharing these next generation Web experiences, users typically find themselves interacting with different siloed software applications that are often poorly integrated with each other and whose UIs do not enable the sort of interactivity, configurability, and customization they desire.

In this world, it might be more accurate to say that the corporate ERP system or the ubiquitous-but-annoying Portal software is 'person' of the year! This is not to disparage the vendors of these software packages (much), but to highlight the fact that change often comes more slowly to the corporate environment and is limited or throttled by these tools.

By now you know well that our goal at JackBe is to bring the benefits of Web 2.0 to the Enterprise and make "You" (The User) the person of the year inside the workplace. Our approach to bringing the benefits of Web 2.0 to the Enterprise is to create the premier Enterprise Mashup Platform (which we call Presto).

At JackBe we believe that Mashups are user-driven, user-focused and ad-hoc in nature. But as we've discussed in the recent past, what differentiates our approach to Mashups from what you'll encounter in the consumer space is an approach that embraces (yet does not displace) existing Enterprise infrastructure and middleware. And as heterogeneous, disparate data sources are the norm, enterprise mashups must meet the need of bringing these hetergenous sources together elegnatly. Finally, I can attest personally that any good Enterprise Mashup Platform must also be built to deploy securely (with the proper governance and access control policies) and safely (with capabilities for high-availability and real-time monitoring).

Remember, we're no longer not talking eye-candy technology to connect restaurant listings with Google maps. We're building solutions to critical, often sensitive, business needs. Serious features for security and safety are unsexy-but-vital capabilities you've got to have in your Enterprise Mashup platform.

If you are a Enterprise Architect in a Fortune 2000 company, these are capabilities to live by. I'll be discussing topics like enterprise mashup security and reliability in great detail in my next few posts. And that's the kind of stuff that would make YOU into Person of the Year in your company.

Read More...

Summary only...

Implementing SOA without Enterprise Mashups? You might as well kiss your job goodbye.

Ok, ok, its an overstatement. But the ROI of SOA is difficult, at best, to define and measure. Have you noticed that the press and blogosphere is filled with SOA implementers/analysts discussing the ROI of SOA and the idea that stand-alone SOA efforts are DOA? For a small snapshot of this teacup tempest, look no further than the recent commentary from SOA expert David Linthicum, the Nucleus Report on SOA ROI, and the subsequent commentary from ZDNet's Joe McKendrick and IT advisors Neil Macehiter and Neil Ward-Dutton.

While these experts differ on issues like the importance of SOA ROI, how to calculate SOA ROI (if at all), and why we don't have more/better of it, they all seem to agree on one thing: 'Enterprise-wide support for SOA hinges on the ability to demonstrate value to the business at large — more growth, revenue opportunities, and all that good stuff.' (Joe's words, not mine.) And that's where your job is at stake. Or, at least, the long-term support of your SOA efforts.

Let's face it, SOA is plumbing. Nice, shiny, efficient plumbing to be sure, but still plumbing. And your average business dude/dudette (think sales manager, marketing director, finance officer, or customer support rep) could care less about it. In fact, if they think about it all, they probably just hope it stays right where it is: out of sight and running quietly. These same business folk probably appreciate the marble floors, wood-paneled doors, and brass fixtures that surround this plumbing much more. In other words, they like that bit of 'stuff' that actually frames the plumbing and brings it to life.

SOAs need to change this inward-focused quality. To paraphrase Macehiter/Ward-Dutton in their recent note, 'More big vs small thinking: SOA vs BPM', IT must focus on where the real business value of SOA lies. That means it needs help. Macehiter/Ward-Dutton point out that BPM can help distill some SOA value up to the business level. And as one of the early implementers of Enterprise Ajax, JackBe knows from extensive first-hand experience that Ajax makes a great service consumer.

To this collection of SOA-complimenting tools I'd add the enterprise mashup. JackBe has found in its enterprise mashup implementations that they can actually drag the SOA out of the proverbial IT basement and onto the end-user's desks. It's not only highly visible, but it's user-driven, giving IT a way fulfill the promise of SOA and enhance that elusive SOA ROI.

As a practical guy I like definitive examples. Luckily, we've already seen a number of very real synergies from the mashup/SOA combination. Just a few of them include:

• Mashups can help create normalized 'virtual' services from sources that haven't been 'SOAed' yet. It's no secret that SOA efforts can take years. Until the formal SOA magic has been applied, a quick, standardized service can help users get started earlier than otherwise.
• Mashups let users 'right-size' the granularity of services. Now IT doesn't have to guess/study/analyze whether a service offers data that is 'too specific', 'too general', 'too dated', or 'too cold'.
• Mashups let users share their resulting services, making them a part of the service-generating network. Now IT doesn't have to do it alone.
• Mashups let end-users visualize the SOA in graphs, charts, tables, maps, etc. Instead of hoping the aging corporate portal has a place/way to get services visualized in the way(s) the users want , users can each do it themselves to meet their own ever-changing needs.
• Mashups let users join in data from outside the enterprise. Today's SOA efforts are largely inwardly-focused. But users often want to include external data in their work. Mashups don't care and good mashup software makes the actual location of a data service irrelevant.

SOA is still relatively new. Enterprise Mashups are, urguably, even newer. So you are likely just getting your Enterprise Mashup mojo going. But if SOA is on your enterprise to-do list, make sure you get Enterprise Mashups on that plan as well. It may not cost you your job, but it could move your SOA from 'questionable' to 'successful'.

---

Parting Comment 1: Kudos to Geek and Poke for distilling this talk of SOA ROI down to a single cartoon.

Parting Comment 2: Coincidentally, JackBe's blog has talked in the recent past about the cost-of-ownership for enterprise mashups. We didn't do a survey or try to define formulas. But our multi-part blog on 'Enterprise Mashups and Total Cost of Ownership' (here's part 1 and part 2) is a good look at some of the business and IT impacts involved in enterprise mashups. (That's a biased opinion, I admit.)

Read More...

Summary only...

Optimal Architectures for Consumer and Enterprise Mashups

It’s so predictable. Whenever there’s a hugely popular technology concept, everyone jumps on the bandwagon and ends up confusing the industry. This year’s winner is “Mashups”. Popularized by Google Maps, it’s now all the rage. Even the Wall Street Journal has covered the topic. Unfortunately, most of the mashup talk seems focused on homogeneous data sources that are easily connected to each other. In short, nothing at all like real-world enterprise architectures. As JackBe's own VP of Engineering, Deepak Alur, put it in Mashing the Enterprise Service Cloud, 'once you step inside an enterprise, things can be a lot different for mashups'. He couldn't be more right.

Deepak worked through 2 issues that differentiate enterprise and non-enterprise (or 'consumer') mashups: the disparate nature of enterprise services and the common enterprise requirement for governance. And others have added to this discussion, like SOA-expert David Linthicum, with a useful walkthrough of security strategies for mashups in the enterprise. All of these things must be functionality supported in any mashup software that claims to be 'enterprise-grade'. It feels like we're finally getting a good set of 'founding principles' for mashups in the enterprise. And to this list I'd like to propose another principle: the proper architecture for an enterprise mashup.

Let's start with a common mashup: 2 data sources joined and subsequently visualized in a map widget. Popular map widgets, such as Google Maps and Yahoo Maps, are self-contained and embeddable Ajax components that can display any address, business, point of interest or driving directions. But say you want your sales prospect’s office locations (stored in a Salesforce.com database) displayed on a Google Map. To complicate matters, you also want to retrieve your current customer’s office locations (stored in an internally-managed Siebel database) to show them along side your prospects color coded by industry. You (or more accurately, a developer) must write a significant amount of Javascript code to retrieve the prospects and display on the map. In this particular example all this “mashing” happens in the browser as show below.

Mashing in the browser works well when information can be retrieved and directly display on the map. However, things get tougher when we need to “integrate” data from multiple sources before we display on a map because the more integration we have to do in the browser, the more customized code we need to write. That means that you not only have to write Javascript code to get the data, but now you have to write code to analyze, integrate and finally place the data on the map. In essence you’ve turned the browser into a mini-integration engine. This is not necessarily a great idea for a wide variety of reasons, particularly the processing typically required to perform such integration tasks. There a solution to this problem though; it’s called Enterprise Mashups, and it lives in the server, not the browser.

Enterprise mashups integrate or “mash” mostly on the server, where the real processing power typically resides. Let me illustrate this by expanding on the prior example. Suppose we want to take all our customers (in Siebel) and our prospects (in Salesforce) and detect which ones are competitors with the help of Hoover’s web services. We could do just what we did in the consumer example plus write more code to get a list of competitors from Hoovers for each prospect and customer. In this example, there’s large amounts of data traveling to the browser plus the data integration is supposedly happening in the browser as well. This is a very tall order for a tool that was originally intended to view static HTML. The efficient solution to this need is to “mashup” the data in the server as shown below. This is the core of Enterprise Mashups; they do all the integration work in the server where the processing power is.

Are server-driven mashups required for the enterprise? No. I expect some trivial mashing could be successfully completed in a browser-driven architecture. But even the simple example above becomes almost impossible to achieve once you've factored in the security and reliability requirements common to an enterprise. Or allow for more complex data needs like a filter-intersect-join mashup with 10,000 data elements from half-a-dozen separate data sources.

The road to successful enterprise mashup solutions is similar to most enterprise software. A proper, enterprise-capable architecture is a must.

Read More...

Summary only...