White paper DevOps for IBM i

DevOps Transformation:
Engage your IBM i
teams

Arcad
software
www.arcadsoftware.com
White paper DevOps for IBM i
EXECUTIVE SUMMARY
Most enterprises accept the imperative to tran-
sition away from legacy waterfall-based de-
velopment models and to DevOps in order to
maintain their business competitiveness. There
exists however, a widening performance gap
between those stuck in the middle stages of
DevOps maturity and those who have been
able to achieve scale.
The IBM i has a unique architecture which is
ideal for mission critical business applications
and it has become a modern platform howe-
ver some barriers exist to DevOps maturity.
Barriers include: The difficulty to modernize
complex applications; breaking away from
silos and bimodal practices; onboarding new
talent; retaining mature IBM i talent; eliminating
the business risk of loosely coupled, non-inte-
grated DevOps tools; eliminating lengthy, late
or truncated test cycles and finding ways to
take advantage of new opportunities in cloud
computing.
This paper is intended for those who influence
IBM i DevOps maturity and success in the en-
terprise. It gives an update on the key factors
affecting DevOps maturity from an IBM i pers-
pective. It describes the barriers to DevOps
maturity and how ARCAD tools can be used to
help you eliminate them.
'By 2020 50% of CIOs who have not
transformed their capabilities to
DevOps will be replaced from the
digital leadership team’
- Gartner Research 2019
Page 2 • Arcad Software, January 2020 - www.arcadsoftware.com
A UNIQUE ARCHITECTURE
The IBM i platform (previously known as
System i, eServer iSeries, AS/400) was the
first minicomputer platform to integrate the
database, security and operating system into
one. It remains the only commercial computer
platform ever to use a machine interface
architecture to isolate applications and most
of the operating system from the hardware. It
is also the first general business platform ever to
achieve an NSA C2(¹) security rating. Originally,
users would access the platform via a bloc-
oriented terminal named 5250. The original
model had green characters on a black screen
hence the term green screen 5250. Many IBM
i power users still prefer this interface because
despite its apparent old appearance it is fast,
flexible and familiar.
This unique architecture has provided an
unprecedented protection of investment in
business applications because users are not
forced to change code to take advantage
of faster newer hardware. The power of IBM
hardware has grown exponentially and is
now able to support near mainframe class
workloads. For more than 30 years, IBM i has
been used by organizations in every industry
from entertainment to retail, manufacturing
to financial services, nonprofits to worldwide
distribution. Today, these enterprises continue
to trust IBM i to run their most critical business
applications and provide security for their most
sensitive data.
The IBM i platform also has an unsurpassed
reputation for longevity, reliability, availability
and security at a TCO lower than Windows or
Linux.
‘92% of respondents believe that
their IBM i server gives them a better
ROI than other servers’
- IBM i Marketplace Survey, Help Systems, 2019
(1) The C2 security rating was established by the U.S. National
Computer Security Center (NCSC) and means that the
computer’s security framework is suitable for use in government
and military organizations and institutes to process confidential
government and military information.

A FULLY MODERN PLATFORM
A modern IBM i can take full advantage of
IBM’s Power Systems server family hardware
which is highly scalable, reliable and available
and which runs different operating systems
(IBM i, AIX, Linux) simultaneously in different
partitions on the same server. IBM has never
stopped innovating and is predicting a tenfold
increase in performance of POWER processors
in the next five years.
The IBM i has many ways to communicate
and exchange data with other platforms and
in addition to the more traditional languages
such as COBOL, RPG and PL/I, the IBM i also
supports numerous modern development lan-
guages such as C, C++ , Java, PHP, SQL, Ruby,
JS, Node.js, GNU C, … and Free-Form RPG, a
highly efficient business oriented language
with a syntax resembling Java. A modern IBM i
supports open source development tools such
as Apache and Python, GNU libraries and mo-
dern DevOps tools such as Git, Jenkins and Jira.
It has become a fully modern platform.
'IBM has never stopped innovating,
today the IBM i is a fully modern
platform’
- Philippe Magne, Arcad Software 2020
TRUSTED WITH MISSION
CRITICAL BUSINESS
APPLICATIONS
Important parts of the business run on IBM i.
IBM i software applications were developed
mostly in an innovative and efficient way for
their day and they have had unprecedented
longevity, running well, without modification
for decades. IBM i software applications have
inherited hardware and OS improvements over
the years without the need for major code
Arcad Software, January 2020- www.arcadsoftware.com • page 3
White paper DevOps for IBM i
change. Most run faster, are more robust,
secure, scalable and available than ever.
Mission critical functions of a business tend
to remain stable so there has so far been less
business justification for major change.
‘43% of core business applications
run on IBM i’
- IBM i Marketplace Survey, Help Systems, 2019
Many mission critical applications have
been modernized(¹). To keep mission critical
IBM i software applications relevant many
have been modernized and integrated with
applications on other platforms. Banks for
example often use IBM i for secure and robust
back office processing while opting for more
contemporary Linux or Windows based front
end to interface with staff and on-line or mobile
users.
‘65% of respondents have moved
their IBM i interface toward a more
modern option, 35% report using the
5250 green screen interface only’
- IBM i Marketplace Survey, Help Systems, 2019
(1) Modernization refers to the conversion, rewriting or porting
of legacy applications to a modern computer programming
language (e.g from fixed format RPG to free form RPG) and
all associated objects and protocols. Also to modernize the
development methods associated with maintaining the
application (e.g. from a waterfall model to a DevOps model).
Legacy transformation aims to retain and extend the value of
the legacy investment.
White paper DevOps for IBM i

