We keep getting more and more field architects and architecture strategy team members blogging. Remember, I keep a list (I am becoming the Scoble of Microsoft Architecture). Anna Liu is a field architect evangelist who presented at TechEd Australia (but we didn’t get a chance to hang out). Anna’s also been thinking about software development as an engineering discipline.

In addition to Anna, two of my teammates are blogging: Chris Keyser and Dave Welsh. Chris is a solution architect who’s doing some awesome next gen SOA work. He’s been bloggingabout using WSE2 to manage Security Context Tokens. Chris, like John deVadoss (who has relapsed into silence), is very pragmatic so it’s great to run radical ideas past him.

Earlier this year, our team “inherited” a group of awesome vertical architects – I’ve blogged about John Evdemon before who’s from that group. Dave is also from that group. Like many of our vertical architects, Dave is heavily involved in standards bodies – in Dave’s case it’s UN/CEFACT. He’s got an great article on how Standards Development Organizations traditionally work and another on how MSFT (and our specification partners) is improving on that process. He’s shining a light on the dark corners of the standard process, which is a good thing since so many people act like standards are a silver bullet solution. I love Dave’s description of the traditional standards process:

[L]aunch a committee, politically pick a chair, generate lots of hype and expectation on how this spec will solve world hunger, stack the new committee with people who may be able to contribute, host conference calls and arm wrestle the original idea down to some compromise that seems to make sense, then hope someone’s got a number of free weekends over to write up a draft of the new spec.

You want an example of the results of a traditional standards process? How about XSD? I think XSD is the ugliest widely-used spec around.  Don agrees, according to his comments from last years SellsCon:

Nothing illustrates [the cost of standardization] more than XML schema. XML schema is the quintessential example of what happens with a design by standards body specification. Rather than taking something that worked and something that was done and that there was experience with and effectively dotting the i’s and crossing the t’s you had two from every company off doing wanton innovation and invention without implementation experience. It was a train wreck in the making, especially when you consider the fact that you had people who vehemently disagreed about what they were building. Some people thought they were bringing object orientation to XML. Some people thought they were bringing database schema concepts to XML. Some people thought they were just, you know, reliving the SGML dream. So what do we get? We get a Frankenstein’s monster that is dumber than the dumbest person in the committee. No one person on that committee could have produced something this bad. It took an army of people to work hard day and night to build something that is not good. It’s not terrible – can we make it work? Yes. But it’s going to take a lot of work from a lot of plumbers and a lot of tool vendors to make XML schema palatable to the average developer.

A great example of the opposite approach is RELAX NG. It is widely believed at this point in time that RELAX NG is a better schema language for XML than XML schema. Why? Because two guys who were really smart said why don’t we go do this and let’s get it working and let’s build it while we do it and let’s iterate it and see what works and what doesn’t work. And then when we’re done we will take it to the rubber stamp – I’m sorry, Oasis – where they will carefully vet every decision and bless it and give it UN status.

I’m with Don and Tim: I want RelaxNG. More importantly, I want standards that are built like WS-* and RelaxNG.

So while I was on vacation, my trusty teammates plus our cohorts @ MSDN published JOURNAL 3 on Architecture Center. The first article from JOURNAL 3 is called The Case for Software Factories by Jack Greenfield, co-author of the Software Factories book. Jack noticed that the article, an introduction to the concept of Software Factories, was being rated inordinately low. Currently, it’s been rated 4 out of 9. To compare, Pat’s introduction to the concept of Metropolis from JOURNAL 2 rated a 7 out of 9. So a 4 is a pretty low score. Granted, I’m not going to lose any sleep over it, but it was curious. Then Jack discovered this thread on Slashdot, where most of the posts were from people who don’t appear to have read the article at all. Here’s an example comment:

The “software factory” analogy has been around before. It’s nonsense, of course. The software analogy of a “factory” is the plant that presses CD-ROMs. Pressing the 10,000th CD-ROM of a software product is the software equivalent of building the 10,000th Nissan Maxima on a production line. But writing the software which will go on that CD-ROM is the software analogy of designing the 2005 model of the Nissan Maxima. Now, some software development is not very creative. Just as tweaking the design of a car model that’s been around for 10 years, to get something a little bit new for a new model year, is not very creative mech engineering. But it’s still design, not assembly-line production. A competent software engineer will be able to do it better and faster than a bad one. And a factory worker will not be able to do it at all.
[Comment by njdj from Slashdot thread Hackers As Factory Workers?]

What’s hilarious about this post is that point of the article is that the software industrialization will not look like a factory stamping out of exact duplicates that njdj describes! The key to understanding software industrialization is understanding the difference between economies of scale and economies of scope. What njdj describes is economies of scale – where you stamp out a boatload of multiple identical instances. Economies of scope is when you create similar, yet distinct, instances. For example, in my housing development, the houses are all similar, but not exactly the same. There are three or four basic designs used for around a hundred different houses, but the different instances of each design vary slightly. Since you can’t stamp out identical copies of the house, economy of scale doesn’t apply. However, economy of scope does apply – these houses use the same basic building materials, similar patterns of construction, the windows and doors are the same size, the plumbing and electrical wiring are the same, etc. Even though the houses aren’t identical, the construction company can build a bunch of similar, yet distinct, houses much cheaper than if they built each one “from scratch”.

I know njdj (and most of the other posters on the Slashdot thread) didn’t read the article, because the article comes right out and states:

We can now see where apples have been compared with oranges. Production in physical industries has been naively compared with development in software. It makes no sense to look for economies of scale in development of any kind, whether of software or of physical goods. We can, however, expect the industrialization of software development to exploit economies of scope.
[The Case for Software Factories by Jack Greenfield from JOURNAL 3]

I don’t know how much clearer Jack could have made his point, so I’m surprised that so many people missed it (or bothered to post their opinions of an article they clearly didn’t read). However, I’m not going to lose any sleep over it. I blogged a while ago about the the Oakland A’s exploiting the inefficiencies of baseball. Jack’s talking about exploiting the inefficiencies of software development. At some point, someone will be successful adopting a factory approach and everyone else will have to adapt. Software development has to change – you can’t expect to stay in the major leagues with a .160 batting average.

So I’m back from vacation and ready to head into work tomorrow. I’m almost over jet lag, but Patrick still thinks his bedtime is his afternoon nap. I slept thru the Tri Nations match yesterday morning, where the New Zealand All Blacks, my new-favorite rugby team, got beat bad by the South Africa Springboks. After losing to the Australia Wallabies while we were in Sydney, the All Blacks are out of the running for the Tri-Nations Cup. Winner of next weeks’ match between South Africa and Australia takes it. (note – apparently, severalreaderspointedout that I got my cups mixed up. Bledisloe Cup is between New Zealand and Australia only, and since NZ and Aus drew in their home and home series, NZ keeps that cup.)

I didn’t blog any of my vacation as it was happening, but I want to revisit two items that I think will be interesting to my blog readers – the Buildings of Sydney and the Sydney Opera House.

I went to Australia (and New Zealand) to present Metropolis. Delivering this talk (as well as the follow-up talk on Buildings and Applications) has changed the way I look at buildings and cities. I’ve lived in three different cities – Washington DC, Los Angeles and Seattle. DC is filled with old buildings, but there are no skyscrapers. No building in DC is allowed to be taller than the Washington Monument. Seattle is relatively young, and there was a big fire in 1889 that destroyed a great deal of the city. Los Angeles is…well…I’ve blogged my opinion of Los Angeles before. LA is like a movie set – it only looks good on TV. Drive around LA and you’ll find miles and miles of mini malls, but no history.

