As the site says:

This Award honours the top IBM Business Partner from each of six major regions of the world. Winners will have demonstrated increased revenue attainment and loyalty to IBM, along with the ability to open new local markets, and to maintain a positive stature in the Business Partner community. Business Partners considered for this award significantly impact Lotus’ (inclusive of WebSphere Portal) position in the marketplace and will be considered rising stars amongst their peers.

This is a huge milestone for Open Logic and one that we should all be massively proud of. This is the highest level of award that was given out by IBM at this event. It will be further recognised tomorrow morning at the main customer opening session when the winners will be announced to the world.

It seems as though I have been sending a lot of emails like this out over the last couple of years in recognition to our growing stature. This is the 4th IBM award in the last 12 months for Open Logic – anyone spot a trend? The timing could not be better. Going into these uncertain economic times awards like this give us additional credibility with both customers and IBM and are undoubtedly a key part of us opening up and winning new opportunities.

Thanks to Jim at Ascendant for the link…

• I was told off by Dave Hay for not updating this blog in 2 months. He was right, of course.
• I had a REALLY interesting chat with the guys from Alphalogix about their portal and forms solution
• And I bumped into some fun folks from Ascendant and had really interesting conversation about WICA

All in all a really good day. The Alphalogix stuff is interesting because integrating Lotus Forms, WebSphere Portal and Process Server is hard work, and many customers don’t want to go there – so something lighter is pretty handy and welcome.
The Ascendant conversation was good because anything that helps bring consistency to WebSphere deployments is really, really welcome!

A couple of customers have recently been asking about how they can store documents within Portal v6.1 now that PDM is gone. Saying that this is replaced by entitlement to Quickr raises more questions than it answers.

Some people want to store documents for use on WCM website pages; others want somewhere to put their organisation’s files. What do I tell them?

People who want to store documents to refer to on a website – PDFs for download, that sort of thing – find that WCM does the job. One of the ways we often discuss is creating a dedicated WCM library for documents and using categories or other meta-data to organise the files. It’s not quite the same paradigm as PDM but it’s good for this purpose.

Those who’re looking for a document store have more to think about. The good news here is that Quickr document libraries are much better than PDM ever was. There are some good docs in the Infocenter, in the Portal Wiki (thanks Dave) about migrating from PDM to Quickr.

The bad news is that integration with portal is a bit fiddly, especially if you’ve got lots of document libraries or want a seamless user- or manager-experience. Just giving users a view of the places they can access is fine, there’s a My Places portlet for that. However users might reasonably expect their document libraries to appear in the same navigation structure as the rest of Portal; and Manager might expect to be able to control access once across portal pages and document libraries.

Alas in both cases there’s not a great answer yet. We appear to be allowed to use the Quickr API without licencing Quickr (check this, though, I may be wrong) so the best solution revolves around custom development. An extension of composite apps to allow the creation of a document library at the same time as an application instance, for example; or some custom portlets to control permissions over a group of pages, portlets and document libraries. Luckily, the Quickr REST API is quite nice.

On the one hand, I’m not particularly surprised by this because I’m not sure that this is what Virtual Portals were intended for. On the other hand, I’m a little disappointed because I’ve two customers for whom Virtual Portals would solve an important business problem.

This is really interesting for two reasons. Firstly, WAS 7 is the first version of WAS to officially support JEE 5, which a lot of customers are asking for. There are also lots of performance and manageability enhancement in WAS 7, which will be especially useful for larger deployments. That version of WAS was only released 10 days or so ago so IBM really aren’t hanging around bringing in support for this.

Secondly, IBM are distributing the beta as a virtual machine with some configuration scripts. As an architect this is brilliant – I don’t really care too much about the installation process and so I can spend less time on infrastructure and more time figuring the product out.

Luckily it’s a quiet day in the office, so I can set a 6GB download going Here’s where to get it – there’s a portlet factory 6.1 VM too.

First impressions next week some time…

We talked about the reasons that University of London decided to build a portal, what they’re going to deliver there and some of the challenges that we faced along the way. It’s been a really interesting project and I’ve got to grips with some of the Tivoli products that go with portal. The biggest technical lessons have been that an Identity Management solution is absolutely crucial, and that Tivoli Access Manager is about the most useful addition to portal out there…

Here are the slides:

s05 – Global learning portal at the University of London

And here’s a link to the University of London site.

Hopefully I’ll get the time to attend some of the sessions and post here about them…

The most complicated case of this I’ve seen recently came from one of our customers who already uses WebSphere Portal, Lotus Connections and Tivoli Directory Server. They wanted to bring portal up to version 6.1 and start using Tivoli Access Manager, preferably 6.1. Oh, and everything should be at the latest possible level and there should be a single database server. Ouch.

So how to work it out? Can we really get to a totally supported configuration or are we going to have live with a compromise somewhere along the line?

To approach this kind of problem, I generally first lay out the major components and look for their immediate dependencies, usually on a big bit of paper, Infocenter(s) to hand. Then I work through each component in turn figuring out whether I can resolve the dependencies into a single version that everything’s happy with or whether I’m going to have to compromise.

While reaching a totally supported configuration is a fine aspiration, once you start having three or four headline products this can get pretty tough to attain. For some reason this is harder if the products don’t all come from a single software brand.

In this case, there were lots of things to think about. Both Connections 2.0 and Portal 6.1 supported TDS 6.1 but only Tivoli Access Manager 6.1. Both wanted DB2 9.1FP4. However getting the right level of database for Portal, Connections and TDS to use the same physical platform was complicated, because even TDS 6.1 wanted an older DB2 than that…

…and so it went on, all around the infrastructure, until we finally hit on just the right combination of software. In some cases we had to compromise by not using quite the latest version of the software (eg TAM 6.0 versus 6.1). In other cases we had to try out a “nearly” supported version (Connections wants TDS 6.0.0.3, Portal just wants 6.0).

Clearly, if the configuration deviates from the officially supported levels then IBM support can (and usually will) ask you to upgrade. The other lesson is, of course, that if the version dependencies are proving complicated then maybe there’s something questionable in the architecture. Is it really a good idea to share databases between LDAP, Portal and Connections, for example?

One thing we also noticed was that new products’ Infocenters are quietly updated without much fanfare. It pays to keep your eyes on them, especially when you’re working in the first few months after a product is released.

So it was with great interest that I attended a presentation today by Andreas Brunnert from the Boebligen lab about the portlet container that’s now part of WAS 6.1 and, soon, WAS 7. This offers an interesting solution to the above problem. The portlet container in WAS could be used to distribute load from (expensive) portal servers to (inexpensive) application servers.

Another interesting consequence of having the portlet container in WAS is that stand-alone web applications can now be developed against the portlet API. That means that developers who don’t want portal can have their cake and eat it – all of the richness of Portlets’ state and context plus not having to worry about where the application will be deployed – portal, WSRP or stand-alone.

The portlet container in WAS also provides an interesting option for unit testing new portlets, at least partially. Maintaining developer workstations with the right level of WAS and WebSphere Portal is quite a challenge, and there’s always someone in the team who can’t compile this or that portlet. Having a WAS image and using the URL Addressibilty to access the test portlet would simplify the platform that the developers have to handle.

On a related note, I spent a very short time looking for a WSRP producer for .NET. I’ll have to ask my .NET colleagues but I wonder if wrappering .NET applications using WSRP might not be a way to handle migration and coexistence between the platforms.

From Andreas’s presentation, I also noted that portal is moving towards being a more “traditional” WebSphere Application (much in the way that, say, Process Server is). That’d be nice, too.