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.
Monday, February 8, 2010
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
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
Friday, January 8, 2010
New Releases of Application Management Pack and Application Change Management Pack for Oracle E-Business Suite Available
Happy New Year! May 2010 be a year of maximum uptime and optimal performance for your applications. To kick off this new year, we are releasing a new version of Application Management Pack for Oracle E-Business Suite and Application Change Management Pack for Oracle E-Business Suite.
These two management packs address many feedbacks that we have heard from our customers. After we launched the original version of the E-Business Suite Management Pack about two years ago, we went to present the product to many user group meetings and tradeshows to promote the product. In the Q&A sessions that followed our presentations, several questions tend to come up over and over. From the questions, we learned that while people were generally pleased to see the new management pack, there were clearly some unmet needs in the original version of the product. These needs included:
- Support for “hot cloning” such that E-Business Suite could stay running while cloning is carried out
- Patching Automation to apply E-Business Suite patches
- Automated Migration for E-Business Suite functional artifacts
- Transaction Diagnostic to identify transaction bottlenecks
We have been hard at work to address these needs ever since. Some of these requirements were met when we released Application Change Management Pack for Oracle E-Business Suite, which covers customization, setup and patch management, last May. However, with the release of that pack came a new requirement: change approval process support.
The new versions of Application Management and Application Change Management Pack finally address all these needs that we have been hearing from our customers. Key improvements include:
Application Management Pack for Oracle E-Business Suite
• Smart Clone: Smart Clone enables E-Business Suite systems to staying running while being cloned, and it provides flexibility for administrators to incorporate their own custom DB cloning techniques into pack's clone routine. Some of the key cloning scenarios supported include: RAC to RAC, RAC to Non-RAC, and scale down (Multi Node to Single Node).
• Concurrent Processing Dashboard: Administrators now have the ability to monitor and manage Concurrent Managers and Concurrent Programs through a intuitive dashboard. The new dashboard provides a detailed overview on the efficiency of Concurrent Managers in processing concurrent request. Administrators also have the ability to keep a watch list of specific concurrent managers and specific concurrent programs.
• End to End Tracing: Administrators can now analyze Oracle E-Business Suite's database load from Application Management Pack. Also the administrators have the ability to search Application Web User Sessions all the way down to Database Sessions. Top DB sessions can also be traced back to the Application User.
Application Change Management Pack for Oracle E-Business Suite
• Change Approval Framework: Changes orchestrated through Application Change Management Pack can now be controlled through the new change approval framework. Separate roles can be defined for approvers, who review and approve changes, and administrators, who deploy the changes. Built in notification capability enables approver(s)/requestor to be alerted about the status of relevant change requests, and the change approval records provide a way to maintain an audit trail of changes.
• Integrated Custom Application Management: This feature enables E-Business Suite administrators to easily register new custom applications across Oracle E-Business Suite systems and also track and validate existing custom applications in a standard way.
• Pre-requisite Patch Analysis: Oracle E-Business Suite patches can now be analyzed for pre-requisites prior to deployment in the target system. The analysis also verifies whether the pre-requisites are already met in the target system, and if they are not met, then those patches may be added to the patch job.
• Offline Transformation: This allows administrators to download Oracle E-Business Suite setup data in Microsoft Excel document and use Excel to edit and define new data.
These two management packs form the foundation of an advanced toolset for managing Oracle E-Business Suite. When combined with complementary products such as Oracle Real User Experience Insight and Application Testing Suite, they form a complete solution that cover all aspects of E-Business Suite lifecycle management.
We hope that you find this new management pack release compelling. To learn more about these two packs, go visit our product website. You may also download it from edelivery to try it out.
These two management packs address many feedbacks that we have heard from our customers. After we launched the original version of the E-Business Suite Management Pack about two years ago, we went to present the product to many user group meetings and tradeshows to promote the product. In the Q&A sessions that followed our presentations, several questions tend to come up over and over. From the questions, we learned that while people were generally pleased to see the new management pack, there were clearly some unmet needs in the original version of the product. These needs included:
- Support for “hot cloning” such that E-Business Suite could stay running while cloning is carried out
- Patching Automation to apply E-Business Suite patches
- Automated Migration for E-Business Suite functional artifacts
- Transaction Diagnostic to identify transaction bottlenecks
We have been hard at work to address these needs ever since. Some of these requirements were met when we released Application Change Management Pack for Oracle E-Business Suite, which covers customization, setup and patch management, last May. However, with the release of that pack came a new requirement: change approval process support.
The new versions of Application Management and Application Change Management Pack finally address all these needs that we have been hearing from our customers. Key improvements include:
Application Management Pack for Oracle E-Business Suite
• Smart Clone: Smart Clone enables E-Business Suite systems to staying running while being cloned, and it provides flexibility for administrators to incorporate their own custom DB cloning techniques into pack's clone routine. Some of the key cloning scenarios supported include: RAC to RAC, RAC to Non-RAC, and scale down (Multi Node to Single Node).
• Concurrent Processing Dashboard: Administrators now have the ability to monitor and manage Concurrent Managers and Concurrent Programs through a intuitive dashboard. The new dashboard provides a detailed overview on the efficiency of Concurrent Managers in processing concurrent request. Administrators also have the ability to keep a watch list of specific concurrent managers and specific concurrent programs.
• End to End Tracing: Administrators can now analyze Oracle E-Business Suite's database load from Application Management Pack. Also the administrators have the ability to search Application Web User Sessions all the way down to Database Sessions. Top DB sessions can also be traced back to the Application User.
Application Change Management Pack for Oracle E-Business Suite
• Change Approval Framework: Changes orchestrated through Application Change Management Pack can now be controlled through the new change approval framework. Separate roles can be defined for approvers, who review and approve changes, and administrators, who deploy the changes. Built in notification capability enables approver(s)/requestor to be alerted about the status of relevant change requests, and the change approval records provide a way to maintain an audit trail of changes.
• Integrated Custom Application Management: This feature enables E-Business Suite administrators to easily register new custom applications across Oracle E-Business Suite systems and also track and validate existing custom applications in a standard way.
• Pre-requisite Patch Analysis: Oracle E-Business Suite patches can now be analyzed for pre-requisites prior to deployment in the target system. The analysis also verifies whether the pre-requisites are already met in the target system, and if they are not met, then those patches may be added to the patch job.
• Offline Transformation: This allows administrators to download Oracle E-Business Suite setup data in Microsoft Excel document and use Excel to edit and define new data.
These two management packs form the foundation of an advanced toolset for managing Oracle E-Business Suite. When combined with complementary products such as Oracle Real User Experience Insight and Application Testing Suite, they form a complete solution that cover all aspects of E-Business Suite lifecycle management.
We hope that you find this new management pack release compelling. To learn more about these two packs, go visit our product website. You may also download it from edelivery to try it out.
Wednesday, December 2, 2009
RUEI 6.0 is Released
Oracle Enterprise Manager Real User Experience Insight 6.0 is Now Available.
Real User Experience Insight (RUEI) is a key technology in Oracle Enterprise Manager's technology arsenal to help application administrators understand how applications are being used and the user experience delivered. Specifically, it helps administrators answer important questions such as:
- Who are the users?
- Where did they come from?
- What have they been doing on the application? What parts of the applications are getting used?
- What sort of response time have they experienced?
- What errors have they encountered?
The insight that RUEI delivers can help application administrators manage application service level better through proactive monitoring and greater insights on end user activities. Besides application administrators, business analysts may also benefit from the insights provided by this tool, as end user activities on the applications can also reveal important information on whether the business is operating as intended. The tool is an indispensable piece of technology for anyone who owns or manages mission critical business applications. It is the next best thing to being there with every single application users and watching what they do on the applications.
The latest version of this tool delivers several important enhancements.
First, it offers integration with Oracle Application Diagnostic for Java and Composite Application Monitor and Modeler, two key pieces of Oracle Enterprise Manager technologies that provide further insights to the internal workings of applications. RUEI helps application administrators find out what the user did, and these two technologies provide further insights on why the applications behave in certain way, so it is nature to integrate them together.
Second, it provides better ways for administrators and business analysts to review user activities with full user session replay on web applications that shows step-by-step interactions between the end users and the applications, and customizable monitoring dashboards that tailor to the information that is most relevant about the monitored applications. These dashboards provide both IT and business users a single view with actionable intelligence, to help identify trends, patterns and anomalies.
Third, and perhaps most importantly, improved out-of-box capabilities to support key Oracle Applications such as Oracle E-Business Suite and Siebel CRM, as well as applications constructed out of Oracle technologies such as Oracle Application Development Framework (ADF) and Oracle Weblogic Portal. While RUEI is designed to be a general purpose application monitoring tool, we want to make sure that we provide un-paralleled out-of-box support for our customers who depend on our packaged applications and middleware technologies to run their businesses. Customers who use RUEI to monitor their Oracle Applications and middleware can expect shorter time-to-benefit as the tool works better out-of-box, as well as greater insights into Oracle technologies.
More information about RUEI can be found here.
Real User Experience Insight (RUEI) is a key technology in Oracle Enterprise Manager's technology arsenal to help application administrators understand how applications are being used and the user experience delivered. Specifically, it helps administrators answer important questions such as:
- Who are the users?
- Where did they come from?
- What have they been doing on the application? What parts of the applications are getting used?
- What sort of response time have they experienced?
- What errors have they encountered?
The insight that RUEI delivers can help application administrators manage application service level better through proactive monitoring and greater insights on end user activities. Besides application administrators, business analysts may also benefit from the insights provided by this tool, as end user activities on the applications can also reveal important information on whether the business is operating as intended. The tool is an indispensable piece of technology for anyone who owns or manages mission critical business applications. It is the next best thing to being there with every single application users and watching what they do on the applications.
The latest version of this tool delivers several important enhancements.
First, it offers integration with Oracle Application Diagnostic for Java and Composite Application Monitor and Modeler, two key pieces of Oracle Enterprise Manager technologies that provide further insights to the internal workings of applications. RUEI helps application administrators find out what the user did, and these two technologies provide further insights on why the applications behave in certain way, so it is nature to integrate them together.
Second, it provides better ways for administrators and business analysts to review user activities with full user session replay on web applications that shows step-by-step interactions between the end users and the applications, and customizable monitoring dashboards that tailor to the information that is most relevant about the monitored applications. These dashboards provide both IT and business users a single view with actionable intelligence, to help identify trends, patterns and anomalies.
Third, and perhaps most importantly, improved out-of-box capabilities to support key Oracle Applications such as Oracle E-Business Suite and Siebel CRM, as well as applications constructed out of Oracle technologies such as Oracle Application Development Framework (ADF) and Oracle Weblogic Portal. While RUEI is designed to be a general purpose application monitoring tool, we want to make sure that we provide un-paralleled out-of-box support for our customers who depend on our packaged applications and middleware technologies to run their businesses. Customers who use RUEI to monitor their Oracle Applications and middleware can expect shorter time-to-benefit as the tool works better out-of-box, as well as greater insights into Oracle technologies.
More information about RUEI can be found here.
Thursday, November 5, 2009
Want to Have a Smooth Running Application? Start with Good Planning.
Last year, I wrote an article that talked about key issues that IT need to consider when deploying enterprise class business applications. This year for OpenWorld, I decided to follow up the article with a breakout session to discuss the topic. There is a saying that “three minds are better than one”, so I recruited Keith Peters and Deep Ram, who had close to 30 years of combined experience working with application customers, to help put together the presentation. I am going to cover what we discussed at the session starting with this blog entry.
To frame the discussion, we decided to organize our material around application lifecycle phases, and based our discussion loosely around Oracle Unified Method, Oracle's implementation methodology for both application and technology products. Oracle Unified Method, as the name implies, is a unified implementation methodology that combined the best practices of the older Oracle Application Implementation Method as well as the methodologies from many acquired companies. The result is a very comprehensive set off best practices that should lead to implementation and operational successes if the methodology is applied properly.
At the earliest phase of an application project, known as the inception phase, there are two sets of activities that need to be done to set the foundation for achieving success later on in production. The first is to control the scope of customizations. Customization is often seen as a controversial topic, and some application vendors even go as far as telling customers to avoid customizations altogether. In our view, some customizations can be justified. One ways that different organizations compete with each other is through process innovation, and process innovation often require application customizations in order to support the processes.
However, bugs and performance problems may also get introduced into customizations alongside new capabilities. Before packaged applications are released to customers, they usually undergo extensive functional and load tests to ensure the proper functioning, stability, performance and scalability of the products. However, once customizations are introduced into these applications, these test results effectively become invalidated, as the actual application is not the same as the version that the vendor tested. In other words, there are potential costs and risks associated with customizations, so they should be made very selectively.
How to be selective?
We have observed the following practices at some of the best run application implementation projects by our customers.
To frame the discussion, we decided to organize our material around application lifecycle phases, and based our discussion loosely around Oracle Unified Method, Oracle's implementation methodology for both application and technology products. Oracle Unified Method, as the name implies, is a unified implementation methodology that combined the best practices of the older Oracle Application Implementation Method as well as the methodologies from many acquired companies. The result is a very comprehensive set off best practices that should lead to implementation and operational successes if the methodology is applied properly.
At the earliest phase of an application project, known as the inception phase, there are two sets of activities that need to be done to set the foundation for achieving success later on in production. The first is to control the scope of customizations. Customization is often seen as a controversial topic, and some application vendors even go as far as telling customers to avoid customizations altogether. In our view, some customizations can be justified. One ways that different organizations compete with each other is through process innovation, and process innovation often require application customizations in order to support the processes.
However, bugs and performance problems may also get introduced into customizations alongside new capabilities. Before packaged applications are released to customers, they usually undergo extensive functional and load tests to ensure the proper functioning, stability, performance and scalability of the products. However, once customizations are introduced into these applications, these test results effectively become invalidated, as the actual application is not the same as the version that the vendor tested. In other words, there are potential costs and risks associated with customizations, so they should be made very selectively.
How to be selective?
We have observed the following practices at some of the best run application implementation projects by our customers.
- Spend time to really understand the full capabilities of the applications. The whole point of buying a packaged application is to take advantage of the business practices that are baked into the product and leverage the economy of scale of sharing their development costs with other customers. To make intelligent decisions on what to customize, it is important to know what is already in the box.
- Analyze the current business processes and adjust them as necessary to fit the application. Customizations are usually done to support specific business process activities. If the out-of-box application does not work the exact way that maps to various business tasks, perhaps it would be easier to change the way that people use the application. Furthermore, simply converting existing inefficient business processes to run in an application usually is not the best way to improve effectiveness.
- Make whoever requested for customizations justify the needs. Evaluate the requests against potential costs and risks for approval and prioritization. This process should both be quantitative and qualitative. For example, justify benefits in terms of task step reduction, or even potential incremental revenue affected. For costs, have rough estimates on implementation and testing times. A scoring system, with clearly defined criteria, could also be very useful.
The most important thing is that these activities need to be carried out by the organization's own staff as much as possible, as it can be problematic to rely solely on the advice of outside consultants. While the best consultants would provide sound advice, there are also some bad apples that would encourage customers to over customize because they stand to profit from it.
By controlling the scope of customizations, not only would you make your application implementation more manageable, but you would also increase the chance that your application will run smoothly in production.
Thursday, October 15, 2009
New Oracle Enterprise Manager Widgets
Oracle Enterprise Manager is a great tool that helps IT administrators keep tab of the health of their various applications and infrastructure components. Its web browser based user interface can be accessed by administrators anywhere in the world where a browser runs in order to get latest status information on the managed objects (a.k.a. targets) that they want to monitor. However, it can be a bit tedious to have to launch Enterprise Manager console every time just to check status. If this problem applies to you, there is now a solution that should make your job easier.
Introducing Oracle Desktop Widgets, which are lightweight applications that you can run on your PC or Mac to access Enterprise Manager information. Three widgets are available. The first widget lets you keep track of the up/down status of the targets that you care to track.

