Wednesday, August 08, 2007

Are portals like death and taxes...inevitable?

In-house development vs out of the box

Ever since I learnt HTML in 1997 from a couple of printed out sheets of A$ I have supported more of a DIY approach to things and at the same time been a keen advocate for good best practice. around development standards, and accessibility/usability etc.

My feeling was always around why spend millions on something you can build yourself?

As I have worked with and for increasingly larger organistations this approach has started to seem unmanagable and increasingly invalid.

The key issues:

  • Inhouse development seems to take just as long and cost just as much as 'out of the box' (or out of the b=box with a bit of customisation.
  • Just because you have standards doesn't always mean inhouse development meets them
  • Inhouse development involves a degree of wheel reinvention if the proper structures and development practices are not in place or followed. (even in very large software houses this is not always the case).
  • 'Portal like' software is getting increasingly flexible and functional (and IT people really love them).

It's the last point I'd like to expand further.

Enterpise protals vs portal development platforms

Now putting aside the contentious use of the word portal (an any actual meaning), in my experience there are two types of portal software.


  1. Proprietary enterprise
    The big enterprise type of systems (Peoplesoft portal, Sharepopoint being two of these). They are characterised by being integrated or developed around previous proeducts in a vendors catalogue and tend to do a lot out of the box (not all of it well) and also tend to be less flexible around the presentation layer (look and feel, site structure, accessibility standards etc). It does generally mean there is less need to employ developers as most functionality is already built. They are starting to offer SOA type of approaches but they are still more restricted than other approaches.
  2. Flexible development platforms
    The other type is the more development platform (BEA weblogic). These tend to require developers to develop base artifacts to be reused. The systems come with already inbuilt functionality but it is relatively easy to build new functionality as they tend to be built around an open web services approach.

My organisation is currently exploring several different platforms (as well as using several... which of course poses many difficult scenarios) but for the 'intranet' I really see approach 2 being far more effective (given my general stance as mentioned at the start of owning and controlling development).

It gives organisations more flexiblity in displaying and managing content and functionality and also the ability to control the base code of development (thus accessibility) more than the proprietary systems.

User demands not being met

User demands are increasing (mostly around workflow, intregration with existing data systems, personalisation of content) more rapidly than most organisations have the ability to meet those demansd and thus in terms of good buisness it seems logical to take on board at least good solid SOA portal development approaches to be able to better meet these demands.

So while I still hate the misuse of the word 'portal', and dislike that the multinationals have hijacked the word, and hate that vendors oversell their products, the 'portal solution' of any colour/format/platform is likely to be part of the enterprise of the future if not fully realised as of yet.

I also see open SOA standards being a key player in this development.

I also realise that 'portal' hype has decreased over the past couple of years (generally it has been migrated into the wider enterprise 2.0 hype) I think this is because many organisations have simply changed their web development practices to be 'portal'/SOA like, rather than from scratch as had to be done in the past.

I think the postives of moving in this direction have started to outweigh the negatives.

Labels: , , , ,

2 Comments:

At 3:36 PM, Blogger Greg said...

Show me the evidence!

And I endorse your dislike of the way the word "portal" is used in the IT land. I've had many developers suggest building a web portal to me in recent years, yet when I try to find out why that would be a good idea, what problem it is trying to solve, they seem strangely silent on a good business reason for doing it. Plenty of geeky, .Net reasons, but nothing our users actually want.

I keep hearing how much better Sharepoint 2007 is than previous editions, but have yet to see the evidence. Is there any?

 
At 1:55 PM, Blogger Nick Besseling said...

Thanks Greg.

I guess I'm trying to separate the old vendor portal software stance from the flexible 'portal like' SOA style functionality.

Sure any good developer can do this but in my experience its proving to be far more effective in getting out of the box software (based on some open standards) to deliver some of the functionality for an intranet rather than spending months and months in projects for bespoke development.

I should probably change this post to 'Is portal like functionality inevitable ?'. I think many of us have been doing this already but we now need to do it faster as users get more savvy on what's possible.

 

Post a Comment

<< Home