Achieving reuse with web portals

When I ask, what to expect most from a web portal, ten years ago I would have received the answer “Single-Sign-on”. Nowadays, the answer is “Increase time to market by reuse”.

So, reuse is the word. People don’t want to reinvent the wheel (which is good). And people expect portals to achieve that virtually automatically. This expectation is doomed to fail.

But first, what is a web portal after all? Basically, portals are a technique for integrating applications and content (s. picture) in the front-end, meaning: at the GUI level. That’s what sets portals apart from other integration technologies like shared databases or messaging, which operate on other architectural tiers. Anyway, we should remember that portals were thought to work on GUI level.

Portlets and portals don’t know anything about reuse, meaning that there is no “reuse” property built inside them. But that is exactly what – at least to my experience – people expect them to do. Even worse: portlets are no “building blocks” for applications and were never meant to be. They are elements of a portal user interface, which are based on some (very deeply technically defined) standards. This means, there is no concept of deconstructing an application into portlets. There is no “standard” how to do this. Although technically GUIs can be decomposed into portlets (which can make sense), they don’t help when you are facing problems like where to place the business logic, how to build reusable “business components” and how to communicate between them.

But, if portlets on there own can’t help – what can? Does it make any sense to use a portal? This question is important, because in some cases, it may be more appropriate to create a “simple” web application instead of using a portal product. This is a serious choice, since using a portal platform comes with a price: the developers not only need to know all the basic Java and JEE technologies, but they also need to have decent knowledge about the respective portal platform and they need to come to grips with a “utilization concept” of the portal. This means, they need to understand how to employ the possibilities of the portal best in their current business situation.

Nevertheless, using a portal can make sense, above all when you already have or want to build more a set of business applications which share an overlapping business process or which share parts of the user interface. If they only share parts of the logic, it’s no point using a portal, because portals work on the user interface, remember? This kind of reuse goes by the name of "platform reuse" (cf. picture) and can be achieved with a portal. But, it does not establish itself just by using the portal - you have to develop a concept how to use the tools given to you by the portal and how to use them on the respective applications.

Reuse with a portal platform

Given you decided that you still want to use a portal – we now have a first general rule:

Guideline No 1: Always search help from a portal expert – somebody who already built portals of comparable complexity and who knows about the possibilities of the chosen portal framework.

The second rule is even more important, especially when you want to achieve better time-to-market:

Guideline No 2: Establish a concept, a process and an organization to foster reuse. Always consider business and technical concepts for reuse.

And that is my bottom line here: reuse cannot be achieved by a portal or by any technology on its own. You always need creative people to think about it and to take initiative in order to get reuse right. Super duper portal technology does not resolve the reuse issue for you. You have to sit down, work out a concept and then implement it. Again, there is no silver bullet.

Let’s look at an example: you have two applications which share some functionality, say the lookup and presentation of a specific product. The search dialogue in the GUI is similar, the lookup logic is nearly the same, and they just work on different parts of the product catalogue. Also, the presentation of the product in the GUI is nearly identical – only the texts, icons and images are different. Although there is big similarity, you wouldn’t achieve any reuse just by using a portal. The programmers could be lucky to recognize the similarities but they would not take the extra time and effort to make all the code reusable, since they always are under pressure to meet the next deadline. Believe it or not: you won’t get reuse all by itself, without doing something for it. In our example, we have to set up a team, which reviews the business requirements and recognizes the overlapping parts in our search process as described above. At that point, a decision has to be made whether to invest in a reusable component “search product” which could include one or more reusable portlets. Time and money have to be invested – and we need a team which is capable of designing, building and maintaining a reusable component. Once you own this reusable components they will help you to free resources from re-inventing the wheel, they will help you to incredibly reduce your time-to-market and will give you an overwhelming quality boost.

So, products provide the basic means by which reuse can be achieved, but it still needs the right people to bring that possibility to life.