'Most enterprises already know the

limitations of traditional waterfall
TRADITIONAL DEVELOPMENT based development models but the
METHODS REQUIRE challenge now is to move all IBM i
development to DevOps in a safe,
ADAPTATION non disruptive way’
- Philippe Magne, Arcad Software 2020
It is widely accepted that the traditional wa-
terfall development model used for decades
with the premise that one should move to the
next phase only when the preceding phase
is reviewed and verified is ill-adapted for the
demands of the modern digital era. There is
a major potential to optimize existing develop- DEVOPS IS BECOMING A KEY
ment models to improve speed, time to mar-
ket and quality levels while eliminating the fol- PART OF DIGITAL
lowing risks: TRANSFORMATION
Costly There is a significant time lag for new
The modern digital era Most businesses must
ideas to be deployed to production which of-
offer better on-line services and goods at lower
ten means development budgets get consu-
costs and greater velocity than competitors to
med delivering features which are no longer
remain viable. Virtually every successful bu-
needed.
siness now looks to software to drive revenue
and reduce costs.
Time-consuming Developers tend to put in
place the structure of software first and only se-
Every company is a software company En-
cond consider implementing customer ideas.
terprises of all industry sectors are continuously
This can create significant unproductive delays
improving their software to gain competitive
and compromises.
advantage. In addition to application functio-
nality, one of the major criteria when selecting
Inflexible Traditional development methods
software today is the speed at which a new
can be rigid to change. Customers change
feature or function is made available. It is the-
their requirements often because the business
refore now vital to pay attention to both func-
changes often. This can mean resistance to
tion and process to avoid falling behind.
change from development followed by much
extra effort and delay.
Risk mitigation Downtime is now one of the
biggest threats to the bottom line and much of
Inefficient At each step of the traditional pro-
it is caused by faulty software releases. Large
cess rigorous approvals are needed, leading to
traditional releases are more likely to introduce
bottlenecks in the delivery process. Indeed this
faults which increase downtime. Downtime
kind of “synchronous” approach is at odds with
costs businesses real money through SLA pe-
the asynchronous needs of today (an analogy
nalties, loss of business and reputation.
would be our reliance on text messages as op-
posed to phone calls). Having a fixed series of
DevOps helps enterprises stay ahead A De-
approval gateways can lead to project delays
vOps strategy results in faster incremental im-
on top of management delays, compromising
provements which bolster the bottom line fas-
delivery speed.
ter and better than a traditional all at once
approach. By always staying those few steps
Lacking transparency Managers of traditional
ahead of competitors we can deliver a real
development projects get inundated with sta-
differentiator and ensure competitive advan-
tus reports about improvements but nothing to
tage.
track business productivity. This means they be-
come ineffective at keeping score.

Page 4 • Arcad Software, January 2020 - www.arcadsoftware.com


‘It’s no longer about if organizations
should adopt DevOps, it’s now about
getting DevOps right and scaling it
across the enterprise’
- IDC, 2020
IDC identifies a prime software industry
challenge for 2020 as “getting DevOps right
and scaling it across the enterprise”. Indeed,
many organizations are looking for world class
tooling to ensure they both deliver DevOps ef-
ficiently across ALL areas of the organization
and at the same time scaling their work across
the enterprise without impacting the business.
World class DevOps tools offer a framework to
deliver the most “rapid wins” while eliminating
the risk of poorly scaled and loosely coupled
alternatives.
Arcad Software, January 2020- www.arcadsoftware.com • page 5
White paper DevOps for IBM i
.
DEVOPS MATURITY IS
INFLUENCED BY YOUR IT
MATURITY
All information technology goes through stages
of maturity so it’s important to recognize which
stage you are at now in order to understand
and plan for what’s next. The levels of IT
maturity have an impact on how mature
DevOps can get in your organization. Though
DevOps adoption does in no way depend
on cloud technology, physical servers and in-
house data centers can slow DevOps progress.
However, a reliance on monolithic programs is
a significant hindrance.
IT Maturity Map (source: IBM Corporation)
White paper DevOps for IBM i

