I admit, I had been resisting studying up on DevOps because of all the misinformation out there, particularly the notion that DevOps was about developers running operations/production and that it was tied up in all these specific Agile tools (jenkins, docker, openstack) or methods (scrum, sprints, XP). Reading this book and doing a little more research over the weekend, I've started to gain an understanding of the underlying DevOps philosophy.
I really like an old blog post by John Willis (https://www.chef.io/blog/2010/07/16/what-devops-means-to-me/) I found that, similar to the book, gets to the heart of the philosophy rather than getting tied up in specific methods, practices, or tools. He breaks it down in to CAMS - Culture, Automating, Measuring, Sharing. I would almost suggest that you could change that to just CAM - Culture (of Collaborating and Sharing), Automating, and Measuring. To many of us, the DevOps philosophy isn't new, it's things we've tried to do all along but may not have had the backing or the state of the technology and tools didn't allow for it.
A lot of people, when talking about DevOps and culture, talk about collapsing silos as if that means you have to get rid of traditional teams ("you can't have a network team and a storage team and an OS team - they all have to be one"), but it isn't that. It's collapsing barriers that stop teams from working with each other - territory building, rigid processes, the blame game - and embracing flexibility that allow for that collaborating and sharing. They talk about getting rid of traditional project management (it's all Agile), but I believe there's still a need for some traditional project management.
I was interviewing with someone a few weeks ago and they asked me about my project management style (even though I'm not a project manager, they were expecting some project management out of the leadership role I was looking at). They asked me whether I was more of a traditionalist/control PM or more of a collaboration person (I believe they were thinking about Agile methodologies). I expressed some confusion, because I didn't see the specific distinction between the two. I said that no matter what you were doing, you always knew there were certain project phases and tasks that needed to be rigidly tracked while sub-tasks and individual steps could be done without such rigor. I said you may spend some time up front collaborating to make sure everyone agreed on the phases and tasks, but eventually I (if I was managing the operation) would have to ensure they were done.
Automation and self-service is nothing new for any of us either. I was setting up automated build systems and allowing people to re-image desktops and workstations back in the early '90s. Before Sun's Jumpstart was developed, we combined network boot with a bunch of back-end tools and scripts (like swdepot) that allowed us to re-build our lab every semester and fairly simply rebuild broken or new systems. When I moved on to a FT job at a software development company, I used similar technologies (including Jumpstart, which was then available) to allow the QA team to rebuild their QA systems whenever they needed. What we didn't have then was the ability to create virtual machines (no VMware, no Zones, no Containers) that would allow for self-service of entirely new environments (we still had to go through budgeting and procurement to get the hardware, there were many pieces that still required manual work like racking/stacking, networking, storage, etc). Over time, we've gotten those tools (along with deployment management, configuration management, systems monitoring, capacity management) and capabilities (networking, security, storage, and others) that are now allowing some of these older ideas to come to fruition. Even more recently, we're finally starting to get the final pieces that were needed. In particular, we're starting to get real policy and governance tools that enable safe and secure self-service.
-spp On 6/17/2015 2:14 AM, Joseph Kern wrote:
> Surprisingly, it isn't that difficult to learn as much as you need. Yes, there's a lot about business you can learn, but you really don't need to learn that much of it. I got an MBA several years ago, but honestly, I could have read a basic accounting/financing textbook, a basic management textbook, and a basic business law textbook and gotten pretty much everything I've used since then. Most of what you need to understand is the basics, the terminology, and some of the newer buzzwords.Well now that you've put yourself out there ... which books would you recommend?I have read the Phoenix Project, and loved the book. Started reading The Goal (the book that Phoenix Project based itself off of), and find myself wanting more.On Wed, Jun 17, 2015 at 1:51 AM, Stephen Potter <s...@unixsa.net <mailto:s...@unixsa.net>> wrote:Surprisingly, it isn't that difficult to learn as much as you need. Yes, there's a lot about business you can learn, but you really don't need to learn that much of it. I got an MBA several years ago, but honestly, I could have read a basic accounting/financing textbook, a basic management textbook, and a basic business law textbook and gotten pretty much everything I've used since then. Most of what you need to understand is the basics, the terminology, and some of the newer buzzwords. Once you've got that, you just need to be willing to listen to people and ask a few questions. And, quite often, the questions you have to ask are "what would it mean if...." or "how could you see that happening" when someone tells you something; just turning their question around on them to get more information. It is amazing how people can see 90% of a solution, but miss the last step. And, if you can provide the last step, you're a genius, even when it is something really simple. I once - many years ago - got a $500 bonus (from a director) because I was willing to ask him if I could move an external disk from one machine in one town to another machine in another town and explain to him how it related to his business (when one system ran out of disk space, it killed one or more long running jobs that cost several hundred dollars in lost productivity each). I was in my early-20s then, and simply a contractor who didn't know any better than to ask! -spp On 6/16/2015 2:50 PM, Atom Powers wrote:+1 million. I wish I had the time to learn that skill. On Tue, Jun 16, 2015, 11:13 Stephen Potter <s...@unixsa.net <mailto:s...@unixsa.net>> wrote: Several others have already mentioned that it sounds like there'smanagement problems at several levels and titles won't help. Some havementioned the split management/technical track with management roles such as Lead, Supervising, Managing, etc and technical advancement through Distinguished, Principal, Fellow, etc titles. What I see as the underlying problem is that no one has been able to relate what IT does to the business goals and values to help the executives really understand where IT fits. You mention that IT falls under the VP of Administration, which generally contains groups like real estate, facilities, logistics, HR, and perhaps regulatory compliance. This is all just overhead and costs of doing business. None of these have anything to do with revenue and enabling the business. If you really want IT to start to get some respect, you need to have someone who can talk the language of the executives and tie their goals into what IT can provide. Business will talk about market share (acquiring/retaining customers), competitive differentiation, business innovation, and profitability. You need someone who can take those and show how IT can help develop multichannel (buzzword: omni-channel) services that provide competitive differentiation and attract new customers. Someone needs to talk about continuous delivery of IT services that enable other business units (R&D, sales, etc) to change the way they do business (mobility, supply chain management, etc) and speed up sales (buzzword: "inventory turn", "sales close cycle") or even enable entirely new products and services (buzzword: "time to market", "go-to-market strategy"). And, finally, you need to be able to show how IT can help reduce costs across the entire company (not just reducing IT costs), reducing SG&A (sales, general, and administration), and how the other things I've already mentioned can reduce unit costs (development cycle, manufacturing costs, etc). A couple of examples I can think of, which wouldn't necessarily be relevant to your specific company. One large fashion retailer I worked with used to ship store layout, discount information and sales reports to each of its several thousand stores weekly. They were spending hundreds of thousands of dollars a month on FedEx shipping alone. IT was able to work with the store operations teams to figure out how all that information could be safely shared through remote access across the network. The savings to the company was millions per year. Another company had dozens of desktops in their distribution facility where product pickers went to print off pick lists for packaging and shipping. The conditions in the DF were such that the desktops and printers crashed regularly, requiring pickers to search for a working desktop/printer combination, and slowing them down. IT had a person onsite in the DF full time, just to handle desktop/printer issues. Orders were batched every couple of hours, so there were often times when the pickers had nothing to do. IT was able to work with distribution to come up with a combination of thin-clients, touch screens, and tablets that enabled more real time access to the lists, reduced errors, reduced outages (to the point they pulled the IT guy back to the office and redeployed him to do higher value activities), and reduced costs. It also enabled the distribution to collect efficiency data, which subsequently led to re-arranging how products were stored in the DF. In order for IT to get respect in many companies, there needs to be a strong leader who can tie IT to the business, rather than just being another SG&A cost. -spp On 6/9/2015 9:52 AM, Tim Kirby wrote: > I'm not sure if this is actually a repeat of past threads, we > spend a lot of time talking about this sort of thing within > "IT organizations" but I'm not sure I've seen this one. > > $WORK is a computer system manufacturer. Thus it is largely > technical with an R&D component building software and hardware. > Within our IT organization we have two or three highly > experienced sysadmin/devop/engineer types that could hold > their own against any of the R&D "Principal Engineers" and > do, at time, consult for R&D. > > The politics and handling of "IT" is every bit as dysfunctional > as you might expect, however, and the job titles and "official > status" of these IT guys make them almost indistinguishable > from a front line help desk tech (no, I'm not dissing the help > desk tech, don't go there). > > I am interested in hearing from anyone who works with or has > worked with companies that have actually recognized such > senior folks within their organizations. One term I've heard > the term "IT Fellow", but I'm really not hung up on the name > so much as the perceived role within the company and how such > people might appear in the company ranks. > > I suppose I should add that the "VP of Administration" who is > the ersatz CIO (in terms of corporate position) denies all > CIO responsibility, indicating that the Director of IT, his > immediate report, has all IT responsibility. There is an > "Office if the CTO", I don't know if it would be possible to > hang these highly senior IT people off that instead. I do > realize that the de-emphasis of IT at the VP level probably > means we're all screwed. Sigh. > > Thanks for any input... > > Tim _______________________________________________ Discuss mailing list Discuss@lists.lopsa.org <mailto:Discuss@lists.lopsa.org> https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/_______________________________________________ Discuss mailing list Discuss@lists.lopsa.org <mailto:Discuss@lists.lopsa.org> https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/ -- Joseph A Kern joseph.a.k...@gmail.com <mailto:joseph.a.k...@gmail.com>
_______________________________________________ Discuss mailing list Discuss@lists.lopsa.org https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
