For those of you who didn't get the memo, Ron Jacobs is no longer hosting the very popular Channel 9 show, ARCast. After spending a couple of years traveling the world talking to hundreds of practicing architects, Ron decided he needed a change and is now a Technical Evangelist in Redmond working with the WCF and WF teams.

Because of the popularity of ARCast worldwide, I and a small team of fellow architects from across the country have been working over the past several months to bring into being what we're calling, "ARCast 2.0." Instead of having one regular host on the show, any architect evangelist in the world that has a story to tell and is willing to sit down and record it can be the host of an ARCast episode.

We published the first official episode of ARCast 2.0 last week. My colleague and good friend Bob Familiar sat down with Simon Guest, Senior Director of the Platform Architecture Team at Microsoft, and had a great conversation about what his team does and what types of content and activities his team will have for the community in the future. If you haven't had a chance to watch the interview yet, you can watch it here.

And this week it's my turn.

A few weeks ago at TechEd Developer 2008, I had an opportunity to sit down in the TechEd Online "fishbowl" and have a conversation with Juval Lowy about his ideas concerning interface-based design in software. Any conversation that starts with, "Object-orientation has completely failed us," is going to be a good one.

You can watch the full ARCast video here:

ARCast.tv - Juval Lowy on Interface Based Design

If you never want to miss an episode of ARCast, then be sure to subscribe to the show's feed here. Please let me know what you think of the interview.

I'd like to thank everyone who came to the Next Web Roadshow event we held in St. Louis last week. The turnout was phenomenal and, based on your feedback, it looks like the material was very useful and on topic.

As promised, our presenter, Mike Henderson, has posted a set of links to resources from his presentation.

For the sake of simplicity, I'm re-posting Mike's links here:

WPF Information:
MSDN WPF samples
Code Project's WPF Pages
Vista x64 Forums on WPF
XCeed's WPF Wiki
Kazaml

Good WPF-related Blogs:
Josh Smith
Mike Hillberg
Beatriz Costa
Tim Sneath 

Silverlight Information:
Silverlight splash screen + dynamic content sample
Silverlight.net 
Silverlight Cream 
MSDN Silverlight Dev Center
Silverlight 2 Controls Source Code

Good Silverlight Blogs:
Brad Abrams
Expression Design + Blend
Joe Stegman
Mike Harsh
Mike Taulty
Scott Guthrie

ASP.NET Information:
ASP.NET 
MSDN ASP.NET Code Gallery
123ASPX Index 
4 Guys From Rolla

Good ASP.NET Blogs:
DotNet Slackers
Scott Mitchell

Books:
Programming WPF 
Essential WPF 
Apps = Code + Markup 
Professional ASP.NET 3.5
ASP 2.0 Website Programming 
Essential ASP.NET

It never ceases to amaze me how contentious the very definition of "software architect" is. It really seems like something that should be very cut-and-dry, and yet a great deal of my energy at Microsoft TechEd Developer was spent discussing this very topic last week. In fact, I'm working on a series of articles on this subject as we speak which should be published online in the near future. And if it is that difficult for working architects to create a standard definition of their own role, imagine what it would be like for those aspiring architects out there.

In an effort to help those individuals who are aspiring to be architects better understand the role and the big topics in architecture today, there is a great series of webcasts starting next week that will provide a primer for moving into the role of the architect. In fact, much of the content in the series would work very well for many working architects out there as well. To get an idea of what you can expect, you can review last year's webcast series here.

Below is the schedule for this year's series as well as links to the registration sites for each:

June 16^th, 2008 – 12:00 p.m. to 1:00 p.m. – Introduction to the aspiring architect Web Cast series
http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032380836&Culture=en-CA

June 17^th, 2008 – 12:00 p.m. to 1:00 p.m. – Services Oriented Architecture and Enterprise Service Bus – Beyond the hype
http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032380838&Culture=en-CA

June 18^th, 2008 – 12:00 p.m. to 1:00 p.m. – TOGAF and Zachman, a real-world perspective
http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032380840&Culture=en-CA

