• Sorry for the posting lag. Had a few technical difficulties around here. In the process of moving hosts, so expect more glitches.
• My talk at the p&p Summit on Monday went really well. At least, it felt good and the applause at the end felt genuine. I recorded the audio on my laptop, so I’ll be posting a Silverlight version as soon as I figure out how to adjust the levels so their somewhat consistent. Paraesthesia and #2872 have reactions.
• Speaking of the p&p Summit, Scott Hanselman posted his ASP.NET MVC demo from his talk. Said ASP.NET MVC bits aren’t available yet, so you can’t, you know, run the demo for yourself. But at least you can review what the ASP.NET MVC code will look like.
• I stopped by the SOA/BPM conference last week and saw Jon, Sam and Jesus among others. Spent quite a bit of time talking to Sam and his Neudesic colleagues about this “physically distributed/logically centralized” approach that I think is hogwash. It sounds to me like Neudesic approach is really federated not centralized, though I’m not sure David Pallmann would agree. Federated makes much more sense to me than centralized.
• Nick Malik continues his series on SOA Business Operations Model. I especially like his point that this isn’t a series of choices, you need to “look at your company and try to understand which model the business has selected.”
• The first CTP of PowerShell 2.0 is out! Check out what’s new on the PowerShell team blog and Jeffrey Snover’s TechEd Presentation. (via Sam Gentile)
• Soma announced updates to VC++ coming next year, including TR1 support and a “major” MFC upgrade to support creating native apps that look like Office, IE or VS. I get supporting TR1, but the idea that people are clamoring for MFC updates is kinda surprising. Many years ago when I first came to MSFT, a friend asked “But don’t you hate Microsoft?” to which I responded “No, I just hate MFC”. Obviously, not everyone agrees with that sentiment.
• Steve Vinoski thinks there’s no hope for IT. Funny, I keep agreeing with Steve’s overall point but disagreeing with his reasoning. I still don’t buy the serendipity argument. I like compiled languages. And I think he’s overstating the amount of “real, useful guidance” for REST floating around. Basically, there’s “the book“.
• In widely reported news, Windows Live launched their next generation services. Don’t bother with the press release, just go to the new WL home page.
• Speaking of WL, Dare Obasanjo points to the Live Data Interactive SDK page where you can experiment with the WL Contacts REST API. It gives you a good sense of how the Web3S protocol works. Pretty well, IMO. However, how come WL Contacts Schema doesn’t include some type of update timestamp for sync purposes? If you wanted to build say a Outlook to WL Contacts sync engine, you’d have to download the entire address book and grovel thru it for changes every sync.
• Speaking of Web3S, I’d love to see some info on how one might implement a service using Web3S. Yaron Goland positions Web3S as an alternative to APP that WL developed because they “couldn’t make APP work in any sane way for our scenarios”. I’m sure other folks have similar scenarios.

• My daughter had her tonsils & adenoids out on yesterday. It was a routine procedure and it went by-the-numbers, but any parent will tell you it’s hard to see your kid in a hospital bed.
• Given the previous bullet, I’m not at the SOA/BPM conference for the big announcement. Don’t worry, there’s lots of other folks covering the news.
• It was a crappy sports weekend in the Pierson house. Va Tech snatched defeat from the jaws of victory, Southern Cal never led at Oregon, the Capitals lost twice, and the Redskins got blown out by the Pats. At least the Caps won big yesterday in Toronto.
• Speaking of the Capitals, Peter Bondra retired Monday. I still think it’s a travesty that he didn’t spend his whole career in DC, but I’ve made my peace with it.
• Nick Malik has a great series on business operations models and how they apply to SOA. Regular readers should be unsurprised that I favor low standardization, though I can see the value of high integration. That makes the Coordinated Operating Model my fav, though I can see the benefit of the Diversified Model as well. I can’t wait to read what Nick has to say on changing models.
• Speaking of Nick, I’m doing a roundtable with him on “Making SOA Work in the Enterprise” @ the Strategic Architect Forum. Should be fun. Sorry for the lack of linkage on this, but it’s an invite-only event.
• Jezz Santos has a new series of white papers on building software factories. First up “Packaging with Visual Studio 2005”
• Aaron Skonnard has a new whitepaper on using the WCF LOB Adapter SDK with BTS 2006 R2. I’ve been building one of these things recently, so I’m looking forward to checking that out. (via Sam Gentile)
• Tim Ewald looks at Resource Oriented Architecture (when did ROA become a TLA?) and wonders “what if your problem domain is more focused on processes than data?” I wonder that all the time. (via Jesus Rodriguez)
• It’s not just durable messaging – Libor Soucek also disagrees with my opinions on centralized control. I agree 100% with Libor that centralized management would make operation’s lives “much, MUCH easier” as he puts it. However, that doesn’t make it feasible at any significant scale. Furthermore, I wouldn’t describe an approach that requires that “all services adopt [the] same common management interface” as “pragmatic”. Frankly, just the opposite.

