Intergrate vs. Interoperate

I found this interview with the BEA deputy CTO Benjamin Renaud via a news post on TSS.NET. BEA’s position is summed up in the following quote:

“Microsoft will standardise at the protocol level, but they won’t standardise at the API level,” he said. “Customers are not that gullible. The real level where integration happens is at the programming level.”

I like Ted’s response to this:

We’re sorry, Mr. Renaud, but integration isn’t necessarily what web services are after–interoperability, in the form of loosely coupled components that know how to exchange messages of data, are the key to truly powerful web services. If you want programmatic integration, you have to standabrdize on programming platform and language, and that’s not what web services were supposed to be for.

As to his complaint that Microsoft is engaged in a huge bait-and-switch, we believe he’s either not putting enough faith in the development community to see this conspiracy, or else he’s trying to cry foul over the fact that BEA has to compete with others in the Java space for the web services dollar, where Microsoft stands relatively alone.

However, I’m not sure what Ted’s driving at with his interop vs. integration argument. To me, they seem to go hand in hand – two great tastes that taste great together. Web services are important for both. If I’m not integrating disparate systems, I probably don’t care about interop that much.

Personally, I care much more about integration than interop. Even if I was going to build a system-of-systems all using only .NET technology, I would still use a service-oriented approach and implement those services using web service technology. The service-oriented approach allows me to be more flexible in the way I stitch my services together. Using web service technology allows me to leverage platform technology (ASMX, WSE, Indigo, etc) so I don’t have to roll the whole stack myself. The fact that I get interop “for free” by using this approach is an extra bonus that I don’t really care much about – at first. That built-in interop, even in this single-platform-which-never-happens-in-the-real-world scenario, helps make my systems future-resistant (nothing is future-proof). New customers, new partners, mergers – come what may, I have a better-than-average chance of being able to integrate it into my system. That gives me an real advantage ($$$) in the marketplace.

Of course, back in the real-world where you’re creating a system-of-systems from a series of stand-alone systems that are all built with different platforms, interop is much more important. But that doesn’t mean integration is any less important.

Type of Architects

Traditionally, our team has divided architects into three categories: Strategic, Application and Infrastructure. Gurpreet Pall, of MSA Enterprise Data Center fame and the new head of our Architecture Strategy team, suggested a different categorization scheme: Component, System and System-of-Systems. I like this scheme because it is more hierarchical where the scopes of strategic, application and infrastructure architects have small intersections.

Gurpeet’s scheme is also interesting in that component architects of system-of-systems architects don’t typically have much to talk about. Component architecture is below the abstraction layer for system-of-systems architects.

I’m not suggesting one view is better than the other, they are both interesting views into the same space. However, I’d like a better term than “system-of-systems architect”.

Authorization and Profile Application Block

patterns & practices has published a new App Block: Authorization and Profile.

This block is a reusable code component that builds on the capabilities of the Microsoft .NET Framework to help you perform authorization and access profile information.

You can read it online or download it.

Too Many Weblogs

I posted yesterday that I’m reading over 200 blogs these days. Those aren’t Scoble numbers (is he over 700 yet?) but there sure is a lot of noise. It reminds me of when I first joined Microsoft – there was so much information available and I wanted to read it all. So I went through several cycles of signing up for a bunch of distribution lists, getting to the point where I wasn’t really reading them, then removing myself. I think I’m at that point for reading blogs.

I’ve cut my list of feeds down to just 20 technical bloggers, though 6 of them are .NEAT teammates or architect evangelists in the field. I’ve also subscribed to a bunch of community feeds, the main MSDN feed and the MSFT Download Center feed.

I don’t plan on keeping my list of bloggers this low. 20 just seemed like a nice round number to start. There is so much interlinking that with the 20 I picked, I feel that I’ll still find out about the important posts without having to read so many entries. I do know that I’ll subscribe to any teammate or field AE who starts blogging, because I like to keep up on what they’re blogging about. I think that for other new blogs, I’m going to create a “tentative” category. Then I can get a feel for the blog before deciding to keep them. Of course, I can delete feeds anytime, but having a tentative category helps remind me of my level of commitment to reading the blog.

David Chappel is Blogging

So David Chappel is blogging. No, not that David Chappel.

I’ve seen David speak at several MSFT events – both internal and external. He’s great. Only downer is that he’s using Blogger which doesn’t support RSS. But Web2RSS has created a feed for him.