Book 1: Prepare for Your Journey

Know your goals & chart a course

Sponsored by
Transforming IBM i Applications
Your Journey Beyond “Modernization”

Book 1: Prepare for Your Journey

Know your goals & chart a course

CONTENTS
Prepare for Your Journey 1
Sleepless in Seattle 4
Silver Bullets 5
Business Drivers 8
Other Technological Drivers 9
Guiding Principles 11
Application Assets 13
Enterprise Application Architecture 16
Conclusion 22
Looking Ahead to Books 2 and 3 23

 
Prepare for Your Journey
Know your goals & chart a course
It’s a wonder IBM i IT managers can sleep at night. To be sure,
the hardware and operating system provide legendary reliability
and virtually (pun intended)
painless transition of applications
to new generations of i hardware
and new operating system releases.

But when an IT manager surveys an

application portfolio that comprises
hundreds of thousands of lines of RPG,
CL and database access code (of various
generations and coding styles), a cold sweat
may break out as he or she contemplates the
following challenges:

IBM i Manager Challenges:

• How will the current applications’ cumbersome user interfaces, “silo” application structures and other
“legacy” design issues be refreshed and reengineered to meet our business unit’s and partner’s growing
expectations? We need to be delivering efficient, integrated capabilities, including workflow, rich media and
“anywhere/any device” access to business data and functionality.

• How will IT staff keep up with the skills and tools – old and new – required to deliver the level of application
innovation and agility demanded by enterprises in this tough, competitive global economy?

• How can these applications be rapidly deployed with equivalent functionality on both the IBM i and Windows
.NET if an enterprise merger or acquisition makes that necessary?

 1 
 2 
I’ll address all these elements in a three-part eBook -- a
trilogy. This installment looks closely at the challenges faced
by IBM i organizations and their IT managers, including
specific risks and opportunities. You’ll gain insight into how
major business and technological drivers are forcing many
IBM i organizations to transform their legacy applications
and development strategies to meet the expanding demands
of successful enterprises. I then lay out a path to finding
solutions, starting with a set of guiding principles you should
follow in determining the specific development strategy
that’s right for your organization. This book concludes by
explaining how IT organizations can use an enterprise
application architecture as the foundation for transforming
their IBM i applications and development methods.

In Books 2 and 3, I’ll describe how to create an

incremental transformation plan, with specific steps
to help ensure the plan is successful. The plan
covers getting the most value out of your legacy
applications, business sponsorship, maximizing your
current staff’s productivity, mitigating risk and other
important areas. To help you implement your plan, I
describe key technologies for supporting an
enterprise application architecture and making a
smooth transition from your current legacy code
and practices to a “new generation” of applications.
Complementing the advice on technology, I also
describe “best practices” to follow as you transform
your applications and adopt new development
strategies.

 3 
Sleepless in Seattle
There was a time, not that long ago, when no right-thinking organization that
ran on an AS/400 would even consider another platform for serious business
applications. In that AS/400 “golden era” there was also an abundant supply
of capable programmers who knew and loved RPG, CL and OS/400. In this
simpler IT world, the relative richness of 5250 display features seemed to
satisfy most end-users.

IT managers who experienced that period of AS/400 development know

the IBM i continues to be the most reliable, secure and manageable
enterprise application platform. But these exemplary capabilities
aren’t all that’s needed to meet contemporary business demands.

In today’s world, enterprises that fully exploit available technology have a

strategic advantage in their ability to reach and serve their customers and
trading partners, as well as reducing the cost of business. The following half-
dozen technological advances have been “game changers” for business IT:

• “Anywhere” communication via the Internet

• Universal adoption of graphical user interfaces as the standard for contemporary business applications
• Mobile devices that have rapidly claimed territory formerly the sole province of personal computers
• The availability of massive amounts of cheap data storage, making online access to documents, images and other rich media affordable
• Enormous server and client processing power
• New standards and ad hoc protocols for application interoperability

When you see what a company like Google has accomplished by pushing their use of these
capabilities to the limit, you realize other companies – possibly some of your competitors –
won’t be far behind. The potential for leveraging technology is enormous.

But for managers of IBM i shops the risk of being left behind is also obvious. Patching up old,
monolithic, RPG applications that have 5250 interfaces isn’t going to cut it, no matter how reliable,
secure, or easy to manage the IBM i can be. And the diminishing pool of skilled RPG developers makes
even holding your head above water a real challenge.
 4 
