Could Next-Gen Modeling Spell the End to Java Heydays?

Execs from IBM's Rational Software unit say that Java devs looking for the "next big thing" should look up-the-stack from new J2EE skills, and instead bone up on "abstraction skills" -- such as UML-based modeling. Roger Oberg, director of market management at IBM's Rational Products unit ticked off 5 keys to why modeling tools are poised to become more powerful than ever -- and ready to help devs write, integrate, deploy and update applications without coding 100s or 1000s of lines of Java/J2EE.

Tags: Modeling, Oberg, Abstraction, Patterns, J2EE, Devs, Implementation Technology,

Some execs from IBM's Rational Software unit say that Java devs looking for the "next big thing" should look past new J2EE skills and bone up instead on "abstraction skills" such as UML-based modeling.

Dev tools are moving up the stack, says Roger Oberg, director of market management at IBM's Rational Products. Standards, such as UML (Unified Modeling Language) are dramatically improving modeling's capabilities beyond simply documenting code you've already built, Oberg predicts.

The stage is set, he says, for UML and other modeling tools to help devs write, integrate, deploy and even change/update their code -- without the need to write 100s or 1000s of lines. Further, it's set for a shift from Java-centric to model centric development.

Inside the Java/J2EE Shift
The key to the productivity benefits of modeling is that they have "real semantic meaning, so they're not just whiteboards," Oberg said. "Developers shouldn't be convinced that modeling is worth their time by 'it's good for you' kind of statements," he said. "They should be convinced because they'll derive real value from it."

Oberg points to 5 "real world" benefits available (detailed below), or coming soon, in state-of-the-art modeling tool that are likely to make a developer's life easier, less stressful and maybe even more fun and profitable. They include easier code generation, better workflow and simpler life cycle management.

But why should experienced, senior Java/J2EE devs feel the need to change?

But, many developers are skeptical that modeling can be truly valuable or useful in helping them with their day-to-day coding responsibilities. Oberg responded, noting: "Grady Booch in much of his writings of late says abstraction is the key. If you think about it, if you abstract yourself and your understanding about software development from any particular implementation technology and become expert at, for example, modeling software, so your application and your skills are portable, that is a definite boost to your career because it makes you more valuable to your employer."

What? We asked point-blank, aren't most senior J2EE developers today looking at furthering their J2EE skills, not abstracting them? "You gotta ask these developers what kind of turn have we seen in the implementation technology called J2EE over the past few years? There were guys telling us that about COBOL 10 years ago, so being expert in an implementation technology is a terrific thing and has its heyday. There is a point in time where that is exactly the place to be. But, abstracting your knowledge of software development, and using methods to abstract your skills so that you understand how to build software better independent of software implementation technology is a longer-win strategy.

Does Oberg have any evidence for that kind of thinking? "If developers look around them, Oberg replied, "they'll see that's who getting paid more money; that's who's getting great job offers -- people who may or may not know deeply any implementation technology, but understand know how to build software using many different implementation technologies."

Oberg concedes that "devs can get too abstracted," and so suggested the middle ground is "about getting at least one layer higher than the implementation language -- and UML is at least one layer higher."

Given that suggestion, it's only fair to ask just how much power UML (and modeling, in general) has to generate code -- not simply document it.

Below is Oberg's 5-point list of how today's (and tomorrow's) modeling is not your father's modeling.

Top 5 Productivity Benefits for Devs
from Next-Gen Modeling (Circa 2003-04)

1. Modeling helps developers automate code routines and developments -- Today's modeling tools can accelerate development by helping devs speed through some of the more dreary or repeatable aspects of a project. Today, modeling tools can capture Best Practice routines and make them available for sharing with other developers -- whether they are basic Java/J2EE, .NET patterns or even a developer's customized pattern, Oberg told IDN.

Rational Rapid Developer, introduced in May, abstracts some of the core complexities of Java client/server and web-based app development, and uses models (and can import UML models) to abstract J2EE development. While a .NET version is not available yet, the product is written in a way that is abstracted from the underlying language, Oberg said.

2. Pattern-creation engines customize the utility for modeling -- Modeling tools, including Rational XDE, are pushing the envelop to allow developers to share internal, customized patterns and small components.

"Using modeling to capture patterns let developers link patterns to code templates so you can automate the generation of a routine," he explained. The result is that modeling provides devs a way to preload a template that equals a J2EE pattern "so the whole team can use what an individual developer has created," Oberg added. These can be extremely small, customizable patterns, or assets, he added, down to the level of an individual JavaBean. This use of model-driven patterns "is a way of automatically generating [code] that developers often do by hand, but is a waste of their time, frankly," Oberg said.

3. Better reuse of "larger-scale components" via XML -- The Reusable Asset Specification (RAS), proposed and developed by Rational, IBM, Microsoft, Flashline and ComponentSource. "One of the big issues for component reuse in the 10-12 years I've been in the development world, has been the lack of a way to consistently describe components, and no way to baseline the component," Oberg said. RAS is a language-independent approach to looks to identify components via XML descriptor files.

"We have high hopes that [RAS] will enable developers to really do asset-based development…because when we have XML files that describe a component, developers will have a lot more visibility into the nature of a component [or patterns and existing code], as well as where it came from," Oberg added.

4. Modeling features are part of the unified IDE -- Modeling used to be totally separate from the hands-on development experience of using tools or an IDE. Modeling options are now more commonly available within IDEs.

Currently, Rational provides modeling inside Websphere Studio or the Eclipse IDE. [While there are no concrete plans to bundle Rational's technologies with .NET, Oberg did tell IDN that the company continues to work with Microsoft.] This changes the whole user experience, Oberg said, so modeling is part of the development environment so a developer doesn't have to shift [from one platform to another].

For .NET and J2EE developers, Rational XDE supports developer-created patterns. "If you've defined a set of known good solutions for your own work, and you write the pattern, store it off as an asset in the XDE simple asset repository and then you can pull it up, or share them, on demand."

5. Modeling-driven development takes pain out of change management and otehr elements of the software life-cycle -- Change management and code maintenance can be one of the most costly aspects of coding projects. Rational is aiming to make its modeling and RAS (asset management) key elements of a software life-cycle platform that would let developers, as well as business analysts, access code components for changes and updates. One key is the Rational Unified Process (RUP) where software development is looked at as a series of workflows that would make it easier for different members of a software team to share, hand-off and/or integrate their work.

"What are the workflows associated in development software, and [through RUP] we have harvested the most effective ways to address the architecture requirements of software development, how to do construction and testing and such," Oberg said. "These are a set of workflows performed by different [professionals] in a software development team. Because development is a team sport, it's rare that a developer does everything in the process. If these workflows are related, it makes sense to create a platform that would let developers seamless do their handoffs," he added.

And, will this approach be extended to code management tools, such as Tivoli. "We intend to integrate software development platform with Tivoli, but we haven't made any announcements about when we'll do that," Oberg told IDN.

Up Close with Rational -- and Modeling
IDN: With IBM acquisition of Rational, how important is modeling to IBM's overall offering to developers? Will model technologies/tools be as important as Java, for instance?

Oberg: IBM recognized the key to the business value proposition for companies around software development is to make software easier and faster to build without sacrificing quality. The key to doing that is abstraction, and connecting the dots, modeling is an important abstraction of the coding activity. Today's cost-conscious IT environment has helped attract growing interest in modeling, and in fact that was a contributor to IBM's decision to buy Rational.

IDN: Your approach lately seems to be emphasizing Best Practices for developing and managing software, rather than just shipping tools for particularly languages. Is it true that you're as interested in sharing your knowledge of how to build software rather than simply supporting one language?

Oberg: It's as important, if not more important, to understand the best way to write software, and then make the tools functionality follow that rather than build tools and figure out how they can be used. It's a big part of the Rational story that we provide Best Practices, tools and services -- not just language tools.

IDN: So today's modeling is part of that, right? That assumes that modeling has become more powerful, and is more than just whiteboarding. Is there true and powerful code-generation associated with today's modeling tools?

Oberg: Yes, definitely. Model-driven development has some key productivity gains today, and is one of our key initiatives that we unveiled at the Rational user conference.

IDN: How would you describe model-driven development? Is it the same as MDA from the OMG?

Oberg Model-driven development encompasses the MDA [Model Driven Architecture] movement. But it means a bit more from our standpoint. We want to make modeling an integral part of what developers do, and not just in terms of designing but in reducing the amount of hand-coding they do and understanding the behavior and performance of the components they build.

IDN: Is that move to push the envelop on modeling for the developer part of what IBM found compelling about Rational, aside from its general interest in modeling?

Oberg: I think it was a significant motivator. I think IBM recognized that the key to business value proposition around software development is to make software easier and faster to build without sacrificing quality. And, the key to doing that is "abstraction." So, to connect-the-dots further, "modeling" is an important abstraction of the coding activities.

IDN: So, are you saying that this is a new bent on modeling, something that is new to offerings from you or IBM?

Oberg: IBM saw this before they acquired us. We worked closely with IBM, as we did with Microsoft, to integrate modeling into the IDE. This as opposed to making modeling a stand-alone, separate activity. So, certainly IBM has bought into the idea that bringing modeling into the IDE, and using modeling not just for visualization of components but to help generate applications from models was the proper direction to go if we were going to reduce the amount of hand-coding and improve productivity."

IDN: Rational has been advocating the use of modeling for years. Have things changed in 2003 to make modeling more useful, or more relevant, for developers than in years passed?

Oberg: Two things make modeling more relevant or important to the organization, and certainly one factor will make it more relevant to the individual developer.

What makes it more important to the organization is simply we are in different times. We are in cost-reduction times, and therefore things that make development faster and less expensive without sacrificing quality are important things. The organizations are responding to the economic realities.

The individual dev is responding to the increased complexity of component technologies for writing software. The J2EE and .NET environments are non-trivial technologies, and if you're going to be recognized in your organization as someone who can produce high-quality code rapidly and repeatedly, and maintainable, good code, then tools that allow you to do that are beneficial.

IDN: So, do you see evidenmce that as UML picks p steam, developers are also picking up a different take on how valuable modeling can be to code-generation overall?

Oberg: The way the UML began to infiltrate development activities, I would assert, had a lot to do with the need to document code. So, architects certainly used [UML] as a way of modeling the architecture, and then developers began to use the UML as a way to document what they had written. While it is certainly a valuable thing for developers to have -- a way to reverse-engineering what they've written and documenting their code for the next developer to look at, that use didn't really get to the point of helping developers accelerate their code development.

So, that kind of modeling advantage is beocming compelling for a lot of devs. Not all, of course. There are expert J2EE devs that feel like they can use vi to do anything they want to do. But, increasingly, developers are saying good IDEs and good patterns and model-based template tools (like Rational XDE) to generate the routine code are very valuable.