These days almost everyone has one or more mobile devices, ranging from Smartphones to tablets. From a business perspective, widespread use of mobile devices is useful, as it allows immediate access to information for employees who work remotely and/or travel frequently. Customers also have easy access to information about products and services.

While the “App Stores” offer thousands of mobile applications, employees need mobile applications that will integrate with line-of-business (LOB) applications and unstructured information. Mobile applications built for customers, must help them in their relationship with the company by informing them about the status of purchases, providing information about products and allowing customers to ask questions or place orders.

Developers who work with RPG or COBOL on IBM i servers will find building applications for mobile devices a very different experience. Mobile devices are smaller, operate on a limited power supply, store much less data on the device and human interaction is touch. The devices have additional capabilities including cameras, location awareness and gyroscopes. Mobile applications can be browser based, native to the mobile device, or a hybrid of both. Native applications written for mobile devices don't use RPG or COBOL as the development language, and the device constraints require different application architectures and design principles.

What's different about mobile devices?

To understand the differences between 5250 and mobile applications, we need to compare the characteristics of the servers that run 5250 applications and the devices on which mobile applications run.

IBM i servers and 5250 applications

The IBM i has had several name changes, but the way applications work has remained much the same for 20 years. The servers are mature, stable, reliable, housed in a fixed location, fed with a constant power supply — and have an almost unlimited upgrade capacity.

Text-based 5250 applications operate in a stable environment and run in a way that prevents users from interfering with the application. They control the database, business logic and user interface. Users may operate the applications, but have no control over how or where the applications run. In addition, 5250 applications can close gracefully when a user shuts down a terminal or emulation session unexpectedly.

Mobile devices

Mobile devices have been on the market for a relatively short time, and have experienced rapid growth in numbers — together with constant change in capacity and capability. In contrast to the IBM i, mobile devices are many and varied in both manufacturer and operating system. On mobile devices the user is in control.

The significant differences between 5250 and mobile applications are:

All of these factors suggest that mobile applications need to be small, agile and focused on discrete tasks — minimising the number of screens, local storage requirements and communications traffic.

Architecture and design considerations

The following suggestions will help to reorient your approach to application architecture from a mindset that expects almost unlimited resources, to more modest and constrained resources available on mobile devices. When designing applications for mobile devices, architects must consider the limits of the devices and the effort required from users to perform tasks. Don't transfer a server or desktop application to a mobile application; instead think about how best to use the resources on mobile devices.

Storing information on mobile devices

The storage capacity on servers, desktop and laptop computers is large. Mobile devices offer limited storage capacity. Use the centralised browser application design pattern for mobile applications that need access to large amounts of information. For applications that operate when disconnected, optimise information stored on the mobile device and ensure that your application monitors and manages out-of-storage conditions.

Coping with power constraints

Mobile devices have a limited power supply and batteries will discharge quickly when mobile applications use power-intensive features of the mobile device. Examples are heavy processor use, excessive graphics activity and constant communication with servers over 4G networks. Design mobile applications so that they minimise power usage.

Designing for reduced memory and processor speed

Complex applications requiring a large memory and high-speed processors will produce a less than acceptable performance. Design mobile applications that are modular and focus on discrete tasks. Every second counts, so mobile applications should return information to the user in the least possible time, and also provide updates on progress when users have to wait while an application completes a task.

The user experience

The screen size of mobile devices limits the information mobile applications can display. Scrolling from screen to screen can become confusing with a large number of screens. Typing information for long periods on small keyboards is both cumbersome and tiring. Mobile device users expect immediate response from mobile applications, with information that is understandable in one view.

Architects ought to design mobile applications that accomplish one, or a few, discrete tasks. Small mobile applications with the minimum number of steps in a task will run quickly, consume less power and simplify designing the user interface.

To make your mobile applications easy to use, follow the conventions and display rules inherent in the operating system on mobile devices. It's worth reading design guides published by manufacturers, and following their advice will produce a better user experience from your mobile application.

Communications and networks

Design mobile applications to use communications services in short bursts and avoid extended sessions. Network activity should be assigned to a separate thread to avoid locking the user interface and inhibiting other applications.

Mobile device management

A discussion of issues about deploying mobile applications, version management, device management and how to secure corporate data on mobile devices is a story for another day.

How to decide what the first application will do?

Once you decide to build applications for mobile devices, how do you choose an appropriate first application? One idea is to build the "Hello World" application. While this application may see a quick result, it does little to help business activity — and its simplicity will not enhance developers' knowledge about building applications for mobile devices. The choice of a mobile application ought to be a business requirement that uses features of mobile devices to gather new information and/or improve business processes. Choose an application that is not mission-critical, but will produce a useful business outcome – this choice will also provide developers with a more realistic development experience.

The take-out message is to think about how a mobile application can do more than a 5250 or Web application — responding to the needs of the device owner and providing an improved customer service.

As modern Web applications have become increasingly interactive and data centric, techniques have been sought to make these applications more efficient. A major breakthrough in this area was the advent of AJAX (Asynchronous Javascript and XML). Since then, developers have continued to squeeze even more performance and efficiency out of every byte. One way to achieve these gains has been the use of JSON.

Let’s first understand what JSON is and what it isn’t. The formal international standard for JSON is RFC 4627. Douglas Crockford, the originator of the JSON (JavaScript Object Notation) specification, describes JSON as “a lightweight data-interchange format.” It’s based on two key ideas — the use of name/value pairs and an ordered list of values. Since these conventions exist in nearly every significant programming language, this makes JSON a good solution across many platforms. While JSON is often described as a subset of Javascript, JSON itself is not a language. Nor is it a document format. JSON is a way to store information in an organized, easy-to-access way. It's both human- and machine-readable and is easily parsed. Most importantly, JSON is an open, text-based data exchange format that provides simplicity and programming language independence.

When considering new technologies for your environment, you might want to know whether the technology is being used by others. So who is using JSON? Consider that Douglas Crockford is the senior JavaScript architect at Yahoo. Twitter has recently switched from using XML to JSON for their APIs. TheGoogle Web Toolkit also works with JSON. The official Internet Media Type for JSON is application/json. The JSON filename extension is .json. The specific section of the standard that JSON is part of is ECMA-262. These are well documented and widely-followed standards, which should give you a comfort factor when using a new technology.

Of course, no one should use a technology just because some really big name players use it. So why should you use JSON? Most definitions of JSON say that it’s “lightweight.” What does that mean? Compared to XML, the ratio of markup to content with JSON is far lower. This means it’s smaller, less complex to generate or retrieve and easier to read. That translates into faster load times for Web pages and the ability to send more data, more quickly than with other data formats.

In addition, JSON is a subset of Javascript. You’re probably already using Javascript — since it’s the world’s most used programming language — and you won’t have to learn another language or formatting standard. JSON data can be as simple as Javascript variables holding name/value pairs or arrays of name/value pairs for larger data sets. Here’s a snippet of how JSON data may be represented:

