Sunday, September 21, 2008

ITIL v3 and the Continual Service Improvement Model: A Strategy for Optimizing Value, Quality and Performance

Today, more than ever, IT must tightly align with the business. IT performance is tied to business performance: Every person-hour and every dollar must be allocated to deliver maximum business value. IT now provides much of the value the business offers its customers—as well as the effectiveness with which it works with its supply chain and business partners.
IT also must respond more quickly than ever to new and evolving business requirements. Two-year development cycles simply no longer work. So, alignment must be attained and maintained with tremendous agility.
Tight, timely business alignment can be achieved with the right strategies and tools. The IT Information Library (ITIL), originally designed by the British government to codify best practices and approaches to systems management, provides some of the industry’s most important guidance for maintaining alignment. Disciplined mainframe systems management—the structured adherence to change management, disaster recovery planning, testing and deployment—formed the basis for the development of ITIL. Although these processes had been long established in the mainframe world, they were still new to distributed systems. ITIL bridged that gap, offering a solution for all architectures.

This article focuses on one aspect of ITIL—continual service improvement—as it relates to mainframe systems management and the alignment of IT with the business. It’s based on the experiences of top IT organizations that have successfully implemented continual service improvement best practices in the mainframe environment. By learning from these experiences, IT organizations can effectively optimize the total business value they generate.

ITIL: Making IT Work
Business depends on IT. IT staff have technical skills and certifications, but their job isn’t to simply write code and maintain server performance. It’s to align with business goals to fuel growth and innovation. And that reflects a change in thinking from years past.
In describing his role 10 years ago, for example, the manager of IT support for a leading aerospace contractor probably would have focused on his coding expertise, certifications on systems and networks, and the number of patents he holds. Today, he speaks of business metrics and goals—and his team’s performance is measured by their response to business needs: “I manage a major service and support function for an enterprise,” he says. “It just happens to be IT.”
IT staff must be fully aware of the business needs and be completely focused on addressing ongoing service requirements. This can be achieved through the kind of proven best practices for which ITIL provides excellent guidance. The latest iteration of ITIL, version 3 (v3), outlines an approach for making IT as much a part of the business as an assembly line or a warehouse. ITIL v3 states that “capabilities and resources in the management of IT and the management of services are no longer perceived as merely operational concern or detail.”

In other words, IT services aren’t special services governed by their own arcane rules, as they were previously assumed to be. They deliver services that must be managed like all other business services—with attention to business goals, risks, service levels, and the bottom line. They also must be highly adaptable, enabling IT to rapidly respond to the changing business environment. Instead of being merely “cost centers,” IT services must be integral components of profit centers, providing the capability to increase revenue.

ITIL v3 explicitly supports the application of contemporary QA strategies to IT, especially in its fifth book—which addresses “continual service improvement” (see sidebar titled “ITIL v3: The Service Lifecycle”). A hallmark of present-day business management, Total Quality Management, Six Sigma, ISO 9000, QS9000, and Lean Manufacturing all rely on identifying and fostering a continuous cycle of planning, testing, implementation, and evaluation. ITIL was built upon one of the first descriptions of this cycle, the Deming Cycle (Plan, Do, Check, Act).

ITIL has always proposed that IT should think in terms of delivering services to the business—rather than implementing and maintaining the various “moving parts” of the enterprise IT environment. In practice, however, this message was often lost. In many cases, ITIL programs began and ended at the service desk, where ITIL practices were easily applied and yielded quick, but incomplete ROI. The next steps, which promised greater financial return, usually weren’t implemented because they required more significant shifts in thinking and behavior. They include managing change, development, and planning.

However, the few “early adopters” who’ve been able to change their approach and implement ITIL more fully have shown the business value of making the leap. Documented case studies of increased quality, higher availability, and better price-performance have validated the importance of making this seismic shift in IT strategy.

CMDB: At the Heart of Quality-of-Service Initiatives
To address the quality issue, ITIL v3 places increased emphasis on the Configuration Management System (CMS), which includes the creation and maintenance of Configuration Management Databases (CMDBs). One of the goals of the CMS with the CMDB implementation is to increase uptime by decreasing the time it takes to restore services. Uncontrolled and untested changes and configurations are a major cause of substantial interruptions or slowdowns in service. They also can be an obstacle to planning and implementing new services. The CMDB can show the business context of services by providing visibility about relationships between entities and their underpinning components—which can be system resources, applications, and services, among other things. As a result, it can be at the heart of quality-of-service initiatives, where premium services can be offered at a premium price, and offerings can be readily changed as business needs dictate.

