Hey everyone - what a great week this was for EGL! As you probably know, we made a big announcement at RSC (a community edition of EGL is coming later this summer). You can read more about it here - EGL Community Edition FAQ.

There were quite a few activities related to EGL and Rational Business Developer at the conference this year. On Sunday morning we had an invite-only session with customers and partners. The purpose was to get feedback on what we're working on and our plans. Of course, we got feedback about things we can do to improve the product as well. One of the main things we discussed was our goals for 2009 and our focus areas:

• performance analysis/improvements
• language compliance testing
• more real-world testing with customer applications, and
• improvements in SOA support

The general consensus was that these are the right areas to focus on. Let me know if you do or don't agree!

Tuesday was one of the biggest days for EGL at the conference. During the opening keynote session (attended by thousands) the director of Rational marketing talked about the RSC Scheduler created by Chris Laffra and Kapow Technologies! As with last year, the scheduler was a big hit with conference participants (I am sure Chris will brag, err, blog about this sometime in the near future)! We also had the EGL Rich UI session on Tuesday (EM08 was the session number if you want to search for the slides when they are posted). We had close to 50 people attend (which is great!). Lots of good questions and discussions. We also had a birds-of-a-feature session on Tuesday night. At this session we talked more about our announcement and also demo'ed an early version of EGL Free. The reaction was positive - people liked some of the new things we've done (like simplifying the new project wizard and the project structure).

Besides the formal and informal sessions, we also had good one-on-one conversations throughout the week. Chris manned the Rational Labs ped where we demo'ed EGL and showed the cool things you can do with it. Theresa manned the Users First Lounge. We also had a few panel discussions that featured IBMers and some of our partners.

So, overall a great week for EGL! Everyone that loves EGL should be happy to know that there is a lot of excitement in IBM and the EGL community about the technology and where it's going!

Take care,
Will

Don't miss out!

There will be a number of sessions, labs, demonstrations, panel discussions on EGL at the Rational Software Conference (RSC) 2009 in Orlando starting May 31.

Register today!



See the attached documents for IBM i and System z-specific sessions for all Rational Enterprise Modernization solutions.

Earlier today, IBM announced Rational Business Developer (RBD) 7.5. RBD 7.5 is built on Eclipse 3.4 and provides support for deployment to WebSphere Application Server 7.0 and WebSphere Portal 6.1. IBM also announced plans for providing support for building rich, Web 2.0-style applications using EGL. With EGL Rich UI, you have the ability to build truly rich internet applications (RIAs) completely in EGL, without needing to learn the complexities of Ajax, JavaScript, REST, SOAP, etc.

To read the full announcement, click here

(Correction: the planned availability date is October 17, 2008)

Stayed tuned to the cafe for more details and announcements ...

I’m an IT guy. I love this stuff. Sometimes drives my wife crazy. Interesting enough she also has a B.S. in Computer Science. Although mine is from Iowa State – nice school middle of a cornfield, hers is from Central Michigan – also nice school in middle of the hand. (Not so inside joke if you’re from Michigan). You know where I work – she has the harder job – taking care of our kids now – and much lower pay.

Anyway, on to the topic.

This is the time of year I love. When we begin to look at next year. I’d like to share some industry trends that I find key to 2009 and beyond:

Web 2.0, RUI and Rich Internet Applications. Enough said on this subject. But WOW - technologies always get my blood pumping. This is it. Everyone in IT should be getting on the train. Providing better access of information and our products - to our internal and external customers and prospects. One word, COOL.

Simplification and Dynamic Languages. Making things easier. Technology drives much of the world – but it just plain needs to be easier to both create and consume. No developer should think that creating web forms, running business logic, and accessing information should be difficult. What is difficult should be the art of creating something that is easy, valuable, and meets the need. Not the underpinnings of the technology. In context of languages, Forrester calls the drive to simplification Dynamic Languages. Languages that are easier that let developers do more.

SOA. It’s mainstream now. And it’s transforming how IT approaches application development and maintenance. And reuse – especially of existing assets is a great thing. Too much money being spent to rewrite, rehost, replatform, or redo with very questionable corporate value or ROI.

Business Rules. Categorizing business processing; identifying processing in code – and delivering processing through rules engines. A repository that codifies the business. This is a no brainer to me. Electronically, I should be pointed to key business processing as I’m working with an application. A key facilitator of SOA. Love the ILOG announcement.

Agile Development. We’re all over that here. And it’s proving to provide better deliveries - through better understanding of working new application components and how they fit with other components – much earlier in the cycle. It’s also improving how teams function and interact. As we’ve all known – team productivity can be a bigger issue than individual productivity. One superstar can’t make much difference without an executing supporting cast.

Model Driven Development. Using pictures to define and understand processing, gain agreement, then generating code - from those pictures - is certainly a good thing. But we need to make even more consumable and useful in the real world. And extend our processes to tie business models to application models to business rules to code (not necessarily only in that order).