Stage 5 - DevTestOps is a role which promotes

testing and ensures it start earlier in the pro-
ject lifecycle, is continuous and is embedded
DEVELOPMENT PROCESS in every phase of the life cycle. The term “shift
EVOLUTION FOR THE IBM I left” is sometimes used to highlight that testing
must be prioritized as early as possible in the
(“A HISTORY LESSON”) development cycle to be more effective in
detecting defects as they arise.
Stage 1 - Waterfall is a very structured and ri-
gid development approach which much le-
gacy development still follows. This approach
generally results in large releases every few
years. Business change has accelerated in
the modern digital era and therefore some of
the delivered features arrive too late or are not
aligned with customer needs.

Stage 2 - Agile - is an iterative development

approach which emphasizes rapid delivery
and includes customers in the development
team.
ARCAD solutions for end-to-end DevTestOps automation share
Stage 3 - CI/CD is continuous integration and a central metadata repository core, to optimize Continuous
continuous delivery which is the practice of Integration (CI), Continuous Test (CT) and Continuous Delivery
(CD) on IBM i
merging all developers working source code
copies to a shared mainline several times a
day and delivering software in short cycles. Stage 6 - DevSecOps is a role which aims to
CI/CD helps reduce the cost, time, and risk of embed security in every part of the develop-
delivering changes because it allows small but ment process rather than stitching it on at the
frequent updates to production applications. end. The DevSecOps promotes a team culture
where everyone feels responsible for security.
Stage 4 - DevOps builds on agile and brings They work continuously to improve security au-
developers and operators and customers tomation at every stage of development.
together through automated tools and pro-
cesses. The increased automation and col-
laboration improves productivity and there is
less team friction resulting in faster and higher
quality software delivery.

From Agile to DevOps: Business and IT agility drive innovation and maturity

Page 6 • Arcad Software, January 2020 - www.arcadsoftware.com

 White paper DevOps for IBM i

Stage 3 – Containers are a form of operating

system virtualization but unlike virtual servers,
several containers can share the same opera-
ting system instance. Containers allow appli-
APPLICATION ARCHITECTURE cations to be more rapidly tested, deployed,
patched and scaled. It is known that applica-
Stage 1 - Monolithic or single-tier are programs tions in containers will run in a similar environ-
where multiple business functions were built ment regardless of where they are deployed.
into a large single program. Historically this
approach was used because it was simpler to
develop, test and deploy at the beginning of
a project. Eventually as many changes were
made the programs became so large and
complex that they were too expensive, time APPLICATION
consuming and risky to change further. INFRASTRUCTURE
Stage 2 - Multitier breaks up monolithic pro-
Stage 1 – Data centers are spaces to house
grams into multiple smaller programs called
physical computer systems and components,
components. The components are grouped
generally in-house. A disadvantage to the en-
into tiers or layers. Layers include: presenta-
terprise of having its own data centres is that all
tion layer, application layer, business layer and
aspects of infrastructure provisioning and data
data access layer. Components are reusable
center management fall to in-house staff as do
in that they can be used many times by diffe-
construction and running costs.
rent components generally in the layer above.
Stage 2 – Hosted data centres are physically
Stage 3 - Microservices break application
located on an external service provider’s in-
components into even smaller single functio-
frastructure. The enterprise requires fewer staff
nal units called services. Applications are now
and less physical infrastructure. There is more
becoming suites of independently deployable
flexibility because the external service provider
single purpose services. Applications built with
can increase or reduce capacity as business
microservices are generally faster to build and
needs change and has the technical staff to
change, more scalable, portable and resilient
ensure the systems run well.
to changes and faults than multitier.
Stage 3 – Cloud computing services are a sub-
set and an extension of hosted services in that
instead of being based on a physical hosted
server, they are based in a shared virtual en-
DEPLOYMENT & PACKAGING vironment managed by a cloud-hosting provi-
der. Cloud servers are a good fit for enterprises
with variable demands and workloads and of-
Stage 1 – Physical servers are also called fer on-demand utilities, multi-tenancy features
single-tenant or bare metal servers. These are and uninterrupted scaling.
computer servers which include memory, pro-
cessor, network connection, hard drive and
operating system for running applications.

Stage 2 – Virtual servers are also called mul-

ti-tenant servers and are software-based envi-
ronments which emulate the process of multi-
ple physical servers on a single physical server.
Each virtual server has its own operating system,
processor, memory and storage resources. Vir-
tual servers are easier to manage and more
cost effective than physical servers.

Arcad Software, January 2020- www.arcadsoftware.com • page 7

White paper DevOps for IBM i

DevOps performers, up from 7% a

