Geoprise Technologies - GM-X

Geoprise R&D Director Tony Marston Receives Multi Corporate LiveWire Global Award 2024/25

admin — Sat, 01 Mar 2025 09:38:04 +0000

LONDON, March 1, 2025 – Geoprise, maker of the GM-X Application Suite, is proud to announce that Corporate LiveWire, a platform which informs business professionals and individuals in the corporate sector around the globe, has awarded its Software Design Service of the Year in the Corporate LiveWire Global Awards to Geoprise R&D Director Tony Marston for the second year in a row.

These accolades build upon the Best Open-Source Rapid Application Development award which Tony received in September 2024 from Innovation in Business, The Developer Awards 2024.

The GM-X Application Suite is an Enterprise Resources Planning (ERP) application that was designed from the ground up as a Web application deployable on public cloud, private cloud, and hybrid infrastructure, or on premises. It comprises 21 integrated subsystems, each with its own database and transactions. This allows customers to economize by paying only for the subsystems they require.

At the heart of the GM-X Application Suite is an award-winning framework called RADICORE which was designed and built by Tony Marston as an Internet application using the PHP language. First released in 2006, RADICORE is supported and published by Radicore Software Limited, a British company founded by Tony Marston in 2005 which joined forces with Geoprise in 2014 to build and market GM-X.

RADICORE is not a clone of any other framework, nor does it use any third-party framework components. Other than including various proven and popular open-source libraries for utility purposes (such as generating PDF documents, emailing, and generating or processing spreadsheets), it is totally 100% unique. Building upon his decades of experience with earlier frameworks and programming languages, Tony specifically engineered RADICORE with Rapid Application Development (RAD) ― low-code methods and no-code tools that allow development cycle times to be measured with a stopwatch instead of a calendar ― in mind. His award-winning approach abstracts all the functionality which is independent of any application so that it runs a Template Method Pattern as the base class software for any application without any modifications. RADICORE also has additional software components which provide a user interface comprising 45 different reusable transaction patterns ― far more than basic Create, Read, Update, and Delete (CRUD) operations ― each implementing its own structure (view), behavior (controller), and content (model).

Business transformation through RAD enables organizations to adapt quickly in response to rapidly evolving market needs, improve customer satisfaction, and gain a competitive edge by driving immediate and significant changes to operations and capabilities. RAD comprises methodologies and tools that enable the cycle time between idea and implementation (sometimes known as “Time to Market” or “TTM”) to be substantially shorter compared to traditional methods. Because the expense of software development is directly proportional to the amount of time taken to design, develop, and test it, then shorter TTM equals lower cost.

RADICORE achieves this objective through its library of transaction patterns, automatic forms navigation, and dynamic generation and re-use of program code including PHP scripts, Web pages in hypertext markup language (HTML), and structured query language (SQL) statements. The RADICORE framework also supplies a Role Based Access Control (RBAC) subsystem which controls access to the entire application by means of a collection of dynamic menus, an Audit Logging subsystem, and an Activity Based Workflow subsystem. As well as being able to run all the application subsystems it also has a Data Dictionary subsystem which can generate the necessary components for new subsystems. These capabilities make it possible for software development and information technology operations (DevOps) productivity to rival or exceed that of the fastest artificial intelligence (AI) using large language models (LLM) without introducing any hallucination risks and the appurtenant need for productivity-eroding code reviews to mitigate hallucination risks.

The roots of RADICORE go back 20 years prior to its first release:

COBOL ― initially running on a Univac mainframe but then on a Data General Eclipse, followed by the HP3000. This is when Tony began creating a personal library of reusable code because no central library was available. He converted this library into a framework in the mid-1980s by adding an RBAC capability to control the running of application components.
UNIFACE running on Microsoft® Windows® connected to a relational database. The aforementioned RBAC system was redeveloped in this language, and it provided more facilities and shorter development times than the original COBOL version.

Before creating the entire RADICORE framework, Tony first built a small prototype application to familiarize himself with the principles of encapsulation, inheritance and polymorphism which are the core tenets of object-oriented programming. Just as UNIFACE treated each table in the database as a separate entity, Tony encapsulated the data and the processing rules for each database table in its own class and moved code segments that were repeated for different tables into an abstract class so that they could be shared by inheritance instead of being duplicated. Because every concrete table class inherits its methods from the same abstract class it means that the code which calls those methods can be used, thanks to polymorphism, with any concrete table class using a unique implementation of dependency injection. Using an abstract class also allows the use of the Template Method Pattern which permits each concrete class to contain its own implementation of various “hook” methods.

Although UNIFACE employs eXtensible Markup Language (XML) and eXtensible Stylesheet Language (XSL), it does not use them to create Web pages. Instead, it follows its legacy procedure which compiles static forms that run on desktop personal computers (PCs). Believing this approach to be unnecessarily complex, inflexible, and incompatible with modern principles of mobile-first adaptive Web application development, Tony introduced a major improvement in his first release of RADICORE which constructs all Web pages as HTML documents on the fly using a series of XSL stylesheets. This requires just one software component to convert the application data into XML, then transform it into HTML using an XSL stylesheet. Instead of requiring separate stylesheets to deal with the different columns on each database table, the RADICORE framework uses just 12 reusable stylesheets which can handle the columns from any database table.

Because building each component in a subsystem follows exactly the same steps, the RADICORE framework automates this procedure through its Data Dictionary subsystem. This follows the UNIFACE Application Model but reverses the procedure by first building the database so that table’s structure can be quickly imported into the Dictionary, then exported into a PHP script which is then loaded into that table’s object when it is instantiated. This means that after creating a database table, the scripts to maintain the contents of that table can be generated without having to write any program code whatsoever ― no PHP, no HTML and no SQL. While the generated code provides all the basic processing to move data from the user interface (UI) to the database and back again, the only thing left for the developer to do is to update the relevant “hook” methods in each concrete table class to provide the custom business logic.

About Geoprise

Geoprise Technologies Corporation was formed in 1999 by a group of software executives with over a century of previous cumulative experience building enterprise resources planning (ERP) and manufacturing operations management systems and implementing them worldwide. The privately held company's mission, then and now, is to create exceptional value for its customers by harnessing the power and economy of information technology to enable lean, world-class industrial operations on a global scale. Today, Geoprise focuses exclusively on delivering its state-of-the-art GM-X ERP solution, which it markets through Geoprise Technologies Licensing, a joint venture with Radicore Software Limited, to businesses operating in North America, Europe, Asia, and the Pacific Rim. Geoprise values integrity by maintaining strict independence, intense commitment to business ethics and profound respect for intellectual property rights. For further information, visit the company's Web site at geoprise.com.

