Terra-Classic-Platform-As-A-Product (Part 2-of-?)
As I sit here on my mountain top watching the sunset on Q1, pondering the future of the Terra Classic L1 Task Force, our community and our progress in Q1 I silently enumerate the fresh battle scares from the recent encounters with the trolls of the Cosmos, and give my mind time to wander to a favored quote of mine by Sun Tzu: “If you know the enemy and know yourself, you need not fear the result of a hundred battles. If you know yourself but not the enemy, for every victory gained you will also suffer a defeat. If you know neither the enemy nor yourself, you will succumb in every battle.”
In retrospect, throughout all of Q1, the L1TF has fought, and won, many battles. We have lost a few internal ones, but by and large I could not be prouder of what people like Till, Vinh & LBA have accomplished and I think its safe to say that we have found an identity for ourselves even thou we know that we face a cohort of yet-to-be-adversaries, some of which will surely best us in battle, but who will never break our spirit.
Naturally some of our vanquished foes will try to belittle us or neglect our accomplishments in order to make themselves seem larger then they are, but as it stands round #1 in this eternal “tug-of-war” over the soul of the Terra Classic community clearly goes to the L1TF and if funded for Q2 we plan to continue our journey and work towards more clearly defining a future proof “Platform-As-A-Product” strategy for our “public-blockchain-developer-platform”, if that is even a thing? 😂
To expand a bit further on why we need to do this, it gives me no great pleasure to inform everyone that a “Platform-As-A-Product” strategy is becoming an essential requirement for enterprises looking to onboard the digital economy. So much so that the larger companies call this old turtle to ask for advice on how to best “architect” their internal developer platforms, sort out their cognitive overload issues and help HR stem an ever growing tide of replacement requests for various projects to ensure they have enough capable developers to staff their teams and meet their deadlines as they collectively race towards the promised land of Industry 4.0. Without truly knowing what it is and how it looks.
To help these companies better understand what it all means I typically break things down into three “architectural pillar”, that in my view underpins any successful “Platform-As-A-Product” strategy.
Pillar #1: Logical architecture
The logical architecture is a conceptual model of the platform that defines its functional and non-functional requirements, and the relationships among its components. It provides a high-level view of the platform and its components, without going into the details of implementation.
In software design, logical architecture is used to describe a system’s behavior and organization, including the components, modules, interfaces, and data flows. It helps in defining the structure of the system and its components, and how they interact with each other to achieve the desired functionality.
The logical architecture is an important component of a successful “platform-as-a-product” strategy due to its importance in the software development process, as it serves as a blueprint for the implementation of the systems on top of the platform itself, in our context we call those kinds of systems “dapps” or “L2 apps”. Its goal is to provide a clear understanding of the platforms functionality and helps to identify the key components and their responsibilities.
In Terra Classic our logical architecture manifests as the REST & Event APIs our network exposes to the world. Its described in more detail @ https://medium.com/@ZaradarTR/terra-classic-integration-guidelines-626997eadfee
Pillar #2: Physical architecture
Physical architecture refers to the way in which the platform is implemented to support its more abstract logical architecture. It is concerned with the physical aspects of the system, such as the code, the servers, storage devices, network infrastructure, and other “L1 components” that are used to manage our public blockchain.
Physical architecture is a critical component of platform design, as it determines how the software will operate in the real world. The physical architecture also defines the hardware requirements for the software needed to support the platform, such as the processing power, memory, and storage needed to support the software’s operation.
In addition, the physical architecture also includes the network topology and the communication protocols that are used to connect the various components of the platform. It defines the location and placement of the hardware components, and how they are connected to each other to ensure the reliability and availability of the platform as a whole.
Most of the work we did in Terra Classic throughout 2022 focused on understanding and defining our logical architecture. The work we are doing to get us to “clear skies” in 2023 is focused on improving the physical architecture.
Pillar #3: Knowledge architecture
Knowledge architecture in software design refers to the way in which knowledge is organized, stored, and accessed within a “internal developer platform”. It is concerned with the way in which information is structured and managed, and how it can be used to support decision-making, development and problem-solving within the platform.
In software design, knowledge architecture involves the creation of a knowledge management system that allows users to store, access, and share information within the software system, sometimes referred to as “dojos”. This may also include features such as custom search engines, code katas, data mining tools, and analytics engines that help developers find and analyze information within the platform.
Knowledge architecture is particularly important in systems that rely heavily on data and information, such as business intelligence systems, scientific research platforms, and blockchains. It helps to ensure that information is effectively managed and utilized, that users can easily find the information they need to make decisions or take action to help fix the code itself if needs be.
Some common techniques and tools used in knowledge architecture include data modeling, ontology development, knowledge representation and peer assisted learning strategies. These tools help to organize and structure information in a way that makes it more usable and accessible within the platform.
In Terra Classic this is most likely one of the least maintained pillars, some would argue it never existed, which is why the L1TF has begun work on a dojo.
With this article I wish you all happy voting for the Q2 prop. Most of us are going to take some time off while the community figure out if they will accept our offer or find a replacement. Until then I wish you all well and hope to see you all in Q2 for some more fun.
To be continued…
