Share: |

BMC currently offers two levels of support, Continuous and Premier. Continuous offers business hours support for severity 2, 3, and 4 and a 1 hour SLA 24 hours/day, 7 days per week for severity 1 issues. Premier offers a 1 hour business SLA for severity 2, 3, and 4 and a 1 hour SLA 24 hours/day, 7 days per week for severity 1 issues. But the difference is not just in the SLA and that is what I want to discuss.

When you purchase Continuous Support, your cases are handled by our global support team, and are routed to the location whose team who is working your business hours.  So, to put it bluntly, your issue will land in a pool of engineers and one of them will take your issue and follow it through to completion. There are so many times that I am in an escalation with one of our customers where they say to me, “I only want Jimmy to answer my issues, I get him a lot and I respect his technical ability.  Why don’t you know my environment? Everyone at BMC should know what we have installed and how it is implemented. Why don’t you know my use cases?”

2011 BMW M3 Coupe 2011 Mustang GT Front Ends 2 - High Resolution Photo 20.jpg


So here is where I want to introduce one of my analogies for which I might be getting famous for. When you are buying a car, you may choose to buy a Ford or BMW, depending on what you expect from the car and what you can afford. Let’s say you could afford either, and you realize that the BMW will cost you more than double than the Ford will. Both cars will get you from point A to point B, one may get you there faster. However, I personally live in the US and not Germany, so pretty much it will get me there in the same amount of time. So, al things being equal, why would you choose a BMW over a Ford? Why would you waste your hard earned money?


Well, I know why I made this choice. For me, It is because of the level of attention I will receive when things do not go right for me. For the most part, this is why you purchase maintenance, to ensure BMC will be there when things go wrong.  If you buy the Ford, and your car breaks down, you will bring it to the dealer and your spouse might have to drive along with you so you can make it home. Then, you will have to decide who can work from home the next few days since your car will be out of service. However, if you buy the BMW, in my case, the dealer comes to your house drops off a free rental car and drives the car to the dealer and drops it back off to your house when it is fixed. (I have a sweet deal going, I know!)


Here is my situation. I have an expectation that this is what happens when my car is broken. I believe that no amount of negotiating at the Ford dealer would get me service like that. So, yes, I chose to pay more for my car to ensure I will receive the service I expect which I now rely on. I am effectively making my purchasing decision based on the support I will get. I am in effect chosing Premier Support.


Another great reason to purchase premier support is for the proactive nature of the offering; again, parallel to my choice to purchase a BMW. When my car needs its yearly service and oil change, etc. I don’t need to call for an appointment, they call me. With premier support you will have an engineer who is focused on your environment, who can recommend service packs, when he feels you will benefit from the fixes in that pack. He (or she of course!) can discuss the pros and cons of the install and help you plan for the implementation. This is something you would not get from Continuous support, because as much as you would want this, of course you see the benefit, it is just not part of the offering. Just as with the Ford and the BMW, you both have access to the service center as all maintenance customers have access to support and related service packs, however, with Continuous, you will have to call BMC, explain your environment and discuss whether or not the service pack will benefit you. With Premier, the conversation is more about when you should implement the service pack and how to plan for that.



My conclusion is, Premier Support is not for everyone. However, if you find yourself in a position where you want a single point of contact to understand your environment and be an expert in the solutions you own and always looking out for your best interest you should consider purchasing Premier Support. If you equate your time into dollars, I’m sure you could convince your management that it is money well spent.


I will end with a shameless advertisement. If you are interested in purchasing Premier Support or for more information on Premier Support, please contact Kevin O'Donnell in the US, Ben Creasy in EMEA or AP, and Monica Padialla in Latin America.


Share: |


A big challenge for companies was to accelerate development of their business application to provide more value to their customers or to address a new market before their competitors.   J2EE platforms provide this value allowing developer to not take care of targeted infrastructure and to easily reuse existing modules. To simplify, now developers only take care of the business logic and don't need to think about the fact that the application will run on a cluster, on a specific OS using a specific database, they don't need to implement messaging services, basically they don’t need to take care on low layer and can focus on business logic.

