Project Description

My IBM Australia Days & Enterprise Printing

Also including reference to GEAC, IBM Global Services, Salmat Australia Limited

These are reflections on my days with IBM Australia (mainly IBM) and the benefits of a Solutions approach to our projects, with valuable principles such as good mentoring, sharing, transparency, balance and concern for all stakeholders, and the pressures from large projects.

IBM Days - A Reflection

IBM: Education, Opportunity, and Lessons in Loyalty

Introduction

I worked with IBM Printing Systems Division in Australia from June 1996 until April 2001, following several years with an IBM RS/6000 Business Partner. Looking back, IBM was more than an employer. It was an education in technology, business, people, and the realities of corporate life.

The experience shaped much of my career and provided lessons that remained relevant long after I left the company.

Taking the Leap

My move to IBM was driven by both opportunity and necessity.

At the time I was living in Sydney while being paid on Brisbane salary levels. Rising living costs were making life increasingly difficult. When my rent jumped from $250 to $360 per week in a single increase, I remember wondering how I was going to make the numbers work. Today, that same apartment would likely command many times that amount.

When I resigned, the CEO warned me that joining IBM would be a mistake and would damage my IT career.

It did neither.

Instead, IBM broadened my horizons, expanded my technical capabilities, introduced me to talented people around the world, and provided opportunities I would never otherwise have experienced. In those earlier days I was across most components of IT – routers, modems, printers, soldering wires, Unix, business software etc. I traveled all over Brisbane, then Sydney, using my street directory to find locations.

Learning the IBM Way

IBM has often been described as an education rather than simply a workplace. I found that description accurate.

The company taught technical skills, but it also taught professional discipline.

Face-to-face communication mattered. Public enquiries were answered regardless of who was calling. If someone needed assistance, it was your responsibility to help or find someone who could. Returning calls promptly was expected. Professionalism was not treated as a slogan but as part of everyday work.

Even today I can often recognise former IBM employees by the way they carry themselves. There was a culture of professionalism that left a lasting impression.

Advanced Function Printing and Technical Growth

Much of my work centred on IBM’s Advanced Function Printing (AFP) architecture, problem management, and production printing systems.

Alongside this, I provided AIX technical support and assisted sales teams with technical solutions involving IBM systems and software.

The work exposed me to a broad range of technologies and industries. It also brought me into contact with IBM laboratories and specialists around the world, including colleagues in Boulder, Colorado.

My overseas travel was never based on status. It was based on usefulness to the business. That lesson alone was valuable. Organisations invest where they see value being created.

Recognition and Achievement

During my time with IBM I received several awards, including recognition that placed me among the top four percent of performers.

Printing and mailing technologies were major industries in the United States during that era. At one conference in Orlando, the industry was large enough to support its own dedicated television coverage.

I also travelled to Wiltshire in England to study IBM archival technologies that were used extensively by banks and large organisations, including institutions in Australia.

These experiences reinforced how widely technology influences everyday business operations, often unseen by the people who rely on it.

Projects That Endured

One of the greatest satisfactions of my career has been discovering that some projects remained operational for decades.

A project I worked on for Qantas involved moving legacy data from a Unisys mainframe environment using SNA communications onto Ethernet-connected IBM RS/6000 systems. The solution supported overnight maintenance documentation for aircraft servicing operations.

Other projects served major Australian businesses and financial institutions for many years after implementation.

While I contributed to those solutions, I remain conscious that many experienced professionals took the time to teach me, challenge me, and expand my understanding along the way.

Becoming a Solutions Architect

Over time I realised that one of my strengths was seeing what could exist before it had been built.

I was often comfortable making decisions in situations where others hesitated. I could visualise systems, data flows, and outcomes before development commenced.

These capabilities contributed to my eventual recognition as a Solutions Architect by IBM both in Australia and internationally.

That said, many architects possessed highly specialised skills that exceeded my own in particular areas. What made the experience rewarding was working alongside talented people with different strengths and perspectives.