year ago’
- 2019 State of DevOps Report , DORA
DEVOPS MATURITY
LEVELS REMAIN STUCK IN THE
MIDDLE ‘79% of firms surveyed were
characterized as medium on the
Any new technology, methodology, process or DevOps evolutionary scale, the
paradigm shift including DevOps goes through same as last year’
stages of maturity. Some well publicized ear-
- 2019 State of DevOps Report, Puppet, CircleCI &
ly DevOps adopters like Amazon, Netflix, Tar-
get, Walmart, Nordstrom and Facebook have Splunk
reached optimized maturity levels but most or-
ganizations are still in the early or middle stage
and looking for a way forward. The stages of ‘60% of European organizations now
DevOps maturity are:
utilize DevOps, however there is a
1.Initial Processes are usually ad-hoc and di- widening performance gap between
sordered. Outcomes are unpredictable, often those “stuck” in the experimentation
exceeding allocated budget and timelines. stage and those who have been
During times of crisis, there is a tendency to
abandon process and it’s impossible to repeat able to achieve scale’
success. - IDC, 2019

2. Defined Processes are defined but not stan-

dardized across projects or even across diffe-
rent lifecycle stages of the same project. The
standards, process descriptions and proce- BARRIERS TO DEVOPS
dures can vary considerably from team to MATURITY ON IBM i
team.
The barrier of non-modernized applications
3. Managed Processes are well characterized
Non modernized applications cannot easily
and standardized across all projects. Standard
take advantage of new IBM i features or mo-
processes are used to establish consistency
dern development methods. Modernization is
throughout the organization. Projects esta-
typically a prerequisite for applications transi-
blish their specialized processes by modifying
tioning to DevOps. Modernization also impro-
the standard processes to fit needs and re-
ves ROI, mitigates risks, improves security, im-
quirements, while still keeping to the standard
proves the user experience and enables the
frameworks defined by the organization.
adoption of cloud computing.
4. Measured Process quality and performance
Many non-modernized IBM i applications re-
are measured to achieve visibility and pre-
main so because they suffer from a high level
dictability. Process performance is controlled
of technical debt(¹) which has been difficult to
using statistical and other measurable tech-
analyze and quantify. The worst scenarios are
niques, and predictions are based on reliable
un-managed applications with missing or miss-
data analytics.
matched source code and these pose the hi-
ghest risks when attempting a change.
5. Optimized Continuous assessments of the
overall process leads to achieving business ob-
Some IBM i developers have worked with the
jectives with minimal risk and cost.
platform for decades and have built up va-
luable knowledge which is difficult to share be-
'Only 20% of respondents consider cause it is not documented. In the past deve-
their organizations to be ‘Elite’ lopers were forced to come up with complex
Page 8 • Arcad Software, January 2020 - www.arcadsoftware.com

