connomon 0600010TDW Visits (1473)
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, tech
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.
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!