David Pallmann of Neudesic responded to my comment that “Physically distributed but logically centralized” didn’t make any sense to me at all:

What exactly does this mean? To some this may sound like a contradiction.

This simply means that a bus is physically more like the point-to-point architecture (spread out, no hub) but functionally more like the hub-and-spoke architecture (pub-sub messaging, centralized configuration and activity tracking, easy change management).

Unfortunately, I wasn’t confused about the seeming contradictory nature of these concepts. In other words, I understand the “what” and “how” of David’s physically distributed/logically centralized approach.

I don’t understand the “why”. As in, “why would you want to do this?” or “why do you think this would work at any significant scale?”.

If we check out Neudesic’s page on their ESB product (which David pointed me to) we find the following blurb:

Centralized Management
The distributed nature of service oriented programming can create a management nightmare. Neuron·ESB supports this distributed architecture while simultaneously centralizing monitoring and configuration.

SOA’s “distributed nature” is it’s primary strength. SOA’s not primarily about standards or ease-of-connectivity – though those obviously play a role. It’s about enabling decentralized decision making. Since you can’t be both centralized and decentralized, enforcing centralized management basically negates SOA’s primary strength. This seems like the worst of both worlds to me. All the hassle of distributed decision making combined with all the hassle of centralized management.

Yes, decentralized decision making can create a management nightmare. Personally, a management nightmare is much more attractive anything centralized approaches have ever delivered in the IT industry.

Dare Obasanjo recently wrote “If You Fight the Web, You Will Lose“. He was talking about the Web as a Platform, but it’s good general advice. Can you imagine applying the marketing blurb above to the Internet at large?

Centralized Management
The distributed nature of service oriented programming the Internet can create a management nightmare. Neuron·ESB supports this distributed architecture while simultaneously centralizing monitoring and configuration.

If the Internet can somehow get by without centralized management, why can’t you?

Steve Vinoski has raised a bit of a flame war by admitting he has lost the ESB religion. Given that I’ve never been a fan of ESB’s anyway, there’s a lot there that I agree with. In particular I liked the description of “magical framework” middleware, blaming enterprise architects for driving ESB’s as the “single integration architecture” even though a single *anything* in the enterprise is untenable and his point that flexibility means you don’t do any one thing particularly well.

However, Steve goes on to bash compiled languages and WS-* while suggesting the One True Integration Strategy™ is REST + <insert your favorite dynamic language here>, then acts surprised that the conversation denigrates into “us vs. them”. When you start by saying that compiled language proponents “natter on pointlessly”, I think you lose your right to later lament the depreciating level of conversation .

All programming languages provide their own unique model of the execution environment.  Dynamic languages have a very different model than compiled languages. Arguing that this or that model is better for everyone, everywhere, in all circumstances seems unbelievably naive and arrogant at the same time.

On the other hand, I do agree with Steve’s point that most developers only know a single programming language, to their detriment. One language developers often miss a better solution because their language of choice doesn’t provide the right semantics to solve the problem at hand. Developers could do a lot worse than learn a new language. And I don’t mean a C# developer should learn VB.

The most pressing example of picking the right language for the right problem today is multi-threading. Most languages – including dynamic languages – have shitty concurrency semantics. If you’re building an app to take advantage of many-core processing, “mainstream” apps like C#, Java and Ruby won’t help you much. But we’re starting to see languages with native concurrency semantics like Erlang. Erlang is dynamically typed, but that’s not what makes it interesting. It’s interesting because of it’s native primitives for spawning tasks. I don’t see why you couldn’t add similar primitives for task spawning to a compiled functional language like F#.

As for REST vs. SOAP/WS-*, I thought it was interesting that Steve provided no rationale whatsoever for why you should avoid them. The more I listen to this pissing match debate, the more I think the various proponents are arguing over unimportant syntactical details when the semantics are basically the same. SOAP is just a way to add metadata to an XML message, much as HTTP headers are. WS-* provides a set of optional message-level capabilities for handling cross-cutting concerns like security. Past that, are the models really that different? Nope.

