This announcement represents an important step forward for enterprise mashups and is another proof point that the market is maturing.
It seems to me that OMA and EMML are formalising a style of mashup defined - in the words of the OMA site - as something that "combines and remixes data from databases, spreadsheets, websites, Web Services, RSS/Atom feeds, and unstructured sources to deliver actionable information for better decision-making".
This data centric "mashing" is definitely a step towards the "tantalizing possibility" you refer to of "rapid software assembly" and ?deep integration out of the silos of IT". I would add that for that to truly happen we need a broader definition of mashup, especially one that addresses user productivity needs. As a result we need mashup technology that encompasses how application screens and flows, and not just data can be combined to create new applications for users.
As the market develops we can expect these different styles to become clearer and supported by broader standards ? this is a valuable first step. The question is how we get there.
A unified mashup model can increase software quality, lower IT costs, and directly drive choice and innovation. I’ve written here over the years about software mashups; simple combinations of pieces of the Web that are rearranged into new useful forms. I’ve even called the approach a key to the future of software development. While mashups in the enterprise have been reasonably successful up until now — about a third of enterprises have them today — there have been challenges in enabling the same level of wide use and benefits that are currently evident on the open Web.
Fortunately, this may be about to change. Today marks the introduction of an effort by the new Open Mashup Alliance (OMA), a federation of interested parties in the mashup space that want to bring the benefits of standardization, consistency, interoperability, and a real marketplace to the world of enterprise mashups. The initial participants include a wide range of firms such as Adobe, CapGemini, HP, Intel, JackBe, Kapow, Programmable Web, Synteractive, and Xignite. Disclaimer: My company is also a founding member organization of the OMA. Note that anyone can become an OMA member, either as a company or a user and the principles of the organization are open and egalitarian.
Related: Joe McKendrick’s Enterprise mashup proponents start organizing.
What makes OMA especially interesting from my perspective is that it’s much more than a “high concept” strategic effort that will one day put forth specifications or technology that may or may not be useful to enterprises for creating mashups. Instead OMA sponsor JackBe, one of the world’s top enterprise mashups vendors, has generously contributed their existing and proven enterprise mashups model — known as the Enterprise Mashup Markup Language — along with a fully working reference implementation of an EMML runtime, as well as 50 working mashups.
Thus EMML exists fully today as one of the more mature enterprise mashup specifications available. It is robust, mature (it has been supporting production applications for several years), and now it is open for anyone to use via a Creative Commons license. And given JackBe’s technology roots in the Java community — their CTO is the respected John Crupi of Core J2EE patterns and Sun fame — it is free of proprietary technologies and formats. EMML also brings the leverage, speed, and power of domain-specific languages to the table as well.
The result is an open enterprise mashup specification and runtime model using familiar standards and/or community technologies such as XML, XPath, XQuery, SQL, JavaScript, and JRuby. Using the EMML reference guide, anyone can now create an EMML-compliant mashup runtime. This also means any EMML-based mashup is able to run inside any EMML-compliant runtime. The resulting mashups — because they are built with an open, interoperable specification — can now be published, shared, reused, and if applicable sold in a larger, standardized market. This creates the possibilities of a real enterprise mashup ecosystem and marketplace that wouldn’t happen of its own accord. The potential is not inconsiderable given that so far the enterprise mashups industry, lacking a consistent model (outside the browser itself, see below for further details) has been fragmented into a story of multiple competing vendors and technologies. This included IBM (Mashup Center), Serena (Mashup Composer), JackBe (Presto), and many others.
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?
