A few thoughts on how to mix the new with the old

At the end of March, IBM announced some enhancements to the venerable programming language, COBOL. http://www-03.ibm.com/press/us/en/pressrelease/41095.wss

I know, you are thinking that a COBOL announcement is the equivalent of flogging what no longer needs to be flogged, but before we write this off as irrelevant, note that the announcement provides a couple of nuggets about COBOL in the market.

One nugget: “Today, nearly 15 percent of all new enterprise application functionality is written in COBOL.” It’s a surprising statistic that tells us that COBOL isn’t completely over. The other (something we probably know): “ … more than 200 billion lines of COBOL code being used across industries …” This portends that COBOL cannot possibly go away anytime soon. What else is interesting is the way IBM is evolving this language, and how they are talking about it.

The benefit of one COBOL update is obvious; the compiled code runs faster. But a couple of the other items seem almost unrelated to the world of mainframes. My attention was drawn especially to these two COBOL updates:  1) added support for Java 7 and 2) improvements to XML control with an updated parser. Putting enhancements in COBOL to better control Java, and specifically XML, on a mainframe is telling.

Obviously we have been able to run Java and handle XML on Big Iron for a while, and indeed IBM is working to make it a better experience when you do so. But handling the high-overhead activities like XML parsing, even if managed to special lower-cost processors, seems overly complex. In most of the Attachmate Verastream work I have seen over the last several years, we focus on keeping the mainframe-specific logic in COBOL unadulterated on the mainframe. But for XML and Java, we append to the COBOL code using a services approach. That way, the additive services, Java or heavy XML manipulations, can be placed external to the host as desired. This approach saves in mainframe processing needs and more important, it keeps the Java and XML manipulations separate from the COBOL logic.

This result is significant because it means the services approach will decrease our dependence on a COBOL language that will become more costly to maintain over time. A well planned services strategy not only allows you to decide where services are run, but also allows you to manage how much logic is controlled by what technologies. You ultimately get critical control over platforms and languages.

Are you extending your COBOL applications in a way that gives you this level of flexibility?

Recently, I was working with a winery with an AS/400 that was completely customized for its business. The applications were business critical and tailored to fit the organization. But the system was outdated.

In this scenario what should a business do? Purchase a new modern system or update the existing system? New is not always better and there are options for leveraging existing applications in a modern way. Businesses such as this winery should consider “reusing” their existing legacy applications with legacy modernization versus “reinventing” and purchasing new applications.  We’ve identified three main reasons why businesses should consider the “reusing” option:

• Retain your investment. By leveraging your existing applications in a modern way, you are able to continue to get more bang for your buck out of your old applications. This increases the return on investment from existing assets.
• Retain functionality. By choosing to modernize the applications in place you are able to retain the functionality of your existing applications that have been customized to your business. If you purchase new applications and have to recreate the functionality, you could lose valuable information that you are dependent on.
• Increase Efficiency. Leveraging existing applications and putting a modern interface on them is easy. Businesses experience measurable improvements in productivity and have little exposure to down time with this approach.

Additionally, reusing your existing applications in a modern way with the help of a legacy modernization solution will help alleviate costly upgrades and you’ll be able to access existing applications quickly. You don’t have to start from scratch. Why reinvent the wheel when you don’t have to?

For more information, please visit http://www.attachmate.com/Products/Host+Integration/

I was recently going through some old articles and found this survey from late last year, “The Mainframe and Innovation: Not Mutually Exclusive.” In looking through the actual survey, conducted by Decipher Research, I was reminded of the ongoing strength for hybrid applications in Enterprise IT. Looking at the survey data, you can see it captured some interesting points on the mainframe with respect to current trends:

• 81% globally, 77% in US, of respondents see the mainframe as strategic to current and future plans.
• More than a third, 44% globally, will enable mobile management for the mainframe.
• 74% expect to allow mobile and the mainframe within 12-18 months.

But what is also interesting is the expected change to the mainframe workforce:

•  A majority, 66%+ US and 74% Globally, expect upcoming problems fulfilling on mainframe specific skills.
• 98% think are prepared to ensure continuity with respect to the mainframe workforce.

These two figures seem counter-intuitive. Yet looking further in the survey detail, you can see why these figures make sense.

Over the next year 89% of these enterprise shops are evolving their approach to building applications and embracing hybrid applications. This is a huge trend in enterprise IT. This change in approach allows applications to run across platforms, but it also allows them to leverage various skill-sets and be less dependent on any one. The modern mainframe shop will not be one just be staffed by a skilled mainframe workforce, it will encompass workers strong across multiple platforms and specifically, in web technologies.

Looking at this survey and others, you can expect the modern IT environment to continue to leverage the mainframe, but in a way that is different. It will be the  ‘server’ platform that sits behind HTML5  and other mid-tier front-ends. These survey results are consistent with what I see occurring in enterprise IT — they make sense to me.

