Introduction
The purpose of this forum discussion is to serve as a basis for seeking verification, validation, and competing perspectives from the small group of participants invited to participate. By way of introduction, note that we will need to share a lot of background information to provide context and evidence for the current facts, and to explain and quantify the opportunity.
This discussion is the result of the following insightful question posed by someone whose views the author values highly: “Playing devil's advocate: if they won't even pay for hardware maintenance or keep their OS current, will they care enough about modernizing their apps…?”, following a post by Bob Losey on LinkedIn: https://www.linkedin.com/pulse/whats-real-cost-ignoring-your-legacy-ibm-i-server-what-bob-losey-azigc/
Once this question was asked so bluntly, it dawned on the author that many of the assertions and assumptions about the motives and objectives of the intERPrise initiative need to be explained in detail, as many of the foundational considerations may not be apparent to people unfamiliar with, or only partially familiar with, the platform and community. To quote a recent participant with more than 5 decades of international (non-IBM i) IT and ERP experience, “this community is totally different from anything else I have ever encountered.”
Participants in this discussion need a clear understanding of the IBM i installed base and the vast differences within it. Also, to recognize that their perspective may not represent the bulk of the installed base, due to vastly different realities. Most people talking about and to the “installed base” today are oblivious to the fact that they unknowingly ignore the largest group of installations globally.
Acknowledge that this document represents our (TEMBO’s) perspective on the market, the opportunity, and how this market originated, as it is the culmination of a myriad of factors that created this remarkable, largely unknown, and untapped market. This perspective is underpinned by more than four decades of experience and insight in this market, both as an SMB user and later as a specialist ISV, for almost four decades on the supply side of services and expertise to the entire global market, with very close ties to IBM Rochester in the 1990s.
Note that this analysis aims to explain how the market evolved. While it may appear critical of IBM Rochester in particular, that is not our intent. In most cases, they—as much as the platform's users—were victims of corporate decisions prioritizing short-term NYSE investor targets. Also note that this development evolved over more than two decades.
For the rest of this forum discussion, our focus is on discussing the “missing masses” and why few even speak of them. Based on the analysis, we believe this represents as much as 80% (give or take a few percentage points either way) of the systems and customers still in production. This discussion aims to identify the causes and possible remedies. As such, ignore generalisations and consider whether you agree with the core statement or consideration, acknowledging that this is a complex, multifaceted discussion spanning two to three decades.
Henceforth, we will interchangeably refer to the missing masses as the “unknowns” and the formal, known, and serviced installations as the “knowns.” The entire formal industry, including IBM, all its partners, ISVs (Industry Software Vendors), COMMON, various other regional user groups, and sundry other vendors, focuses most, if not all, of its attention on the “knowns,” as explained and elaborated on elsewhere in this discussion. It is easy to market to the “knowns,” as they are very active, up to date on hardware and OS, and relatively easy to engage with decision-makers.
There are sprinklings of “unknowns” on the periphery that, from time to time, attempt to engage with the “knowns,” but usually the experience is less than desirable from their standpoint.
The current “known” market almost acts as an “echo chamber,” where the “unknown” market’s realities are essentially ignored, as no one recognises that nobody speaks for the silent masses. An incestuous culture exists in which everyone else's views are belittled and ridiculed.
A horrific tendency within the vendor community is to be very selfish and not share as much as they can for the benefit of the entire user community, under the pretense that they are protecting their intellectual “property” (a verbatim comment). We should either decide to serve the entire community or be selfish and doom it, as selfishness does not scale. The opportunity is large enough for everyone to benefit, so keeping anything that could unlock it for all participants is not wise.
Acknowledge that this discussion covers more than four decades of history and events. It is a complex and multifaceted discussion, and often statements will be made that will shock you, even upset you. That is not the intention, but we have to lay out all the facts and separate the wheat from the chaff to formulate a strategy that will address the mistakes or unanticipated outcomes of previous management actions.
Consider all the supporting references carefully, as they may help you gain a better understanding of a rare marketplace and community.
Management Summary
Based on the discussion that follows, we believe the potential market revenue is at least twice what IBM and its partners currently generate annually. Even if the opportunity is only a percentage of that figure, it amounts to much.
We also believe that by bringing the missing masses back into the fold, enormous benefits, and especially excitement and opportunity, exist if we can reverse the trend. Also, in adding many more years to the future of the platform we adore. Even potentially grow the market, as the platform is uniquely positioned to quietly settle the uncertainty, hype, and confusing messaging emanating from the industry globally.
Defining the IBM i (and predecessors) installed base
Analyzing the installed base without intimate knowledge of IBM business practices and the widespread use of the system by clients across virtually every industry imaginable will often leave the analyst confused, as the distinction between customers and machines (unique CPU serial numbers) can easily be blurred and used interchangeably. This distinction and the consistent use of the same metric become vital later on in this document.
The AS/400 reached its peak installed base of approximately 275,000 customers by the end of the 1990s, with around 500,000 discrete systems (i.e., unique CPU serial numbers) shipped by 1997 (therefore, on average, almost two systems per customer). It is estimated that approximately 550,000 to 600,000 systems were shipped by the turn of the millennium. By 2002, the base was around 250,000 unique customers, dropping to around 220,000 by 2005. IBM reported in 2012 for the last time that over 150,000 companies (customers, not discrete machines) were using IBM i. Since then, the only numbers available are from a single “friendly” industry analyst. Nobody knows exactly how many systems are still in production or where, given the platform's remarkable reliability.
There is no publicly available independent market research on the installed base, and IBM guards the numbers with total secrecy (not necessarily deliberately but as a consequence of how events played out). Due to this factor and the platform's unique nature, investors on the outside largely ignore the platform and the industry segment.
It is important to note that no current, valid database of contact details exists for every single IBM i (and predecessor) installation worldwide. Even the remarkable ALL400s initiative, though more recent than any other such attempts to reconstitute a representative database, represents only a small percentage of installations compared to the number of machines manufactured and installed since the platform's announcement in 1988.
The installed base demonstrates that companies that wanted to move on to other platforms have done so. Those remaining remain because of the immense value the combination of their applications and the platform brings. Often, the interdependency between the company and the application is such that one cannot function without the other, as all the business's competitive advantage is encapsulated in its application.
A key takeaway from all the various Fortra’s annual IBM i Marketplace Surveys conducted since 2016 is that a very small group of respondents, primarily from the “known” market, participated, with perhaps a handful from the peripheral “unknown” market. Again, the “unknowns” are underrepresented, though we believe, based on experience, the survey's broad findings apply equally to the SMB faithful and the known market. Although based on cursory evidence, the SMBs are more dependent on their applications to remain competitive, than their larger counterparts.
An interesting side note is that database marketing companies are constantly offering their versions of contact databases for sale, claiming the following statistics: 182,573 companies, with contact details for 435,682 “decision makers,” claiming an accuracy level of 95%. We seriously doubt these figures, but it does confirm the quantum in general terms.
Some IBM (Corporate) Background and how the “midrange” clients were serviced in the 1980s and 1990s.
It is perhaps best to explain this through the author’s experience, as it encapsulates the ethos and culture, and how IBM General Systems Division (GSD, the division responsible for the midrange systems) worked with its clients in the 1980s.
The midrange systems (S/3, S/3X, AS/400, iSeries, etc.) were designed to meet the commercial computing needs of small- and medium-sized businesses. At that time, IBM sold and serviced its clients directly.
My first installation in 1983, where I qualified as a programmer, had three programmers in total, developing and maintaining custom applications on an IBM System/38 to serve the needs of an organization that rendered municipal services to towns too small for their own municipality.
We were often visited by our local IBM SE (Systems Engineer), a common practice at the time, who supported us, guided us, freely provided example code, and offered a wealth of experience and knowledge, all free of charge. Later, I realized how amazing and unusual that was, as our SE at the time, the late John Schiff ( https://blogs.oracle.com/profit/post/john-schiff ), later became one of the founding architects and a member of JD Edwards' executive management team. (I am only sharing this to highlight the calibre of the IBM SEs at that time, supporting small installations.)
My second System/38 installation was (at that time) the largest paper and pulp manufacturer in the Southern Hemisphere, where we built our in-house ERP around GL Plus and MAPICS as the core for the financials and Elke Maintracker for the plant maintenance, all integrated with interfaces to our custom ERP that was highly integrated with the production shopfloor PLCs. This manufacturing site operated around the clock, 24 x 7 x 365. The development team consisted of four developers and two systems analysts. Again, in this instance, we had a dedicated SE allocated to our installation, as the company was part of the largest listed corporation in the country at that time. The support and access we received were fantastic.
The point of the two preceding paragraphs is that it was tiny teams that developed and maintained these systems, who usually knew the business and processes better than most, including the people performing the actual work. It also means the developers worked exceedingly hard and long hours, always under immense pressure and with no time to spare for experimentation, research, or study, unless executive management allocated time for those activities, or individuals sacrificed private time. There was always too much to do, with too little available time. Overtime and after-hours support were our staple “diet”.
IBM support, guidance, code examples, and solutions were just a telephone call away, and we used them freely and often. During the late 1970s and early 1980s, IBM augmented its capacity to sell to and support its customer base by appointing software industry specialists and geography-focused companies as partners, while tightly controlling its relationship with clients.
Both our (AO and as a consequence intERPrise) key architects had similar experiences, starting their careers as programmers with IBM SMB clients before moving to the services supply side, usually focused on larger (more profitable) installations.
The disruptive changes brought about by the advent of personal computers forced the entire industry to change; old business models came under increasing pressure, and IBM was not immune; it had to review and revise its business practices to remain a viable investment target on the NYSE. It should be acknowledged that the changes occurred under three successive CEOs: the late John F. Akers, the late Louis V. Gerstner, Jr., and Samuel J. Palmisano, with Lou Gerstner in particular gutting staffing and the direct engagement distribution models and changing the company and its culture forever during the period 1993 to 2002.
Sales and support staff, in particular, were severely impacted, and the impact on GSD (the division responsible, among other things, for the “midrange” platform) was particularly severe. In an effort to still serve their clients as best they could, subject to the new edicts, IBM adopted a much more aggressive “channel” strategy, over time essentially ceding all sales and support responsibility to the bulk of its clients through its business partners (the “channel”). They retained only the largest (often corporate or large multinationals) users of their systems, keeping control of those relationships while involving their business partners as needed.
This led to IBM Rochester gradually losing contact with the very clients (SMBs) who made the platform so hugely successful and popular, with an almost rabid following due to its remarkable reliability, flexibility, integration, efficiency, and ease of use.
Due to various financial crises during the platform’s existence, combined with a loss of impetus from corporate and other changes, the installed base and the business partner community globally contracted dramatically from the turn of the millennium until somewhere in the 2010s. Dramatic consolidation occurred everywhere, and true innovation and positive engagement suffered as a consequence.
Although the preceding is an oversimplification of events lasting more than two decades, the reader should be able to glean the essence of what contributed to and influenced current realities.
Only by acknowledging the reality and the ways the industry at large has mistreated the “missing masses” can we begin to redress the mistakes of the past and bring them back into “the fold” to the benefit of the platform and community.
Why did SMBs not stay current on the latest hardware and operating system, and did not “modernize” (events/factors impacting adoption)
This is likely the most difficult subject to understand, as conventional wisdom and the current assessment by the general (known) market is that it is caused by resistance to change, stinginess, and ignorance. That perspective, which is prevalent and pervasive, alienates us (in the known market segment) from the very people we need to take hands with and assist, to the benefit of the platform's future, our applications, and the community globally.
The prevailing attitude in our community is to belittle developers on older hardware and operating system releases if they dare to raise their heads above the parapet and ask for help. The discussion invariably becomes a lecture about nomenclature, poor skills, being stuck in the past (ignorant), being resistant to better, more modern ways, and being poor developers. All this, while these very same people keep the lights on, the systems running, and food on the table for all employees, often at an enormous cost to themselves and their families. Destructive criticism in that lived reality is doomed to failure and the destruction of relationships.
It is critical for all parties to acknowledge this reality, as only by owning up to our contribution to the sad state of affairs and changing our ways can we begin to engage effectively with the missing masses and help them become part of a vibrant community again. There are many benefits for all in that.
A fact that most, if not all, people outside of the SMB market grapple with is that it is not unusual for SMB users to retain their machines for many more years than the usual 3 – 5 year replacement or upgrade cycle accepted as the norm in the “known” market, as machine performance as a bottleneck is exceptionally rare in the SMB community. Since the introduction of the RISC-based Power processors, it is almost unheard of: the smallest, least powerful processor today delivers performance orders of magnitude better than the most powerful processors of the 1980s and 1990s.
By way of a simple comparison to demonstrate what happened to processor performance and efficiencies, a middle-of-the-range 9404 model B20 (small clients) in 1989 had a derived CPW rating of 5,1 (CPW as a processor performance measurement did not yet exist at that time) and a middle-of-the-range 9406 model B45 (medium clients) in 1990 had a derived CPW rating of 6,8. Contrast this with the smallest Power11 server today, which is the IBM Power S1122 (9824-22A), an entry-level 2-socket scale-out model supporting 2 x 4-core processors. This system is ideal for IBM i OLTP workloads; per-core CPW is ~29,550 for a single core, but the minimum shippable system from IBM is an 8-core system at 236,400 CPW.
No doubt, workload demands and complexity have increased over the decades, but not nearly as fast as processor performance capabilities have exploded. It is estimated that 80 percent of SMBs today operate comfortably within the 500-5,000 CPW processing capacity requirement range, demonstrating that even the smallest processor today is far too powerful for their needs, leading to a perception of massive potential waste or unused capacity.
SMBs are notoriously careful with their investments and ROI expectations and are exceedingly conservative in managing and extracting maximum value from acquisitions. They have to, or they would not have survived in a highly competitive business environment where dominant competitors strive to eliminate competition.
As a result, if no compelling business justification for additional processing capacity or new operating system, database, or programming language features was required, and the SMB remained competitive in their market segment, they simply would not upgrade their system. Even more so when their original supplier no longer works with them and does not guide them on how to extract maximum benefit, contrary to the spirit of the original partnership established in the 1980s.
Combined with the remarkable reliability and availability of the system, what possible compelling business demand would justify investing in new hardware and software, compared to investing in, say, a new production, assembly, or distribution line? One is seen as an expense supporting business operations, while the other is seen as a source of new revenue streams.
The preceding paragraphs on processor capability, however, are the least of the challenges we need to address with unambiguous solutions and positioning. In our assessment, 5 major developments in the early to mid 1990s onwards added dramatically to the challenge confronting SMBs:
- removal of SE support from SMB installations (reference my earlier explanation on the remarkable support IBM used to provide),
- change in direct engagement to an indirect engagement model,
- Introduction of the ILE compiler,
- the introduction and continued evolution of the new SQE DB2 for i database engine, and
- The dramatic changes in the developer tools (IDEs) since 2001 have demanded a completely different skill set.
It is paramount to acknowledge what a near insurmountable obstacle the combination of the preceding facts created, considering the prevailing culture (study that section carefully) within SMB installations, combined with suddenly being forced to research and educate themselves in their own time (which they never had), of three highly technical and complex software engineering developments on the platform that completely changed (dramatic improvements) the way in which software could (and should) be developed. Especially if you could no longer rely on your trusted SE to guide and assist you in delivering the optimal solution for your environment.
The introduction of the ILE compiler and the SQE DB2 for i database engine on the platform essentially “broke” all applications from an architectural standpoint and was both almost as significant as the original announcement of the platform or the CISC-to-RISC processor transition. Yet, thanks to IBM Rochester's remarkable architectural prowess and commitment to protecting its users, all applications remained operational and fully functional. This left the user community, especially SMBs, largely isolated and unable to benefit from these two major enhancements. It was literally “a bridge too far.”
However, from that moment (mid-1990s) onwards, technical debt began to accrue at an alarming rate. Both these remarkable advances required the applications to be re-architected to exploit the inherent capabilities. With no local SE to assist and guide, and IBM Rochester navigating troubled corporate waters, the usually remarkable support and tooling from IBM Rochester for such a major endeavour were lacking. They tried their best, but if you continuously fret over your own future and career, the results will naturally be dubious.
From that event onward, the chasm between the “knowns” and “unknowns” began to open, worsen, and go into overdrive in the early 2000s. From then onward, amid internal turmoil at IBM, the SMB faithful were largely ignored as IBM staff valiantly tried to preserve the most important elements of their long-term strategy. They had no choice but to focus on clients who ordered vast quantities of hardware and services every year, thereby justifying their continued employment. SMB clients, with a culture of perhaps ordering additional hardware every 5–7 years, were no longer at the forefront of their considerations.
The IDE issue is a particularly painful and unfortunate subject, as it certainly established the perception in the SMB community that IBM Rochester now only cared for the large users and was chasing revenue at all costs, even though they (the SMB masses) had already funded the original Application Development Tools (ADTS). The learning curve for the original graphical IDE, WDSc, announced in 2001, was exceedingly steep, the machine (PC) requirements significant, and the initial releases still poor, meaning that developers had to use both WDSc (which later became RDi) and ADTS to maintain their applications. On top of that, IBM charged for the new IDE, while the SMB developers always maintained they had already paid for their development tools. The price tag was steep and exceptionally difficult, if not impossible, for SMB developers to justify, and the learning curve was steep, leading to an initial drop in productivity until familiarity could be established. To add insult to injury, in the rest of the software industry, development tools were offered free, and the community was aware of that.
It is important to acknowledge that the preceding factors and changes were not limited to IBM alone; very similar forces triggered massive consolidation and terminations across the distribution and ISV channels as well, driven by global economic events and the contraction of the installed base.
All these factors combined gradually created a situation whereby an almost parallel universe developed supporting the “missing masses” or SMB faithful, and a haphazard, informal supply “chain” for want of a better word developed, with experienced individuals rendering services to a few installations in their vicinity, sourcing second-hand hardware, third-party maintenance organizations, eBay and similar sites offering parts and even complete systems. However, as this is a largely informal support channel, significant risks exist, but SMB installations have always been creative in keeping their systems running. With a system so reliable and dependable, it is utterly doable for an extended time.
The reply to the question “Playing devil's advocate: if they won't even pay for hardware maintenance or keep their OS current, will they care enough about modernizing their apps…?” is therefore that:
- They care deeply for their systems but had to find alternative ways to keep them operational, as the formal distribution and support channel was not interested in investing the hard yards to partner with them and assist and guide them for an extended period (years) to bring their systems and applications into the new millennium, while being extremely cost-conscious and especially ROI conscious.
We believe, given half a chance, with compelling business justification, a clear, sensible, and pragmatic roadmap, education, guidance, the right tooling and blueprint, and a process to mimic the support they originally received from IBM, the average SMB will leap at the opportunity to remove the shackles from their heritage systems and applications.
What is unique about the culture in the SMB installations?
The second-most difficult concept to understand is likely the differences in culture between SMB installations and large or corporate users of the system. It is, however, critical that we carefully consider this and define valid approaches to effectively engage with the “missing masses.”
Something quite unusual is that most developers in the SMB space learned their trade “on the job,” using a sprinkling of original ISV applications (usually core financials) as examples and the coding approaches and templates from those applications to craft their own coding standards and templates. These templates and the software development approach permeated the entire SMB community to such an extent that we believe the “custom” or in-house-developed applications within SMBs significantly exceed the 73% figure reported in the most recent Fortra annual survey (page 12).
The IT teams in SMBs are usually very small (literally less than a handful), multi-skilled individuals doing everything they can under immense pressure. As a result of the remarkable level of integration IBM Rochester facilitated, they strive to keep their technology stack as lean as possible. They cannot afford to chase after every latest fad or technological innovation, as their focus is on delivering business functionality.
The team cannot afford to fall into analysis paralysis when choosing tools, approaches, and solutions, given the enormous demands on their time. They usually define their core requirements, consider available choices in the vendor community, and are forced to make rapid decisions because they cannot afford wasted effort differentiating between an 80% or 90% solution. The choice is dictated by the solution that delivers the greatest benefit to their users, the fastest.
Additionally, SMB developers are usually far better business analysts than programmers. If faced with a choice between an intricate low-level programming technique and an additional business feature that improves business functionality or user efficiency, the business functionality consideration will win every time. The objective and passion are to produce business results, not to be the most gifted MI programmer. The average SMB developer is a uniquely versatile craftsman, with an exceptionally intimate knowledge of the business.
They know the tools they have been using well, as attested by the results their installations achieve, not by how current their programming techniques are. Due to the demands on their time and available resources, they seldom have the luxury of attending conferences or user group meetings, as they seldom can bring anything back for free from such events to the immediate benefit of their employers. In years gone by, before the culture shifted so dramatically, their installations usually benefited substantially immediately.
The chasm between their use of the system and tools, compared to their counterparts in large installations, is due to events since the early mid 1990s, and to the fact that they have to cover all disciplines in running their applications and systems, whereas teams of people do that in large installations. They are specialist generalists, rather than specialist one- or two-discipline developers. Developers in large installations usually become very good at one or two subject areas.
Due to the team's size, SMB developers are continuously under enormous pressure and often make even greater sacrifices. Their families pay the brunt of that cost. Like all professionals, they would love to stay on top of their game and adopt the latest approaches, but the continuous churn to keep their heritage going and the massive chasm between where their systems and applications are and what IBM and the “known” market dictates create extreme tensions.
As a team, they have to focus on quick results, simplicity, the leanest possible solution, and above all, integration. As Timothy Prickett Morgan recently remarked, “One of the secrets to the success and longevity of the OS/400 and IBM i platform is integration for the sake of simplicity. That may be two closely interrelated secrets, now that we think about it, but the important thing is that for any product or service to take off among the IBM i faithful, it has to integrate well with the platform and it has to mask complexity even when an underlying technology might be quite hairy.”
It is important that we contrast the preceding characteristics of the SMB team with those of large or corporate installations. The people in the “known” market segment cannot fathom the environment in which SMBs have responded to and delivered exemplary solutions (from a functionality standpoint) remarkably well.
What is the opportunity and the potential size of the opportunity?
We strongly advise that you source and read the compelling “The Long Tail: Why the Future of Business is Selling Less of More” by Chris Anderson as additional background. It provides a compelling backstory for the opportunity to bring a fair percentage of the “unknowns” back into the formal user community.
Although we believe the number of clients worldwide remains closer to IBM’s published 2016 figure, we will use the 120,000 figure that the remaining industry analyst is referencing. Using that figure and extrapolating the number of machines still in production, we believe the number is somewhere north of 360 000. Nobody knows for sure, given the nature of the “parallel universe” that has gradually evolved since the mid-1990s.
Considering that IBM and the formal vendor community generate their significant business results from approximately 20% clients and installations globally, the remaining 80% makes for a compelling target market, especially since most of them have remained on IBM i because of the value proposition it offers and their competitive advantage that is encased or encapsulated within their business applications. Should they be presented with a compelling business justification and a pragmatic, realistic, and achievable objective, we believe a significant percentage will leap at the opportunity to resolve all the business risks they have attempted to manage and contain over the last 2 to 3 decades. Their biggest current risk is the rapid rate at which the IT staff responsible for these systems is retiring or approaching retirement, as it is primarily Baby Boomers and Gen Xers who developed and implemented these systems. This risk, however, may also be the perfect catalyst, as the status quo is no longer a viable option, and the expiry date to resolve and remove the inhibitors is within the next few years, probably about three years.
Realistically, we believe the potential opportunity to be somewhere between 19,200 and 48,000 installations that may benefit significantly by removing the shackles that have inhibited their growth or adoption of the latest technological advances.
Initially, we believe we should aim for SMBs with US$75 million in annual turnover while we refine the business justification, as these companies will likely have the financial reserves to reinvest in their IT systems if suitable benefits can be demonstrated rapidly. However, it is critical that the expectations from the executive team are set correctly. Two to three decades' worth of neglect, combined with the rapid pace of technological advancement, cannot be corrected overnight.
Fundamental considerations
As a group, representing and largely influenced by the “known” market perspectives, we need to acknowledge our collective contribution to the SMB faithful’s plight. Also, ALL our heritage applications have been broken from an architectural perspective since the mid-1990s. The fact that our applications continued to run is a testament to the remarkable platform IBM Rochester developed, rather than to our own abilities.
The applications need to be gradually completely re-architected, fully exploiting the ILE programming model, separation of concerns (MVC or MVVM), and the DB2 for i database engine. This is foundational. Anything else is short-term tactical moves.
It is also paramount to understand the potential implications of pursuing short-term tactical solutions driven by business pressures, such as using screen-scraping technology or exposing heritage functionality through microservices or APIs. Doing so can set technical debt in stone and likely lead to double maintenance, eventually grinding productivity and progress to a standstill. Sadly, vendors in that space are less than completely honest about the long-term implications of believing the challenge has been permanently met.
Also, expressing the old solution in modern syntax, be that RPG or ANY other language, without gradually re-architecting the solution will eventually result in a total, unmaintainable, and unmitigated disaster. Automating that translation to modern syntax or another language will cause even more severe long-term consequences. This is especially true for Synon 2E (CA2E) applications.
We also need to be cognisant that everyone in the market is on the “modernization” bandwagon, as it is one of the most pressing business challenges facing all IT systems, especially with the rapid advances in cognitive computing (read “AI”). Vendors on the fringes often claim to be “modernization” providers, as that is where the C-Suite’s focus is and where money is to be made…
What are the barriers to successfully engaging with the “hidden masses”?
There are a number of significant challenges confronting us, as anything we do will certainly be met with much cynicism due to decades of neglect, belittling, and negative sentiments about how SMBs ended up in their current situation. Very little was their own doing, and most was caused by how events unfolded as everyone fought for their survival.
First and foremost, we need a compelling justification of what the SMBs stand to gain by considering our collective offering. The initial installations will be especially sceptical, with good reason, until this initiative can clearly demonstrate dramatic value. We expect them to entrust their future to us, yet the past decades have shown that their previous trust was misplaced.
An even bigger barrier is that making initial contact with the SMB faithful will be difficult, as we gradually reconstruct a database of current contact details for all platform users. The current ALL400S initiative ( https://www.all400s.com/ ) may provide a good starting point, but that is all it is, as none of the companies in that list had a solid reason to confirm their continued use of the platform. Acknowledge they are cynical, as they know they are a captive audience with limited options, and know someone is trying to sell them something. Our motives will be questioned until the results can speak for themselves. We need to acknowledge and prepare ourselves for that.
To demonstrate the scale of the client database challenge, compare the number of companies remaining on the platform quoted by IBM and by industry analysts, and cross-reference that with the number of companies in the ALL400S database, as well as the numbers claimed by companies selling databases of supposed platform users (refer to my earlier quote from such a company).
They (the SMB faithful) are confronted daily with their limited capacity and accumulated technical debt, and they know the clock is ticking as the current developers of their system gradually retire. They need a younger generation to take ownership of the application and the business's future, but the current tooling, older hardware, operating systems, and legacy code structures create an environment that is less than desirable for younger generations.
Modern tooling (especially VS Code for i and “Project Bob”) demands current hardware and operating systems, with systems that are dramatically overpowered for their processing needs, which screams wastage to the SMB faithful. If you use only a fraction of the processing power delivered, you expect to pay commensurately for that capacity, rather than having idle capital tied up in something you don’t need.
None of the preceding barriers is insurmountable, but a cohesive and all-encompassing offering must be developed, providing a realistic, affordable approach to gradually resolve the following inhibiting factors:
- A “no-risk,” non-disruptive roadmap to gradually ease your development team into adopting approaches and coding examples, as they gain confidence with the modern way of developing applications.
- A complete, self-paced curriculum of education materials that facilitates complete skills transfer.
- Weekly recorded workshops in a classroom setting, discussing and demonstrating potential solutions to all participating installations and developer questions, similar to what SMBs expected of their SE in the 1980s and early 1990s.
- Complete adoption of the ILE programming model.
- Complete adoption of DB2 for IBM i, leveraging triggers for all data validations and constraints for all entity dependencies, establishing true data-centricity within the database.
- Complete, integrated error handling between all components. In the modern component-based environment, this is crucial.
- Complete separation of concerns (MVC or, more relevant to our environment, MVVM).
- Complete adoption of a modern IDE.
- Modern Development Skills.
- A simple and efficient way of delivering heritage application functions (5250) rapidly, without double maintenance, to the web, with minimum effort, as a short-term tactical step.
- Modern Power10 or Power11 processing capacity, using the latest stable operating system release. Whether this is on-premises or on-demand cloud capacity is a matter of client preference.
- A pragmatic strategy to prevent a recurrence of the errors of the past, being sensitive to SMB business and cultural realities. SMBs are very different from corporate or very large users and aim to squeeze every ROI benefit from any investment.
All of the above should be offered as a monthly rental offering, payable quarterly in advance. Outright licensing should be possible, but the focus should be on reducing the barrier to entry to be as low and simple as possible.
Why intERPrise?
The question posed by every global installation we (TEMBO) worked with internationally that consistently got tabled since 2008 was this: “What does a modern IBM i application look like?” regardless of the size of the development team at that installation. What was confusing about this question was that it was tough to answer without preconceived ideas about the audience’s subject-matter knowledge and expertise.
Assuming the audience was familiar with the latest software engineering practices and how to apply them effectively within the IBM i architecture was exceptionally dangerous, given the community's disparate, vastly differing development teams. The nature, skills, and capabilities of large corporate development teams and small SMB development teams are dramatically different, as explained earlier.
Once we recognized that the “known” installations were well served and serviced by the vendors focusing on them, and we acknowledged the plight of the faithful, silent “unknown” masses, the lot was cast.
As SMB development teams taught themselves through the examples of the ISV components they acquired as the foundation of their custom application many decades ago, by providing a similar solution and the required materials to assimilate and adopt the approaches, we trust and hope that an environment can be established that fosters excitement, trust, and mutual respect, while providing a gold standard in software engineering as their objective, leveraging all the remarkable, inherent capabilities of IBM i.
Therefore, intERPrise is aimed at the small SMB development teams, providing them with a modern software blueprint, the necessary education, and a non-disruptive roadmap to gradually, as familiarity sets in, adopt and apply the approach and any components to their heritage application, with a working example at their disposal to take apart and reassemble to their heart's content. All components and source code are provided to use as installations see fit, subject only to the terms of the Apache-2.0 license agreement.
It is also for this reason that we chose to provide a foundational ERP application with user enrollment and administration, General Ledger, Accounts Payable, and Accounts Receivable modules, as most custom applications in use at SMBs since the 1980s were built around core financials from one of the ISVs at that time. It is also the component most likely to require a complete rethink and modern implementation, given advances in accounting system design, transaction values and volumes, and real-time, dynamic executive dashboards. Batch processing, day-end, month-end, and year-end processing is no longer acceptable, and nimble, agile, and dynamic adaptation to changing business requirements is a must.
As financial modules are the easiest to implement in any system and can run in parallel with no risk to the company, adopting components as the development team gains confidence and becomes familiar with modern system design and coding practices, it is a natural choice. It allows the development team to experiment with approaches and decide what will work best in their business environment, with absolutely no risk to their production systems.
This environment will facilitate SMB development teams in validating all approaches, coding standards, practices, and templates, and confirming whether they will work for them and what benefits will be realized, in a completely neutral environment.
Most importantly, though, we received clear guidance on 25 July 2018 to deliver intERPrise, with no strings attached, as our final parting contribution to the user community.
As nobody knows for certain whether and how the SMB faithful will respond to our offering, once we have a clear indication of appetite, we can adopt a formal development plan for other components, building on top of the established architecture and development standards.
Additionally, the base ERP offering can be evolved and enhanced by all participants, subject to proper controls, if there is value in that. TEMBO never started with intERPrise with a commercial outcome in mind, as nobody knows if and how the installed base, especially the silent masses, will respond. The benefit we have already received in the maturity of AO is remarkable.
Our motives and what we hope to achieve.
First and foremost, our dream is to establish a gold standard for modern, native IBM i, data-centric, authentic ILE-based applications, completely hosted on IBM i only, that can serve as a blueprint for the SMB-faithful to renovate (modernize) the proud heritage applications that served them so well for decades.
If we can bring some excitement back to the SMB installed base, assist them in truly mastering the ILE programming model, leverage the inherent data-centric capabilities of DB2 for i, and fully adopt separation of concerns (MVC or MVVM as more accurate in our implementation) via JSON payloads delivered to any client, we will be thankful. Especially if they adopt this architecture for gradually renovating their heritage applications.
Naturally, we will be elated if some sales of AO result from people reviewing what AO produced. However, there will be absolutely no code dependencies, and development teams will be able to use all code without any tools beyond standard IBM application development tooling.
If AO receives the recognition it deserves, we will be thankful and glad, as it is the culmination of our entire careers. Every experience spanning four and five decades, respectively, equipped us for this parting gift to a platform we adore and that has served us exceptionally well.
AO is designed to automate and manage all the processes we propose, thereby providing significant potential value and benefits.
Who is the target audience for intERPrise, and what characteristics define them?
The optimal target audience for intERPrise is installations that can be defined as small to medium businesses or SMBs that usually have zero to 5 developers. Zero, meaning that installation contract developers, when they have work that needs to be performed, and don't have permanent development staff. In a nutshell:
- SMB with less than 5 IBM i IT staff.
- SMB with a custom application developed over decades, often based on one or two ISV applications acquired with source code in the 1980s or early 1990s.
- Probably minimal adoption of authentic ILE constructs.
- Still using ADTS (Application Developer Tools such as PDM, SEU, etc.).
- Database defined using DDS and little to no use of SQL beyond very basic queries.
- Developers are better business analysts than programmers, usually knowing the business better than anyone else.
- Initially, SMBs that achieved annual revenue in the US$75 million range in their last reporting period.
What do the hidden masses stand to gain?
- Fully conversant developers on top of the latest software engineering approaches on IBM i, fully exploiting the ILE programming model, DB2 for i, and the remarkable inherent capabilities of IBM i.
- Self-paced instruction and a fully functional example application that can be used, deconstructed, and reassembled as often as the developer wants to experiment, with no risk to production systems.
- Ability to start using VS Code & Project Bob once access to the latest development capacity (at least IBM i V7.5) can be secured.
- Latest hardware with related performance and reliability improvements
- Latest security enhancements
- Latest software architecture
- Access to the latest software development skills
- Eventually, a brand new application will provide a solid foundation for a few more decades.
- Dramatically reduced risk factors.
- Young, dynamic, new generation developers who can take the application forward.
Strategy to engage and inform the “hidden masses.”
Developing this strategy and code repository within the ILE RPG Developers group on LinkedIn gives us unprecedented access to the largest professional developer community on the platform. https://www.linkedin.com/groups/1835406/ . Additionally, we have good relationships with a few other professional groups on LinkedIn, and they may carry our announcements and news once we break radio silence.
We need to acknowledge that, even with more than 16 000 professional members in the ILE RPG Developers community, it probably represents only 10 to 20% of the developers dedicated to the platform. Due to the immense pressure in SMBs to keep the lights on, we believe a significant percentage of developers have little time for social media.
IT Jungle (Alex Woodie) has been very interested in this initiative since we announced it originally. Like most, given the long delay in getting this far, he is likely jilted and sceptical, which is understandable. TechChannel is also keenly interested in our efforts. We suspect that many SMBs are unaware of IT Jungle and TechChannel, or are flying below the radar themselves, having not divulged their names or contact details to these organisations.
Once we have the code Repo ready, we intend to break radio silence on LinkedIn first, with links to the GitHub Repo. We are DV working towards a May 2026 announcement timeframe for the foundational intERPrise components. Those components can be used by ANY IBM i installation and may provide a disruptive IBM i technology stack to deliver native web applications with no additional hardware or software requirements, leveraging standard IBM i functionality. The components delivered in the first Repo will represent Authentication and RBAC components, and are therefore common to any application deployed to the Web.
The Repo will contain two RBAC implementations: a generic one relevant to any installation with the need to deploy functionality to the Web, and a second, more advanced version that is intERPrise specific. The objective is to provide something of truly remarkable value to the entire installed base, so they can use it however they want, subject to the Apache 2.0 license terms.
As soon as we have the code Repo in the public domain and can start measuring real interest, we will begin reconstructing the user database, focusing on SMBs in specific geographies. and specific market segments (say transportation or freight forwarding). This will be very targeted, using one metro with a large user base to develop a blueprint for the process and the best way to successfully engage those users, making them aware of the full offering. We have to limit this initially to one geographic location, to stay nimble and sensitive to what works and what triggers resistance.
The same principle will apply to specific market segments to determine what works best for each.
Informed by what delivers the best results, we will gradually accelerate development of additional geographies and market segments to get the message out across the entire SMB installed base.
We doubt that traditional advertising will ever work, given the disparate user community and the lack of a single platform that provides access to the SMB faithful. As we gain traction, though, we (the initiative) will explore LinkedIn, YouTube, and other platforms to deliver targeted advertising to users.
However, we believe the best way to get the message out will be through word of mouth, especially since many SMBs have established an alternative universe or support structure for themselves by communicating directly between installations in the same geography or market segment. Once they know there is a solution and a pragmatic roadmap that will eventually resolve all their IT challenges, we believe the code Repo will gain traction.
Acknowledgement
The following people deserve special mention for their remarkable contributions, support, and motivation over a very long time, while most people internationally lost interest very quickly. Chris Hird, Mark McDonnall, Mike Moegling, the entire TEMBO Exco, Vijai Garg, THANK YOU! Your patience, motivation, and guiding questions were of enormous value, as we often doubted our own rationality.
Conclusion
We believe, with every fibre of our bodies, that by truly serving the SMB community and providing them with everything they need to overcome more than 3 decades of neglect, we can bring excitement back to the entire community.
Also, position IBM i and RPG as vibrant career opportunities.
What we need from you
Please carefully ponder everything shared here, especially the foundational assumptions, and correlate it with your experience. Please challenge conventional wisdom and prevailing attitudes, especially any “echo chamber” perspectives.
Challenge any unsubstantiated statements or where the presented argument does not hold water.
Please read “The Long Tail,” as it will help you see the opportunity and the hidden masses with fresh eyes.
Highlight any missing perspectives or subjects that require elaboration or substantiating facts or references.
Attempt to place yourself in the shoes of an SMB developer or a C-Suite member, critically asking if the proposed approach will compel you to action. Especially what is missing to bring excitement back to the community and bring ALL platform users back into the formal fold.
We can all benefit from each other, and the SMB staff has much to offer. Their experience in achieving the near-impossible with little promises potential efficiencies for larger installations.
How can this strategy be improved?
Market Research and IBM Strategy
https://static.fortra.com/hs/pdfs/guides/marketplace/ibmi-marketplace-survey-results.pdf - latest 2026 results
https://docslib.org/download/10134500/ibm-i-strategy-and-roadmap
https://www.frontline-consultancy.com/wp-content/uploads/2022/07/IBM-i-strategy-paperBP.pdf
https://youtu.be/eWRxttiRbUc?si=UxU-MLJ3hNkxGJEH – IBM i in 2025 A Strategic Preview
https://www.ibm.com/downloads/documents/us-en/10a99803f42fd846 - IBM i: Integrate
and innovate (Latest version of the original IBM i Strategy Whitepaper)
https://www.tripwire.com/state-of-security/interpreting-key-points-ibm-i-marketplace-survey
https://www.itjungle.com/2026/02/02/skills-displaces-cybersecurity-as-top-concern-for-ibm-i-shops/
Supplementary research , interesting reading and other considerations
“The Long Tail: Why the Future of Business is Selling Less of More” by Chris Anderson
ISBN : 978-1401309664 – https://www.amazon.com/dp/1401309666 also available at https://www.yumpu.com/en/document/view/69763108/download-free-pdf-the-long-tail-by-chris-anderson
All of Mark McDonnall’s musings on LinkedIn. Connect with him at https://www.linkedin.com/in/mark-mcdonnell-911022127/ or access all his musings at https://ibmireference.blogspot.com/p/mark-mcdonnell-musings-page.html
https://www.linkedin.com/feed/update/urn:li:activity:7404420037312335872 ?
https://www.reddit.com/r/IBMi/comments/1kphpt6/what_takes_significantly_more_time_in_ibmi/
https://www.linkedin.com/feed/update/urn:li:activity:7422654267989299201 ?