When using JSON, data is readily available as an object in your Javascript – versus XML, which needs to be parsed and assigned to variables using DOM APIs. You can retrieve JSON data from anywhere, not just your own domain, so there are no proxy server complications. Because JSON is part of Javascript – and Javascript is not just data – you can send executable code. If you’re building applications for phone and tablet devices these reasons are all helpful to the cause of building smaller, faster and more interactive apps.

None of the above is meant to discredit XML in any way, but to show the strengths and uses of JSON. As with many things, this is a horses for courses discussion. As a matter of fact, another plus for JSON is that JSON and XML are not mutually exclusive. JSON plays well with other tools – and you may find opportunities to use the strengths of each to build your applications. Speaking of playing well together, another excellent pairing is JSON and JQuery.   

Let’s put the lists of features and options aside for now and talk about what JSON can actually do in real applications. What are people using it for? In a word, AJAX. OK, so you thought that AJAX stood for Asynchronous Javascript and XML, but in many cases JSON is taking over as the X in AJAX. Why? It’s fast and it’s compact. This results in applications that are better able to run in tight spaces, such as phones. In many cases where size and speed are the primary factors in application design, JSON has started to replace XML as the data format of choice. XML may still be appropriate for some applications, but in many places Javascript best practices point to the use of JSON for many traditional XML duties – unless there is a particular reason to stay with XML.

For example, Callbacks with Web service requests in client-side Javascript are particularly well suited to JSON. Web service requests using the XMLHttpRequest object will run into browser security restrictions with a limitation of only being able to communicate with the server from which they were downloaded. This can become a problem for deployment environments which span multiple domains. Also the code to manage XMLHttpRequests is browser specific, so customization is required to handle each browser. Using JSON and Callbacks, none of these proxy or server workarounds are required. What you can do is dynamically create a <script> tag where its src property is set to the URL of the out of domain page. As long as the page returns valid JSON, it will be executed locally. This makes JSON productive in environments where other data exchange mechanisms may not be viable. So, add flexibility to the list of pluses.

Another use of JSON is to store complex data structures in databases. An entire object can be stored in a single field of the database table. Using JSON, you can build a more advanced non-relational data-store. In some respects this is similar to the use of .ini files to hold data structures for things like configuration information, rather than more complex mechanisms like a registry. This comes back to its use of name/value pairs, which are simple and efficient.

In conclusion, JSON is another potential tool for the arsenal — and one you should consider adding if you’re not already using it as part of your Web solutions. It has many benefits, including simplicity, speed, readability and familiarity as part of the Javascript family. While there are certainly other technologies that can do some of the same things, JSON works with those technologies to allow you to ease it into the mix at a pace you’re comfortable with – while providing an increase in performance at the same time. It’s not meant to be a complete functional replacement for XML, for example, but where their capabilities overlap you should keep JSON in mind. You may find your users thanking you for it.

The second annual iPulse Survey, organized by LANSA, ran during October 2011 and was promoted to the global IBM i community via email, social media and publicized by leading industry media outlets like Intelligencer Magazine, IT Jungle and MC Press Online.

This year’s survey attracted just over 1,500 participants worldwide, which is around 10% down from last year’s numbers. Although views this year were represented from farther afield, with responses received from over 70 countries – a 30% greater reach than last year’s survey.

The participants represented a cross-section of the industry whose job roles were as follows:

• Business Management – 22%
• Developer / Analyst – 40%
• Project Management – 17%
• Operations – 13%
• Other (vendor, journalist, consultant, etc) – 8%

This demographic snapshot revealed some significant changes compared to last year. Responses from Business Management were down from 36% to 22% with the major shift going to Developer / Analyst and Project Management roles.

Here are the results from our five key questions:

1. Is the future of your IBM i system under threat? The answer to this question will, once again, be one of the most anticipated results of the survey because there is still so much speculation and misinformation about the future of the platform.

Yet again the majority of respondents felt that the threat level to the platform was “low to none” and exactly the same minority of just 17% felt there was a high level of threat inside their organization. However, we did see a 4% shift from those stating that there was “no threat” to “low threat,” so that’s an interesting trend to monitor in future surveys.

The exact breakdown (represented as percentages of the total) is as follows:

• High – 17%
• Medium – 20%
• Low – 40%
• None – 23%

2. People's future plans for their IBM i applications will, (as I stated last year) to some degree, correlate with how under threat the platform is felt to be. For instance, it is unlikely that the budget for continuing new development would be found in a high threat situation.

The overall survey results indicated that modernizing and continuing new development is still what the majority of organisations intend to do. Other results worth mentioning include a 2% increase in those organisations running in “maintenance mode” and a 1% reduction in those organisations planning to migrate their applications to another platform. The full results are as follows:

• 38% will continue to develop new applications on the IBM i
• 27% of applications are idling in maintenance mode
• 19% will modernize their existing applications
• 11% say they will migrate to another platform
• 5% say they are moving to a package

3. In last year’s survey we felt that the state of the economy would have a significant impact on the amount of money organisations were willing to invest in new software, and with nearly half of the respondents saying they had “zero” to invest this came as little surprise. But this year’s results have come as a surprise! The economy has taken various twists and turns over the past 12 months, although none that we would expect to influence budgets in a positive way. However, the results show that organisations are feeling more confident to make investments in software. The number of companies with a budget of zero reduced from 49% to 40% and there was a small increase in those willing to invest over $100,000 (up 1%).

• Zero to invest – 40%
• Less than $10,000 to invest – 18%
• Between $10,000 and $25,000 to invest – 14%
• Between $25,000 and $50,000 to invest – 9%
• Between $50,000 and $100,000 to invest – 9%
• Over $100,000 to invest – 10%

4. Each year we ask participants where their software budget would most likely be invested. With the market hype surrounding both Cloud and Mobile we decided to add these options. However, in order to keep the survey as short as possible, we removed the Utilities and Document Management categories.

The most popular investment category was again in the area of Application Development, in fact there was an increase from 26% to 30%. Close behind was Application Modernization, which also saw an increase from 23% to 25%. Investment in Cloud and Mobile solutions show small but significant investments, with 10% and 14% respectively. It will be interesting to measure whether these perceived high growth areas can maintain their momentum through 2012/13.

• Application Development - 30%
• Application Modernization - 25%
• Web Enablement - 21%
• High Availability and Disaster Recovery - 18%
• Business Intelligence - 17%
• Application Integration (B2B, EDI, FTP) - 14%
• Mobile – 14%
• Cloud – 10%
• Security - 9%
• Other - 18%

5. Finally, we asked participants to list who they perceived to be the leading vendors in the product categories we defined for them. Once again this was an optional section, with free-text entry rather than prompting, and therefore not a particularly scientific study. But vendors do like to know if they have become “top of mind” in their respective specialties, so this chart is always eagerly anticipated by the vendor community. Where product names were listed, these were changed to the appropriate vendor for said product. The data has also been normalized such that the score for, say, Vision includes their brand names like MIMIX and iTERA.