The point is that if developers don't need any more to take care of low level layers because of the abstraction layers provided by J2EEplatforms, this last one still needs to be setup, managed and maintained by operation. If J2EE platform allowed more productivity for development it added complexity for operation. Bottom line is that to move application from test to production could take more time than to develop  the application itself and operation becomes a bottleneck.


More and more company try to automate J2EE platform management and many of them have a lot of scripts to do so. Each time an upgrade is done they need to review their scripts or to rebuild them. The need to have solution to automate this area is clear and there is some try to use server automation tools to achieve this. Usually, server automation tools won't provide so much value than homemade scripts. Why? Because server automation tools are server centric when an application, a J2EE platform are not server centric. For example, when I want to configure a JDBC provider, I don't want to setup this service for a specific OS instance or physical server, I want to setup this service for a Java server (JVM) or a Cluster that are part of my J2EE infrastructure. And on the last case, Cluster may means several physical server at the low layer level.


For automation, in J2EE context, I need a tool that allows me to create a package for a service or an application that is independent of the topology of my J2EE infrastructure as they maybe different on the different environment used to test, qualify the application before pushing it on production. Without this kind of feature, that means I need to create a package for each kind of topology and environment which seriously decrease automation capabilities and value.

Being able to manage J2EE platforms through the abstraction layer with topology independency capability is even critical with virtualization and Cloud computing as topology could move very fast.


Conclusion is that to get real value from automation on J2EE platforms, the automation tool needs to be able to address those platforms through their native API with enough abstraction, package parameterization and topology independence enablement  capabilities. By the way, low layer management capabilities are also required for initial provisioning of J2EE infrastructure. The good news is that BARA could help to achieve J2EE platform management automation. First of all, BARA is on top of BSA that allows to do initial provisioning of J2EE platforms like installing WebSphere or WebLogic. But ARA provides capabilities to not be server centric but to target J2EE objects with enough abstraction layer to act on the same way for different J2EE platforms and to provide topology independency. What I mean here is that with ARA I could deploy the same application package to either standalone server (JVM) or to Clusters which enable real application release management. I get J2EE platform management automation with infrastructure independency from physical severs to cloud through virtualization.

Share: |

tmbBlazingTrails.jpgI'm thrilled to share that on July 12, BMC announced our newly integrated Application Performance Management solution for the management of enterprise, software-as-a-service (SaaS), and cloud applications within a single operations management framework.


BMC is blazing the path to managing end user and application performance for new and modern application and cloud architectures, by providing visibility into the performance of applications running inside and outside the data center. As more and more organizations are moving their applications to leverage SaaS and cloud delivery models, it’s imperative that enterprise operations teams gain visibility into the service levels being delivered by the SaaS and cloud providers.


As applications move to the cloud, many organizations are relying on application and content (e.g., videos, graphics) and application acceleration providers (ADN/CDN providers) like Akamai, to ensure that their service levels are met. It’s essential to have visibility into application performance – accelerated or not – to know if and when to take advantage of acceleration providers. With BMC, you have the ability to do just that. 


Application Performance Management from BMC provides the quickest and easiest deployment and fastest time to value for optimizing the performance of higher scale production applications. In fact, BMC provides measurable results within hours; with the flexibility to add incremental value over time. For example, you can start with monitoring your end users in real-time, and quickly add the ability to collect deep diagnostics and trace transactions within the application tier. Next, you might monitor key application elements, such as your databases, packaged applications, and middleware. Ultimately, you can combine your end user, transaction, application element, and infrastructure KPI’s and events into a behavioral analytics engine to accurately isolate the root cause and drive preventative repairs of application issues; including the rollback of mis-configured applications and the automated release of application fixes, as well as re-allocation of workload. 


