Creating a unified model for enterprise mashups

I've personally examined EMML and can attest that it's a clean powerful design that includes potent capabilities such as declarative data transformation, advanced procedural logic, parallelism, meta-data and much more. That's not to say more can't or won't be done to extend and evolve EMML but it's a credible start to create a consistent model and runtime artifacts for the design and operation of enterprise mashups across all the vendors that support it. At its core, however, EMML and its runtime is essentially an enterprise-class version of Yahoo Pipes.

While it's also true that today's announcement will certainly not hurt JackBe as the top provider of EMML tools today, I also know -- based on my conversations with them lately and over the years -- that 1) they are a startup company that is volunteering the output of their hard work and is unlikely to vault to market domination on this basis alone and 2) that they believe this effort is one of the best practical ways to help enterprise mashups gain critical mass and that 3) the benefit to them is by improving the conditions of the enterprise mashups industry as a whole. At least that's my perspective.

Ultimately, the OMA creates a standardized approach to enterprise mashups that creates an open and vibrant market for competing runtimes, mashups, and an array of important aftermarket services such as development/testing tools, management and administration appliances, governance frameworks, education, professional services, and so on. Creating an ecosystem like this is only possible when the mashup industry is focused on heading in the same general direction instead of competing over individual technologies (notably, this is one of the reasons the Web works so well).

Enough of the mashup development and runtime process is left open with EMML that there is also plenty of room for differentiation. While EMML will indeed level the playing field, vendors also have plenty of room around the edges to offer additional capabilities for EMML-based environments including visual designer tools/IDEs, modeling systems, administration consoles, portfolio management systems, and so on.

In the larger view, there has always been the tantalizing possibility for mashups to fundamentally transform the business world into an environment of rapid software assembly, viral sharing of innovative solutions, and create an ecosystem of deep integration out of the silos of IT. This can also help tap into and realize the often major investments companies have made in SOA, BPM, business intelligence, and other existing IT resources like few other approaches. With OMA we are almost certainly one step closer to realizing that vision. I am hoping that the industry will come together and drive EMML forward in the right direction to enable these opportunities.

Why not the browser as a mashup run-time?

For mashups to work, it requires that the sites and applications of the Web (or local intranet) be available in "mashable" form, that is reusable via snippets of Javascript in the browser or as services on the Web in the form of feeds and APIs. Since the about 2005, this has been increasingly common and most leading sites on the Web now offer up key functionality in these forms, making it possible for their functionality to be re-used from all over the Web in other sites and Web applications.

Browser-based mashups are now so common a technique when building a new site or application that it's hardly remarked on and we can now all build on the "shoulders of giants" often simply by browsing the Web and borrowing what we like. Sites that are a source to 3rd party mashups find it worthwhile for a variety of reasons and give active technical, business, and legal support for this approach.

Related: Running your SOA like a Web startup.

The enterprise, however, is a different subject altogether. While making a business application or software suite open in the same way is important -- we have SOA initiatives that focus on this for example -- we've never achieved 1) the same level of ready openness within organizations for the "ingredients" of enterprise mashups and 2) a consistent standard for them as a discrete software artifact.

One can argue that the browser is the best place for mashups and some might say that's all one really needs to capture the value they offer, either on the Web or in the enterprise. Certainly the rise and fall of many mashup maker apps argue for this, with Google Mashups, Microsoft Popfly, and many other tools having long since departed the consumer scene. It's often easy enough to build a mashup by copying and pasting code that it sometimes seems that tools aren't needed as much in the consumer space.

However, public sites like Yahoo! Pipes show a different possibility. By this I mean that mashups can be run elsewhere (outside the browser) with great utility, particularly on the server-side. The advantage over traditional approaches to integration is the ease and simplicity of connecting multiple data sources, often in minutes or hours instead of the traditional days and weeks for classical integration approaches. The browser is also an environment which is designed primarily for user-centric applications. Many enterprise mashups need a place to run outside of the browser where other systems will interact with them instead of people. This has ushered in a need for a simple, common way to describe and run mashups wherever they need to operate, whether that is the browser or, perhaps just as importantly, elsewhere.

This means that the browser is a necessary -- but not sufficient -- runtime environment for mashups. Other important locations that are interesting for mashups includes server-side processes, batch operations, compute clouds, mobile devices, embedded systems, and just about anywhere else a browser is not a suitable place for mashups to work. Consequently part of the power of EMML is that it ultimately decouples mashups from the browser and brings the approach to a much broader set of situations in the enterprise and beyond.

Enterprise mashups and EMML: One canvas fits all?

Once size fits all has rarely worked well in the software business and EMML is certainly no different. Some requirements may have a hard time being met in the short term including organizations that may run their businesses on non-Java architectures (the only EMML runtimes right now are Java-based) or must be able to fully utilize legacy environments for BPM and business intelligence. Of course, one way to resolve this is to join the OMA and incorporate these elements in an open and non-proprietary way or help create EMML runtimes for other technology stacks. There will undoubtedly be other shortcoming discovered over time as well but the community approach to OMA is one that has a good chance to let the right solutions emerge naturally.

It's also worth noting that EMML is not particularly enterprise specific and works just as well on the open Web. So there is also the potential that once the marketplace for EMML runtimes and apps matures (perhaps eventually into an Apple App Store-like offering) that it will also be popular in the online world, further driving the robustness and capability of the approach.

Related: Enterprise mashup market to increase 10 fold over next 5 years.

Enterprise mashups are already common in many industries (especially financial services and public sector) and hand-crafted and one-off solutions are still quite common. But as new methods of enterprise architecture spread (to adapt to higher rates of organizational change and the new operating conditions of the 21st century) the OMA identifies a path that can further decrease the level of effort required to create integrated software while reducing technology confusion/fragmentation. The unified mashup model itself will ultimately help promote interoperability and foster a true marketplace of exchange that includes software, tools, shared experience, and more solutions. Why will this matter to your business? For integrated software solutions (meaning most of them these days) this will increase software quality, reduce risk, lower costs, and directly drive choice, agility, and innovation.

Does your organization use mashups? How are you creating them today?