The Sphere Journal Online- December 2011
|
Hybrid Cloud Integration
Marc-Thomas Schmidt, IBM Distinguished Engineer & CTO SOA Integration
Clouds are Moving In
 Over the past couple of years, there has been a rapid increase in the use of cloud-based services and resources in enterprises of various sizes and across industries. And I think we’ll see that trend continuing over the next several years – cloud will become a basic feature for pretty much all IT shops out there. However, I do not think that many shops will "go cloud only" any time soon. Rather, most will have parts of their IT resources and services in a cloud form factor in the near future. The benefits are extensive, and the barriers to adoption have been lowered to a point where this becomes appealing for mainstream enterprises, not only recently "born on the Web" shops. This article will discuss approaches for managing hybrid cloud environments, where enterprise services will live in private or public clouds as well as in a traditionally managed fashion.
There are a number of drivers for cloud adoption; the most important ones at this stage are Virtualization 2.0 and Software as a Service (SaaS). Let’s explore both in a bit more detail.
Private Clouds - Virtualization 2.0
Most enterprises I work with are incorporating virtualization in their IT resources to some degree. In a way, private clouds are taking virtualization to the next level by providing an elastic set of on-premise resources where enterprises run their custom business services. Private clouds make it very easy to manage, monitor, and facilitate self-service provisioning of pre-configured software constellations in the form of virtual images and patterns both at the Infrastructure as a Service (IaaS) and Platform as a Service (PaaS) level. IBM recently announced major enhancements to their Cloud Computing story, including the IBM Workload Deployer, which supports provisioning and management of private clouds running SOA middleware and services.
Connectivity middleware is part of this Cloud Computing story in the form of Hypervisor editions that offer pre-canned topologies for WebSphere MQ or WebSphere Message Broker configurations optimized for specific integration workloads. This could also be referred to as connectivity in a private cloud.
Business Services in the Clouds - SaaS
The other driver behind cloud adoption is the growing set of business services in a (mostly public) cloud, which enterprises adopt at a rapid pace. Those public cloud-based business services are generally referred to as Software as a Service (SaaS) and cover a broad range of capabilities, from CRM to HR to ERP to collaboration services in a cloud form factor. Their differentiator is not so much that they offer entirely new capabilities (there’s an established set of on-premise packaged application products), but how they offer those capabilities. They are very easy to adopt, and by limiting adaptation options it becomes possible to avoid the rather long customization cycles for traditionally packaged applications. They offer a self-service consumption model and with it the elasticity one expects from a cloud; users consume (and pay for) as much capability as they need at a given point. Many enterprises I work with are considering moving—or have already moved— some of their non-core services to SaaS type solutions. There are also a growing number of IT Service Providers and Independent software vendors who are considering offering their services in a SaaS form in the future. As more enterprises are adopting the approach, more services are becoming available in the cloud form.
No Cloud is an Island – Managing Hybrids
 There is this wave of cloud adoption building up, and I urge IT shops to get ready for it. Hybrid environments that mix resources and services in private and public clouds with traditionally deployed ones will be the predominant model in the coming years. And just as it is important to plan for the integration of traditional business applications, to make them building blocks for ever-changing business processes, and to ensure that business information is kept in sync across a portfolio of services, it is just as important to do that for cloud-based services. Enterprises need to establish a Hybrid Cloud Integration (HCI) strategy, even if they are not yet using cloud-based services or resources. Otherwise, clouds are introduced in an ad-hoc fashion and often driven by business users in the Lines of Business in an enterprise. Also, integration of those clouds with existing enterprise services is done via custom integration code, which is not only expensive to maintain but constrains agility in using the cloud-based resources as well as posing significant security and compliance risks.
