First, very strict guidelines were given that didn't take the portal capability and best practices into account. It was assumed that the software could be made to fit within the given parameters, and
second, the developer given this task, simply took the requirements at face value that this was how it had to be done.
So who is driving these requirements?
- Business, Marketing, Design, and Information Architects should probably be driving the look and feel, user interaction and the actual functionality of the application from a users standpoint.
- Architects will define underlying product set, interaction, scalability, and organization requirements.
- Specialists will need to design the actual application based on the above decisions.
It has to be made clear that this should not be a one-way process, rather an iterative cycle using some type of feedback mechanism, or by introducing technical folks into the project life cycle early. If an architect is at a technically deep enough level with the product or technology, then they can often provide this guidance and assist the developer through how it should be done. Often this is not the case, and someone with deeper skills in the product suite needs to actually provide information, in real time, to the rest of the team about decisions. This goes for Business Analysts, Marketing, Designers, and others who are making decisions which can affect the technical outcome. Working with an Architect or Specialist who is knowledgeable about the Portal framework and how to best take advantage of that technology can great increase your chances of success. Or at least reduce the number of problems you may face. Enterprise standards often have to be revisited when introducing a portal into your environment. In some cases exceptions need to be made or perhaps additional standards that take the portal into account.
The simple moral here is to ask questions and speak up as early as possible when designing your portal. Ask the Portal SME on your team if a specific decision makes sense. Then give that person some time to research the answer and maybe offer some different solutions. What? you don't have a Portal SME on your team? Then shame on you. If this is your first portal project then, more shame. The expense of adding an experienced member to the team can well outweigh the cost of a failed or troubled project. Developers are not blameless here either. It is important that developers speak up when they see potential problems or know that something has been poorly designed. Remember, not only do you have to build it, and deploy it, but you may have to maintain it in the future.
Look to my next blog for a continuation of these thoughts and a discussion about the trade off between adding real business value and wants...