Again, I’m late to the story but I think it’s ultra-cool that MS Research released the source code to Allegiance. At 511 MB, it’s almost thirty times bigger than Rotor + Gyro, which is a significant code release in itself, though honestly, only about 5% of the Allegiance archive is code, the 95% is in the “Artwork” subdirectory. That still leaves about 25MB of compressed code.

I’d love to see a port to MC++, a la Quake II.NET. Is anyone working on it?

I had a few negative things to say about InfoPath a while back. Today, I finally used it to solve a “real” problem and I was extremely pleased with the result.

I’m working on some team stuff and needed to collect a bunch of info on all my teammates and stick it in an XML file. Traditionally, I’d have to send out email asking everyone to send me this info, then manually cut-and-paste the results into an XML file. Instead, I whipped up an InfoPath form (well, truthfully, I whipped up several – but that’s just because I’m not familiar with the tool) and stuck it on a SharePoint site. Now, all my teammates can go fill out the form and I can merge the results together in one big XML file. All in under an hour, including learning curve. InfoPath even supports pictures, so my teammates can even provide a photo of themselves in the form.

I’m not exactly uninstalling VS.NET, but it’s good to know how well InfoPath hits the mark for target scenarios like this one.

I think it made the rounds in the blogsphere, but I’ll post it just the same: Pat Helland’s TechTalk on TheServerSide.NET was published late last week. You know it’s not your run-of-the mill interview when one of the questions is: “Why is Hooking Shit Together a more appropriate term?” and answers like ” Sometimes I want to talk about cleavage a lot”.

Seriously, one of the things I think was most important was Pat’s answer to the question on integration challenges:

When you’ve had a couple apps that have been independently designed, they have different assumptions about the world. Different assumptions about inventory, different assumptions about customers; they probably don’t even have the same snail mail address format. It’s true that we can connect the bytes back and forth with IP and TCP today, but that doesn’t do me anymore good than if I can pick up the telephone and talk to China, and if I’m speaking only English, and they’re speaking only Mandarin, we still can’t communicate very effectively. I can hear some cool sounds, but it doesn’t help get work done.

The same thing’s occurring when you bring applications together. The semantics of the interaction is a challenge. It’s very, very difficult across an enterprise to get a common understanding of what a customer is, is a great example. Because, this half has got these fields, and that half has got those fields, and maybe you can get some common fields of understanding, but there’s still all these differences that are in there.

A huge advantage that we have is XML. XML and XML Schema have allowed for at least the expression of what the data formats look like, even though that hasn’t helped with all the semantics. But it’s a good start. We don’t have to worry about parsing, we don’t have to worry about a lot of those details. But we still have a huge road ahead of us in terms of rationalizing how we understand the data across differently and independently designed applications.

This leads back to the SOA vs. SOP question. Being able to send a message is one challenge. It’s an entirely different challege to get a consistent idea of “customer” or “order” across your enterprise systems. Both challenges are important but distinct and are important to different levels of architect.

I also thought his best practice comments were facinating:

I would argue that the biggest best practice is pragmatism. Don’t do anything unless it makes financial sense.

Service-oriented architectures allow you to make whatever business choice fits. Because it talks about these being independent things, that can then hook together with others, using messaging, and using the sequences of messages that flow. That then takes the decisions of about what you bulldoze and you don’t bulldoze and puts it back where it should be: in the pragmatic business guy’s hands.

This leans heavy to towards Realist, but that doesn’t make it any less true.

Inspired by my post on the types of architects, Michael has blogged on architect behavior: the Purist vs. the Realist. I leaned heavily to the purist side earlier in my career, but I have evolved to be more middle-of-the-road between the two. (note the use of the word “more” implying that I have not yet reached the middle-of-the-road).

Michael implied that I care about title and function more than behavior. Of course, no one has “Realist Architect” on their business card. I guess I’m wondering: if we asked this question on a survey (Are you a total purist, mostly purist, slightly purist, middle of the road, slightly realist, etc?) would anyone answer it?

At least one person was interested in an OPML of MSFT .NEAT and AE bloggers. So I hacked them out of my full blog roll and posted it on my site. I will be keeping it up to date, so check back every once in a while. I added a link to it in my nav bar so it is always available.

I love dasBlog. I was able to make one small change to the web.config file and now the OPML file is addressable while still being easily managed via dasBlog’s blogroll editor. Sweet.