Your organization has systems helping manage enterprise-critical activities and information – and your team is the key to keeping these systems vital. Sustaining the rapid pace of business and technology is crutial to your company’s success. Let’s look at how you can make change happen and build knowledge within your team, empowering them to take your enterprise systems to new frontiers.

Chances are you have a wealth of valuable business information in your systems. It’s equally likely that people in departments around the company have ideas of how the systems can be made better. When the ideas, the information and the goals of the company come together, this can be a powerful motivator for change. Then, your team has the responsibility of making change happen.

This discussion will focus on three areas for simple, but powerful system enhancements:

• View, Extract and Analyze Information
• Streamline Business Processes
• Leverage Existing Skills and Tools

A Common Situation

Often a large amount of focus is placed on making the processing of transactions in systems more efficient. This is good, because your critical data must be accurate and your people must be efficient. This is also good because it builds a solid foundation of critical data that can be mined to facilitate better business analysis and better decisions. This discussion assumes there is a foundation of good critical data in your enterprise systems that you desire to explore.

Easing the Approval Process

Before we jump into the discussion, I must remind everyone that all enhancements should be put through proper business justification to determine how they fit into the plan and strategy for the business. Refer to the previous blog series on "How to Justify Legacy Application Modernization to your CFO" for information and techniques on justifying business system enhancements.

One of the keys to easing the approval process is to have the tools, knowledge and skills in place to maximize effectiveness and minimize cost and time. Many tasks will be easier to justify and gain approval if, rather than having to say:

• That will take 20 days
• We will have to buy software for $10,000
• It will take time for our staff to ramp up their skills

Instead, you are able to say:

• We can get that done in 2-3 days
• We have the tools we need
• We have done this before on another project

Once the tools, knowledge and skills are acquired, they can be utilized across many areas – making it easier to justify similar enhancements going forward.

View, Extract and Analyze Information

Sometimes great improvements can be as simple as providing well-designed inquiries to the people that do the job. To start, observe the people doing the job. Review the questions that are asked in the daily flow of business and examine people’s ideas. Focus on the ideas that promise the greatest improvement. Create a Design Outline to define and communicate the concept for discussion and approval. Then in a very short time – utilizing good tools such as program coding assistants, combined with existing or refined logical views of your data – your front line people can have a tool that allows them to find more information in less time utilizing very flexible search criteria. Let’s take a look at a few scenarios that illustrate this:

Scenario 1

Consider the Accounts Receivable department of a large company. The department consists of just three people. These people perform hundreds of transactions daily, including posting payments, adjusting invoices, posting credit memos and performing write-off’s. Additionally, throughout the day they answer questions received via phone calls from their large customer base. The information is all in the system and is available via inquiry screens. This is good (absolutely essential). However, when customers call in, they provide one or two tidbits of information. Some provide an invoice number, some provide a customer order number, some provide a purchase order number, some provide a payment number and some provide an invoice amount or payment  amount. This is quite a variety to accommodate.

Here is a rough plan for addressing this situation:

• Step 1: Provide a filter which allows them to enter whatever tidbit of information is provided by the customer in order to efficiently search the AR information.
• Step 2: Ensure that once a selection is made the detail screen(s) concisely display the information containing the answer.
• Step 3: Provide simple access to related information because often other questions arise once the first answer is provided.
• Step 4: Allow the information to be simply forwarded to the customer via email or other quick electronic means, leaving them confident and happy.

When these things occur – combined with short duration and a pleasing tone during the call – you can rest assured that you’ve provided great customer service.

The following example is presented inside an application framework. The filter provides searching by a wide variety of customer information. The detail screen presents the information concisely. The tabs provide simple access to related information. The report viewer and PDF generation tool present the report and allow simple emailing to the customer.

In the Accounts Receivable situation just described, the components involved included using a:

• Program coding assistant (or filter template) to quickly generate the desired searching and list display capability
• Framework to facilitate the creation of links and navigation between related inquiry screens
• PDF generation tool to create a report to email to the customer

Scenario 2