Lessons from High-Pressure Projects

Many projects involved intense pressure, difficult timelines, and competing opinions.

On one major engagement I worked closely with IBM laboratories and management teams in Boulder. We were making measurable progress when senior management changed the delivery timeline.

From a technical perspective I knew the revised schedule could not succeed. Alternative approaches were proposed that I believed had little chance of working.

Rather than argue endlessly, I continued advancing the solution that was producing results. Eventually the revised timetable collapsed and the original work delivered a successful outcome.

Experiences like this taught me that confidence should come from evidence, not hierarchy.

An example of pressure:

The Qantas project involved moving legacy data from a Unisys mainframe environment using SNA communications onto Ethernet-connected IBM RS/6000 systems. The solution supported overnight maintenance documentation for aircraft servicing operations.

The project was not without controversy. A senior IBM engineer repeatedly phoned me, sometimes angrily, insisting the design would not work. The difficulty was that there was no practical alternative. The RS/6000 hardware available to us had a specific path from SNA into Ethernet, and the business requirement remained unchanged. The data still had to move between Melbourne, Sydney, and the associated printing systems.

I reviewed the documentation repeatedly and could find no technical basis for the objections. The engineering reality was straightforward: either this solution worked, or there was no solution. Despite the criticism, we proceeded. The engineer had no advice or alternative to propose.

The system worked exactly as intended.

That experience taught me an important lesson. Technical discussions should be settled by evidence, testing, and engineering facts—not by who speaks the loudest. Confidence is useful, but proof is better.

The Human Side of Information Technology

Technology projects are often portrayed as technical challenges. In reality, most are human challenges.

Throughout my career I observed extraordinary professionalism and, occasionally, disappointing behaviour.

I saw people work heroically under pressure. I saw individuals refuse to share knowledge for fear of losing influence. I saw organisations promise outcomes that were technically impossible. I saw others openly admit what they did not know and work collaboratively toward a solution.

One project faced a looming penalty of $100,000 per month. The breakthrough came not from technology but from creating an environment where people felt comfortable sharing ideas without fear of criticism.

Once a viable direction emerged, progress accelerated rapidly.

Again and again I found that people solved problems when they felt safe enough to contribute.

Loyalty, Redundancy, and Reality

As the years passed, IBM changed.

Large-scale redundancies became common. Many talented employees lost positions with little warning. I witnessed people reduced to tears after years of dedicated service.

The experience altered perceptions about loyalty.

Veteran IBM employees openly acknowledged that the traditional relationship between employer and employee had changed. Loyalty could no longer be assumed to flow in both directions.

Years later, when I left IBM Global Services, someone remarked that there really was life after IBM.

They were right.

When Work Stops Being Healthy

My final year in Solutions Architecture was the most difficult period of my IBM career.

The role became heavily focused on timesheets, utilisation metrics, and administrative control. Research, reflection, and technical exploration—activities essential to architecture work—were increasingly discouraged.

Architects were expected to deliver complex outcomes within unrealistic constraints while having limited authority over design decisions.

For the first time in my career, I felt trapped.

The experience reinforced an important lesson: professional success is meaningless if it comes at the expense of wellbeing.

Too many people find themselves moving towards burnout, depression, or physical illness because workplace demands become excessive and relentless.

It is a reality that deserves greater attention.

Life After IBM

When I left IBM, one thing became immediately obvious.

I no longer had access to the immense pool of developers, specialists, documentation, and institutional knowledge that had surrounded me for years.

The absence was noticeable.

Yet leaving also brought financial relief. For the first time in my career I experienced a salary that allowed me to move beyond merely surviving from one pay cycle to the next. I was able to eliminate debt and build some financial stability.

That experience left me with a deep appreciation for the financial pressures many people face every day.

My follow-on years led me to new local and overseas projects, utilising my past skills and experience.

