Tag Archives: Mashup

Definition of a Mashup

The JournalSince Larry Clarkin and I wrote the Enterprise Mashups article in the Architecture Journal, I’ve been getting a ton of questions about mashups and what they are. To that end, I thought I’d put my neck out and lay down a public definition.

A mashup is an application that pulls together data from different sources and puts that with functionality that didn’t know about each other previously to provide a interesting graphical look at that data.

Often, a mashup is used to the end of making decisions based on a visualization of the data.

The canonical example is putting data on a map. For example, Wikipedia (at least as of when I wrote this) defines it as follows:

In technology, a mashup is a web application that combines data from more than one source into a single integrated tool; an example is the use of cartographic data from Google Maps to add location information to real-estate data from Craigslist, thereby creating a new and distinct web service that was not originally provided by either source.

Mashup (web application hybrid) – Wikipedia, the free encyclopedia

However, it doesn’t have to be a map. It could be a graph, chart, mind map or any number of different overlays.

Now, notice that I didn’t talk about any given UI technology in my description. It could be AJAX. It could be Silverlight or Flex/Flash. It could be Java Applets. I’m not concerned about the exact technologies involved – just the overall idea that you are pulling together data with functionality with a UI none of which knew about each other before your “glue” code put them in the same room and let them dance.

Granny wants to Mashup?Things that are not mashups

Composite applications are not mashups. This is actually a funny one. Mashups are, by and large, composite applications. You can equate it to inheritance. Mashups have an IsA relationship with Composite Applications. However, the composite application that simply pulls together a number of different widgets each completely independent of the others on the page is not a mashup. So, what I’m saying here is that CAB Smart Parts, Sharepoint web parts and Java Portlets are not mashups – they are simply part of an overall application that has been assembled.

Aggregations are not mashups. I’ve been asked several times if aggregating 2+ RSS feeds or simply combining different data sources is a mashup. The reality is that it’s not.

If, on the other hand, you were pulling in 1+ RSS feeds and/or data sources and laying those out on a timeline or some different view of the data than just an aggregated list – then we are probably talking about a mashup. The key part here is that we are doing something more with the data than adding it together. We are enabling decisions to be made based on that data.

Tools to build mashups

You don’t actually need tooling to build a mashup. You could create it from scratch with a little bit of Javascript and a chart control. The most common mashup, as stated in the canonical example above, is a map with geographical data laid on it. Both Google Maps and Live Maps have SDKs that you can build on top of. Actually, the Live Map SDK has a completely interactive documentation set as you can play with that will let you try different things and copy source code right into your own applications. In a lot of ways, you can look at these maps as not only applications but mashup platforms.

Popfly and Yahoo! Pipes

Then there are more complete frameworks and platforms that will help you build mashups such as Popfly and and Yahoo! Pipes. These platforms allow you to drag and drop different data sources and apply logic and ultimately run that through a front end visualization. My 12 year old son has played with Popfly and created mashups with ease. Denny Boynton wrote a great post entitled “Is the Future of Popfly in the Enterprise?“. I think that he’s got something there.

One of the interesting parts about Yahoo! Pipes is that it allows you to pull in your data, build out your functionality and then at the end you produce it and have a tabbed view with a different visualization on each tab. That’s cool! If your data is geo tagged, then it will give you a map view. If you have numeric data, it will show you charts and so on.

Where to get started

There are a couple of ways to get started playing with mashups. First, you can take a look at Popfly and the like. Or you could get started with one of the online mapping applications/mashup platforms. However, if you are serious about mashups in your own company and want to produce mashups with your own data – you need to start by taking a long and hard look at your SOA strategy.

Are all of your services written because you needed to move the client to a different machine? Often you can tell these because they start to resemble your table names and fall into Ron Jacob‘s CRUDy Web Service Anti-Pattern. Unfortunately, this is the vast majority of applications that I’ve seen in the world that use web services. It’s just using web services rather than truly service enabling your platform.

Or are they strategically built services that encapsulate business logic? Are you thinking about your authentication and authorization strategies? Are you thinking about SOAP verses REST? Can you produce either from your platform?

These are all decisions that need to be made before you decide on the UI technology.

Mashups – Powerful Enterprise Tools

IMG_1402In the 13th edition of the Architecture Journal, Larry Clarkin and I wrote an article on Enterprise Mashups. You can find a PDF of the journal here. The two of us actually presented the paper at the Strategic Architecture Forum (SAF) in Redmond which is a gathering of about 100 enterprise architects, CIOs, CTOs and the like.