I have also indicated how this chart has changed compared to last year.

The content of this report and all data resulting from the iPulse Survey is the property of LANSA. This information and data set in whole or in part must not be reproduced, combined with other data or otherwise processed or published without written permission from LANSA. Such requests should be directed by email to . However, this information can be reproduced in the correct contextual format with a citation stating "Data Source - iPulse Survey 2011 - copyright LANSA." So, journalists/bloggers, feel free to discuss pieces of this survey on your own Web/blog site, but then direct interested parties to this iOpener page (http://blog.lansa.com/general/ipulse-2011-survey-results) for the full report and analysis.

Guest Blogger: Paul Conte, President PCES, is a leading Application Development Strategist.

The other day I was reflecting back on what has been a long, and generally fun and interesting IT career. One thing I remember vividly was discovering the IBM System/38, the first incarnation of what would evolve into the AS/400 and the current IBM i. I was responsible at the time for a major planning process for a large university’s (hint: “Go Ducks!”) administrative computing strategy. The S/38 technology promised application flexibility and reliability unimaginable on the other platforms available at the time. The IBM i technology still does.

But, as in the early days of the S/38, this platform’s technology and benefits are a well-kept secret. There were more than a few nights I lay awake wondering whether I’d made the right decision to embark on a consulting career focused on the IBM S/38, AS/400, i world. Would the then “jazzy” Wang system, with its fairly slick, but also fairly shallow, interface capture the imagination of departmental organizations wanting to break free of the central IBM mainframe? Would the just introduced DEC-system 20 dominate, with its far greater horsepower than the S/38 and a more modern operating system than the IBM mainframe (but still years behind the S/38 architecture)? In the end only one of those competitors survived, and has in fact thrived.

So, I empathize with today’s System i IT managers who may share similar worries. But I also can offer encouragement. Before doing that, however, let me spin a story and see if it sounds familiar. I call this “The Secret Thoughts of an IBM i IT Manager.”

Once in a typical midsized company that was doing OK, but still facing pressure from the lagging economy and hard-scrambling competitors, there was a System i IT manager named Al who generally maintained his “game face” of calmness and optimism regardless of his anxieties. Al knew that top-level executives needed to have faith in his ability to safely navigate the vast and ever-changing landscape of modern computer technology, and that an IT manager who expressed his own doubts about the IBM i or seemed uncertain about how to deal with future application development wasn’t going to reassure executives that their faith in him was well-founded.

But in the late evening, after most employees had gone home, and Al was alone in his office, these are some of the thoughts that ran through his mind . . .

“How can I convince my managers the IBM i is still the right platform for us? I know the i can compete with Windows, but we can never seem to find time to ‘modernize’ our applications because of the time-consuming RPG maintenance effort. Our lack of innovation is painting the platform in a bad light. I need a way to produce applications on the i that showcase the platform.

Thinking about maintaining all this old code makes my head hurt. I can’t even determine how much of my code base is redundant or where the important business logic sits. I know we’ve ‘cloned’ a lot of the code, too; and I can’t tell which of the multiple variations are up-to-date.

We need to stop writing and ‘cloning’ more code until we can get a handle on what we have; and yet, tomorrow we’ll just pile on more of the same kind of code because that’s our only way to respond to demands from other departments. I know a day of reckoning is going to come when all this code will have to be rewritten. We need to find some way off this hamster wheel . . . or I better retire before that day of reckoning arrives.”

Al continued to muse . . .

“I remember how nice it was when all we had to think about was adding a new function to one of our big, all-purpose RPG programs, and I had a full complement of RPG programmers who could keep up with the workload. Now, I can’t even fill two of my programmer positions because good RPG programmers are so scarce. And Lord help me if I were to try to get one of my two .NET programmers to take on some RPG maintenance responsibilities. They don’t have a clue and aren’t interested in working with a language they consider ‘archaic.’

Then there’s the other side of the coin. Right now, our use of .NET is limited to a few Web applications, and our main line of business apps still run on the i. But my boss keeps asking why our applications aren’t better integrated, and he clearly wonders if we wouldn’t be better off on a single platform, like Windows, which has a better user interface and seems to be widely used in our industry.

So far, I’ve been able to hold him off by arguing that our applications and data are more secure and operations are more reliable on the i, but just last week he said I better be looking for ways to deliver security and reliability on the Windows platform, as well as the i, because our company is in acquisition talks with another company that runs everything on .NET. Just what I need right now!”

The minutes ticked by; the cleaning staff came and went without Al even noticing. His mind was on the seemingly insurmountable problems he faced . . .

“What can I do? I hear all this talk in the IBM community about ‘modernization,’ but I don’t hear much that addresses my fundamental concerns. It’s really pretty simple – somehow, I need a practical way to move to a development strategy that will take advantage of the IBM i’s exceptional technology and reliability, but also let me easily deliver an equivalent application on .NET when that’s necessary.

Did I say ‘simple’? Ha! With the amount of old code I’ve got, trying to make such a transition would be a nightmare if I had to do it in one shot. That’s really the reason we’re still stuck. Why add some new approach to development – even if it is better than what we’re doing now – if we still have to maintain all our old code and can’t make use of any of the functionality we’ve already implemented in RPG?

Maybe I should follow in the footsteps of my two top programmers who left last year for jobs in a pure .NET shop? There’d be operational headaches with Windows, for sure, but at least I wouldn’t have other departments hammering me for the lack of integration between our IBM i and .NET applications. And, I could finally quit worrying about trying to manage multiple copies of data stored in DB2 and SQL Server.

Look for a .NET job in this job market and with my experience? Nah. Plus, I like the company and my current job, despite the stress. What I need to come up with is a plan for transitioning to a better development environment in a way that lets us continue to use our RPG implementations of business logic, while incrementally improving our user interfaces and increasing the integration among existing and new functions, so we get rid of our current application ‘silos.’ Eventually that could unify my IBM i and .NET application development. Then I could finally relax . . . at least a little.”

Finally, Al got up and reached for his jacket . . .

“Oh man! That’s enough worrying for today. I need to go home and get some rest so I’m ready for tomorrow’s round of questions about the IBM i’s viability.”

Do any of Al’s thoughts resonate with you?

What’s interesting is that Al’s concerns aren’t really about the IBM i, they’re about finding an application development strategy that will take advantage of the i, make use of his current application portfolio and support multiple platforms. Al realizes this isn’t going to be RPG, but his intuition correctly tells him it isn’t going to be just .NET, either.

So if I were Dr. Phil and Al came to me seeking advice, what would I suggest? Well, the details won’t fit in a single blog post, but I’ve written Transforming IBM i Applications – Your Journey Beyond Modernization – a series of three eBooks just for folks like Al. Take a look. The first book, “Prepare for Your Journey,” discusses the challenges faced by IBM organizations and their IT managers, including specific risks and opportunities. I also explain several “core” principles to guide your planning. In addition, you’ll discover how transforming your IBM i applications requires an enterprise application architecture that provides an over-arching description of the building blocks and practices your organization will ultimately use to design, implement and adapt applications that fulfill the enterprise’s business objectives. I complete the preparatory steps by describing eight pillars upon which any application architecture should rest.

In the second installment, “Be a Savvy Traveler,” I lay out seven steps to create an incremental transformation plan. Implementing a comprehensive enterprise application architecture that encompasses all your legacy and new applications can only be reached through a series of non-disruptive steps where each step produces immediate returns and minimizes risk. As we travel through this transformational journey, I explore ways your enterprise can reuse, recycle and reengineer legacy applications. I also explain how to put your current IBM i development staff in the right position to create success, without having to turn them into Java programmers.

“Embark with Confidence” completes the series by looking at specific technologies and “best practices” that support a non-disruptive, low-risk transition process from an organization’s current application portfolio and practices to a “new generation” of applications and an architecture-based approach to development. I provide a careful analysis of application generators as a potential tool and provide a set of specific scenarios and decision steps an IT organization can work through to assess the level of risk in using an application generator. This final book also describes a list of criteria to evaluate contemporary application generator products.

The journey through these three eBooks leads not only to an effective application strategy; it also leads to getting a good night’s sleep!

Over the past decade, we’ve seen the explosion of information, mobile devices, tablets and the ability to consume and access information from anywhere in the world. Web applications are being built at an ever-increasing pace to satisfy the need for information and deliver content-rich, user-friendly applications to users. With the increased demand being placed on IT departments to build and deliver business applications, HTML, CSS and JavaScript are being used to develop creative, immersive and cutting-edge Web applications.

One of the trickiest tasks any Web developer faces is the ability to build and deliver the same functionality and richness across multiple browsers and devices of various form factors. The introduction of HTML5 and CSS3 makes this task even more challenging as not all current browsers support the same HTML5 and CSS3 features. Browser vendors are incrementally adding support for new HTML5 and CSS3 features with periodic browser updates, which further complicates the matter.

Some of the key challenges faced by Web developers when building Web applications for browser and mobile devices are:

• Maintaining JavaScript and CSS code across Web pages and Web browsers
• Providing degradable functionality for older browsers
• Reducing the maintenance and testing burden on developers
• Learning curve required to build immersive user experiences
• Leveraging new CSS3 and HTML5 capabilities in newer browsers

JavaScript framework libraries help developers overcome some of these challenges without limiting creativity and functionality required to deliver cutting-edge applications to their users. One of the common JavaScript framework libraries that Web developers use to address these challenges is jQuery. Since it was introduced in 2006, jQuery has received support from and continues to be used by some of the largest companies in the world, like Microsoft, IBM, Google, Nokia, Amazon, Twitter, DELL, Best Buy, NBC, Bank of America, ESPN, CBS News and EA video games to name a few.

Simple and Easy Access to HTML Elements

jQuery provides developers with fast and easy access to HTML elements via the Document Object Model (DOM). Since the aim of any Web developer is to provide access to content to the widest possible audience, jQuery makes this possible by providing developers with the ability to have clean HTML markup with unobtrusive DOM scripting so that Web pages will still work in older browsers that have reduced or no support for JavaScript.

Cross-browser Compatibility

Web developers know all too well the pain and effort involved in creating a Web site that works the same in all browsers – let alone keeping up with new browser versions while maintaining support for older browsers, which do not disappear overnight. jQuery provides the ability to build consistent cross-browser functionality and overcome browser inconsistencies. It also provides developers with a consistent framework to leverage new HTML5 capabilities, while catering to all existing browsers and variations in functionality between them.

Faster Development Time

The amount of functionality that is already built into jQuery – and the ability to use jQuery user interface (UI) to provide consistent theming and CSS support – gives Web developers a head start when building Web applications and enables them to focus on the business logic of the application. The jQuery UI controls are a separate library to the base jQuery library and provide sophisticated composite functionality, which gives developers ready-to-use rich controls like date pickers, tabsheets and auto complete functionality to name a few.

Extensibility and Plug-ins

jQuery was designed to be easily extensible and co-exist with other JavaScript functionality on Web pages. This allows the developer community to build and deliver UI controls and extensions to the base jQuery capabilities. jQuery UI with Themeroller support uses this plug-in architecture to deliver UI controls that enable developers to pick and choose the functionality that they want to include within their Web pages and deliver smaller-sized Web pages to users.

Documentation, Widespread Adoption and Learning Curve

Many Web developers shy away from using JavaScript to build AJAX functionality and Web UI controls due to the lack of documentation and examples. With the widespread adoption of  jQuery by millions of Web developers (jQuery is used by 80% of Web sites around the world), it gives developers access to a large community to ask questions and discuss ideas to help shape the future of the Web. In addition, the in-depth jQuery documentation and examples make it very easy to get started.

HTML5 and CSS3 Compliant

jQuery fully supports the emerging CSS3 selectors and the CSS3 specification, which provides developers with a consistent way to deal with HTML and CSS using a single interface and JavaScript library. With the emergence of HTML5 and CSS3 support in mobile devices and tablets, it’s very easy to build Web applications to target and leverage these new form factors using a single skillset. Web developers can sleep at night knowing that jQuery will continue to support the emerging CSS3 standards in the same way as it always has – allowing developers to leverage new capabilities as soon as they become available.

Helper Utilities

Web developers will agree that a lot of time is wasted reinventing the wheel and implementing basic functionality that’s required in all Web applications. jQuery comes to the rescue by providing a standard set of helper functions and utilities to perform common tasks like string manipulation, extending and iterating through objects and array manipulation – and, most importantly, the supportsfunction that enables Web developers to test and see if a particular feature or function is available in the Web browser before leveraging its features.

jQuery and jQuery UI Framework

The ability to use jQuery and jQuery UI to leverage new UI controls and CSS theming along side JSON support when building AJAX-enabled Web sites for browser, mobile devices and tablets enables developers to create compelling Web applications and deliver information and data to users. Wizards within the Visual LANSA development environment generate a fully-functional sample Web application that leverages these capabilities – providing developers with a quick and easy way to learn and get started.

The capabilities of jQuery and jQuery UI to enhance CSS3, HTML5 and UI controls when building business applications is aimed at developer productivity, simplicity and raising the level of abstraction. jQuery hides the complexity of JavaScript, HTML and CSS  and provides developers with the right set of capabilities to continue to build creative, immersive and compelling Web applications — faster and better than ever before. In summary, enabling developers to focus on the business and NOT the technology aligns perfectly with jQuery’s mission of “Write Less. Do more.”

Over the last decade, Global Data Synchronization (GDS) has been evolving as a standard practice for businesses to share product data. This practice is greatly improving the accuracy of product data, increasing the speed to market for new products and reducing the costs in the supply chain. Within the last year, we've seen Global Data Synchronization move into new phases:

• The early adopters have integrated GS1 Item Alignment into their everyday business processes.
• More industry verticals are selecting GS1 Item Alignment as their standard method for exchanging product data.
• An expansion to new regions and product synchronization across regions is becoming more common.

As testimony to the widespread adoption, the use of GTINs (Global Trade Item Number) continues to expand and the Global Registry has now reached 7 million strong. In the Consumer Product Goods space, GS1 Item alignment is mature and this is influencing the later adopters. A lot of lessons have been learned and the keys to success center around GS1 Item alignment integrated into core business practices.

What has been happening over the last year?

UConnect Live 2011

At the annual UConnect conference held by GS1 US, the increased adoption and implementation of GDS standards was evident. GS1 Item alignment has become more mature — with not just the larger organizations participating, but small- to medium-sized companies imbedding standards into their internal systems and business processes.

LANSA Data Sync Direct User Group

We held our first LANSA Data Sync Direct User Group meeting at the 2011 UConnect conference, which was well attended by our customers. The biggest challenges they face are keeping up with the standards and gathering, sending, or receiving their item data faster and with increased accuracy. We're focusing our new development efforts mainly in the area of increasing speed, accuracy and usability of our applications to meet these demands.

GS1 UK

LANSA has recently become the first certified solution partner providing an automated end-to-end Global Data Synchronization solution for GS1 UK, where activity with GS1 Item alignment is increasing. Businesses in the UK are seeing the benefits that are being realized in other regions and are moving towards adoption of the GS1 standards.

Foodservice Industry

The foodservice industry has moved away from proprietary Item alignment and has adopted GS1 standards. A GS1 Foodservice Initiative was formed about three years ago to respond to their specific needs, resulting in guidance for those companies in this sector. A set of Phase 1 and Phase 2 attributes was identified and has since been implemented in the standards in 2011.

Healthcare Industry

The healthcare industry is focusing their efforts on adopting GS1 standards to keep up with requirements to have better, more accurate product definition and identification. We're seeing a lot activity in the GS1 healthcare workgroups as companies work towards addressing any shortcomings in the standards to ensure that GS1 Item Alignment will be successful in their line of business.

Global Integrated Solutions

We're also seeing more and more global solutions being put in place. As many of our customers move towards global ERP and/or Master Data Management solutions, they're using LANSA to connect to these systems to leverage this product data. Many of the greatest successes with GS1 Item alignment are when there is a single point of truth for the management of product data.

How do you take advantage of Data Synchronization to benefit your organization?

STEP 1 – Create a Global Data Synchronization Plan

• Align with one data pool.
  • A certified GS1 Data Pool should be able to provide you one entry point into the Global Data Synchronization Network (GDSN). If you're being asked to join more than one data pool, ask a lot of questions and encourage your trading partners to only use GS1 standards. If they use standards, you should be able to select any data pool of your choice.
• Understand GS1 item alignment standards and rules.
  • Use your data pool to train you on GTIN and GLN (Global Location Number) standards and allocation rules.
  • Identify if any packaging or labeling changes are required for your products to meet these standards.
• Identify who owns GDS in your organization.
• Identify your key trading partners that will provide you the greatest benefit with which to align your product data .

STEP 2 – Understand Your Product Data

Having one single point of truth for information about your products is the key to Global Data Synchronization. Identifying that one point of truth and building systems and business processes around that will create the ultimate benefits for your organization and your business partners.

• If you are the Supplier of product data:
  • Identify the one place where a product attribute will be maintained and who the owner is of that data. Product attributes may reside in many systems within your organization. It's important to select a solution partner that can aggregate these product attributes and provide the ability to fill in the gaps for product data that you don’t currently have.
  • Verify the data for accuracy and put processes in place to keep this data accurate.
  • Identify who is responsible for the data and the processes to approve any new items, changes to items and the discontinuation of items.
• If you are the Recipient of product data:
  • Identify the product data you will receive via GDS and how you will leverage that data inside your organization.
  • Identify the product data you do not receive via GDS and how that data will be assigned and maintained.
  • Select a solution partner that can aggregate the GDS- and non-GDS data and integrate with your internal systems.

STEP 3 – Execute Your Plan

• Implement your integrated solution enabling product data to smoothly flow through the supply chain.
• Implement your business workflow for verification and approval of new products, changes to products and discontinuation of products.
• Align your product data with your trading partners via publication and confirmation processes. The more partners you align with, the greater the return on the investment you have made in GS1 Item alignment.
• Stay in tune with developments and changes within GDSN. If your industry sector has workgroups or user groups, it's helpful to participate. Keep in regular communication with your data pool and with any community activities they offer.

If you're new to Global Data Synchronization or you're looking for a better way to align product data with your trading partners, now is the time to get started. The standards, tools and adoption levels are mainstream and you just need to develop the plan that's best for your organization to maximize your benefits.

There’s delicious irony in Dan Burger of IT Jungle breaking the story that finally lays to rest the ghost of IBM’s ill-judged campaign: “Sure there will be other jobs for programmers who don’t know Java.”

Dan tells the story of long-time IBM AS/400 shop the Harry Fox Agency (HFA), where a couple of IT managers decided their "RPG resources were far too great to squander." This story was refreshing because I invariably read articles and discussion threads that couch the future of RPG developers and the IBM i platform in simplistic black or white terms that belie the real issues and options.

In the black hat camp we have the doomsayers who advocate “get the hell off the platform right now and get your hands dirty with something that has a future.” On the other side, the big blue hat proponents are tarred with being the “make do and mend brigade who allegedly won’t learn anything new and who are secretly saving their energy and creativity for retirement.”

The Harry Fox story dumps on these idiotic stereotypes and demonstrates a common sense approach that other RPG shops could easily emulate. The first mistake the black hats make is to regard “a legacy system” as a single entity to be discarded rather than an asset to be managed. Even the blackest of hats would struggle to argue that an IBM POWER7™ system is not state-of-the-art hardware. In most cases the RPG applications are not broken and collectively they represent great business value. So, where are the problems with being an RPG shop and what is the risk of just staying put?

The RPG programming language has two limitations that cannot be ignored when assessing business risk: it is an IBM platform-specific language and the talent pool is diminishing with fewer new developers entering the community. These limitations combine to fuel ever-spiralling costs for maintaining RPG applications.

So a good first step is to draw a line under those RPG apps by assigning them to be modernized rather than actively developed. This designation is seen by some people as a derogatory term, but it shouldn’t be. Modernization is merely short-hand for that series of tasks that keeps applications in-tune with the needs of the business and its users. But to spend more than the minimum is irresponsible when you consider that for every $1 spent maintaining an old system you are building-up a $3 debt for when you eventually re-write or migrate the legacy code. But the other extreme, starting-over again in a new language like Java, is even more fraught with risk and unjustified in many cases.

It is a fallacy to assume that “newer is always better” because there is genuine commercial value in stuff that already works and good software developers know the business as well as the technology. In my experience it is the business knowledge that is hardest won and therefore vital to persist as corporate memory, whereas skills with a particular programming language, database, or operating system can diminish in value as technology evolves. This point is underscored in a quote from the Harry Fox story:

“I wasn't sure of the direction I needed to take the RPG team. The CIO explained how valuable the team was. So I started to understand what they were doing. I realized that these guys are the ones that know everything and have the deepest history of our data and solutions. They handle the guts of our processing here. On top of that they are extremely sophisticated in the whole process of setting up the data structure, writing good code, and testing it; they know everything from the requirements stage through the deployment of the product. To me, that is more than 50% of being a good coder. And they know the music business. When you bring a new developer in off the street you don't get this.”

I could write ad nauseam on the topic of application modernization but instead I commend you to read the free eBook Application Modernization For Dummies. My colleague Richard Lancaster has produced what I’m sure will become the superlative work on the subject. You can read the full story about the experiences at Harry Fox here.

We, in the western world, are living through an era of increasingly fewer computer graduates entering the workplace and we are operating in a global marketplace where technical competency (like writing code in a particular programming language) is being seen as a commodity skill that can be outsourced to cheaper locations. If you are an RPG shop then please, before you embark on your next major application development, modernization, or integration project, ask yourself “how can I best up-skill our existing software developers?” rather than “how cheap and easy will it be to find new Java, C#, PHP, HTML, [blank] software developers and then integrate them into our team?” Never underestimate what great people can achieve with good tools.

I leave you with the sage words of HFA Senior Vice President and CIO Lou Trebino, “RPG was ‘Oh, my God, get the garlic out! It's not something we're going to touch.’ Now, with LANSA in place, the RPG team is on an equal footing with the Java team. It's part and parcel of every decision we make for every application including new and revitalized apps.”

How closely does the average IT shop actually follow emerging technological trends and the advice of leading industry analysts and the media in planning their budgets and projects? When Gartner says they predict large organizations will establish "cloudsourcing" teams or that future applications will be integrated with social technologies or that organizations will need to provide applications to interact with customers via mobile devices, does this impact your planning?

If you follow the industry analysts, in particular Gartner, you will be accustomed to seeing predictions about the future of Information Technology — software, applications and infrastructure — often numerically identified Letterman-style as a "Top Ten" list. I recently referenced Gartner's Top Strategic Technology list for 2011 in my blog post "Reaching for the Sky -  Cloud Computing." Afterwards, I pulled the lists for the past three years to see how these trends have changed or evolved. 

For reference, below is a summary of Gartner's Top Ten Technology Strategies for three years in a row. Their predictions for 2012 will come out in the fall.

Gartner’s Top 10 Strategic Technologies

A striking shift I've noticed between IT trends in this decade versus previous decades is how corporate IT strategies are becoming mirrored by — and even triggered by — activities in the consumer world.

With the proliferation of the Internet, where computers were once the domain of the technology professional or “geek,” they are now in the hands of literally everyone with increasing capacity, capabilities and mobility. And this has had an exponential impact on the growth of the technology. If you consider the top four strategies in Gartner's 2011 list, all of them are driven by widespread use of the Internet, smart phones and social media.

As an executive with a leading software vendor, I know that following these trends is important so that we can stay at the leading edge and provide our customers with advanced capabilities within our software as and when they are needed. There are some organizations who are keen to implement new and evolving technologies and stay ahead of the pack. However, we are working with many organizations who are so engrossed with their operational and systems' challenges that they are barely paying attention to Gartner's hot items, like cloud computing, mobile applications and social media. Does this mean these organizations won't be able to remain competitive in an increasingly complex business climate? I believe the answer is "not necessarily — and it certainly depends on your industry and target customers to some extent."

There are so many directions you can follow today that most small- to medium-sized organizations can't do them all anyway. (Think of your social interactions — should you text, email, Twitter, Facebook, or call someone on their mobile? Sometimes, it's simpler to just wait until your next get together.)

