Nick Malik forwarded the last ZapFlash newsletter to me. I gave up on analyst newsletters like this long ago, but Nick shared it with me because it “hit directly on what [Nick] thinks an ESB is and does, and why an ESB is not a hub.” I’m not a fan of the whole ESB concept and frankly this article didn’t do much to change my opinion. However, this passage did sorta jump out at me.

[T]he main concept of SOA is that we want to deal with frequent and unpredictable change by constructing an architectural model, discipline, and abstraction that loosely-couples the providers of capability from the consumers of capability in an environment of continuous heterogeneity. This means that we have to somehow develop capabilities without the knowledge of how they might be used…[T]his means that we need to have significant variability at a variety of aspects including the implementation, infrastructure, contract, process, policy, data schema, and semantic aspects. Having this variability allows companies to have stability in their business and IT even though the IT and business continue to change. Agility, predictability, reliability, visibility, and cost-effectiveness all become that much more realistic when we can achieve that sort of abstraction.

My reading of this is that the author, Ronald Schmelzer, is advising organizations to introduce “significant variability at a variety of aspects” in their services in order to deal with what he openly admits is “unpredictable change”.

This sounds like a mind-boggling awful idea to me.

At it’s heart, any practical design – including a service-oriented one – needs to be an exercise in tradeoff analysis. You can’t add “significant variability” without also adding significant complexity, effort, time and cost. So the real question is: Is the significant variability Ronald describes worth the inevitable tradeoff in significant time, effort, cost and complexity?

I seriously doubt it.

Since unpredictable change is – by definition – unpredictable, you have no way of knowing if you will actually need any specific aspect of variability down the road. Ronald’s strategy – if you can call it that – seems to be let everything he can think of vary except the kitchen sink. That way, when said unpredictable change happens, you might get lucky and have already enabled the variability you need to handle the change with a minimum of effort.

Getting lucky is not a strategy.

Chances are, a specific aspect of variability won’t ever be needed. In other words, most of the the time, effort and money you spent building these aspects of variability will be wasted. And remember, this isn’t just a one time cost – the increased complexity from including this significant variability means you’ll pay the price in additional time, effort and money every time you have to change the system.

I wonder if Ronald is familiar with the term “You Aren’t Gonna Need It“. He talks about increasing business agility, but he eschews many of the principles of agile development. I realize they aren’t the same thing, but I have a hard time believing that they are so diametrically opposed that a core principle of agile development should be readily violated in order to enable business agility.

Maybe it’s cliche, but I try to always come back to “What’s the simplest thing that could possibly work?”. I would think that building a ton of currently-unnecessary variability into your system on the off chance that someday you’ll need it fails the “simplest thing that could possibly work” test spectacularly.

Personally, given the choice of taking advice from Ward Cunningham or pretty much any enterprise analyst on the planet, I’ll pick Ward every time.

Scott Hanselman wanted an F# version of this Play Ball! round-robin scheduling PowerShell script. Here’s what I came up with:

let randomize list =
    let random = new System.Random()
    let list'=  
        list  
        |> List.map (fun i -> (random.Next(), i))
        |> List.sort (fun (i1,_) (i2,_) -> Int32.compare i1 i2)  
    let (_,list'') = List.unzip list'
    list''

let rec makeGames teams =
    match teams with
    | first :: rest ->
        [for team in rest -> (first, team)] @ (makeGames rest)
    | [] ->  []

let teams = ['a'..'f']
let games = teams |> makeGames |> randomize

MakeGames uses pattern matching to see if the list of teams is empty or not. If the list is empty, we simply return an empty list of games. If not, we use F#’s list comprehension syntax to generate a list of games between the first team in the list and each of the remaining teams. This list is combined (via the ‘@’ operator) with the results of calling makeGames recursively. This generates the un-randomized list of games.

Once we have the list of games, we need to randomize it. I ported the randomize function above over from a version I found in Erlang. Basically, it attaches a random number to each element in the list to be randomized, sorts by those randomly generated numbers, then throws the numbers away and returns the just the randomized list. Note, the Erlang version I referenced runs randomize log(length of list) times to ensure a fair shuffle, but I thought once would be enough for this simple script.

