Reaction to API Strategy Video

A great friend and colleague of mind, Jay Yanko, share this link with me.  The video, which is about 45 minutes long, hit on few specifics that I have seen within enterprises throughout my career.  They really don’t have anything to do with Web 2.0 or API strategies.  On one of the slides, Sam Ramji, puts up this message.  “What’s do damn wrong with the current model?  I like it and it’s working for me.  Plus, I understand it.”  This had me reflecting on the root of these statements.  One word, “tradition”; but then I thought of Woolworth five-and-dime corner drugstore.  Where did that store go, it had tradition.

So, I reflected deeper…  I read CIO; I talk to other CIO’s, CTO’s, CEO’s; owners of companies.  There are two kinds of requests for action.  One is actually what Sam states in his presentation, keep tradition, we are good to go.  The other request for action describes the core of one’s business and a request to reaching a greater population.  This request is without FEAR (fear of something “bad” happening); but more of a question of vision and understanding of “change”.  Change is happening much more rapidly.  In Darwin Finches 20^th Century Business and API’s Evolve video, I can see the message that there are many different species today than before.

The socialmedia demographics slide graphically displays the different species.  A ha-ha moment was that one needs an API for to allow an interface for each of these species.  So, the traditionalists are stuck and those accepting change are able to put those API’s in motion.

I share an example of a potential non-technical API.  So, you are manufacture who makes specific parts.  You have a great pipeline of work, but your resources are constrained by size of building, number of workers, and number of machines.  What would happen, if this manufacture had an API?  The API could be open to all species, even you biggest competitor making similar parts.  Should one FEAR something bad is going to happen if the API shared those additional requests for work?  A traditionalist may.  An opportunistic manufacture may say, let them make the part and grab a small percentage of the flow through that API.  In the end who wins?

Everyone wins and gets a piece of the pie; along with the consumer asking for the part.  If our world, which creates great competition, begins to “SHARE” rather than “BLOCK & TACKLE” builds us a nation of enablement and satisfaction all at a rate of change that can keep up without really changing some of the tradition.  By increasing the number of channels (API’s) that can reach a great population.

Are you working to create additional channels?

How to build an internal knowledge base?

Jim’s message:

Hi all,  I work for a tech company full of engineers. I'd like to build a simple knowledge base without having to purchase a 3rd party app. Does anyone have any pointers?  I've started just a wiki-style site, but it's so unstructured and it's not catching on with my engineers.

Elliot is asking a good question, "What does Knowledge Base provide?"  You need to answer the question, which I would believe will lead to the next question.

This is the information organization challenge with this platform.  What does your Knowledge Base taxonomy look like; have you defined terms such as types of knowledge, categories the knowledge is filed under.  It does not have to perfect, however in order for your engineers to find, discover, search for knowledge the terms need to be defined and understood.   You will also need someone to continually oversee that knowledge is being filed and maintain correctly.  Assigning engineers to specific terms, helps build acceptance and adoption; because they feel like they own it.

Once your initial taxonomy is defined, then you get determine the best widget the platform has to offer.  So, the next question is, "What does your company like to use?"   Documents are still very common, so start with a drop off library which aligns with your taxonomy and allow the engineers to evolve.  Blogs are great why to allow for opinions to be shared with others about a document (knowledge).   Wikis are a great way to jump start to sharing some knowledge.  

Don't try to force the technology on the engineers; find one or two engineers who are highly engaging.  Let those engineers drive the knowledge base and what it starts to evolve.