If you want to learn more about Application Performance Management from BMC… check out

Bill Robinson

Where's the OS?

Posted by Bill Robinson Jul 10, 2011
Share: |

Often one of the first questions a customer asks me about our application suite is "We are a Linux/Solaris/Windows shop, will your applicaitons run on that?".  To which I want to respond "Who cares?". Of course I don't and I tell them yes we support X.beef.jpg


Sadly we still have to ask this question because there are applications that will only run on certain OSes.  But most applications, and most business applications will run in an application server that is cross platform (eg .NET, J2EE), so the OS really doesn't matter.  And those that don't are usually ported to support multple operating systems.  So we can argue about the merits of Windows over Solaris over Linux but at the end of the day, unless you are doing something very specific that only one OS supports, you could provide your application from almost any operating system.  And not even a full operating system - Microsoft has it's 'server core' version of Windows and Linux vendors have their 'Just Enough OS' or 'Appliance OS' variants that provide enough operating system to run your application but none of the services you'll never use.


The OS is just another part of the infrastructure service you provide.  The OS now is the application server stack - J2EE, .NET, PHP.  It's trivial to manage the OS with an automation tool (eg BBSA) to push configs, security lockdowns and patches and that is even simpler with the JeOSes.  Until the OS becomes something akin to firmware that needs infrequent updates all of those mundane activities must be done.


To manage that new OS stack (the application server) there are similar management tools to manage configs, security and patches - such as BARA (for application servers) and BBDA (for databases).  These tools let you achieve the same automation as BBSA lets you achieve for servers.  You can also use these tools to push our your applicaitons and code updates.


To really get to this level of nirvana there's likely a lot of policy changes that need to take place. 

  • The one-off servers must be gone. 
  • Letting developers decide to stick with Java 1.ReallyOld.Version isn't acceptable. 
  • You need to create classes of servers and cluster them together. 
  • Standardize your builds. 
  • No one gets access to the OS except the infrastructure team and then only when the automation tools fail.
  • No one gets access to the application server layer except through the automation tools and perhaps any application-specific management tools needed.
  • The personal relationships admins seem to develop with the servers they manage need to be dissolved.  The server is a throw-away, replaceable, rebuildable entity.  Make your servers names read like a bunch of UUIDs instead of 'Bart' and 'Homer' to re-enforce that.


You are building a 'cloud' of .NET or J2EE service.  It's a 'private cloud' or 'utility computing'.  Call it what you want.  You're pushing applications into the application 'cloud' you've just created and charging for use of the resources (whether internal chargebacks or otherwise).  When an OS/application instance fails there should be capacity already there to take over while the hardware or VM is replaced and added back into the pool. 


Cloud right now seems to be about throwing out a bunch of bare OS instances.  While that's all well and good and there are definately still challenges to resolve there, the fun part is going to be doing to the appserver what we've done to the OS.  For the most part it's a step beyond what is currently out there because we still think about the OS as the most granular and measurable unit.

Share: |

Picture1.jpgI’ve been in the IT industry a little over 13 years and even though I’ve not been completely around the block I’ve been around long enough to know that the one thing we all can do to make our jobs a whole lot easier -  is to “KISS.” 


Years ago my father introduced me to the KISS principle which stands for “Keep it Simple Stupid” or “Keep it Short and Simple.” – there are many derivations.  And at the time I thought he was calling me both stupid and a simpleton, so I wasn’t exactly open to his words of wisdom.  But I soon came to learn the true meaning of the KISS principle.  Years later I still subscribe to this time tested idea and think it’s needed more than ever, especially in this fast paced world.


And here’s why…


In the world of IT and enterprise management software we are constantly bombarded with new technologies that are promised to revolutionize the datacenter.  Two of latest and greatest technologies today are cloud computing, which can simply be thought of as virtualization on steroids, and software as a service (SaaS) – where services are hosted centrally and delivered on-demand to users via the web. 


