[Crossposted from my JackBe blog]

Today is an exciting day for us at JackBe. It is particularly exciting for our engineering team. Why? Walk down the memory lane with me for a minute…

About 3 years ago, we embarked on a mission to create a new kind of software which today we call an ‘enterprise mashup platform’. And as we started designing JackBe’s enterprise mashup platform (which we ultimately named ‘Presto‘), we knew the basic problem we needed to address was how to make data securely and easily accessible to enterprise users.

That’s not an easy problem, of course. ‘Easy’ and ’secure’ aren’t often associated with each other. And enterprises are typically heterogeneous collections of data sources, data security solutions, data destinations; web services, portals, databases, spreadsheets, and much, much more. And as we considered the many different options we had to tackle this complex problem, we always came back to one fundamental concept that has proven its worth time and again:

A language is the best tool one can have.

So began our journey towards an ‘Enterprise Mashup Markup Language’ (EMML), a language specifically designed to address the needs of creating and sharing mashups within the enterprise. In conceiving, designing and implementing the language, Raj (our chief architect) and I set out defining the key wants and desires and came up with the following criteria as a basis for EMML:

1. It should be declarative. So we made it XML-based.
2. It should leverage existing standards. So we used XPath and XQuery.
3. It should be domain specific to enterprise mashups. So we added features for user oriented activities.
4. It should be friendly to popular languages. So we allow the embed of Java, JavaScript, Ruby, and Groovy scripts.
5. It should be tooling friendly. So we made it interpretive for construction and execution on the fly. And extensible with your own meta-data.
6. It should be data neutral. So we made it work with all kinds of data from different sources.

While I will refrain from describing the complete language in this blog (instead refer you to the excellent documentation on EMML on the Open Mashup Alliance website), I would like to point out a few key features of EMML here using the following diagram:

As you can see, from each feature, and from the collection of all the features EMML offers, it a robust and powerful language for mashups. And over the last few years, EMML has become an important differentiator for Presto, our award winning Enterprise Mashup Platform. As part of Presto, since its debut, EMML has been thoroughly field-tested and proven. It is time to take EMML to the next level.So now let’s return to the present and let me tell you why it is so exciting for all of us here at JackBe.

Today we launched the Open Mashup Alliance (OMA) to promote and foster interoperability and portability through an open mashup language. As a founding member of OMA, JackBe has contributed EMML to the Alliance and, indirectly, to the entire mashup community. Joining us (see this, this and this)are other industry leaders such as Adobe, Bank of America, Capgemini, Hinchcliffe & Co., HP, Intel, Kapow Technologies, Programmable Web, Synteractive, and Xignite.

So why I am so excited about giving away our vision and our hard work? Why would we want to give away one of our crown jewels? Because…

1. It offers an opportunity for our industry to converge upon an open language that aids interoperability and portability of enterprise mashups.
2. I believe that OMA offers a huge potential in enabling enterprise mashup adoption in the enterprise by promoting standard approaches and reducing risk and cost.
3. As a practitioner, I strongly believe in open and standards based approaches for new and emerging technologies and for enterprise mashups, OMA and EMML are it.
4. By contributing EMML to OMA, we will see a lot more innovation in this space by the members of the mashup community.
5. I look forward to working with other industry leaders who want to collaborate to ensure portability and interoperability for enterprise mashups.

Why should you care? I hope many of the above reasons are also the relevant reasons for you. As a vendor or a practitioner, I hope you share the excitement and passion for openness and collaboration in any technology. Check out what several industry leaders are saying about OMA and EMML and you will get a sense of why I am so thrilled.

As the enterprise mashup market evolves further, OMA will provide a platform to bring together different efforts around enterprise mashups into a collaborative alliance. If you are a mashup developer, programmer, IT developer, IT Manager, software vendor, or someone simply interested in enterprise mashups, join the OMA Support Group, check out OMA website and download EMML reference implementation and start participating now.

This is just the start of things to come.
Mash On!

I came across this interesting post: How Mashups Could Eliminate Integration Projects by Loraine Lawson. In a related post, she refers to John Crupi’s article Enterprise Mashups Part I: Bringing SOA to the People which I would recommend to readers who want to understand JackBe’s take on defining mashups. Anyway, Loraine’s post led me to Ron Schmelzer’s ZapFlash.

