And you thought COBOL is dead?

Think again! Contrary to a popular misconception by the current generation of programmers that are deep into open systems languages such as Java/J2EE, .NET and faintly familiar C++, COBOL is growing at a rate of 3% to 5%.

No one is learning COBOL in school anymore, and new applications aren’t built on COBOL any more – it’s like Latin over English! Yet, the growth is real – How? Maintenance of existing mainframe programs. It makes sense, right? Thousands and thousands of legacy applications constantly go through enhancements including change in core business logic to accommodate changing business needs.

Having written over the past 40 years, , the total value of the COBOL applications residing on mainframes today exceeds $1 Trillion (ref: Computerworld April 24, 2006). Some amount of PL/1 and 4GL languages are in the mix, but COBOL’s has a lion’s share.

Sure thing, there are efforts around the globe to modernize legacy systems from mainframe to distributed systems. But, most of the effort is still in either infancy stage or early on thought process. You would think that today’s distributed systems offer scalability and manageability – but the five 9s of reliability and the blazing performance these mainframe systems offer for a complex transaction processing application, today’s distributed system just don’t stand a chance to match. For example, when I worked to rearchitect and prove a Model-Type-Option computation system for a large automotive company in Japan on a Java based custom system, the performance of the new system stood at about one-twentieth of what their mainframe system offered.

Just to give you all a flavor on how those white elephants are recognized, there are three categories of mainframe systems:
(a) Under 500 MIPS; (MIPS = Millions of Instructions Per Second)
(b) Between 500 and 1000 MIPS and
(c) Over 1000 MIPS.

Of these, enterprises those use systems of over 1000 MIPS, are not even willing to touch the big irons for modernization – particularly where the computing algorithms are complex non-linear ones. The category (b) is a grey area – CIOs/CTOs are brooding, waiting and watching. Category (a) is where the thought processes and early attempts are focused at and taking some shape. Enterprises are willing to identify applications that are less critical in nature under category (a) and make an attempt to modernize them on either J2EE or .NET based platforms.

So, you wonder: where are the high end big irons heading? For now, it is predicted that they are there to stay – for a decade or even two. However, there is some form of transformation strategy that is being mulled around:
(1) Enterprises that consider the current user interface as a clunky tab-tab-tab text screens, are looking for technologies to develop web user interfaces. Screen scraping tools – a sort of pig-with-lipstick! – make a living out of this approach.
(2) Organizations that consider the business processes and the data needed exposure to other systems or other parts of their business, are looking at SOA as an option. But it’s a long way to go.

Now you got a glimpse of the landscape – sort of Back-to-the-future Part II. Here’s a thought for those who want to be popular and most sought after in the coming years: If you are a J2EE/.NET/SOA junkie, with experience in COBOL/CICS/Mainframe, get yourself familiar with legacy transformation strategy. Who knows, you might take a “consultant” avatar!

TRUE or FALSE : SOA cannot be implemented without WebServices?

If you are ready with your answer, hold on to it…. Lets validate towards the end of this note.

Last week I met with couple of my customer architects in one of the technology roadshows. When one of the researchers mentioned that SOA is much broader than a technology concept and WebServices is just one of the technology enablers, a customer architect got agitated and argued vehemently against these notions. He later summed up in an email : "my only point is that if we decide that SOA is not about technology or webservices etc, then perhaps this topic should be discussed somewhere else (not between architects and researchers) .. I apologize if I wasn’t clear." This quasi confrontation, which I think is a healthy one, triggered some thoughts in my mind the result of which is the above quiz.

Here are my thoughts …. Before going into details below, lets keep one thing in mind loud and clear: SOA (Services Oriented Architecture) is about "Sharing of Services". It’s about reusability, repeatability, and maintainability!

WebServices are NOT essential to implement SOA: if you operate in a homogenous environment. Here's my explanation ...

Most of us techies, that work on OOAD principles Java/J2EE, C++ or .NET, can clearly visualize what I am talking about. If not, here's an example: when you write code, don’t you organize repeated calls to a specific algorithm to a separate function or a method?

Now expand the thought further. While developing a comprehensive application, you must have used common exception handling and security services across multiple different modules. Do you agree that's a shared-services approach?

Now, broaden that same thought to multiple applications in an environment that is pure J2EE. Cant one application communicate with other application to leverage some of its "services". Lets take a specific example - lets consider two different applications

Application 1 - Part Inventory System written in J2EE that has a method to query the database for available inventory.

Application 2 - Spare Parts Management system under development in J2EE, requires inventory information. In this scenario, cant we leverage the query function along with the data available in Application1? So, aren't we using the shared services approach?

In the scenarios described above, reusability, repeatability and manageability led to shared-services approach which I think is the foundation of Service Oriented Approach. In my mind, service oriented thought process started and proliferated when client-server computing emerged. Later when distributed computing gained pace, much more clarity got added to service oriented thinking through shared-services approach.

The key constraint here is that we operated in a homogenous environment! When you operate within a homogeneous environment where visibility among systems is not an issue, (same OS, networking infrastructure, common communication protocol etc), two disparate application can "share-their-services"

WebServices ARE essential to implement SOA: if the environment changes to a heterogeneous one, then YES.

So, where do we use WebServices? In a heterogeneous environment that requires two different technology stacks to interoperate or where there is no visibility among systems due to enterprise boundaries. A simple example of heterogeneous environment: J2EE and .NET. An example for no-visibility situations: two J2EE systems at different enterprises that are business partners that agree to share information. Here WebServices with the concept of service-provider, service-consumer and service-directory comes into play.

To conclude, WebServices are NOT essential if SOA is thought in a visible-homogeneous environment. But, WebServices are essential in a heterogeneous technology platforms or inter-enterprise environments.

So, the answer to my question: Neither true nor false.

What do you all think?