Many organizations must focus first on ensuring they have efficient line of business applications that keep up with their changing organizational needs while, ensuring that mission-critical apps remain stable and perform well. We encounter many companies with 20-30 year old legacy environments which must first be brought forward to current architectural and development capabilities so that they can be poised to take advantage of advanced technology.

I recently met with an organization in this situation and they aren't concerned with whether they have GUI interfaces, SOA architecture, browser-based applications for Web or mobile, Web services, a social media presence, or even a cloud strategy. They are about to upgrade their decades old RPG and SYNON code on old hardware and an unsupported release of OS/400 to current hardware, OS and an improved software environment. They plan to follow a staged approach to transforming their applications so they can leverage their information rich system and gradually enhance and evolve this into current technology. And meanwhile, their business has been in growth mode. While they are at a stage where it is critical that they start to move their monolithic legacy systems forward, their inability to keep up with trends does not appear to have hurt them (yet). The situation will depend on the industry and competitive landscape to some extent but, generally speaking, internal systems and operations should be addressed first.

So, for many organizations, taking care of your core applications is critical and must take highest priority. Watching the trends and predictions by analysts will help you plan for the future. If the current trends continue, then you actually may be able to assess this yourself by observing what technology you, your family (especially your kids) and friends are using.  Although, the industry experts should help you understand how the latest technologies are translating into IT implementations where significant ROI, customer satisfaction and business value are the outcome.