Cost Management and the tie to Green initiatives. I know. Cost management sounds boring. And what does IT have to do with Green? Well think about it. If we take up less building space, require less infrastructure, use less power, we save resources – and money. By lowering costs in other areas, IT can be more responsive by reallocating some costs to even more revenue producing initiatives.

More entrepreneurship and growth of IT influence in the business. This is the most important. Profit is king. Try things that generate profit. Fail or succeed. Learn. Try some more. Bring more excitement to and focus on IT.

In closing – my view is that IT will need to focus on these key areas in 2009 to be successful. Some are lower level, some higher – but I think all will need coverage. I’d recommend you assign owners to each – some can be shared. I look forward to delivering technology next year to you that can help in all these areas.

The stock market is down, COBOL caused it. Gasoline prices are up, COBOL caused it. Businesses and governments are not responsive? COBOL caused it.

See the attached link referring to the State of California? Titled: "California can't perform pay cut because of COBOL"; according to their Governor; http://developers.slashdot.org/article.pl?no_d2=1&sid=08/08/05/1816206

And over the last few years I've seen many more of a similar bent. Basically COBOL applications, developers, and infrastructures are the root cause of IT not meeting it's business requirements.

Are our business leaders, IT leaders, governmental leaders and publications - when discussing languages - out of their collective minds?

So some facts.

There are 2 Billion lines of COBOL code running worldwide large corporate businesses. There are 1.5 Million COBOL developers doing business development. Both according to Gartner Group. That's the positive.

Much of the COBOL business processing is delivered in older less changeable architectures of the past. That's the negative.

One person's conclusion. COBOL is a good business language. And COBOL developers are generally good resources. But at the end of the day - as noted in my other blog entries - it's about IT delivering value. And for COBOL only applications - and COBOL only developers - that's a problem today.

COBOL will be one of many languages forward. It's easy to write, and performs really well. Great language attributes. But it won't be the key language. Nor will the architectures of COBOL's past be the key ones either. COBOL is not great at Rich User Interfaces, and providing the front end of Web and Web 2.0 architectures - which will drive most design and development efforts. COBOL as a language is and continues to be relevant for business processing. So for delivering back end services in a service oriented architecture, it will be a key language. It's also unparalleled in batch processing which will continue to provide back end support for web applications. And many customers want to share transactional and batch processing as well.

I also believe COBOL as a runtime should be viewed independently from COBOL as a language. EGL can let us take advantage of the runtime positives of COBOL like high throughput, very fast access to data, and strong transactional processing in CICS, IMS, and other transaction managers. And EGL can also be used for the UI and front end part of the application.

People eat up lots of the IT cost structure. Reuse as well is much more important today - both due to cost of writing code as well as in meeting requirements for faster responsiveness. These modern architectures also promote reuse. No matter what the underlying language or languages.

COBOL developers will need to deliver value in new languages and infrastructures, like Web 2 and SOA, to stay relevant in overall application design activities. It's not COBOL that's the problem - it's about IT doing, or not doing, more. Blaming COBOL is ridiculous. Blaming those who hinder the endgame; won't change processes; won't get with the new economic realities on how we need to perform; is also probably not going to be productive. My message. For the COBOL developers - learn Web 2.0, do Web 2.0, make your mark. You're companies will do better with their revenues, you'll do better in your careers, and I won't have to read the any more nonsense about COBOL

As programmers, new technology is always interesting. But for most of us - when that technology surfaces in a usable programming model - is when it becomes real.

The Web 2 programming model is fundamentally different than the Web or ICCS programming models of the past.

The Web programming model revolved around designing a group of forms that in some way map to our desired business process. In many ways the information processed on each form was sequential; start here - do this - end here. As well, we were reasonably limited by what could fit on available real estate.

As a result, A user entered a request (form or URL), our application processes it, builds the next form, sent it, waited for a response, then built the next form sent it ... and on and on. After each request and before each response the user waits. 1 second, 5 seconds, 1 minute, etc. The traditional Web programming model is like this - and fancy enough - the traditional CICS programming model, albeit "green screen" driven, was also identical to this.

Things have changed. Users don't want to spend their time hitting buttons or function keys to move from form to form. And they don't want to wait. They do want to do more. They want to process more information now - the more information - the better the decision making process - and the more productive and ultimately revenue driven the user can be.

The Web 2 programming model is based on AJAX. Asynchronous JavaScript and XML.

We still do requests and responses. But now the requests and responses can happen in an asynchronous manner. Only part, not all of the form waits for the response from the server. The user can go to other pages, other parts of the current page, even move on to other URL's.

Even better yet, as well the entire page - as in a traditional web application - doesn't have to reload and redraw.