The ultimate goal is to follow the example of leaders such as Amazon and Google in adapting technology to business, using IT to generate new revenue sources and levels of productivity. Although these companies opted for distributed servers (largely Unix and Windows), large enterprises have found the mainframe to be the optimal platform for generating new revenue streams. IBM has continued to modernize the mainframe so it offers newer capabilities such as WebSphere, SOA and Web services, while continuing to lead in Reliability, Availability, and Scalability (RAS)—as well as in price-performance, reduced energy consumption, and environmental impact. ITIL v3 promises to enhance this already compelling value proposition through the continual improvement cycle that keeps business goals in focus at every stage and IT involved at every point in the process (see sidebar titled “Traditional IT Management Systems in the Service Lifecycle”).
A Service-Centric View of Systems Infrastructure
Continual improvement requires that business services be followed through their entire service lifecycle. The philosopher George Santayana once wrote, “Those who do not remember the past are condemned to repeat it.” The same principle applies to service improvement in IT: Enterprises that don’t track and use all the information they can maintain about the services they provide to the business are condemned to keep repeating the same mistakes.
But how can IT organizations best create and preserve this knowledge?
The difficulty of this challenge has deep roots in the IT industry. IT professionals are highly trained engineers. Without their specialized knowledge and experience, IT infrastructure would come to a crashing halt. But depth of technical expertise is rarely matched with breadth of knowledge about how IT as a whole supports the business. A network engineer with detailed knowledge of the latest in switching and routing technology, for example, may have little interest or knowledge of the applications that use the networking services his group provides. He or she may have even less interest in the business rationale for the existence of those services. Similarly, performance analysts watch server and transaction performance, but may not understand how those performance metrics affect the actual end-user experience—which is ultimately what matters to the business.
This narrowness of focus is understandable. Attaining and maintaining competence in a specialized discipline such as network engineering is no easy task. But a stovepipe approach to IT management is one of the things that works against business alignment. And such an approach can become especially problematic when services cross mainframe and distributed systems.
Stovepipe specialization makes continual improvement very challenging. Was a rollout issue a problem in the way the design was communicated to the development team? A flaw in the design? Inadequate funding for staff or training? Was a persistent problem in production the result of a faulty design or misinterpreted priorities in operations?
To answer these questions, it’s essential to understand a service’s entire design process or history. This is one of the central lessons of ITIL: Strategy, design, transition, and operations all must contribute to continual service improvement. To achieve this, mainframe and distributed systems can’t be treated as separate silos. They must be incorporated into a holistic view of the various business services they support.

Summary
ITIL v3 and the continual service improvement model offer a way to achieve ongoing optimization of value, quality, and performance. If you’re looking to improve quality of your services, while increasing the ability to dynamically manage them, this may be the part of ITIL to focus on now.

Wednesday, May 21, 2008

WebSphere Express in a VMware guest - Cloning

I am sure that you can save lot of time & efforts if you proceed
installing WAS after the clone.

Khaja.


On May 21, 2:14 am, tim.w...@schwans.com wrote:
> We are getting ready to deploy a new site, using WebSphere Express hosted in a VMware ESX environment. One of the nice features of VMware guests is that one can clone a machine; I'd like to be able to build on instance of my host machine and then clone additional from there.
>
> The hosts will be running RHEL v.4 Update 6, WAS Express 6.1 and Apache Web Server. I can clone the first instance, and re-naming the OS is quite simple; here's my question. If I install WAS before the clone, is there a way to reconfigure the install to use the new machine name for the server/cell/etc? Is there a list of files that contain the name I can edit, or an administrative task I can perform? Or am I best off doing the clone before the install? I am working on building the response files for the installation(s) and I could have the necessary files ready and actually probably script the install, but as always, I am looking for the option that will give me the best/quickest results.
>
> Thanks in advance.
>
> Tim

Sunday, May 18, 2008

MQ Link

From: scag...@us.ibm.com
Date: May 16, 4:12 pm
Subject: MQ Link
To: ibm.software.websphere.application-server


I just set up an MQ link using the following doc:

 http://www.ibm.com/developerworks/forums/thread.jspa?
threadID=178523&tstart=0&messageID=14016821

I did not secure the link, becuase I do not need SSL security

How do I test the link (other than using a MDB)

Can I view MQ files from within WAS using the MQ link.  Can I see the
contents or view the number of messages on the queue.

If not, in what way can I test the MQ link ?

