Anybody remember the dual highway?
by Volker Weber
Another look at Quickr reveals that this is not one product in two flavors but two distinct products with the same name, and very few things in common: name, fonts, colors, Windows connectors. The rest is very different:
- User interface constructs (Portal vs QP framework)
- Search (Portal Search vs GTR)
- Templates (SNAPPS templates are Domino only)
- Workflow
- and the list goes on and on
There is no way to move content from one version to the other. You can't have a Portal frontend with a Domino backend for instance. Or the other way around.
Too me Quickr looks like two products in one box: Quickplace and Workplace Documents.
Comments
Exactly what I thought. I installed Quickr for Domino a week ago and thought: hey! A rebranded Quickplace. Then I installed Quickr for Websphere Portal last week and thought: hey! A rebranded Workplace...
This is not really going to solve the confusing feelings companies have when it comes to the offerings that IBM has in the collaborative software space...
Thanks for surfacing this, uhm, concern. Just imagine the consultation to a client on the New! Quickr offering without revealing this rather strange dual product pulled together: sir, would you prefer the Quickr on the left with a Domino architecture with the new, cool and improved SNAPPS collaboration tools...or perhaps rather the Quickr on the right using a proper portal framework with decent document management, search and component capabilities, but with fewer, slightly less cool tools... It really is not great for either one of the two Quickr's futures.
Thank you a thousand times over for distilling this down! I've been banging my head against a wall trying to understand where/how the functionality split without actually having seen the product. The discussions seemed to go one direction, the marketing another, and I was left confused in the middle.
So, again, thanks for making it succinctly clear. :-)
Volker - you have beaten me to that post. Why the hell would I use portal for this? Bigger, more difficult to understand, harder to implement (am I am a fan of Portal).
Domino - quick, simple, functional.....
I had a feeling the Domino version was a bit different than the WPS version when I looked at the download sizes...
This confirms my suspicions. Thanks for the heads up!
I'm impressed that IBM has the resources on this again. Quickplace was down to almost no people and now they ahve enough people to build two products with the same name. Congrats to the person that managed to get that budget approved. I think it would probably be better use of resources if they were dedicated to one technology though, surely leading to quicker releases, more features addressing customer requests etc.
The problem for Quickr websphere version is that typically the Domino Partners do not sell websphere stuff well, and the Websphere folks tend not to sell anything Lotus brand related well, so it ends up with no one selling it. IMHO.
I prefer to think of the glass as half full here (actually, maybe one and a half times full). Each deployment option for Lotus Quickr leverages the technology base and capabilities of the underlying platform...but if you want, you can use them all together, in one environment. Take the Lotus Greenhouse for example - Create a Place in the greenhouse and you'll see a list of templates that happen to span services for WebSphere and services for Domino. As the user, you choose - based on function not based on deployment, of course. Then when you go to My Places, you see them all. And when you access places via the connectors, you have a consistent experience no matter which deployment option your place is running on. The experience on the connectors is 100% the same, and via the browser there are some differences but the underlying services infrastructure of Lotus Quickr definitely allows for the possibility of browser based components that operate against any deployment option.
That being said, Lotus Quickr certainly does not require both deployment options to be installed to provide value. As the earlier comments implied, install the deployment which matches your needs and skills, and you'll be set!
Interesting comment, Satwick. Which template will give me a Domino Quickplace? The Portal Quickplace failed to impress me. Maybe the other one does.
I think Carl’s hit the nail on the head, as usual:
The problem for Quickr websphere version is that typically the Domino Partners do not sell websphere stuff well, and the Websphere folks tend not to sell anything Lotus brand related well, so it ends up with no one selling it. IMHO.
The problem is that too many of the people in the Domino community will not (for whatever reason ... good and bad) work with Portal. Portal sells well and integrates with both the IBM collaboration stack and others. So you can sell Portal into a MS shop if you want to. Having Quickr and Connections that are not tied to the hip of Notes/Domino is a good thing for those customers.
The initial reaction of customers, once you get past some of the install bugs that are reporting in the forum, is they are happy with the update. They are also excited about the release that will come out later to provide the Notes 8 integration ... even if it slips to early 2008.
What is clearly needed is a design tool for Quickr that works at the meta level, so that someone can design a template once and generate both the Domino and Portal versions with the same functionality. If IBM is not working on this, it is a mistake -- but it is a mistake that a partner could profit from.
Lotus Quickr: Single bridge over disparate waters
When Lotus made the decision to invest significantly in the team collaboration and basic document services space and bring Lotus Quickr to market, we were not inventing a new concept or a new market. Both basic document / content services (or document management if you prefer) and team collaboration have been around for quite a few years. Analysts and customers and our own experience tell us that these services are converging -- that customers would like a single offering that integrates the ability to organize and share content with the ability to collaborate. But this desire for an integrated offering -- as obvious as it might seem to us now -- is a new development in the market. These capabilities were viewed (and purchased) separately not that long ago.
Many large companies have 6 or more content repositories deployed today and customers are asking for a way to provide end users with easy access across those disparate back-end systems through a compelling Web 2.0 style UI. We like to think of Lotus Quickr as a "single bridge" that will provide end users with transparent access to content and collaboration functionality across a wide range of repositories and environments from departmental repositories (like Domino) to enterprise content management systems (like IBM DB2 Content Manager & IBM FileNet). The Lotus Quickr strategy to provide easy access to our collaborative content services across a range of content repositories has struck a chord with our customers. We are also protecting those customers who have invested in Lotus QuickPlace or Workplace Documents or Workplace Team Collaboration or Domino Document Manager that have tera-bytes of data. We're committed to preserving their data, investments in licenses and in skills... and to providing them with a path forward to take advantage of the exciting new capabilities in Lotus Quickr 8.0 and the future releases we're already planning. Protecting our customers investments and existing data is paramount and drove some of the decisions in our 8.0 release.
Lotus Quickr 8.0 does offer two different deployment options: Domino services (or "runtime") with content stored in an NSF repository or WebSphere Portal services with content stored in a Java Content Repository (JCR). This isn't a secret. It has been key to our strategy -- starting at the Lotusphere Opening General Session. This flexibility in deployment options is essential for us provide a path both for customers who invested in Domino-based collaboration products and for customers who invested in Workplace or Portal-based collaboration products.
The flexibility in deployment options has also started us down the path of building a common web services architecture that is one of the greatest strengths of Lotus Quickr. You can see it today in the Quickr connectors. The connectors provide integration and transparency for the end user by bringing collaborative content services into their everyday applications such as Notes or Sametime. I can add Quickr places from a Domino server and Quickr places from a WebSphere Portal server to my connectors. As an end user, I don't know or care which type of server it is. It simply doesn't matter. We're building a services / API layer in Lotus Quickr that is independent of the underlying deployment architecture, implemented for the connectors and a few other services in Quickr 8.0. In future releases, we will continue to build out that services layer so that eventually all the services will use it. That will give us the consistent Web UI you're looking for -- a single Web UI, written to a services layer, which then accesses one or more back-end repositories. Already, many business partners and customers are grasping the potential of this architecture. Instead of clamoring for a single deployment option, they are asking for more -- connectors to integrate IBM FileNet P8, IBM Content Manager, Documentum, Opentext, and ... Heterogeneous environments are a reality, and Lotus Quickr provides a path to making that more or less invisible to end users.
Our main priority in this release was to delight the end user with a focus on delivering an easy to use interface and "connectors" to enable content sharing regardless of the everyday application they use. From an end user perspective the core collaborative content services they want are over 80% common regardless of which Quickr services are deployed - Domino or Websphere. That doesn't mean each capability looks identical from both perspectives -- the user interface to create a workflow is different, for example, but in both cases I can create a basic workflow. As an end user, I really only care about whether I can do it. Since most companies won't deploy both Quickr services for Domino and for WebSphere, why does an end user care that the mechanics are somewhat different in the two deployment options? (And remember, this is a journey... over time, Lotus Quickr will have a complete services layer so the end user experience will be the same.) And yes, the fonts and navigation are not identical. In this release of Lotus Quickr, we focused primarily on consistency within a single deployment option, not across the two. That will come...
For most customers who are buying Lotus Quickr, the two different deployment options simply isn't an issue. They love the capabilities it delivers. They love the Quickr connectors and the cool new UI. And they will choose the deployment option that matches their skills and infrastructure preferences. We're bridging the two core environments today with a core set of connectors and with the common web services layer that will continue to expand to enable Lotus Quickr to integrate & coexist with an even broader set of disparate repositories and leveraging a common UI layer tomorrow.
Long comment, Peter. And good to see you.
If you run Quickr 8 on Domino, you can only access Domino repositories. And if you run Quick 8 with (its own) Portal, you can only access JCR repositories. Right?
If you develop a template for Quickr 8 on Domino, it will only run on Quickr 8 on Domino, right?
And if you deployed Quickr 8 with its own Portal, and you then decide later that Quickr 8 on Domino would have been a better choice because you want to enable your users to take their content offline, you can't take your JCR repository and move it over to Domino, or can you?
Peter:
re: "Since most companies won't deploy both Quickr services for Domino and for WebSphere, why does an end user care that the mechanics are somewhat different in the two deployment options?"
I understand that end-users are your priority, but developers do care about these things, and developers are the key to multiplying your end-users! And it's not just in-house developers who care, but also partners. How many Domino-oriented partners will invest in Quickr when they realize that to serve the whole market they have to have two sets of skills and duplicate all their value-add efforts? How will a community of Quickr-oriented developers grow? The answer, right now, is that two different communities will be needed, and that these communities won't be able to share with each other. And that's not just in terms of sharing actual templates, but also in terms of sharing skills and cross-cultivating ideas that strengthen Quickr on both underlying platforms. And the end-users do suffer on account of this, because as a result of having two technologies and two communities there will be fewer value-added offerings available on each of the underlying platforms.
Richard:
End users certainly aren't the only priority, but they are definitely one of our primary focuses for this initial release of Lotus Quickr. We heard loudly and clearly from many of you that if we don't create something compelling for end users, the game is lost.
But we certainly understand the need to provide an architecture that will support of single set of development skills rather than requiring our business partners and others in the community to have two sets of skills. That is one of the drivers behind building a services layer architecture -- so people can program to a single set of services and APIs, no matter what the repository. In the long run, that will of course save us development money too and enable us to focus more on adding new function.
We also feel it is critical to prioritize preserving the investment of customers who have adopted either architecture. I'm sure none of you really intend to encourage us to abandon one set of our customers to make things a little simpler in the short run for the other set... We're pedalling as fast as we can to get to a more streamlined, integrated architecture with that single development environment and tool set, but we're also working hard to build bridges for everyone along the way.
Volker:
To try to answer your question about the relationship between the runtimes and the repositories. If I use the Quickr services for Domino (Domino runtime), then by definition, I have NSF repositories deployed where I have my content. Ditto for Quickr services for WebSphere Portal -- I get a JCR. So at this point in time, I can't choose to deploy Domino runtime against a JCR. The runtime and the repository go together.
However, we have some customers looking at deploying both -- mostly for infrastructure reasons. We provide an integrated Quickr "home page" for the end user (nicknamed "Onespace") that lists places on both repositories. When I link to a place, then under the covers, I'm using the runtime that goes with that place / repository. Same thing with the connectors. I can have both types of places in my connectors. That's our first step in distancing the end user from the back-end.
We have also had questions from others about the type of place "transitions" that you describe. Will people be able to "export" a place from the NSF repository and "import" it into the JCR, for example. We don't have this capability now, and we're not positive it is something people will really want to do over the long run. The whole point of support for multiple repositories (going beyond just NSF and JCR in the future) is that it should stop mattering where things are.
That's our thinking, but we are also looking at some options for place migration from one back-end to another (and from completely different back-ends into Quickr places) if people really want to do that.
This is kind of surprising. So far I have been briefed on a three layer architecture: connectors, services, repositories. The web interface was always presented as one connector to the services, which then connected you to the repositories. Now it turns out that there are two different silos, where the web interface is different, the services provided are different, and the repositories only work in their silo. When you add new repositories, will they add more silos? Or will I be able to use my Quickr service on Domino to access the Content Manager and Filenet repositories? Or will those only be available on the Portal version of Quickr?
So far I see two different products with the same name, which share only the connectors for Microsoft Office, Windows Explorer, Lotus Notes on Windows and Sametime on Windows.
Jelan,
I assure you, I am in no way suggesting you should abandon either set of customers. What I am suggesting is that you produce a meta-design tool that a developer can use to produce a single template design, and generate and deploy the platform-specific versions for either architecture. I hope that is implied in what you refer to as the services layer architecture. I do look forward to learning more about it.
