After Machteld Meijer having hosting Charlie Betz and myself for breakfast in January this year in the Netherlands, Charlie very kindly took me out for dinner in his home town of Minneapolis on Aug 21st 2012, inviting Jeff Sussna, another local mover and shaker, to join us.
|Mark, Charlie, Jeff|
A selection of the topics we discussed follows.
- Whether IT is any different from HR, legal etc. in the degree to which they say no to the business.
- That 'IT' is often use just to refer to the organization that's responsible for the infrastructure, pushing the application group towards the business.
- The core competence of apps people is abstraction, something that isn't as dominant, if at all, in the infrastructure (or ops) domain. Turing talked about the division of IT into masters and servants in 1953. Abstraction is also something that business people often struggle with, making 'programming' with business rules a challenge.
- That axiomatic thinking isn't what you need to deal with complex adaptive systems in which behavior is emergent. And if this even baffles Betz, surely the rest of us are doomed ;-)
- Building resilient instead of reliable systems.
- Systems are getting so complex that it's irresponsible to think that IT has got them under control – but who dares to tell the business?
- Jevons paradox wrt clouds – more expensive because of more use.
- Rogue IT can be regarded as a demand request.
- Mark Burgess' key insight is that IT can no longer rely on an axiomatic (first order predicate logic) foundation. Quote: "The field of system administration meets an unusual challenge in computer science: that of approximation. Modern computing systems are too complicated to be understood in exact terms." Again, IT is not scientific and most IT people do not understand science. It is logical without being scientific, an odd paradox that we think leads to much dysfunction.
- The inability of IT (people) to comprehend the importance of probability.
- Quantum IT: you don't know if you have an incident until you look inside the box.
- DevOps filling in the gap that Agile doesn't address.
- That DevOps also deals with the business (not just the apps-ops connection).
- The need for T-shaped people: depth of knowledge complemented by broad interest.
- That IT started off with people who multi-tasked on both applications and infrastructure, then specialized and introduced a division of labor, but now seems to be reintegrating tasks.
- The confusing misnomer 'no-ops', referring to the fact that somebody else (e.g. cloud supplier) deals with ops. Might be better termed app-ops.
- The shift of IT from order takers to marketeers (markITeers?)