Fwd: Best Practices

ibm.software.websphere.application-server


Ok, here's the short story. I work at a place where we use Websphere
Application Server with Oracle. Our environment consists of around 8
servers, each with Websphere along with one of the servers as Oracle.

Our architects along with help from IBM originally setup these WAS
servers to use the IP Address instead of a hostname or FQHN, etc.
Since these clusters are setup on a private LAN to talk to one
another, this works how it is. We usually have them talking with one
another either thru their own switch or VLAN, using IP Addresses.

We have a partnership with another company who does testing (sort of
like our QA department) and they hired this guy who claims he knows
everything that takes the servers we setup and installs/integrates it
into their environment to test. Even though he's never touched
websphere before he got hired, he's now trying to demans we change our
long process of using FQHN instead, saying it's best practice and
claims that IBM Websphere documentation says to avoid using IP
Addresses, even though IBM from the beginning helped us setup our
clusters with IP Addresses. (To make that portion short, our actual
client who uses this environment will not allow a separate DNS for
FQHN). I also believe that if you want to go by best practices, you
would skip setting these up using the /etc/hosts like this guy wants
done on each server but this is just making a simple setup more
complicated cause we gave them a new cluster and they refuse to put
the backend IP Addresses we used on its own VLAN or buy a switch.

Can anyone tell me if there's any documentation that actually states
in writing that IBM says to avoid using IP addresses when setting up
WAS, even though I've seen some documentation use IP Addresses instead
of hostnames when setting up clusters?

And trust me, I've been a Unix admin for a long time, I understand
"best practices" but I also believe in, "if it isn't broke, don't fix
it". I have a case against this guys demands so we don't have to
change our whole process of delivery and we want their test
environment exactly how production is setup but I hate it when people
might be blurting out things that aren't necessarily true.

Thanks.

Newsgroups: ibm.software.websphere.application-server
From: "Ben_" <re...@newsgroup.com>
Date: Sat, 17 May 2008 09:27:51 +0200
Local: Sat, May 17 2008 3:27 am
Subject: Re: Best Practices

they hired this guy who claims he knows everything


Exporting your frustation here won't help... :-)


> saying it's best practice and claims that IBM Websphere documentation says
> to avoid using IP Addresses


Generally speaking, it's indeed recommended to use DNS aliases instead
of IP
addresses or real hostname for the flexibility it brings in terms of
network
and system management.

A drawback of this I can think of is that it opens the server to DNS
spoofing attacks.

> even though IBM from the beginning helped us


It's not a guarantee. I saw IBM consultants do weird things to say
the
least... :-)


> they refuse to put the backend IP Addresses we used on its own VLAN or buy
> a switch.


I don't understand what you mean here.

If they prefer to use hostname, they can put it in your/their DNS.

> Can anyone tell me if there's any documentation that actually states in
> writing that IBM says to avoid using IP addresses when setting up WAS,
> even though I've seen some documentation use IP Addresses instead of
> hostnames when setting up clusters?


There is enough formal documentation where use of IP or hostname are
mentionned, be it in Technotes or InfoCenter.

E.g. this Technote explains how to change it:
http://www-1.ibm.com/support/docview.wss?uid=nas1c6cf048cd783df7b8625....

Thursday, May 15, 2008

WebSphere Technical Exchange Webcast

WebSphere Application Server Administration with Jython
Presenter(s): Bob Gibson
Time: 28 May 2008, 11 AM EDT (GMT-4)

Insufficient WebSphere® Application Server administrative scripting
examples written in Jython are available for review and learning.
Techniques, idioms, and some complete Jython scripts will be
described, discussed, and made available.

Please call into the phone conference and join the e-meeting 10
minutes early.

Web conference

URL:

https://www-1.ibm.com/collaboration/webconferences/center/meetingdetails.jsp?meetingId=1A34A21E8DAB9DB6A294EDA871BC1BA8

Password: wste28may

Phone conference
Confirmation number: 4249220
US Toll-free number: 888-293-6953
International number: 719-325-2177
IBM only tie-line: 650-2041
Belgium 0800-75239
Denmark 8088-6220
France 0800-903255
Germany 0800-181-9023
Italy 800-873-740
Netherlands 0800-023-5304
Norway 800-19666
Portugal 800-819-729
Spain 900-947-605
Sweden 02-079-0880
Switzerland 0800-564-398
South Africa 0800-980-989
United Kingdom 0808-101-1147

Bookmark and Share
Join the TrafficZap Exchange