About Radicore

Radicore Software Limited, established in 2005, markets and supports the RADICORE Rapid Application Development (RAD) Toolkit for building enterprise applications which are platform independent, browser independent and database independent. RADICORE is based on a combination of the 3 Tier Architecture and model-view-controller (MVC) Design Pattern and comes with pre-built and reusable components in the data access and presentation layers. The GM-X ERP application is built using the RADICORE framework. For further information, visit the company's Web site at radicore.org.

How To Cut ERP Costs

admin — Wed, 04 Jan 2023 02:49:29 +0000

By: Nelson M. Nones CPIM, Founder, Chairman and President, Geoprise Technologies Corporation

Happy New Year!

With the new year come forecasts that a worldwide recession is likely, with signs of recovery around the corner by the end of 2023. In response, businesses are freezing or cutting spending on everything from marketing and research to information technology (IT).

As the Financial Times reported on New Year’s Day:

The headlong growth of cloud computing has reached a watershed, as increasingly cost-conscious customers and economic pressure combine to dampen one of Big Tech’s hottest growth markets.

The chief technology officer of one large bank complained that the biggest cloud companies had not moved fast enough to reduce fixed charges as the volume of business has soared, despite the greater efficiencies that come from operating at massive scale.

Anyone who is familiar with how most software-as-a-service (SaaS) subscriptions for enterprise resources planning (ERP) software are sold is all too familiar with this problem. According to the latest SaaS survey from KeyBanc Capital Markets, nearly half (41%) of all SaaS providers use seats as their primary pricing metric. Per seat pricing is also known as per user pricing and services are usually sold as annual contracts that typically reflect a 10% discount off quoted monthly rates.

Assuming they don’t cheat by sharing a single User Id between multiple users, the limitation of this pricing model from customers’ perspectives becomes obvious: their total cost increases in direct proportion to the number of users, with no opportunity to gain efficiencies from economies of scale. Sure, they might be able to negotiate bigger discounts when their contracts come up for renewal, but often those larger discounts are only offered for larger and longer-term commitments that would increase instead of freezing or cutting total IT spend.

Other customers are unfortunately stuck with less scrupulous software providers who are belatedly trying to force their customers onto pricier plans. Two days earlier, the Financial Times also reported that Sage, the United Kingdom’s largest listed Big Tech company, has in recent months “pushed customers who had been sold single-payment, long-term licenses to the software on to monthly subscriptions that work out to be more expensive over the long run, by saying they would turn off their licences on security grounds, despite having no specific grounds to do so in their terms and conditions.” We know. Most of our sales leads from the United Kingdom during 2022 came from Sage customers.

At Geoprise, even though we sell our GM-X ERP software on either a subscription or perpetual-use basis―in the cloud, or on premises―we deliver the best value to our customers by completely avoiding per user pricing. Instead, we license GM-X ERP software by server and subsystem. Unlimited users!

If today’s uncertain economic climate means you need to improve information sharing within your enterprise, and reap the benefits of sharing a single version of the truth, without increasing―or even reducing―your IT spending, then now is the time to switch to GM-X ERP, before you’ve added more users that would drive up your switching costs in the future.

Is Blockchain's Capacity Limited To 7 Transactions per Second?

admin — Wed, 08 Aug 2018 22:03:15 +0000

By: Nelson M. Nones CPIM, Founder, Chairman and President, Geoprise Technologies Corporation

I was recently asked to confirm if “the maximum theoretical processing potential of blockchain is 7 transactions per second.”

Claim: Blockchain’s capacity is only seven transactions per second.

Rating:

Origin

Numerous Internet postings and articles state that bitcoin’s capacity is currently seven transactions per second.

Bitcoin is far and away the largest cryptocurrency by market capitalization. It utilizes a blockchain, invented by the creator of bitcoin, which arranges transactions chronologically into blocks not exceeding one megabyte (1 MB, or 1,000,000 bytes) each. Blocks are confirmed by “miners” using a proof-of-work (POW) system which makes it computationally impractical for an attacker to reverse transactions when honest participants control the majority of central processing unit (CPU) power on the bitcoin network.

Currently, the bitcoin protocol targets a ten-minute interval between block confirmations which reflects a tradeoff between confirmation waiting time on the one hand, and waste of POW effort on the other. According to the Bitcoin Wiki:

After a block is mined, it takes time for other miners to find out about it, and until then they are actually competing against the new block instead of adding to it. If someone mines another new block based on the old block chain, the network can only accept one of the two, and all the work that went into the other block gets wasted. For example, if it takes miners 1 minute on average to learn about new blocks, and new blocks come every 10 minutes, then the overall network is wasting about 10% of its work. Lengthening the time between blocks reduces this waste.

The minimum bitcoin transaction size is 166 bytes; however, the Bitcoin Wiki says:

Users can also combine their transactions to make them slightly smaller … multiple users can create a joint transaction with no risk of their funds being stolen. This reduces average transaction size by 10 bytes … Using this technique aggressively results in 156 byte average transactions … A reasonable, conservative, assumption is … that every transaction requires two outputs, including change, and two inputs, consuming change … [giving] us 322 byte transactions .... Actual real-world rates will likely be somewhere between those numbers.

Consequently, if each transaction requires 156 bytes, then a single block can store up to 6,410 transactions (1,000,000 bytes ÷ 156 bytes per transaction), meaning that 6,410 transactions can be confirmed every 10 minutes (600 seconds). That’s 10.7 transactions per second on average. On the other hand, if each transaction requires 322 bytes then a single block can store up to 3,105 transactions and throughput falls to 5.2 transactions per second. Splitting the difference (and taking the integer portion only) works out to 7 transactions per second which “is commonly quoted as a ‘ball-park’ approximation in discussions of the blocksize limit,” according to the Bitcoin Wiki.

So, bitcoin’s maximum theoretical throughput is actually 10.7 transactions per second, not seven.

Bitcoin and blockchain are not the same thing

Moreover, bitcoin is a cryptocurrency whereas blockchain is a system for keeping electronic transaction ledgers. Bitcoin’s capacity is limited by constraints imposed to keep the cryptocurrency efficient yet secure by design; specifically, POW consensus, the ten-minute target interval between block confirmations and the 1 MB maximum block size. These constraints are needed because bitcoin’s ledger is a public, permissionless blockchain which anyone can join, including nefarious as well as honest actors.