Here are some excerpts of Ron’s article that caught my eye, with my take on it:

A year or two ago, assuming that a mashup was a web browser-based, static, user interface composition of web-based functionality would be a reasonable presumption. But in the enterprise context, none of those assumptions necessarily hold – we might want non-Web access to mashed applications, we might want to change them regularly, and we might want to mash up information that exists below the user interface abstraction. For sure, Web mashups might embody the ideals of the original mashup concept, but we now have the desire to mash up a wide variety of IT resources from application to infrastructure to data that might be exposed with a wide range of interfaces – or without. And, it’s the desire to mash up information freed from the application that diversifies the mashup term to include the concept of the data mashup.

Introducing the Mashup Tier

My take: This hits the point right on what we at JackBe have been saying all along about mashups. While some mashups are done purely in the UI/Browser, in the enterprise, such mashups need to be supported by a new tier, the mashup tier, which sits between the presentation and business tier. So enterprise mashups will have some mashing done in the client, but most of the mashing happens in server side where security, governance, policies can be applied before any mashing can happen in the client.

Another excerpt:

There are many scenarios for composing data, but some are better suited for static, tightly-coupled, IT-driven, non-Service Oriented form. In fact, 80% of the value that businesses derive from data come from the 20% of fixed, highly optimized data integration approaches implemented over decades. In this realm, traditional data integration approaches retain high value. However, it’s the other 80% of data integration requirements, most of which come from the need to meet short-term, often ad hoc, integration requests that cause 80% of the problems. Anyone who has lived long enough in the enterprise IT space knows that business-driven requests for reporting, forecasting, analysis, or other interpretations of data can present significant complications and cost to the IT organization. The reason for this is that the IT organization is set up to meet the recurring needs of the business and not “situational” needs for information.

Long Tail of Enterprise Software Demand

My take: This highlights another issue which we have been talking about at JackBe about the long tail & enterprise applications need which was so nicely discussed here by Dion Hinchcliffe.

Bottom line: Something new and interesting is happening in the enterprise architecture space. A new flexible and agile tier is being introduced in the architecture to meet the increasing demand on IT and  add value to existing architecture, applications, services and data. Question is, are you embracing this inevitable change? If not, it’s still not too late.

Session: Enterprise Mashups / Presenter: Kishore Subramanian, JackBe

[ Disclaimer: I work for JackBe ] There are about 30 attendees. Kishore is going over the concepts behind our mashup approach like mashables, mashups, and shareables.

Kishore demonstrating SalesForce mashups and walking through the internals including EMML code. Talking about how you can merge data from SalesForce with data from internal proprietary data source and merge/combine to produce a mashup (virtual) service. Showing how to invoke it as a REST interface, which makes it easier to use a complex/mashup service. Now showing how to make a Mashlet using MashletMaker and sharing the mashlet. Now he is demo’ing Wires to show how to visually mashup by drag, drop and connect.

Got some interesting questions. Here are a few:

• Question: Is it Free?
  Answer: Yes, it is for developers. Get it here.
• Question: Is it Open Source?
  Answer: No. Did I mention it is free? JackBe is partnering with enterprise software vendors and developers to open up the EMML language. Please contact me (deepak dot alur at jackbe dot com) to get involved, support EMML or for more information.
• Question: We got a great question from a guy from the Yahoo Pipes team (I think I heard it this way) -
  Do you guys have the same problem as we do in that you need a programming language underneath?
  Answer: Yes, absolutely. We solve it by providing our Enterprise Mashup Markup Language (EMML) which has integration with different languages allowing you to plug in your program in Java, JavaScript, Ruby, Groovy. EMML and such integrated script will run on the server side dynamically.
• Question: Can you offer a hosted version for developers to use? I am not going to download this. Would like to play before I download.
  Answer: Thanks for the feedback. We are looking into it.
• Question: I am a developer. Can I run and host Presto for personal use ? What about if I am a non-profit?
  Answer: Contact me at deepak dot alur at jackbe dot com.

Get the Free Developer Edition of Presto here.

