| Follow @cleverbeard
Centreville
Matt Micene is an evangelist for Linux and containers at Red Hat. He has over 15 years of experience in information technology, ranging from architecture and system design to data center design. He has a deep understanding of key technologies, such as containers, cloud computing and virtualization. His current focus is evangelizing Red Hat Enterprise Linux, and how the OS relates to the new age of compute environments. He's a strong advocate for open source software and has participated in a few projects. Always watching people, how and why decisions get made, he's never left his anthropology roots far behind.
Authored Comments
Ron, thanks for taking the time to comment.
You make a great point, while I focus on the development / engineering split here, these sorts of divides happen all over the organization. The same cultural forces are in play, just different players. Your mention of product development reminds me of an example within Sony where 3 different groups launched 3 separately developed portable music players at the same product launch event.
As an aside, there's also a great next thread that leads to Japan in the storyline. A good portion of current thought in technology draws from The Toyota Way via LEAN and Kanban. Much of the early work in Toyota came from Peter Drucker's work on management science. A seminal piece of Peter Drucker's work came from a 2 year study of Sloan's GM. There are more connections that can be easily explored in a short time.
Bruce,
Thanks for taking the time to comment.
I agree with your comments the visibility of daily work to the business. I used to tell my managers (when I was still in ops) that the less they heard from (or about) our team, the better we were doing our jobs.
I argue that the very issue you mention, that places less value on maintenance than new features, is one of the business culture facets that a successful DevOps plan needs to correct. The separation of these phases of application lifecycle into different teams isn't a "natural" split in software engineering, but imposed on software engineering by business thinking.
One way this is reflected is how the business accounts for costs for each team. Capital expenses are tied to the means of generating profit and usually viewed as an investment potential. New application development is usually placed in this category. Operational expenses are tied to ongoing costs and are usually thought of in terms of reductions to the lowest levels without impairing production. Application operations are usually placed in this category. This sort of accounting model is the legacy of hard goods manufacturing, and the latest guidance generally hasn't kept up in software to practices like Agile.
I agree it's also central to people over tools in DevOps. A tools-only or tools-first will simply paper over the culture problem and not cure it. Culture is about the beliefs held by a group of people, and in a business context value of labor and output is part of that culture. This has be to recognized at all levels and conscious effort is needed to change the thought process.