I was having a discussion with Eric Nelson on his blog the other day. I was having a rant about requirements, which I think is one of the most vital aspects of software today.

For instance, I've been told by a number of developers that MVC is the 'correct' way to develop a web application. However, I disagree strongly with this.

I don't doubt that Model View Controller is very useful for certain applications. It is a valid design pattern for solving certain problems.

However, it's not 'the correct' way to develop a web application. The only thing that is correct is the requirements. If you use MVC, and it either hinders achieving the requirements, or it adds nothing to those requirements, than MVC is not the correct design pattern to follow. Simple as that.

There have been similar patterns used in security that added no value. I worked on a project three years ago that used WS-Security, because it was the latest 'cool thing'. At the end of the day, it added no value, as SSL matched the security requirements more efficiently.

So, when should you use WS-Security? I wrote an article recently that is on the MSDN Developer Security page.

The article matches requirements to technologies, and has been used by various clients as I was writing it. I hope you find it useful.

Hmmmmm......

Most of the time, when your application is accessing web services or databases, it's done within the same datacentre, right? This means that it's not a problem using network layer security (IPSec) to protect any data in transit across the network/subnet.

But what if you're accessing data across a MAN or a WAN? With the enormous bandwidth available now, this is happening more frequently. Also, what good's designing functionality as a service if it's only available to servers on the same subnet?

Well, the problem with applying network layer security is that accessing data across a MAN means that a huge amount of encryption power is required. Many hardware IPSec solutions become problematic and expensive as they reach 1GB.

Also, we've got MPLS to support over a fully meshed network, with the problems that may entail.

The result is that you, as a systems architect, may not be able to rely on the infrastructure people simply creating an IPSec security association for you.

That's right - security has made another step to the application layer. SSL should be fine, but don't rule out tools such as WS-Security.

No longer can architects rely on just annotating the link between the web app and the database with the words 'IPSec' and think that's enough.

And don't just think it's all covered by the magic words 'data security'!

Ian Cooper, a developer who I respect very much, wrote an excellent article on agile and documentation. He states that documentation is clearly a part of agile development methodology.

Agile may favour lightweight documentation in many circumstances, but it is still a prerequisite. I've seen agile methods used very successfully with condensed documentation for a very large enterprise scale application. I've also seen agile used with very heavywieght documentation for a mission critical app using Telelogic DOORS.

One of the most annoying things in my current work, within a large Information Security team, is when a development team tell me "we don't have any documentation, we do Agile!". So how do we meet compliance requirements here, where we have to give assurance that standards have been applied to both process and application?
Well, I went to a conference recently where an agile evangelist declared that compliance is an outdated concept.

Fine. The bank I work for is thus outdated, as without compliance we're unable to trade.

Seriously, we use agile, and we do documentation. The agile team I mentioned earlier were told to go back and write some docco if they wanted their app to go live.

The point was that some people think that agile is an excuse not to do documentation.

I feel it's starting to go further than this. We're actually losing the practice of SOFTWARE ENGINEERING. Software engineering is where we do everything for a reason - all that we design, code, test is related to requirements.

Ten years ago, the 'software crisis' of increasingly unmaintainable code was attributed to programmers not introducing comments to their code. A couple of years ago, with some misinterpretations of agile, it became common to have applications developed without detailed design, component design etc.

I worked on a project last year where I was told that " we don't document requirements, because we use agile". Good grief! Agile is a methodology for MANAGING requirements. If you don't document them, then YOU CAN'T POSSIBLY BE DOING AGILE!

Where do we go next? In a few years' time, will we not even need someone to approve/describe a PROJECT before we start coding?

What are you developing? I don't know, we do agile.......