[Cross-posted from http://blogs.jackbe.com]

In my last blog entry, I defined what I mean by a mashup. In this entry, I want to expand upon how I think mashups differ in the enterprise compared to some of the consumer mashups out there.

I mentioned in my earlier post that mashups based on maps are ubiquitous and something that the users can immediately grasp. But, once you step inside an enterprise, things can be a lot different for mashups. Enterprises are not greatly interested in map-based mashups, neither are they interested in RSS or ATOM services which I think are still not fully leveraged inside an enterprise. Over the past few years, enterprises have invested heavily in SOA and because of that, they are just about getting done with service orienting their enterprise with Web Services (primarily using WSDL). And there are many applications in the enterprise that are still very database oriented. It has become relatively easy for an IT developer to expose services as WSDL based web service. And almost every middleware product out there in the enterprise is capable of exposing services via WSDL or makes it really easy to do so. Hence if you start looking around in an enterprise, what you will find is what I call the Service Cloud.

So what you have in an enterprise is a cloud of services where some are WSDL based, some are REST based, some or XML/HTTP, some are database objects, and so forth. Now, the real challenge is how to mashup these disparate kinds of services, with different service contracts and data formats. Any respectable enterprise platform that offers to mashup services in the enterprise must negotiate these disparate contracts these services expose (e.g. while a WSDL based web service defines a service contract in a WSDL document, a REST based web service has no such contact definition). And not only that, it must be done so that that we can make it easy to access for developers and users alike, and to be able to do that securely and with high-performance and scalability. Some enterprises might regulate the service consumption of even public web services that most of us can freely access on the net (think of the ubiquitous RSS feeds for example). Enterprises might allow consumption of these services, but would like to do so with governance underneath to manage, monitor and secure such activity within the enterprise. This is why we built our enterprise mashup platform at JackBe from the ground up, to address the unique challenges of mashing in the enterprise so that we allow our users to do the following:

• Create and customize mashups that consume all kinds of services: RSS, ATOM, WSDL, REST, DB, SDO, Java Objects, etc.
• Securely govern the mashups: policies for who can mashup, what can they mashup
• Share the mashups to collaborate in the enterprise

My colleague John Crupi wrote about enterprise mashups becoming the new front-tier in the enterprise. I would like comment a bit on what he said in his post. While SOA efforts have been IT driven and IT oriented, even with involvement by the business units, the outcome has been primarily IT and developer focussed. It has neglected an important stakeholder in the enterprise, and that is the User. Therefore, I view the new enterprise mashup layer as a new service layer in the enterprise application architecture that finally begins to leverage SOA from the end user perspective and to make the services layer more user-friendly (and developer-friendly) to build, deploy, share the next-generation enterprise web 2.0 mashup applications.

What do you think?

[Cross-posted from http://blogs.jackbe.com]

Over the last year, the term mashup has become extremely popular not only in the consumer software space, but also in enterprise software. It has been a little more than a year since I joined JackBe as VP of Engineering responsible for executing our vision. Over this time, I and our team at JackBe has been busy creating our enterprise mashup platform, which is a unique innovative offering in enterprise software today, by combining the benefits of RIA technologies such as Ajax/RIA, Web Services, Service Oriented Architecture and Mashups.

At the internal technology briefing last week, I and my team presented and demonstrated the features of Presto, JackBe’s enterprise mashup family of products, to 25 developers and consultants. One of the important areas of discussion was around what we mean by a mashup and how the term ‘mashup’ has evolved over the last year to mean almost anything. For example, the following is the definition of the term mashup on Wikipedia:

A mashup is a website or application that combines content from more than one source into an integrated experience.

The problem with this definition from my perspective is that it allows you to practically label anything as a mashup, including a portal application, composite application, and what have you that brings disparate content onto a single web page.

I don’t think I want to disagree with this or any other definition of a mashup floating around in the industry. However, I feel that all the existing definitions and explanations are lacking something so important about the real intent of these mashups. This was also apparent at the discussion a few weeks ago at the IBM Mashup Ecosystem Summit. So, now I feel compelled to offer you what we at JackBe mean by a mashup:

A mashup is a shareable software block created by a user, encapsulating ad-hoc user driven processing of disparate data sources, delivered with a user focused view.

Allow me to elaborate further using the following characteristics:

1. Mashups are made up of user driven micro-orchestrations. In other words, when I access some data or service, I am performing small operations on the way data is computed and rendered in a very informal and iterative manner. For example, consider how one uses a spreadsheet which is a great example of a canvas where mashups happen in the enterprise when a user pulls in data from different sources, combines, sorts, computes, filters and visualizes by iteratively processing it until he gets the desired results. If you really think about it, what the user is doing is really orchestrating getting data from different sources and processing using one or more operations to yield an integrated view of the data.
2. Mashups are user focussed, i.e. they are primarily created by the user for the user. They are not the product of some developer or IT guy writing a lot of code. However, current examples of mashups that we see are primarily developer oriented, it is just the beginning. The real value of mashups comes when we enable and empower our end users to perform these mashups the way they want to do it without having to call and rely on IT needs.
3. Mashups are ad-hoc creations and are very situational based on users immediate short term needs. They are designed by the user to meet a specific need. These mashups have a very short life span varying from hours to days. This is the reason that the users cannot wait and demand IT to create and deliver these mashups.
4. Mashups can be visual and non-visual. The most common kind of mashup that is out there is probably something that overlays some information on some kind of a map. However, there is more to mashups than just displaying pins on a map. I can mashup disparate data to create an integrated data view. I can mashup processes to create a new process. I can mashup domain models of different application domains to create a new application domain model.
5. And finally, mashups can be performed on the client side and on the server side. However, I think the best value of a mashup is when we combine both client side and server side mashup functions since we can defer heavy lifting to the server and build intelligent clients that can enhance, complement and focus on user experience.

Before I conclude, I would like to emphasize a few points.

1. Whether we do visual or non-visual, client-side or server-side, mashups must be user driven and user focussed.
2. Just because mashups are user driven and user focussed does not mean that we no longer need IT. IT is still a critical part of the whole mashup infrastructure in an enterprise. However, instead of the users going to IT for every little thing they need which can be transient, situational and ad-hoc, they should be able to accomplish what they need without having to rely on traditional IT and experienced programmers to build what they need. For example, imagine what would happen if Microsoft Excel users needed IT help to write a macro or to create a chart from a table of data they put together. Mashups in the enterprise must address these kind of needs of enterprise users accessing disparate data and services to create and share new information in the Enterprise Web 2.0 world.

In my next blog entry, I will discuss more about our work in creating our comprehensive enterprise mashup platform that encompasses the above characteristics. It finally feels great to be able to talk about what we have been obsessively building over the past year!

What do you think? I am really interested to hear other opinions and thoughts around this.

[Cross-posted from http://blogs.jackbe.com]

[As a preface to this blog, I want to give my apologies for being away from blogging for the last few months. I've been busy creating Enterprise Mashup software here at JackBe. Now that our software is production-ready, I'm looking forward to getting back to posting regularly and getting your feedback on my development efforts. Deepak.]

I was at the Mashup Ecosystem Summit organized by IBM at their offices in San Francisco last week. Our CTO, John Crupi, and our Chief Architect, Raj Krishnamurthy, also attended with me. It was an interesting mix of people from different backgrounds and companies all converging on the concept of Mashups. Jeff Nolan (ex-Teqlo, ex-SAP) gave an interesting talk about his experiences in a starting up a mashup company. Some notable points were: (lack of) availability of APIs; Do-it-yourself Data Formats; Performance can be a challenge; Need for strong visual composition tools; Lack of Standards. I think these are questions that this group will be able to tackle over time. (At least, I hope!)

At one point during the end of the meeting, someone asked: “What really is a Mashup?”. This led to a brief but inconclusive discussion. Which goes to show how nascent this field is that even among the experts in the industry, there is still some uncertainty about how to define and qualify a mashup. (Coincidentally, JackBe has a webcast coming up on May 23 on this very topic: ‘Enterprise Mashup Bootcamp: What, Why and How’. You can register for that webcast here.)

I managed to slip in a question at the Mashup Summit about how the group feels about Composite Applications which were a hot topic a year or more ago and how they relate (or not) to mashups. Predictably, there wasn’t a big desire for this discussion. However, my own personal take is as follows. We in the SOA software industry have been busy implementing SOA in the enterprise over the last few years in our architecture and IT infrastructure. This effort in SOA has largely ignored the end users, and mostly focused on the IT and business stakeholders. Composite Applications are, in a way, IT efforts to provide integration of data, services and processes. While there has been a proliferation of services around the internet/intranet, users have no good tools to use them to do their job more effectively. Therefore, end users do not see much direct benefit of SOA or services or even composite applications.

These SOA/services/composite applications efforts are now undergoing an (r)evolutionary transformation. Enter mashups. And enter the users! The integration is now happening at a higher level in the application stack, much closer to the user. (This is also what Dion Hinchcliffe points out in his blog, where he talks about the 5 styles of mashups.)

There was also some question/opinions about security and how to govern mashups. I think there is no need to be overly paranoid about this. However, service access control is still important in an enterprise world of mashups. Consider that today users are already doing mashups, whether you like it or not. They are doing this mostly in their heads or in a spreadsheet, mostly manually and mostly in a tedious and time consuming way, and in a not-easy-to-replicate-or-teach manner. If the users have access to the data, you don’t really have control on what they do with it in their heads or spreadsheets. So, why not make it easy for the users to do this, faster, more efficiently, collaboratively (so they can share their analysis/knowledge), and to do all this with the least amount of programming skills required (leaning towards no programming required). We are aiming for this at JackBe, as I am sure other vendors in the mashup space are.

Other notable topics of discussion at the Mashup Summit were:

1. Microformats. My favorite topic. I think Microformats (www.microformats.org) are currently under rated/under used in an enterprise. Expect to see a lot of interesting things in this space in the coming months. We have a thing or two in the works about this as well at JackBe. (Also see Jeff Nolan’s comments on this topic.)
2. Mashup of Data vs. Processes. It is easy to confuse the two and it’s important to remember they are not the same.
3. Offline & Synchronization: Ross Mayfield of SocialText asked how important this feature is and whether there really are good use cases that demand this feature. He blogs on this (and related) topics quite a bit and has a interesting perspective.

Bottomline, we at JackBe believe that a mashup has to be user-focused and user driven (not IT driven). Let’s stop searching for the killer app. The killer app is here and it is the User. Let’s enable and empower them to do what they really can do with mashups.

[Cross Posted from JackBe blog]

Yesterday, I came across this article by M. R. Rangaswami of Sand Hill Group that discusses Web 2.0 in the Enterprise. M R goes on to say:

Enterprise 2.0 is the synergy of a new set of technologies, development models and delivery methods that are used to develop business software and deliver it to users.

Being a technologist, I get this.

In my previous post, I discussed a little about what Social Web/Web 2.0 means to the Enterprise. A couple of weeks ago, I wrote an article for eBizQ that was simply titled SOA and Ajax. In my article, I discussed the potential emergence of Enterprise 2.0, which can be defined as enterprise computing leveraging Web 2.0 principles and concepts. I predicted that consumer-oriented Web 2.0 concepts like tagging, folksonomy (informal community-based taxonomy), wikis, blogs, and RSS feeds will also gain adoption in the enterprise context. Web 2.0 concepts and techniques enable capturing the semantics of different data and resources within the enterprise. Together with SaaS, Ajax, and SOA, and the other aspects MR points out in his article, I see the emergence of Enterprise 2.0.

Whether you love or hate the term “Enterprise 2.0″, one thing is for sure. The landscape for enterprise software is changing rapidly. What do you think?

Click Here to Comment

[Cross Posted from JackBe blog]

While there are varied agreements about what Web 2.0 is all about, in this short presentation on ZDNet, Andy Gutsman (from Zend) concisely lists the following three enablers of Web 2.0:
• RIA – to bring the experience of desktop applications to the browser
• SOA – to enable by exposing services including mashups
• Social Web –where the end user is the integral part of the data and applications

That’s interesting. I have a few comments on the above. While talking to customers and analysts, it seems there is a sense that many equate Web 2.0 to Ajax/RIA in some sense. I work at JackBe, which started out as an Ajax company. While I am happy to hear the above association of Web 2.0 to Ajax/RIA, I would like to reiterate that Web 2.0 != Ajax or RIA. Just by putting a RIA face on your enterprise applications will not make your applications Web 2.0.

The second item above, SOA, is interesting as well. Over the last few years, many enterprises have been aggressively adopting SOA with the goal of realizing all the business benefits it can unleash if implemented correctly. But most of these SOA efforts have been focused primarily on enabling the integration efforts inside and outside the enterprise. I came to JackBe with a background of SOA along with my colleagues John Crupi and Dan Malks, and we see a strong association between Ajax and SOA and that is the area we are currently focused on at JackBe to realizing the conjoined benefits of Ajax and SOA. In other words, unlocking the potential of SOA by synergizing it with Ajax.

But I will admit, that in some ways, I am still scratching my head a bit about the third item in the list above, the Social Web, in the context of an Enterprise. In the consumer Web 2.0 space, the concept of Social Web is associated with wikis, blogging, and other aspects of sharing such as tagging, ranking and so forth. But, most enterprise applications are primarily aimed at enabling their employees and to some extent their partners. Think CRM, Sales force applications, support/help desk, ERP, Supply Chain, etc. When it comes to enabling cross-enterprise integration, most applications tend to expose service interfaces, be it proprietary or standards-based. There is no notion of a social web in this context yet. Sure there are burgeoning arguments over Enterprise 2.0 here and here about the Wikipedia’s Enterprise Social Software. But that entry on wikipedia still lacks depth and credibility.

So, What does Social Web mean to the enterprise? I have some ideas still in early stage, but I want to hear from you first. I will try to elaborate on my ideas at a later time. Meanwhile, tell me what you know, will you?

Click Here to Comment

I was at the Enterprise Think Tank meeting this week organized by the World Internet Center. The event was sponsored by SAP to bring together SAP Labs and Research folks along with some Web 2.0 companies to talk about what we all are thinking about the impact of Web 2.0 phenomenon on the Enterprise. The companies that were invited in addition to JackBe were: Abgenial, Coveo, Google, IBM, nStien, Sitepen/Dojo, StrikeIron, SocialText, and Zoho/AdventNet. I got to meet some very sharp and talented individuals from SAP as well as from these Web 2.0 companies. Jeff Nolan from SAP led the sessions from SAP.
Someone in the audience commented that Web 2.0 is nothing but the Web As It Should Be. I feel exactly the same way about it. Anyway, while there were the usual warm up discussions about what Web 2.0 is, we also talked about other topics such as (guess we couldn’t resisting suffixing everything with 2.0):

• Audience 2.0: The new users who have higher expectations and have experienced the joys of using the new rich Internet applications popping up all around us.
• Developer 2.0: Too busy to design/develop software (busy reading blogs?), needs to be more productive than ever, and is heavily focused on collaboration and leveraging open source.
• Technical Challenges: Thick vs. Thin Clients, Offline vs. Online, mashups. How it is easy to gather information in heaps, but what can we do to better understand it and analyze it.
• Business cases/models: Situational Applications (as IBM calls it), new delivery models for software (SaaS), software appliance model, application modernization, and enterprise productivity.
• Finally we talked about what SAP needs from us Web 2.0 companies and vice versa. As Ross Mayfield from SocialText says here, SAP has a tremendous set of assets and by leveraging/partnering with us Web 2.0 companies could end up doing something pretty unique and innovative for the enterprise. Pretty exciting! Let’s wait and see.

One of the recurring topics that kept popping up is Governance. And this is really key, because it is a very important aspect that we need to address in Enterprise 2.0. A couple of months ago, I attended the Gartner conference on SOA/Web Services where one of the analysts said something like – If you are doing SOA, you better be addressing governance. No governance, no SOA, no nada. And that is right on.

The traditional enterprise software issues such as security, scalability, manageability will clash with the Web 2.0 culture of instant gratification, unanticipated usage, less governable users and will further clash with new trends such as SaaS, situational applications, mashups, and so forth leading to Enterprise 2.0.

So what do you think is Enterprise 2.0?