June 19^th, 2008 – 12:00 p.m. to 1:00 p.m. – Services Oriented Architecture (Web Cast in French)
http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032380842&Culture=en-CA

June 20^th, 2008 – 12:00 p.m. to 1:00 p.m. – Interoperability (Web Cast in French)
http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032380844&Culture=fr-CA

June 23^rd , 2008 – 12:00 p.m. to 1:00 p.m. – Realizing dynamic systems
http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032380846&Culture=en-CA

June 24^th, 2008 – 12:00 p.m. to 1:00 p.m. – Web 2.0, beyond the hype
http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032380848&Culture=en-CA

June 25^th, 2008 – 12:00 p.m. to 1:00 p.m. – Architecting for the user experience
http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032380850&Culture=en-CA

June 26^th, 2008 – 12:00 p.m. to 1:00 p.m. – Conclusion and next steps
http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032380852&Culture=en-CA

Brian Moore called me out on providing some answers to a few questions about how I got started in software development. Seeing as it's Brian that asked, I'm only too glad to oblige.

This post is actually the most recent in a thread of posts from different bloggers, essentially a blog-based chain letter with a purpose. And I can guarantee that you won't get ten years of bad luck if you don't respond.

Here is the stacktrace for this thread as it stands today:

With that said, here's my contribution.

How old were you when you started programming?
I was thirteen. My friend next door got a Commodore VIC-20 for Christmas. After spending more time on it than him, I immediately began earning money to buy my own and, after a particularly lucrative garage sale in the summer of 1984, I went to Toys-R-Us and bought a Commodore 64. From that point on, most of my  free time was spent sitting at the keyboard copying programs from the popular computer magazines of the time and learning how to code by changing them to make them do what I wanted -- it was my first experience with extending third party software.

And by the way, I still proudly own my Commodore 64 and even pull it out for my kids sometimes when they start complaining about how slow their Internet access is.

What was your first language?
BASIC

What was the first real program you wrote?
This depends on your definition of "real." The first thing I ever wrote that did something, looked a little bit like this:

10 print "Denny is awesome"; 20 goto 10

This, of course, had the expected output of printing "Denny is awesome" an infinite number of times, or at least until I hit the Run Stop key.

If that's not real enough, then I guess it would be a text-based adventure game I wrote called Despair Mountain. Inspired by Zork, I set about writing my own game in that same particular genre. I know this will be hard to believe, but I was a big Dungeons & Dragons nut when I was that age, so my game was set in fantasy-adventure universe. I had two major achievements from that particular development project:

1. I managed to develop a calligraphy font for the UI before there were such things as fonts
2. I wrote a very basic "fuzzy logic" algorithm for interpreting directions typed in by the user

I would hate to go back and run a cyclomatic complexity text on that app, but for that time in history and my level of inexperience, it wasn't bad.

What languages have you used since you started programming?
I cut my teeth on BASIC, both at home and what passed for a computer education course at my high school (we learned on the Apple IIe in class). When I started my professional career, I was writing in C and moved quickly into Perl, as I was doing a lot of web development work in the mid-nineties and Perl was preferred language at the time for CGI.

Around that same timeframe, I learned and developed in Java for awhile. I was really drawn by the promise of "write once, run anywhere" that Sun was making. Unfortunately, it didn't take long for me to recognize that it was all a pipe dream.

Disillusioned with Java, I picked up a copy of Visual Basic 5.0 and started writing software for Windows. While I was never crazy about the VB syntax, I soon discovered a new web technology Microsoft was touting called Active Server Pages that used VBScript as the primary language and that alone made it worthwhile. ASP changed the way I looked at software development in general. Sure, we look back and laugh at the simplistic model "classic" ASP provided, but in a world where CGI was the only option, ASP was an enormous evolutionary step forward in web development.

When .NET was released in 2001, I stuck with VB in the form of VB.NET for a month until I started playing with C# and just fell in love. To this day, I'm still a C# developer through-and-though and only go back to VB.NET when I have to.