And a side advantage - our back end servers aren't spending all their time serving up HTML web pages. They still do that on occasion. But the requests for information result in responses in XML. The web page doesn't have to be resent unless the application requires it.

And a second side advantage - the new programming model is easier. Developers need not be constrained by always having to manage the sequential form flows discussed above.

And yes, you can still create whole pages - that wait for responses - if that's what you like. But you'll still use the Web 2 model rather than the legacy Web model discussed above.

Wait, did I just use legacy and Web in the same sentence. Yes, any fundamental change has the potential to make the past legacy. I think this is a good thing. It means we're still being innovative and continue to evolve. And someday the Web 2 model will be legacy too. But the good news. The older Web model still works, is being developed - and isn't going away anytime soon, as the older CICS "green screen" model is still working and being developed as well. But as we've seen in the past and will continue to see into the future - there now is a better way.

As a a product manager, I’m often asked “what’s new or what’s coming?”., and the simple answer is : “Change” We have all heard the quote “Change is our friend”, although in many cases I’ve not been completely sure, but it is a fact: change is a trademark of the IT industry.

I started out as an IT professional developing CICS and COBOL applications. Even at that time change was underway… we were in the midst of changing from Macro to Command level CICS programming interfaces. That change was definitely good for both customers and IT. Customers got more, IT was able to deliver more easily.

Then came the client/server revolution. Certainly customers got beter ways to view and process - but it was unclear if IT was able to do more. I don’t think I would ever say that C and the Windows programming model and API’s were easy.

With the advent of the Web, it certainly was clear to me that users could get more information more readily to support better business decisions and business processes: all in all customers received lots more value. Phenomenal value. But it was also pretty clear that instead of doing more, with the proliferation of technical complexity , IT could be doing less. Not because IT staff wasn’t working harder –they were – but because of the growing number of artifacts, technologies,languages, and the fact that runtimes did less and code had to do more.

To compound the problem, as complexity grew, the economic climate and business demands increased the pressure on workers, who were expected to be more and more productive. On average between 3 and 6 percent more productive according to overall worker productivity economic estimates. I think you get the picture.

Then SOA and web services emerged. Really cool stuff that enabled transaction managers and platforms to seamlessly communicate. Again, customersgetting more. Like that. But some fairly good complexity built in as well : SOAP, XML, WSDL, WS-Security, WS-Transaction, WS splat, headers, payloads, and so forth…. Left me wondering why it all just couldn’t have been implemented in a simpler fashion.

Now it’s the time of Web 2 and Rich Internet Applications. With Web 2, we’re realizing the power of the Web by exponentially increasing the power the browser can deliver to the users. We’re also getting a simpler and cleaner programming model. Client side programming and application flow stays in the client tier, facilitated by client side scripting languages. Server side programming focuses on flows and processing of business logic and data. It’s clean, and separates concerns. The architect in me likes that. And customers that have standardized on business processing in J2EE, CICS, IMS and other transaction managers can continue leverage them for back-end (heck, whoever wanted those high valued business systems to be processing User Interfaces anyway?). Now we’ve certainly got something for the users with significant value , but what about IT?

That's where EGL comes in. It’s a simple common language for the various elements of the application. Both the UI as well as enabling integration – including Web Services – and all the way to back end business and data processing. EGL provides something for IT as well, it enable developers to deliver more with less effort, simplifying innovation.

I'm often asked what EGL stands for. Originally it stood for Enterprise Generation Language. And it does generate artifacts targeted at the various runtimes in modern applications. JavaScript, Java, COBOL, and SQL to name some of what’s generated. Similar in concept to the fact that Java generates bytecode, and COBOL generates assembler.

But most importantly it’s an Easy General Language. The idea here is that a standard language across application tiers makes developers more productive. And also hedges an organization's bets that the next great platform, runtime, language is coming. Let’s see – you ever hear that said about PHP, Groovy, etc. The point here is that EGL is an Extensible Generalized Language. Support for new runtimes, languages, frameworks and technologies continue to be added as needed. To net it out EGL applications are meant to be portable between runtimes and platforms, yet not be constrained by one specific architecture.

So does the world need another language? Whole heartedly I say yes. In fact we’ll see many many more new languages and runtimes over the next 20 years. What we don’t necessarily need is for IT to have to code in them all to accomplish a single business system. Think about the change from TV to HD. You get a converter box – everything just works.

Finally, I’m asked will EGL be a standard. If a technology having a set of processes, API's, extension points managed by an open community can be considered a "standard" then the answer is absolutely! The community is this one, the EGL community. We’ll shortly be implementing a process, accessible on this site, where all members of the community will be able to participate in the development and vision of the language. So you’ve heard it here first. The current target for the establishment of this process is late 2008, after the next major release of EGL and RBD.

I encourage everyone to become an active member of this growing community, so hit the EGL café “JOIN” button and let's talk EGL!