Architecting solutions based on all the requirements

Gathering great requirements from business analysts is one thing, finding requirements in an existing legacy system is another. The former implies a possible new development, the latter implies an existing system.

So many questions are asked, in forums and the like regarding new developments, and using the anti-pattern of redeveloping with new technologies, patterns seems commonplace, and yet it also seems that very little weight is given to that existing system. You don't hear of many people immersing themselves in that system, finding out what the real problems are, and testing against those problems to provide a more useful solution.

It seems to me that more weight is given to using in-favour design patterns, and new technologies such as WWF, WCF and WPF over whether the re-development of the legacy system is even cost effective, or provides any benefit.

Our proof of concepts should be an end-to-end solution that cover all aspects of the system, including those difficult areas that we want to avoid, as well as the 'buzzword ridden' layers that prove nothing that you don't already know.

Consideration of complete, end to end solutions, including as much functionality as is conceivable is going to leverage that proof of concepts' worth, and provide a good benchmark for timescales and cost benefits, as well as giving insight into areas of high risk and potential problems.

I know this bit of text seems to point out the obvious, but from my observations, that point clearly is not being taken on board.

We need to focus on business value, and the ability to make software solutions perform in a way that enables our clients businesses to succeed, instead of producing systems with all the latest technology, designed is a really complex ways that does nothing really well, and most things quite badly.

You boss is your client, and you client judges you on how well you perform, not how many acronyms you can place on your Curriculum Vitae!

New Architecture for legacy systems

I don't know what it is, but so many architects that I meet in the various projects in which I work are so focussed on writing new solutions with new technology, that they often completely miss the problem in the first place.

I've seen enthusiastic architects often propose solutions that replace the easy part of the solution, and make it "better" (when often it isn't broken) and then not even attempt, or only partially attempt to address the real problem.

Our anti-pattern is to replace all this stuff we currently have with new stuff, and still have the same fundemental problems as before.

Why instead, can't we take much more of an agile, iteratative approach, and replace things little by little, and slowly move away from one solution to a more mature one, without once putting all our eggs in one basket with a particular "buzz" technology?

What this whole process often involves is moving from one bad decision, to a new bad one, or worse still starting implementing a solution with a new technology, that by the time it is finished, is an old technology, and we iterate with the same.

To my mind, architecture is more about an approach, a pattern, that is agnostic of the technology that may be used by it. If we work toward a solution that looks like a pattern but instead uses a particular technology that completely undoes that pattern by coupling everything through the technology, then it seems a completely useless and expensive exercise.

A big area that seems to suffer from this particular ailment, is SOA and the web service based solutions. Often, I hear that the reason for choosing a web service based solution is because of a need to make that solution available, particularly to other platforms. Later, I find out that the solution is intranet based, and could have been implemented a lot better without the need at least initially for web services at all. We then get hacks based on that concept to achieve various things, largely borne out of the need for "cool" technology. Things such as WSE are such an example. Whilst there is defintely a place for these technologies, that unemotional choice is often not correctly made, in favour of a curriculum vitae boosting entry instead.

There really is a good case for technology aware-but-agnostic architects out there, my experience is that they are few and far between. An architect should be exploring all possibilities, rather than a set that suit their purposes, or career.