“Silver Bullets”
Facing these kinds of pressures, it’s not surprising that some
organizations have looked to a variety of “silver bullets” for their solution.

“Screen scraping”
In the early days of the Internet, it was understandable that the AS/400’s
lack of a native graphical user interface was seen as the fundamental problem,
and providing a Web browser interface as the complete solution. “Screen
scrapers” became the first “silver bullet,” and they did eventually deliver visually
attractive mappings of an application’s 5250 input and output to Web pages with
“clickable” entry fields and menus.

The problem with screen scraping was,

and is, that simply improving the appearance
of an application’s output and providing a few
shortcuts for user input doesn’t change the way
an application actually works. At the most basic level,
an application needs to be designed to fully exploit the
navigation, prompting, selection, early error-detection
and other capabilities of a browser or “rich client” interface.

But even more importantly, screen scraping doesn’t break down

application “silos,” provide useful access from mobile devices or
increase interoperability with trading partners. Changing the look of
the interface also does nothing to make applications easier to adapt to
new business requirements or re-deployable on a different server platform, if necessary.

“Rip-and-replace”
As new mobile devices, programming languages and interoperability protocols made the true power of the Internet more apparent,
IT organizations came to recognize the limitations of screen scraping. What seemed to be needed was a whole new way of creating
applications, and IBM and Microsoft were ready to offer their solutions to the problem – switch to Java or .NET.

 5 
Both the Java J2EE and the Windows .NET platforms, along with a bevy of supporting tools and utilities,
provide rich foundations for contemporary applications. And, of course, there are additional
alternatives (such as PHP) in what might loosely be considered the UNIX/Linux open source
world. While these platforms provide good underlying infrastructures for “greenfield”
development, they haven’t turned out to be the “modernization” solution that most
IBM i shops need.

While a few IBM i organizations have dabbled in Java, .NET, or PHP applications, to my
knowledge not many have voluntarily leapt entirely to any of these alternatives and left
behind their RPG. There have been a number of cases where an organization that formerly
relied on the IBM i has been absorbed in an acquisition or merger, and the organization has
been forced off the i entirely.

The essential problem with Java, .NET or any other “modern”

alternative is that most IBM i organizations can’t afford to toss
their enormous investment in RPG applications and recreate the
applications entirely from scratch. Regardless of the quality of your
legacy RPG portfolio, existing programs comprise a very detailed and
executable representation of thousands of business rules and operations.
Furthermore, your staff understands and can work with these descriptions.

Hypothetically, automated translation of RPG code to Java or C# might appear

to solve the problem by totally replacing the legacy code. Frankly, there aren’t
any products that can accomplish this in a way that produces an acceptable result. Even when a particular program
can be fully translated, what you end up with is the same legacy application in a language that’s unfamiliar to your
current developers and whose structure will look equally strange to programmers in the new language.

My experience consulting with IBM i development groups suggests that many developers find it difficult to gain mastery
of Java or .NET while still keeping their RPG skills sharply honed. A large part of the problem is that programming for J2EE
or .NET requires not only learning a new language, but also learning an enormous number of methods (i.e., procedures)
and programming techniques to implement basic user interactions, database access and business logic. Exploiting the full range
of Internet, mobile and interoperability capabilities requires even more extensive knowledge of complex J2EE or .NET frameworks.

 6 
Many IBM i organizations find themselves “stalled” in their development strategies because screen
scraping doesn’t address the big issues and a “rip and replace” switch from RPG to Java or .NET is
prohibitively expensive and risky. Meanwhile more RPG code keeps getting added to the
maintenance burden, and frustrated departments continue to implement their own
“skunk works” applications in .NET or PHP.

For an IBM i manager, the obstacles can seem insurmountable. But let’s take a
deep breath and tackle the problem by first understanding the business and
technological drivers, identifying key principles and objectives and looking
more closely at our application assets. Then we’ll be able to describe our
goals and execute a plan to reach them.

Purchased software packages

Faced with “stalled” progress for their IBM i applications, some enterprises purchase
software packages to completely replace one or more legacy applications. My advice
on this alternative is simple: If your enterprise can make a long-term business case for the
acquisition, maintenance and modification of a commercial application package, then that may
be a sound decision. However, purchasing an application package rarely, if ever, can be justified as
a “modernization” strategy, when you consider the business drivers and essential elements of “new
generation” applications, as I explain in the next two sections.

