Over a period of time the amount of data stored in your Remedy system will increase and affect the performance of the application and the user experience. A slow application guarantees unhappy and inefficient users.  Worse still, over time, the accumulated data will cost more to manage and maintain.

 Applying best practice database indexing and regular maintenance can help mitigate the impact on the user experience. However, reducing data volumes in the right areas is certain to improve overall performance. The practice of managing the volume and location of the data that supports a Remedy system is one of the pillars of a performant, cost-effective system.

 A large data set means it costs more and takes longer to perform all database maintenance operations such as database backups, refreshes of development and test environments. Larger hard disks and tapes are required to store the database and its backups. Removing data from the on-line transactional database altogether keeps these maintenance overheads as low as possible.

 This article introduces the topic of Remedy data archiving and explores the out-of-the-box Remedy archiving functionality.

What will Archiving Do?

When we talk of archiving data, we mean the ability to move data from an on-line location to a different location. While Archiving solutions differ as to where archived data is stored and how it is moved, this is the core feature of any solution.

 The key benefits we look for archiving to bring are;

•  Improved Application Performance
•  Reduced System Administration Costs

The most successful solutions will also;

• Enforce Data Consistency
• Respect the Data Retention Policies of the Users
• Be Operationally Flexible

If you’re still reading this then you probably have a Remedy system that has a lot of data, and is starting to have some performance issues and for which you need to find an archiving solution. 

We hope this primer will be useful, however if you’d like to discuss archiving data in more detail please contact info@alderstone.com.

What Do We Archive?

Typically data is moved from the transactional tables where the most data is created and where reductions in data will have the most positive effect on the user experience. For BMC Remedy ITSM this means Incidents, Problems, Changes, Service Requests, Work Orders and Tasks (and all the data related to them), are all candidates for archiving.

The benefits of reduced data volumes must be balanced against the requirements of the business. Although a policy of archiving all Incidents that have been closed for more than 1 week would boost performance it would significantly affect the ability of the teams using the system to deliver effective services to the business.

Drawing up the data retention policy that is right for your BMC Remedy system will involve coordination with the various stakeholders and will include some decisions about the functionality that your archiving implementation will offer.

Requirements, Requirements, Requirements

IT Service Management is fast moving, and much of the data held in a BMC Remedy ITSM system is very time-sensitive. For example, the fact that today the head of purchasing has forgotten their Windows password and cannot run the month end reports, is a very valuable piece of information to the business today. However this fact will not be important three years from now.

By comparison, the fact that on average the Helpdesk were closing 20% more calls as First Time Fixes three years ago than they do today, is very important for the success of IT Service Management within the business.  

Not all data is equal and the requirements for data retention will differ depending on the type of data we’re considering.

A well-defined data retention policy is critical for the success of the archiving solution. Here are a few questions that you should consider as part of your exploration of the right policies;

• Do you need to retain data for auditing purposes?
• Are there key business reports that require longer periods of data to be retained?
• Do you ever need to un-archive data?
• Are there other sources where the data can be found such as a reporting data warehouse?

The time invested into identifying the stakeholders, understanding exactly what data they need and why, will more than pay for itself in achieving the right solution for your business.

The wrong solution can be more expensive to maintain and less effective for the business than keeping the data in the transactional database. In other words, there are just a few ways your archiving solution can make things better but lots of ways it can make things worse!

Take nothing for granted!

You may be told authoritatively; that there is no way that data can be removed from the system as it simply must be maintained on-line for the auditors or for regulatory requirements. Take the simple step of asking the auditors or relevant enforcement bodies. You may find the restrictions to be less severe than believed. Off-line archiving is a far simpler and cheaper solution than on-line archiving.

In summary, approach archiving as you would any other major enhancement to your system; take time to understand requirements and to understand the repercussions of the decisions you make.

Out-of-the-box Remedy Archiving

BMC Remedy provides the ability to create an Archive Form for any Form in the application. For example you can create an Archive Form for the main Incident Form (HPD:Help Desk) and set up a rule to move data from the “on-line” form to the Archive Form. This feature allows the time of the archiving to be scheduled to minimise the performance impact. It is also possible to set this feature to delete data rather than just moving it to the Archive Form.

The diagram on the right illustrates the way in which data is moved between Remedy Forms on the same ARS Server and consequently data is moved between tables in the same underlying database. 

Because Remedy OOTB Archiving only moves data out of the “on-line” tables into “archive” tables within the same database. If accompanied by database maintenance, this can provide performance improvements to the user experience as well as retaining the data in a location where, with bespoke Remedy workflow, data can be easily accessed by users.

Using Remedy OOTB archiving presents the following challenges;

Bespoke Remedy application enhancements can make Remedy OOTB archiving aware of the relationships between Forms holding ITSM entity data. Unfortunately, this pervasive change modifies a lot of BMC Remedy ITSM Forms. Changes to the out-of-the-box Remedy ITSM Application obviously carry a cost in on-going maintenance and support.

With the challenges posed by the Remedy OOTB Archiving solution, companies are choosing to implement their own bespoke solution for archiving Remedy data that meets their data retention requirements.

Part 2 in this series will look at the design and implementation of archive solutions for BMC Remedy Applications

Outline

Organisations which have deployed Enterprise wide IT applications, such as BMC ARS and the ITSM Suite, will often have the requirement to implement a Single Sign On solution to reduce the burden on IT support and to improve the end user experience.

 We have to accept that SSO is complex, different conventions for user name formats between systems, different repositories of Application and User credential means finding an out-of-the-box SSO solution is a challenge. It is a difficult but necessary balancing act of infrastructure platform and application support, customisations and security concerns.

There are a number of different architectural options when discussing SSO, the selection you make will affect the implementation and support of your solution. This is further complicated because SSO has a range of meanings. In a BMC Remedy context SSO will typically include an authentication against any system which is not Remedy.

This article describes the SSO architecture for Windows Active directory web clients of the BMC ARS Mid-Tier.  It also highlights feature support if a commercial solution is to be sought.

What is Single Sign-On (SSO)?

 Single Sign-On (SSO) is a means of access control of multiple related, but independent software systems. The process authenticates the user for all the applications they have been given rights to and eliminates further prompts when starting those applications during a particular session.

Benefits include:

• Reduce time spent re-entering passwords for the same identity
• Reduce password fatigue from different user name and password combinations
• Can support conventional authentication such as Windows credentials (i.e., username/password)
• Potential for ‘seamless’ or transparent logons where the client technology supports automated forwarding of ‘logged in user’ credentials
• Reduce IT costs due to lower number of IT help desk calls about passwords

 Context Diagram

The diagram below shows the system context at a high level

Sequence of Events

 The sequence of events for an SSO enabled login are:

1. User authenticates themselves into Windows on the Client.
2. The user navigates to Mid-Tier in their browser
3. A customized Mid-Tier login servlet extracts a user token from the HTTP request (if not present then it is requested as part of the authentication with the browser)
4. The browser sends a user token (no user interaction required)
5. The customized login servlet extracts the username and may perform username mapping if the Windows login name format does not exactly match the Remedy login name format
6. The Mid-Tier forms an ARS login request and calls ARS
7. ARS dispatches the login to the AREA plugin.
8. The AREA SSO plug-in validates the Mid-Tier IP and a shared key

Below is a UML sequence diagram that shows the order of events in detail.  The components (actors) are described in more detail in the section “BMC Remedy Enterprise SSO Architecture”

BMC Remedy Enterprise SSO Architecture

 The logical architecture diagram below depicts all the components involved when implementing an ARS Mid-Tier based SSO solution typically seen in BMC Enterprise deployments.   The items highlighted in yellow indicate components that would either be built in a bespoke solution or would be provided and configured when installing a commercial solution.

 The diagram also shows the numerous configuration touch points also described in the sections below.

Browser  

This would typically be IE v6 or later and it must treat the Mid-Tier as a trusted site in order for IE to seamlessly send the user token.  The token exchange between the browser and web server is done using Microsoft NTLMv2.

In a typical enterprise environment the rollout of the change could be implemented via a Group policy change centrally and pushed globally and not individually on each client.

