Mashups can turn any Enterprise into a Superorganism

A few nights ago I watched a very interesting piece on the Discovery Channel about ant colonies called ‘Ant Wars’.  (Give me a few more lines and you’ll understand why this has anything to do with IT, enterprises or Mashups).  I was awe-struck with the way that an ant colony behaves as one unified being rather than millions of individuals - some ants perform one function, which other ants use to their advantage so as to be able to perform their function more easily, and so on, and so on. 

The commentator mentioned how scientists consider an ant colony to be a “Superorganism”.  The Wikipedia, as usual, had a helpful description of the term: ‘A superorganism is an organism consisting of many organisms…where division of labour is highly specialised and where individuals are not able to survive by themselves for extended periods of time’.  

Without much apparent centralized coordination and without any one individual leader barking-out precise orders to the individuals, each ant performs their own task in what appears to be a seamless orchestration of actions towards the achievement of a much larger purpose – that of survival of the colony.

As I have said many times, I see Mashups everywhere.  So I got to thinking that…

…with the adoption and use of mashup technologies, enterprises evolve into a kind of Superorganism where individuals create mashups to solve particular problems and by doing so create an environment of re-use where others can more easily solve subsequent, perhaps more complex, problems.

As the leading Mashup vendor, we are lucky to be a front-and-center witness to many cases where, with the use of our Presto Enterprise Mashup Platform, individuals in organizations are able to easily and economically take data from many different applications built by enterprise IT departments and mash it up with other services to solve their own problem. Then, those services are re-used and built upon by others to solve similar yet different problems.

This beautiful “ballet” of solution solving and application building happens with little planned coordination and appears to occur naturally without the central planning usually required. A Superorganism indeed.

Read More...

Summary only...

Mashups : New and Agile way to Integrate

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 them.

Excerpt from ZapFlash:

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.

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 from ZapFlash:

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.

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. :-)

[Cross-posted from my personal blog]

Read More...

Summary only...

The 3 Parts of Mashing

Deepak Alur, JackBe’s VP of Engineering, has outdone himself. He recently posted a great blog on our Mashup Developer Community entitled ‘Mashables > Mashups > Shareables’. It does a great job of distilling a mashup down to 3 fundamental parts. You can post comments to Deepak in our Community.

How exactly does the mashup process work? What does Presto really do? These are a couple of common newbie questions. I have had different explanations for this, but of late, I have narrowed down on the following elevator pitch (trust me, this textual explanation looks long, but I can explain really fast in person) that I have used successfully with other developers recently. So I thought I will share this with the community in case it helps others to understand the process and artifacts around enterprise mashups.

I found it easier to explain the whole mashup workflow using three terms: "Mashables > Mashups > Shareables". (OK, I confess, these may not be in the English Dictionary yet.)

As a mashup developer or user, we need to start somewhere. To me that starting point is what I call Mashables. These are things that one can use, invoke to get data and send data. Things like services such as WSDL based web services, REST based web services, RSS or Atom services, proprietary XML/RPC services, or even the conventional RDBMS tables, view and stored procedures. I would also include other items such as spreadsheets, XML documents and unstructured information on internal and external websites. These are the raw material for mashups. These need to be made Mashable! And this is exactly what happens when you 'publish' one of these things to Presto. It becomes a Mashable artifact that can be normalized, secured and managed.

And then comes the second thing called Mashups. I don't want to go into a philosophical discussion about what a mashup is or isn't. However, I think mashup is a user-driven, user-focused thing that encapsulates the kind of data processing and manipulation actions a user would normally do to turn any data into real information. Such actions include joining, merging, sorting, filtering, constructing, transforming, clipping, and so forth. And in Presto, a mashup is represented by an small file written using EMML (EMML is Enterprise Mashup Markup Language). EMML is an XML-based dynamic declarative domain specific mashup language. Again, a Mashup becomes this artifact which can be secured and managed just like the Mashables.

The third and final thing is the Shareables. Once you have Mashables, and Mashups, you want to be able to share them with co-workers, partners, friends, whoever. Shareables can be exposed as a service interface so others can use it as a REST or RSS or Atom or WSDL service. Another popular type of Shareable is what we call Mashlets, which are enterprise widgets that offer a rich interface to the Mashups. Mashlets are not full blown applicaitons, but can be small micro-applications that encapsulate a very specific functionality. Mashlets can be shared by publishing them on Wiki pages, blogs, websites, portal servers. You can even email a mashlet or call it directly from a smart phone like iPhone. Other types of shareables include mashups and services shared as REST urls, RSS feeds, data feeds, spreadsheets, email and so on.

There you have it. Now I can just describe Presto simply as a platform to securely create, publish, consume and collaborate with Mashables, Mashups, and Shareables!

Read More...

Summary only...