If we take the above scenario just one step further, with simple integration of the detailed information to a desktop tool like Microsoft Excel, the information can be simply and accurately downloaded for analysis, sorting, graphing and then reporting or emailing. Often your enterprise systems contain all of the information necessary to answer a question and analyze or provide information. But if the format is not right, or the information crosses many screens or types of records, the job is difficult. Integration of desktop tools such as Excel can save countless hours of manual review, entry and analysis. If you can save hours and minimize errors in collection of the data, then your key people can spend more time adding value to the business by making better business decisions.

In this scenario, the user has requested the display of historical information regarding a customer’s account. Several years of information reside in the system and the application has the proper filtering to allow selection and presentation of the information. But if the request is to analyze the information or provide it to someone, what do you do? Do you capture several screen shots? Do you manually enter the information into a spreadsheet?

Here we facilitate the automated capture of that information into a spreadsheet. There are many tools available to accomplish this. This scenario utilizes the inherent technology of the Visual LANSA Framework to “Load to MS-Excel” based on filtering already accomplished.

In this scenario, the components involved included using a:

• Tool to read a list and load it to a Microsoft Excel spreadsheet (or csv file)

The resulting benefits include: accurate information, efficient use of time and usable information that can be analyzed, sorted, graphed and formatted for proper use.

Scenario 3

Now let’s move up to the management or executive management levels of your organization. Suppose one facet of your organization’s health is judged by monitoring daily orders booked compared to the past 10 days, or compared to the same time last year. Wouldn’t it be great if executive management were able to quickly pop up a dashboard and see the real-time volume of orders booked in line with the past 10 days or the same time last year.

There are a few things about a dashboard that make it a great choice for this situation:

• Information can be presented graphically, at a high level, using colors or symbols that make it obvious whether performance is good or bad
• It’s self-service. Management does not need to ask anyone else to do anything to get the information they desire.
• Information can be presented in real-time. Management is seeing the latest and greatest, which is already more current than any report.

Summary — View, Extract and Analyze Information

The beauty of these three examples is that no difficult modifications are required to your core systems to provide the desired results. This minimizes risk, reduces time to provide the tool to the people who will use it and improves your standing with key people. You solidify your reputation as a person (or team) that can provide accurate information with efficiency to enhance people’s jobs.

Streamline Business Processes

Now let’s review ways to streamline business processes, including:

• Event Notification Triggers
• Workflow

Event Notification Triggers

Event Notification Triggers are a simple means of making your systems proactive. When a defined event occurs in the system, an email containing important information and a message is sent to interested parties. This allows the interested parties to take action in a timely fashion. It’s a means to “push” activities along.

Workflow

Workflow is the full-featured way to streamline business processes. Setup includes defining the process flow, roles, responsibilities and actions. Then, as steps in the process occur, the next step appears in the “To-do List” of the next party in line. As the process proceeds, full history is kept. Full integration allows access to your system’s transaction screens to perform the required actions and advance the flow to the next step.

Summary — Streamline Business Processes

Event Notification Triggers are a great way to ensure that people get information as soon as a critical event occurs. The inclusion of important information and a message allows them to take action with little or no research. Event Notification Triggers require no new software, very little setup and very little coding.

Workflow is the right path if you want tight control of critical business processes, along with full history, document generation and additional features. Workflow requires licensing a workflow tool, detailed setup and can require significant coding to integrate fully with your systems.

Leverage Existing Skills and Tools

Companies have staff members with skills crossing a wide variety of areas including: .NET, Java, Windows, Web, IBM i, enterprise systems, RPG, CL, etc. They may also have a wealth of critical business applications and data in a variety of databases on IBM i, Windows servers and Linux servers. With the proper tools seamless integration and interaction are possible. Now is the time to leverage your strengths in each area and create a system that is seamless to the users.

Taking Your Enterprise Systems to New Frontiers

A system improvement may not affect the physical product you produce or distribute, but it can affect the service you provide, the accuracy of your information, the efficiency of your people and possibly, the profitability and reputation of your business.

All of the examples discussed above can provide valuable enhancements to your business without major changes to your core systems. This keeps you in the desirable “low risk” zone.

Open your mind to the possibilities. Listen to the people who use the system regularly. Plant seeds of ideas with key people. Get your team trained and excited. Unleash the possibilities and take your Enterprise Systems to new frontiers.

To quote the book “Oh, the Places You’ll Go!” by Dr. Seuss:

