Cobbler's Children Syndrome The stovepipe enterprise S tovepipes are - - PowerPoint PPT Presentation

Cobbler's Children Syndrome

The stovepipe enterprise

Stovepipes are “systems procured and developed to solve a specific problem,

characterized by a limited focus and functionality, and containing data that cannot be easily shared with other systems.” (DOE 1999)

• DOE. Committee to Assess the Policies and Practices of the Department of Energy, Improving Project Management in the

Department of Energy, National Academy Press, Washington, D.C., 1999, page 133.

Mic drop development

40 offices in 14 countries

Vendor Team Ops Team DBA Team Dev Project Team Vendor Team Dev Project Team Dev Project Team

"Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization's communication structure."

[Conway, Melvin E. “How Do Committees Invent?” Datamation April (1968). Print]

Conway’s Law

“the path taken between two points by a ray of light is the path that can be traversed in the least time”

Fermat's principle of least time

“the development team chosen to implement a

feature is the

development team that can

implement it in the least

time”

Least Time + Conway

= Monoliths

“XP teams are self-organizing and cross-functional. This has two important consequences: first, they're responsible for their own

• success. Second, XP teams

include all the expertise necessary to do so.”

[http://www.jamesshore.com/Agile-Book/the_xp_team.ht ml]

Back to our core Agile principles

responsible for their own success include all the expertise necessary to do so

Microservices

was my ‘boss’

Sales

Change management Stakeholder management Infrastructure Support Vendor management

Staffing

Change management Stakeholder management Infrastructure Support Vendor management

People

Change management Stakeholder management Infrastructure Support Vendor management

Inverse Conway Maneuver

Monolith Staffing People Sales

Teams Leave Rates Leave Rates

Focus on capabilities

Big App Staffing People Sales

Teams Leave Rates

Refactor

“Make it up fatigue”

Staffing API Key Pair People Basic auth/SSL Sales OAuth 2.0

n+1

waste

Infra is rarely touched 3 to add environment variables 1 to change log format 1 Microservice 4 commits out of 1000

Avoiding horizontal centralisation Enforcement

(policing role)

Consultancy Partnership

"Susanna Celeste Castelli, DensityDesign Research Lab".

/dəˈɡɛrəˌtaɪp, -roʊ-, -riə-, -rioʊ-/

“All teams will henceforth expose their data and functionality through service interfaces.”

Control over Ownership

Fabric tech

Cloud, Data, Monitoring, Analytics, API management, Build, Source, Security, Synthetic monitoring

Capability tech

Lambda, Clojure, Angular, iOS

People APIs, Web, Mobile Staffing APIs, Web, Widgets, Chat Bot

Capability tech

Ruby, ElasticBeanStalk, Solr, Hangouts, React

Sales APIs, Web, Mobile, Reports

Capability tech

SFDC, node.js, mondrian, neo4j, PhoneGap

Return to Conway

Cross functional + microservices

Fabric Services

Stakeholder management Delivery (PM, QA, Dev) Vendor management Product owner Specialists Support

IoT

Platform of services

Build Source Automated security checks Identity User analytics Monitoring Notifications and escalation Resilience Synthetic monitoring Logging APIs Data DNS/SSL Infrastructure (servers, storage etc.) Social Security monitoring Identity M&A Infradel No home Mobile testing Authz/Authn

Mature towards services

Genesis Custom build Product Platform / commodity Patterns Solution specific Library / framework Service Continuous Integration Build server CruiseControl Snap/Jenkins Fabric Tech Capability tech

Fabric tech Capability tech Capability platform Fabric tech Capability platform

vs

Autonomy over Standardization

http://www.flickr.com/photos/bortescristian/2326692011/

Preserve Autonomy by preserving control (responsible for own success) Provide specialisms via microservices (all the expertise necessary)

Remove the Yak!