or unorthodox solutions to the most pressing
problems “on the fly” and the production of
technical documentation would have limited
the speed of development and innovation.
‘We rarely find complete
documentation for a legacy
application making it nearly
impossible to modernize or restructure
without automating the application
analysis process’
- Philippe Magne, Arcad Software 2019
(1) Technical debt reflects the extra development work that
arises when code that is easy to implement in the short term is
used instead of applying the best overall solution.
The barrier of silos(¹) and bimodal(²) practices
Industry standard open source DevOps tools
such as Git(³), Jenkins(⁴) and Jira(⁵) were not
designed with the unique IBM i architecture in
mind. As such there is an IBM i technology layer
missing without which these tools become inef-
fective in practice when applied to IBM i. Typi-
cal questions asked by modern development
leaders as they modernize their processes for
DevOps include:
1. why use Jira to track IBM i development
issues if there is no synchronization between
Jira issues and IBM i application development
documents.
2. Why use Git as your universal version
control system if your mature developers
threaten to resign because you are taking
away their familiar SEU and PDM tools.
3. Why use Jenkins to trigger an IBM i build if the
build steps on IBM i are manual or require crea-
tion of a complex custom “makefile” in control
language programs.
These and other barriers have caused some
enterprises to create IBM i silos(1) or bimo-
dal(2) practices in order for DevOps to conti-
nue around them without DevOps actually im-
pacting traditional IBM i development. While
bimodal practices have mostly succeeded in
enabling DevOps in some parts of the enter-
prise to progress in the early stages, as DevOps
matures these practices create friction, even
conflict between the two groups. Group 1
Arcad Software, January 2020- www.arcadsoftware.com • page 9
White paper DevOps for IBM i
seeing themselves as defenders of ‘what works’
; ‘what runs the business’ and group 2 seeing
themselves as ‘champions of new and superior
methods’ ; ‘building systems which enable the
business to compete, grow and prosper’.
To alleviate this problem, a cross-platform stan-
dardization on enterprise tooling such as Git,
Jenkins and Jira coupled with ARCAD’s layer of
IBM i specific technology helps to progressively
migrate IBM i staff to DevOps methods while
maintaining productivity and compliance re-
quirements.
‘Industry standard open source
DevOps tools were not designed with
the unique IBM i architecture in mind
ARCAD provides the missing IBM i
technology layer that makes them
usable’
- Philippe Magne, Arcad Software 2020
‘The problem with silos and bimodal
practices is that eventually they
create friction, even conflict’
- Philippe Magne, Arcad Software 2020
(1) An IBM i silo is a circumstance where IBM i teams are closed
off from other technical teams within an organization, follow
their own processes which are different from those of the rest of
the organization.
(2) A Bimodal practice is where developers are divided
typically into two groups each following a different ‘mode’ of
development. Mode 1 are typically highly specialized IBM i
developers working on core system maintenance projects and
following traditional, stable, slow moving development cycles.
Mode 2 are typically younger developers working on projects
which help innovate or differentiate the business. Mode 2
projects require a high degree of business involvement, fast
turnaround and frequent updates.
(3) Git (maintained by Junio Hamano) is an industry standard
open source DevOps tool used as a distributed version-control
system for tracking changes in source code during software
development. It is designed for coordinating work among
programmers, but it can be used to track changes in any set
of files. Its goals include speed, data integrity, and support for
distributed, non-linear workflows.
(4) Jenkins (by Jenkins) is an industry standard open source
DevOps tool used as an automation server. Jenkins helps to
automate the non-human part of the software development
process, with continuous integration(CI) and facilitating
technical aspects of continuous delivery (CD).
(5) Jira (by Atlassian) is an industry standard open source and
proprietary DevOps tool used for issue (bug) tracking and agile
project management.
White paper DevOps for IBM i
The barrier of onboarding new talent while re-
taining mature IBM i talent Most young deve-
lopers on IBM i use RDi(⁴) but have never seen a
fixed format language(¹) and most mature IBM
i developers feel they could not be effective
without their familiar, highly specialized green
screen 5250 development tools such as PDM(²)
and SEU(³). Both young and mature develo-
pers are needed to ensure successful and ma-
ture IBM i DevOps environments. It’s important
for all developers to collaborate and share the
same version control system. Trying to address
the needs of both groups requires some crea-
tivity.
‘Most young developers have never
seen fixed format code’
- Michel Mouchon, Arcad Software 2020
‘Some of our customers tell us that
their mature IBM i developers would
resign if they could not use SEU or
PDM any more’
- Philippe Magne, Arcad Software 2020
(1) Fixed format RPG is source code (e.g. RPG II, RPG III and
RPG IV) which requires instructions to be entered into a specific
column and where the position of a character or number can
have a different meaning and outcome. It’s efficient code in
that it is much less verbose than most modern programming
language code but to younger developers it looks alien (like
assembler code) rather than the free form languages like C
and Java they grew up with and therefore it’s harder for them
to learn.
(2) PDM (programming development manager) is a
proprietary IBM i green screen 5250 productivity tool which
allows developers to use shortcuts to perform repeated tasks.
Programmers can also create their own custom shortcuts. PDM
simplifies repetition, recall, search and filtering across large
object libraries and large source code files. In the hands of a
power user it can deliver high gains in speed of development.
(3) SEU (source entry utility). Is a proprietary IBM i green screen
source code editor which allows prompting of commands
to validate their syntax. It allows entry of many different
programming languages by changing the source entry type.
(4) RDi (IBM® Rational® Developer for i) is an integrated
development environment (IDE) built on the Eclipse platform.
Designed for creating and maintaining applications on IBM i
systems in a more graphical way than green screen 5250 tools,
it resides on the developer’s desktop, supporting development
in both host-connected and disconnected modes.
The barrier of loosely coupled, non-integrated
DevOps tools Some enterprises have attemp-
ted to construct home-grown DevOps solutions
Page 10 • Arcad Software, January 2020 - www.arcadsoftware.com
by combining open source “point” tools with
internally developed tools or scripts. While
this may seem like a good idea at first it qui-
ckly leads to business risks. Non-integrated tool-
chains pass little or no information between
each tool in the chain. Each one designed to
address one issue with little care for what hap-
pens elsewhere in the life cycle. The business
risk is that these non-integrated tool chains al-
low defects to pass through undetected and
they cannot deliver the economies in perfor-
mance that an integrated solution can. Each
new release of a point solution must be tested
for compatibility with the rest of the tool chain.
That’s an instability risk for the future. Such
approaches typically lead to DevOps matu-
rity getting stuck either in the early or middle
stages because as velocity increases so does
friction.
The goal of DevOps is to streamline the transfor-
mation of an idea into a production-ready fea-
ture that adds value to the business. To achieve
this, the entire process from idea through to
deployment to production must be seamless.
This requires a profound change in the way we
approach software development – and it ap-
plies to “back-end” application development
as well as to front-end. For a seamless process
to work, security and automation must be built
into the process from the start. For example,
automated, continuous regression testing will
safeguard against incidents in production wi-
thout introducing an unnecessary bottleneck.
To find the right balance between risk vs. ef-
ficiency, DevOps encourages the rapid han-
dling of very small software increments, thus
accelerating their path through the software
development lifecycle.
‘Non-integrated, home grown
DevOps point solutions limit the level
of DevOps maturity in the enterprise’
- Philippe Magne, Arcad Software 2020
The barrier of lengthy, late or truncated test
cycles Under pressure to deliver new functio-
nality into the hands of users more quickly, and
still using traditional waterfall development
models, code quality checking is often seen as
a bottleneck in the process. Done manually
this can be a tedious process which often re-

