New technology - If you don't adopt are you untrendy?

I could have called this "The anti-pattern of choosing new technology" but decided against it in the end.

That probably gives you readers and idea of what I'm talking about in this post.

There are a lot of questions that I read that go something along the lines of "If I choose technology x, how would I make it work with the following scenario...". Spot the obvious mistake there?

The architecture always comes first, then start simple, and work to the more complex, or unknown solution, as requirements discount the most simple ideas.

If more architects of systems thought like that, certainly a lot of the work I have done over the years would not have been necessary. Somebody believed that a particular technology did something in a particular way, pushed it a little harder, and found that they were too far down the implementation to pull back, as the technology no longer fitted the requirements at all.

A case in point, and the forums are flooded with questions surrounding it - is LINQ. Don't get me wrong, I have nothing against the technology at all, it is great, in the right place. Honestly though, unless you have a very good justification for using it, it's quite probable that the old data reader / data adapter and sprocs is going to be a simpler and more understandable solution.

My problem with the technology is that it uses some logic to try to get the best performance out of a query - it's good, but I'm afraid, it isn't as good as me. What I mean there is that you have little control over how a statement gets implemented, so how can you possibly tune it? That for LINQ to do, right? So long as it does, that is fine.

So if you're starting out designing applications, take a bit of advice, and keep it simple, understand the technology fully before using it in big commercial applications where it ends up needing o be worked around.

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.

Generalised, Generic, Configurable frameworks. Worthwhile?

My opinion is no! I don't think that frameworks should be so generalised, as to not be able to do anything particularly well.
Generally I think, these sorts of frameworks are overengineered. The reason?
Well, what is the point in designing some framework that can be applied to literally any situation, but requires so much configuration and tuning to make it work at all? That doesn't seem useful to me, it seems like a headache! I'd say that this comment is especially relevant if you consider the situation where a framework can do all those different things, but in reality is only ever used for one very small and specialised set of tasks.
Personally I think it's a much better idea to implement a test driven approach, or at least one that includes proper unit testing, then you implement what you need, and refactor to include those "future features" as they become requirements.
Using proper OO, using interfaces and the like, and good designs should allow the refactoring of the code, to extend and expand it to fit new scenarios.

The big difference is that the solution then only implementing what it needs, and is therefore more likely to be tuned to those tasks, and be easier to maintain, and better performing to boot!