Architecture vs. Design

I recieved an e-mail from a client that I hadn’t heard from in a while. I did some consulting work with them on their first .NET project. Apparently it was a “big success”, but that didn’t surprise me because the the folks where were pretty sharp and they worked well as a team.

Was web-services worth it?

On reviewing the finished product my client made the observation that layer of web-services that seperated the user interface and the underlying database.

That isn’t too unusual – there are a few different reasons to employ web-services in a solution. One is to enable you to tuck away complex or proprietary logic while another is to remove the need for client applications to connect directly with databases and accept all thos licensing, scalability and security implications. If the only reason that you implemented web-services is the later, then you will likely end up with a pass-thru CRUD-like implementation. This is especially true if the application is really focused on record keeping/data entry/retrieval as opposed to automating workflows.

My client ponders the question whether the web-services layer represents an uncessary overhead. Well – the answer is *drum roll* it depends.

From a workflow/logic abstraction point of view, most of the interaction logic exists in the client application and the underlying stored procedures in the database. However from a security perspective it really is a good idea to speerate the client from the database because the web-services present only a subset of the underlying database functionality – which (if you do it right) actually reduces the attack surface.

My suggestion would be to stick with the web-services layer – it’s place in the design seems to be justified.

Where should I get my data from?

My client also aksed about building a data access layer and whether they should use some third party toolkit like Castle or stick to the tools that come out of the box. I don’t really have enough experience with Castle to say definitively whether it is the right tool for them, especially since (form memory) they are heavy users of Oracle, and Oracle support usually comes second if at all in the world of community extensions for .NET.

O/R mapping solutions generally come at a price, mostly around getting your head around how their persistence and round-tripping mechanisms work, but once you are over that hump they can give you a pretty decent productivity boost, and some of the newer ones are event developed with an eye on performance. Even Microsoft is taking another stab at this O/R space with LINQ with a special focus on the query mechanism – an area where other tools have struggled because they can’t break into the compiler tool chain as easily.

So what is the wright answer for you (my client)? In all honesty I don’t know, a lot of it depends on how you intend to balance the conflicting business requirements – its a design question, not an architecture question. Please excuse me while I go off on a rant that has been a long time coming.

Why I hate the “architecture” word!

This is not intended to be a architect bashing session, rather I have a problem with the word “architecture” and the amount of baggage that it brings over from our friends in the construction industry. Architecture is a big word, it implies building something relatively large with layer upon layer of support systems, which is ultimately topped off with a pretty facade.

As practioners in the software industry we seem to have taken this and tried to replicate this necessary complexity in software, where in reality – a lot of solutions we build don’t require anywhere near as much code. I think we need to take of the architecture hat, and put on the design hat – design is a much lighter world.

Here I evoke the spirit of Joel Spolsky who has written some great stuff around what design really means. But what I want to say is that a good design is a simple design (or at least as simple as possible) and that a software designer wouldn’t necessarily believe that they need to add code – they might decide that usability (in the holistic sense) of the system might be improved by turning something off – or completely removing a feature.

In the consumer electronics business, some people are actually hired to go through a system and remove components until it stops working – they do this to remove the cost before they go into mass production. We need more of this in the software business.

</soapbox>

Now that I’ve had my rant, how does that relate to the question at hand? Well, my point is that you should look at each new application as a different challenge – go into it with your eyes open and don’t assume that the framework that you used in the previous application is necessarily the best one in this case. If you do implement a framework like Castle or LINQ, be up front about how much code you expect to save yourself – and, if you end up writing more code bail out. More code is seldom more maintainable – in my experience (and that includes code generated code).

10 thoughts on “Architecture vs. Design

  1. Clarke Scott

    “But what I want to say is that a good design is a simple design (or at least as simple as possible) and that a software designer wouldn’t necessarily believe that they need to add code – they might decide that usability (in the holistic sense) of the system might be improved by turning something off – or completely removing a feature.”

    Well said Mitch!

  2. Kevin Daly

    Actually, my biggest objection to the A-word is that it’s unbearably pretentious and pompus and reflects how many in our industry are desperate to be taken seriously.

    But worst of all is its use as a verb – No Virginia, you cannot “architect” something, any more than you can “lawyer” a court case, or “plumber” a set of dodgy pipes. But if we said “design” that would sound soooooooo ordinary wouldn’t it? And heaven forbid, it might suggest some kinship with those arty types who hardly ever wear *shoes* let alone suits, and we couldn’t have that, could we?

    Or to put it another way, I think the term is a) a symptom of the job title inflation that flows our way constantly from Americaland and b) indicates a desire to suck up big time to the corporate world, because the poor little darlings get all anxious whenever they encounter people who they suspect might not have the souls of accountants.

    Or maybe I just ate something tonight that didn’t agree with me.

  3. murls

    It’s just another word with a definition. Sure it has its roots in the building industry but so does about 30% of everything else. We are just extending the term to represent how in technology terms we design and build systems, as distinguished from the skills associated with the actual server builds or code cutting. And just like in the building industry, there is no one vantage point from which the whole system structure can be understood.

    As a PM (ex now I guess) when ask for the architecture of a system I expect to see something I can continue to drill down on to find the smallest possible component, either from a hardware or software component view. So I guess what I am saying is that the word itself is not inappropriate for our industry, but I agree it gets tossed around like expensive confetti.

  4. Mitch Denny Post author

    Hi coffee shop man,

    I agree with what you are saying. Looking at something from multiple perspectives is still different from looking at something big🙂

  5. Mitch Denny Post author

    Hi Kevin,

    I’d like to think that the best architects are well rounded individuals🙂

  6. Tariq Ali

    dear reader:
    upto know i have to the conclusion that their is a lot of material to study from net on any topic like software architecture but indeed if we observe the implimentation of these rules and guidlines related with architecture in daily life, dan we see that most of them are just bookish and its true that software devolopment still involve much art.

    PlZ commints on this……………………………………………………….Thanks

  7. offshore software development

    “I think we need to take of the architecture hat, and put on the design hat – design is a much lighter world.”..very true dude this line is something that can give you a feeling of developing software solutions on your own will power than having :architectural” burdens to carry on our shoulders.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s