What was your first professional programming gig?
I actually sold my first piece of software before I ever had a full-time job as a developer. A friend of mine at the time contacted me in February of 1996 with an opportunity to write an application that would produce web pages and associated CGI scripts that could tie users into a proprietary document management system. I developed a VB5 app, which I named Voyeur with tongue firmly planted in cheek, that let users start a new web project, customize the look and feel of the document and add custom search fields, content and logos. When the user published the project, it produced a web page reflecting their chosen layout and a corresponding Perl/CGI script that connected through a COM component to the back-end of the DMS.

For its day, it was pretty slick little application and I sold it to the document management company for a tidy sum.

If you knew then what you know now, would you have started programming?
Absolutely. In fact, I would have started earlier.

If there is one thing you learned along the way that you would tell new developers, what would it be?
Wow, nailing down one thing is going to be hard -- there's a lot of advise I would dispense to those just getting started.

I guess my advise would read like this: "Trust in God, but lock your car."

You'll be presented with many technological panaceas over the course of your career. It seems every year has another "If-You-Just-Use-This-Technology-Nothing-Will-Ever-Go-Wrong-Again" product line. The sad fact is that nothing of the sort really exists or will likely ever exist. Development tools, frameworks and platforms are like tools you keep in your work shop: Each one is very good at certain things and not so good at others. So be optimistic and open-minded, but also learn to develop a healthy sense of skepticism. Look at each technological advance you come into contact with and give it a thorough, objective examination before deciding whether or not you're going to use it.

