DevOps has become a huge buzzword recently, and several colleagues
had been recommending this book.
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 <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> wrote:
Several others have already mentioned that it sounds like
there's management problems at several levels and titles won't
help. Some have mentioned 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 [email protected] <mailto:[email protected]>
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 [email protected] <mailto:[email protected]>
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 [email protected]
<mailto:[email protected]>
_______________________________________________ Discuss mailing
list [email protected]
https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss This list
provided by the League of Professional System Administrators
http://lopsa.org/
