Roundtable Transcript, Part 1 (Continued)

The Impact of Model-Driven Development
[30:17] Burba: Yes, I place my vote with model-driven development. At Compuware we're big believers in model-driven development and frameworks. I would say one other thing, you know you guys have covered it pretty well, but another important thing to customers is not only that you can drop down into the detail of the code, but also that you remain open—that you don't become, and the frameworks don't become, a way for platform vendors to lock customers into the underlying platform. We think standards are important in that process, not only that we generate standard-based code, but also we think there's some important standards from the OMG around model-driven architecture to help standardize the transformation process of declarative abstractions like models into artifacts like code.

[31:16] Elloy: Fully agree, and true MDA and [EDD] strategies are one way that SIs for example are looking to leverage to go above the technical component framework level into the business framework level to the point that they can get a lot of leverage out of the systems that they develop for customers time and time again.

[31:35] Stover: I think I need to add a little discontinuity into the discussion. I'm going to slightly disagree…

[31:39] Phipps: No, no, no. Disagree big time. [Laughter]

[31:41] Stover: OK, I disagree big time. [Laughter] To be perfectly honest, without having a standard like MDA, some of my most successful projects have been using the UML from years ago. However, that is what I call the thinking-man's development game. I have met some of the most talented Java developers who do not understand UML, and do now want to understand UML. So I think there's a balance. While it's important, that's going to appeal to a certain segment of the developer population.

Not to weigh one against the other, but the visual development paradigm where you can deal with smaller applications more quickly, and things like application assembly versus application coding, I think is important, and there are two different ways to go about the same problem. But whether it's the biggest one because, not to raise flags, but two people who have modeling tools spoke up about modeling. [Laughter] I think it's wonderful technology, and I have had some of the most successful development projects I've ever worked on using that paradigm. However, that paradigm does not appeal to everybody, so there needs to be a balance between what I call again the thinking-man's and the everyday-man's tool.

[32:52] Elloy: If you look at where Java developers, where the population is moving, like the center of gravity, it's going offshore. It is, right. There are tens of millions of Java developers in China and India that will be looking to get proficient in Java, and if MDA and [EDD] and frameworks, technical and conceptual, and then business frameworks help them get better at their job, they mitigate the risk of offshoring. And offshoring is not a vehicle for saving costs, which is the utopian definition; it's the vehicle for generating business agility. So businesses are doing more and more offshoring.

[33:24] Phipps: But then that's surely untrue that the project's so large you can afford offshoring. Well, you know you can afford to offshore when you can afford to have a project manager managing offshore development, but if your developments are small and modular or if your developments are rapidly developed and available as service [farms] in your enterprise, that's also another way of preventing offshoring.

[33:48] Renaud: I think that one of the points that needs to be made here is that we need everything. OK. Java is a big platform that is trying to attract as large a following as possible, and we need to be able to cater to the needs of various people. In some cases UML is appropriate—it's not my first choice personally, but that's just me—and some people love it. Declarative programming, visual programming. We have to be able to support everything. Now, I will make one point. Historically, the Java community has been full of rocket scientists that love UML. And we have plenty of tools to solve these problems today. There are three or four different UML solutions in Java today. What we don't have are the other tools to give to the rest of the community, and that's where we need to be spending our energies much more than talking about the stuff we've had for years and years.

[35:01] Burba: So I disagree a little bit. OK, I'll disagree a lot. With model-driven development or frameworks, we're looking at different types of projects and solving different types of problems. There is a certain class of tools that looks to woo the small departmental corporate Visual Basic developer into the Java camp. But I think there's also a place for model-driven development even for enterprise application development. Java is moving up the triangle. Things that used to be developed in COBOL and the mainframe are now being targeted for Java, and so the implication of that is we're going to have an influx of new developers into the community, and so we have this body of gurus who have been successful; they've laid the foundations of design patterns, and they've created some frameworks that have helped us become more productive, but we're going to have an influx of what used to be COBOL developers.

Maybe they're coming from the university now, but they're going to be part of this development team and building mission-critical enterprise applications that last for 8 to 10 years. So the question is how do we take these gurus and team them with less-experienced developers and work together productively to deliver high-quality, mission-critical, big applications.