Final Reflections

My career in information technology exposed me to banks, manufacturers, hotels, libraries, insurers, transport operators, telecommunications providers, and many other industries.

I learned about systems, architecture, and technology.

More importantly, I learned about people.

I learned that expertise matters, but character matters more.

I learned that some people lead through fear while others lead through trust.

I learned that loyalty has limits, professionalism endures, and good people are often the reason projects succeed.

IBM was not perfect.

No organisation is.

But it provided an education that shaped my career, broadened my perspective, and left me with lessons that remain valuable to this day.

Enterprise Printing - IBM AFP

The Hidden World of Enterprise Printing

Most people only ever see desktop printers. We print a document at home, send something to an office printer, or visit a copy shop when we need larger jobs completed.

Before email, internet banking, online accounts, and digital communication, however, an entirely different world existed behind the scenes.

Every bank statement, telephone bill, utility account, insurance notice, and government letter had to be physically printed and mailed. Millions of documents were produced every day, and they had to be accurate. A missing page, damaged statement, or printing error could affect thousands of customers.

This was the world of enterprise printing.

Printing Before the Internet

Large organisations relied on mainframes and midrange systems such as the AS/400 to process enormous volumes of data.

Desktop printing technologies were not designed for this environment. Languages such as PCL and, later, PostScript were suitable for office printing but were not originally intended for high-volume, mission-critical production environments.

The challenge was not simply printing a page. The challenge was ensuring that millions of pages could be printed accurately, tracked, and recovered if something went wrong.

That requirement led to specialised enterprise printing architectures.

IBM’s Advanced Function Printing (AFP)

IBM developed a technology called Advanced Function Printing, commonly known as AFP.

AFP was much more than a print driver. It was a complete architecture that defined how documents were constructed, formatted, transmitted, printed, and verified.

Most people today think of a document as something created in Microsoft Word. AFP was fundamentally different. Documents were built from structured data and presentation instructions designed for industrial-scale printing environments.

One of AFP’s strengths was reliability.

If a paper jam occurred halfway through a print run, the system could identify exactly where the failure happened and reprint only the affected pages. This may sound ordinary today, but at the time it was a significant achievement when dealing with hundreds of thousands of statements in a single production run.

The printer itself became part of the verification process.

Intelligent Print Data Stream (IPDS)

A key component of the AFP environment was Intelligent Print Data Stream, or IPDS.

IPDS allowed the host system and printer to communicate continuously. The printer could confirm what had successfully printed and what had not.

This meant the printing process was not simply sending data and hoping for the best. The printer actively reported its status and could participate in error recovery.

For environments such as banking, warehousing, logistics, and government, this level of control was extremely valuable.

The Other Side of Printing

Many people remember the older bank statements and utility bills of the 1970s and 1980s.

These were often produced using line printers and matrix printers. Instead of lasers and toner, they relied on mechanical hammers striking paper through inked ribbons.

The distinctive appearance of those documents was a product of the technology available at the time.

Although less sophisticated than later AFP environments, these systems formed the foundation of large-scale business printing for many years.

Archiving: The Problem Nobody Saw

Printing was only half the challenge.

Organisations also needed a way to retrieve documents years after they had been created.

Banks, insurers, and government agencies could not simply print a statement and forget about it. They needed rapid access to historical information.

IBM addressed this with archival technologies that later became known as OnDemand systems.

These platforms could store vast quantities of document data and retrieve information within seconds, even when managing millions of records.

Today, when a customer accesses an old statement through online banking, they are benefiting from ideas and technologies that originated long before modern cloud platforms became common.

The Great Transition

The late 1990s and early 2000s were a period of enormous change.

Mainframe-generated statements increasingly moved into relational database environments. Legacy networking technologies such as SNA gradually gave way to Ethernet and TCP/IP. Physical mail volumes began to decline as email and online services became widespread.

The printing industry evolved alongside these changes.