quires lengthy peer reviews. Unit testing is of-
ten done by developers creating their own unit
tests and then throwing that investment away.
Regression testing done manually is also a te-
dious process because it is time consuming to
identify the right test cases to run and then to
set them up correctly.
The problem is that when testing gets cut short,
there is a higher overall cost to the business be-
cause more defects get released to produc-
tion and inevitably become more costly to re-
pair than they would have been if the testing
detected them early in the life cycle.
‘When delivery deadlines loom, then
it’s typically the test phase that gets
squeezed or even removed from the
timeline’
- Philippe Magne, Arcad Software 2020
The barrier to start taking advantage of cloud
computing IBM i operations teams are star-
ting to feel the pressure to move away
from inflexible and costly fully in-house in-
frastructure and stat taking advantage
of hybrid cloud(¹) based infrastructures to
improve agility and reduce capital expen-
diture. Just as with software agility the in-
frastructure that the software runs on must
be able to adapt faster to changing bu-
siness needs. Struggling with higher prio-
rities and not having a clear and simple
path, this business need is often shelved by
IBM i teams.
‘Although cloud computing has
become a foundation of digital
business, many organizations still
struggle to optimize this powerful
tool’
- Gartner Research 2019
(1) Hybrid cloud is a cloud computing environment which uses
a mix of on-premises, private cloud and third-party, public
cloud services with orchestration between the platforms.
Arcad Software, January 2020- www.arcadsoftware.com • page 11
White paper DevOps for IBM i
HOW ARCAD HELPS TO
REMOVE BARRIERS TO
DEVOPS MATURITY
How to modernize applications when they are
difficult to modernize
Arcad Software offers modernization as a ser-
vice (MaaS) and specialized ARCAD moder-
nization tools which enable you to tackle dif-
ficult modernization projects in-house or with
our support. Our deep expertise in legacy IBM
i application modernization coupled with AR-
CAD tools enables us to help tackle the most
challenging projects. Modernization projects
can include modernization of databases,
source code, user interfaces, CA 2E (Synon)
and Unicode. We can execute your whole
modernization project or we can work with you
as part of your team.
‘Application modernization and
DevOps go hand-in-hand’
- Philippe Magne, Arcad Software 2020
How to eliminate silo and bimodal barriers
ARCAD for DevOps(1) provides an IBM i specific
technology layer which is missing from industry
standard DevOps tools such as Git, Jenkins and
Jira. This technology layer makes these industry
standard open source tools usable on IBM i.
Tasks initiated by Git, Jenkins and Jira are exe-
cuted on IBM i in an automated way which
respects the unique IBM i architecture. This en-
ables you to integrate IBM i development more
easily with the rest of the enterprise and for a
single enterprise pipeline to manage all the
applications in your portfolio.
The ARCAD Repository used by all ARCAD
modules(¹) contains rich real-time metadata
about all IBM i applications under develop-
ment. The ARCAD Repository enables a fric-
tionless process as developers pass through all
stages of development. Each change and ac-
tion made by a developer during testing and
deployment phases for example is tracked and
can be rolled back on error, automatically. De-
White paper DevOps for IBM i

ployments can happen to any platform using
pre-defined processes. By eliminating manual
deployments you guarantee the integrity of
your Test, Pre-Production and Production en-
vironments. You gain confidence in the state
and synchronicity of your environments and in-
crease velocity of deliveries.
With the IBM i specific technology layer in
place, Git, Jenkins and Jira become usable for
the IBM i and it becomes much easier to break
away from silos and bimodal practices and
join in with other enterprise DevOps teams.
‘ARCAD for DevOps helps developers
break out of their silos and bimodal
practices safely’
- Philippe Magne, Arcad Software 2019
‘ARCAD provides the IBM i specific
technology layer that renders
enterprise tools like Git, Jenkins and
Jira usable in practice on IBM i’
- Philippe Magne, Arcad Software 2019
(1) ARCAD for Devops is made up of the following modules:
ARCAD Repository, ARCAD Observer, ARCAD Skipper, ARCAD
Code Checker, ARCAD Builder, ARCAD iUnit, ARCAD Verifier
and DROPS

ARCAD for DevOps provides a risk-free “bridge” between two development modes (SoE and SoR) in
bimodal operation, to ensure a seamless flow for accelerated and reliable software delivery