While technology improvements have lowered the cost of building and deploying business solutions, until recently, the software and implementation cost of Customer Relationship Management (CRM) systems was unaffordable for most small to medium businesses who rely on their IBM i for their line of business applications. CRM is a strategy for managing a company’s interactions with customers, clients and sales prospects. It involves using technology to organize, automate and synchronize business processes—principally sales activities, but also those for marketing, customer service and technical support (Source: Wikipedia).

A CRM system should provide at least basic information about the companies or organizations (accounts) and the people you work with at those companies (contacts). Accounts can be your customers (or leads), but they may also be your suppliers, your partners, or your subcontractors. While highly extensible and customizable, a CRM cannot be everything to any and all businesses. It also has its limitations, and not acknowledging them upfront often leads to frustration or poor user adoption rates. In turn, this usually translates to a business never fully realizing the benefits of a CRM system.

CRM Feature Set

As CRM tools have matured over the years, a set of functionality has evolved based on well-known sales methodologies, marketing best-practices and other popular trends and processes from the business world. A CRM system should support the following:

Sales force automation (SFA) - the ability to capture lead (potential customer) information separate from actual customers; the promotion of leads to opportunities and sales forecasting tools.

Opportunity management - tracking of revenue opportunities, including attributes, such as the sales stage and likelihood of winning the business.