Congratulations!
Today is your day.
You're off to Great Places!
You're off and away!

You have brains in your head.
You have feet in your shoes
You can steer yourself
any direction you choose.

It may take some effort to take your first step. But once you do — combine great ideas with great tools, get a small success under your belt and you will be on your way.

The first part of Paul Conte's eBook trilogy “Transforming IBM i Applications – Your Journey Beyond Modernization,” introduces the concept of “virtual users” – referring to the technique of “wrapping” an existing 5250 interactive application with code that intercepts and controls the 5250 data stream. The technique can be implemented in a “batch” program, without any required access to a physical 5250 terminal or emulator. The “batch” program becomes the “virtual user” – a robot that can then do the bidding of another application.

The “virtual users” technique is commonly applied in the context of application modernization, and can offer compelling benefits including:

• Fast and incremental delivery
• Low risk and low cost, relative to alternatives
• Target strategic elements of the application that deliver the maximum business benefit
• Reuse business knowledge and rules that are already encoded in the 5250 application

When considering application modernization strategies, it would be unwise to overlook the potential of “virtual users.”

But what about applying “virtual user” techniques in your Business Process Integration (BPI) solutions as well? Is it valid to do so? Is it wise? Why would you do so, and what are the risks and rewards? Let me propose some answers . . .

Why?

The three key parts that comprise a BPI solution are transport, transformation and orchestration. All three of these should be core competencies of your BPI toolset, but transformation is the part of most interest in this discussion.

Transformation involves transforming data between the various formats in which it is represented both within your organisation and with trading partners. For example, you should be able to map data between standard EDI formats and your application database or from a spreadsheet to XML.

Whatever other formats are involved, a common part of many transformation requirements is getting data into or out of your IBM i application’s database. But what if it is not feasible to directly address the application’s database tables in your transformations?

If you scoff at that thought, then you are fortunate indeed and you probably need read no further. But many organisations today still employ extensive manual rekeying of data in the course of what should be routine business processes. Sometimes the reason is simply an apparent case of Hobson’s choice. A variety of factors may rule out the option of directly addressing the application’s database tables, such as:

• No specifications or source code
• Lack of domain knowledge or skills
• No application program interfaces

One of the objectives of Business Process Integration is to eliminate the manual re-keying of data. If re-keying is your only viable option, then the only way to automate the process will be to employ “virtual users” to perform the re-keying.

Consider this

Imagine a simple process involving three main steps:

1. Receive sales orders from a trading partner via FTP
2. Transform the sales orders from their XML format and write them to the ERP database
3. Call an ERP application program to initiate the order, generate picking lists, adjust stock levels and invoice the customer

Now what if, for any of the reasons discussed, we cannot perform the transformation directly to the ERP database? We might still be able to make use of a “virtual user” to automate this process. In such a case, the BPI solution might employ a “virtual user” to:

• Connect to a 5250 session and logon
• Start the order entry 5250 application
• Navigate to the order entry screen
• “Type” the order details from the XML file into the order entry screen
• Verify the results and logoff

Sometimes a “virtual user” may be employed to achieve more than simply transformation. For example, it can be good BPI practice to receive data from external parties into a temporary or “staging” database and then validate it before accepting it into your core ERP application. Now we really want step 2 of our scenario to look like this:

2a. Transform the sales orders from their XML format and write to the “staging” database

2b. Call an application program interface (API) that contains business logic and validation rules that will check the data before it is inserted into the system

But what if the API for step 2b simply does not exist? Well, again, we might make use of a “virtual user” to automate this process. In this instance we are leveraging the business logic and validation rules that are already encoded in the 5250 application.

Risks

As a general rule, implementing “virtual users” is the least preferred integration technique if any of the more standard techniques are feasible. This is because it does carry risks that are prone to under-estimation and/or discounting as not “today’s problem.” Primarily the risks fall into two categories:

• Changes to the 5250 application
  If the 5250 application that the “virtual user” will operate is subject to on-going change, then it is very important to clearly understand that such changes may also affect the BPI solution – because it depends on the 5250 “screens” having a defined layout and sequence. If the application is developed or maintained in-house, then, of course, such changes and their impact are entirely within your control, but you need to be sure that all involved are aware of the potential impacts. If the application is provided by a third-party, then you must be aware of the potential impact of patches and upgrades to the application.

• Unanticipated behaviour of the application
  I am not referring to application failures, but simply intended responses to certain inputs that you were not aware of when you designed the BPI solution. For example, imagine if entering the discount code “9Y2Z” on a sales order the week before Thanksgiving resulted in an extra pop-up window prompting you to enter an optional promotional order code. If you were not aware of this exceptional behaviour, then your solution will not be designed to handle it and will probably fail when that particular combination of circumstances arises.

These risks have the potential to affect the reliability of the BPI solution. If your organization has come to rely upon the BPI solution to receive sales orders, then a failure in the process may well be critical. The risks are by no means unmanageable but you need to understand and plan for them.

Rewards

Calculating the rewards of implementing Business Process Integration using “virtual users” is relatively straightforward.

In the simplest case, it may very simply hold forth the possibility of completing that last link in the data chain that makes the solution possible or not.

In a more nuanced case, it may be the savings in time and cost of the alternative process of discovery, specification, implementation and testing that is necessary to implement a mapping solution in the absence of existing domain knowledge.

Either way, the bottom-line rewards are the same as offered by any Business Process Integration solution

Conclusion

In general, preferred BPI techniques for integrating with an existing IBM i application include:

• Direct transformation mapping to or from the application's database and/or
• Integration via application program interfaces provided by the application

Using such techniques will generally provide the most resilient and the best performing solution as well as being the easiest to maintain.

However, if these techniques are not open to you, then you may have only the one option remaining. Implementing “virtual users” judiciously in your BPI solutions may provide the “last mile” of integration that could not otherwise be feasibly attained.

There are risks and rewards. If we were talking here about the FTSE100, I might be able to present some formulae to evaluate the risk versus reward, or a graph that plots one against the other. Alas, there is no simple calculation here – all I can offer are some considerations necessary for you to make your own judgement according to your own circumstances.

There is an oft-used truism: If the only tool you have is a hammer, every problem looks like a nail. Well, in this case, we might turn that on its head . . . if your problem is a nail, then you had better use a hammer to drive it home.

Suggestions

If you’re considering employing “virtual users” in your BPI solutions, here are some suggestions that might help along the way:

• You’ll need to have access to someone who knows the 5250 application inside-out. If that’s not you, then it may well be worth consulting the business users who most frequently use the system.
• Make sure that you document what has been done and that those who need to know, do know – so that in the event of changes or upgrades to the 5250 application, the impacts can be planned and managed from the start.
• Keep it simple – minimize navigation and data entry. Consider non-programmatic ways to minimize the navigation and data entry necessary to achieve a given result. For example, it might be that by creating a specific user-profile for the purpose, you are able to assign it a different entry menu or initial program that eliminates 5250 navigation that is not essential to the purpose.
• If the orchestration of the 5250 operations is non-trivial, or if you anticipate reusing it in other solutions, consider wrapping it in a separate callable program or function and calling it from your BPI solution.
• Generally, the performance of an automated 5250 application can be very good for many purposes, but since the navigation and data entry tends to be a very granular activity, beware of vectoring these activities through too many layers of your BPI toolset – especially if the solution will be subject to high-volume, high-throughput patterns of usage. Again, consider wrapping your “virtual user” in a program or function.
• Make sure you are familiar with the capabilities of the tools you will be using. This includes both your BPI toolset and the tools you use to implement your “virtual user” robots.

Legacy Asset Management and Transformation is the practice of maintaining older application assets so that you can continue to derive value from your stable line-of-business applications – while executing a plan to gradually transform and possibly even replace them. A common goal with this approach is to move forward in a cost-effective, low-risk fashion.

Many IT organizations struggle to keep up with the demands of day-to-day maintenance and operations. In a survey of RPG development shops run by MC Press Online a couple of years ago, 65% said they missed maintenance deadlines annually. Meanwhile executives expect IT to not only maintain a stable business environment while reacting to frequent changes, but to also ensure the company stays competitive in their industry with eCommerce, Web services/EDI, operational/business process improvements such as workflow, mobile solutions, social media integration and whatever comes next.