Page 12 • Arcad Software, January 2020 - www.arcadsoftware.com


How to onboarding new talent while retaining
mature IBM i talent
ARCAD is unique in supporting Git based de-
velopment on IBM i from either a green screen
5250 interface with SEU or PDM or graphical-
ly with RDi. You can have different tools in the
same team so young developers can use RDi
while more mature developers use SEU and
PDM. Both will use Git as the master distributed
version control system. Also, when develo-
pers use the RDi project view to make code
changes ARCAD Skipper will track the task and
report to Jira automatically.
ARCAD Observer for application analysis gives
all developers an instant understanding of the
impact of a code change. Cross reference
down to the field and source line level gua-
rantees accuracy, guarantees completeness
and the integrity of each code update. ma-
nagers can more precisely estimate how long
a development project will take and more ac-
curately report back to the business.
The ARCAD Git hybrid environment and power-
ful application analysis enables both young
and mature developers to work on the same
projects side by side using their preferred tools
while ensuring consistent centralized version
control.
‘Using Git standalone for central
source control enables the enterprise
to bring IBM i 5250 developers and
open source developers together in
a Git hybrid environment’
- Ray Bernardi, Arcad Software 2020
ARCAD for DevOps is unique in offering repository-based process optimization via an enterprise
DevOps toolchain based on Git, Jenkins and Jira spanning all platforms Windows, Linux, IBM i and z/
Arcad Software, January 2020- www.arcadsoftware.com • page 13
White paper DevOps for IBM i
How to eliminate the business risk of loosely
coupled, non-integrated DevOps tools
Each ARCAD module automatically updates
the ARCAD Repository in real time and shares
this information with all other ARCAD modules.
This tight integration optimizes the entire deve-
lopment life cycle. The ARCAD Repository elimi-
nates trivial consistency errors, automating the
source code analysis, dependency build and
forcing development guidelines and helping
to train your newer developers in real time.
By comparison non-integrated DevOps tool
chains stitch together individual point solutions
each designed to address a specific issue but
lacking shared metadata on the state of the
applications and target environments. These
non-integrated tool chains can allow defects
to pass through and they cannot match the
performance advantages that ARCADs inte-
grated offering can provide.
‘DevOps tools and practices need
to be useful to your IBM i teams and
not in their way’
- Philippe Magne, Arcad Software 2020
White paper DevOps for IBM i
How to eliminate lengthy, late or truncated test
cycles
ARCAD Code Checker creates and enforces
code quality guidelines. Code Checker auto-
mates the tedious source code quality checks
or continuous peer reviews. ARCAD Builder per-
forms smart dependency builds automatically.
Using the ARCAD Repository it finds dependent
components, automatically sequences com-
pilations and ensures the integrity of every
change. This automation saves time and effort
and improves the quality and accuracy of de-
ployments. ARCAD iUnit eliminates the need
for developers to create their own unit tests
and then throwing that investment away.
ARCAD iUnit automatically creates tests and
then executes them as an integral part of the
continuous integration and delivery cycle. AR-
CAD Verifier mines the ARCAD Repository to
identify precisely which regression test cases
are impacted by the code change. It groups
them and runs them automatically and reports
instantly on defects before they propagate fur-
ther down the cycle.
Instead of your test phases taking months and
involving a hundred different journeys through
The Shift-Left effect: Most software defects are introduced in the coding phase, but only found late
in the process. The earlier the defects are detected, the less they cost the business.
Page 14 • Arcad Software, January 2020 - www.arcadsoftware.com
your application ARCAD Verifier will identify for
example the exact 25 cases to run cutting your
testing effort by up to 90%. ARCAD Verifier uses
the ARCAD Repository to go under the hood of
your IBM i applications and to locate defects
deep down in the source code, spool files and
database and then notify the developer of the
specific code lines behind a defect and what’s
been changed in the database.
Taken together ARCAD modules contribute
to fixing defects much earlier in the develop-
ment cycle when their cost is much lower. This
is also called the Shift-Left effect. Thanks to this
integrated approach you can document your
continuous improvement, speed up your de-
velopment cycles and pack more functionality
into each release.
‘ARCAD modules contribute to
fixing defects much earlier in the
development cycle when their cost
is much lower. Also called the “Shift-
Left” effect’
- Philippe Magne, Arcad Software 2020
 White paper DevOps for IBM i

How to start taking advantage of cloud com-
puting
IBM is fully embracing Red Hat OpenShift(¹) as
their primary container environment for all IBM
hybrid cloud offerings. IBM is fully embracing
Red Hat OpenShift(¹) as their primary container
environment for all IBM hybrid cloud offerings.
This includes IBM Cloud which supports IBM
i. OpenShift provides a platform as a service
(PaaS). Red Hat Ansible(²) is a DevOps tool for
configuration management and deployment
of infrastructure and provides infrastructure as
code (IaC). Skytap(³) provides software as a
service (SaaS) based environments for deve-
loping and testing complex applications inclu-
ding IBM i infrastructure.

DevOps for IBM I in the cloud - ARCAD example configuration #1: virtualization of development and
test environments

DevOps for IBM I in the cloud – ARCAD example configuration #2: wholesale lift and shift to Skytap
Cloud
Arcad Software, January 2020- www.arcadsoftware.com • page 15
White paper DevOps for IBM i

Through the Arcad Software collaboration
with IBM and Skytap, ARCAD and DROPS have
been integrated(⁴) with OpenShift, Ansible and
Skytap. This makes it easier to adopt modern
development practices and integrate new
cloud architectures and processes.
A first quick win scenario into cloud computing
for many IBM i shops is to use these technolo-
gies to spin up and provision test environments
in the cloud, on any platform, including IBM i.
Testing is a periodic activity which requires new
(1) IBM Red Hat OpenShift, (owned by IBM) is a full-stack auto-
mated containerization platform which enables the manage-
ment of hybrid and multicloud(2) deployments. It is also com-
monly referred to as a PaaS (platform as a service).
(2) IBM Red Hat Ansible (owned by IBM) is a DevOps tool used for
open-source software provisioning, configuration management,
and application-deployment. It runs on many Unix-like systems,
and can configure both Unix-like systems as well as Microsoft
Windows. It is also commonly referred to as IaC infrastructure as
code.
(3) Skytap provides Software as a service (SaaS) based environ-
ments for developing and testing complex programs. Skytap
can migrate and run AIX, IBM i and Linux on IBM POWER natively
in the public cloud.

environments to be set up for each project. (4) ARCAD integration with IBM RedHat OpenShift and IBM Re-
Testing is considered an important but non-bu- dHat Ansible is available in ARCAD V12.
siness critical activity hence moving testing to
the cloud is seen as a safe.

Applications are becoming increasingly dy-

namic, complex, distributed and component
based. Cloud-based testing has the potential
to offer a compelling combination of lower
costs, pay-per-use and elimination of upfront
capital expenditures (Cap-Ex). It can address
the ramping demand for sophisticated test en-
vironments.

‘Businesses are starting the next

chapter of their digital reinventions,
modernizing infrastructure and
moving mission-critical workloads
across private clouds and multiple
clouds from multiple’
- Ginni Rometty, IBM, 2019

‘Cloud computing continues to

evolve from a market disruptor to the
expected approach for IT’
- Gartner Research, 2019

Page 16 • Arcad Software, January 2020 - www.arcadsoftware.com

 White paper DevOps for IBM i

CONCLUSIONS

Enterprises which try to implement DevOps without expanding investment in IBM i risk cost overruns
and delays because so much depends on IBM i data. The unique architecture of the IBM i has
helped it remain one of the most secure, available and scalable platforms on the planet with a TCO
lower than Windows or Linux. The IBM i, despite its longevity, has become a fully modern platform
able to take advantage of the latest development languages and open source DevOps tools. No
wonder it is trusted by enterprises across most industry sectors to run their mission critical business
applications.

IBM i practitioners recognise that traditional waterfall based development methods, prevalent for
so long on IBM i need transformation if the enterprise is to remain competitive beyond 2020. DevOps
is seen by most as an indispensable part of this digital transformation but for many enterprises IBM i
DevOps maturity levels remain stuck in the middle.

The maximum achievable level of DevOps maturity is influenced by the level of IT maturity within
the enterprise. Particularly if your IT maturity levels are lagging behind in the areas of application ar-
chitecture, deployment and packaging and application infrastructure, it’s difficult to achieve fully
mature IBM i DevOps.
On the road to DevOps maturity on IBM i, key challenges include: non-modernized applications;
silos and bimodal practices; onboarding new talent while retaining mature talent; replacing loo-
sely coupled, non-integrated DevOps tools; lengthy, late or truncated test cycles and monolithic
architectures that hold back the adoption of cloud technologies. ARCAD solutions help resolve
these IBM i challenges with an approach centered on automated application modernization, agile
workflow for software delivery and a unified «DevTestOps» process.

Arcad Software is unique in offering an end-to-end, integrated and modular suite of DevOps tools
which remove modernization barriers and help you achieve mature DevOps on IBM i. Arcad solu-
tions integrate tightly with Git, Jenkins, Jira and Azure DevOps, spanning IBM i, Linux, Windows and
z/OS. These deep integrations enable a shared DevOps toolchain and common source repository
across all technology platforms.

‘Enterprises which try to implement DevOps without expanding investment in

IBM i risk cost overruns and delays because so much depends on IBM i data’
- Philippe Magne, Arcad Software 2020

Arcad
software
www.arcadsoftware.com
Arcad Software, January 2020- www.arcadsoftware.com • page 17