Implementation Guidelines and Specifications

Since the beginning of the year, I have concentrated on using implementation examples to explain the various components of the satconomy framework. I hoped that through these demonstrations, a more complete picture would emerge in the reader’s mind, showing how the various pieces relate to each other. Of course, the site also discusses the framework’s conceptual bases, but I have always felt that observable practice is always more effective than verbally communicating abstract ideas.

I still feel that way, but at this point, I also see the need to supplement the simple implementation examples with more definite guidelines and specifications. So, I am now in the middle of drafting documents to address this perceived need. Whereas before I thought it would be counter-productive to create specifications that might narrow the appeal of the satconomy framework, I have since realized that there are ways to draft highly flexible guidelines and specifications that broadens the framework’s inclusiveness to diverse technology platforms. I liken this approach to using the minimalist protocols that gave birth to the ‘world wide web’, as explained by Tim Berners-Lee in his book “Weaving The Web”.

The specifications will cover the basic features that must be offered by accounting systems, transaction processing and publishing/reporting mechanisms in order to comply with framework implementation requirements. Using the specification documents and online examples as guidelines, each system component or module could be independently developed on its own. Specifications-compliant components would then be assured of compatibility with each other, facilitating the implementation of a robust system from readily available applications.

Come to think of it, there are some similarities between this approach of developing independent software components and the establishment of independent currency brands. Both conceptual frameworks encourage independence while offering a way for the independent pieces to work with each other. Software components offer specific services outputs which are used as inputs by other components, which is basically the same concept behind inter-entity market trades. Another similarity is that whereas software development is expected to be self-regulating against open specifications, entity and brand establishment is expected to be self-regulating against public opinion within a satconomy framework. In both cases, it is expected that the transparency and diversity of interacting components or brands will enhance framework adoption and robustness.