Tomorrow I’m reviewing an upgrade approach with my technology team (the one I used to manage) for moving the PeopleSoft Enterprise Portal from 8.46 to 8.9. I need to dynamically mix transactions and content with awareness of context, person, function and process. Having measured the delivered functionality against my needs for almost a year I’m pretty sure that I’ll decide to pass.

I’ve been in a love/hate relationship with this product since I deployed 8.3 three years ago. From the very start we needed to modify it to do things that it can’t easily do. I run one of the largest implementations on the planet and have pressured Oracle to be more forthcoming with me about the road map for the Portal line and Fusion, but I don’t get a lot to go on.

Right now I have a very expensive, slightly intelligent link farm. Bottom line is I’m not inclined to take the time and budget for an incremental upgrade that isn’t going to bring me a whole lot of business value. The most likely scenario for 2007 is I’ll tweak the UI and look to replace it entirely in 2008-9.

I started to reply to DoubleDubs’ post: Melting Pot or Salad Bowl part 2 but I got so verbose I figured I better put it down here. Go read his originals, then come back.

I have a dozen or more vendor products in the mix, each with their unique UIs and generally poor ability to integrate via any method, not the least being a services architecture. I love the food analogy, but I tend to characterize what I want as being like Amazon. It’s a sure bet that they use content management, media distribution, shopping cards, credit clearance, inventory, their famous recommendation engines, user profiles…you get the idea. Yet at the UI layer it’s a single, seamless product. It had better be, because if they can’t get me to that last click they don’t get revenue. We don’t share that imperative, but we should. Then I wouldn’t need to take 2 hours of training before I can use the darn thing. Granted, we are more familiar with the shopping domain than with the employee transfer domain.

So do we need specialized interfaces? They are a Good Thing in may cases. You wouldn’t want to use Photoshop or a Playstation with a mouse or keyboard. I support specialization and at the same time reject the idea that a specialized interface has to look unique.

We have almost 40 internally developed point solutions. A few of them are big-ticket global apps and many others are specialty items for a particular line of business’ unique needs. We just finished developing a set of interface and design standards for all of them. We developed a framework and then the UX team went through a ‘skinning’ exercise to ensure that we could apply the standards regardless of the interface we were dealing with.

This is not a melting pot. It’s more of a family resemblance. And it’s an important step towards aligning ourselves to the state when we stop being application-centric. Right now I have business managers, analysts and developers who live in their own silos. They know the rest of us are out there but it’s not their problem, they know their function and that’s what matters to them. By introducing the notion that they don’t get to design their UI independently, we begin to get them to look around and notice that we look alike. It’s an appetizer, meant to pique their hunger for the next course while delivering some real value for the consumer.

I want to get us completely away from application-centric thinking, but honestly nothing can support what I want to build yet. The vendors have to catch up to SOA and so do we with our internal apps. I know this is true because we are using services and SOAP for some of our integration functions. It’s still immature, and I fear that that our vendors worries disintermediation results in partial solutions for a while to come and a lot of custom work on our part. In the meantime, I hope we’re making it easier by going to standard interfaces where we can.