Although legacy applications may be born out of stagnation by maintaining the status quo (sometimes for decades) and not taking an application forward as technology and business progress into new areas, there are often solid business reasons why this has occurred. For example, lack of resources and budgetary constraints are often factors plus the legacy application may be uniquely suited to the business and difficult to replace. So while doing nothing will be detrimental over time, there may also be reluctance to take any significant steps to change and possibly destabilize the mission-critical systems.

If your IT shop has been consumed with managing a legacy environment and day-to-day operations such that there has been little time or budget for innovation and improvements, you will benefit from building a plan for Legacy Management and Transformation to ensure that your business remains competitive in the rapidly changing world of technological advancements affecting commerce today.

Drivers for transformation

Many organizations are managing legacy applications that have grown over many years along with the business. These legacy applications may encapsulate the unique capabilities and processes of the business – which can make them difficult to replace.  Architected using older design patterns, they do not easily allow componentization and reuse.

Modernization and transformation is a popular topic today and can mean many things, especially if you’re talking to different software vendors with different approaches to modernizing legacy systems. The challenge that many IT Managers face is whether to evolve and modernize their applications while bolting on new technology solutions to satisfy their business executives, or whether a “rip and replace”/ “big bang” approach to replace or convert their old applications is advisable.

From the perspective of Information Technology, the primary requirements for transforming legacy systems might be:

• The ability to deliver applications to users via current interfaces and devices, such as Web, Windows, mobile with social media integration and whatever comes next
• A modern application architecture – ensuring componentization, reuse of logic and centralized business rules and service-oriented access to key business functions

Commercial drivers for legacy transformation can vary but they generally involve product and service strategy improvements and some assessment of future markets/opportunities. For example, business priorities may require some variation of the following:

• Providing online interfaces for customers and partners to transact business directly with in-house systems
• Mobility access to some subset of functionality for the roaming workforce
• Increasing productivity via improved processing, workflow and access to information
• Electronic interchange solutions, often conforming to industry standards or governance
• Improved quality of customer- and supply-chain interactions through advanced technology
• Executive information and analysis

Information Technology’s challenge is that the business may only provide budget or requests when specific needs arise, whereas a CIO must anticipate what those needs might be and proactively prepare the systems’ landscape so the application architecture and tools are in place to deliver.

The Options

Identifying your technology and business drivers for transformation is required so that you can enroll the rest of your organization in the plan.  Commitment and alignment among everyone involved for the challenging – and sometimes costly – road ahead is crucial. As a leader in technology within your company, you will also benefit from building a cost benefit analysis for your plan.

A number of factors such as the commitment within your organization, your business priorities and the current state of your enterprise systems will help you to determine the direction to take on your journey to Legacy Transformation. In a future post, we will delve deeper into considerations and details to build a plan for transformation. At a summary level, consider the diagram above for the primary approaches and typical degree of risk associated with each area.

If you have both the mandate and the budget to replace your legacy systems then you may be evaluating some large scale replacement options. In other words, you may be considering a “rip and replace” or “big bang” approach to transformation — which is higher risk than evolutionary transformation. This may involve implementing COTS (Commercial off-the-shelf) software or full-scale redevelopment.

In some cases legacy application conversion might be an option, but one that should be considered with care. This involves taking a legacy application and converting it over to a newer technology, platform, or language while preserving the information structures and the basic logic, UI and navigation of the original application. Performing conversion may involve the use of automated tools for partial or full translation of code, screens, or database – or it may involve use of low cost (offshore) resources for heads down “replication coding.” Aside from the technical challenges of accomplishing the conversion, you must consider that you're taking an older paradigm for application development and replicating in a new technology. In this scenario, you would usually reserve any improvements or new functionality until the application is safely migrated to the new environment. Depending on the amount of effort this will require, you may be better off with a transformation approach that involves gradual redesign and implementation of “extended” solutions to provide the business with the leading edge capabilities it's demanding.

If you have limited budget or are more risk-averse and prefer “evolution” over “revolution,” you will likely be more comfortable with transforming your legacy system in stages towards a brave new world. A good first step to satisfy users while you continue on your transformation mission often involves refacing the application with a graphical user interface against the existing back-end legacy system. Enhancing an application refacing project to include workflow processing can significantly increase the Return on Investment with your first modernization effort.  The Beacon Insurance Company is a good example of effective workflow integration over an insurance legacy system.