What are you seeing, are you prepared for this change?

Take a look at an article over on ZDNET by Spandas Lui: IBM: Bright future for hybrid mobile apps. This article, via an interview of IBM’s marketing manager for mobile Jon Baxter, projects how application development will be affected by mobile user’s needs. It makes a case that in only a few years half of applications developed will be built as hybrid apps — applications run from a server, but with the UI delivered as HTML wrapped in native code.

I personally think this is a great approach and would like to see this pan out. The article also captures a few of the drivers that make hybrid apps compelling:

• Native code wrappers let the applications take advantage of device specific features.
• Making spare use of native code, the wrapper approach, makes apps easier to maintain and build.
• This more server centric approach allows better centralized management and change control.

Considering just these three basic benefits, one can imagine the strong allure that a hybrid application approach will have across the enterprise market.

App stores are nice, but to the enterprise, efficient and strong central control over applications and users is paramount. Combine this with the device specific control and rich experience native code provides and you end up with the best of the best. I can state that in the product group I spend my time with, we have been moving in this direction in building mobile support for existing legacy applications and these benefits are real as well as easily obtained. This approach is applicable all across the enterprise.

What development and integration approaches have you been considering to handling the needs of your mobile users?

I recently had a chance to read through a survey on mobile application development and unlike many I have read, this covered an area of the market that is really interesting to me.

The reason I liked this survey,  Mobile Application Development Survey conducted by King Research, was its focus. As opposed to drilling into mobile security and management concerns, a common and popular topic in the enterprise, it looked at how enterprise architects and developers plan to make mobile devices useful. It was geared towards capturing how corporations are investing in making the mobile user a productive mobile worker.

A few things that were not surprising in the data:

• Apple products were the most supported devices for application development in the enterprise — both iPhone and iPad respectively.
• Development for mobile devices is getting funding.
• The use of mobile devices is expected to impact the enterprise with internal employees, partners, and customers.

But, if you read through the data presented, you can pull out some interesting trends that aren’t obvious to all. Buried in the data was a question that pointed out that more than half of the respondents say their mobile applications will be dependent on existing applications.

This is interesting as it hints that mobile applications in the enterprise are more about allowing users to do what they already do, but just doing it with mobile devices. Take-away:workers will work more if you let them. Now, combine this with the results on preferred development styles and you will see a strong integrated development trend.

On the topic of preferred mobile development styles, three areas stood strongly apart from the rest: Java, HTML5, and Web apps / services. Now this is something worthy of exploration.

Think about it. When the most popular answer for mobile development is Java (over 50%), and it doesn’t even run on the most popular mobile devices cited in this survey, you must either think the respondents don’t know what they are talking about, or there is more to it than running the applications on the devices themselves. Of course, the answer is that integrated multi-platform applications are the target.

This is easier to see when you also look at the other two popular areas of development focus: HTML5 Web apps / services. That can only mean Java is the application on the server and HTML5, and Web services are being used to allow their access by the mobile device. With the popularity of app stores and the huge selection of mobile specific applications, this is easy to lose sight of. But to the enterprise, the key is simply building applications that leverage the work already being done, in a way that is less device-dependent and more flexible. This makes sense to me. Of course I must admit that we take a very similar approach with our Verastream and MobileNow offerings.

What are you doing to make applications mobile-capable?

Big news within Attachmate Corporation this week, we have announced our new MobileNow Strategy.

The MobileNow Strategy addresses the daily conflict of mobile device use and enterprise application needs —  users want to use mobile devices, it makes them more productive, but allowing the safe and productive use of these devices against enterprise class applications is anything but straightforward.

All are designed to allow quick and easy access of legacy applications from mobile devices, any type and any form factor. A few of the enhancements now available are:

• Instant zero-footprint emulation access to mainframe and i Series applications.

• New rich HTML5 enhanced emulation themes tailored for better tablet productivity, iPads and the like.

• Automatic and customizable ‘Hotspots’ to simplify control of host applications from a mobile device.

• New customizable HTML5 enabled CSS available for creating custom tailored access.

• Better control for exposing and managing server-side macros (procedures) in the mobile UI.

• Improved control over building tailored processes that underpin custom mobile device workflows.      

The mobile market has been an area that we have all been interested in for a number of years. It really took off with the smartphone market and then in the last couple of years it has garnered great attention with the arrival of the tablet.  What will change in 2013 is largely around what the market drivers are — we will see dramatic changes to the market drivers that lead less to disruptive changes and more to evolutionary changes in the market itself. 

