From Governance to Chaos

Convener

Carlos Eberhardt (@carloseberhardt)

Attendees

Harbal Singh @harbal, Vimin

Notes

• What is governance? Super-high-level, it makes sure IT is aligned with what business wants to do. Regulatory and industry requirements are also a part of governance.

Governance is what you do before you change a contract.

• Does the change in scarcity challenge some of the reasons for governance?

• The cost of investigating new technologies has gotten much better due to incremental changes. Big bang investments are not required any more.

• The end-costs may not be cheaper but the cost of experimentation is much cheaper now.

• possibly analogy to departments getting minicomputers instead of needing mainframe access

• Governance is often one-dimensional, it's driven entirely by IT and without business involvement

• Does the emergence of API programs as a product provide for new opportunities for governance?

• Traditional governance is very project driven. Does that align with product strategy?

• Governance for API as a product needs to have marketing, biz development, etc. at the table alongside security, info protection, and so forth.

• Roles and responsibilities need to be clearly defined.

• What is the scope of governance? How do we keep it from becoming too big?

• Heavy governance on the asset side, the SOA side, can cripple your API program.

• Is it a serial process or can it be done in parallel?

• Can you split your governance model in similar to how Netflix has split their API model?

• Business governance becomes a factor if so. There's a technical governance and a business governance side.

• Risk: people in governance roles become fossilized.

• Assuming Governance is not going to be eliminated, how can you make it more agile? ** Identifying short-paths with governance roles to navigate quickly ** Where does the buck stop? ** Make slow governance responsible for core systems ** Multiple governance layers to mimic other layers

• Lens of contract thinking matches up with the lens of "pace of change" layer thinking

• Risk of change is another view that needs to be included

• Onion model

• Contracts must be well-written

• Contract in API space mimics B2B with different contracts. Unless your API model has 1000s or orders of magnitudes more consumers, so contract becomes standardized.

• Could you govern the core systems and allow only "moderated" governance for internal developers to build anything they want?

• Seems yes, but how is it justified? Innovation!

• No! it's crazy. It's wild west.

• General consensus is that Carlos is crazy. ;-)

• Duplicating skins is easy, duplicating big stacks is expensive.

• tie in with costs.. if costs are trending to zero, then can you have a more wild west style development process for apis?

• can you have multiple teams creating multiple apis that do the same thing, allow the developer community to "vote up" the correct ones through usage?

• can governance move to the lower level "platform" and allow ungoverned creation of APIs by project teams?

• If you let enough accidents happen, some of them will be happy accidents. Can you loosen governance in internal API development enough to allow happy accidents.

• Outcome: Depending on risk, there may be areas where governance can be loosened.