Architecture: The right tool for the job

Way back when, almost 10 years ago now, I got my first Microsoft Certified Solution Developer (MCSD) certification. In addition to passing exams on Visual Basic 5.0 and SQL Server 6.5 database development, I also needed to pass two “Architecture” exams. [1] I remember walking out of these exams thinking “what a joke,” because it seemed that most of the questions involved picking a different Microsoft product from a short. When you compared them to the VB5 exam [2] they just didn’t measure up. Who cares about picking the right product, I thought – being able to write solid code is much more important…

And I’m certainly not going to disparage the importance of writing solid code. But as time has gone on (and as Microsoft’s product offerings have grown many times broader and more complex) I’ve come to understand why these exams were the cornerstone of Microsoft’s premier[3] developer certification. And that’s because the best code in the world isn’t going to be worth much if it’s built using the wrong tool.

There have been several recent posts on the MSDN SSIS Forums that have made me think of this. Some of them have taken the format “I’m trying to do this thing that is practically copied and pasted from an SSIS white paper, but it doesn’t work – can SSIS do this?” These appear to me to be the result of both a lack of product knowledge – what is the tool supposed to do – as well as a lack of detailed implementation and feature knowledge – how do I use the tool to make it do what I need. For these posts it’s usually enough to point the poster to the right feature – tasks, transforms, expressions and so on.

Other posts have taken the opposite format: “I’m trying to use SSIS to do something that it can probably do well, but which will be 1,000 times more complex than it needs to be – can you please help me force this giant square peg into this tiny round hole?” For these posts, it’s usually best to point out how they can solve the problem with a simple C# app or a T-SQL query or the like. Even though I love SSIS, it’s not the right tool for every job.

So back to my point. [4] It’s vitally important to know these things:

• What tools are available
• What each tool does
• What tasks are appropriate for each tool
• What tasks are not appropriate for each tool
• How to perform tasks with each tool
• How and where to find out the other things when all else fails
  

That’s quite the list, isn’t it?

I think that this is a big portion [5] of what makes an architect an architect, and not simply a developer. It’s not enough to draw boxes and arrows and look only at the big picture. But it’s also not enough to write the best multithreaded listener either. An architect needs to be able to do both, and to help others do both if he (or she) is going to succeed.

And now I’m done. I don’t know if I said what I was hoping to say, but I’m pretty sure I’m not going to get any more coherent tonight. All the work I needed to get done is done, and sleep’s siren call is getting more seductive by the minute…

[1] That’s right – 70-160 (Microsoft® Windows® Architecture I) and 70-161 (Microsoft® Windows® Architecture II)

[2] Yep – 70-165 (Microsoft® Visual Basic 5.0 Programming)!

[3] This was the case then, anyway. Microsoft’s certification story has grown in breadth and complexity as well, and it’s also gotten a lot more relevant. But that’s a story for another post…

[4] Yes, I do have a point. But it’s almost 02:00 and I’m still not done with my Exchange 2007 migration and ISA 2006 upgrade, so while I wait, I type, and ramble as I fend off sleep.

[5] Another big portion is communication and soft skills, but that’s another story as well.