Cary, North Carolina features an office park where paths stretch around a wooded lake and beyond. If you walk the paths alone, you can have a productive meeting.

In the late 1980’s, a small software company won a contract with IBM and rented space in one of the park’s buildings. The company was required to invent a mechanism for transforming business-process diagrams into source code. The subject area is now called Model Driven Development (MDD).

This early attempt at MDD was expensive. Even the project’s tech writer—yours truly—was flown repeatedly between North Carolina and Arizona at short notice, primarily to type the minutes. With doubts and costs rising, IBM ended the experiment. And a few years later, Rational Software created what would ultimately be known as the Unified Modeling Language (UML), which is at the heart of MDD.

What is needed to fulfill the promise of MDD? One requirement is a language whose main constructs easily link the high-level business diagrams characteristic of the UML, on the one hand, with the low-level logic available in compiled code, on the other.

Enter EGL.

In the future (we believe), a business modeler will be able to select an EGL system definition (a stereotype, in UML terms) and place it on a process diagram. Each stereotype implies a specific kind of runtime behavior. For example, the modeler might select an SQLRecord stereotype to indicate that an automated process must access a relational database.

For now, a developer’s selection of a particular stereotype in EGL source code creates a particular, generated output. For example, if a developer declares an SQL record and includes that record in an EGL add statement, the EGL generator writes the appropriate SQL INSERT statement into the COBOL or Java source. The developer’s ability to affect the EGL system code in a simple, declarative way is central to how the technology works, under the covers.

What are the practical effects of these abstractions? First, the EGL developer can write code that does basic tasks in a single way, regardless of the runtime technology. Adding a row to a database is equivalent to adding a record to a file. Second, the language can better accommodate new runtime technologies such as Web 2.0. Third, the language is likely to be useful for business modeling as well as software development.

The upshot is that EGL is designed to be useful, now and later. For an overview that describes EGL as a technology, see the MC Press title Enterprise Web 2.0 with EGL.

Link to MC Press

Greetings. I thought to offer a perspective different from the ones provided by architects and system developers. Here you will read the idiosyncratic thoughts of a technical writer.

In sniffing the Web last weekend, I found a post from somone who was just learning about EGL and who had the impression that EGL is essentially an update to Cross System Product (CSP), circa 1990.

Let me give you an analogy. In the 1960's, Macy's wanted to build a department store in Queens, New York. The plan was likened to the city's Guggenheim Museum, which was designed by Frank Lloyd Wright. The Macy's building was to be more than functional; it was to be beautiful.

The firm bought most of the land needed, but could not sway Mary Sondek, an elderly homeowner who valued her residence more than she valued the money on offer. The Sondek house stayed. Macy's built a circular structure with a notch that broke the circle. The irregularity was there to accommodate someone who had an established right; but the building itself was modern.

EGL is like a circular building with a notch that accommodates those who wrote code with a predecessor language. Some aspects of EGL are there to allow migration of programs written with CSP, VisualAge Generator, or Informix 4GL. But EGL encompasses far more than those aspects. The language was architected for consistency and has a beauty that CSP never had.

And I should know. My first exposure to software generation was on the IBM project that converted CSP into a COBOL generator. At first, I was a technical writer, asking questions like "How do you spell MVS?" Later, I became a tester and then a CSP programmer and came to know quite a lot about software generation. EGL is a far cry from the technologies that preceded it.

In blog entries, I'll clarify aspects of the language.