Look Inward. Look Outward. Break it Down.

There are two types of entites in an organization. Those that look inward and those that look outward. This applies to any size organization. Each extreme is deadly. Too much inward looking and one loses sight of all the ways the world moves on organically outside. Too much outward looking and ones loses all sense of self control. The middle road seems worthwhile. All things in moderation.

The same inward and outward view is true of one's, potential and existing, customers or believers. The hope is to match outward and inward appetites.

Most very large organizations fall into looking inward. They focus on internal issues. They become protective. And they often close their borders. They raise up walls. This can work for awhile - especially when everyone in a domain is looking inward - including clients.

But in the face of even a moderate amount of client and competitive outward looking behavior, introspection is ultimately doomed. It is like the network effect: The power of the arrangement is more than simply a linear function of the participants. It goes more like the scale of potential connections.

This is, in technical microcosm, the story of APIs and microservices. The move to outward facing APIs and microservices is a reflection of the larger effect of a move to looking outwards overall.

Fintech organizations (banks "which can be defined as a bank or division thereof") now a see a world where it is important to look for new vehicles and new services. And to actively partner and acquire those vehicles. One bank buying another bank wants seamless integration. The melding should be about business initiatives and synergies and not about whether COBOL speaks to Fortran... those days are long gone. And the days where differences could be used an effective protective wall are likewise gone.

Industries where there are walls:
PLC communications. Cold chain management. Security systems.

Domains where the walls have been broken down:
Google maps and APis in general. AWS, Cloudfoundry and VMware systems. Network management protocols: Cisco.

Areas in transformation:
Building automation - witness a move to RESTful webservices.
Certain types of industrial automation - witness MTconnect. Platforms like GE Predix for IIoT. Renewable energy management - witness Sunspec and others.
Tools and platform providers are deaggregating- witness Microsoft Azure and IBM Bluemix.

Even energy itself is being deaggregated with Microgrids - with a strong analogy to microserviecs and APis. Utilities which continue to look inward will have serious problems.

There can be no knowledge without looking inward and outward. One needs to work on the viewpoint where one is most blind. 

APIStrat 2016 Boston November 2-4.

First week of November 2016 was API week in Boston. Still trying to absorb APIStrat 2016. Presentations the same week with similar API themes from IBM, SmartBear and GE Predix.

API?  Had in mind the API definition from Wikipedia. But the core is now more what is defined above as "Web API". API is about REST, SOAP - MQTT, CoAP - etc.

Presentations in past months and years on IoT from Axeda, Thingworx, PTC and IBM Bluemix and AT&T M2M and Amazon Alexa/Lambda were in retrospect more about APIs than anything else. The APIs for endpoints and platforms for IoT have been building. BACnet Web Services is but one example.

API is more than a "definition". API is about the rising ecosystem of business use cases and tools for APIs. Swagger, RAML, OpenAPI , Stoplight, even Postman, CURL and choices regarding REST, SOAP, XML, JSON and so forth.

Gartner analyst APIStrat keynote: Mark O'Neill : Business use cases gelling. Rich ecosystem of tools and cases for API creation. But also cases for API consumption... and there is a business opportinity therein. [Also *grin* Why are digital voice assistants like Alexa and Siri always depicted or embodied round? Are polygons too edgy? ]

Great easy venue for APIstrat at Marriott Long Wharf on Blue Line MBTA.

New Devices – Just Give us the Pins and APIs

Recently blogged about the renaissance of the DIY electronics pathway.

http://albertputnam.blogspot.com/2013/12/renaissance-of-diy-electronics-store.html

Now one can find modules for almost any function - at near instant mail order and even at a local retail outlet.

That speaks to a message that needs to get to the developers of new chips and modules for connectivity and core or ancillary functions. The release of such modules often involves a CPK (programmers kit) to the chip or module API – fair enough. The supplier company often releases a development kit - which has a reference design board, their module, a power supply and various cables, and a DVD or CD with the CPK (or more lately a slip of paper or QR barcode code with a website link to a CPK download *grin*)

The new paradigms of modules at retail screams out to stop building/providing hardware development kit boards - with UARTs and LEDs and converters and drivers power connectors and all such do dads, plus saying nothing of CAD and revisions for a reference design.

Suppliers - just put your chip or module on a carrier with pins (at human scale with 0.1” or 2mm spacing). Make your reference designs utilize other modules. Refer to said modules specifically if you like.

The only things the developers add are

A. wire interconnects between modules (and the developer at the end gets to choose which modules to use). There is no harm in a reference /design/, just do not make it the defacto only thing the developer can use as hardware.

B. code interconnects between module APIs.

The work in development becomes the interconnection for pre-existing functional blocks with accessible API and pinouts. There are some nice USB (and other protocol and wireless) bridges developers could really go to town with given accessible pins. This is to say nothing of a fair bunch of embeddable microcontrollers. Get humans something to get humanly started. Then the design wins will come.