Friday, May 30, 2008

Oracle Enterprise Manager Grid Control 10gR4 is Available on HP/UX PA-RISC

EM Grid Control 10gR4 is available on HP/UX PA-RISC. With this release, 10gR4 is now available for Linux, Linux x86-64, Windows, Solaris, AIX, HP/UX Itanium and HP/UX PA-RISC. You may download them from OTN or ARU.

http://www.oracle.com/technology/software/products/oem/index.html

Thursday, May 22, 2008

Lessons from Extreme Data Center Makeover

Several months ago, I blogged about our OpenWorld hands-on lab set up project, which I referred as “Extreme Makeover, Data Center Edition”, as we had to set up a complex environment with a large number of complex enterprise class software in very short amount of time. It was both a fun and stressful project, and I learned a couple lessons from the exercise. I planned to blog about the lessons, but keep on postponing as other topics, from Gartner Conference to EM release to Collaborate took precedence. Well, here is a belated follow-up to the original post.

Lesson #1 – No project is too small when it comes to applying good IT practices

“How hard could setting up a demo environment be?” - that was the initial thought that came across my mind. However, it became very apparent very soon that it was a serious project with all the attributes of a real deployment. For example, after we came back from lunch on day 2 of setup, we found that one of the servers could no longer speak to the network. That was weird, as it worked just before lunch. After checking the network cable connection to the machine and agonizing all the network configuration parameters on the box, we discovered that it was actually a change that someone made on the network switch during lunch that caused the problem. We wasted half the afternoon troubleshooting. A little bit of discipline in the form of configuration management would have prevented that problem.

Lesson #2 – Be very careful about making assumptions

When we specified the hardware spec of our demo environment, we put down the usual requirements about CPU, memory, disk space, etc... What we did not specified, and assumed that we would get, were DVD drives on the server machines. We got CD-ROM drives instead, and we lost at least a day of time from this simple omission.

Lesson #3 – Expect the unexpected

A 5.6 earthquake hit the San Francisco Bay Area on one night while we were going to system test our client-server connection. That disrupted our work for the night as we didn't feel safe working in a mid-rise building not knowing whether there would be more shaking to come. I am not sure how to plan for something like this, but almost all projects run into “unforeseen” difficulties that are very hard to predict. In our case, there was very little that we could have done other than working longer hour the next day to make up for the lost time. If we had more time to work with at the beginning, we would have built extra buffer time into the schedule.
The examples above might seem trivial, but they introduced days of delay when their cumulative effects were added together. We managed to pull the project through thanks to hard work by the whole team, and we will have to keep these lessons in mind when we set up for the next OpenWorld or other similar projects.

Thursday, May 15, 2008

Demystifying Siebel Application Response Measurement

Siebel Application Response Measurement (SARM) is a performance-tracing framework that was originally introduced in Siebel 7.5. Even though the technology has existed for almost five years, it seems there are still some misconceptions about its design and intended use. Since I was the original product manager for SARM, I guess I can try to offer some explanations.

Myth #1 – SARM is Siebel ARM

Back was Siebel was an independent company, our strategy to provide Siebel management tools was to instrument the Siebel platform and work with 3rd party ISVs to adapt their tools to work with Siebel. As part of this strategy, we thought it would be a good thing to try to comply with industry standards such as Application Response Measurement (ARM) so that tools that support ARM can be used to monitor and diagnostic Siebel performance. Therefore, it is possible to consume SARM data by using an ARM-compliant tool.

However, strictly speaking, SARM is not an implementation of ARM. The problem with standards is that they often have to sacrifice capabilities for compatibility and provide the lowest common denominator solution. We found that ARM, specifically ARM 2.0, was not rich enough to capture Siebel-specific performance data. As a result, we built SARM to capture a superset of the information, and pass a subset of that to the ARM API. Specifically, contextual information such as the names of the Siebel UI views, business components, workflow processes and scripts are not passed through the ARM API, which would make it a bit difficult to tell what goes on in processing transaction requests.

In other words, to fully take advantage of the rich information captured by SARM, you need a tool that processes the native SARM data stream.

Myth #2 – SARM has high overhead

The driver behind SARM was the need for a way to identify transaction request performance bottlenecks, especially for interactive user workload. It used to be rather strict-forward to do this in the Siebel 2000 (version 6) days, as Siebel applications were deployed with 2-tier client/server topologies, with direct connections from clients to the database. In Siebel 7, the topology became truly multi-tiered, and with database connection pooling, there was no deterministic way to tie a database transaction to the user request. SARM was intended to be the remedy by providing a way to trace transaction request throughout the Siebel mid-tier.

As a performance management tool, the last thing that we needed was having SARM introduce more performance problems. Consequently, we were obsessed in squeezing every last bit of performance out of the tool and making its overhead as low as possible. This was achieved through several means:
- Record timing information while doing as little secondary processing as possible in real-time
- Use highly optimized buffered I/O to persist performance data
- Provide various throttling mechanisms to control the amount of SARM data captured

Prior to releasing SARM, we ran SARM through numerous load-testing scenarios. For example, in the Call Center 1 load tests, which simulated hundreds of simultaneous users running against a single Siebel app server, we observed SARM overhead to be less than 3%, well within our product performance requirement. We thought this was a reasonable cost to realize the benefit of having good management data for optimizing the application.

