A few days back I finally ended reading Nicholas Carr's polemic "Does IT matter – Information Technology and the Corrosion of Competitive Advantage". Being in a company that has "IT" in its name, the contents of these book are very relevant. The author spells a message similar to Fukuyama's, but applied to IT, stating that IT cannot be seen as giving a real competitive advantage in today's markets: whatever lead the use of Information Technology gives to a given organization, will be quickly replicated by its competitors. Additionally, the author defends that IT is becoming infrastructure, much like electricity or the railway (or other means of fast transportation). This analogy with electricity actually is used throughout most of the book to sustain the main thesis: no organization strategy today is based on the fact that the company has access to "state-of-the-art" electricity. And, consequently, no organization can base their strategies/market leads in investments in information technology.

This book had a lot of impact a few years back, and like Fukuyama's, has strong, extremely intelligent and well built arguments. It's a book I profoundly disagree with, as well, one that made me scribble lots of notes on its margins. XXX wrote a book dedicated to contradict Carr, and there is information all over the net about this, so I doubt I can add much to this argument, so I'll just leave some notes: there are a lot of anecdotes in the book that justify some positions. While stories and specific cases are interesting to know, they are hardly proof of anything: there are probably as many examples pointing in the opposite direction. The last part of the book I found especially dishonest, when the author compares the impact of IT with that of basic living conditions stuff, such as clean water to drink, or sanitation. My answer to this is: can't the same be said of BOOKS (=recorded human history) and that same water/sanitation? We wouldn't have this world without it. This is the stuff of journalist rhetoric, and not honest discussion.

ANYWAY, changing gears, I do think several of the arguments in the book make perfect sense. The emerging trend of moving into cloud-based, hosted, software, is clearly a step that brings more truth the analogy of electricity and IT (software is just… there, somewhere, I don't really care). Having the software is no longer the advantage. At least, not for long periods of time, as it will be replicated by competitors sooner or later. So it all comes back to good, ol', business strategy and practices.

The question I now pose myself is: how can I, aware of this line of reasoning, "sell" a project to a customer based on its technology merits? I happened to have a conversation with a long-time client and business partner about the book, which he had also read, and 5 minutes later the topic changed to a possible new project we are doing with them, where I am proposing brand new technology, one month old. I couldn't help feeling something was wrong. I am going forward with it, especially because it's a very sound architectural approach to the specific business problem, but I feels uncomfortable anyway.

Changing to the second, related, topic of this post: in college, quite a few years back, I remember studying Amdahl's Law. It basically states (if I remember correctly) that the impact of a given change/optimization on a component of a system has an impact on the full system that is proportional to the relative importance of that component in the full system. Simple proportionality rules. An example. Like I said above, I have this situation where I am considering using this new technology that just came out. In the typical projects we do at |create|it|, 40-60% of the effort of a given project is spent in development/programming tasks, so let's consider 50% as the average. Let's suppose this technology is applies to 10% of the project, and that it allows me to cut in half (50%) the development time. This means, summit it up, that if the project had 100 days of development, we'd be saving the customer 0.5 * 0.1 * 0.5 * 100 = 2.5 days, or about 2.5% of the total cost of the project. And this is discounting the learning curve, obviously.

This whole rant is related to constant flux of innovations and new technology being made available almost everyday by Microsoft and other vendors ("can't they just stop for a few months?" – sentence I heard recently), and it serves as a kind of reality check. It's important to measure the impact of the technology we choose for our projects, especially if it's new technology. I'm just bundling here for the sake of example, but make sure you have an answer, when a customer asks you what's in it for him when you decide to use Linq, the Entity Framework Asp.Net MVC stuff, WCF/WPF/WF, Windows or Sql 2008, etc.

That said, and since I personally thrive on innovation and breathe new technology :-), I'll make sure I have that answer. It's a different world, out there in "Does IT matter"-land.

By the way: the new technology I mentioned is the BizTalk Adapter Pack.

The post «Does IT Matter», and Waves of Innovation appeared first on Blog IT.

D will be a declarative language aimed at non-developers, and will be based on eXtensible Application Markup Language (XAML), sources, who asked not to be named, said.

I guess this explains one of the (NDA’d) presentations we had at last year’s MVP Summit, by the man now titled «Microsoft’s Chief Modeling Officer», Don Box.

The discussion thread following this post is already very long, and several of the posts either raise problems with modeling/higher abstraction, and others just complain about “yet another language“. On my personal opinion, it makes perfect sense to have new languages that are good at new, specific tasks. I’m still now sure, for example, that bringing LINQ to C# is good, in terms of aspects like language-cluttering and database-coupling, but most of the time these aspects are neglected in discussions of LINQ. On the other hand, in this SOA world of today, I think it COULD make sense to have a “service-oriented language”, with primitives to send/receive messages, define message schemas, handle service/message versioning, governance, deployment, logging and monitoring built into the language itself.

So my take in this is: go D! 🙂 I’m looking forward to try it out and see how far it can be pushed. It it can help me do more in less time, I’m all for it.

The post «D» Modeling Language appeared first on Blog IT.