Search BMC.com
Search

Share: |


My car battery died last week.  Since I've never been very handy with tools and I know very little about car maintenance, taking the car in for an oil change and replacing some tires are about all that I've done; I decided to take care of this myself as the first step towards becoming more knowledgeable about auto repairs.

 

I read the basic instructions for what to do and got a replacement battery from the store.  Being not handy at all, I just had some basic tools (screwdriver, wrench, pliers, and hammer) available.  I decided to give it a try with what I've got.  Once I popped the hood and took a close look at how the battery is attached, I realized that this isn't as easy as I had hoped.  The battery was held in place with a strap that's screwed in on both sides.  The clamps to both the positive and negative terminals are screwed in and pretty tight near the top area of the battery.  The battery itself is positioned a bit lower than rest of the engine so it's a bit difficult to access it.

 

I began with trying to remove the clamps.  The battery was quite old and the screws hold the clamps on were stuck on pretty tight.  I started with the wrench but it was too big to fit around the bolt of the screws.  I then tried the pliers.  I got a hold of the bolt but it didn't hold it very well and I didn't have much leverage to twist it.  Every twist seems to just slide the pliers against the bolt instead of actually loosening it.  After about 15 minutes of struggling, I managed to take off one clamp.  I decided to take a break and try to take off the strap instead.  This proved to be even harder.  The strap was bolted down on both sides towards the bottom side of the battery.  It was very difficult to reach and impossible to see once I have my hand over it.  I tried using the pliers and guiding it by feel alone, but without being able to see what I'm doing, it was near impossible to get a good hold of the bolt to loosen it.  After about 20 minutes of struggling and cursing, I gave up.

 

I live in Phoenix and it's about 105 degrees in my garage.  So after over half an hour of this, I'm drenched in sweat and I've only gotten one of two clamps off and none of the bolts holding the strap.  It was pretty clear to me that I don't have the right tools to do this.  I went online, went over a few how-to guides and videos on battery replacement and went to the store to get the tools they recommended.  I picked up a set of socket wrenches, a wrench extender, and a grip handle.

wrench.jpg

With the 10mm socket wrench, the fit was perfect for the bolt on the battery clamp.  Attaching the handle gave me a ton of leverage so the stuck bolt wasn't a problem at all.  With the new tools, I got the remaining clamp off in a matter of seconds.  Now onto the harder task of removing the bolts on the strap at the bottom.  Here was where the extender came in handy.  Again the 10 mm socket fit the bolt perfectly.  With the extender, how low the bolts were wasn't a problem at all.  I attached the handle to the extender and started taking the bolt off.  Again after mere seconds, the bolt was off.  I repeated this with the other side.  While I was taking off the last bolt, I caught myself with a silly grin on my face.  This was just so much easier, and compared to the half hour of sweat, pain, grunting, and cursing, this was so much more fun!  So within 10 minutes of using my new tools, I was able to get the old battery off, place the new one in, get it strapped down, and get the clamps back on the terminals.  Mission accomplished!

 

After this exercise, as I thought about the painful experience I had before getting the right tools and how easy the task became after;  I realize that this is exactly what many of our customers go through.  When we talk to them before getting our automation solution, we hear many horror stories of repetitive manual tasks taking days, weeks, or even months to complete; mistakes were common and many times things would need to be redone again by hand; late nights and long weekends spent firefighting due to outages caused by human error.  Things were painful, tedious, and took so long that they were always behind.  Many of them are on the verge of burning out.

 

A few months later, after they've adopted our solution, we would go back and see how things are going.   The first thing we always notice is that everyone seems happier, more relaxed.  They would tell us all the cool things they've done using our tools and how much productivity and stability have improved since implementation.  They were happy, excited, and many of them would have a smile on their face while they told us of their progress, probably similar to that silly grin I had on my face once I started working with the right tools for my battery.

 

Throughout this ordeal of replacing my dead car battery, I gained a deeper and very personal appreciation of the fact that, having the right tool for the right job not only makes it much easier, but also much more fun!

Share: |