And one more thing (yeah, I'm breaking the "one thing" mandate -- sue me):  Don't get emotionally attached to one specific technology or platform. The only thing that you can count on in this business is that things are going to change constantly, and if you're married to the wrong technology, you'll likely find yourself on the outside of things very quickly.

What's the most fun you've ever had ... programming?
Back in 1997, my wife and I owned and ISP in suburban Chicago. Our company web site was my first ASP project and was a wonderful learning experience. I was pretty new to the Windows platform and had a blast writing an application that would allow customers to sign-up for service and provision their personal web site and database account online. I can't ever remember a time when I had so much fun making so many mistakes -- I learned so much. Even when I first started working in .NET, I already knew a lot about the platform, so it was fun, but not as much as that first ASP project.

Who am I calling out?
This was a lot of fun. These are the kinds of questions I don't get very often and it was very enjoyable walking down memory lane. That being said, I'm going to tag the following friends and colleagues to continue the thread:

• Clint Edmonson
• John Mullinax
• Jeff Julian
• Rob Foster

This afternoon, I attended career day at my daughter, Josephine's, school.

Now, I've spoken all over the country in front of audiences large and small, but I'll tell you this: There are few more intimidating audiences than 40 or so fifth graders. That being said, I came prepared.

I started my session by trying to explain what Microsoft does. I held up a picture of BillG and asked the group if they knew who that was. Scattered hands went up and we eventually got that part right. Then I reached into my bag and pulled out my Master Chief helmet and asked if they knew who that was and, not surprisingly, they got it on the first try. "Sweet," I thought, "I've got them in the palm of my hand now."

And indeed it seemed that way for the next 10 minutes. I answered more questions about Xbox, Wii and Playstation than I thought there were in the known universe. I even gently explained why Microsoft won't be producing an Xbox for the Wii.

As I was preparing to wrap up the Q&A, I picked a young lady in the front row who looked me straight in the eye and asked:

Isn't Linux better than Windows?

Like an underpaid, under-appreciated vaudevillian actor, I actually did a double-take and said, "Excuse me?"

"It's just that I think Linux is better than Windows and I'm wondering why you think it isn't."

Needless to say, I was not exactly prepared for this. I mean, I discuss the merits of Linux and Windows all the time, just not with eleven-year-olds. I answered her question by saying I didn't necessarily think that Windows was better than Linux, but that they were both operating systems and each had specific strengths and weaknesses, and that it really depended on what you were looking to do. That seemed to satisfy her, but she concluded by saying, "I still like Linux better." I absolutely failed as an evangelist in this instance, but in all fairness, she did ambush me.

This really got me thinking about the younger generation and their ubiquitous connection with technology. We hear about this all the time. In fact, the one major argument I've had with my oldest daughter, Zoe, in the past few months has been whether she's old enough to have her own mySpace page ("But Daaaaaaad, all my friend have one!"). Both of my oldest daughters have cell phones and the idea that mobile phones used to be carried in bags and had batteries that lasted 20 minutes carries the same level of incredulity as when I showed them the video games I used to play on my Atari 2600. Even my six-year-old, Gwynneth, can play most Nintendo DS games far better than I can and even laughs at my eventual failure each time we play.

But this question was different. Here was an eleven-year-old child that already had a preferred operating system, and challenged me to explain the major advantages of one platform over another. She was alone in this group of kids, but a 1:40 ratio of kids with deep technical knowledge to kids who think software is just about video games is a pretty significant part of the American population and worth noting.

As kids become more discontented with just experiencing technology, they are going to start looking for ways they can become a participant in it, and this is going to lead them to start exploring platforms and the tools available to develop software for these platforms. Because they will have had so much exposure to technology growing up and the ability to learn and build new software will be so available to them, they will have no fear as they approach new problems that require innovative, creative solutions.

There is a post I've been working on for some time now, inspired by Zain Naboulsi, about Second Life and the impact it can have on interpersonal relationships. The holdup in finishing and publishing that post has been that I needed to get deeper into that experience to prove out some theories I had about it. What I've found is fascinating.

When letting my kids ride "shotgun" with me in Second Life, they seem to form connections with the other avatars I interact with in the virtual world. One example that comes to mind is when I walked away from someone I was conversing with in the middle of their sentence. My kids actually admonished me for being "rude" to the other "person." This, I think, shows the connection that our children have with technology that perhaps we, as adults, do not. I see a screen where my momentary rudeness to another virtual being is not even worth noticing. But, to my kids, that was equivalent to turning around and walking away from someone I was speaking to in "meatspace," and that, therefore, is rude.

This is the thing we need to really understand about this younger generation. The lines between personal and virtual relationships are going to melt away. I want to believe that machines will never replace real, interactive human contact, but that may be because that is the the world I've grown in. My children live in a world where they can befriend digital representations of real people half-way around the world and it is as real as if they lived next door. The text messages that they send and receive can carry as much value as a personal conversation over coffee does to us "older folk." And a mySpace page can be the difference between social success and failure.

So here's what I learned at school today: Don't underestimate kids and their depth of understand when it comes to technology. They are living in it now and will drive the direction it takes in the future.

"The Next Web." "The Next Generation Web."

What the hell is that, anyway? Just another buzzword? More "marketing techno-babble?"

I like to think of it as "Web 2.5." It ameliorates the technical innovations that drove the Web 2.0 movement and really takes them to the next level. If you consider the impact that AJAX has had on the way web applications are built, essentially making them behave more like desktop applications, next generation Web applications look and feel like desktop applications as well. In the Microsoft world, the technologies that are driving this evolution are Windows Presentation Foundation, Silverlight and the incredible advances in ASP.NET.

If you live in or near St. Louis, I encourage you to register for a great seminar we're going to be holding on Wednesday, June 11th at the Microsoft offices to talk about the next generation of the Web and how these technologies will play into it. You will take part in a technical exploration of the latest technologies Microsoft has to offer, and how you can take advantage of those technologies to provide a truly next-generation user experience in you Windows and web client applications. During the seminar, Mike Henderson from Pluralsight will guide you on a technical walkthrough of each technology, demonstrate the technologies' capabilities, and show the tools and techniques used to provide those capabilities.

Seating will be limited for this event, so I highly encourage you to register today if you would like to attend.

I try to avoid doing posts that simply announce upcoming events without providing some kind of value to the message. This is a blogging tip I got from my buddy Josh Holmes and it's really proven to work well.

But this time, I'm going to make an exception...

If you haven't heard already, Microsoft launched the Professional Developers Conference 2008 (PDC) web site. The conference will take place in Los Angeles from October 27th through October 30th. The registration site is now open and, if you possibly can, you should make every effort to attend this conference.

For those who aren't familiar with the PDC, this is not a conference that happens every year, like Microsoft TechEd that is taking place over the next couple of weeks in Orlando. The PDC only happens when Microsoft has something big coming that they want the development community to learn about.

What might you learn about at the PDC this year? Well, Ray Ozzie spent a lot of time at MIX last March talking about Software + Services and, not long after that, the Live Mesh CTP as released. S+S is surely going to be a big topic at PDC this year, but I'm also betting that we're going to see a lot great information about the future of the Windows Mobile platform, Silverlight and .NET as well.

If you're a senior developer, architect or technical decision maker responsible for helping determine the technical roadmap for your organization, you will want to be in Los Angeles this October for the conference. I'm definitely going to be there, and hope to see you there too.

Code reviews should be built into every project timeline. What I find most of the time is that they are overlooked, excluded in lieu of functional testing only, or worst of all, performed by the wrong person. This is shame because a code review can significantly enhance a team's chance of delivering a quality piece of software that the customer will actually use.

There are several ways of conducting an effective code review, some very laize faire and some very hands-on. The key is combining the power of review tools with an architect's personal and professional experience to yield the most effective review possible without taking inordinate amounts of time away from the project itself.

The following are three tips I'd like to offer to help you get the most out of your code reviews.

1. Do Reviews Early, Do Reviews Often
The first three weeks of a project are the most crucial. It is during this early time that the foundational parts of the application are being developed. This will be the first and best opportunity for issues in this vital part of your application to be identified and fixed inexpensively. Every day that goes by without identifying a critical defect in the code will cost you exponentially down the road in lost time and money.

The first key to a successful code review is to start reviewing the first day of the project. Look at code written by all the members of the development team and make sure that they are heading in the right direction. Some important things to look for in these early reviews include:

• Are they correctly implementing classes, interfaces and layers per the system design?
• Are they leveraging any reusable utility components in your organization?
• Are they using established naming conventions, either industry or organization specific?
• Are they implementing proper exception handling, i.e. not swallowing exceptions?
• Are they properly closing database connections, streams, etc.?
• Is there any redundant code that can be consolidated?
• Are they properly addressing tier requirements for the system?

With a focus on these specific items, I recommend that you do daily code reviews for the first three weeks of the project, providing feedback to the team the same day. By identifying these fundamental structural issues before thousands of more lines of code are written on top of them allow your team to address them while they are still easy and inexpensive to fix.

This process also provides the architect a great opportunity to mentor your development team. Looking at their code will be a great indicator of how experienced they are and sharing your feedback will help make them better developers down the road.

After the first three weeks of the project, you should be able to back off the daily code reviews and start doing them every couple of days instead. By this time, your team should have firm expectations what they need to do and solid direction going forward. Ideally, within a month, you should be able to move to weekly reviews with minimal risk of missing something important. Of course, every project and development team is different, so use your best judgement as to the effectiveness this approach offers at the start of each new project.

2. Tools: Trust, but Verify
Any software vendor that you talk to will tell you that their static analysis tools will catch most of the bad stuff in your code, and the only ones you should be considering should allow you customize the rules that the tool applies in its analysis.

However, analysis tools are just like any other piece of software: They're limited by the number and quality of rules provided them to do their job. Most static analysis tools I've worked with in my career provide good starting points for a more in-depth, manual review.

Think about a code analysis tool like Cliff's Notes. Cliff's Notes were meant to be a study assistant while reading a particular book, not a replacement for the book itself. However, ask any group of high school English students and I'm sure you find them enjoying the Cliff's Notes for Huckleberry Finn without a copy of the novel anywhere in site. While this will give you a high level overview of the plot and the major themes, nothing can replace the level of detail you'll only get from reading the book itself.

Also, Cliff's Notes are not always correct. I remember using Cliff's in college for some 18th century British novel I was struggling to get through (I wish I could remember wish -- it was dry as hell). I got through the novel, but depended almost solely on the Cliff's Notes to arm me with the information I needed to discuss it in class. As it turns out, we were using an alternative version of the original text and I was missing several details which made me look like an idiot in front of my classmates.

If anyone out there used FxCop before it was (arguably) improved and integrated into Visual Studio Team System, you know that tools can't always be trusted to return an accurate representation of reality. I once wrote a "Hello World" console application in C# and FxCop told me I had over 1,200 defects in my code.

The point of this is to use code analysis tools as a means of "sniffing" your code for potential problems. Look at them as sign posts to something you should investigate further. Sadly, I don't think we'll ever see a tool that will deliver the same, high-quality results as actual human eyeballs on the source code. "Trust" that the tool is pointing you in the right direction, but "verify" that there is really some fire to go with that smoke.

3. Actually Read the Code
Building on the previous section, nothing can replace actually looking at source code. This is definitely time consuming, but will yield the best results. While code analysis tools will catch naming convention violations and orphan variables, actually looking at the code will provide you the context of those issues, especially in the structural integrity of the application as a whole.

The other benefit is that it gives you more visibility to what your developers know how to do. In my first bibliography class as an undergraduate, I was fascinated to learn that literary scientists had been able to identify individual typesetters of Shakespeare's first folio by the grammatical and spelling errors they made setting type on the printing press. The same principle can be applied to reviewing developers' code. It will help you identify strengths and weakness in individuals' coding and allow you act accordingly.

Reading raw code isn't necessarily to most exciting or desirable work in the world. In fact, it can be downright tedious and tiring. However, it is the most sure way to make sure that your project is proceeding the way it should be in development, so budget time to sit and just read and understand the code being written for your project. If you do, I can guarantee you'll reap the benefits later.

Just Do It
Hopefully you'll find these tips useful in getting better quality results from your development projects. I absolutely recommend trying these techniques out on your next project, but also encourage you to try them out on your current project, even if it is well underway. You may not get all the benefits, especially from the early and often reviews, but doing some level of review is better than doing none at all.

I welcome your input, experiences and additional best practices. Please leave a comment if you have something to add to the conversation.

In a post yesterday, Eli Feldblum makes the assertion that Microsoft seems to prefer to use Flash over Silverlight. He argues this fact is obvious since most of the rich, interactive parts of Microsoft's public sites are using Flash. In fact, he even states that "the software giant seems to be not even trying" to move to Silverlight and goes on to say:

A quick check through Microsoft properties reveals that only the Microsoft Home Page  and the Microsoft Developer Network use Silverlight; MSN Video, Zune.net and the new WWTelescope all use Flash.

The idea that Microsoft isn't interested in using Silverlight on its sites is, of course, completely wrong. However, in Mr. Feldblum's defense, it could certainly seem that way if you make the assumption that any company, including Microsoft, could implement massive technical and creative changes across an incredibly wide swatch of high traffic sites like the ones cited above in a month or two.

I felt compelled to respond to Mr. Feldblum's post not necessarily to defend Microsoft, but because I have very similar conversations with people all the time about adopting new technology in general. There is a natural human reaction when something new and revolutionary is laid before them. They need to strike a balance between all the new possibilities this new technology offers with the tangible business value of replacing what they already have in place. In this case, the question is, "What do I gain from paying a development team to replace the considerable Flash presence on my sites with Silverlight?"

To assume that a project team with any company would simply throw out a project plan already in motion, ramp their developers and designers in a new technology and start over for the simple fact that there is a new way of accomplishing their goal is ridiculous. You wouldn't do that and I wouldn't do that, unless there was a real ROI as a result.

However, when I talk to people about adopting Silverlight, they always make the comment, "I already have so much Flash built into my web site, I don't know where to start with Silverlight." Well, the good news is you don't have to throw out the baby with the bath water. The fact of the matter is that you can begin to implement Silverlight where it makes sense in your web site without modifying or removing any of the Flash assets you already have in place. Silverlight will run just fine in a web page with Flash, so you can iteratively begin the process if implementing Silverlight and, if prudent, replacing Flash to take advantage of XAML, developer/designer collaboration, developing in managed code and all the other benefits Silverlight has to offer. No expensive and painful "big bang" replacement is necessary. Find a requirement for which Silverlight is a good fit and implement it. It's as simple as that.

The truth is, while the rest of the world would hold Microsoft to a higher standard than any other company, at the end of the day Microsoft works very much like the IT shops you probably work in. Each Microsoft product and web site has a team of developers and product managers that have a finite budget, timeline and resource pool in which to work. Believe me, if Silverlight could be deployed as a replacement to Flash across all Microsoft web sites next week, it would certainly make my job a hell of a lot easier, but that's not possible and difficult decisions have to be made in order to deliver a multitude of solutions currently underway on time and on budget.

I can all but guarantee you that there are roadmaps in place to adopt Silverlight across most or all of the Microsoft web assets. That adoption will be rolled-out in a manner that delivers value to the business and as it makes sense. You're seeing that adoption begin on Microsoft.com and MSDN, and should see it on more Microsoft sites in the coming months and years, a very timely example being the new Expression Suite web site, all built in Silverlight.

In fact, if you're still of the mindset that Microsoft isn't using Silverlight because they don't believe in it, it will probably interest you to know that NBC will be broadcasting all 17 days and 34 sports of the 2008 Summer Olympic Games this year, at total of 2,200 hours of streaming HD video with multiple views and control gadgets, all in Silverlight. For an early review, have a look at Adam Kinney's post.

Rather than shame Microsoft for not dropping everything else that they're working on to replace Flash with Silverlight, we should learn from their example of implementing Silverlight iteratively as it makes sense. That just good project management and good business.

While there is still a lot of conversation going on about what it means to be a software architect, there are a few things that are true among all of us who wear the title "Architect":

• Architects are thought leaders, pushing the envelope on what's possible
• Architects provide the vision, guidance and experience that enable others to make that vision a reality
• Architects need to understand the technical and the business (practical) side of any project to provide the best proposed solution

Now, watch the following Monty Python "Architect Sketch" with these points in mind. It's not only entertaining (one of my very favorites from the Python troupe), but required viewing for anyone who purports to have a sense of humor:

Monty Python's "Architect Sketch"

Though John Cleese and Eric Idle are pitching "a block of flats," there are certainly many things that should resonate and seem familiar to those of us working in the software industry today.

Understanding the Project Requirements
This is one of the most obvious and most missed parts of working as an architect. There are several reasons for this:

• The architect doesn't understand what the customer wants, but doesn't know it
• The customer doesn't know what he/she wants, but doesn't know it
• The architect makes certain assumptions about the customer's intent, goals and technical maturity
• The customer makes certain assumptions about the architect's experience and level of knowledge
• The customer and the architect don't ask questions or challenge ideas for fear of looking unknowledgeable

Any one of these common situations can send a project off the rails before it even gets started, and usually there are two or three in play at the same time.

As architects, we need to understand the business drivers of the project in order to present the "right" solution to the customer. There's an old joke that says, "The only answer an architect needs to any question is, 'It depends.'" Well, to a certain degree, that's true. There are always going to be many different ways to solve a problem. Our job is to understand our customers' motivations by asking pointed questions and challenging them on things that don't seem to make sense, thereby enabling us to provide the best solution to meet their needs and avoid pitching an abattoir when a block of flats is what the customer really wants.

In addition, the architect needs to be self aware and not push a customer into a solution because he/she is afraid to admit they've missed something during the discovery phase of the project. I've never heard tell of someone being removed from a project because he/she was honest and said, "I must have misunderstood what you were looking for here -- let me work on an alternative solution," at the beginning of the project. I can imagine it would be very easy to get thrown off a team for spending several weeks developing only then to find out that the solution you convinced your customer was the "right" one is not going to get them what they need.

Thought leadership becomes a reality by taking your collective experience, diving deep into the customer's needs by asking the right questions and challenging the ideas that don't make sense and by listening as much as you talk. Self-criticality and honesty build trust and credibility.

Compromising the "Right" Solution
No one who has worked on even one project in their careers is unfamiliar with the multitude of external forces that can negatively impact a project's outcome. The customer wants the most business value from a piece of software for the least amount of money. Developers don't tend to care about cost as much as putting together solid code that works.

In the middle sits the architect.

It's not unusual for a customer to look to cut corners to save money on a project, especially if there isn't a real, tangible ROI attached to the final product. As an architect, we need to make sure we communicate the probable consequences of these cuts and make sure that we adjust the technical roadmap as a result. The fact is that the customer is not always right, and we need to make sure that they have all the facts about a decision before they make it.

At the end of the day, the customer is one paying for the project and we need to attentively listen to their ideas, but we must not passively let the make erroneous decisions. Our passion for building solid, secure and performant solutions has to be asserted in a way that serves our customer's best interests. This sometimes means pushing back on cutting corners, especially if they involve a "central pillar system," "recessed magnilium phalange groups" or "fire suppressant materials," i.e scalability, performance and security.

Politics and Technological Religion
It's been said that if you put more more than two people in a room together, politics becomes part of the decision making process. OK, I've always said that, but it seems too obvious for someone else to not have said it already -- I just don't know who.

Political struggles within companies are right up there with death and taxes on the "Things You'll Eventually Have to Deal With" list. More times than not, politics drives the decisions made concerning technology, the one area where it should be easy to purge political influence. I say that because it is very easy to quantify technical decisions. You can easily apply hard numbers to:

• Development resources required to deliver the solution
• Cost of new software and hardware to support the proposed solution
• Cost to integrate the new system with existing systems
• Cost of training to ramp developers' skill sets
• Projected cost of maintaining the solution over its life span

All this being said, I still see decisions made all the time based on political and technologically "religious" grounds instead of hard-core numbers. I was once talking to an architect who was working on performance problems with a JSP-based line-of-business application. He had the idea to build a WinForm application with .NET and see if he could improve on the 57 seconds it was taking for the JSP page to render a grid of data from a local database.

He got it down to 2 1/2 seconds.

When he presented the solution "bake off" to his management team, the conversation went a little bit like this:

Management: "How many records could be returned in the web app so that it would match the performance of the client-side 'test' you wrote?"
Architect: "About 250."
Management: "OK, change the web app so it only returns 250 records."

Clearly, politics and technological religion are so prevalent in that organization, management is willing to dramatically alter user requirements to stay on one technological stack and avoid the other completely, regardless of the hard facts in front of them.

As architects, we need to be aware of the these forces at work all around us. Ultimately, we have to consider the existing technology landscape within an organization and weigh the potential advantages and disadvantages of our proposed solution. As much as possible, we need to consider ourselves "technology agnostic" and truly consider what is the "right" architectural approach to meet the customer's needs.

Put simply, the architect should expect to deal with politics, but not participate in them.

"Free Masonry Opens Doors"
In the end game, being an effective architect is about integrity as much as it is technical skill. I've known many people over the course of my career that were my technical superior, but always struggled to fill the role of the architect on projects, due primarily to their overly focusing on implementation details.

Success is largely dependant on being able to take a macroscopic view of the project and the overall ecosystem in which it will need to fit. Having a detailed understanding of the requirements, being your customer's biggest advocate (sometimes in spite of their best efforts) and distancing yourself as much as possible from internal politics and technological "religious wars" will go a long way to letting you apply your technical expertise and be a successful architect.

Then you'll learn the secret handshake.