Mashing the Enterprise Service Cloud

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?

Read More...

Summary only...

Enterprise Mashups: The New Integration Front/Tier

'Integration for the user and by the user'. That's often how we describe enterprise mashups. Is this right? Historically, integration has been an IT-driven process involving integrating large systems, wrapping and reusing existing systems, connecting them together. And, as we all know by now, the paradigm for this is SOA.

SOA-style architectures are based on open standards, such as WSDL, RSS and REST. These technologies enable us to use standards to dramatically reduce integrations costs. The good news is that SOA killed the proprietary adapter market and the business unit may reap the rewards. The bad news is IT has a huge legacy integration backlog and can't even come close to implementing SOA for the business unit.

This creates an even bigger problem for the knowledge worker (also known in McKinsey-speak as the 'tacit' worker) who needs an ever-changing set of things integrated in an ever-decreasing amount of time. This might be non-tech integration via 'cut and paste' or more sophisticated 'drag and drop' integration. You can think of this integration as situational or 'user-driven' integration. It's what IT can't (and shouldn't!) deliver.

But contrary to some opinions, tacit workers don't integrate for the hell of it. They integrate because they have no other choice. Today, their standard integration software is Excel. They create information by combining disparate information from databases, email, CRM, ERP, etc and integrate it using Excel and collaborate by email the spreadsheet, time and time again.

Every day I monitor ten RSS news feeds looking for news about my current and potential customers stored in Salesforce.com. I'm paid to gather information about my customers from disparate Web sources to help drive our product strategy. But now I finally have technology which helps me integrate this disparate information into an instant application. Not the full-blown application we're used to, but rather a micro application that does just what I need it to do with the data I consumed. Welcome to Web 2.0. More specifically, welcome to Enterprise Mashups.

It's this combined information that I use to make daily decisions that establishes my value to my company. The added value happens when I can instantly share this rich information with others (aka collaborate). And what if I can expose my creation to others so they can add value by simply consuming what I did and integrating with more? The answer is I get something IT could never give me and something others like me would kill for. This is the real future of integration. The real future of Web based empowerment. This is the real power and future of enterprise mashups.

Read More...

Summary only...

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

The SOA Petri Dish

Looking down a microscope at my son’s school, I was amazed that all those ‘things’ could co-exist in such a tight shoulder-to-shoulder world. These organisms even thrive in this type of environment, dying if you separate one of the 'things' from the group. It might be obvious but I’ll say it anyway: SOA is like that. It’s impossible to exist alone, even deadly. But learn to co-exist with your neighbors and you flourish.

I've also seen many posts on similar subjects, such as Eric Norlin's 'Assembling the disparate bits' post. And because JackBe makes both SOA ‘consumer’ products (a mashup consumer interface, Dash, and an Ajax IDE, Studio) and ‘producer’ products (a SOA virtualization and mashup server, Edge), we’ve seen the SOA Preti Dish in action too many times to count. We’ve had the opportunity to interoperate with many, many third-parties in the SOA world. JackBe has both consumed BEA portlets and had applications (can we call them 'applicationlets'?) consumed by a BEA portal. We’ve brought in services third-party ‘service’ types including EJB, SOAP, REST, RSS, and XML, and from many function-specific vendors like Salesforce, Bloomberg, X-Ignite, StrikeIron, Amazon, Yahoo Pipes, Google, ESRI, Ionic, and some really cool demographic data providers that we'd love to mention but can't. We’ve incorporated third-party Ajax widgets from Dojo, ActiveWidgets, DynamicDrive and others. It’s a dizzying list. And every day we add more.

None of these technologies or technologists could live alone. I find it impossible to believe that any single vendor could provide the innovation, engineering and support behind the broad array of SOA infrastructure out there. And this buffet-style development changes many things for the better. Flexibility is the major improvement. And it’s one that is not emphasized enough. Don’t like the service you are using? Need a better 3-dimensional graph? Find another vendor. The cost and risk of change is much smaller than it used to be.

Life under the microscope can be tough. But it’s worth it.

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