Sydney is very different. Many of the older buildings are under “heritage protection” meaning that their facade’s are protected and can’t be changed. This leads to a fascinating mix of older buildings side by side with modern skyscrapers. Paddy’s Markets, which has been there since at least 1834, is housed in a building originally built in 1909 (according to the building’s facade). However, if you check out the picture, you’ll notice that the building’s second floor is notably more modern than the first floor. That’s Sydney to a “T”, new sitting right next to, or on top of, the old. I imagine that some of the older eastern seaboard cities of America have the same combination of historical and current, but none that I’ve spent a significant amount of time in.

Of course, you can’t go to Sydney and not visit the world famous Sydney Opera House. You can read the history online, so I wont bore you with those details. But here’s something you probably don’t know about the opera house – it’s a pretty dinky opera house as opera houses go. My mother works for the Washington National Opera and I grew up hanging around the Kennedy Center so I’ve been around opera all my life. (Betcha didn’t know that about me, did ya?) The Opera Theatre of the Sydney Opera House only holds 1547 people, only about two-thirds of the Kennedy Center Opera House. It also has limited fly, wing and back stage space – the unique sail roof structure severely limits off stage space. (This isn’t an issue in the Concert Hall, which is housed under the larger sail roof and has less need for off stage space.) I found it very interesting that, as opera houses go, the Sydney Opera House looks great from the outside, but isn’t that well thought out on the inside. This comes back to Metropolis metaphor as well – what’s on the outside (in this case, the roof) severely limits what you can build on the inside (i.e. the theatre). In the case of the Sydney Opera House, it’s no problem as people come from all over the world to see shows there, even if the house creates unique logistical challenges for the company putting on the show. For enterprise apps, you probably won’t be so lucky, so design your roof with great care.

I’m back at work tomorrow, so watch this space.

I know I’m on vacation, but I had to blog this. The third issue of Architects JOURNAL is online. The first article from J3 is about Software Factories. It’s is the first of a four part series. You can check out the second article in the series from our brand new Software Factories page on Architecture Center.

Update: My pal Chris (who is blogless at this point) pointed out an article in eWeek on Software Factories.

My presentations are done. I have one more analyst meeting, and then I am officially on vacation down under for a week. I’m stoked (but don’t expect too much blog traffic around here).

Doing both talks twice in the space of a week really helped improve my delivery. I still think the Data in SOA talk didn’t go quite as well as the Metropolis talk, but the gap narrowed this time. Also helped that they were on separate days this time. I got lots of great questions afterwards. A couple of gentlemen from the Australian government grabbed me for over an hour after my Metropolis talk yesterday – one from Dept of Defense, the other from Dept of Statistics. At the Federal Architect Forum earlier this year, I spent some time with an architect from the US DoD and I’m coming to the conclusion that compared to most government agencies, DoD seems to be ahead of the curve on architecture. Of course, when you measure failure in human life, it behooves you to stay ahead of the curve. We were discussing business process and the gentleman from Aus DoD pointed out that we “mangle business processes in order to fit them into technology implementations.” Very true. We even got into some social aspects. For example, the battlefield leaders of tomorrow are in their teens today, so they are looking at how teens communicate today. They want their battle systems of the future present information optimally for those future leaders. Each generation tends to communicate differently than previous generations. His 16 year old doesn’t read or write well, but he can IM chat 6 people, send phone text messages and talk on the phone all at the same time. How will future battle systems leverage that ability. Fascinating.

We head back to Sydney tomorrow evening. This afternoon and tomorrow, we’re off to find a kangaroo petting zoo and take a tour of Canberra. There’s a big rugby match on Saturday – the Qantas Wallabies vs. the New Zealand All Blacks competing for the Bledisloe Cup. It’s sold out, but it will be on TV. There’s something about the passion of large scale sporting events like this. My parents and brother went to several matches of Euro 04, including the England vs. Portugal game that sent England home in penalty kicks. The parting after went on all night. World Cup 98 in France was the same way every time France won (though we had gone home by the final game that France won – I’ll bet that was quite the party). I know nothing about Rugby, but I’m keen to learn.