I wanted to finish the thread that I stared in my last blog before I go back to more technical issues. I'm currently playing around with the preferences validator in JSR 168 and I think that will be interesting for my next entry. For now, let's complete this issue.
It is generally accepted that business requirements should drive functional and some nonfunctional requirements. The business doesn't want to pay for functionality it doesn't need or want, and likewise it should get the most bang for its buck in terms of portability, scalability and all the other 'ilities that are needed. However there are still many nonfunctional or rather organizational or architectural requirements that need to be determined, either at a project or an organizational level. For these issues I'm always a bit wary of the driver behind them and the value they may bring.
For example the use of Struts in portal sometimes concerns me. (Before the Stuts people start to feel picked on, let me explain.) There are solid business and financial drivers for using the Struts Portal Framework within WebSphere Portal. "Because it's cool", or "I want to learn it" is probably not one of them.
During any project I have a very simple frame of reference. What is it going to take to allow me to deliver this application within the given time frame and within or even under budget? In many cases the team is new to WebSphere Portal and J2EE technologies, and reducing the complexity or layers within an application and taking advantage of what is available within the portal framework can help now and as the application evolves.
I like the idea of creating standards across a project, or better yet, across your organization. The use of something like Struts can fit well within this ideal, but here again, there may be many exception cases. Is it going to cost you more in initial development, ongoing maintenance, and even future upgrade headaches to implement within these guidelines? Portability might be another reason to take this route, but it is probably not realistic to think your code will port seamlessly across platforms just because it's based on Struts. This will be more of a problem if you want to take advantage of specific portal functionality within your code.
I have the same concerns around some of the methodology's that a team sometimes want to use within their project. Some teams get really excited about using the Rational Unified Process and all the tools that IBM Rational can provide to assist in this area, or maybe they want to go another way such as using EXtreme Programming. With anything of this nature, your first question should be, what is the experience of your team? Are they skilled in these areas or are you willing to make the investment to get them to the level they need to be? Secondly what are your immediate needs. If you have to deliver a portal very quickly then many short-cuts will be made. How will this affect your methodology strategy?
Fortunately, many organizations are on the right track to seriously evaluate all the options and the value they bring. This provides the advantage that, either the requirement is really warranted, or the organization is willing to make the effort to ensure the team has the tools and training they need to do the job correctly. Don't think I'm against developers or teams learning new things, that's how we get better and continue to improve our processes and projects. However, learning at the expense of the project delivery date or capability should be weighed heavily. Trust me, build a few portal projects and the learning will come. : )
Development Requirements and Business Value