Archive for June, 2009

J9 Technologies, Inc. Announces Migration Solution for OpenView Internet Services Users

J9 Technologies, Inc. announces a limited-time migration solution for Hewlett Packard customers currently using OpenView Internet Services (OVIS). As of December 31, 2009, current OVIS customers must migrate from OVIS to HP’s BAC and SiteScope solutions in order to receive licenses, customer support, patches, and updates from HP. As a result of the Mercury acquisition, HP announced that it is dropping support for the OVIS solution in favor of the Business Availability Center (BAC) and SiteScope solutions. HP is offering, free-of-charge, a license exchange from OVIS to BAC and SiteScope.

J9 offers expert services to streamline the customer’s license acquisition process, pre-migration planning, end-to-end migration from OVIS to BAC, and identifying best practices for ongoing utilization of the new BAC solution. With J9, the migration process is not just one of conversion, but evolution. J9′s solution reduces a customer’s time to value risk during the migration process.

J9 works with each customer individually to determine their current state, identify gaps and provide a plan for migration. Throughout the process, J9′s experts partner with the customer to ensure the migration not only replaces their current state, with no gaps, but allows the customer to be positioned to expand their capabilities utilizing the enhanced BAC platform. J9′s services expand beyond OVIS migration solutions to offer a complete range of basic and advanced BAC implementation services and training programs designed to enable the customer to take full advantage of the power of the BAC platform.

Business Availability Center brings a robust platform to address a broad range of application environments. BAC’s rich feature-set offers customers an enhanced platform addressing their Business Service Management needs and initiatives, including application diagnostics, service level management, business transaction management, and superior dashboarding capabilities. The BAC platform is capable of supporting a wide range of application environments beyond standard web-based applications, resulting in enterprise-wide coverage for the customer’s most business critical systems, such as ERP/CRM, E-Mail, SOA, Web 2.0, and client-based systems.

About J9 Technologies

J9 Technologies is a certified Hewlett Packard Gold Partner, specializing in Business Service Management and Application Performance Lifecycle management.

Offering strategic consulting, training, installation and ongoing support for HP software products such as SOA Systinet, Service Test, Business Availability Center, Diagnostics, LoadRunner / Performance Center, Real User Monitoring (RUM), TransactionVision. With a focus on application diagnostics, composite application management, and business transaction management, J9 Technologies strives to ensure that customers can quickly identify the root-cause of issues and minimize mean time to resolution.

We are just catching our breath after few a long and fruitful days in Las Vegas, where HP held it’s annual Software Universe conference. We exhibited, we rolled out our OVIS to BAC migration offering, we chatted, we happy hour-ed, we presented, and after it all, we slept. For a long time.

And now here we are, in all of our glory, having emerged from the gambling flames of software sales and services just a little bit tougher, a little bit wiser, and a feeling lot more connected. Thanks to everyone who came by the booth (and picked up one of our lovely one-handed bottle openers pictured above) and who attended our happy hour event. It really was a blast getting to be face to face with all of these people we work with everyday. See you next year!

Yet another Monday after a red-eye flight, at another new customer in some city far from home. I’m ushered into a conference rooms with a team randomly checking their watches and Blackberries, each tense, nervous, and wishing they were somewhere other than this. A project manager begins the briefing, which everyone has heard a dozen times before: the project is past its scheduled delivery, application performance is terrible, the users are angry, the sponsors are talking about pulling funding, and the order for the past month has been forced 15 hour days and weekends. This afternoon they want to begin another series of load tests and they ask me if our team of consultants will be able to help them. My only question is: What are you testing?

It’s a simple question. I find myself asking it several times per day with customers and sadly the usual answer is a blank and distant stare. The reality is they don’t know, but it’s not their fault. To be honest, I’m not entirely clear myself on how the state of the industry reached this point. The trend though goes like this:

1) Testing happening just prior to deployment, often not even starting until the same week.
2) Tests being run by an operations team or perhaps by a lone consultant, without the involvement of a business owner who understands the functionality of the application.
3) A random mishmash of tools, some properly licensed, some not, downloaded and used without any training or guidance.
4) Test cases being made up on the fly - “Hey, what if we try this?” without any rhyme or reason as to the validity of the test.
5) Little or no written record of the test cases executed or their results, leading to duplicate efforts, errors, and a lack of objectivity.

It all really boils down to that same question — if you can’t answer, objectively, the reason for a particular test run, then your efforts are for nought. Once you are on that treadmill of test run after test run, it’s impossible to get off without a hard reset; the only objective test at that point will come when the application is introduced to the real world.

Once an organization has reached this point, where production firefighting is a daily routine, the only way to bring order back is to reverse the list above. Testing must be an integrated part of any development or implementation project. Developing a written, comprehensive, repeatable test plan requires input not only from technical teams but also from end users and business analysts who understand the use cases — both common and edge. Only then will you know what you are testing.

Shortly after I wrote the last entry, about tools that get purchased and not used, I realized that I hadn’t really described the reasons why this happens. Sure, there are reasons like insufficient training, inadequate tools for the problems at hand, or organizational ownership and politics. But the most common reason is far more human and harder to mitigate: apathy.

A friend of mine is a Six-Sigma and Toyota Process expert. He knows and understands quality and process control methods inside and out. I asked him about the barriers to organizational adoption of these practices. His answer was very telling. It wasn’t money, time, tools, training, or anything measurable. Instead his answer was very simple — because people don’t like being told what to do.

There’s a parallel here. Unless a tool, process, practice, or even idea fits within someone’s world view, they simply aren’t going to adopt it. It’s even worse if they feel like something is being forced upon them, rather than being an engaged participant. Even if they feel invested in the tools, good old fashioned apathy can take hold.

Why? Incentives and consequences. Its just tremendously easy to become apathetic if there are no incentives or consequences to our actions. Many times after J9 consultants find a problem with a customer’s application, we hear rumblings of “oh yeah, I wondered if that was a problem.” Easier to turn a blind eye then to invest ones self in learning a tool, exploring a problem, and coming up with a solution. Especially since in so many organizations that live by firefighting, volunteering is akin to accepting blame for the problem.

So, the guiding points here appear to be:

1) It’s imperative that all types of users are included in the selection and implementation process so that they feel invested.
2) Management has to continually communicate intentions and uphold the standard.

On this second point, here’s a really example of how this can be done in a way that emphasizes the point yet stays away from simply giving orders. Say for example it’s a Monday morning triage meeting and an outage that happened over the weekend is the topic. The questions isn’t simply “What happened?” but also “What did the tools tell you happened?” This is a means of continuous communication about the expected tools and the expected method, plus a means of continual assessment of the value proposition — if your tools are proving less than useful, then perhaps there is a legitimate reason why they aren’t being used.