Many purchased packages themselves are largely “legacy”

applications that have the same disadvantages as home-grown
applications. And because their design is usually unfamiliar to an
enterprise’s in-house developers, initial customization and on-going
revision can be time-consuming and often requires relying on contract
consultants, which can increase costs and reduce agility.

In any case, as part of an evaluation of commercial software, your IT

organization should apply the principles and concepts described in this book.
Don’t be fooled by the disguise It would be counterproductive if your efforts to transform your IBM i applications
of purchased applications. produced even more legacy stuff to maintain, as a result of purchased packages.

 7 
Business Drivers
It’s no exaggeration to say the Internet and the huge increases in available
computing power have changed every dimension of business over the past
decade. The Internet makes possible a direct, rich relationship with almost
every customer and trading partner. In addition, the Internet creates a virtual
community in which all of an enterprise’s human and information assets can
be immediately accessible, on a controlled basis, to every employee, customer
and trading partner. Enterprises that have strong assets and know how to use
today’s technology to apply these assets to create better products and deliver
exceptional service will not only survive, they’ll thrive, even during stressful
economic periods such as we’re experiencing now.

Here are some of the ways leading businesses are using truly modern applications:

• Providing sales and service to customers any place, any time on any device
• Helping customers quickly determine their needs and then find high-value solutions through sophisticated Web sites and portals
• Attracting new customers through non-traditional channels, such as social and professional networking sites
• Increasing employee productivity and quality of service through workflow automation
• Integrating documents, images and voice with transactional data to improve the quality of business decisions and service
• Reducing cost of materials by broadening the pool of suppliers and creating faster and less expensive systems for supply chain
ordering and fulfillment
• Integrating product and service offerings more closely with complementary products and services from business partners

There are other important business drivers, as well. The global economy requires being open for business 24x7 with localized applications
dealing in multiple currencies. Industry consolidation through acquisitions and mergers often requires support for running applications on
Microsoft Windows or other platforms in addition to, or in place of, the IBM i. And difficult economic conditions place a premium on
minimizing risk – a failed initiative that 10 years ago would be a temporary setback can sink an enterprise today.

In general, IT organizations are being put between the hammer and anvil, with enterprises looking for more IT capabilities and greater agility,
while keeping costs and risk low. As a result, IT managers are expected to preserve the value of current assets while making steady, incremental
improvements in productivity and better aligning applications with business strategies.

 8 
Other Technological Drivers
I’ve already mentioned the game-changing aspects of the Internet
and increased computing power. The blistering evolutionary pace of
several pivotal technologies is expanding the reach and capability of
today’s applications. Among the most important trends are the
following:

• Rich, Web-based user interfaces, such as those found in

Ajax, “Web 2.0” and Microsoft’s Silverlight
• The explosion of handheld and other unique devices with
substantial on-board processing power and native applications
• Service Oriented Architecture (SOA) for application
interoperability across languages, platforms and enterprises
• Software as a Service (SaaS) and “Cloud computing”
• “On-demand” information and processing services
• Application integration with social networks, such as
Facebook and Twitter

What’s common to these and other current technologies is how

rapidly the technologies change or new technologies displace older
ones altogether. “Cloud computing,” SaaS and “on-demand” services
are good examples of this phenomenon. Cloud computing provides
dynamically-scalable, “virtualized” computing resources accessed via
the Internet. SaaS essentially provides applications in the “cloud,” i.e.,
accessed by the Internet, rather than hosted on the enterprise’s own
servers. In both cases, the resource or service is provided “on
demand,” or as needed. On-demand information and services applies
both to third-party providers and to services available on the
enterprise’s own servers.

 9 
All three of these trends increase the need for, and technical complexity
of, integrating applications that are running in different locations – i.e., in
the “cloud,” on the enterprise’s servers and on personal computers and
mobile clients – and which are not always connected to one another.
One of the most challenging aspects of the continuing evolution of
such distributed computing is keeping data and workflow processes
synchronized across platforms and applications.

While one result of this fast pace is constant improvements in features

and performance, the resulting instability makes it difficult for an IT
manager to pick specific technological targets for development
strategies. In addition, this instability inherently amplifies the risks of
development by directly coding to J2EE or .NET frameworks because the
platforms are constantly changing underneath developers. The issue isn’t
so much that code written to older framework versions won’t continue
to run. The risk is that a large amount of code will be hand-written using
a J2EE or .NET framework version that gets supplanted by something
newer. Ultimately, the long-term result can be another huge mound of
outdated code to maintain – even if it is a “modern” language like Java
or C#.

