Target Audience

The intERPrise open source project has two distinct target audiences in mind, which are essentially worlds apart in terms of software engineering practices. As a result, the biggest challenge this initiative is confronted with, is to provide a mechanism or an approach that will facilitate collaboration and skills transfer on both sides of the audience spectrum.

It is therefore of paramount importance that this initiative successfully straddles the chasm between the “consumers” and contributing developers, successfully engaging, collaborating and implementing intERPrise architectural constructs and conventions.

Consumers of intERPrise

From a “consumer” perspective, the ideal candidate client installation and developers are entities that can best be categorized as genuine SMB (https://www.gartner.com/it-glossary/smbs-small-and-midsize-businesses or https://whatis.techtarget.com/definition/SMB-small-and-medium-sized-business-or-small-and-midsized-business) installations, which remains a significant percentage of all IBM i (and predecessor systems) installations globally. It is an installation with usually less than five developers, often one to two developers and sometimes none (engaging with contract developers when the need arise).

For these installations, their application often defines their business, and the business defines the application, having gradually evolved and matured as the company matured.

Even though the application is critical to the existence of the business, there is continuous pressure on available funds, as most small and medium enterprises experience, with many competing considerations. Usually SMB investments will go towards core business infrastructure investments that have an immediate ROI (read sales and profit) and seldom to perceived “support functions” like applications and systems.

One of the secondary objectives of this initiative is to inform and demonstrate to SMB executives that their applications CAN (and SHOULD) have a DIRECT positive impact on their bottom line. It should also serve as catalyst to genuinely modernize their entire IBM i software asset portfolio.

It is important to acknowledge the tremendous contribution these developers have made to the success of the platform and their employers. Additionally, it should also be acknowledged how much they achieve keeping the “lights on” and their applications functioning, delivering this under exceptionally trying conditions.

Contributing Developers to intERPrise

Most of the early contributors are software engineers who enjoy coding for a living/hobby and continuously testing the boundaries of software engineering approaches. They are most often early adopters of new tools, languages and approaches and always seek to hone and improve their skill. As such, pointer based processing, API’s, software architecture, leveraging ILE, SQL and new IDE’s are second nature to them. They will usually be comfortable developing in several languages and also comfortable with many computing platforms.

Most of these developers will enjoy the perceived “freedom” of descriptive (read long) program names and flexible file schemes for storing their source, using folder structures to keep components logically grouped. The complexity of continuously mapping between actual object names and the originating source, especially where you are managing potentially hundreds or thousands of objects in a production environment is seemingly not a impediment for them.

This issue however highlights the challenge of bridging the gap between two completely different audiences, with entirely different coding objectives.

As a result of the preceding background, it is important for the contributing developers to acknowledge that the published standards and conventions serve as mechanism to attempt to bridge this divide. It does not make sense to develop something, if it won’t be adopted and used by the installed base.

This infers that compromises will have to be found between the initial contributors and the potential adopters, with the primary consideration on the adopters, not developers, as this audience will determine the success or failure of this initiative.

We subscribe to the KISS principle, keeping names and conventions clean, uncluttered and clear. It is of specific importance to acknowledge that even though some of the conventions may seem antiquated, it is not. The conventions adopted here, are adopted because they work consistently, reliably, simply and clearly.

Just because some concepts may seem old, does not mean it is. The conventions and standards adopted are all brand new, even though some of them may seem old, because it is based on principles that has served the platform exceptionally well for 35+ years.