Why did I postulate a confusion between the "operational" and "infrastructure" viewpoints?
Where to start...
At the beginning! In the old days, before software engineering was called software engineering, those who "wrote code" simply, we may now say maybe naively handed it over to operations, who independently, maybe instinctively decided how to deploy it.
(And, human nature being what it is, this "over the wall" approach is still the case today in many places. That'll be politics, people and power... and process!)
So we had (and still have!) functional-application stuff, and infrastructural-operational stuff. Two power bases for separate "tribes", each largely blissfully unaware of the other's world. And as a consequence a whole host of decisions automajically made to fill the gap between the two worlds, hopefully largely based on custom-and-practice; or better still an IT inspired standard template ("put it in the cloud!"), but never "joined-up" between the two viewpoints.
But thinking of "application" and "infrastructure" as distinctly different things from "functional" and "operational" gives us the chance to help each tribe see, and therefore more cleanly and obviously first separate and then properly join, the concerns of "how will we make the application work technically?" and "where will it all go?"
Can we help the functional developers consider the infrastructural implications of there code and data designs; and the operations professionals to understand the deployment needs of the applications and databases for which they are designing/configuring an operational environment?
Yes! We can... and I'll explain in a moment... but first I think there's another, equally powerful explanation for mistakenly making "operational" and "infrastructural" synonymous... in my next entry!
No comments:
Post a Comment