Apr 092012
 

Admiral Adama: In your opinion, off the record, what was Garner’s flaw?
Major Lee Adama: He was used to working with machines. Command is about people.
- Battlestar Galactica Episode “The Captain’s Hand”

A couple weeks ago I found that Netflix was providing every episode of the Battlestar Galactica series online. While I was watching it (and enjoying it thoroughly I might add), the above quote stuck with me. The quote refers to an episode in which an engineer is promoted to commander of a ship, and his command turns out to be quick and unsuccessful. The quote got me thinking about being an architect, and how often people promoted from the ranks of programmers into architects have the same problem. Sure, architecture requires a good understanding of technology, but understanding people can be much more crucial. Continue reading »

Mar 312012
 

I’ve often been asked to define what a software architect does. We do many different things, and the job description varies quite a bit among different companies, and across different sub-disciplines such as infrastructure architect or application architect. But the best definition I’ve come up with for what a software architect does is this: we balance the different quality attributes of a system so that they are best aligned to delivering business value for our organization. In this post I will talk about what quality attributes are and how they are employed when architecting a system.

Continue reading »

Apr 192011
 

This is part three in a series of articles on .NET architecture. You can start here for the introduction and table of contents. This post will focus on the first thing you should think about when starting a new .NET application: cross-cutting concerns. And, by the way, I got really tired of type “cross-cutting concern” after about a dozen times, so I decided to coin a new acronym for them: C3s. I hope you like it. Continue reading »

Mar 202011
 

This is part two in a series of articles on .NET architecture. You can start here for the introduction and table of contents. This post will focus on the overarching principles I’ve developed when tackling application architecture. The focus of this post is not on individual technologies (except when used as examples), but on general rules of thumb that I use to help guide me when making architectural decisions.

I consider these to be the axioms of my architectural philosophy. And like axioms in philosophy, if you disagree with any of these foundational principles, you will most likely disagree with a lot of the conclusions I draw based on them. But that’s okay – no matter what principles you hold, someone will always disagree. :-) Continue reading »

Mar 202011
 

About a year ago, through a series of cascading events, I found myself in the position of being the only application architect for the .NET portfolio of a medium sized development shop. Even before that happened, I had read a good deal about architecture, .NET technologies, coding best practices, TDD, design patterns, etc. But it is a bit of a shock to move from reading about all of those things to deciding how to apply them in a practical way. Of course as a developer you have a chance to apply all of that knowledge to whatever code you are working on, and you can influence the rest of the team. But as an architect I found I suddenly had to have a well-defined position on a lot more of these topics, and, if at all possible, that position had to be right. Continue reading »

 Posted by at 2:22 PM