It is possible to configure other browsers (e.g. Firefox) on Windows to do similar, but not via automatic rollout using group policy settings; such a change needs to be performed individually for each installed browser.

 Load Balancer

In enterprise deployment a load balancer typically sits between all of the clients and the web tier.  There are User token passing technologies that are stateless and introducing a load balancer has no significant impact to an SSO solution.  However, NTLM is stateful (i.e. Capable of maintaining the status of a process or transaction)and requires that the load balancer supports:

• Client IP forwarding
• Session affinity

 Failure to support these properties will result in needless re-authentication between the browser and the web tier.  The impact on performance depends on the number of users and concurrent requests.

Additionally, if the production architecture has load balancers between the Mid-Tier and the ARS servers then it is critical that the Mid-Tier server IP addresses are preserved.

Apache HTTPD

Although the Tomcat Java Application server is also an HTTP server it is recommended by Apache to front Tomcat by a dedicated HTTP server, such as Apache HTTPD. Without going into great detail this guidance is based on the dedicated HTTP server implementations being more robust to high volumes for serving static data and better handling of clients with sub-optimal session closedown behaviour.

Apache Tomcat          

Apache Tomcat is the J2EE WebApp container that hosts the Remedy Mid-Tier WebApp.

There is often no need to change the server configuration.  However, the Mid-Tier web app will need modifications.

Security Filter