Conceptually, not much invention is required – the principles of SOA for managing an enterprise portfolio of business services as a set of loosely coupled, well-described, and encapsulated services apply when it comes to making cloud-based resources part of the enterprise software portfolio. HCI should be done as an extension to an enterprise integration strategy. However, there are some important differences between traditional and cloud-based services to consider when expanding an existing integration strategy to include this new type of services.
Clouds make syntactic integration easier
SaaS business services are rather well-behaved from an SOA perspective. In contrast with many traditional applications inside an enterprise, they offer well-defined service interfaces (Web services with WSDL interfaces or RESTful variants). Many SaaS providers offer meta-data and service discovery interfaces that make it easy to add the services to an enterprise service registry and repository. From a syntactic integration perspective, things get a lot easier than in traditional intra-enterprise SOA. However, there are some new challenges.
Semantic integration challenges
The first challenge has to do with semantic integration problems. Simply put, there are so many cloud APIs with widely varying semantics and they change at a much more rapid pace than anything enterprises are used to from traditional integration projects. There is no consistency in the definition of basic business entities like "customer" or "account" across SaaS vendors, and the style of APIs vary widely (e.g., session concepts, constraints on how much info to obtain, security, and monitoring interfaces). A good HCI solution needs to encode knowledge about the API semantics in addition to offering Web service integration capabilities.
There's also the rapid change of APIs to consider. Many SaaS vendors offer updates to their APIs on a quarterly basis, which is good for those waiting for new features, but requires careful integration management to make sure updates do not break affected systems. From a governance and integration perspective, it's a really good idea to think about SaaS clouds as service domains in a Federated Service Management context. They control the life cycle of their services independent from what the other service domains in an enterprise do, and therefore "federation contracts" that govern the use of those services need to be managed.
“Time to integration” challenges
The second challenge is speed and consumability of integration. Compared to traditionally developed, deployed, and managed software, cloud computing makes it so much easier to consume services, stand up a private middleware cloud, or provision a SaaS-based business service in a matter of days.
The connectivity required to integrate those resources and services needs to keep up with that level of consumability and speed to solution; cloud consumers expect their HCI solution to connect in days, not months—as is often the case in traditional integration projects. And that applies to the entire spectrum of integration problems in HCI scenarios—from integrating services and information in clouds (synchronizing cloud-based assets with traditional ones), to security models across clouds and traditional environments (user profile synchronization, identity federation, and so on) to monitoring and management across the entire hybrid environment (e.g., feeding resource monitoring information from clouds into an enterprise dashboard or managing resource allocation across private and public clouds to shift workloads depending on changing resource needs) —holistic integration of cloud APIs at all of those levels in a very short time frame is the challenge.
HCI with WebSphere Cast Iron Cloud Integration
 Integrating hundreds of constantly changing APIs is an inherently difficult task, but it can be significantly simplified by encoding knowledge in the form of repeatable patterns and pre-canned building blocks. Those templates are the basis for the actual day-to-day integration work; they significantly simplify both the initial authoring of the integration behavior as well as subsequent management and maintenance of those integration scripts.
