LT: What changes in the development environment itself will most affect enterprise developers?
MD: Being able to integrate the VS.NET IDE with ISV lifecycle development tools makes it easier to tackle large-scale projects. Visual Studio .NET has been reengineered substantially, with a whole new framework that makes it easier to integrate the VS.NET IDE with third-party lifecycle tools, such as ones for project management, modeling, version control, and testing. Today they all function as separate tools. With VS.NET, developers won't be thinking, "I'm invoking this separate tool." They'll just be using another function of their IDE.
LT: How did Microsoft swing this?
MD: They provided the ISV community a common framework to use—a complete set of technical APIs, and the Visual Studio Integration Program, which supplies technical assistance, early access, and marketing support. Microsoft has always been good about enabling the ISVs when it develops a new platform, and it's learned a lot of lessons along the way, which it's applied specifically to the development area. Microsoft is definitely easier to work with than most other vendors. Also, Microsoft has been able to couple the development environment tightly to the underlying framework. And because of the common platform, the cost is lower for an ISV to bring up new functionality in this environment. As a consequence, developers get not only the current capabilities of the platform but more from the community of providers building on top of the framework.
LT: Good as all this sounds, there's going to be a learning curve. What do you recommend IT managers do to bring their teams into the .NET era?
MD: The technology's great—no question about it. So it's really more a human issue. Training has a short half-life if not applied, and success breeds success. So you need to get the lessons learned in a contained way. Take some of your best people and put them on a real-life project that's important to your business. Pick a project you can apply .NET to quickly. It could be an application or set of components. And while you're doing all this, in the background think about having an overall architecture for the domain you're in. Architectural issues are a little independent of .NET, but without an architecture, it's hard to take full advantage of .NET. I think some organizations will need to get a better handle on that.
LT: Sounds like a plan for the developers. How about one for existing code?
MD: A lot of things can carry over, including lifecycle processes such as configuration management and change management. As for current applications, if you've been developing business models, you have a starting point. For whatever you're not going to migrate, your model provides the foundation for encapsulating that. There's no silver bullet here, but I'd pick the dozen or so services that are critical and package them up as Web Services.