(Note to F# team: perhaps List.randomize should be a part of the standard F# library?)

• p&p have published new versions of both the Web Service and Web Client Software Factories. Beyond support for VS08, I’m not sure what’s new but that’s worth the price of download (admittedly close to zero) right there. I assume these need the most recent release of the Guidance Automation Toolkit as well.
• W3C has published a new working draft of the Service Modeling Language. I’m really interested to see where this technology goes.
• Yesterday, Microsoft announced the Silverlight Blueprint for Sharepoint, part of a larger Software + Services Blueprints initiative that I wasn’t aware of. According to Michael Lehman (who’s blog I’ve been been remiss to read of late), S+S Blueprints has a bunch of other interesting projects including Video.Show and Outlook+Services.
• Martian Maly demonstrates how you can use DLR trees to build a statically typed add function. Literally, my very first thought after Martin presented DLR Trees @ Lang.NET was “I wonder if you could use that for static languages too?” I guess the answer is yes.
• It’s been six months, and Scott Hanselman still isn’t evil. Perhaps he could start turn his ASP.NET wiki into an evil ASP.NET wiki? Actually, I’m only linking to his post because I liked the way he described blogging as “I’m writing a book that will never end”.

• I was slammed Friday, so I didn’t get a chance to post the results of last Thursday night’s hockey game. I’m sure you’ve all been eager to hear. We lost, bad, 8-2. Personally, I was -3 and had no points, but I played much better than last week. We had three full lines of forwards, which was a big help, but I have started to find my ice-legs so to speak.
• Charlie Calvert has the now-definitive list of LINQ to Everything. Of all of them, I found LINQ over C# fascinating, especially given my recent efforts in parsing.
• Chris Tavares blogs about a distributed source control system called Bazaar. Unlike most version control systems, Bazaar is distributed which means you can use it without a server. According to Chris, you can share branches as easily as mailing a file. I wonder if you could make Bazaar work over a P2P network.
• While looking up the MSDN link for the previous coffee item, I noticed an entire new section in the MSDN Library for Open Protocol Specifications. Not much to add, just wanted to highlight their existence.
• Admitted non-designer Scott Guthrie shows off using the new version Expression Blend to build a Silverlight 2.0 app. Personally, I was most interested in seeing some of the new of built-in controls.

Nick Malik took me to task for my suggestion that Enterprise Architecture provides no value.

You implied that I could not answer the question, “How does EA demonstrate value.” That is not true. I can readily answer the question, from my viewpoint, but I chose instead to *ask* the question to see if my answer matches the various answers that I may hear back. I got a lot of valuable input, both on the blog and on the forum on Shared Insights where I asked the same question.

You are the ONLY person to reply and say that EA provides no value.

Perhaps you should read about the role and value of Enterprise Architecture from established sources before you bash the entire profession.

EA is real, my friend. It is as real as city planning. The only major city in the US without city planning is Houston. I have visited a few times, and I can honestly say that without city planning, they are a mess.

Nick also provided a link to an article in Architecture and Governance magazine. I was going to read it, however their web site is down as I write this. I feel comfortable interpreting that as a sign that I’m right… 😄

Actually, Nick’s got a point. It was wholly unfair of me to say that EA provides no value. However, I do believe the return on investment of enterprise architecture is fairly low, perhaps even negative. In other words, I shouldn’t have argued that EA doesn’t deliver any value, but instead that I don’t think it delivers enough value, given what we spend on it.

Architecture ROI is hard enough to calculate on a project by project basis. I would argue that measuring it at the EA level is probably impossible, but I think that’s both a blessing and a curse. It’s a curse because EA can’t justify their existence in terms the business can understand. It’s a blessing because if EA is running as deep in the red as I suspect they might be, the company would cut EA entirely in a heartbeat.

Since Nick started my asking a question about value, let me turn it around and ask some questions of my own:

1. How much do you think your organization spends on EA per year?
2. What do you think your organization’s EA ROI is?
3. What can you do to improve your organization’s EA ROI?