Enterprise print volumes reduced. Colour printing became more important. Archiving, software, and digital document management grew in significance. The focus shifted from printing information to managing information.

Why It Matters

Most people never see enterprise printing because, when it works, it remains invisible.

Yet for decades it formed part of the critical infrastructure supporting banks, utilities, airlines, insurers, and government agencies.

The systems had to be reliable. They had to scale. They had to recover from failure without losing information.

Working in this environment taught me an important lesson about technology.

The best systems are rarely the most visible. They are the systems that quietly perform their function every day while millions of people remain completely unaware they exist.

Enterprise printing was one of those systems.

Much of the technology has now been replaced or transformed, but many of the principles remain relevant today: reliability, scalability, recoverability, and thoughtful design.

Those principles matter whether you are printing a million bank statements, building a website, or designing the next generation of digital services.

IT Technology v. Solutions

When people work with a technology for years, they naturally become experts in the technology. The trap is believing customers buy the technology.

Most don’t.

Banks didn’t buy AFP because it was an elegant print architecture. They bought it because they needed to produce millions of statements accurately and reliably.

Warehouses didn’t buy IPDS because they cared about datastream verification. They bought it because they needed shipping labels to print correctly at 2 a.m. without stopping operations.

Insurance companies didn’t buy archival systems because they admired the database design. They bought them because customer service staff needed to retrieve a seven-year-old document in seconds.

In other words, customers bought outcomes.

A technical specialist might say:

“AFP provides page integrity, resource management, and print recovery.”

An architect or solution designer might say:

“If a printer jams halfway through a 500,000-page statement run, the business can recover automatically without reprinting everything.”

Both statements are true. The second one is the one executives understand.

Looking back, one of the most important lessons I learned was that customers rarely buy technology. They buy outcomes. AFP was a remarkable architecture, but organisations were not purchasing AFP itself. They were purchasing reliability, recoverability, compliance, and confidence that millions of critical documents would be delivered correctly. Over time I realised that successful technology projects are rarely about products. They are about solving problems. The technology is simply the tool.

Two Project Examples

Over time I noticed a recurring pattern in technology projects.

People are naturally attracted to what is new, visible, and impressive. New products generate excitement. New interfaces attract attention. New hardware creates interest. Yet the factors that determine long-term success are often much less glamorous.

I remember attending an industry conference in Orlando where a major organisation had signed a contract worth around one million dollars. Much of the attention focused on the hardware and the size of the deal. What interested me was something else. I knew there would be significant challenges integrating and managing the customer’s data as I knew the software involved. Experienced and qualified specialists could solve those problems, (including reverse engineering of data) at a cost of fifty thousand dollars, but the work was largely invisible compared to the excitement surrounding the deal itself.

Years later I saw a similar pattern on another project.

A young manager wanted online mobile phone bills to look modern and visually impressive. He was enthusiastic about a particular product and dismissed concerns about reliability, maintainability, and data integrity as old-fashioned thinking. The development team was directed to use the technology (including iframes) despite reservations from several experienced people involved in the project who he berated.

For a time, the solution appeared successful. The presentation looked modern and the project moved forward.

Not long afterwards, however, the technical limitations became apparent. Parts of the implementation had to be removed and reworked because the underlying approach created problems that had not been fully considered during the initial enthusiasm and stubbornness.

Neither experience was unusual. In fact, they reflected something I encountered throughout my career.

Technology changes constantly. Products rise and fall. Today’s innovation often becomes tomorrow’s legacy system. What tends to endure are the engineering principles underneath: reliability, recoverability, maintainability, scalability, and a clear understanding of business requirements.

The most valuable lesson I learned was that successful projects are rarely about selecting the most fashionable technology. They are about understanding the problem well enough to choose technology that will still be serving the business long after the excitement has faded. Solutions Architecture fits well to this.

In fact, the older I get, the more I think one sentence captures much of what I’ve written about my career: