JeeWiz For Application Generation

Enterprise-level Application Generation - Pros

Closer to the Business

Too often the requirements specification seems to undergo a mutation as it gets translated to the system. As the requirements pass from the business expert, to the analyst, to the development team and the coder, a "Chinese Whispers" filter occurs and what is coded is not what is required. With model-driven development that changes. The requirements as embodied in the model are used to generate around 95% of the application, so the business expert can comment on both the model and a working application, and the business gets something closer to what is needed, without too many painful and costly iterations. This even holds true when the business expert isn't completely sure of what she wants, as seeing the application is what triggers suggestions for improvements previously unconsidered.


These days more than ever, it's important that the software written complies with the architectural, security and coding standards laid down by the IT department, but when a project is running late it seems inevitable that shortcuts will be taken. Not only will most of the application be generated directly to comply with standards, a good code generator actually makes it easier for a coder to write good compliant code than bad code. So even when the pressure is on, the temptation to deviate from standards is low.

Faster, Cheaper, Better

Almost a mantra within the code generation community, this really holds true in practice. Systems are generated more quickly than coding it all from scratch or using cut and paste. Fewer people are required for any particular system, making the system cheaper to produce, and because the same code generation software is reused from application to application, the number of bugs in the system are fewer and easier to spot. We have all heard that the major cost of a system is the maintenance cost, keeping the system going over the years, rather than the initial cost of development, but in too many companies that has no impact on the busy project manager, whose first priority is to get a system out on time and to budget. It sometimes isn't even included in the ROI calculation as it's deemed too long term. A generated system is more maintainable without extra effort. The quality of the code is that of a good programmer on a good day, and the documentation is also up to date because it is either part of the specification, or like the code, it's generated from it.

Lower Risk

Projects become less risky for several reasons.

  • The business experts can see the application earlier in the process and can give feedback sooner.
  • The development is decoupled from the architectural and platform requirements and both can be worked on independently.

Easier to Migrate

If the business decides to change from an old platform to a new one, change or upgrade the database, move application server, or upscale to a distributed system, very often all that's needed is to regenerate the old applications to the new configuration and run a system test. This costs a fraction of having to rewrite the system and avoids the "write an interface and bolt the new stuff on top" approach.

Enterprise-level System Generation - Cons

Some People Just Don't Get It

It might be that they don't believe it works. Perhaps they tried a CASE tool in the 1980s and it didn't deliver. Perhaps they're a programmer who can see their place anymore if it's all generated. Perhaps they are happy enough with the way things are and can't see the need for change.

Let's take the first point. The best way to convince someone it works is to show them it working. Do a small pilot so as you are happy that you know what you're doing. Then do another before their eyes.

Convincing the wary developer is not so easy as the profile of a project development team should change, that's part of the point, and there will be fewer developers. There are broadly three areas that a programmer may end up in. First they can do the coding that's unique to the application. All the repetitive work is gone, leaving just the interesting bits. But there will be a need for only a small fraction of the number of developers doing that sort of job. Developers who always found the biggest thrill was in helping the business achieve something can move to modelling. Because the models are no longer an indication of what's wanted, but a constrained specification that will be used to generate systems, the sort of old style analyst-programmer works ideally in this role. For the hardened technologist, who loves to get the best out of the technology at hand, the obvious role is in writing and maintaining the transforms. The technical challenge is greater and there's a possibility of moving into an architect role in time. One the developers understand that there's a place for them, they are happier to buy in. It's also our experience that most companies use the reduced effort level on a particular project as an opportunity to do more projects rather than fire people.

For people who are just resistant to change, there are no pat answers. Many books have been written on the best way to implement change in a large organisation. Once again, I find the best thing is to show them the advantages in action. But in reality it's often not until some crisis occurs and some project is going over budget that people become okay with changing their working practices.

Planning Change Takes Effort

Even if you've decided that code generation is the way ahead it still requires an effort to move a department over to a new way of doing things. Unless programmers are trained properly they will modify generated code, modellers will produce ambiguous models and project teams will be formed with the wrong mix of people. The current method of archiving and holding systems will have to change to include the model, and possibly the generation templates. Although we recommend starting out with a pilot project or two, there will come a time when it will become necessary to create new project development procedures more suited to code generation. Obviously we think the investment is well worth it.

SME-level System Generation - Pros and Cons

In many ways, the same pros and cons that apply to enterprise level generation also apply to SMEs, but to a lesser extent. Because smaller businesses can't put the same level of investment into writing their own transforms, they will normally have to modify something off the shelf: add logos, tweak colours and so on. This might limit the sort of applications possible until full application transforms are available within the open source environment.

The big advantage is that they can quickly develop bespoke systems that achieve the business benefits that you want, without worrying about all the steps that larger companies regularly go through.

Using JeeWiz

JeeWiz can be, and indeed has been, used as an enterprise-level systems generator. Because it is based on a commercial product adopted in global and multi-national businesses for many years, we know that the level of flexibility provided by the JeeWiz engine is more than sufficient to generate systems with arbitrarily high complexity.

Some of the things JeeWiz has been used to generate include

  • Fully scalable n-tier commercial systems with production quality user interfaces
  • Distributed, multi-threaded and asynchronous systems
  • Greenfield systems and legacy system tie-ins
  • Service orientated architectures (SOA) and web service backbones
  • Systems tailored for data grids
  • User manuals and documentation
  • Web sites
  • Test suites
  • Software factories
  • Language to language transformations
  • XMI-to-XML transformations
  • Eclipse features and plug-ins

Because it's a code generation system, JeeWiz allows you to tailor the system to the architecture you prefer, so you can choose to link to your current infrastructure for elements such as logging, security or databases access, instead of generating them as part of the application.

As part of our Open Source commitment NT/e have released a basic back-end transform on Spring and Hibernate to get you started. Also included are transforms for the Enterprise Architect and Rational (Rose and RSA/RSM) class and component UML models to create the sort of simplified XML that feed into the Hibernate/Spring transform and for which it is easy for you to write your own transforms. The example front end transform released with the Community Edition is for Java Server Faces (JSF), but to generate anything more than a very basic page structure as it stands needs a fair bit of work. We hope that the open source community will use it as an indication as to how to develop transforms for themselves in JeeWiz, which they will eventually make these available to all.

The commercial release of JeeWiz will continue to be developed, and new aspects are expected to feed through to the Community Edition over time. NT/e have also committed to providing stable engine updates on the Eclipse open licence.