1. The market will not be dominated by disruptive technologies as much as it will be by evolutionary changes to existing product sets. Don’t expect net new markets to open up like Apple was able to do with the iPhone and then the iPad. Expect both the smartphone and the tablet market to be dominated by incremental improvements to existing product sets. Disruptive technologies, Google’s Glass for example, are probably not going to make a big impact in 2013.
2. We will see continued and increased dominance in the smartphone market by Apple and Android devices. This will come at the expense of RIM’s market share and will contribute to the continued challenges Microsoft has had in establishing itself as a player in this space.
3. The tablet market will become increasingly varied. Up to now, the iPad has been dominant, but expect to see real use of both Android and Microsoft tablets in the enterprise.
4. We will see consolidation in the software market that caters to mobile device infrastructure — especially with respect to enterprise use of mobile technologies. As this space matures, we will see more of the smaller vendors merge or lose out to the larger established infrastructure vendors.
5. For software that is used by mobile device users, software development will become more cloud focused. And specifically, HTML5 will become less hype and more of an essential aspect to creating competitive software for mobile devices.

It’s become apparent that we are at a crossroad — if not in technology, in expectations. The crossroad presents uncertainty, and it boils down to this question: Which mobile operating system will win?

From an application-integration perspective, the winning OS will determine how IT needs to build applications and what tools they can (or should) use. Looking at the market, IT can only guess what the future will bring. The chatter we are hearing on the direction of the Mobile OS is varied and inconclusive.

Many IT shops are asking: Is it iOS and Apple devices? Is it the media-labeled, market-leading Android? If so, which flavor (version) is important and what does that mean for our direction on device support? Or should we leverage the upcoming offerings from Microsoft based on Windows 8? If that is the case, should we focus on Pro or RT?

It appears that RIM is the only player not given much discussion.

Current statistics favor Apple. According to a quote in Infoworld, Good Technology pegs 97.3% of business tablet activations as iPads, while the iPhone represents 73.9% of non-business activations. On the other hand, Android has the most consumer users (something to consider with the advent of BYOD). Furthermore, Microsoft has a planned solution for mobile and the ‘legacy’ desktop (albeit, no current market share). All this market ‘noise’ complicates IT strategies for building and maintaining applications meant to live for numbers of years.

With so many uncertainties, how can IT be expected to roll out solutions that will last? One approach that is becoming more and more acceptable: ‘Leave it in the cloud.’ In other words, build your applications, or even expose your existing applications, in a way that they can be served to devices. The momentum of this trend means that we can expect to see an increasing use of web technologies (e.g., HTML5) as the front end for enterprise applications. With this approach, the outcome of the current mobility battles will have one less impact on IT.

The bottom-line question you should ask: Do I really need the application to run on the device? Or is it really just a matter of allowing users access to the application?

I recently read a blog post that examined the battle among the mobile device vendors. In the blog post, “The iPad Should Be Free”, the author, Mitch Joel, pointed out that the battle is really about the application ecosystem.

It is a good read and makes several points about how app stores and the like make as much or more money than the devices themselves do. Yet, for me, what I found most interesting was what this means for mobile use in the Enterprise.

With so much attention and money at stake around the device specific ecosystems, mobility vendors are offering more and more exclusive and locked-in application options. For the enterprise, this has ramifications and complications which are not good. Enterprise IT does not have the time to accommodate the volatility these application specific ecosystems are creating.

My quick take-away, enterprise IT would be well served to be device agnostic and avoid ties to any of these mobile application ecosystems. And the best way to do that today is to provide cloud style (server based) applications access when possible. Put the enterprise application access on servers that are within the control of IT, then provide access through industry standard options like HTML5.

Mitch’s Post: http://www.twistimage.com/blog/archives/the-ipad-should-be-free/

I just ran across an interesting blog post, “BPM fills some application modernization needs, not all“.

The author, James A. Denman, brings up a couple of interesting aspects about using business process management (BPM) against legacy application assets for modernization efforts. Bottom line, he makes the point that applying standard BPM practices to legacy applications, applications that are not easily parsed into understandable building blocks, is often more complicated than one might understand.

As I read the post, I was reminded that not all BPM is equal — there are higher layer enterprise processes that are typically housed in enterprise class Business Process Management Systems (BPMS), and there are lower layer BPM tools that are often used to make sense of terse granular services. It is this second case where I see the role, and necessity, for BPM in most modernization efforts.

As the post implies, the people that expose legacy applications as services have to really understand the legacy application behind the service. This is true because legacy derived services are not truly free of dependencies from other parts of the legacy application. This is not visible to a consumer of the legacy services and it is these hidden dependencies that have to be protected when using the legacy derived services.  To allow these services to be useful, but safe, a simple low level BPM tool is a perfect solution. A BPM tool in the hands of the legacy literate gives them the power to surround the legacy services with processes that govern their use so no direct use of the services that breaks the application dependencies is allowed. It is through this first layer of BPM that non-legacy indoctrinated developers and users can consume and freely use the services that come from the legacy applications.

I agree that IT should not rely on the corporate BPMS and its users to freely create processes for legacy code, at least not without guidance. But it is through the first layer of BPM, the processes that provide needed rules on the safe use of these services, that does allow any and all to leverage the legacy applications for their own purposes.