Sales pipeline tracking - graphical representation of the sales pipeline, offering drill-down from the bar or segment of the chart to the data that underlies it.

Definition of sales teams and territories - helps to manage information sharing and tracking sales performance by territory.

Marketing automation - tools that automate the execution of marketing campaigns, such as bulk email.

Lead source analysis of sales and opportunities - analytic tools providing insight on the return from differing marketing efforts.

Activity management - ability to hold and schedule all the appointments, meetings, scheduled calls and planned tasks.

Quoting - allows a sales person to generate quotes pertaining to products or services offered by your business.

Flexible reporting - analyzing CRM data from differing perspectives is critical to track the effectiveness of business practices and sales and marketing efforts, identifying issues and other trends within the business.

Service case tracking - service or support capabilities such as tracking product defects, managing support contract renewals and tracking service inquiries from customers.

Activity management - this can be used for arranging meetings, scheduling calls for customer follow-up, or setting reminders to perform other tasks.

Employee directory - simplifies communication among fellow employees.

Interface consolidation - helps eliminate data silos within your business. Consolidating information and data from disparate systems or sources makes it easier for everyone in the organization to know what is happening with any given customer and, in turn, provide a better customer experience.

Document management and revision control - helps in managing and retaining reference copies of important documents, such as company policies.

