Category: Software Architect

I overheard some people deciding that they need more layers in their architecture. They were right, as it happens; but going about it a little backwards. They were attempting to create a framework that would contain the business logic. Rather than solving some specific problems they started with the idea that they want a framework that wraps the database up and produces objects. And it should use object-relational mapping. And messages. And web services. And it should do all sorts of cool stuff.

Unfortunately, since they didn’t exactly know what cool stuff it would do, they didn‘t know what to call it. So they held a little competition to suggest a name. And that is the point at which you must recognise that you have a problem: if you don’t know what a thing should be called, you cannot know what it is. If you don’t know what it is, you cannot sit down and write the code.

In this particular case, a quick browse throught the source control history revealed the depth of the problem. Of course, there were lots of empty interface “implementations”! And the really funny thing is that they had already changed the names three times with no actual code. When they started they called it ClientAPI — the “client” refers to the customers of the business, not client as in “client-server” — and the final version was called ClientBusinessObjects. Great name: vague, broad and misleading.

Of course, in the end, a name is just a pointer. Once everyone involved knows that the name is just a name and not a design metaphor then you can all move on. However, if you can’t agree on a name that is specific enough for you to know when it is wrong, then you might have some difficulty even getting started. Design is all about trying to fulfil intentions — e.g., fast, cheap, flexible — and names convey intentions.

If you can‘t name it, you can‘t write it. If you change the name 3 times, then you should stop until you know what you are trying to build.

Have you heard of a judge who wasn’t a lawyer; or a chief of surgery who wasn’t a surgeon? Even after they get to what some would call the pinnacles of their career, the people holding these occupations are still expected to continue learning the new developments within their respective fields. As software architects, we should be held to the same standards.

No matter how well designed a solution is, one of the most important factors for determining the success of an implementation is getting the developers to sign on to the game plan. The quickest way to get the developers to sign on is to gain their respect and trust. We all know the quickest way to gain a developers trust: your code is your currency. If you can show your developers that you‘re not just some pie in the sky day dreamer who can‘t code his way out of a paper bag, you‘ll hear less grumbling about the hoops you‘re “making” them jump through to get data to show on the page when “I can get it done in less time by just binding a dataset to a grid.”

Even though I‘m not required to as part of my job, I will frequently pick up some of the more intricate tasks. This serves two purposes: first it‘s fun and helps me to keep my development skills sharp; second, it helps me demonstrate to my developers that I‘m not just blowing smoke where the sun doesn‘t shine.

As an architect, your primary goal should be to create a solution that is feasible, maintainable, and of course addresses the issue at hand. Part of knowing what is feasible in a solution is having knowledge of the effort involved in developing the elements of the solution. Therefore, I propose that if you design it, you should be able to code it.