The recent acceleration in the rate of technological change is likely to

continue. This exacerbates IBM i organizations’ dilemma because at the
same time they’re under tremendous pressure to deliver a whole new
class of applications, implementing these “new generation” applications
must necessarily rest on a shifting foundation of technologies.
Furthermore, enterprises expect this transformation to be done quickly,
but without incurring excessive risk and by extracting as much value as
possible from legacy applications. In these circumstances, what many IT
managers are looking for is an application strategy that insulates their
developers from platform specifics and constant changes to
infrastructure interfaces.

 10 
Guiding Principles
That’s quite a challenge. Before I dive into a strategy to meet that challenge, let’s
enumerate some guiding principles. Most importantly, the solution must be
business-driven. This means you don’t focus solely on the technical dimensions
of platforms, languages, or other technology.
What it does mean is that you create a
strategy that will efficiently deliver the
right information and capabilities to
the right people at the right time, Guiding Principles for a
as determined by changing business needs Transformation Plan
and initiatives. This core principle implies
applications will also provide highly
functional user interfaces and pervasive • Business-driven solutions that
integration with other applications, deliver the right information and
including within business process
capabilities to the right people at
workflows.
the right time
A business-driven strategy must also minimize risks, among which • Minimize risks from inflexible
the most serious risks to avoid are: applications that are too hard to
adapt to changing demands
• Failure or delay in adapting applications to capitalize on time-critical • Capitalize as much as possible on
business opportunities or to respond to competitive initiatives
current application assets
• Inability to meet trading partners’ interoperability requirements
• Inability to deliver applications on a new platform, such as .NET, • Deliver more than just a graphical
should this become essential due to an acquisition, merger, or user interface
other business requirement • Agility, productivity and reliability
are the hallmarks of “new
As mentioned earlier, another fundamental principle for most generation” applications
IBM i organizations is to capitalize as much as possible on
current application assets, both as executable code and as
a fine-grained definition of business rules and processes.

 11 
From a technical perspective, the strategy must go beyond “modernization” of just the user interface.
While graphical interfaces are clearly a requisite element of a “modern” application, the real
hallmarks of “new generation” applications are agility, reliability and productivity. Agility
provides the ability to meet rapidly changing business and/or technological demands, and
productivity means you can deliver more capability with better quality and at less cost
than you did with previous approaches to legacy applications. Very high reliability is
essential to achieving agility and productivity. You simply cannot keep up with the
pace of change if your organization is constantly diverted into repairing
malfunctioning or deficient applications.

Figure 1 provides a list of specific technical capabilities that “next generation” applications
should support. You can see how each of these elements can play an essential role in delivering
the right capabilities wherever and whenever they’re needed.

Figure 1: Essential technical elements of “New Generation” applications

 12 
Application Assets
As I’ve already mentioned, many enterprises have large amounts of legacy code
constituting substantial enterprise assets. While legacy applications may have
outdated user interfaces, lack support for current technologies such as mobile
devices, and be limited to their own “silos,” nevertheless, the code contains
potentially thousands of very precisely defined rules about the enterprise’s
structure and processes. The challenge, of course, is to extract this embedded
knowledge, a hurdle I’ll address below.

Importantly (and obviously), legacy code models business

structures and processes in an executable form.
Consequently, even if some of this knowledge about the
enterprise remains “hidden” from plain view because of
poorly written code, the functionality is still there to be
exploited – if there’s a way for new applications to coexist,
and even interoperate, with legacy applications.

Legacy code comprises several types of artifacts. Most

obviously, there are typically many large, monolithic
programs that include code for business logic, database
access and 5250 display I/O. In some cases, these programs
will have parameters, which provide flexibility in the
programs’ use. Large RPG programs are usually organized as
a number of subroutines (without parameters or local
variables) that access global variables and interleave logic,
file I/O and display I/O. Less frequently, ILE RPG programs
may be structured as a hierarchy of procedures which have parameters, use
local variables and factor out code used for different aspects (e.g., database I/O)
of the application.

 13 