Our basic thesis is that Mashups, while most famous in the consumer space, are gaining traction in the Enterprise. We also lay out the common architectural tenants of all Mashups and explore the critical success factors that you will need to ensure inside the enterprise. Hopefully I’ve convinced you to go read the article at this point. Without stealing all of the thunder from the articles, it was fun to see our basic premise and prediction come true already. Larry pointed out in his write up about the article that we had quoted a McKinsey study that said that only 21% of enterprises that they surveyed were considering Mashups in their enterprise. 2 days after our article was sent to the press (48 hours too late to put this in the article itself) the Economist published a survey had that number doubling to 42%. It’s good to be right.

The discussion at the SAF was a round table discussion with Larry and me leading. We had a great conversation with a lot of good questions. I can group the vast questions into three large buckets:

  • Enablement
  • Governance
  • Technologies

Enablement and Governance were the two largest parts of the discussion. How do I safely allow more people to create mashups without compromising the IT department, the data and everything that we hold near and dear? The fear, that I think that we resolved, is that this is the Excel or Access database of this generation and that if we as the IT department don’t have control over it that we will have the wild west and everyone will be working off of non-record data. The counter point is that if someone is creating a mashup with approved services, they are actually leveraging the authoritative data source rather than creating new rogue ones. One of the companies had counted 85 different access databases with pricing information in them. That’s a bit hard to manage and needs to be reigned in because that’s not just 85 different databases, that’s 85 different versions of the truth out there and you have to ask yourself why would all these little departments create such a database. Really it’s to solve a business need that the IT department wasn’t solving. That might be access to the data or a certain twist on the data or any number of things but it’s pointing out that the IT department is not aligned with their business in the way that they need. A solid and flexible service in front of authoritative pricing information would go a long way to eliminating the need for those other databases. But the problem is potentially deeper than that.

Denny Boynton (who was moderating the discussion for us) asked the question, if we govern access to the data appropriately – is that enough? The answer from a lot of people was that governing the data was an 80% solution. But the reality is that there are certain types of data that shouldn’t be mashed with other types of data. There are conversion issues if the information is not uniform. There are filtering issues because every department has their own idea of what is a “valid” this, that or the other thing. All of these could be potential blocking issues and should definitely be concerns.

One of the interesting analogies that came up was cars and roads. As roads are built, people are enabled to drive to new location. We are not trying to control where a particular person or car drives. We do control the traffic through what roads we build, which roads are 1 way, where we put stop lights, speed limits and more. In a similar way, we are enabling people to do many different type of activities by building out services. We are not going to be able to prevent all wrecks. That’s a problem. It’s scary. The other issue is that if you watch the news, you hear about the 4 wrecks that happened on the way to work while you hear nothing about the 15 million that made it to work without incident. Similarly, the scary part is that there will be mashups that will be the IT equivalent of a wreck. There will be mashups that use data in ways that you were not intending or expecting. More often than not, these are answering some business need that you didn’t foresee and couldn’t fulfill. That enabling position rather than the one that is trying to do it all. It’s like building out railroads. The rail system only goes so far and then people get off the train and into cars.

The end result is that we have to build a core competency in SOA. That’s building out and governing the services that your constituents need. Sometimes those constituents are others in the IT department, sometimes they are from marketing or finance or manufacturing and so on.

From a technology standpoint, we talked about Popfly and Sharepoint in particular. Popfly is an amazing set of technologies and it’s going to change the way that we architect systems in the future. Denny Boynton wrote a fantastic article on it called “Is the Future of Popfly…In the Enterprise?”. John Mullinax also has posted on “building brand and transcending walled gardens” However, it’s really aimed at the consumer at this point in time. There are a couple of big things that it’s missing before it’s an enterprise level toolkit. The big one is that it’s not able to really leverage secured web services. Another big one is that it’s not hostable inside your own firewall and therefore not able to leverage services that are internal to your organization. These are just the current speed bumps but I’m sure that more tools in this vein will be coming soon for the enterprise. The other questions that we had were around Sharepoint. The reality is that there’s nothing specific in Sharepoint that does or does not do mashups. It’s a great portal site that does a lot work for you but it’s not specifically a mashup tool. That’s not to say that there won’t be tools built into Sharepoint in the future – but I don’t know what the product roadmap looks like.

Writing does not come easy to me. I feel very natural in front of a crowd but the act of writing is quite painful. I just want to say very publicly – Thank you Larry for making me go through the process of getting our joint thoughts down on paper for the journal. It’s been a great thing to have done.