Blockchain technology is useful not only for cryptocurrencies, but also in any situation that requires arm’s length parties to exchange information in a way that is permanent, tamper-proof and verifiable. When those parties belong to a private, permissioned blockchain, POW is a useless waste of CPU resources and is therefore not needed at all. As a result, because there is no POW effort to waste, there is no need to enforce any minimum time interval between blocks; network speed becomes the limiting factor.

The maximum block size of the blockchain bundled with the GM-X ERP software is 1 GB (1,000,000,000 bytes). As a result, based on the smallest possible bitcoin transaction size, its maximum theoretical processing potential is 6.4 million transactions per block, which would require no fewer than 80 seconds to transmit over Fast Ethernet (12.5 megabytes per second, or MB/s), equivalent to 80,125 transactions per second – well over 7,000 times bitcoin’s maximum theoretical throughput. Gigabit Ethernet would be ten times faster still.

In reality, our tests reveal throughputs up to 1,000 transactions per second under ideal conditions over a network of mid-range servers. Average conditions are more like 600 transactions per second. That’s anywhere from roughly 50 to 150 times bitcoin’s maximum capacity, and well beyond the capacity required for even the busiest of enterprise applications.

Blockchain for Blockheads

admin — Thu, 05 Jul 2018 15:44:00 +0000

By: Tony Marston, Director, Research & Development, Geoprise Technologies Licensing

Ever since I added blockchain capabilities into an ERP application (refer to Adding Blockchain to an ERP System for details) I have been monitoring the Internet to see how others are dealing with this opportunity, and I am quite amazed at what I have read. Some think that blockchain is nothing but Bitcoin, some don't understand how blockchain can be used outside the cryptocurrency field, some think that a blockchain database will replace the relational database, while others think that blockchain will totally replace an ERP system. This tells me that a lot of people are still in the dark about what blockchain is and how it can be used.

I recently had a conversation with someone from the academic world who thought that integrating blockchain into business applications such as ERP systems would involve nothing more than the transfer of financial data, and that conversation prompted me to write this article in the hope that I can shine a light into the darkness. I shall stick to high level facts and avoid the low level details.

What is blockchain?

Here is the most simple of definitions that excludes any techy buzzwords:

Blockchain is a tamper-proof system for logging messages chronologically. A message sent to one node in a blockchain network will be replicated across all nodes in that network.

Here are some deeper explanations:

A blockchain consists of a two or more nodes in a network. Less than two nodes would not constitute a network and would be pretty useless.
Blockchain software passes messages between nodes. In its most basic form, it does not generate messages nor process them, it just passes them around as if they were sealed packets. Additionally, some blockchains can process messages using logic contained in smart contracts which may be applied to those messages.
Each node has blockchain software and its associated data store, plus an external application (a separate piece of software) which handles the generation and processing of these messages.
When a message is sent to a node by this external application the blockchain software will add that message to its own data store, then send it to all the other nodes in that network who then add it to their copies of the data store.
There is no central copy of the blockchain data or central control of this data. The data store at each node is an exact duplicate of every other node’s data store.
There is some under-the-hood verification processing which causes each message to be authenticated before it is accepted as a valid message.
When a message is received at a node the blockchain software will send it to the external application which processes it as it sees fit.
The data store at each node is tamper-proof as it allows messages to be written and read, but never updated or deleted. This data store is actually a chain of blocks (hence the name ‘blockchain’) where each block of data has a unique key derived from the transactions it contains, and also the unique key of its predecessor on the chain. For this reason, new blocks can only ever be added to the end of the chain.

Aren’t Bitcoin and blockchain the same thing?

No. Bitcoin is an implementation of blockchain, but it is not the only implementation. It would be like saying “chalk is a rock, therefore all rocks are chalk”. Bitcoin, and all other cryptocurrencies, are distinguished by the contents of the messages that they pass between nodes, such as “Take X amount of funds from account Y and put it into account Z”.

There may be other implementations out there, but their capabilities will be limited by the structure of the messages that they send and receive.

What are the main types of blockchain?

Blockchains fall into two major categories:

Public, permissionless and untrusted
Anyone can join without the need for an invitation and can send and receive messages immediately. The lack of trust requires that each message goes through a complex and expensive validation process. For Bitcoin and many other cryptocurrencies, validation or mining uses a proof of work protocol. Cryptocurrencies such as Bitcoin are prime examples of this type of blockchain.
Private, permissioned and trusted
An organization creates a blockchain and invites other organizations to join that chain so that they can exchange information in the form of electronic documents. After joining they are given a set of permissions, such as being able to read messages but not send them. It is not possible for uninvited or unauthorized parties to break into the blockchain and read messages or send messages of their own. Due to these access restrictions the method of validating or ‘mining’ each new block can be far less expensive and time-consuming than a proof of work protocol. The product provided by MultiChain is an example of this type of blockchain.

Can blockchain be used for more than financial transactions?

Most certainly. A lot of people read the term distributed ledger in the description of blockchain and automatically associate the word “ledger” with an accounting system, which then leads them to believe that blockchain can only be used by accounting or financial systems. The correct term should be “distributed message store” as each node maintains its own copy of every message sent across that blockchain.

Notice that I did not use the term distributed database as the data store at each node is nowhere as sophisticated as a fully-fledged relational database (RDBMS). All it does is store packets of information without knowing the contents of each package.

Will a blockchain database replace a relational database?

Definitely not. A relational database holds data which is arranged into tables and columns with primary keys, unique keys, indexes and relationships. Its associated application allows particular pieces of information to be inserted, viewed and modified in sophisticated ways. A blockchain data store has no structure apart from a chain of blocks each of which holds a message. Each message holds a packet of data, but the structure of that data is unknown to the blockchain.

Will blockchain replace ERP applications?

Definitely not. ERP applications will continue to exist either with or without blockchain technology. However, if an organization wishes to exchange information with other organizations it can utilize a blockchain in order to perform this exchange in a more secure manner. It can create a private blockchain, invite specific organizations to become nodes, then exchange information with those nodes sure in the knowledge that no-one can break into that blockchain and either read private messages or send bad messages of their own.

