Monday, February 8, 2010

Oracle to Acquire AmberPoint

Oracle announced this morning that it is acquiring AmberPoint, the leading vendor of SOA management solution. AmberPoint is widely recognized as the Cadillac in the SOA management space, especially with its ability to enforce policies that help improve application performance and security, and to diagnose transactions not only within a composite application, but also across different applications. There had been speculations for a long time whether AmberPoint wanted to stay independent, or be acquired by a larger vendor. The answer is now known, and it is good that we got it. :-) AmberPoint, along with Sun Ops Center, will add to Oracle's capabilities in delivering application-to-disk management to customers.

Click here for the official press release about this acquisition.

Thursday, February 4, 2010

Want to Have a Smooth Running Application? Architect Your Tools Deliberately

In Oracle Unified Methods, the elaboration phase follows the inception phase of the project. This is the time when detailed analysis is done and key design decisions get flushed out. Traditionally, the focus of this phase is on coming up with detailed application functional design, especially the user interface, the data model, the means of integrating with other applications and data sources, or even the technical architecture of the deployment, etc... However, the same vigor is often not applied to the tools that are needed to manage the applications. This is very different from other complex engineering endeavors such as automotive and aerospace design, in which far more thoughts are put into the dashboards and the avionics. Using the right set of tools and implementing the tools properly are important to successful application projects.

Several deliberate decisions need to be made in tool selection for managing applications. The first one is whether to build home grown tools or buy packaged products. Some people prefer to build their own tools, but it is a difficult effort to sustain in the long run. Developing tools is like developing any software. To do it properly, they need to be properly designed, implemented, tested and maintained over time, which get expensive. Instead of building tools from scratch, most organizations opt to reuse something that they already have, which in many cases are generic management tools that were originally designed to manage servers or networks. The problem here is that a fair amount of effort is still needed to adapt these tools to manage applications, and they always provide only generic functionalities that do not address the real needs of managing applications. A better thing to do is to use tools that are designed specifically for the job of managing specific applications, while maintaining a balance of avoiding tool proliferation. I wrote about the topic of tool selection in greater depth in article last year. Click here if you want the details.

Besides getting the application management tools, it it important to design the tools to be an integral part of the runtime environment and allocate capacity to run them. Many people treat tools as an overhead. If you go by the definition that tools do not perform any actual processing of business transactions, then it is indeed an overhead. However, tools form a critical part of an application infrastructure. Without tools and the instrumentation to collect management data, the application becomes a black box that cannot be managed. No one would design an aircraft without proper avionics, and the same thing should apply to tools also.

Another set of decisions are related to the deployment architecture of the tools. The architecture needs to be designed deliberately with a similar level of care taken to design the deployment architecture of the applications, especially if the tool will be used to manage a complex application environment. In fact, there are similarities in designing tools deployment architecture and application deployment architecture. For example, one has to decide between centralized single instance tool deployment vs. multi-instance deployment of tools such as Oracle Enterprise Manager, just like one has to decide how many production application instances to deploy. This sort of decision is highly environment specific.

Oracle Enterprise Manager Grid Control, by building on Oracle Fusion Middleware and Oracle Database, allows the tool to scale both horizontally and vertically. Therefore, from a technical perspective, a single instance of Oracle Enterprise Manager can scale to manage thousands of applications, database, and servers targets spanning development, testing and production environments. However, some organizations may still want to deploy multiple instances so that different units within the organizations can maintain control over their own instances of Enterprise Manager in order to maximize control and flexibility. Others may want total separation between Enterprise Manager instances used to manage pre-production vs. production environments in order to maximize security. The final decision needs to be made based on not only technical factors, but also organization and other considerations.
Whether you are going to have a single or multi-instance Oracle Enterprise Manager Grid Control deployment, you still need to make sure that you set up at least one separate test instance of the tool. Before you roll a version of Oracle Enterprise Manager into production use, for example, you should have it tested in order to minimize any surprise.

Another potential decision is to decide whether high availability (HA) deployment is needed for the tools. Just like a pilot cannot fly with non-working avionics, it is virtually impossible for administrators to manage their applications effectively if the tools are not available. Some management tools support high availability deployment. For example, Oracle Enterprise Manager Grid Control servers, known as Oracle Management Service (OMS), can be set up to run in a clustered configuration or even a multi-site clustered configuration. The underlying Oracle Database repository can be made highly available by leveraging Oracle Real Application Cluster (RAC) and data guard technologies. More information about HA Oracle Enterprise Manager Grid Control implementation is spelled out in Oracle Maximum Availability Architecture guidelines.



Related Articles

- Want to Have Smooth Running Applications? Start with Good Planning.
- Building Application Management into Your Capacity Plan
- People, Process, Technology – The Right Tool