Exploiting legacy programs requires some means to execute selected parts of the
code as if via a procedure call, even if the desired code isn’t isolated in a
procedure with suitable parameters. As a simple example, let’s consider a pricing
function, which involves business rules and accessing item- and customer-specific
information from a database. When this code is cleanly encapsulated in an ILE
procedure, the only requirement for new applications is that they be able to make
an ILE procedure call, either directly or through an intermediate mechanism, such
as invoking a service.

When the code to determine an item’s price is intertwined

within a monolithic, interactive program, however, a
different approach is required. In many cases, a subset of
the 5250 display input fields are the means by which input
arguments to the pricing function are supplied and an
output field on a subsequent screen returns the pricing
function result. By “wrappering” such an application with
code that intercepts and controls the 5250 data stream,
it’s possible to create an appropriately parameterized
procedure or service that is in turn callable by other
programs. This technique is not only feasible, it’s already
available in some third-party development tools for the
IBM i.

Legacy menu programs, typically organized in a hierarchy of menus and submenus,

are also common IBM i application artifacts that provide fairly comprehensive,
although cumbersome, navigation among and within applications. Using a
wrappering technique similar to the one just described, complex paths through
multiple menu programs can be reduced to a single operation via a callable
“navigation” procedure. By utilizing both wrappered functions and wrappered
navigation, new applications can be composed from a combination of old and new
code. The key here, of course, is using a development and runtime framework that
supports this form of wrappering and composition.

 14 
 Conceptually, you can think of the approach I’ve just
described as having a “virtual user” behind the scenes who
receives requests for some function or operation and uses
the information in the request to navigate legacy
applications and enter appropriate data. When the legacy
application displays its results, the “virtual user” returns
just the requested information in the format that was
requested. Such a “virtual user” provides potential access
to every function and operation implemented in interactive
legacy applications.

And, of course, we shouldn’t overlook the short-term

potential for “screen scraping” 5250 display files to “reface”
an application. Refacing block text and function key screens
to provide a WIMP (windows, icons, menus, pointer)
interface can provide legacy applications with an
appearance similar to new applications and potentially a
more convenient way for the end user to interact with screens. As I’ve explained,
this technique isn’t a solution to transforming applications, but it can serve as an
interim step, especially for less important parts of your business applications.

Legacy source code is also written in a form that current staff can comprehend. As
an enterprise transforms its applications, developers responsible for creating the
“new generation” applications must understand the applications’ functional
requirements in order to create and maintain them. This is true no matter which
new languages or tools are used. Exploiting the descriptive value of legacy
applications, however, depends on being able to interpret the code as a
“specification.” Thus, realizing the full value of legacy code depends in large part on
a transformational strategy that uses current development staff to the best
advantage – a point I’ll return to shortly.

 15 
Enterprise Application Architecture
Keeping business and technology drivers, our guiding principles and the value and characteristics of legacy applications in mind, the first step
in an effective transformational strategy is to identify an enterprise application architecture (or just application architecture, for short). An
application architecture lays the necessary foundation for pervasive agility, productivity and reliability in application delivery and deployment.
An 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.1

A sound enterprise application architecture can take many specific forms, but there
are eight “pillars” that should always be in place. The architecture should:

#1 – Be based on a #5 – Support multiple

framework platforms
#2 – Provide an
#6 – Support multiple
application
application
repository
interfaces
#3 – Provide automation
#7 – Integrate legacy
and developer
applications
guidance
#4 – Be based on a #8 – Manage
Service Oriented application
Architecture evolution

1 This section is excerpted and condensed from my previous whitepaper, The Eight Pillars of an Enterprise Application Architecture. The full whitepaper provides an
in-depth discussion of application architectures and provides advice on how to establish an application architecture in your own organization.

 16 
Pillar #1 – Is Based on a Framework
A software framework is a collection of reusable artifacts that cooperate to implement the design inherent in an application architecture.
While the definition of an application architecture itself is abstract, the corresponding framework is concrete, enforces standards and
comprises such elements as executable runtime routines, procedure libraries, source code segments and higher-order (aka “4GL”) languages
and associated code generators.

The essential point here is that to derive actual benefits from an application architecture, a framework must provide most of the code for
applications that conform to the architecture.

Pillar #2 – 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.

Pillar #3 – Provides Automation and Developer Guidance

An effective application architecture must be designed to enable a high degree of computer-
assisted guidance and automation for developers. Along with a framework and repository, a
high-degree of automation and guidance delivers the practical benefits of an architecture-
driven approach.