The type of information which can be exchanged is unlimited. The MultiChain software allows messages of up to 64MB in size with no particular format, which means that I can send whatever data I want in whatever format I want. I can send text files or I can send binary files such as images, videos, spreadsheets or PDF documents. The GM-X ERP application has a relational database containing hundreds of tables coupled with thousands of Web forms which allow an enormous volume and variety of data to be input, maintained and viewed. Each discrete set of data can be considered as an electronic document where each document, be it a purchase order, sales order, shipment, invoice or inventory item, consists of data which is held in one or more records in one or more tables in that relational database. A relational database is infinitely customizable, therefore the number and type of electronic document that it may hold is also infinite.

The blockchain data store, on the other hand, is not infinitely customizable and it can only deal with things called messages. It has no concept of columns, tables and relationships, just packets of information known as messages. It is up to the external application to extract the data for a particular document, such as ‘Purchase Order #27’ or ‘Invoice #301’ or ‘Shipment #1024’, put that data into a single message, then send that message to the local blockchain software which will then send it to all the other nodes in the network.

If the message does not have a fixed structure then how can the receiving node possibly process it? The structure of each message is not known to the blockchain software, but it is (or should be) known to the external software which both constructs and deconstructs each message. The trick is to use a message format which can preserve the structure of the data as it resides in the application database with its tables, columns and relationships, so that when the data is deconstructed by the receiving node it puts that data into the correct columns of the correct tables in its own database. Fortunately such a format has existed for decades, and it is called XML. Although each XML document is a file containing human-readable text, it is possible to embed binary data into this text using a method of binary-to-text encoding. It is therefore possible for an XML document to contain an image as well as metadata which describes that image. That image could be a picture of an item, or a document that contains someone's signature. The possibilities are endless.

References

Adding Blockchain to an ERP System

admin — Fri, 16 Feb 2018 09:33:37 +0000

Pictured above: a new block is added to a venerable structure with the help of a framework

By: Tony Marston, Director, Research & Development, Geoprise Technologies Licensing

GM-X is an enterprise resources planning (ERP) system which was first created in January 2007 and went live at the first customer in June 2008. It was designed from the ground up as a Web application comprising a group of interconnected subsystems, and was developed using the RADICORE framework which I built in 2002 and published in 2006. GM-X has been continually enhanced and new subsystems added since its debut. Today it has 17 subsystems.

Each subsystem has its own database and its own collection of tasks (user transactions). Currently there are 389 tables, 759 relationships, and over 3,000 tasks.

We recently added a new GM-X subsystem for Blockchain management, and how this came about is the subject of this article.

In mid-October 2017, Nelson Nones, the Founder of Geoprise, contacted me and asked, “What do you know about blockchains?” “Nothing” I replied. He then described an idea which he’d been mulling over for some while. His idea began to seem more plausible after he discovered a product called MultiChain which is able to send large volumes of data between nodes on a blockchain, not just financial transactions as is the case with Bitcoin. This appeared to be possible using MultiChain data streams.

Over the next few weeks we discussed what MultiChain could do and how we could use it in our ERP application. We recognized straight away that using it in a stand-alone application would be a waste of time. Any blockchain requires a network of at least two or more nodes, so we needed a use case in which many organizations need to share information with one another. Nelson immediately brought up a use case which GM-X currently addresses for a major client of ours who procures products from a network of suppliers. This currently has the following steps:

The Buyer constructs a request for quotation (RFQ) and sends it to eligible Sellers.
Each Seller examines the RFQ and, if interested in the business, prepares a Quote which is then sent back to the Buyer.
The Buyer examines the various Quotes submitted by Sellers, chooses one of them, and then raises and sends a Purchase Order (PO) to the winning Seller.
The Seller fulfils the order and sends an advance shipment notice (ASN) to the Buyer.
The Buyer receives the shipment, matches it with the ASN and books it into inventory.

Long ago this communication was done by sending letters back and forth in the post (later, emails), but is most commonly handled nowadays by the Buyer setting up a Supplier Portal Web site which each Seller can log into to transact with that Buyer. But such a system has two disadvantages. First, on top of their own ERP system most Sellers need to learn and use many different Supplier Portals, one for each customer, which often requires double entry of transactions. Second, the Supplier Portal is available over the public Internet, and although each Seller has its own unique login it is well known that any Web site which is accessible by the public can be attacked and infiltrated by people with nefarious intentions.

So how can a blockchain solve these problems? For starters, it eliminates double entries by connecting the Sellers’ and Buyer’s ERP systems directly. This is conceptually similar to old-fashioned electronic data interchange (EDI) but much simpler, faster and less expensive to implement. It is also far more secure than EDI or the Internet:

All the ERP systems remain safe and secure behind their respective organizations’ internal firewalls.
Blockchains are not accessible via HTTP or HTTPS ports and are completely private.
No one can join the blockchain at will. They must be specifically invited.
When the invitation is accepted a new node is added to the network and its credentials are shared with all the other nodes.
When a node publishes a message, it is first validated by all the other nodes before being either confirmed or rejected. Using MultiChain, the message can be a block of data up to 64 megabytes (MB) in size.
Confirmed messages are then sent to every other node on the network, and then added to each node’s copy of the entire blockchain.

Once a message has been added to the blockchain it cannot be amended, so the copy of the blockchain database at each node holds a complete audit trail of every message sent. This makes the data permanent, tamper-proof and verifiable, and eliminates the reconciliation burden for trading partners.

There now follows a list of questions we asked ourselves in order to identify the various points which need to be addressed in our solution.

How could we utilize a blockchain in GM-X?

Although each blockchain maintains its own database of all messages which are sent, this is not a relational database which can be queried using SQL statements. We decided that each node would have its own local copy of GM-X and its relational database(s), and would only use the blockchain when data from that node needs to be sent to other nodes. Upon receipt of such a message each node would extract the message and copy its contents to its own copy of the GM-X database. Some people have suggested that the blockchain database may remove the need for a relational database, but the relational database maintains the current picture while the blockchain maintains a history of changes which result in the current picture.

How could we send data across the blockchain?

For data, each message can be either plain text or binary so the possible formats can be quite varied. Having used several different formats over my long career I chose eXtensible Markup Language (XML), mainly because I have used it extensively since 2002, both in the RADICORE framework and GM-X Web services integration. A series of functions already existed which could take data out of one or more records in one or more database tables, put that data into an XML document before it is sent, extract each table’s data from the XML document after it is received, and finally apply it to the database at the receiving end. Although XML documents can be quite large, as plain text files they can easily be zipped to make them smaller.

GM-X also manages documents and other multimedia content which is stored in files (for example, PDFs) instead of tables and records in a database. For these, the file contents will be placed in the XML document along with its metadata.