"Oh, that's the other guys' problem!" If I had a $CURRENCY_UNIT for every time I hear that phrase, or variations upon it…

 

In talking to organizations large and small about automation and the benefit it can bring to them, quite often it turns out that the team which I am talking to is only involved in a small part of a much larger process, with many other, different roles involved in completing the request. This usually comes up in conversations where we talk about the annoying, boring, repetitive and error-prone tasks which they have to complete, and which could and should be automated away so that they can concentrate on the interesting, rewarding, highly visible, and value-adding parts of the job. It gradually becomes clear, however, that (to pick an example at random) a naked VM is not the users' requirement.

 

Users want a server that's ready to go into production, with an updated operating system, all the infrastructure agents (backup, antivirus, monitoring, management, etc.), the organization's current security policy applied, all the security credentials in place, and so on. This is of course the easy case, compared to those users who want a clustered database, a replicated and mirrored content-management infrastructure, or a fully-fledged web service ready to be exposed to the rigors of the public internet.

 

However, the conversation with the technical team tends to bog down at this point, as they are focusing on their small part of the picture. They build a VM or two, and pass them down the line. Sure, automation could shave some time off that, but there's a chunk of incompressible machine time in there - so what if we can take the task from thirty minutes to twenty?

 

What this narrow focus is not showing is that after they chuck that completed VM over the wall to the next team, there is at best a communication lag until they pick up the request: until, say, the middleware team gets around to installing their components into the VM. That is the ideal case; in most situations, what happens is that some core component is missing, or there is a version mismatch, or the VM is not reachable in the first place due to a missing configuration at the network level, and so what happens instead of work is a meeting.

 

blamestorm.jpg

There is nothing wrong with meetings per se, but this is a particular type of meeting: a blamestorm, kind of the opposite of a brainstorm in that all the effort is going, not into achieving a productive result, but towards directing the blame for the delay at another team.

 

Meanwhile, the requesting user is fuming at how long IT takes to deliver "a simple request", and phrases like "I have no idea what they do with all their budget" start to be heard.

 

The value of automation is this: not shaving a few percentage points off the execution time of the task, nor getting rid of competent and valuable employees, but in making the overall process joined up. Being able to deliver a full stack of components, integrated and ready to go into production, without the long-winded game of Chinese whispers which is the typical process at many IT organizations, is what delivers on and exceeds customer expectations.

 

I have been talking about this concept of orchestrationfor several years now, and yet it still comes as a surprise in many situations. Stories abound of large automation projects, their promise and their failure; but in every case the limitation appears to be what was automated, rather than the automation itself. Every manual step is a bottle-neck and a chance to introduce delay, errors, mis-understandings, and gaps in the documentation. On the other hand, we have customer processes which we were able to take from weeks to hours. Let me repeat that: from weeks, to hours. How valuable is that, when it makes the difference between the marketing campaign launching on time - or not? Between the new tax rate being applied correctly - or not? Between leading your market - or lagging behind?

 

Next time you are looking at your small part of the problem, take a step back and think about the step before and the step after, and the steps hidden in between the visible steps. I guarantee you'll be surprised at what you unearth.

Share: |


Not that will be the first to say, but virtualization has really come into its own. One analyst prediction shows over 20% just in 2011 for virtualization infrastructure solutions. Virtualization is no longer a neat tool for the lab and for developers. It is an enterprise-level solution for getting the most out of your data center hardware, and to reduce capital expenditures going forward. This whole process has happened in the midst of the cloud computing revolution, which has both turbo-charged the growth of virtualiztion, but also overshadowned some of the real, fundmental values of building out a virtualized infrastructure.friends.gif

When IT operations management software joins the party, the message has become more muddled. "Well, I am using stamping out virtual templates faster then you can say the word 'virtualization' now. Do I really need automated provisioning, patch management, or compliance management?" "I am baking my apps into my virtual templates. No need for automated deployment". I think it is safe to say that the perception of IT management is lagging virtualization adoption. That amazes me, since automation is one the best ways, if not the best way, to make virtualization. So, why can't virtualization and IT operations management be friends? Well, let me state the obvious. THEY CAN!

 

There are many reasons, and we could spend hours pontificating on it. But let me recount the top hits:

 

1. How do you know what you have?

     The good 'ol spreadsheets doesn't hack in VM land. Virtual machines are being produced at an amazing clip, and they aren't staying static either. Virtual motioning can shuffle running VMs from one cluster to another in seconds. If you are really going to use virtualiztion in production, you need to integrate your virtual systems in your Config Mgmt Database (CMDB) in real time. You might say - "My virtual console says it all". Not if your database is physical, and your web servers are virtual...

 

2. How are you going to build it?

     Virtual templates are extremely powerful - allowing you to reproduce an OS again, again, and again. But we run into the same problems we did with OS imaging earlier in the decade. The more you include in the template, the more likely you are going to have to version it every time one of your apps changes. Oops - need a new version of our monitoring agent. Need to update all of my virtual templates. It makes a lot more sense to use VM templates to stamp out a "thin" OS, and then provision applications on top it like building blocks. Provisioning automaiton is your friend again. And what about the complex applications like application servers and databases. Those tools may need to be install on multiple nodes, inter-connected in a multi-tiered infrastructure. Application automation to the rescue!

 

     And what about the underlying virtual infrastructure. Who is building that? It is fine to install from CD in the lab, but if your business wants to quickly stand up several hundred virtual machines, you need to automate that install. Unless you want to stare at screens pressing buttons for days on end. If that is your thing, well, go for it...

 

3. How do you run it?

     How is that we have such selective memory in IT. Virtualization is new! Actually, no. Ask the mainframe guy with the great beard in the next cubicle. Same thing with management. Just because you virtualized a system, doesn't mean you virtualized IT management. You still have maintain configurations and compliance over time. How will you know when you need more, or when you are not using your capacity? Capacity Management tools. Have virtualized applications become more reliable? Maybe a little (less pesky hardware), but just look at the news to know that clouds can fail too. So, you still need your powerful systems monitoring tools. And you need to integrate with the rest of your physical systems.

 

So, do you want your virtualized infrastructure to grow and thrive. Then get your VM  and your IT operations teams in the same room, buy them pizza, and tell them to get to know each other better. They are destined to become best friends.

 

 

Check out this link for BMC's solution to get the most out of your virtualization infrstructure.

Michael Ducy

What's Missing?

Posted by Michael Ducy Sep 13, 2011
Share: |


A recent article in Bloomberg Businessweek spoke about 2 automation startups, Chef and Puppet, that could help companies ease the transition to Cloud in their organization.  When I first read the article with my insider knowledge my response was "Yeah, no kidding, automation is critical."  But when I stepped back and looked at the article with a less biased view I understood better what the article was trying to get across.

 

The article ended with the statement:

 

"Investors have bet $20.5 million that Puppet and Chef, competing server-management tools, will be at the forefront of cloud computing."

 

Taking a moment to digest this, I realized something; most companies still don't get it.  Most companies still don't understand that datacenter automation is the keystone to getting any meaningful initiative accomplished in their organization.  Whether is it Cloud, IT Auditing and Compliance, or Application Release, datacenter automation is the key requirement needed to accomplish these goals.

 

But automation is nothing new.  As the article pointed out, Puppet has been around since 2005 and was founded by a former employee of Bladelogic, BMC's Datacenter Automation Suite.  The "Big 3" - HP, IBM and CA - all have their own automation solutions, and there are a myriad of other solutions from smaller niche players.  So with all this percieved saturation in the market, why do Venture Capitalists still feel that there is significant room for growth that they would invest $20.5 million in what appears to be an established market?

 

Here are some possibilities:

  • Current suppliers of automation software do not meet customer needs - If this is the case, what should the current suppliers be offering that these startups do?
  • IT Organizations are reluctant to adopt automation - If this is the case then there is still significant market share for the startups to claim. What needs to be done to increase adoption?
  • Barriers to enter the automation market are low, especially with an open source model - Thus one can expect startups like this to pop up from time to time.

 

