The Sclable Business Application Development Platform continues to grow and gain functionality. Besides developing stunning new features for our Platform, it is one of our biggest challenges to share and spread our knowledge on developing Business Applications with Sclable.
Knowledge only has value when it is available, and even the best tool isn’t worth much if you don’t know how to use it. This is why we have reinvented the Sclable Documentation and the way we transfer our knowledge.
With the launch of the Sclable Documentation as part of sclable.io (our key knowledge hub for Sclable developers), we made a big step towards our goal to make Sclable knowledge available and understandable for every developer out there.
Sclable.io – totally build with our own Sclable Platform technology – will also cover some other features and topics in the near future. You will read about these upcoming exciting news in another blog post. For now it is our biggest challenge to capture and structure the Sclable internal knowledge and transfer it to our developers.
“INFORMATION IS NOT KNOWLEDGE”
Albert Einstein said that. And yeah, probably he is right about that too. It is one thing to inform our developers and users about the power and new features of Sclable.
It’s another to build a structured system to impart knowledge in a sustainable way, and make it available at any time for every developer worldwide.
KNOWLEDGE MANAGEMENT THEORY AND CLASSIFIED KNOWLEDGE
Before launching a new documentation system, we started to classify what kind of knowledge there is and what we want to share with other people.
According to Michael Polanyi, a hungarian-british polymath, knowledge can be classified into explicit and tacit knowledge.
Polanyi made his thoughts about knowledge, knowledge transfer and what kinds of knowledge there are, back in the 1960s. That was long before the term “knowledge management” came up in the early ’90s by people like Ikujiro Nonaka and Hirotaka Takeuchi. And even longer before it got hyped at management boards and chairmen’s speeches in companies all around the globe.
Nonetheless. What Polanyi pointed out and Nonaka, Takeuchi and many others made clear with their researches, were some basic ideas on how to capture, develop, share, and effectively use organizational knowledge.
EXPLICIT AND TACIT KNOWLEDGE
As Michael Polanyi pointed out, there are two different kinds of knowledge. Explicit and tacit knowledge.
Explicit knowledge is that kind of knowledge that can be articulated, written down and is relatively easy to store. It can be understood as a kind of “people-to-document knowledge”. It makes sense to write explicit knowledge down, as it marks a fact. For example, “That’s an entity. It has attributes, states and actions.”
With tacit knowledge it is a little more tricky. Tacit knowledge cannot so easily be written down. It is more complex to transfer tacit knowledge to another person. In fact it is sometimes not even easy to realize that it is (very important) knowledge.
Tacit knowledge can be things people just do in their daily life, without imagining, that it could be really important knowledge for other people. Like the engineer, who knows that on a particular hydraulic press he has to unlock the protection safeguard twice in order for the machine to work properly.
These knowledge “between the lines” (also called people-to-people knowledge) is very hard to document, but all the more important for a successful knowledge transfer.
THE SCLABLE DOCUMENTATION – KNOWLEDGE TRANSFER IN THREE PARTS
When we were planning how to share our knowledge best and how to structure it, we knew that the Sclable Documentation had to cover both, explicit and tacit knowledge.
Our explicit knowledge on the one hand, is easy to transfer. It includes fundamental concepts, descriptions of layers within the Sclable Platform and so on.
Our tacit knowledge on the other hand, is more complex to add to the Sclable Documentation. Yet, it was the kind of knowledge we were interested in even more:
It’s one thing to know (and read) everything about Sclable Entities, but it’s even more productive to understand why in a certain domain model some references were implemented the way they were by our business analyst and domain modeller.
It’s even more helpful to grasp the benefit of selections and action triggers through a hands on example of one of our domain specialists than just read about how these things work out.
We came up with a solution that consists of three parts, which we believe is the most effective way to transfer our entire knowledge:
1. Explicit knowledge:
Captured within the Documentation menu. The place for plain concepts and descriptions. The theoretical foundation for developing with the Sclable Platform
2. Tacit knowledge:
Captured within the Tutorials section, this is where you find solely specific solutions for your specific problems. We tried to bind as much tacit knowledge as possible to here. All the little hints and tricks an experienced Sclable developer makes use of are shown and explained.
3. Hands-on and knowledge mix up:
Captured within the Get Started section. The idea was to give an easy jumpstart into Sclable. Set up your Sclable environment, start building a first application and check out our Phonotronic Sample Application. Away from theoretical jabbering just start developing with Sclable and gain knowledge through experience.
SCLABLE DOCUMENTATION FURTHER DEVELOPED
Basically, these are the main ideas behind the new Sclable Documentation. Our aim was to transfer knowledge with a straightforward approach. Explicit knowledge and tacit knowledge had to be included as well as guided walk-throughs to just “sclable around” and gain knowledge passing by.
Nonetheless, we are just standing at the beginning when it comes to transferring our knowledge. As this is an ongoing iterative process, new content for our Sclable Documentation will be added and updated continuously.