How could we ensure that only selected nodes could read a particular message?

As noted earlier, every node in a blockchain receives a copy of every message. This means that every node can read every message, which is a problem whenever a message is private and confidential. Fortunately, MultiChain provides a mechanism for protecting confidentiality which ensures that each message can only be read by authorized nodes. This uses two additional data streams, one (“public keys”) to hold each authorized node’s public key, and the other (“access”) holding the password for a particular message. There is a separate entry on the “access” stream for each combination of recipient node and message. Each of these entries is encrypted with the receiving node’s public key so it can only be decrypted with that node’s private key. Private keys are NEVER published on the blockchain (or anywhere else for that matter) so confidentiality is assured.

How could we know when to send data over the blockchain?

Changes to the database are made using a SQL query containing an insert, update or delete operation on a table. It is not necessary to send every database change over the blockchain network, so what’s needed is a signal which means, “When an insert, update or delete operation is performed on table X then send a blockchain message”.

Instead of inserting code into individual application components to identify when a message needs to be sent and what it should contain, we decided instead to build a separate Blockchain Trigger class which the RADICORE framework could automatically examine whenever an insert, update or delete operation is performed. This allows us to configure the signals which cause blockchain message to be sent, without amending any application code.

How could we know when to send data from related tables as well as the target table?

In some cases, like simple lookup tables, it is only necessary to send data from a single table across the blockchain network. Most of the time, however, the data is spread across several related tables whose contents are maintained by several other tasks, so we needed a mechanism to identify which additional tables to include in the blockchain message, even if they were not amended during the same task.

We decided to build a Related Tables class associated with the Blockchain Trigger class which identifies all the additional tables (if any) required for the data extract.

If related tables are involved, how could we delay the blockchain message until the collection of data is complete?

An entity such as an RFQ is not restricted to a single record on a single table. Each RFQ has one or more line items, and each of those line items has a foreign key to a record in the Product table which needs to be included as well. In situations like these the message shouldn’t be sent until the entire collection is complete.

In such cases the relevant “header” table in the GM-X application always has a status which starts off as “Pending” and can progress through any number of other states such as “Approved”, “Sent” and so on. We therefore decided to include a mechanism which postpones the sending of messages until the specified status is attained. This type of trigger isn’t fired with an insert or delete operation, only an update.

How could we identify the blockchain address for each node in the blockchain?

Each node in the blockchain is identified by a 38-character address. Each node is also a separate organization, so it has its own entry on the Organisation table of the GM-X Party database. Each party, in turn, can have any number of Contact Mechanisms of different types representing postal addresses, telephone numbers and email addresses, so we decided to add a new type which identifies blockchain addresses.

How could we identify which nodes should receive the key to unlock each message?

It is rare to want to send a message to every node on the blockchain, so for each message we needed a mechanism to identify the list of authorized recipients. Where GM-X already had a table identifying a list of valid parties, we amended it to hold each party’s blockchain address. Otherwise we had to create new tables for these data, and make the application aware of them, but this was relatively painless using the RADICORE framework.

How could we ensure that data which uses technical keys generated at one node does not conflict with similar data generated by other nodes?

Each node in the blockchain has its own copy of the GM-X application and database(s), with certain tables having primary keys which are supplied from running number sequences. These are known as technical or surrogate keys. As a result, it is possible for different nodes to send messages having conflicting primary keys. For example, when different Sellers independently generate the same quote number for different Quotes, how is it possible to avoid a collision at the Buyer’s application?

Geoprise was already well-versed in standards, such as GS1, for assigning globally unique identifiers to a wide variety of business objects. All these standards incorporate a globally unique company prefix, so we decided to change our primary keys from a simple 10 digit running sequence number to a 38-digit number which has two parts—a leading 12-digit company prefix followed by a 28-digit running sequence number. Why 38 digits? If we have to change the database then go straight to the biggest number available and so avoid having to increase it again at some point in the future.

After analyzing the various points which our solution needed to address, next came the tricky part—actually implementing a solution as Proof of Concept (PoC).

Starting late November 2017, I downloaded the MultiChain software and installed it on two workstations connected to the same local area network (LAN). I also downloaded the MultiChain Web Demo which is written in PHP, the same language as GM-X. This gave me valuable information on how to use the various JSON-RPC API calls which allow the GM-X application to communicate with MultiChain. My next step was to create two new PHP scripts—one acting as the client to send messages out, and another acting as the server to receive messages at the other end. I did this to test the code dealing with public keys and access streams which is responsible for encrypting and decrypting messages. This involved using the PHP OpenSSL and Bzip2 extensions. I used these two scripts to send an encrypted message from one workstation, then show the decrypted message on the other. At this point each message was constructed manually as I had yet to write the code to extract data from the GM-X database.

Having successfully completed the PoC, we decided to develop a working prototype using three GM-X servers. At least three servers were needed in order to demonstrate sending messages to all nodes as well as a selected node. The goals were to:

Send changes to a single table;
Send changes to a group of related tables; and
Send a disk file along with data from a database table.

My first step was to build the Blockchain Trigger and Related Tables classes as well as the tasks to maintain them.

This is what the Update Blockchain Trigger task looks like:

In this example, a blockchain trigger has been set up for the order_header table with reference to the Alias order_header_p which is for purchase orders.

The Trigger Column and Trigger Value entries work together as follows:

If both are empty the Blockchain Trigger will be fired on every insert, update and delete affecting Table Id;
Otherwise it will only be fired on an update, when the Trigger Column contains the Trigger Value (‘Sent to Supplier,’ in this example).

The Distribution Table entry must be empty unless ‘Database table’ is selected from the Distribution Type dropdown, in which case the Distribution Table is either the Table Id, or a table which is directly related to the Table Id.

This is what the Update Related Table task looks like:

Here the term “Node Id” doesn’t refer to nodes (addresses) within a blockchain. It is the node in a tree structure where a senior node can have any number of child nodes in a hierarchical arrangement.

The validation rules for this table are made easy simply because of the way in which the application components are arranged, which in turn is determined by the RADICORE framework. Every GM-X subsystem has a Subsystem Directory as well as a database comprising a set of tables, each having a unique Table Id. Each table in the subsystem’s database has its own class. In some cases, a table class may have several subclasses, each having a unique Alias such as order_header_p for purchase orders (illustrated above), or order_header_s for sales orders.

When a table class or subclass is instantiated into an object it provides the following information:

Field specifications for every column in that table.
Options, if a dropdown list is specified for the field.
Child (junior) tables, identifying the Table Id, Alias (if any) and the Column names which link the two tables.
Parent (senior) tables, also identifying the Table Id, Alias (if any) and the Column names which link the two tables.

This means, for example, that the dropdown list of tables within a subsystem can be populated as soon as the user identifies a Subsystem Directory. Likewise, as soon as the user identifies a table, the dropdown list of Trigger Column values is populated (but may be left empty); and the dropdown list of Trigger Values is populated as soon as the user identifies a Trigger Column. If the ‘Database table’ option is selected from the Distribution Type dropdown, then the Distribution Table dropdown is populated only with tables that have a Contact Mechanism column representing blockchain addresses.

This design makes it possible to construct a hierarchy of related tables which are to be extracted similar to what is illustrated below:

Note here that a Party may be either an Organization or a Person, so only one of these child tables will actually contain data. This is an implementation of Silverston's Universal Data Model for parties.

This takes care of identifying which tables will be the subject of data extraction when a Blockchain Trigger is fired, but the next step is to actually fire the trigger when the relevant table is modified. Again, the RADICORE framework made this process surprisingly easy:

Each table in the database has its own table class, which may have subclasses.
The table class and any subclasses are specializations of a single abstract table class, and inherit methods from the abstract table class which perform the insert, update and delete operations.

It was therefore easy to amend the abstract table class to call a new function at the end of each of those methods to check if a trigger could be fired. The function is passed the following parameters:

The method name (‘insert’, ‘update’ or ‘delete’).
The current Table Id.
The Alias name (if applicable).
The current data for this table in an associative array.

Using this information, it is straightforward to perform a lookup on the Blockchain Trigger table to see if it contains a record which matches the current information. If it does then the following data is stored in a global variable:

The Trigger Id.
The method name.
The primary key of the affected record.

Note that the trigger is not actually fired at this point as the operation is within a database transaction. If there is a failure down the line then the transaction is rolled back and the trigger never fired. It is only when the transaction is eventually committed that the trigger is actually fired.

blockchain_send.php

I had originally thought I could execute the necessary code as part of the online transaction but eventually decided to launch a background task instead as this avoids any delay in processing the online task. I therefore extended the code I had built earlier for the PoC, to read the Blockchain Trigger table as well as the application table that was just modified. As it is passed the primary key of the affected record it knows which one to read. It then starts building the XML document which will be published on the blockchain using the following format:

The method is either ‘insert’, ‘update’ or ‘delete’ and table is either the Table Id or its Alias (if applicable). Then follows an element for each column in that record with its value.

If that table has any related tables which should be included in the extract it will also contain one or both of the following elements:

Note that each parent_tables or child_tables element can contain any number of records from any number of tables. Each of those records can, in turn, contain their own collections of parent and child records. This is a fully recursive process, so it processes all the Related Tables until there is nothing left.

For delete operations, there is no need to supply any data other than the primary key of the trigger table. Any cascade deletes will automatically be performed when the message is processed at the receiving node.

If any record refers to a file then its contents are inserted into the XML document after being base64 encoded.

blockchain_receive.php

The last step was to execute a script at the receiving node in order to extract a message and process its contents against the local GM-X database. MultiChain provides a mechanism called walletnotify to run an external program upon receipt of a message. I created a new script called blockchain_receive.php by extending the code I had built earlier for the PoC.

This script does not need to use the Blockchain Trigger class because everything it needs is contained within the XML document. The root node identifies both the starting table and the method, so it is a simple process to navigate through the XML document and process each record one at a time. The table value identifies which table class needs to be instantiated into an object, then that table’s data is passed to that object using the specified method.

For insert and update operations, a special “insert or update” method is actually used which will check if a record with that primary key exists before performing the insert or update operation as appropriate.

Note also that if a record contains any entries in parent_tables then these will be processed before the record itself. Any child_tables entries will be processed afterwards before moving on to the next record in the XML document.

After completing the coding and testing I then uploaded everything to the GM-X servers, and just before New Year’s Eve I demonstrated the results to the Geoprise stakeholders. I showed that I could update a record on one node and propagate it to one or more of the other nodes. I further showed that I could send data from a collection of related tables, and also that I could send files as well as data. Whilst building the working prototype I also managed to change some technical primary keys from 10 to 38 digits to demonstrate that using a leading 12-digit company prefix followed by a 28-digit running sequence number was a practical proposition. (Note: as of February 2018, all sharable GM-X technical primary keys have been changed in this manner.)

All the Geoprise stakeholders were impressed that I could accomplish so much is so little time, but this was only possible due to the design of the RADICORE framework which is centered around performing standard SQL operations on database tables. It was therefore a relatively simple process to identify when a particular operation was performed on a particular table, extract that data into an XML document, and then send that document to a blockchain. At the receiving end a script would extract the XML document from the blockchain database, then send each table’s data to the object which dealt with that table.

Because the sending of messages containing application data over the blockchain can be configured and managed within the framework and without having to modify any application components, this provides a simple yet flexible and powerful solution to a complex problem. As a follower of the KISS Principle this seemed the right thing to do.

The Inside Story of GM-X ERP for Blockchain

admin — Wed, 10 Jan 2018 14:00:00 +0000

By: Nelson M. Nones CPIM, Founder, Chairman and President, Geoprise Technologies Corporation

I recently co-authored a book with Dr. Janson Yap, “Wow! How Did You Know That?” (Chatswood, Australia: Gadwise; 2017. 275 p. ISBN 978-9811156618.). If you're interested in reading it, head over here where you can order a copy.

What's this got to do with the inside story of GM-X ERP for Blockchain? Plenty, as it turns out.

Spark of Inspiration

Dr. Yap is a recognized Innovation Leader in the Asia Pacific region, and has been a friend and professional colleague of mine for over 20 years. Our book focuses on the theory and practice of risk intelligence, including threats and opportunities posed by new technologies. Naturally, blockchain technology figured prominently in Dr. Yap's vision for the book project, so at his suggestion I took this topic on board about a year ago. You can read the outcome in Chapter 12 ("Get SMART"), pages 209-212, which I completed in May 2017.

To be perfectly honest, I didn't know much at all about blockchains at the outset, beyond the fact that they underpin today's cryptocurrencies. A great deal of research was required before I was able to write something worthy of inclusion in the book.

After that, at the very instant I stood back to view my work as a whole, the light bulb went on.

The Proof of Identity Dilemma