A well-conceived CRM must also have a truly outstanding user interface, as the whole purpose of the system is to make the organization's information accessible quickly, easily and naturally. If users do not utilize the system because it is too complex to access or use, it will be difficult to realize its potential benefit.

Do you need a CRM?

A CRM may not relate well to all types of organizations. Some of the questions to consider are:

• Is the sale made to an other business (B2B) or an end-consumer? This impacts the structure and relationship between accounts and contacts.
• Are products or services sold? Services typically involve an ongoing relationship over a period of time with an income stream.
• What is the average value of a sales transaction, the length and complexity of a sales cycle and the likelihood of repeat business? Marketing campaigns have more value when tied to customer loyalty mechanisms, and leads and opportunities have more significance.
• Size and location of the business. Where are sales made? From an office,  at the client’s premises, or over the Internet? Is the staff in the office or in the field selling? How complex is the organization, and how is sales information shared or protected from other team members?
• Internationalization. Do non-English users and data need to be handled? Are differences in date and local currency entry and presentation and timezone important?
• What is the cost and availability of  technical and project management expertise needed for the CRM installation, customization and implementation, training and ongoing support?

Should I feel comfortable with an open source application in my organization?

SugarCRM is unique as an open source application, meaning that the source code of the application is available to any user, developer, or customer of the product — including all source code to enable developers to customize and build on the product with ease.  The current version as of August 2011 is 6.1 and is available in 5 versions from the freely available Community Edition to the Ultimate Edition. The Community Edition does have a strong developer ecosystem with both a free add-on available at Sugar Forge and free online training and documentation at Sugar University.

Sugar requires an open-source LAMP (Linux, Apache, MySQL and PHP) application stack, and can run on Windows (using IIS and MS SQL Server or Oracle) and is also offered as Software as a Service (SaaS) on cloud platforms like Amazon EC2, IBM Cloud and Rackspace.

The platform and version focus of this blog post is running SugarCRM 6.x Community Edition on the IBM i alongside an organization’s other core applications. On the IBM i, Sugar uses the PHP language to build the browser interface running with IBM’s Apache Web server interacting with Zend’s open source Application Server and mySQL as the database server. Once these are installed, the Sugar Edition is installed over the top. IBM provides an IBM DB2 for i Storage Engine for MySQL, which allows seamless access to MySQL data from native IBM i-based languages like RPG, LANSA and Query/400.

Developer Features of the SugarCRM Platform

Modular Design – each part of the application is its own module, and the modules can interact with each other through data relationships. You can build on this base by customizing the modules – adding new fields, additional relationships and business logic.

Metadata Driven Views – the designer can customize metadata driven views and generate the resulting HTML content. This makes it easier to build and customize forms.

User Authentication and Access Control – user authentication can be tied to existing LDAP or other types of authentication. Each user can then have multiple role permissions applied with fine-grained control over the application modules a user can access. The user rights can also be assigned to record-level access.

External Services Integration – via Sugar Connectors (to LinkedIn ) or Microsoft Office and Outlook applications or the SugarSOAP API via Web services to the published API.

Ease of Administration – a simple to use interface that includes the Studio to add and edit fields, change layouts and add new relationships. A DropDown Editor allows the setup of drop-down values for existing and new fields.

Import Wizard – data from old CRM systems can be imported, mapped and validated during the import to Sugar  process. There are preset templates for users moving off popular CRMs like Salesforce.com™, Act™ and others.

Implementation Lessons Learned

Having recently completed a Sugar implementation for a large CRM in the health products industry to support a worldwide multilingual salesforce and support the cycle from marketing, opportunity definition through lead tracking through to the conversion to an account — the functionality offered by Sugar via a browser interface accessed by the mobile salesforce on an iPad was a major step up from the older Windows-based CRM. In addition to the typical implementation management and user adoption tasks, there were some key criteria the project success was measured on:

Performance – the Linux/PHP/mySQL architecture is not native to the IBM i and needs to be monitored and optimized where possible. Sugar has released a set of recommendations on tuning and optimization.

Data Integrity – a CRM is a portal view into other systems that touch the customer relationship such as ERP, workflow and document management systems. Use Sugar’s modular architecture to ensure that data is validated on entry and key relationships are maintained between Sugar and the other critical systems so the user can seamlessly move between those applications.

Integrating Sugar with your core applications – IBM's DB2 Storage Engine for MySQL will allow native access to the Sugar database from your RPG or LANSA applications and allow the customer facing staff to use Sugar as a portal to seamlessly access everything required to give a 360° view of the customer relationship. On the IBM i, this can be achieved using:

• Tools that support Web services, such as LANSA Integrator, which will use the Sugar API to control the Sugar actions based on external events, such as the process of converting a lead to a customer, or accessing other systems containing customer sensitive information.
• Tools that provide programmatic control over 5250 screens such as aXes, which permits your AS/400-based screens that allow price lookup, customer order history and order creation to be available from Sugar.
• Tools that standardize and report compliance with business processes, such as workflow and document generation, so customer case management and issue management and resolution are managed in a standard way — and dashboards in Sugar measure the improvements in customer satisfaction.
• Making use of wireless and customer self-service interfaces, whether based on Sugar’s own offerings in the Professional and Enterprise Edition or custom developed using Visual LANSA for Web Development and native access to the Sugar database.

If you are looking for a inexpensive way to extend your application suite with a customizable low-cost CRM that has a large community of developers and consultants to support it — and runs on a diverse set of platforms including IBM i — you should evaluate how well Sugar can meet your needs.

Guest Blogger: Paul Conte, President PCES, is a leading Application Development Strategist.

“Give us the tools, and we will finish the job.” – Winston Churchill, February 9, 1941

While application modernization isn’t as daunting as the challenges Churchill faced during World War II, application developers and IT managers may feel his words perfectly express their sentiments as they face a mountain of “legacy” code that needs updating.

Some developers may wish for the kinds of bombs and artillery Churchill wanted, so they can blow the legacy code to smithereens and start fresh without all the headaches of gnarly old code. Dropping a bomb on an enterprise’s code portfolio might be gratifying to the IT team, but it would likely destroy the enterprise along with the code.

When more sensible views prevail, development teams often start looking for the right “modernization” tools to help them finish (and, in many cases, start) the job.

To help in that search, here’s my “top 10 checklist” for finding the right tool.

1. Get a good handle on what “modernization” means so you know what tool capabilities you need.

Here’s an example: You need the ability to create a variety of user interfaces – Web, mobile, etc., but “refacing” isn’t where modernization ends.

Go deeper and look at the full range of modernization issues that need to be addressed. A good starting point is my Transforming IBM i Applications eBook Trilogy.

2. “Kick a few tires” to get a “real world” feel for the variety of tools that are available.

I’m not talking about lengthy “test drives” of modernization products. That comes later.

But settle in to watch some videos on vendor Web sites, visit trade show and conference “expo” booths and invite some vendors to present their demos on-site.

Keep written notes of what looks promising, as well as concerns over missing functionality or other deficiencies in the products you look at.

3. Get advice from your peers in the IBM i “social network.”

Hearing about other IBM i developers’ experiences with modernization tools is invaluable. You wouldn’t buy a car without plugging into the discussions on Edmunds.com, would you?

To use your time productively, I’d suggest getting customer references from product vendors and using that “legacy” device, the telephone, to call. For some reason, serious i application developers don’t seem to be hanging around a particular Facebook site to share their insights.

4. Sketch your “use scenario” and your “enterprise application architecture.”

I always think it’s better to get some initial exposure to what’s really out there in the product world before jumping right into writing specs for a “Request For Proposals.” But if you followed the first three tips, now is the time to shut your office door and draft a concise description of where you are and where you want to go.

A “use scenario” is a collection of “use cases” and other information that describes your situation and needs. So, for example, are you focused on having your applications able to run on platforms in addition to the IBM i? Is support for mobile devices or other UI technology a priority? And so on.

An “enterprise application architecture” describes how a set of building blocks and principles should be used to design, implement and adapt applications that fulfill the enterprise’s business objectives. A well-thought-out application architecture not only provides a conceptual structure to guide developers; the architecture lays the foundation for a corresponding framework and tool set that can automate much of the application development effort, an essential prerequisite for greater agility, productivity and reliability.

You can learn more about these two subjects in the Transforming IBM i Applications eBook Trilogy I mentioned earlier.

5. For most IT organizations: Go with an integrated product.

In theory, your organization can define an application architecture and assemble disparate tools to implement your architecture. In practice, this requires adequate staffing to support a home-grown infrastructure.

Modernization isn’t a one-time “face lift” or “code conversion” for your old RPG code. Modernization is a transformation of your application development strategies so you can efficiently deliver the right information and capabilities to the right people at the right time, as determined by changing business needs and initiatives.

For most IBM i organizations, purchasing an integrated “application generator” is the most practical way to deploy the tools necessary to fulfill this objective.

6. You’re going to need a tool that provides an “application repository.”

An application repository provides persistent and structured storage for all the information that defines applications. The repository may also contain information related to requirements, standards, environment and other aspects of application development and deployment.

The pivotal advantage of a repository is that shared application items can be stored, managed and reused effectively. Items like data element definitions, business calculations, user interface templates, code snippets and so forth can be defined once and used across many applications and developers in a consistent manner. Having one definition for a shared repository item yields application consistency, and having a “single point of truth” greatly simplifies modifications to applications.

7. Take any candidate product for a hard “test drive.”

One of the most common mistakes I’ve seen when an IT group evaluates a modernization tool is that their “test drives” usually are comparable to making sure the wheels roll and the brakes work during a new car test. Not very demanding, in other words.

What you need to do is what I did when I tested the “sport sedan” (an Infiniti) that I later bought. The salesman had been touting the superiority of the “I’s” anti-lock braking system. So I went to a large, vacant parking lot; accelerated to 40 mph; and then jammed down hard on the brakes while whipping the steering wheel sharply to the left. Impressively, the “I” rolled right through the sharp turn with no skid at all. That’s when I knew the car measured up to its promotional literature.

So, throw hard cases at any prospective tool to see how well it handles under pressure.

8. Spend a lot of evaluation effort and reference checking time on how well a tool enables you to exploit the functionality of your existing code.

For many i development teams, the biggest hurdle to comprehensive modernization is the insurmountable cost required, not to mention the risk, to “rip and replace” legacy RPG code. Consequently, the ability of a tool, such as an application generator, to incorporate existing application functionality is critical and varies widely among available products that support the IBM i.

9. Evaluate “risk” realistically.

Humans are notoriously bad at correctly assessing risk, and IT professionals aren’t immune to this limitation.

Your enterprise and IT management is likely to be uneasy about the risk of acquiring tools for application development that aren’t as widely used in the industry as Java or SQL.

The reality is that no comprehensive application modernization tools for the IBM i will ever reach the level of use enjoyed by these two languages or some of the popular code-centric Integrated Development Environments (IDEs), such as Visual Studio and Eclipse.

But here’s another reality: No version of RPG and its associated IDE will ever have much of a market presence either.

So an enterprise with a considerable investment in RPG code needs to compare the risk of a future development strategy based on writing more and more RPG code using an IDE or using a tool, such as an application generator, that frees developers from low-level coding complexities and allows them to focus on business functions, a wider range of user interfaces and better integration with internal and trading partner applications.

Although I don’t have concerns about the IBM i or RPG compiler “going away,” corporate mergers and acquisitions that force IT to support a different platform, as well as or instead of the IBM i, are just one of the “risks” that IT must also consider in choosing a development strategy. Application generators that target additional platforms, as well as the IBM i, are one tool that can mitigate this category of risk.

There aren’t any canned answers to balancing risks, so give this critical dimension of your modernization strategy very careful consideration.

10. Budget adequately for training and mentoring.

Beware of “shelfware”!

With any powerful tool or toolset, including an application generator, your organization will benefit tenfold by having adequate initial training and mentoring.

While good tools can automate and standardize much of the “glue and plumbing” code required in modern applications, the same tools provide such wide latitude to developers that you want to get off on the right foot using “best practices” learned from training and mentorship.

Training provides a foundation in the common ways a tool is used, mentoring provides invaluable advice on the best approach to unique enterprise requirements or cultural practices.

There’s another bit of wisdom that the “Great Old Man” passed along, which seems appropriate to IBM i developers and managers facing the challenges of application modernization: “A pessimist sees the difficulty in every opportunity; an optimist sees the opportunity in every difficulty.”

I certainly think there’s lots of opportunity in a well-planned IBM i modernization strategy.