Now I’ve noticed during my jaunt around the block that with any new technology - be it client-server, x86 virtualization, cloud computing or SaaS comes added (IT and business) risk and increased IT complexity.  One of the primary reasons for the increased IT complexity is for the  simple fact that new technology never immediately or completely replaces the old technology.  This leaves IT to manage multiple platforms (physical, virtual and cloud), operating systems (UNIX, Linux, Windows, iSeries and maybe even Mainframe) and hypervisors (VMware, Xen, Microsoft HyperV, etc).


So what’s an IT person to do to make it through the day?  You’re likely one of the 85.8 percent of males and 66.5 percent of females in the U.S. who work more than 40 hours per week, so your time is limited and you need to be as productive (i.e. efficient + effective = productivity) as possible. 


Here’s a great example of where you can apply the “KISS” principle… 


“For any given IT project, whether you’re implementing a performance management solution, launching a new capacity management process, or expanding your IT reporting deliverables, begin by identifying what’s mission critical and what isn’t.  Start with your critical servers/apps/services that drive your business.  The other “stuff” can wait – most of the time.”


Case in point: I’m continually asked by customers, “how do I do full-blown capacity management on all of my 2,000 servers when I only have one full-time equivalent (FTE)?  And my reply is, you don’t.”  Keep it simple…


Communicate, up front, with your stakeholders that you will not be doing comprehensive capacity management (i.e. analysis, planning and reporting) on every server (physical and virtual) in your infrastructure.  It’s simply not practical, possible or cost-effective if you have thousands of systems in your environment and limited resources – which is the case in virtually every organization on the planet.  The criticality of the server should define the attention it receives.



Start by identifying the mission servers in your infrastructure and begin collecting performance data from them first.  Many customers collect granular, (10-second sample rate) process-level metrics from critical systems and (1 – 5 minute sample rate) from non-mission-critical tier-2 or 3 systems.  Remember, there’s a cost associated with collecting data in terms of storage space, managing the data, etc.  So the goal should be to only collect the data you need to do the analysis, reporting and modeling for that particular system, application or service.   


Define the server(s) to application(s) relationships, this can be done automatically, with a good discovery solution, or manually (if you have a lot of time on your hands) - so all of your activities (i.e. analysis, reporting and modeling, etc) are in the context of an application or service (e.g. online banking) and not and in IT speak.  Bottom line anytime you communicate your results to stakeholders make it “business relevant” in a language that they understand (e.g. talk about “service” performance not “server” performance.)


If you want to learn more about how to apply the KISS principle to IT read the white paper, “Align IT Operations to Business Priorities”


I swear by the KISS principle, but if you’re still skeptical don’t take my word for it, take theirs…


  • Everything should be made as simple as possible, but no simpler.” Albert Einstein
  • “Our life is frittered away by detail... Simplify, simplify, simplify!”  Henry David Thoreau
  • “There is no greatness where there is not simplicity, goodness, and truth.” Leo Tolstoy