What are your thoughts?  Why do you think that new entrants are able to enter the datacenter automation space?  What should automation vendors be doing differently to meet the needs of their customers?  Leave your thoughts in the comments below.

Share: |


Locomotive_MC900233994.JPGThey seemed alive – living, breathing monsters that captured you attention while moving goods and people across continents.  But, despite US government standardization of designs in World War 1, they were all custom-built.  The diesel-electric locomotive proved not only that standardized components were easier to manufacture and maintain, but also matching modular power to workloads.  The economics of standardization were so overwhelming that steam locomotives disappeared over only a few years – some being scrapped only a few months after delivery.

 

IT processes are similar to steam locomotives when executed manually every time an action or procedure needs to be accomplished.  Even rigorous documentation of every recurring action or procedure in run books is only a guide for the many different individuals doing the manual work.  The standardization of procedural tasks is useful when contemplating automation, as you have already done the hard work of determining the routine and repetitive tasks that need to be consistently executed by lower-skilled staff than required to define the string of tasks.  Automating run book workflows is much like the effect of dieselization on railroads – the liveliness of accomplishing tasks manually is supplanted by the less-involving effectiveness of IT process automation.

 

Automation does not need to start with large complicated processes.  In fact, you will most likely have more success beginning with a simple procedure that has a limited impact in order to develop best practices for planning and implementing automated processes that will lead to wide adoption across your organization.  Diesel-electric locomotives started small, doing uninteresting, tedious work as switchers to prove their worth.

 

Diesel-electric proved the strategic value of standardized, modular power units when the opportunity opened to supply power for increasing train traffic after World War II.  Technology elements converged at that time to produce the capabilities at the right time to motivate rapid adoption.  Part of the success was enabled by enterprise acceptance of combining power modules to address varying requirements rather than purchasing and maintaining many customized locomotives.  Costs and operations were predictable while the enterprise could easily adjust to different business conditions by reconfiguring standard modules rather than enduring the costs and delays of acquiring new customized motive power.

 

IT process automation technologies are here today that enable you to address task automation in the many ways that will benefit your environment.   Significant components of your IT process automation puzzle may already be in place or under consideration:  Service Desk/Incident Management, Change Management, discovery, service dependency mapping, configuration change management, event management, workload scheduling, etc.  You would not want to replace these solutions with a single solution after investing in the adoption to solve specific issues you have had in the past.  A workflow orchestration solution augments your foundation automation tools in two ways:  1. extend foundation automation to execute manual tasks that complete key processes of these tools and 2. unify foundation automation into fully automated, end-to-end processes – what you define in your IT processes.

 

  1. Foundation automation tools focus on essential features such as filtering events or guiding agents through process tasks.  Workflow orchestration implements routine and repetitive tasks upon automatic triggers or selectable options built into the User Interface (UI) that is the agent’s primary workspace.  These can be simple tasks to enrich event and incident information for faster determination of root cause that can advance to decide the best reaction to queries and apply known fixes.  Another area of task automation to consider is fulfillment of simple self-service requests, such as password resets and email quota increases.
  2. Unifying automation tools across functions is a more sophisticated use of workflow orchestration that is a natural advancement from extending processes of foundation tools.  Internal process of a tool, such as configuration change jobs may need to be approved by the Change Approval Board (CAB) before executing in order to meet enterprise process governance or ensure compliance for audits.  Automatic creation of Change Requests upon submitting a configuration change job eliminates tedious manual effort, not to mention training on multiple tools, to enforce process compliance and documentation of changes to simplify audits.

 

You will identify more of these opportunities to improve efficiency and relieve your staff from repetitive tasks to put more effort into higher value use of their skills.  Railroads benefitted from standardized power with greater capacity to move goods and people at lower cost.

 

Continue the conversation on-line with your comments or extend the conversation to cover related topics, such as how reusable workflow segments resemble the ability to reconfigure motive power modules to adapt quickly to changing requirements with existing assets.

Filter Blog

By date:
By tag:
It's amazing what I.T. was meant to be.