Nearly twelve years before, I had written a series of blog posts about security and privacy concerns which I thought would obstruct software-as-a-service (SaaS) offerings from gaining traction in the marketplace—particularly SaaS offerings dealing with sensitive information such as personal and financial data. I stated the basic problem in On Identity, Part 1:

A bilateral trust model ... puts absolute enforcement power in the hands of the respective parties according to the terms of a mutually-agreed contract ... [which] might give you the right to declare certain information ‘private,’ after which the service provider has no right to see or retain it in its domain without your explicit permission, obtained according to your rules. You can enforce your rights by encrypting this information, and issuing the [decryption] key only when you’ve authorized someone to see it.

Proof of identity is of course the crux of any bilateral trust model. That’s because each party's ability to enforce its end of the contract depends, in turn, upon its ability to tell the difference between a legitimate representative of the other party, and an impostor.

In On Identity, Part 3, having demonstrated that none of the authentication standards then in use are appropriate ways to implement a bilateral trust model, I examined several competing federated identity frameworks as well as proprietary networks, and then peered into the crystal ball:

This leads me to the Universal Private Address, [a] federated identity framework put forward by [the Organization for the Advancement of Structured Information Standards (OASIS)] and Advanced Micro Devices (AMD). It is a new type of abstract address that uses an OASIS XRI (Extensible Resource Identifier) and protocol known as XRI Data Interchange (XDI).

What intrigues me most about the Universal Private Address is that it specifically targets the need for bilateral trust that I believe is key to future marketplace acceptance of ‘on demand’ software. This is because the link between any two Dataweb pages is a pipe for pushing or pulling data in either direction, under the control of automatic ‘valves’ at either end known as ‘XDI line contracts.’

Will Universal Private Addresses take off?

In hindsight, Universal Private Addresses never went anywhere—nor did any competitors I considered (except, arguably, Shibboleth in academic circles). Today, the overwhelming majority of commercial SaaS offerings in the public cloud still rely on User IDs and passwords to identify people. According to SkyHigh Networks, just 1.1% of cloud providers support tenant-managed encryption keys. The rampant pandemic of security breaches, identity theft, ransomware and “fake news” plaguing the world today should come as no surprise to anyone.

Inability to assure even the most rudimentary proof of identity is precisely what enabled Russian entities to buy advertising, post memes and organize political rallies during the 2016 U.S. Presidential campaign using fake Facebook® accounts, in an attempt to trick prospective U.S. voters into believing this content came from credible and legitimate domestic sources.

Geoprise, meanwhile, tried to hop onto the SaaS bandwagon in 2007. We introduced a product known as GeoBooks On Demand, but we should have known better considering our warnings just two years before. GeoBooks On Demand flopped. The main reason: enterprises—particularly those located in Asia—were loathe to store their financial data in the public cloud. “We won’t put our data anywhere the government could see it without our knowledge” was the usual objection. So, it seemed, our original warnings were spot on.

Readers who are at all familiar with how blockchains and cryptocurrencies work can be forgiven for wondering how this technology comes anywhere close to establishing the proof of identity needed to create and sustain bilateral trust. After all, most cryptocurrencies are pseudonymous, in the sense that account owners can choose to remain completely anonymous by changing their blockchain addresses (identities) with each transaction. And their proof of work (POW) mechanism for validating transactions operates according to a “trustless consensus” principle which assumes that no one on the network can be trusted at all.

But blockchains have another important property: they are federated. Account owners keep, and verify, their own copies of the blockchain instead of relying on an intermediary to maintain a single, centralized database. In addition, blockchain transactions are self-certifying which makes them permanent, tamper-proof and verifiable (see our white paper, pages 4 and 5, for details and a demonstration).

It suddenly dawned on me that blockchain technology fully satisfies one of the essential requirements for establishing bilateral trust: it gives individual participants complete and exclusive control over the data they own, the assets those data represent, and even their identities. No other technology platform which purports to satisfy this requirement has ever come close to gaining such widespread acceptance in the world of commerce, and for this reason none are as battle-tested in the wild.

This realization was the spark of inspiration.

The Confidentiality Quandary

But there was a problem. At first glance it would appear that blockchains are incapable of protecting privacy, because they keep a ledger of all verified transactions, and those transactions are visible to everyone. From the research I'd already conducted, it didn't appear that a blockchain could perform anything resembling an “XDI line contract” like the Universal Private Address.

So, I continued my research. Eventually I found this blog post by Dr. Gideon Greenspan, CEO and Founder of Coin Sciences Ltd in which I found:

The first idea that we (and many others) started with ... inspired by bitcoin directly, was that private blockchains (or ‘shared ledgers’) could be used to directly settle the majority of payment and exchange transactions in the finance sector, using on-chain tokens to represent cash, stocks, bonds and more.

This is perfectly workable on a technical level, so what’s the problem? In a word, confidentiality. If multiple institutions are using a shared ledger, then every institution sees every transaction on that ledger, even if they don’t immediately know the real-world identities of the parties involved. This turns out to be a huge issue, both in terms of regulation and the commercial realities of inter-bank competition. While various strategies are available or in development for mitigating this problem, none can match the simplicity and efficiency of a centralized database managed by a trusted intermediary, which maintains full control over who can see what.

Why is this an issue? According to Dr. Greenspan:

In a nutshell, concentration of control. By putting so much power in one place, we create a significant security challenge, in both technical and human terms. If someone external can hack into the database, they can change the ledger at will, stealing others’ funds or destroying its contents completely. Even worse, someone on the inside could corrupt the ledger, and this kind of attack is hard to detect or prove. As a result, wherever we have a centralized ledger, we must invest significant time and money in mechanisms to maintain that ledger’s integrity.

So far, this seemed like yet another problem begging for a solution. But further exploration led me to a subsequent post from Dr. Greenspan which described a solution:

As I’ve discussed previously, confidentiality is the biggest challenge in a large number of blockchain use cases. This is because each node in a blockchain sees a full copy of the entire chain’s contents. Streams provide a natural way to support encrypted data on a blockchain, as follows:

One stream is used by participants to distribute their public keys for any public-key cryptography scheme.

A second stream is used to publish data, where each piece of data is encrypted using symmetric cryptography with a unique key.

A third stream provides data access. For each participant who should see a piece of data, a stream entry is created which contains that data’s secret key, encrypted using that participant’s public key.

This provides an efficient way to archive data on a blockchain, while making it visible only to certain participants.