Want to learn more…


    Share: |



    When I worked in an operations capacity, we would build virtually everything we needed.  Need a new monitoring tool?  Build it.  Need a log analysis tool? Build it.  Need a new critical messaging system? Build it.  While this worked to "save the company money", and solved the immediate need of the department, it was by no means a fool-proof plan for success. 


    The biggest flaw was in the huge technical debt we were creating for the organization.  For those unfamiliar with the term, a technical debt works very similar to the concept of financial debt.    You borrow money, for some immediate benefit, and over time you have to pay it back.  There are of course different payment structures for financial debt.   You might make periodic payments for a fixed term until the loan is paid off.  You may pay only the interest on a periodic basis, hopefully planning to pay off the entire debt one day.  You might make periodic payments leading up to one large lump sum.   In the financial world, these payments are known as servicing your debt.  Technical Debt works the same way and needs to be serviced periodically.  Feature requests, bug fixes, and support issues are all ways you service your technical debt.


    Some technical debts may be small.  For instance, a script that you wrote to perform a specific task.  That technical debt is analogous to buying a cup of coffee on your credit card.  In and of itself, this debt won't create too many problems.  This kind of debt can cause problems when you accumulate too much of it.  Go to the coffee shop multiple times per day, every day, and soon the debt starts to pile up.  Same thing with your scripts.  Develop too many of them, too often, outside of an automation framework, and you'll end up spending all your time maintaining and supporting these scripts; thus servicing your technical debt.


    Some technical debts may be much larger.  For instance a company I talked to recently wanted to build their own cloud management software leveraging open source technologies.  This creates a huge technical debt for their organization comparable to mortgaging your house.  This debt includes the software development, the ongoing support of the software, feature enhancements, and bug fixes.  In addition to the increased work that is required, there is a long lead time until you can start to leverage the investment you are making in the software you a building.  Compound that with the lack of industry knowledge and  technical breadth that your team could be missing, and your debt increases substantially.


    While I acknowledge that not all pieces of software in an organization will be Commercial Off the Shelf software, it is important to understand what technical debts you are accumulating when Building Your Own.  Most organization's goals in Building Your Own is to save the upfront costs of purchasing the software.  But what most organizations forget that this comes at a tradeoff of a huge technical debt they incur.  In making these decisions, organizations should ask themselves; Is this the best decision for the long term future of the company?  and Does this work fit the core competency of my company and the goals and objectives the CEO has laid out for us as a whole? 


    And always remember the real question is never "Can we?", but "Should we?"

    Share: |

    Top10.jpg In the coming day’s thought leaders from across BMC Software will share their knowledge, experience and random thoughts on how you can become more “proactive” when it comes to IT operations.  You’ll find their posts to be educational, informative as well as humorous at times.  So I thought I’d start things off by defining the word “proactive” and providing a top-10-list of the reasons why you should strive for proactive IT operations.  Because until you’re clear on what we mean by “proactive” and understand “why” you should do it, there’s no reason to learn “how” you should do it.


    If you look up the word proactive in you’ll see that it’s an adjective.  And if you remember back to grade school adjectives modify a noun or pronoun by describing, identifying, or quantifying words, and normally precede the noun they’re describing.  Here’s the definition of proactive…


    pro·ac·tive [proh-ak-tiv]

    Serving to prepare for, intervene in, or control an expected occurrence or situation, especially a negative or difficult one; tending to initiate change rather than reacting to events; anticipatory: proactive measures against crime.



    The opposite of “proactive” is “reactive” which means you’re responding to incidents/events – many of which have caused service degradation or downtime.  You’re continuously fighting fires, reacting to events around you, and are generally speaking, in a defensive posture.  But in today’s fast-changing, cost-conscious world, where IT complexity & risk are on the rise and end-user quality of service is key IT operations can’t simply react to events.  They must do far more than simply ensure IT availability.  It’s no longer a question of whether you can afford to be proactive, it’s a question of whether you can afford not to.


    That said - here are the Top-10 Reasons for Being Proactive…


    10. Increase Agility – speed IT’s responsiveness to business demand


    9.  Reduce Costs – eliminate costly and risky reactive processes


    8.  Reduce the Number of IT Events - focus on “real” problems


    7.  Mitigate Risk - detect problems earlier and faster


    6.  Improve Service Availability, Performance and Delivery – increase QOS


    5.  Speed MTTR – repair problems quicker


    4.  Reduce MTBF – avoid many  problems all together  


    3.  Optimize IT Resources – continually align IT capacity with business demand


    2.  Increase Efficiency – automate manual time intensive triage and remediation processes


    1.  Everyone else is doing it so you might as well too!



    Want to learn more...

    Read the thought leadership white paper on Proactive Operation - “Proactive Operations for the Modern Datacenter"

    Filter Blog

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