And that's what is being done in IBM’s flagship HCI product, WebSphere Cast Iron Cloud Integration. It is tuned from the ground up to meet the challenges described above. It addresses the semantic integration problem by encapsulating all one needs to know about the many existing cloud APIs in the form of business service connectors. WebSphere Cast Iron Cloud Integration users do not, for example, think about the Salesforce.com system as a set of Web services, rather they think about it as a business application that offers services to manipulate business objects like customer, account, and so on. The WebSphere Cast Iron Cloud Integration connectors know how to interact with the target systems and how to deal with potential access problems.
However, encoding of cloud integration knowledge goes beyond the business service connector level. WebSphere Cast Iron Cloud Integration addresses the speed to integration challenge by offering a catalog of pre-defined integration templates (TIPs) that encode maps required to go from one business application to another, typical integration flows, and more. It is this extensive catalog that enables so many WebSphere Cast Iron Cloud Integration projects to be completed in a matter of days or weeks rather than months.
WebSphere Cast Iron Cloud Integration comes in three form factors: a physical appliance, a virtual appliance (a Hypervisor edition), and WebSphere Cast Iron Live, which is a public form factor that offers the self-service consumption experience one expects from a cloud with the same capabilities as the rest of the WebSphere Cast Iron portfolio. WebSphere Cast Iron Live is particularly interesting when it comes to integrating between clouds. A growing number of customers use many SaaS systems that need to be integrated, so if the two endpoints to be integrated are in public clouds then it makes sense to have the integration itself run there.
We're collaborating across the spectrum of IBM technologies to provide that WebSphere Cast Iron Cloud Integration experience to HCI not only when it comes to integration at the business service and information level, but in the holistic fashion discussed above. New capabilities have recently been added to WebSphere Cast Iron Cloud Integration to support integration of cloud monitoring information, to support synchronization of user profiles between enterprise directories and counter parts in clouds, and to facilitate workload management across private and public clouds.
Summary
I strongly believe that hybrid clouds will be the model most enterprises use in the future and they should prepare for that by establishing a cloud integration strategy now. IBM offers middleware today to connect to clouds and between clouds at all levels of integration; this is a holistic HCI approach— from services and information to security to monitoring and management and governance. IBM also offers connectivity middleware in a cloud form factor— from Hypervisor editions of messaging and ESB products for private connectivity clouds to WebSphere Cast Iron's hybrid cloud integration technology in a public cloud.
Marc-Thomas Schmidt is a Distinguished Engineer and has been working on IBM’s Business Integrations technologies for more than a decade, from workflow management systems to advanced message-oriented middleware to business process management technology. In his current role, he leads the work on technical architecture for IBM’s ESB technologies.
Copyright 2011 IBM Corporation
|
|
|
Case Study: Museum of Modern Art and IBM WebSphere Cast Iron
Diana Pan, Director of Technology at The Museum of Modern Art (MoMA) in NYC
Last year, the Museum of Modern Art (MoMA) in New York City had a record-breaking 3.1 million visitors, MoMA memberships reached 136,000, and the museum’s website drew nearly eighteen million visitors. MoMA also experienced a rapidly growing online community through social media networks such as Facebook, Twitter, YouTube, and Flickr. MoMA’s vast collections and program offerings are supported in large part through generous contributions from its members and friends. Three years ago, MoMA’s Membership and Development department (M&D), along with its IT partners, embarked on a major technology upgrade project primarily based on building a new system that would provide a 360 degree view of MoMA members, visitors, donors, shoppers and attendees. We wanted to know exactly who interacts with MoMA and their interactions over time, membership renewal rates, member visits and patterns, donation history, e-commerce and in-person transaction history, and overall interest in premium website content and website personalization.
At the inception of this project, MoMA’s M&D team was using a 30-year-old custom application built on AS/400 as the primary system of record. Over time, this system became very difficult to use.
Some key issues:
- Numerous workarounds (e.g., spreadsheets) were needed due to lack of training in AS/400 ("green screen"), functionality and usability with existing system.
- Excel workarounds were not connected to a central database so information was not being shared, synchronized, or analyzed consistently.
- Critical data and processes tied to spreadsheets carried tremendous risk: spreadsheets could crash, go missing, or have no change management or testing procedures. Even small mistakes and changes had the potential to cause huge reporting errors.
- Important data, such as research profiles of potential donors, could not be entered in MoMA’s AS/400.
- Information that was entered in MoMA’s AS/400 needed to be exported and merged with spreadsheet data in order for it to be complete or useful. On its own, AS/400 data had very limited use.
- It was difficult to relate M&D information to other parts of MoMA – there was no holistic view. This hampered cultivation efforts and customer service.
- More time was being spent on filling out forms and using Crystal Reports than on fundraising and prospecting.
From 2008-2009, MoMA performed an in-depth analysis of the M&D business process and data flow, and determined that the old AS/400 application should be replaced with a new Customer Relationship Management (CRM) system with a single data repository and a unified platform. The Salesforce.com CRM platform was chosen as the best solution for MoMA. As a cloud-based solution, it also fit in well with MoMA’s overall cloud and IT strategy.
Once the Salesforce.com platform was selected as a CRM solution, it quickly became evident that until a complete migration to Salesforce.com takes place, data in both AS/400 and Salesforce.com would need to be maintained. While most of the M&D team would eventually begin using Salesforce.com, certain business-critical data and functions would still reside in the AS/400. Specifically, transactional data and payment processing would continue to originate in the AS/400 since the integrations into MoMA’s accounting system (PeopleSoft) would only migrate over to Salesforce.com at a to-be-planned later phase of the project. In addition, integrations with other major systems (such as the moma.org and the momastore.org websites, point-of-sales systems used in the MoMA retail stores, MoMA lobby applications, membership and donor card printing functions and the caging application) would need to be rebuilt in Salesforce.com in future phases as well. At the time this article was written, these additional phases had not yet taken place; this will be done eventually in a second or third release when all of the AS/400 functionality is eventually moved into Salesforce.com.
Once it became clear that, for some significant amount of time, both AS/400 and Salesforce.com must co-exist to support MoMA’s M&D business, the team began researching options that would allow for this data synchronization.
As with most technology solutions, the first consideration was buy vs. build. In order to build a custom solution to synchronize data between Salesforce.com and MoMA’s AS/400, this would require many changes in the AS/400 as well as custom Salesforce.com APEX code. In addition, maintenance of, and timelines for, the project were not cost-effective – we would not have been able to launch on time. The team shifted its attention to evaluating three leading integration products, one of which was IBM WebSphere Cast Iron Cloud Integration (also referred to as “WebSphere Cast Iron” in this article).
Potential integration products were evaluated based on the following criteria:
- Ease of implementation
- Average implementation time
- Out-of-the-box connectors. (i.e., did the product have “out-of-the-box”, proven connectors that could support AS/400 DB2, Salesforce.com, as well as other future endpoints that were part of MoMA’s current technical architecture landscape?
- Ease of customization if complex integrations were required
- Intuitive developer’s toolkit
- Support for real-time or near real-time bi-directional updates
- Reliability
- Performance
- Ability to handle large data sets
- Security of data as data moved from one endpoint to another
- Multi-layer options for error handling
- On-going maintenance of infrastructure (systems)
- On-going maintenance of integration logic (people)
- Pricing model
- Support structure, development community, and viability of company in 5 years
- Suitability as part of MoMA’s longer term cloud strategy
The methodical evaluation of these products took nearly 3 months and involved multiple live demos with each vendor, as well as evaluation of technical documentation and reference sites.
After this assessment process, MoMA selected the IBM WebSphere Cast Iron Cloud Integration solution. Some of the key reasons were:
- Real-time (or near real-time) bi-directional updates between Salesforce.com and AS/400 DB2
- Easy-to-use interface with centralized management console
- WebSphere Cast Iron uses JavaScript as a scripting language, making it very easy to perform transformations that required more complex logic
- Ease of deployment and management of development and production environments
- Completely maps to MoMA’s overall cloud strategy
- Easily integrates with other systems using pre-defined connectors – such as WebSphere Commerce (DB2) for Retail – opening up the possibility of tracking members’ shopping patterns and identifying potential new members and donors
- Could be used as an integration platform for all future projects
- Performed well with initial stress tests
- First development prototype was up and running within a week
MoMA went live with the Salesforce.com and WebSphere Cast Iron solution on September 14, 2011. Most of MoMA’s M&D team members have been moved onto the Salesforce.com platform. WebSphere Cast Iron Cloud Integration ensures that the data between MoMA’s AS/400 and Salesforce.com is synchronized daily. The team is now investigating the requirements for the next phase of the project and they are considering integrating other areas of MoMA — such as the Retail systems for a customer or a member’s shopping history — into Salesforce.com using WebSphere Cast Iron.
As we implemented WebSphere Cast Iron, some basic best practices became evident in our projects:
- It is important to use Configuration properties. This is necessary so that projects can be easily deployed from Development to Production and changes would only need to be made in these property variables to point to development or production instance names (e.g., database names, secure connector names, etc.).
- It can be convenient to use multiple methods of invoking an orchestration. For MoMA, every orchestration can be invoked through a Web service. While most of the orchestrations are also set to run on a scheduled basis, the Web service invocation is convenient during testing and is also used when sequencing orchestrations that must run in a certain order.
- WebSphere Cast Iron activities within orchestrations should always be named appropriately. Since orchestrations are mostly visual, the activities themselves describe the logic and data flow. Default activities such as “query object” or “insert rows” should be renamed so they are more meaningful.
- Similarly, variables within WebSphere Cast Iron orchestrations should be named consistently and with meaningful context.
- “Catch All” should be used as a separate branch to catch all fatal errors within an orchestration.
- “Try/Catch All” should always be used to catch exceptions for an individual activity for error handling.
- It is necessary to set up integration users for each endpoint, especially where there are bi-directional updates. Logic can then be added to an orchestration to prevent infinite loop updates between these endpoints by filtering out changes from the integration user himself.
- As part of the WebSphere Cast Iron Cloud Integration solution, MoMA is using the WebSphere Cast Iron secure connector, which is installed on a local machine behind MoMA’s firewall. It facilitates secure communication between systems behind MoMA’s firewall, such as the AS/400 DB2, and external systems such as Salesforce.com. This secure connector is a vital part of the architecture if the cloud solution is used and should therefore be monitored for 24/7 availability.
Some of the key lessons learned in this project pertain to both WebSphere Cast Iron Cloud Integration as well as considerations when moving to any cloud solution. A cloud strategy frees up people and resources, but it also comes at a price: loss of control. It is therefore important to partner with companies whose solutions make sense for your business need. Basic due diligence analysis still applies: evaluation should be based on reliability, performance, functionality, security of data, access and ownership of data. There should be no need to compromise on these important factors. In addition, standard best practices for software engineering still apply, so I encourage those moving to a cloud solution to use source code control, have a well-defined structured Q & A process, perform load testing, and have a well-defined change management process for managing and pushing defect fixes and enhancements into production.
Diana is responsible for the strategic direction, technical architecture and development of the applications that support the museum for both internal and external facing customers. She has over 15 years of experience and has helped engineer solutions in a variety of areas including eCommerce, content management, CRM, Internet applications and education products using a variety of technologies such as j2ee, IBM WebSphere Commerce, MQ Series, IBM DB2, Oracle, Sun LDAP, Google and Endeca search engines. Most recently, Diana is helping to define and implement the museum's overall technology strategy that will include cloud based solutions such as IBM CastIron and Salesforce. Diana holds a BS and MS from Columbia University.
|
|
|
Using WebSphere MQ in Development
Verifying Application Quality through Message Driven Testing
Richard Nikula, VP Development at Nastel Technologies
Developers face many challenges today in order to ensure they deliver quality applications. They must deal with changing requirements from their customers, evolving application design models, new technology, and demands to decrease delivery timelines. However, regardless of these new challenges, one thing that remains constant is the expectation that applications do not fail. When applications were monolithic, the developer had a high level of control to ensure that the data processed met the requirements. With current service-based applications, this control has diminished. This paper is targeted at message-driven applications with examples based on WebSphere MQ, but the concept can be applied to any situations that leverage messaging technology including SOA and cloud-based environments.
One of the key elements of ensuring application stability is verifying that both good and bad data provide the expected results. As changes are required, it is important to be able to replay a set of messages to ensure these changes do not introduce failures. With message-driven applications, it is impossible to drive every possible interface to generate these test cases. Tools are required to save and restore messages for testing. Capturing both content and the context provides the application developer the data needed to simulate the conditions expected during production operation as well as to fabricate specific situations.
In the example below, you can see an example where a developer is loading previously captured test data back into a processing queue. Multiple sets of test data have been captured to test specific conditions, including month end processing.
However, despite thorough testing, when messages that cause unexpected behavior occur, quick handling of this situation is required.
With WebSphere MQ, there are two primary techniques for dealing with bad data.
The first approach is to design the application to trap any exceptional messages and process them, perhaps by writing them to an exception queue. In this case, the application treats the condition as 'normal' and includes the logic to handle processing them. In some cases, a response to the requester will be immediate and in other cases it will be asynchronous. Alternatively, other processing might be used to address the bad message before normal or error path execution continues. An example would be manually correcting the message and resubmitting it to the processing application.
The example below shows a technique used when the application uses error queues to hold the exceptional messages, which also provides the ability for the application developer to view the messages that are not processing properly.
The second technique in WebSphere MQ for dealing with bad data is similar, but in this case when the application determines it cannot process the message, it rolls back the unit of work, which returns the message to the origin queue. In some cases, the application will set the queue to “get inhibited” in order to prevent the message from being immediately re-processed. In other instances, the application will allow the message re-processing to be controlled by WebSphere MQ. It is possible that this could mean immediate rescheduling for processing. In this case the expectation is that conditions that caused the failure have been corrected by other means. To prevent infinite replaying of a bad message, WebSphere MQ provides the ability to define a backout-queue to move these messages to after a specified number of retries.
The example below shows an application that has created a backout-queue and has allowed the message to be processed twice before being placed there.
Regardless of which of these two techniques is used, there are several actions that must be performed. The first is to address the problem and to both get the message processed and get the application operational. To complete this, one course of action is to review the offending message to determine what led to the failure. Based on this data, possible outcomes might require using the information to make a manual correction, deleting the message, submitting a compensating transaction, or in some cases deleting the offending message. In addition to correcting the problem, the more important activity is to capture the message or messages so that it can be analyzed and included in the test data suite. Capturing this data is applicable to all steps of the application lifecycle, development, unit testing, acceptance testing and production. In order to provide the optimal conditions for performing both analysis and data capture, the development team needs access to the exceptions queues while being restricted from accessing other production resources. Recently referred to as DevOps, the cooperation between the development team and operations is essential to provide the highest quality service to the customers.
The example below shows the analyst reviewing the message content on a backout-queue to get details regarding the potential cause.
While manual intervention may be required, the process of capturing data for processing should be automated as often as possible. This ensures that data is always captured and ready for analysis. The application itself could complete this capture or, for simplicity, this could be an external application.
As we've seen in this paper, the development of applications today relies on increasingly message driven technologies. From development through testing and into production, it is important to understand the message processing. Application development, test teams, and operational staff must have access to the messages. This is essential to both correct and operational problems as well as to capture messages to provide a thorough test suite during application development and testing.
Watch this brief video to learn more!
 As Vice President, Product Development and Support for Nastel, Richard directs Nastel's development organization and manages all aspects of software development, delivery, implementation and support. His areas of specialization include helping customers understand, reduce and manage the complexities introduced by Service Oriented Architectures and virtualization. Richard brings 25 years of software development and implementation experience to Nastel, the majority of which has come from working on leading edge technologies at software vendors such as BMC. A recognized expert in mainframe, distributed computing, Service Oriented Architectures (SOA), and WebSphere, he has contributed to industry standards, delivered articles and presentations at many levels.
|
|
Solutions Spotlight
Jody Hunt, Lead Solutions Marketing Manager, BMC
The Challenge
The IBM WebSphere Application Server is a major tool for the agile, cost-effective business to accelerate application development, testing, deployment, and operations. Yet there is a need to deploy WebSphere in a scalable, consistent, and reliable fashion. This can be further complicated by the need to run and support WebSphere Portal and Process servers. The challenge of ensuring consistent configuration of WebSphere instances and automating the application release processes that move applications through them is paramount to successful deployment and on-going production use.
The productivity gains created by WebSphere instances can be diminished, or even cancelled out, by the consumption of valuable manpower and technical resources. Configuration errors are responsible for between 40–60% of application failures. The trend is for more and more frequent application releases into environments of higher complexity (e.g., WebSphere Portal and VE) and affecting more users (SaaS, Cloud computing). As Web applications are increasingly business critical, outages can publicly hinder a company’s ability to do business, causing damage to brand, revenue, stock price, and career.
All too often, development teams are not able to work cohesively and coherently with IT Operation teams to ensure smooth, successful, and automatic application deployments of systems.
The Solution
Application Release Automation and Process Management from BMC transforms application release processes with collaborative workflows, high-level planning and calendaring, deployment automation, environment management, and defect identification. It lets developers collaborate easily with IT Operations in a controlled, consistent, browser-based way to ensure consistent provisioning and configuration of pre-production environments. Application Release Automation enhances the capabilities and timeliness for teams to manage and support application releases and various WebSphere server configurations.
BMC’s Automation Release Automation (ARA) eliminates unplanned application outages due to configuration error and the time necessary to mitigate, diagnose, and solve application problems. Furthermore, ARA can manage middleware configurations and configuration drift, ease datacenter moves or consolidations, and readily support migrations to a new middleware release. It can even ensure against application failure when cutting over to one or more Disaster Recovery sites. This ensures you have the capacity, the consistency and the availability your business requires.
Workflow, Planning, Coordination, Automation, Configuration and Diagnostics
Application release automation requires much more than checklists, schedules, meetings, and coordination of user-maintained scripts. Application Release Automation from BMC addresses the following critical areas:
- Collaborative release workflows — Get centralized views with web-based visualization of schedules, tasks, team and individual responsibilities, environments, and staff allocation tailored for every release train or lifecycle.
- Incremental conversion to automation — Capture and visualize existing release processes and introduce automation where it delivers greatest performance improvement.
- Granular Configuration Modeling — Captures details and inter-relationships of all configuration items and enables automated deployments, compliance management, and application migration.
- Parameterized Packaging — Deployment packages adapt to differences between environments without modification. “Abstract uniqueness of every environment.”
- Rollback on Error — Deployments are never left partially configured; all changes are rolled back when an error is detected.
- Role-Based Access Control — Granular role- and object-based authorizations ensure integrity of packages and environments.
- Distributed automation infrastructure — You can execute deployments the same way every time — regardless of application type, platform, location, or virtualization.
- Environment management — Maintain consistent infrastructure configurations without scripting, even in the most complex of instances. Out-of-the-box support for IBM WebSphere, IBM WebSphere Portal, and other popular middleware relieves administrators from routine, mundane, and thankless tasks.
- Defect and adaptive decision analytics — Quickly diagnose and analyze the root-cause(s) of application failure, for example, zero-in on any deviance in WebSphere environment configuration, or trace line-by-line execution up to a poorly formed SQL call within the application.
BMC Application Release Automation enables IT operations to:
- Reduce damaging application failures — Eliminate over 95% of configuration errors, the leading cause of application downtime.
- Optimize quality/cost ratio — Improve quality while reducing costs, reduce release times from weeks to minutes, require many fewer FTEs to handle greater release volumes.
- Improve application rollout success rates — Automate handoffs between release teams, enable preview and rollback of changes, ensure configuration consistency.
- Improve compliance and governance — Eliminate 98% of unaudited release processing, enable auditing and reporting, add role-based access control.
BMC’s ARA solution results in shortened release cycles, application and system configuration consistency, and smoother handoffs across groups. Users can ensure that server and application configurations are consistent across environments by tracking application compliance against a policy model. All deployment actions can be authorized based on user roles, ensuring appropriate levels of user access. If necessary, deployments can be rolled back easily.
Comprehensive DevOps Support
Application Release Automation from BMC provides comprehensive release management for the emergent practice of DevOps, as well as Continuous Integration and even Continuous Delivery initiatives. Deployment processes and environment configurations are tailored to the requirements of each release plan and lifecycle, and then executed consistently from Development to Production — without scripting, according to plan, scheduled by team and activity and driving existing automation to successful completion (and reporting along the way).
Whatever applications or application components may come, wherever they may come from, and wherever they are meant to go, Application Release Automation from BMC profoundly eases the movement of releases from development through the deployment pipeline to operations, consistently, reliably, and quickly.
|
|
