Defining Mashups

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 an internal technology briefing last week, my team and I 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-focused, 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.

(Editorial note: Since I've been asked about this a few times, I've submitted this blog to Digg. You are welcome to add your Digg here.)

Read More...

Summary only...

Differences in 2.0's Continued

Wow, we received fantastic feedback on our the last post, Differences in 2.0's. In particular, we received emails asking for more clarification about the difference of Enterprise Web 2.0 and Enterprise 2.0. I created a pic (see below) that I hope will help.

First, let me attempt to relate Enterprise 2.0 to Ford, the car company. We could draw parallels to Enterprise 2.0 and what Henry Ford did with manufacturing. In this case we could say Ford created an 'assembly plant 2.0' which changed the core of the whole organization; organizational processes & relationships with said processes, the workforce, their roles, relationships with partners and customers, and how all of these parts interact with each other. This is a stretch but what I am trying to convey is that the core of the enterprise, down to how its business & peoples operate, changes and doesn’t resemble that of the organization before. This change resembles more of a social diagram tied together by Web 2.0 social tools and loosely coupled web apps capable of being composed or customized by each node at a moments notice to respond to whatever need arises using inputs(data & information) from around and out of the network.

[...pause after that mouthful...and we're back...]

In this stretch example, the change creates a Ford company that looks and operates much differently (better) than other enterprises around it still assembling cars the pre-Ford way. This is due to the relationships between the people, data, and the collaborative nature of the new organization.

I expanded a portion of this new picture to incorporate the two facets of Web 2.0 (The social collaborative paradigm shift & the Web 2.0 technology enablers that make this possible), how these once implemented correctly make up the Enterprise Web 2.0 infrastructure, and lastly how with the addition of a Enterprise collaborative paradigm shift, all make up Enterprise 2.0.

You’ll notice that the nodes here state ‘The User’ but this user could be one person, a team, or even a business unit. The connecting lines can be thought of as the social construct or Web 2.0 paradigm that I talked about in the last post, and the Web 2.0 bubbles as Web 2.0 technology enablers connecting Users with systems and other Users.

So, simply stated (I hope) Enterprise Web 2.0 is a technology solution made up of Web 2.0 and Enterprise 2.0 is the organizational paradigm shift that leverages these solutions which, by EW2.0's very nature, must be deeply embedded in the organization to work, creating a much different 2.0 organization as a result. This transition takes time as the whole organization re-roots strategically around the embedded Enterprise Web 2.0 infrastructure. Now one could raise the point of why go through all of this -- benefits of Enterprise Web 2.0 adoption? But this is an entirely new post all of its own. Here are a couple of posts that might help if interested.

• The Age of Customization: Enterprise Web 2.0 is the perfect pair of pants!
  
• Enterprise Mashups and Total Cost of Ownership
• Enterprise 2.0 meme map

I hope this helps. Although I am not a graphic artist, I think it pretty much summarizes the connection and relationships of all four 2.0’s we touched on in the last post sums up how I put all these pieces together. As always I am open and would like to hear your thoughts. mike@jackbe.com

Read More...

Summary only...

Differences of 2.0's

A lot of people ask us here at JackBe about the definitions and or differences between Web 2.0, Enterprise Web 2.0 and Enterprise 2.0. So here are some of my thoughts simplified for a blog post.

Web 2.0 – There are two parts to this one which will make sense when I get into the difference between Enterprise Web 2.0 and Enterprise 2.0.

1. Web 2.0 – the user-driven paradigm shift. Youtube, blogs, wikis, RIAs with greater self-service capabilities… all of these are examples of a paradigm shift from older HTML static, mostly one way communication of ideas and information to a new User-Driven web model which enables you and me to more easily contribute content, share information and collaborate with each other through the web.

2. Web 2.0 - technology enablers. This user-driven shift has been made possible in part by new or now accepted technologies and techniques which have gained greater penetration as web application tools. Such include: Ajax, proprietary RIA tools like Flex and Lazlo and now Silverlight, Service Orientated Architecture (SOA), Ruby on Rail and other lightweight dev models, Web Services like REST and RSS, Mashups (data and visual) and Tagging. Of course this is not an exclusive list but I think you get my point.

Enterprise Web 2.0 – the Web 2.0 technologies mentioned above put into practice in the enterprise. For example: richer, more productive customer self-service apps, inter-department collaboration through bogs, and wikis. But simply ‘slapping’ these technologies into a rooted organization will not bring about the same successes and value that Web 2.0 apps have enjoyed in the public domain. Enterprises have too many constraints and need a mind and culture shift along with deep embedment of these 2.0 tools into its processes to have any kind of a definable impact.

Enterprise 2.0 – The Enterprise 2.0 is analogous to #1 above in that it represents a user orientated paradigm shift of the enterprise makeup itself. It embraces the decentralized organization built around disparate data and information with users empowered to create new information built around and on top of others ideas through sharing, and collaboration. An organic organization loosely designed and constructed to empower knowledge workers to do what they do best by giving them what they need, when the need it and how they need it by enabling them with 2.0 technologies and nurturing this new paradigm mind set internally. Here enterprises reap the benefits of 2.0 through network effects from its user’s contributions and collaboration and realize success that increases proportionally as more users contribute to the organism creating a potentially indefinable value proposition to stakeholders.

Each of these could be expanded in much more detail but why make it more complicated as this? If you have any thoughts please feel free to share or contact me. That is after all the point.

Read More...

Summary only...