Guidance includes a consistent and flexible set of steps to define an application using the items from the repository and supported by the
framework. Thus, developers can take advantage of the architecture without having to master all the architecture’s details. The heart of
automation is code generation for both the “plumbing” and “glue” code that often constitutes the bulk of an application’s source code, but
adds little or no business value to the application itself. With automated tools, developers can select from templates and repository items and
define much of an application by specifying options for code generation. The developers can then concentrate most of their efforts on the
unique parts of an application that provide business benefit and use the higher-order language of the framework to implement these parts
without having to write the plumbing code.

 17 
Pillar #4 – Is Based on a Service Oriented Architecture
Basically, a Service Oriented Architecture (SOA) uses a modular structure in which a service is implemented as a chunk of code that returns a
result or causes some side-effect. For example, a service might calculate and return a credit rating for an individual, reserve an airplane seat,
send an email message, or start a piece of equipment.

At the implementation level, a service is fundamentally a more flexible procedure or method — an invocable chunk of code that has a name
and, optionally, parameters and local variables, and that returns a value or produces a side-effect. What distinguishes services is that an
application can invoke a service locally or remotely via an invocation protocol that isn’t tied to any language, operating system, or proprietary
Web application platform. For example, using the Web service protocol, a C# application running in a .NET environment can invoke a service
implemented in ILE RPG running under the IBM i operating system.

Among the benefits of SOA is a protocol for providing or consuming services from other enterprises, either trading partners or service
providers. An SOA architecture is also almost essential for incorporating application functions into an automated workflow environment. A
particular value to IBM i organizations is that SOA and supporting tools provide
a powerful way to integrate legacy functions into a modern application
strategy; in effect, greatly expanding upon the application interoperability
provided by ILE.

Pillar #5 – Supports Multiple Platforms

In the contemporary, global business environment, it’s almost impossible
to guarantee that IT will have to support only one platform, such as the
IBM i, for the indefinite future. Mergers and acquisitions, off-the-shelf
applications that require a specific platform and unforeseeable changes in
the products and support offered by system vendors require that
applications can be deployed on multiple platforms or moved from one
system to another.

 18 
Pillar #6 – Supports Multiple Application Interfaces
The people that participate in an enterprise’s business processes have varied application interface requirements. Heads-down data entry in a
local office is much different than mobile access by a sales representative at a customer site. Shop floor workers often need specialized
devices and manufacturing and other equipment itself requires an entirely different set of application interfaces. Customers purchasing from
the enterprise’s Web site want an easy-to-use browser interface; while enterprise managers and analysts need a powerful rich client.

An application architecture must address multiple application interfaces in two main ways. First, it must structure applications so that
business logic, data access and application interfaces are separated. Second, it provides the framework, repository capabilities and tooling to
support a wide range of specific devices and protocols. The ultimate goal is that
applications’ capabilities can be easily exploited through any number of alternative
interfaces, including user interfaces and SOA application interfaces.

Pillar #7 – Integrates Legacy Applications

As a practical matter, a critical part of most application architectures suitable for
IBM i organizations is the ability to integrate legacy applications seamlessly into
a suite of new and legacy applications.

A general approach is to embed legacy applications under a contemporary

navigation structure (e.g., various forms of “explorer” navigation panes) thus
replacing cumbersome legacy application menu hierarchies. This concept can be
expanded by mapping sequences of multiple user actions and, optionally, application responses in the legacy applications to one-click
selections in the architecture’s navigation and application structure. Depending on the legacy applications’ structure and user interfaces, this
type of integration can provide end users with substantial consistency and ease of navigation among new and legacy functions.

Deeper integration can be achieved by exploiting a Service Oriented Architecture using the “wrappering” technique described earlier. This
non-invasive approach doesn’t require modifying existing application code. A more fine-grained alternative is to selectively refactor existing
legacy code into procedures and wrapper these procedures with code that makes them available as services.

Working in the other direction, a legacy application that’s embedded in the architecture’s navigation structure can be extended by adding calls
to services implemented either as new code or as legacy code that’s been adapted as described above.

 19 
Pillar #8 – Manages Application Evolution
The final pillar of an application architecture is a viable means to manage the evolution of applications so at the end of the next 10 years of
development, the IT organization doesn’t find itself faced with another portfolio of outdated applications that need another round of
“modernization.”