For system integration scenarios like Steve is talking about, I’m not sure how important any of the WS-* capabilities are. Security? I can get that at the transport layer (aka HTTPS). Reliable Messaging? If I do request/response (which REST excels at), I don’t need RM. Transactions? Are you kidding me? Frankly, the only capability you really need in this scenario is idempotence, and neither REST or SOAP provides any standard mechanism to achieve that. (more on that in a later post)

I understand that some vendors are taking the WS-* specs and building out huge centralized infrastructure products and calling them ESBs. I think Steve is primarily raging against that, and on that point I agree 100%. But Steve sounds like he’s traded one religion for another – “Born Again REST”. For me, picking the right tool for the job implies much less fanaticism than Steve displays in his recent posts.

Nick Malik lays out what he thinks are the four business cases for integration:

Assume we succeeded, and our systems are all optimally integrated.  What has changed?

1. We have better business intelligence.  We have better understanding of our customers, our partners, our products, and our business.  And from that understanding, we make better decisions.  Those decisions are made in a federated manner using self-apparent information.
2. We have end-to-end business processes that cross multiple systems, multiple roles, multiple geographies, and multiple data stores, all aware of and supporting the needs of the customer.
3. We have end-to-end awareness of the metrics that drive both dissatisfaction and cost, and we can take that knowledge and apply it to making our business better.
4. We have a more efficient enterprise, more able to grow to a larger size, at an accelerated rate, and still respond with agility to changing business opportunities.

I put to you that, in fact, we only have one business case for integration: better business intelligence. The other reasons Nick lists are either redundant or not as important to the business – at least in the general case – as you might think.

First off, #3 from Nick’s list sounds suspiciously like #1. If there’s a difference between “better understanding driving better decisions” and “applying awareness of metrics to making our business better”, I don’t know what it is. We’ll send one of them off to the Dept. of Redundancy Dept. and be done with it.

Second, I don’t think the business cares that IT has multiple systems or multiple data stores. If the business could run on one big centralized system that could meet the needs of the customer (aka the ERP fantasy), they’d be fine with that. The fact that realities of modern enterprise IT require splitting up capabilities across many systems is an implementation detail that frankly isn’t a concern of the business.

Besides, what’s the business benefit here? News flash: the enterprise already has end-to-end business processes that cross multiple systems, multiple roles, blah blah blah. They’re just not automated end-to-end. Does the business care that their not automated? Not a bit. Sure, they care about processes are slow, costly and error-prone, which manual processes tend to be. But it’s those negative characteristics that the business cares about, not integration. Besides, making processes quick, cheap and error-free sounds a lot like making them efficient. In other words, more work for the Dept. of Redundancy Dept.

Finally, I don’t think efficiency and agility is as important to the enterprise as Nick makes it out to be. I mean, the enterprise will say it cares about efficiency – especially in front of the stock holders. But when it comes to putting it’s money where it’s mouth is, the enterprise doesn’t, more often than not. Think about how success is measured in the typical IT project. Is efficiency one of the criteria for judging success? Not really. Will your project stakeholders let you run over budget and ship a few months late, just to improve efficiency? Probably not, unless that efficiency gain is both demonstrable and dramatic.

Of course, there are certainly specific examples where a automation or efficiency business case for integration can be made. For example, if replacing a specific manual process with an automated one has a large and measurable ROI, the business will likely be interested in making that investment. If you have a certain process that you do over and over that’s core to the business, the business will probably be interested in optimizing the frak out of it. For example, I would guess a delivery company like UPS or FedEx has spent a lot of time and money on optimizing their delivery processes.

But what it sounds like Nick’s talking about here is making a general case for making all our systems “optimally integrated”. Given that our current systems aren’t, this would take significant time and money. Yet the tangible benefit to the business is at best nebulous. Nick thinks improved integration will allow the business to “respond with agility to changing business opportunities.” He’s probably right. But how do you quantify this agility? How much will we save in the future for what we’re spending today? For the general case, the answer is “it depends”. It’s really hard to fund a project when it’s projected ROI is “it depends” .

However, business intelligence is a no brainer for the enterprise to invest in. Giving decision makers better and more up-to-date information, that’s a tangible benefit that the organization can quantify now. If you can quantify the value of a project, you’ve got the start of a budget. Of course, all that juicy data is smeared across a variety of systems, which means integration. Again, the enterprise doesn’t really care about said multiple systems or integration, but they care about the outcome.

Nick recommends to SOA folks that “if you aren’t already working with your BI team, pick up the phone. Their mature processes and practices are able to address many of your issues, and the natural synergy between BI and SOA can make them a strong ally in the fight for a better, faster, cheaper, and more intelligent enterprise.” Good advice. Otherwise, selling integration to the business isn’t much different than selling them SOA. In other words, don’t sell it – just do it.