This is an optional component and is not required if the user token is easily extracted from the HTTP headers. When dealing with NTLMv2 though, this component is a J2EE Servlet filter that challenges the browser client for the NTLM token – the NTLM challenge is a multi-step (and stateful) process that is defined in a protocol specification by Microsoft.  It is a non-trivial protocol that has been implemented by the likes of the commercial Jespa Java library discussed later.

 In a J2EE environment NTLMv2 can be implemented by the Jespa Component. ( http://ioplex.com/) Implementing the browser NTLM challenge in a Filter simplifies downstream processing in the custom Mid-Tier authentication servlet.

 Alternatively, if Microsoft IIS is used then it is possible to extract the username from the HTTP session and forward this on to Tomcat.  As NTLMv2 token extraction is alien to a Java stack it removes the reliance on a commercial 3^rd party library to perform the extraction.

 Mid-Tier Servlet  

This is the out-of-the-box Mid-Tier J2EE Servlet based entry point.  By default it will dispatch to the standard login page servlet.  To replace the standard Mid-Tier login process a custom login servlet can be specified in the Mid-Tier configuration file. [see the section named ' Configuring the User Name Alias’ in the BMC document “BMC Remedy Action Request System - Configuration Guide”]

 Custom Auth  

This bespoke or 3rd party component overrides the default Mid-Tier Authentication mechanism via a BMC extensibility mechanism. The component implements a BMC Remedy API and is responsible for extracting the username from the user token and obtaining the Mid-TierShared Key.  The Mid-Tier shared key is a common password shared between all Mid-tiers and the SSO plug-in that runs on the ARS server.  It is important that this shared key is stored encrypted.  A shared key is required because at no point is the user password transmitted.  In fact, in order to enable SSO within BMC Remedy the user must have no password defined in the User form.

 The username of the Active Directory user needs to correlate to the BMC Remedy login (or alias, see the BMC document  “Integrating BMC® Remedy® Action Request System® with Single Sign-On (SSO) Authentication Systems and Other Client-Side Login Intercept Technologies”)

 The actual Active Directory username can be obtained from the token in any one of 3 standard formats:

1. Username - only username, for example.: joeuser
2. Backslash - username + domain name separated by a symbol '\'
         For example.: example\joeuser
3. Principal - username + full domain name separated by a symbol '@'
         For example.: joeuser@example.com

It is at this point any custom transformations or other lookup can be performed, if required, in a bespoke implementation.

If a commercial SSO product is being used it is important to understand what transformations are supported at this step when considering how to map from Active Directory to BMC Remedy users.  Also bear in mind that there is username aliasing support in ARS too [see Integrating BMC® Remedy® Action Request System® with Single Sign-On (SSO) Authentication Systems and Other Client-Side Login Intercept Technologies]

 ARS  

A bespoke or commercial solution will need to provide an AREA plugin and therefore the ARS server config file (arg.cfg or ar.conf) will need to be modified accordingly. 

If the mapping from user token login names to Active Directory login names is required then it is possible to add an additional filed to the standard ARS User form to accomplish this. See "Configuring the User Name Alias" in the "ARS 7.5 Configuration guide.pdf".

 AREAHUB    

This OOTB component is a plugin that allows Remedy to support more than one authentication mechanism.  Note: ARS versions >= v7.6 may eventually support multiple AREA plugins.          

AREA,  AREASSO and the AREALDAP and will consult each one in turn when a user logs in.

 AREASSO  

This plug-in will be called by the ARS login mechanism any time an user attempt to authenticate, in either a bespoke or commercial solution this plug-in has 2 main tasks:

1. validates the request has come from a mid-tier IP and
2. validate the request has the correct shared key, by comparing what came from the CustAuth config to the shared key stored as part of the plugin configuration

If those 2 checks pass the user is authenticated and the plug-in simply responds with either a YES or NO.

It is important that this shared key is stored encrypted to ensure casual browsing of the filesystem does not expose this ‘global’ password.

NOTE: If a bespoke solution is to be built BMC provide an example C based SSO plug-in, search the support forums for: AREA_SSO_ALL_v206MT_v209AREA

 Any commercial solution will need to supply you with either a native or a Java plug-in; so you should check platforms and version support if it’s a native plug-in.

 However at the time of writing ARS only supports 1 AREA plug-in. This restriction is alleviated by the AREAHUB plug-in; as the area AREAHUB plug-in is native, you will not be able to use a Java based AREA SSO plug-in.  

 AREALDAP  

The out-of-the-box  BMC LDAP plug-in used to validate usernames and passwords again LDAP repositories (e.g. Microsoft Active Directory).  This may be required if, for example, only your MidTier users are using SSO and your User Tool users do not have the necessary client SSO DLL’s rolled out to the native clients.

 Active Directory

This component represents Microsoft Active Directory.  For a SSO solution based around NTLMv2 authentication and the Java JESPA library the Mid-tier component will need to be given its own AD ‘computer’ login as the Jespa implementation appears to Active Directory as a ‘machine’

Conclusion

As you can see from the myriad of configuration touch points and security concerns, implementing a bespoke SSO solution is a significant undertaking and a commercial option should be considered before going down that route.  Hopefully this technical dive into BMC ARS Mid-Tier SSO can help shine a light into a dark area and will help you when you need to design and/or troubleshoot the chosen implementation.

 Further Information

BMC have recently released BMC Single Sign-On product.  At the time of writing it does not support the transparent extraction of the Windows users’ credentials in the NTLM  token therefore they will get prompted for a login.  Support of such functionality is on the product roadmap.

If you would like to discuss your specific requirements, or have issues with your current SSO solution please feel free to contact us at info@alderstone.com

More and more of our customers are seeing a real need for integrations between Service Desks. These may be within their organisations or, more recently, to Service Desks within external organisations. As companies migrate systems to the Cloud,  outsource some services or use external suppliers, the need for integrated systems to reduce the need for manual data input has increased. However, even if the software for two endpoint systems is the same, the effort required for integration should not be underestimated.

 What do you need to consider if you are about to start such a project?

 Here are 10 things to get you started:

1. Objective

 As with any project before starting it should be very clear to everyone involved what the project is aiming to achieve and why. This is even more important with a Service Desk integration project because of the different parties involved. As a minimum this will be multiple departments within the same company but is increasingly likely to span company boundaries and possibly include multiple geographies. If everyone is working towards the same clear objectives the project is far more likely to be a success.

 2. Systems Thinking

 This is often the most difficult thing for people to accept. When you integrate two systems you are building one larger system. If the solution is considered in these terms, then a number of the other items on this list can be addressed far more readily. These include:

• Roles and Ownership
• People
• Support
• Open Communication

One system, one team, one solution - irrespective of departmental or company boundaries.

3. Roles and Ownership

 As well as the objective being clear from the start the roles of the various actors relating to the solution need to be clearly defined. With departmental or company boundaries involved it is far too easy when a production error occurs to blame someone else. There will be existing owners of the endpoint systems but ownership of the integration needs to be defined, understood and agreed by everyone.

 4. Monitoring

 The technology supporting an integration works in the background and is typically invisible to the end user until it breaks. However once it does break the symptoms can become very visible very quickly. As the data most frequently transferred between Service Desks is Incident information by definition something else is already broken. Adequate monitoring is therefore important and this also relates to 'Roles and Ownership'. The monitoring not only needs to highlight something that is not working but also notify the correct people to resolve the issue.

 5. Technology

 A wide range of technologies can be used to transfer data between Service Desks. From tools designed specifically for the task, such as Enterprise Service Bus messaging systems, to tools that can be adapted to the task of systems integration, such as Run Book Automation or Orchestration tools. There is no silver bullet; the best solution depends on a number of factors, some of which are:

• What software is used in each endpoint system?
• How much and what type of data is to be transferred?
• What are the skill sets of the people who will support the solution?
• Is this part of a larger implementation?
• Is the use of Open Source an option within the organisation?

 The costs and features of these options will vary. The best option within your organisation may not be the slickest message passing system. It may make more sense to reuse a technology you have already licensed and have knowledge of but which is less efficient.

 6. People

 Joining two systems involves collaboration between the teams owning and supporting those systems and as such the people involved need to be team players. Practice makes perfect and integration is no exception. The project is more likely to run smoothly if you have people on the team who have done this before. This includes those involved from the two endpoint systems, project management and integration partners.

 7. Support

 Once the project has completed it will be handed over to support to manage the 'Business As Usual' activities. It is prudent to involve the support teams early in the development process, consult them on the monitoring and logging requirements, include them in the testing and provide clear processes and documentation for the finished system. This will help to ensure that the transition is smooth and uneventful. Involvement from an early stage will help promote ownership for the longer term.

 8. Logging

 After go live most issues occur either because of something that wasn't adequately tested or because of an issue with one of the endpoint systems.  The purpose of logging is to enable the source of an issue to be identified quickly, the correct responsible party engaged and for them to be able to rectify the issue. Logging is fundamental to a process that runs in the background, as it is the only way to 'see' what has happened. Appropriate time needs to be allowed during implementation to ensure that logging is designed and implemented properly.

 9. Open communication

 It is very easy to adopt a 'them and us' mentality when working with other departments, external customers and suppliers. From the outset of any integration project, open communication, honest discussion and the sharing of ideas should be strongly promoted. Only with an environment of openness, where no one is afraid to speak up when they spot a potential issue, can a project be really successful.

 10. Continuous improvement

 This key element of ITIL is important here. A good integration solution will typically be invisible to the end user, as it will be providing seamless data transfer between the systems they use as part of the service provided. As such it will be easy to overlook in the process of Continual Service Improvement, However In order for this to remain the case it must be evolving, when the end systems change, as the traffic increases, after every outage. Only by continual review and improvement will the expected service levels be maintained.

 We hope this is helpful when considering your next Service Desk to Service Desk integration, and if we can help in any way please don't hesitate to contact us at info@alderstone.com

Cloud computing is receiving a lot of press recently. Anyone in the industry can’t help but notice the increasing marketing push by the infrastructure, platform and application vendors.

What exactly do we mean by Cloud Computing? The most concrete and widely accepted definition seems to be the National Institute of Standards and Technology (NIST) definition of cloud computing, which we covered in part one of this series.

Implications and Challenges

So what does this all mean for Service Management? At first glance it could be seen a readily facilitating the BSM dream, whereby a business can define tight SLAs for technical services that are required to support their Business Services.

However, for an enterprise who may be considering the leap into using cloud based services there are a multitude of things to consider.

This brief article is intended to provide some food for thought in this regard.

Impact on a few of the key ITIL processes

Incident Management

Modern enterprise systems are complex. Identifying the cause of an incident when parts of the infrastructure/service are ‘in the cloud’ can be difficult, especially as these services may be only serving part of a process.

It is also worth thinking about how Incidents will be passed to and from the cloud provider. Clearly an automated solution would be preferable as no business wants to be in a telephone queue to the provider of your CRM system when you have a severity one and angry customers of your own to deal with. On the other side of the coin…you need to be informed that there is an issue before your customers find out.

Service Asset and Configuration Management

In the past few years enterprises have made great strides in understanding their infrastructure and service topology and modelling these in a CMDB. How does replacing your own infrastructure with cloud based solutions affect this as a trend? The intuitive and wrong answer is ‘phew…we don’t need to worry about THAT anymore’! This is unfortunately not the case. Companies still have business services to operate and will undoubtedly still have some infrastructure to manage. When your customers complain that function x is no longer working, you will still need to understand what the underpinning technical services are, whether they are internal or external or a combination of both.

Access Management

There are several challenges that present themselves in this area. Most enterprises will have a robust internal IDM solution. Enterprises need to consider this will integrate with the chosen cloud service. Sharing Identity and Access Control amongst systems you own and maintain is one problem, sharing these across disparate third party managed systems is quite another.

In the modern workplace staff turnover can be quite high, It is important to consider how quickly can these cloud based services activate and deactivate users.

General Considerations

Security

One of the key concerns that is raised in almost every conversation about cloud computing is data and system security.  Enterprises need to consider any commercial and/or regulatory constraints. Quite apart from any regulatory implications, we have all seen the bad press that accompanies a personal data leak for any large company. It is clearly critical that in choosing which systems to put in the cloud, which deployment model to choose, and which provider to select that data and system security is paramount.

The Cloud Security Alliance have prepared some excellent guidelines on moving your data, functions, applications and processes into the cloud. The guidelines centre around the decision making process as to which of your systems are you able or willing to risk in the cloud.

Availability

The elasticity of cloud based services is one of the strong selling points, but how do we guarantee that availability?

The ‘on-demand’ , ‘under the hood’ nature of the automated computing, storage and network resources provided by Cloud computing can give the illusion that these resources are infinite and will be always available. While in most situations this may be true, anyone who has worked with a large financial system one can imagine the load put on a thousand ERP solutions at year end.

Conclusion

Clearly the above is just touching the surface, and represents just some of the areas for discussion amongst our consultants when assisting customers making the leap to the cloud. It should be an interesting journey, and one we hope we will share with many of you.

Of course, cutting through all of the above is  Service Level Management.

In part 3 of this series we will explore some of the issues pertaining to Service Level Management and the cloud.

The official BMC release notes for ARS 7.6.3 describe all of the new features and known issues of BMC Remedy AR System (ARS) 7.6.3. (This document can be downloaded from BMC's site with a valid support account.) This article will technically review the new features and look beneath the hood to identify the benefits, pitfalls and opportunities which 7.6.3 brings us.

ARS 1.1 was released in Q4 1992, 18 years later the application development toolkit underpins the industry leading BMC Remedy ITSM Suite. Remedy Corporation saw ARS as both a rapid development toolkit and an ideal technology for the IT Service Management market. Bespoke applications developed using ARS were as, if not more, common than the applications developed by Remedy Corp. Over time, the focus of Remedy Corp, then BMC, was for ARS to take second place to the comprehensive ITSM Suite applications developed using the ARS toolkit. The number of bespoke Remedy applications has been declining as the ITSM suite has grown more popular and ubiquitous. BMC have now positioned the ITSM Suite as a high-end platform for IT Service Management within the context of BMC BSM; consequently fewer companies are leveraging ARS as a bespoke application development platform.

The recent releases of ARS 7.5 and ARS 7.6 have elevated both the development platform and architecture of ARS to become truly modern and very feature-rich. Ironically, bespoke application development using Remedy is now finally capable of creating sophisticated and feature rich applications with excellent user experiences; just as the capabilities of the toolkit are least well promoted.

Typically releases for ARS follow a pattern where a release has been primarily focused on the back-end, development and infrastructure OR the user experience. 

Review ARS Release History >>

ARS 7.5 contained a large number of user interface enhancements, and because ARS 8.0 will be the first release which does not include the Remedy User Tool, we would expect ARS 8.0 to be a UI-focused release. Once BMC are able to focus purely on the web interface without being constrained by the development overhead of a dual platform user interface, we can expect substantial steps forward with ARS 8.0.

We would therefore expect ARS 7.6 to be an architecturally focused release, building on and refining the functionality brought in with ARS 7.5. We are not disappointed in this expectation; ARS 7.6 is primarily focused on improving performance of the infrastructure and applications. This release also has some thoughtful improvements to the web architecture which lay the foundation for ARS 8.0. Finally, ARS 7.6 sees some very welcome refinements of the new objects introduced in ARS 7.5 as well as some great new features.

Performance Improvements
In our opinion this is a key driver for this architectural release. The footprint of ARS has grown increasingly larger as the target market has moved into the enterprise space. The vast array of new features in ARS 7.5 has introduced some performance issues for customers, however for consultants the system requirements of the new ARS 7.5 and 7.6 environments are challenging.

Previously it was possible to run a full ARS and ITSM server installation within a VM on a laptop and even to run multiple VMs in parallel. Our recent build of a Windows VM running Oracle, ARS 7.6, and the full ITSM 7 suite requires far more memory and system resources than ever before. A minimum of 1 GB RAM is required to enable the VM to run at all, around 2GB is needed to be able to develop workflow, around 3-4GB is required for a performance good enough for customer demonstrations. We hope to see more innovation from BMC to allow the performance of the platform and applications to support Laptop virtualisation.

Improved Mid Tier Caching

There are several significant improvements to the way Mid Tier handles its cache.

As always, changes to the workflow of a Remedy application need to be carefully planned due to the recaching of both ARS and Mid Tier server caches. Recaching has been an issue for a while and BMC are targeting this persistent issue by improving the way Mid Tier recaches.

Cloud Computing is the hot topic in IT at the moment, however there is still some confusion as to what this term actually means.

The most commonly accepted definition seems to be that of the National Institute of Standards and Technology (NIST).

In the coming weeks we will be exploring the impact of Cloud Computing on Service Management, but for this first part we have will simply introduce the NIST definition

 NIST Definition of Cloud Computing

Cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model promotes availability and is composed of five essential characteristics, three service models, and four deployment models.

Characteristics

On-demand self-service. A consumer can unilaterally provision computing capabilities, such as server time and network storage, as needed automatically without requiring human interaction with each service’s provider.

Broad network access. Capabilities are available over the network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs).

Resource pooling. The provider’s computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to consumer demand. There is a sense of location independence in that the customer generally has no control or knowledge over the exact location of the provided resources but may be able to specify location at a higher level of abstraction (e.g., country, state, or datacenter). Examples of resources include storage, processing, memory, network bandwidth, and virtual machines.

Rapid elasticity. Capabilities can be rapidly and elastically provisioned, in some cases automatically, to quickly scale out and rapidly released to quickly scale in. To the consumer, the capabilities available for provisioning often appear to be unlimited and can be purchased in any quantity at any time.

Measured Service. Cloud systems automatically control and optimize resource use by leveraging a metering capability at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported providing transparency for both the provider and consumer of the utilized service.

 The SPI Service Models.

Cloud Software as a Service (SaaS). The capability provided to the consumer is to use the provider’s applications running on a cloud infrastructure. The applications are accessible from various client devices through a thin client interface such as a web browser (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.

Cloud Platform as a Service (PaaS). The capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possibly application hosting environment configurations.

Cloud Infrastructure as a Service (IaaS). The capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, deployed applications, and possibly limited control of select networking components (e.g., host firewalls).

Deployment Models

Private cloud. The cloud infrastructure is operated solely for an organization. It may be managed by the organization or a third party and may exist on premise or off premise.

Community cloud. The cloud infrastructure is shared by several organizations and supports a specific community that has shared concerns (e.g., mission, security requirements, policy, and compliance considerations). It may be managed by the organizations or a third party and may exist on premise or off premise.

Public cloud. The cloud infrastructure is made available to the general public or a large industry group and is owned by an organization selling cloud services.

Hybrid cloud. The cloud infrastructure is a composition of two or more clouds (private, community, or public) that remain unique entities but are bound together by standardized or proprietary technology that enables data and application portability (e.g., cloud bursting for load-balancing between clouds).

In part two of this series we will explore some of the challenges this new application of technology poses in the world of service management.