To me, this looked a lot like the concept of “a pipe for pushing or pulling data in either direction, under the control of automatic ‘valves’ at either end” which I had described 12 years before. It's why the GM-X ERP for Blockchain solution we are announcing today calls them “data valves”.

At last, a solution that performs the equivalent of an “XDI line contract” appeared to exist that, in tandem with blockchain technology, was sufficient to establish and sustain bilateral trust.

Proof of Identity, Revisited

It was by now clear to me how blockchain technology could dissolve the concentration of control that is inherent in centralized systems, and enables bad actors to flourish by stoking today’s security breach pandemic.

It was equally clear how streams and encryption technology could overcome the confidentiality quandary inherent in blockchains (see our white paper, page 6, for a demonstration).

Still, none of these solutions is capable of proving identity. When I transact with someone over a blockchain, how can I “tell the difference between a legitimate representative of the other party, and an impostor”?

This is where the distinction between public, “permissionless” versus private, “permissioned” blockchains enters the picture.

Cryptocurrencies like Bitcoin are public: in theory, anyone can create a cryptocurrency account, anyone can engage in mining (transaction validation), and all these players can choose to remain anonymous. In conditions like these, nothing short of a “trustless consensus” mechanism will do.

But membership in a private blockchain is conferred by invitation only. As our white paper says on page 18, “a private or permissioned blockchain is not a trustless environment; even if the participants ... don’t fully trust one another, they must nevertheless be accredited or trusted enough to have been invited in the first place.” This is certainly the case for nearly every business-to-business (B2B) collaboration scenario I've ever encountered during my 37 years in the ERP field.

Technically, it is much simpler to prove an enterprise's identity than it is for individual consumers because well-accepted standards and services for doing so already exist. The most common standards are D-U-N-S® numbers, issued by Dun & Bradstreet, and GS1® global company prefix (GCP) numbers. You may have heard of D-U-N-S numbers before—especially if you work in the U.S.—but if you think you’ve never heard of GCP numbers before, think again. They are embedded in each and every one of the barcodes that are scanned at the checkout lines in millions of retail stores across the globe; the GS1 standards even provide a place for International Standard Book Numbers (ISBN).

In order to get a D-U-N-S number or GCP, enterprises must apply to Dun & Bradstreet or a GS1 Member Organization (MO) as explained on pages 18-20 of our white paper. The vetting process for those applications has nothing whatsoever to do with blockchain or encryption technology, and everything to do with good old-fashioned due diligence. What's more, the outcome is an identification number that is globally unique, and freely verifiable over the public Internet.

It's important to note that the sponsors of a private blockchain don't have to mandate the use of D-U-N-S numbers or GCPs to establish proof of identity. The blockchain's initial sponsors and current members are, in fact, free to choose whatever accreditation protocol they deem fit for purpose, no matter how strict or lenient. But the fact that well-accepted standards and protocols exist which provide globally-unique and trustworthy identities for individual enterprises, and participants can refuse membership to applicants who fail to accredit or comport themselves satisfactorily, resolves the proof of identity dilemma for B2B collaboration scenarios.

A happy consequence is that the POW (mining) required for “trustless consensus” is no longer needed and, in fact, is a needless waste of resources. As a result, the MultiChain blockchains described by Dr. Greenspan are capable of processing up to 1,000 transactions per second on networks comprising mid-range servers, and our initial tests revealed that new transactions propagate through a MultiChain network instantaneously.

Proving the Concept

In mid-October 2017, I discussed my findings at length with Tony Marston, our R&D director. Like me at the start of the 2017, Tony professed very limited knowledge of blockchain technology but he immediately agreed to put MultiChain to the test.

It took Tony just under two months to build and successfully deploy a proof of concept using MultiChain.

The outcome of all this work was the partnership with Coin Sciences, Ltd that we are announcing today.

Designing and Building the GM-X Blockchain Subsystem

During the proof of concept phase, Tony and I also invested considerable time in discussions—and a few very lively debates as well—on the best way to integrate our GM-X ERP application with the MultiChain blockchain server. The outcome of these discussions is described on pages 16-24 of our white paper.

Our design required just three key GM-X enhancements:

Developing the GM-X application program interfaces (APIs) which send GM-X transactions to a blockchain ledger, and retrieve new transactions from a blockchain ledger. See pages 5 and 6 of our white paper which illustrates the messages which are sent, stored in the blockchain, and received. This work is complete and has been extensively tested.
Creation of a new GM-X Blockchain Subsystem to configure and manage the data items which each participant publishes from its instance of the GM-X ERP application, the blockchains to which these data items are published and the distribution policy for each of these data items. Every participant runs its own instance of the GM-X ERP application, and can maintain its own private data in addition to the data it chooses to share with one or more of the other participants. See pages 21 and 22 of our white paper for further details. Tony completed the development and initial testing of the new GM-X Blockchain Subsystem in about 3 weeks.
Enhancement of most GM-X auto-incrementing primary keys to guarantee that data items created independently by each blockchain participant will mesh properly, without any collisions, when published to a common blockchain ledger. See pages 17 and 18 of our white paper for further details. This work is ongoing and currently supports 3 of the 11 GS1 Class 1 Identification Keys standards. We expect to complete this phase of work during the first quarter of 2018.

I am enormously proud of what our team has accomplished so far, and am absolutely certain that our GM-X ERP for Blockchain solution will prove just as revolutionary for the world of ERP as the introduction of client-server computing a quarter-century ago.

My aim in telling our inside story is to make it clear that Geoprise isn't taking opportunistic advantage of all the hype about blockchain technology to flog yet another half-baked solution in search of a problem. On the contrary, in partnership with Coin Sciences Ltd, our solution has been many years in the making, and offers a solid and proven way for enterprises who depend upon B2B collaboration to counter today's alarming and rapidly escalating information security threats.

Acknowledgments

I gratefully acknowledge the inspiration and contributions provided by Dr. Janson Yap, Dr. Gideon Greenspan and Tony Marston.

I also thank David Shultz, Will Shultz, Jeff Khoury, Chris Will and Randy Spiess for your critical and constructive reviews of our design thinking and white paper.

Geoprise Technologies - GM-X

Geoprise R&D Director Tony Marston Receives Multi Corporate LiveWire Global Award 2024/25

Tags:

How To Cut ERP Costs

Tags:

Is Blockchain's Capacity Limited To 7 Transactions per Second?

Tags:

Blockchain for Blockheads

Tags:

Adding Blockchain to an ERP System

Tags:

The Inside Story of GM-X ERP for Blockchain

Tags: