As part of the new job, I’m involved in the planning a workshop called SPARK, which Dion Hinchcliffe blogged about this morning. (Dion also writes a blog here - bringing the total to three - so I created a combined feed just to keep track of all the places he writes). My new boss Mike also mentioned SPARK this morning. In the hopes of sparking futher interest (pun intended), here’s the overview of SPARK:

SPARK is the first in a series of high-level forums hosted by Microsoft that use a workshop setting to examine “the issues that matter most” in the practice of strategic architecture and produce guidance for the industry as a whole.

Today, new social movements, advances in technology, and forces within business are overlapping to create a landscape glutted with challenges and opportunities. In many cases, these forces have driven the deployment of new technologies and the adoption of new behaviors, adding multiple layers to an already complex set of issues that must be navigated. Architects are searching for a solution that helps manage this complexity.

SOA, Software as a Service, Web 2.0, and Edge are all elements of the solution, but are they the complete picture? Are they a sufficient answer to the issues?  Can they be used together in a productive and efficient fashion? What matters most?

I have been so focused on Web 2.0 stuff that I’ve been reading a bunch of new blogs and disregarding the old ones I used to read. So I didn’t realize until today that the DSL Tools team released a new drop last week. According to Gareth, the highlights include:

• Integration into the Visual Studio SDK. According to the site, they are shooting for an April release for v2 of the VS2005 SDK, so does that mean the DSL Tools will be done in April?
• Single file format and complete visual designer for all aspects of a DSL. I’m guessing this mean we no longer have to edit the designer definition by hand. That’s a good thing. But I liked the seperation of domain model and designer, so I’ll be interested to see how I like what they’ve built.
• Domain-specifiic model serialization. This is huge – previously, the domain model dictated the XML serialization format. Now, if you can customize this, you can provide a clean model syntax and even possibly read in other syntaxes as well
• Port Shapes and a revised modeling API

Update: Apparently, I can’t read. Only the VS SDK integration is done in this build. improvements to the file format and model serialization will be in the next drop.

It’s been a long time since I cared who won the Super Bowl. But I’ve got to give it up for my adopted home team. Go Hawks!

Update: 😦

When I wrote yesterday about the Browser as VM, I made the point that extensibility is difficult as we have four major browsers and multiple OSes to deal with. What Web 2.0 company is going to be willing to bet on a proprietary extension implemented in only one of those combinations? Not many if any I would guess. However, there is one option that works across all those browsers and OSes: Macromedia (now Adobe) Flash Player.

Unlike the browser, where AJAX is a relatively new idea, Flash has been positioning itself as a platform for nearly four years. Instead of AJAX, Macromedia coined the term Rich Internet Application or RIA. RIAs share a lot in common with AJAX in that they are downloaded on demand, execute arbitrary script code and can retrieve data across the network. But the most interesting commonality that Flash has with the browser is that runs across multiple browsers and OSes.

In platform portability, Flash has succeeded where Java failed. I haven’t done enough research to know exactly why yet, but I suspect that it’s because Java tried to be a complete portable environment on day one where Flash focused on specific functionality that weren’t possible any other way – so called “skip intros” – and grew up from there. In other words, Java tried the top-down approach and Flash tried the bottom-up approach. I’m not surprised bottom-up worked and top-down crashed and burned.

While the modern browser has evolved to make it a capable platform, it still lacks some capabilities that Flash has. Most notably support for rich media. Thus, sites like Pandora, Google Video and MTV Overdrive need the capabilities provided by Flash.

While it’s hard to imagine enhancements to the browser due to the difficulties across four browsers and multiple OSes, improvements to Flash are easy to imagine. According to Macromedia, Flash has 98% penetration. Even more impressive is that Flash reaches 80% penetration with new versions of the player within 12 months.

Check out this post from Kevin Lynch for more on Flash for Web 2.0 companies. So far, the only Web 2.0 company I know about (which is to say I’m sure there are more out there) is Goowy. Which ones am I missing?

Note: this is the first in a series of Web 2.0 entries. I know I’m on record as hating the term Web 2.0, but as I wrote in that post, I do belief there is a fundamental shift underway in computing. The industry is calling this Web 2.0, and I can either spit in the wind or go with the flow. Furthermore, for the more Web 2.0 savvy among my readership, much of what I write about in this series may be old news. But I want to blog what I learn as I learn it, so bear with me.

Just as the dumb terminal was eventually replaced with more sophisticated personal computers, the dumb browser has been replaced on the modern desktop by something significantly more versatile. When the ability to process arbitrary script code was added to the browser, it became a virtual machine in its own right. Perhaps unique and special-purpose when compared to environments such as the .NET CLR, but a VM all the same. And while its unique nature makes the browser unusable for entire genres of applications – you’d never use the browser to build a server application for example – it makes it well tailored for user-centric, software as a service style applications that have become commonplace. While the browser’s scripting capabilities have been around since the mid 90s, the industry has only recently started to leverage those capabilities to build applications that run on the client inside the browser. Jesse James Garrett coined the term “AJAX” – Asynchronous JavaScript and XML – to describe this style of application.

If the browser is a virtual machine, that makes JavaScript the “assembly language” of the browser. That is, JavaScript is the lowest level of abstraction you can program the browser with.  This has pretty dramatic implications on the applications you build for the browser VM. For one, JavaScript is at a sufficiently high level of abstraction that you can use it directly and be productive. Writing an entire application in IL or Java byte code is unthinkable, but isn’t really a big deal for JavaScript. Furthermore, Because JavaScript is a text-based scripting language, protecting your code as intellectual property is extremely difficult. While obfuscators exist, in the end they can only delay the reverse engineering of your code, not prevent it. This encourages business models where the in-browser code has little if any value.

For example, the big mashup functionality these days is mapping. There are three big mapping services out there: Google Maps, Microsoft Virtual Earth and Yahoo! Maps. 266 of the 368 mashups listed on ProgrammableWeb as I write this include mapping functionality from one of those services. That’s nearly three out of four. Mapping is interesting because of the sheer amount of data involved. In fact, the code is pretty useless without the back-end data. So while I can get the code for Google Maps, it does me no good without access to the data for which I need the API key. Contrast this with the complete lack of market for browser-based rich text editors. Sure, there are various open-source script libraries like Dojo, Web Wiz RTE and Kevin Roth’s RTE. But no companies offering a rich text editor service like they offer map services. Why is that? I would think the value of rich text editing would be even more widely applicable than mapping. The problem is that, unlike the map service, there’s no back end associated with a rich text editor. There’s no way to protect a client-side-only solution such as these rich text editors. The only people who do sell rich text editor components are ones who have integrated into some back-end programming environment such as Richer Components’ RichTextBox for ASP.NET.

The browser as a VM also has broad implications with regard to extensibility. Similar capabilities are delivered by the four major browsers (IE, Firefox, Opera and Safari) across the major operating systems (Windows, MacOS, Linux, FreeBSD). So the question is, how will new capability evolve in the browser? Will the growing number of Web 2.0 companies looking to provide compelling features and differentiate themselves in the marketplace demand new functionality in the browser VM? Will one of the browser vendors be willing to take the heat of building proprietary extensions to their browser? I realize that many people have a dim view of proprietary extensions, but many features we take for granted today are de facto standards that arose from Microsoft’s proprietary extensions to IE. Most notable of these of course is XMLHttpRequest, without which “AJAX” would just be “J”. And JavaScript itself started life as a proprietary extension to Netscape before eventually being turned over to ECMA for standardization.