Myth #3 – SARM is only for production diagnostics

While a lot of the initial discussions about SARM were for performance diagnostics, we have always intended SARM to be a framework that supports the full set of application performance lifecycle activities.

SARM really is just a set of timers that measure the timing of transaction requests, as well as the timing within various points in the “call graph” of the Siebel software stack for processing the requests. SARM doesn’t care whether the timing came from actual user operations while the application is live or from activities generated from pre-production load tests. While in production, the data that it captures can be used for day-to-day monitoring as well as diagnostics, as well as longer-range capacity management.

Friday, May 9, 2008

Steps to Fusion - Centralize the Management of Your Applications on Oracle Enterprise Manager

eWeek recently reviewed Oracle Enterprise Manager Grid Control 10gR4. In the article, Cameron Sturdevant referred Enterprise Manager as “a high-powered ecosystem management platform that uses its home field advantage in Oracle shops to provide administrators with top-notch tools”. He went on to say that he recommends “administrators [to] consider a management strategy that brings Enterprise Manager in over time to take care of Oracle databases, application servers, web applications from Oracle and its fleet of acquired products from PeopleSoft, Siebel, JD Edwards and others.”

Wow, “home field advantage” . . . never thought of this metaphor when we planned our products, but it is the right idea. It is safe to say that Oracle, more than any other vendor, cares about whether customers can properly manage Oracle products, be they database, middleware or applications. They are all parts of our home field. It is also safe to say that Oracle, more than any other vendor, possesses the domain expertise for managing Oracle products. We built all these software in the first place, so we know how they work really well and we can build tools for managing them properly.

Oracle has made quite a bit of progress in solidifying its application management portfolio in the past 18 months. This started with the release of three application management packs that are designed specifically for managing Oracle E-Business Suite, PeopleSoft Enterprise and Siebel. It continued with the introduction of Application Diagnostics for Java, acquisition of Moniforce for end user monitoring, acquisition of the e-Test product suite from Empirix for application functional and load testing and release of Enterprise Manager Grid Control 10gR4, which included, amongst many things, improved service level management, SOA management, data masking, and a new management pack for Oracle Business Intelligence applications.

So what do all these development means if you are an Oracle application customer? It means you now have a new set of fantastic option to consider when acquiring tools for managing your application, as these Enterprise Manager tools cover everything from configuration management to monitoring to diagnostics to pre-production testing, and they are designed specifically for managing Oracle application products. It also means that you have one fewer set of vendor to deal with by choosing these tools from Oracle.

In addition, you would have taken the first step to Fusion from an IT operations management perspective by centralizing the management of your applications on Oracle Enterprise Manager today. Oracle Enterprise Manager is the tool for managing Fusion Middleware, the foundation for Fusion Applications. Since all these technologies may be managed through Oracle Enterprise Manager, it means that you may evolve your IT management setups incrementally as your modernize your application environments through products such as WebCenter, Business Intelligence and Oracle Application Integration Architecture.

Let's consider the following example with Siebel CRM for front office and Oracle E-Business Suite for back office. At the beginning, you manage these two applications separately using the bundled tools.



Step #1 is to connect these applications to Oracle Enterprise Manager Grid Control using Application Management Pack for Siebel and Application Management Pack for Oracle E-Business Suite, respectively. You gain advanced monitoring, centralized event management, configuration management, transaction diagnostic for Siebel, advanced cloning automation for E-Business Suite, end user monitoring and service level management.



For step #2, you decide to connect Siebel with E-Business Suite so that orders captured in Siebel could be submitted into E-Business Suite for fulfillment. You deploy Oracle Process Integration Pack for Order-to-Cash, running the integration processes on Oracle SOA Suite. For management, activate SOA Management Pack on the same Oracle Enterprise Manager Grid Control instance. You may now manage both Siebel and E-Business Suite, along with the integration between the two applications as a single logical system.



For step #3, you want to expose information to your users in a unified portal using Oracle WebCenter, and provide business insights using data from both front and back office systems using Oracle Business Intelligence. As you deploy these products, activate Oracle Middleware Management Packs and Oracle Business Intelligence Management Pack on the same Oracle Enterprise Manager Grid Control environment, and manage these Fusion middleware components along with Siebel, E-Business Suite, and SOA Suite as a single logical system.



Fusion Applications arrive, and in step #4, you decide that you want to start uptaking these new functionalities and run the new applications along with your existing Siebel and E-Business Suite applications. No problem, just add Fusion Applications to the same Oracle Enterprise Manager Grid Control, and you may then use it to manage your Siebel, E-Business Suite, SOA Suite, WebCenter, Business Intelligence, and Fusion Applications as a single logical system.



As you can see, as you evolve your application environment to meet your changing business needs, one thing may remain constant – the tool for managing your applications, as it evolves with you. This approach provides continuity for your IT operations while at the same time give you access to a comprehensive set of tools designed specifically for your application environment. Sounds good? Let's take your first step today.

p.s.: These diagrams came from the slide deck that I used at Collaborate. You may find the full presentation on the conference CD.