The second widget allows you to monitor the actual service levels of your service targets.

The third widget is designed specifically to monitor database usage and performance.

One of the key advantages that these widgets provide is the ability to stay connected to Enterprise Manager. You can set them up to be launched automatically every time you log onto your PC, and the widgets stay on your desktop until either you close them explicitly, or when you log off your account.
How much do these widgets cost? They are free! They are released technology previews in order to test out new ideas and concepts. Please try them out, and give us feedbacks. To submit your feedback, click the feedback icon on the upper right corner of the widget.
Thursday, October 1, 2009
Distributed Application Management - Rapid Remediation
The concept of integrated management software applies to more than just monitoring and diagnostics. Unfortunately, when it comes to remediation, there is no single integrated tool that can do the job across the entire environment. A good policy is look for tools that provide the most automation. The next thing to look for is using as few tools as possible. One interesting approach is to perform post mortem on some recent problems and see if you could have reduced Mean Time To Repair (MTTR) with more automation and whether you could eliminate certain tools by extending the use of other tools. When it comes to remediation, having to deal with fewer tools is better for you. It helps you reduce MTTR.
Let’s look at deployment automation. A fix may require deploying various kinds of changes to the application environment. These changes may involve deploying new application code, correcting configuration discrepancies, tuning database SQL, or patching the software. Similar to monitoring and diagnostics, the task of applying change to a modern distributed application environment is complicated by dependencies amongst potentially large number of affected components. If changes are not applied uniformly across all the affected components, the application environment may become destabilized. Furthermore, change needs to be applied systematically following a set of well-defined policies in order to preserve availability as well as compliance.
When it is time to applying changes, deployment automation tools can be used to group together related change elements into a single package, and orchestrate the numerous steps involved in bringing down elements of the application environment, moving the package into the proper places, applying the change, and re-activating the application environment. Deployment automation helps reduce human errors in potentially complex change procedures, increase the efficiencies of such operations, and ultimately, lead to lower costs and increased agility for the applications. OK, I don’t like to reuse expressions but not all deployment automation tools where created equal either! Most provide a scripting tool and using it, you can develop highly sophisticated deployments. This is certainly necessary but not sufficient. Deploying an application may involve dozens of individual steps. A great percentage of them could be automated for most deployments. A truly useful deployment tool should have these steps pre-defined for you. Furthermore, with some basic questions, you could address a great deal of customizations. So, we should expect deployment automation tools to actually do the job without requiring IT staff to tell the tool how to do the job. In the e-commerce application example, modified checkout logic and table index update can be deployed together, and the change be recorded for auditing purpose.
Let’s look at deployment automation. A fix may require deploying various kinds of changes to the application environment. These changes may involve deploying new application code, correcting configuration discrepancies, tuning database SQL, or patching the software. Similar to monitoring and diagnostics, the task of applying change to a modern distributed application environment is complicated by dependencies amongst potentially large number of affected components. If changes are not applied uniformly across all the affected components, the application environment may become destabilized. Furthermore, change needs to be applied systematically following a set of well-defined policies in order to preserve availability as well as compliance.
When it is time to applying changes, deployment automation tools can be used to group together related change elements into a single package, and orchestrate the numerous steps involved in bringing down elements of the application environment, moving the package into the proper places, applying the change, and re-activating the application environment. Deployment automation helps reduce human errors in potentially complex change procedures, increase the efficiencies of such operations, and ultimately, lead to lower costs and increased agility for the applications. OK, I don’t like to reuse expressions but not all deployment automation tools where created equal either! Most provide a scripting tool and using it, you can develop highly sophisticated deployments. This is certainly necessary but not sufficient. Deploying an application may involve dozens of individual steps. A great percentage of them could be automated for most deployments. A truly useful deployment tool should have these steps pre-defined for you. Furthermore, with some basic questions, you could address a great deal of customizations. So, we should expect deployment automation tools to actually do the job without requiring IT staff to tell the tool how to do the job. In the e-commerce application example, modified checkout logic and table index update can be deployed together, and the change be recorded for auditing purpose.
Subscribe to:
Posts (Atom)