Blog of a Boston-based IT Consultant

I have worked on several “portal” projects in my career. Here is a list of the ones that I can think of right now, at the end of a very busy week:

1. A portal to allow Union members to check on their benefits, file grievances, and essentially do whatever we could allow them to do via the web in reference to their Union membership

2. A portal to allow an organization to manage all of its content, publish it to different websites, spawn new websites based on predefined templates, and create reusable tools for the “children of the portal” sites.

3. A portal to allow salespeople and store owners to keep inventory, sales, and company-related documentation and metrics up to date in order to streamline, simplify, and centralize business processes

4. A portal that functioned as a dashboard for a collection of Real Estate agents who were managing the same properties and responding to the same sales inquiries

These sites are all very different. The most complex was the second one because it was built after a lot had been invested in the conceptualization of the “child” sites and the organization sponsoring the project was committed, totally and utterly, to seeing that vision through via the portal. The portal was seen as a natural way to organize something that would otherwise require some repetitive effort. A good CMS could have done this as well, but they had other goals that it is not important to get into here.

But then, what is the same between those four projects that allows them to all be called “portals”? They all have a particular context. The term “portal” is often ambigious, chiefly because it is a term that has been adapted from common language and made specific to an aspect of technology. It is the latest meaning that has been added in the Dictionary definition of the word. A portal is an entrance. None of the aforementioned projects stand out as an entrance. They stand out as a collection of contextual functionality.

Now, I hate when people do this, but let’s look at what the Dictionary says a portal is:

por·tal1 [pawr-tl, pohr-] –noun

There it is, at number 4. Our portal definition.
Most clients talk to me about a “portal” and have heard the term used in the context of I.T., but have not actually seen this definition. They see it as some sort of web-based home page for everything that they want to do as a person, an employee, a luge enthusiast, and any number of things.

In many ways, it is a personalized home page. However, that is far from all that it is. The meaning has been extended to mean a place where functionality with common or complimentary context is presented. iGoogle is a portal of sorts. MyYahoo is a portal of sorts, and the Union’s website is a portal of sorts. A portal’s definition is given by the scope of it’s context.

So in the second portal I mention having worked on, it just so happens that the portal contains functionality to create websites from rough templates. This is a valid portal, as is the portal that allows Real Estate agents to communicate with clients.

The interesting part of portals, besides the fact that they create very niche-oriented homes for sets of Business and Functional Requirements, is in the process of defining the System and Functional Requirements.

It becomes partly a matter of Information Architecture when you are developing a portal that must have children. If I have Functional and Business Requirements for the children sites, do I take those and use them as my founding Portal Requirements, or do I attempt to build a Parent Portal first, then accomodate the children?

It is not a trivial question. If we start with the children sites, it may be that time constraints mandate that non-essential functionality is cut from the project scope. It may be that functionality not common to all children is cut from the first portal iteration. More than likely, if projects with momentum are spawning the idea of a portal, time will be an issue because the project started long before it was actualized in the form of a portal.

Ideally, we would start with the Requirements for all features of our portal. If this includes the ability to generate websites with unique content and functionality, than we would have to build that ability into the portal scope.

When we are developing a portal that will include the ability to spawn distinct sites, functionality that does not require customization (maybe a login procedure) helps minimize development time, scope, and cost. We only have to develop it once and can reuse it across sites.

However, if one of my sites needs to have drag-and-drop page elements and no other do, we are doing a lot of work to accomodate that one site. Ideally we would do it at the Portal level so if a site comes along in a few months that requires the same drag-and-drop functionality, it is there ready to be reused.

In this scenario, the places where the “child” sites do not resemble each other are the places where the most significant work (and the most debate) will occur. Not only do we need to do a different kind of scoping, we need to build the functionality to be forward-minded and extensible. Or at least, good OO theory would have us do that. And of course, before we do all of that, we have to show a solid Business Need to justify the custom development.

A portal is not just a home on the internet. It can be a toolbox of sorts or a number of other things.

I have found that when you are developing a portal, it is best to establish a good set of Functional Requirements, working from the ground up instead of working from the top down. This is hard, because most people will try to envision the portal as a whole.

Walk your users through what they want to do. Interview them and see how they envision using it. Make “Barely Good Enough” Use Cases or Use Case Diagrams if you can get away with it, and see where the overlap is. Chances are, a bit of natural negotiation will occur and while site A might want to do something *this* way and site B might want to do something *that* way, it becomes apparent that *another* way is easier to develop, easier to use, and actually - closer to what the users really want.

The functionality that is not shared across sites falls into a different model. We have to look at it as we looked at the portal. What is it that the functionality is accomplishing? What are other ways that we can imagine accomplishing this functionality? What does it resemble? Can we build it so that it can be customized, or is it truly a “one-off”? If you are using something like Ektron, Joomla, or SharePoint, do they offer any OOTB functionality that can be leveraged? This is where a lot of money gets spent in development and risk is assumed. It is no uncommon for scope to change, and if you put 300 hours into developing something custom only to have that custom functionality removed from your scope, you just lost a bit of money and time.

If possible, you can also phase releases of this kind of portal. Start with what is common. There will be Discovery during development just like there was Discovery during Discovery. Software projects rarely exist in a vacuum. By phasing the portal, you can allow time for ideas to mature and change. Once users see V.1, they may see a natural extension of what you have built that will satisfy their requirements for something custom.

Use Cases should be generic and built as though the platform has not been determined yet. Do not box your developers in, and do not commit to any technology in your Use Cases. In a project involving a portal, this is especially important, because Social Networking and Collaberative Software is an amazingly dynamic world to be in right now. What you spec today might be light years behind tomorrow. This is always the case, but a portal requires users to partcipate for it to have value. Again, extensibility is vital. The ability to have to portal function cross-platform is becoming increasingly important, with portable device use and portable device users becoming more demanding.

When you are developing the functional parts of your portal (portlets), you should keep it in mind that these mini-applications often function best under the “less is more” model. If your portlets are providing functionality that is not UI-centric or graphics-centric, dont forget about your Web Services and dont forget to have an overall data model that accomodates them. It is easier for a lot of portable devices to swallow portlets than to swallow entire portals, and Web Services communicating with Web Services communicating with Web Services becomes more simple if your apps are developed simply, sleekly, and with open architecture - a simple WSDL.

There is an emerging standard for applications that aggregate functionality such as portlets. I always think it is a good idea to develop according to standard, even if your specific implementation is entirely unique.

Another kind of interesting thing that happens during portal brainstorming sessions and the weeks that follow is that folks hear about a “portal” being developed and they want to see if you can give them access to their gmail through it, the weather forecast, do videoconferencing through it, and any number of things. Some people will be offended if the “Corporate Portal” does not take their unique request to heart. A good technique is to have a formal meeting in which you establish the business need for each scope item, and simultaneously creating a list of items that will be held off on until V.2 of the portal comes around. People are much less offended if you do it this way, and will often want to stay in touch with the effort so that they are there when V.2 scoping begins.

In conclusion, regardless of what your portal will be used for, it is only sensible to start from the ground up and capture user requirements, mandate elucidation of the business need, and keep the larger picture in mind. Do not let emotional investment in any particular feature outweigh the business need of the project as a whole.

- Josh Milane

MIT Technical, Boston

Project Management | RSS 2.0 | Comment it , or trackback this post.