In many cases, first transformation projects are triggered by urgent business needs to extend enterprise systems and offer new services – such as eCommerce or initiatives like Global Data Synchronization (GDS), EDI or mobile apps. In these situations, the required solutions will typically be implemented using different technologies than the legacy system and integrated via database access or service-level calls into the application. As these projects do not usually require changes to the core legacy environment, there is low risk to the line-of-business systems.

Another consideration for Legacy Asset Management is outsourcing. This can involve transferring your entire legacy application to a server at a third- party location or to the cloud. Or, you may just want to consider outsourcing the mundane maintenance activity with your legacy system to an organization with offshore resources, so that your core IT team can focus on transformation and higher priority tasks. This division of labor could both save costs and enable you to more effectively move forward with your plans.

Getting Started

Assessing your current enterprise application portfolio is an important first step in formulating your plan for transformation. Many legacy applications do not have good documentation and the knowledge of how the systems have evolved is primarily in the heads of the IT experts that manage the systems. To get started, a Legacy Asset Management Study is a good way to take stock of what you’ve got and where you need to go so you can plot out the best approach to get there. In a future post, we will get into more detail on how to build this plan.

Imagine the Possibilities

By leveraging your existing application assets while building for the future, you can begin to take advantage of more modern capabilities and design paradigms. With a strong game plan for transformation, your business can enjoy a return on your investment with innovative solutions.

Imagine a future where:

• Business priorities are always delivered by IT because systems, processes and staff arenimbleandeasilyadaptable to change
• Your organization is the first of your competitors to deploy the latest in eCommerce or supply-chain innovation to your customers
• Your business operations are efficient, automated and agile

As Paul Conte said in Book 1 of his eBook Trilogy Transforming IBM i Applications – Your Journey Beyond Modernization, “Agility, productivity and reliability are the hallmarks of ‘new generation’ applications.”

This blog series unveils the steps needed to make an ROI-powered business case for Application Modernization to your CFO. Prior episodes outlined your current resources, your goals and the first 5 steps of the process, culminating in a Project Scope or Requirements Analysis.

Output from this Project Scope included:

• Business Vision Statement
• Non-functional Requirements
• Functional Requirements
• Design, which depending on the project may include a Data Model, User Interface, Workflow, etc.
• Report of all Project Risks, and how they will be addressed
• Prototypes, to address identified risk areas and draw out early feedback and support
• Project Plan, perhaps in MS Project format, with all known tasks, resources, dependencies, effort
• Project Management Methodology, including meetings, archives, time reporting, quality, etc.

However valuable this output is, it arguably pales in comparison to Step 6 – ROI Calculations.

Return on Investment, or ROI, is the ratio of money gained or lost on an investment relative to the amount invested. There are many different formulas to calculate the returns, such as the example below. But don’t worry, this isn’t a math lesson. 

Let’s look at the big picture first.

The chart below provides context for the ROI-related steps in the process:

Of course, the Project Scope deliverables have already addressed the green blocks. The blue block will have to wait until after the project is completed and the dust has settled.  For now, we’ll focus on the gold blocks.

Predict Measurable Impacts

Although the Project Scope forced a deep dive into the requirements, design and planning, remember that it’s really all about creating business value. Here’s where you list all the business impacts that you expect your modernized system to have. Do your best to make them all measurable, ideally as dollar figures.

Here’s an example:

The numbers should come from the business owners, not from the IT team. They should be realistic. For example, note the expected reduction in revenue from traditional orders, as your new sales channels will be appealing to existing customers as well as new ones. 

Calculate Gains (in PV)

Gains caused by the introduction of a modernized business application are expected to be realized in future months and years. However, capital costs for the project itself will be spent far sooner. To get them to make sense to your CFO, you might want to express them both in Present Value (PV) – the mathematics answer to the question: “What is it worth today?”

To calculate PV, you need to set an interest rate. For argument’s sake, let’s assume a 5% interest rate. In this case, the formula for Present Value is: PV = FV / 1.05ⁿ, where “FV” is Future Value and “n” is the number of years into the future. Isolating the ROI factor of “Easier Recruiting,” we calculate:

