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.

Separation of Concerns

Here's the thing - recently I put together some questions to use for interviewing, and one of the questions on there was simply what was "separation of concerns".

None of my team got that question right, although some of them are quite experienced, but all of them told me that this was a dated question that will only invite a textbook answer.

The point here is that a good design has good separation of concerns, and is coherent, but what does that mean? Simply put, a subsystem with a particular responsibility performs only that set of tasks, and no tasks for other subsystems. It's a little like the normalisation rules for databases, that the key must refer to all the data in a table.

This poses a couple of immediate questions, what happens when you have a Person subsystem, and want to get the addresses that that person resides at, without making a chatty set of calls?

There are a few approaches - if we're talking services, then the service call is very granular, and uses a DTO in effect to transport data from multiple sources. In the backend, the multiple source are nicely separate.

If the problem is considered from the backend, the Address subsystem would have to be injected into the Person subsystem, and vice versa. In this way you are delegating responsibility to the correct subsystem, however, this could lead to many calls to the database. Do we care? Well, we might do if the data really does have to be realtime, which is wouldn't in the given example above.

The final implementation would be to implement functionality (a PersonAddress nested subsystem within Person subsystem) or an AddressPerson nested within the Address subsystem. These would have a very different focus, or context, but the code is quite likely to be repeated in both. I guess that final point is similar again to the database example, in that generally you should start with 5th normal form, then work backwards to compromise redundancy against speed. Same with coherence, but it is "separation of concerns" versus maintainability.

Need help with architectures, or coding?

Hi,

If you need help with requirements, architectures, development code and the like, leave me a comment in here, and I'll help you out.

Cheers,

Martin.

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.

Architecting High-Performance, Reusable, Granular Services and SOA.

Sorry people, but I don't believe the above is really a good idea at all.

You cannot write granular services that can perform well, in general. It's a shame that the selling point of SOA has often been this concept of re-usability... It is not! It is availability. You can access the service from many platforms, or that's the idea at least. The more technology specific the extensions you add to a service, the less you leverage the true power of SOA.

Managers particularly get to hear of SOA, and think of it as a great concept that will cut costs, save money and time, and generally be the answer to their prayers. Whilst it may be the latter, the other parts rely on an understanding of the technology. Writing services and expecting them to perform well, and be re-usable isn't going to happen, because in general you want your services to be quite specific to the problem that they address, to make them perform well.

Obviously if performance isn't a consideration, you'd probably be able to get away with granular services, but not for long! How many systems have you seen that started off as a few macros running on a users desktop application, and then becoming the company software platform, and having to attempt upscaling the solution?! What I'm saying is, if you're writing services, then that of itself should mean that the problem domain is complicated enough to justify the effort. don't do it, don't come up with a bunch of services such something to get a bunch of person records, then get a bunch of address records for a given person. Then you're going to try to munge them together, right? Please tell me you're joking! The whole process is over-engineered and would require so many workarounds that it's just not funny! Although I did have a giggle myself...

It's a much better idea to look at what you need, and how fast that needs to realistically perform, then come up with a solution that fits that requirement.

Generally speaking, distributed architecture means that you should be calling the backend only once if possible, to get better performance. If you're combining and consolidating services in the backend, you're introducing overhead and complexity that really isn't needed.

Can I get an Amen?!