I just watched the MSDNTV episode on Whitehorse. It answered a few of my questions, but there are still many that have yet to be answered. Most of the fuzziness comes from the fact that Whitehorse’s final scope is still seemingly up in the air. How far will Whitehorse reach? And when it’s finally out there, where does UML fit into this?
From what they showed in the demo, I like Whitehorse as a concept already. Whitehorse lets you model a service provider as a “black box” that exposes functionality to other systems. By raising the level of abstraction so that the service-level implementation details are hidden, the tool allows architects to focus on the interconnections between those systems – and the composition of the larger system-of-systems. I think the ability to visualize complex systems at this level of abstraction will be a real benefit to integration architects as enterprise software becomes more interconnected and less monolithic.
What’s unclear right now is whether Whitehorse will allow you to “zoom in” on a particular service to view its underlying class structure. I think it would be a cool feature to double-click on a service in the system-of-systems view and have a class diagram pop up, showing you the gory details of the application you just selected. Whether this level of detail will be available in the Whidbey release is unclear, although it would seem bizarre to have to use another tool to look at a single system. I guess my question is this: what’s the future of Visio’s UML tools? Is Whitehorse a complementary toolset, or a replacement?
The other major feature in Whitehorse is the ability to model the infrastructure requirements of your application and validate them against the infrastructure capabilities of your datacenter. Whitehorse lets you say “My server has this set of IIS settings, and my app has this set of requirements. When I deploy this application on this server, will it run?”
I think this is a pretty brilliant idea for two reasons. One, it really benefits the consumer because it increases communication between developers and operations folk. On most projects I’ve worked on, infrastructure requirements have been modeled in spec documents, an approach that requires a lot of human intervention. Now that these requirements can be modeled in machine-readable format (and validated by machine-enforceable rules), I think it will become a lot easier to get an application out of the development lab and into the production environment.
The other reason I think Whitehorse is a brilliant idea is because I think it substantially extends the market reach of Visual Studio. Prior to Whitehorse, it didn’t make much sense to spend money on Visual Studio licenses for operations people. After all, since the infrastructure guys don’t write code, what value does the IDE bring to them? Now that Whitehorse can add significant value to the day-to-day life of a network architect, there’s suddenly a compelling reason for companies to spend money on Visual Studio licenses for non-coders. With Whitehorse, Microsoft can now convince enterprises that they need to buy VS not only for their developers, but for their network guys too. This translates into more money and enterprise penetration for MS.
All in all, I’m impressed with my first glimpse of Whitehorse. I’m interested to see how this product evolves between now and the Whidbey release.