As you can see, this has the general effect of reducing your predicted gains, as gains achieved in the future are worth less than gains achieved today, thanks to the 5% annual interest.

Using a spreadsheet, it’s easy to extend the formulas and calculate the Present Value of all expected gains. In this case, the totals work out to:

Calculate Expected Risks

Just as your predicted gains should be based on expected values, you need to calculate the expected negative impacts for each risk.

You have a big head start on this, as you identified all risks in your Project Scope. Putting aside that you plan to bring risks forward through prototyping and model offices, let’s keep things simple. For each risk, you need to approximate two values:

• The % likelihood of the risk being realized
• The cost to the business should the risk be realized

Then, you multiply them together to get the Expected Loss of that risk factor.

For example, here is a table of risk factors that may be pertinent to this project:

Although we could predict risks for five years, for simplicity, let’s make believe that these risks are not applicable after year one.

Expected Gain Exceeds Expected Cost?

 In the Project Scope, the Project Plan should list all the project costs. These should include costs for analysis, design, construction, quality and implementation. Costs for ongoing maintenance of the system should also be considered here – let’s assume $100,000/year in this example, starting in year two and remembering to use PV.

After all your hard work, this step is very simple, and hopefully very satisfying.

 (ROI) = PV (Expected Gain) – PV (Expected Project Cost) – PV (Expected Value of Risk)

So, in the simple example, we see that the total ROI is $17,462,950 – $1,854,595 – $1,144,500.

That is, the expected ROI of the modernized system in Present Value is $14,463,855. Any expected ROI above zero is worth the consideration of your CFO, but this one is a no-brainer!

As a reminder, make sure you are not just whimsically tossing out numbers; each figure should be based on a realistic prediction achieved by surveying the business. Also, make sure that there is a mechanism in place to measure the actual impacts. 

Monitor Actual ROI, Compare

As a Consultant, I like to stand up in the Project Scope presentation meetings and tell the executive team that they must hold me and themselves accountable to meet again 12 months after go-live to measure the actual ROI – and not just settle for a general feeling of the business impacts. A year goes by quickly, and most organization’s executives seem almost surprised when 10 months later I am asking to schedule the follow-up meeting. 

Measuring the actual ROI and comparing it to the predictions will bolster your credibility and help your cause the next time you want money for a project. 

So, track all the actual project costs, related changes in revenue, related changes in operational costs, risk factors and related losses suffered.

Survey the system users, their managers and other stakeholders for their general impressions of the project, the modernized system, how it has impacted their roles and how they believe it has impacted their business. Ideally, run the survey twice, maybe five months after go-live, and again at 10 months. Use different but equivalent question sets, and consider keeping the first survey anonymous to coax out the truth from those that may feel a conflict of interest otherwise. 

Knowing that the “day of reckoning” with the executives is coming, I find that everyone involved feels the pressure to do their part. To galvanize this feeling, I like to build the skeleton presentation before any of the business impacts can even be measured, and show it to managers and key users. I include their names in the presentation to highlight the fact that they will be highly visible to the executives, and that their role matters. Then I show the skeleton presentation to the CFO to get his feedback on what we plan to measure and report on:

• Reminder of original vision and key business objectives
• Status update – what was achieved, when, etc.
• Impact Assessment – business benefits realized, losses suffered, survey results, ROI achieved
• Call to action – what changes are recommended, how the executive team can assist, etc.

Ideally, your results will include charts like this:

And quotes like these:

“Customer Service is much improved due to easy accessibility to client data.” – F. Mohammed

“The system proved very impressive when a potential client visited recently. The prospect was most impressed with our degree of connectedness, and I myself was blown away” – D. Lodge

“Workflow is very efficient in times of urgency in my department” – K. Villafana

… all of which happen to be authentic.  

Of course, after legs grow weary of standing ovations and all backs have been thoroughly patted, it might be an opportune time to let the audience know that you have more cool new initiatives in mind.

Having been through this entire process more than once, I can tell you that there’s nothing more rewarding for a Systems Analyst / Project Manager like myself than presenting arm in arm with IT and Business Managers, following through on our commitment to the executives, and especially to the all-important CFO.

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.