There are several keys to this capability. Previously described pillars – framework-based, an application repository and automation and
guidance – provide isolation from underlying technology by supporting a model-centric, rather than language- or technology-centric approach
to defining applications. Another pillar – Service Oriented Architecture – ensures that even code that may not conform internally to a future
version of the application architecture can still interoperate because the SOA invocation
protocols are specifically intended to provide language and platform independence. It’s
conceivable, of course, that the SOA invocation protocols themselves may evolve, which
would require changes to the services wrapper code. This code, however, should be part
of the framework and/or generated code and be updated automatically.

A good test of an architecture’s ability to manage evolution of underlying technology is

the degree of support for dissimilar target systems. If the architecture is flexible enough
to encompass applications that run on IBM i and Windows .NET, for example, the
architecture is likely to be capable of encompassing applications that run on different
versions of supported operating systems, Web application servers, or databases.

On paper, an enterprise application architecture describes both a more agile, productive

and reliable way to develop and evolve new applications and a way to incorporate legacy
applications into a consistent, new interface, including user navigation and workflow. Of
particular importance to many IBM i organizations, pillar #5 can enable a unified IBM i and
Microsoft .NET application strategy.

Turning this vision into reality, however, takes time, careful planning and appropriate tools. Figure 2 provides a high-level summary of the
recommended steps to establish an enterprise application architecture. The Eight Pillars of an Enterprise Application Architecture whitepaper,
referenced earlier, covers these steps in more detail.

 20 
Figure 2. Key steps to establish an enterprise application architecture

Describe current IT practices and tools Implement or acquire and deploy the Embed legacy applications, extend
for delivering and supporting framework, repository and automation selected applications and begin
applications. tools in a production environment. developing new applications.
  

Use the architecture (and tooling) as the

Identify the enterprise’s business Refactor selected legacy foundation for new applications, as well
objectives for software applications. applications. as incrementally transitioning legacy
applications.
  

List and describe the critical

Plan how to handle legacy
requirements for your enterprise
applications.
application architecture.
 

Make a key decision: Do you design and

Evaluate how, and how well, your implement your own architecture, or do
current practices and tools address the you acquire the core of your
requirements. architecture from other providers?
 

 21 
Conclusion
For most enterprises with a large portfolio of IBM i legacy
applications, transforming these applications is a matter of
“when” and “how,” not “whether.” The task may at first seem
too large and complex to accomplish, especially without
considerable expense and risk.

But as I’ve tried to lay out in this book, there are sound ways to
approach the problem. The most pivotal step is to consistently
follow a business-driven strategy. This involves understanding
what drives the need to transform your IBM i applications, both
from your own enterprise’s business requirements and the
dramatically changed technological landscape upon which your
enterprise – and its competitors and partners – conduct
business.

To lay the foundation for transforming your applications,

this book describes “core” principles to guide your
planning and execution: implementing business-driven
solutions, minimizing risk, capitalizing on your current
assets and establishing an agile, reliable and productive
application development capacity.

As I laid out at the beginning, 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 described the eight pillars upon which any
application architecture should rest. The next two books
in this series will build on these foundations to complete
the picture.

 22 
Looking Ahead to Books 2 and 3
Be a Savvy Traveler is the next book in this series
and lays out the steps to create an incremental
transformation plan. The ultimate transformation
goal is far reaching – to implement a
comprehensive enterprise application architecture
encompassing all your legacy and new applications.
But the goal should be reached through a series of
non-disruptive steps where each step produces
immediate returns and minimizes risk. This
upcoming book dives deeply into a variety of ways
your enterprise can reuse, recycle and reengineer
legacy applications. I also cover an approach that
puts your current IBM i development staff in the
right position to create success (Hint: This doesn’t
require turning them into Java programmers.) Book
2 also provides advice on minimizing risk and other
aspects of a sound plan.

The third book, Embark with Confidence, completes the trilogy by looking at specific technologies and 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. The final book takes a close look at
application generators as a potential tool, and provides a set of scenarios and a specific sequence of decisions an IT
organization can work through to assess the level of risk in using an application generator. Embark with Confidence also
presents a list of criteria to evaluate contemporary application generator products. This book concludes the series by
enumerating a set of “best practices” for a successful transition process.

After reading the entire series, you’ll be prepared to help your IT organization put a transformation plan in place and begin to
experience your first successes. Not only will this deliver the level of IT capability your enterprise needs; you’ll also reap
another benefit – the ability to sleep without worrying about the IBM i’s future.

 23