Is VS.NET ready for enterprise? (4)

 

LT: Ten years ago this conversation probably would have centered on object-oriented programming, yet so far it hasn't come up.

MD: OOP is a small part of the bigger picture at the enterprise level. What we're doing now is analogous with the way Visual Basic hid underlying complexity. You simply can't spend all your time at the language level and get your projects out the door. You have to think at the component level and the project level. Underneath you'll still find all the principles of OOP, such as data abstraction, encapsulation, and information hiding. But as an industry we're focusing at a higher level of abstraction.

LT: Does that also hold true for the messaging-based programming model?

MD: The messaging model places a little more emphasis on the workflow aspect. I see it helping to break down barriers between business modeling—thinking of workflows through your business—and application development per se. The workflows act on objects, so if anything, .NET-based architectures tie OOP and messaging together and provide more commonality.

LT: What does .NET-based architecture do for developers that's new?

MD: In a word, patterns—Microsoft's paradigm for using a set of components. Patterns aren't new, but they get much more momentum with .NET. The focus for an application architecture should be to provide a set of models for common architectures. So you're looking less at a core object model than on pattern mechanisms. And both developers and ISVs can build on Microsoft patterns, of course. We could provide patterns for how to build certain classes of applications on top of .NET—for example, ones for building B2B or B2C apps. I can imagine some of those becoming more verticalized for particular industries, such as logistics and financial services. But initially we're focusing on horizontals, along with providing powerful pattern-generating mechanisms. On the enterprise side, a bank could build a number of different apps and in doing so generate patterns for how to use .NET and capture the essence of the bank's needs. Once those patterns have been generated and distributed, application writers will find it harder to make mistakes.

ISVs can't do patterns by themselves, so all this really depends on the Microsoft .NET architecture. In this environment a customer can build both patterns and components that are reusable. It's easier and more appropriate to do a pattern-based architecture, reusing not just components but whole architectures.