Service Matters! ITSM & IT Management

Have you ever thought of the reason why Pseudo-wire configurations over MPLS cloud are getting popular? Pseudo-wires are common in wireless especially in Long Term Evolution (LTE) to transport traffic from eNodeB to EPC (Evolved Packet Core). Over and above this, pseudo-wires are being used for international point to point connections. Pseudo-wires are even used as a replacement to international SDH/Sonet circuits. By using pseudo-wires, you get the same Quality of Service and operational specifications similar to transparent transmission circuits which are created by combining multiple vc4's in Vc41v configuration.

Latin American suppliers, in particular, have been using pseudo-wire as an upcoming trend for their customer's point-to-point connectivity requirements. This is achieved over their MPLS cloud with major destinations.

So what are the parameters a customer should anticipate from a service provider who provides a point-to-point connectivity over their MPLS cloud in the form of pseudo-wire?   

·         VLAN ID transparency: The circuit must support IEEE 802.1q VLAN trunking and be VLAN transparent. It must not be necessary to inform the supplier of the VLAN IDs in use or the bandwidth required by each VLAN ID. The supplier must comply with this requirement.

·         Quality of Service: Service providers mostly use the highest QoS level which can be premium.

·         Security: As an internet carrier on the same L3 platform especially in the global routing table is considered as an unacceptable security risk. But the service provider is transporting the point-to-point circuit directly over MPLS. So there is no layer 3 or internet element involved.

·         MTU: It can provide MTU which is 1722+ (Ethernet MTU)

·         Latency: In most of the cases the latency will be little higher compared to the sonet/sdh implementation. This should be taken care during the planning stage.

·         Availability: The availability can be as high as 99.999%.

Why do service providers prefer to use Pseudo-wire or what can be the service providers business benefit while using pseudo wire concept?

The main advantage is all about cost savings - savings by not installing any cross connects, fibers, DACS or fibers or DWDM systems specific to create SDH/SONET network as well as associated sync network. All traffic will pass through the MPLS cloud and the slices of bandwidth will be configured in MPLS network according to the requirement from client.

As I said if there is no sync network, then how is sync chieved?  Although packet timing and synchronization has not met universal adoption yet, it is no longer a barrier to rolling out packet backhaul, with widespread acceptance of IEEE  1588v2 products, and SyncE coming along as an added option.

With these advantages, there is little wonder that Pseudo-wire configurations over MPLS cloud have become one of the hottest trends in the Networking space.

Continue reading "Pseudo-wires over MPLS network - Dawn of a new era?" »

Posted by Shaji Kumar at 8:43 AM | Permalink | Comments (0) | TrackBacks (0)

As experience always dictates and what typically people with grey hair always say - 'Knowledge is present everywhere. It is up to an individual to learn and understand.' But in today's world, knowledge is essential; knowledge is solution to an issue which in turn means that knowledge is customer satisfaction. The one who has more knowledge actually is better-placed to excel. It could be as simple as possessing a word document that everyone is searching for or as complex as understanding a concept that others are finding it difficult to grasp! To know more, read on...

 

Continue reading "What you (want to) 'Know' is what you (want to) see!" »

Posted by Ravindran A. Varier at 12:35 PM | Permalink | Comments (0) | TrackBacks (0)

Cloud has started to become ubiquitous in the world of technology and none of the practitioner discussions or plans are complete without keep cloud technologies on the horizon. Till a few years back, Service Management professionals were busy in discussions on - how do they need to change their management methods in order to manage the cloud? Compare that with the present, where the cloud technology has matured such that it is being used as one of the critical vehicles to deliver service management.

 

With a view to enable experience sharing within the community and for service management professionals to take advantage of peer knowledge, ITSMF Australia Victoria Chapter is launching a Special Interest Group (SIG) on Cloud Service Management. The first SIG will be held on 14^th March 2012 in the Infosys Docklands office at Melbourne, Australia. Topics of interest for discussion are quite open and some of topics to be discussed may be Service Management for Cloud, Impact of Cloud on Processes, Cloud use cases for efficiency and effectiveness, Skills and trainings for Cloud readiness, etc.

 

Join us at the launch of this "Cloud Service Management Special Interest Group", an open discussion moderated by me and my colleague Rishi Pattnaik. Visit the event page to register and find more details on the session.

Continue reading "ITSMF Australia, Victoria Chapter, launching new Special Interest Group on "Cloud Service Management"" »

Posted by Gautam Nadkarni at 2:17 PM | Permalink | Comments (0) | TrackBacks (0)

Hello all faithful followers!

It has been a fun filled 5 years for the ITSM Service Matters Blog - and now, we want to make it bigger.

As of February 2012, we will be expanding our focus with a new blog - Infra Matters which will cater to the latest trends across IT Service management, Data Centers, End User trends and emerging technologies in the IT infrastructure Services space. As a result, the ITSM Service Matters blog will now be merged with the new blog, and will not appear as a separate link.

Click here to access the new blog

Posted by Administrator at 7:44 AM | Permalink | Comments (0) | TrackBacks (0)

Cloud Computing continues the march towards all of the enterprise. Nowadays it's almost become cliché for technology companies to talk about products as 'Cloud-Enabled' or 'Cloud based'. In fact if tech startups do not have cloud 'baked' into their business plan, they will not get too far in the funding rounds. For Enterprises as consumers of cloud services, there are many options to choose from, as they start to bring cloud computing into their mainstream strategy.

However one of the areas that has not been talked about much, is the management side of the house. ie how does one 'manage' the cloud. Or does such a situation even exist. Isn't cloud supposed to enable one to do more and of course automatically!.

 Isn't Infrastructure as a Service (IaaS) really an automated programmatic interface served on top of commodity infrastructure? Will SaaS platforms eventually eat into PaaS ones or is that the other way around? And the bigger question is about ITIL. Can cloud do without ITIL or is ITIL archived away in some silo?

These 'management' questions had also troubled us early on and we at Infosys have been very focused on successfully solving these issues for our customers as a Cloud Ecosystem Integrator. In today's uncertain economy with pressure on spends at all levels, enterprises are looking to learn quickly from relative experiences to adopt the cloud journey rapidly.

Join us at next week's premier annual conference for IT Service Management - itSMF UK Conference & Exhibition. Our speaker Prashanth Prabhakara will be talking about key ITSM design principles for the cloud with examples. He will be sharing valuable insights and learning's from his own 'cloud journey'! Visit the event page for more details on the session.

Posted by Ramshankar Ramdattan at 12:51 AM | Permalink | Comments (0) | TrackBacks (0)

It was an awesome day today. To follow up on my previous post about our participation at the annual itSMF Arizona Local Interest Group summit, this was indeed the day for sharing best practices - a packed, day-long event filled with industry veterans and luminaries. 

Continue reading "Infosys' day out at the annual itSMF AZ LIG summit" »

Posted by Ramshankar Ramdattan at 7:19 AM | Permalink | Comments (0) | TrackBacks (0)

Every now and then, one comes across the term 'Best Practices' especially within the IT Services industry.

This term is used far and wide by teams within the enterprise, IT leaders and service providers. Ever wonder what this truly means? Or to put it in a more structural context--

·         What is the meaning of 'Best'- i.e. 'Best' as compared to what?

·         What is 'Good' and is 'Excellent' better than best?

·         Does 'Best' result in value for the business always or only sometimes?

·         What is it's shelf life? When does 'Best' become obsolete?

·         How many people does it take to recognize a 'best practice' and do they need to be in particular roles?

Continue reading "The truth about Best Practices and everything in between" »

Posted by Ramshankar Ramdattan at 1:35 PM | Permalink | Comments (0) | TrackBacks (0)

"Trust"

The word that defines the essence of business.

 

Some of you may be aware that even today it is a general practice of diamond merchants in Antwerp to close millions worth deals / trading of diamonds just by a handshake and Verbiage without any written documents/ agreements. Still millions of traditional business runs over both parties completing agreements over phone calls.

 

In the world of business, trust had and will plays the essential part and in a typical business relationship either parties has a level of trust built upon on face to face interactions, meetings, word of mouth etc. But with the internet exploding and the ecommerce becoming a major driver in the last 3 decades and the regular set of business activities moved to cyber domain, there was an ever increasing need to have business run over internet. End to End lifecycle of a Products or services are now transacted over internet. B2B and B2C type of business including Marketing, Sales, and Finance etc are handled through Internet.

 

Building and maintaining considering Security aspects and particularly Trust over Internet is always a challenge. How can an organization conduct business with someone or some organization over cyber world where it is possible that the data's confidentiality, integrity, authenticity and non-repudiation of either could not be guaranteed?

 

This is where the Public Key Infrastructure came into play and we have a trusted 3^rd party would secure the above security essentials of the information / business transactions carried over an Internet.

 

In series of blog, I would be covering on the Basics of PKI, Components of PKI and then the Design, Implementation / Deployment and Technology Guidelines / Considerations for PKI.

 

In this 1^st blog let me try to bring about the Basics of PKI and its different Components.

 

Basics of PKI:

Simply put, Public Key Infrastructure or PKI is not just a technology consisting of Software and supporting hardwares but is a framework covering people, process, policies and services to ensure Confidentiality, Integrity, Authenticity and Non-repudiation of electronic transactions using Public Key Cryptographic technology.

 

Before we move further it would be apt to understand how Public Key cryptography works and the basis of the PKI.

 

Public Key Cryptography -

 

Cryptography is technique uses keys for encrypting or decrypting data. Cryptography is being used for many thousands of years and in principal uses a single or private key to encrypt or decrypt the data. The challenge in this private key technique is the distribution of keys. The Keys essentially need to be sent to the receiver before or separately and is always prone to compromises.

 

This challenge of key management was addressed in 1976 with the introduction of Public Key cryptography by Diffie & Hellman. This technique involves use of a Key pair - Public and Private Key which are mathematically related but very much impossible to compute. The Private Key is held secret by the User and the Public Key is published and available to anyone who needs to communicate with the user. For e.g., if User A want to send a confidential data to User B, he uses the private key of User B which is publicly available. This message can only be decrypted by User B as he is the one who possess the related Private Key. Similarly Integrity and Non-repudiation can be addressed by using the key pair accordingly. This is a breakthrough technique which enabled secure communications over public network which was not feasible earlier.

 

The Service of securing communication over public network using Public Key Cryptography is the basic of PKI

 

PKI Components:

Generally speaking PKI contains Policies for Key and certificate management, Operational procedures, Supporting Software & Hardware for Key and certificate generation, distribution, management and storage etc.

 

Following are the Components of PKI -

 

Certification Authority (CA): Trusted 3^rd party for Management and Issuance of certificates

 

Registration Authority (RA): Help Certification Authority with the management and signing of the certificates, registration process

 

Certificates: A digital certificate issued by the CA or RA essentially validates the identity of the User for electronic transactions. It contains Serial no, Name and Signature of the CA, Name and Public Key of the Owner/User, Expiry date of the certificate etc.

 

Repository / Stores: Storage for Certificates and Public Keys including Distribution mechanism.

 

In my next blog, I will cover the Design, Implementation and Technology considerations for PKI

Posted by Aravind Ravi Kumar S at 4:42 PM | Permalink | Comments (0) | TrackBacks (0)

Are you actively in pursuit to increase value, optimize costs and induce innovation into your IT services BUT instead...

• all your energy and resources seem to be consumed by the very tool that was supposed to contribute towards achieving those benefits.
• are plagued with reduced tool performance, complex and elaborate processes leading to poor user buy in and satisfaction.
• feel trapped and helpless about the fact that patching up the tool will involve high costs, endless months and things seem to be in a stalemate.
• fear making wrong decisions on getting the right tool to avoid sinking further.
• are busy looking at options for replace the processes & tool but the thought of transitioning makes your stomach cringe.
• there seems to be no way to scale up... and any tiny upgrade seems like an endless battle with no benefits to share.
• moral is down and the blame game for the poor process & tool implementation is just warming up.

Well, if any of the above symptoms are showing then it is surely a sign of something I call SaS, 'Service anxiety Syndrome'.

Firstly, you are not alone! This is prevalent in most of the IT organizations of the corporate world today. Strangely even some of the hottest (or the coolest depending on how you look at them) technology companies suffer from it. This syndrome does not discriminate on the size, capacity, location, domain, experience or resources of the company. It's also one of those where prolonged avoidance actually causes further collateral damage causing the service maturity of the entire organization to rapidly deteriorate. To make matters worse, we are all nurturing IT in isolation and each organization seems to have their own prescription to battle and survive this. With all the lessons learnt and knowledge being kept within closed doors it's a huge loss with zero collective healing.

Well the first good news is that IT is moving higher! A little background first... IT units were always 'told' or directed by the business. It was only after years of being in the basement that IT was finally placed somewhere higher when it let loose its pack of Business Analysts. Although a lot of 'requirements' were being gathered very less of 'analysis' was really being done. At best it was just listen, document & build (to make matters worse... troves of wisdom was getting lost as the requirements were sometimes just a single point of view). No one's really to blame... the engineering was so heavy that it left very little time and resources for anything else. To add further pain, engineering (or rather the tooling) was everything. Even business seemed to be excited to brush up and spill a few technical jargons within rounds of being confused, lost and nervous at the same time.

So where do we go from here? Well, SaaS changes this... IT is no more about just the tool but more of utility. In simple terms quite a lot of the engineering and maintenance is already done and managed somewhere else and only the services (benefits) are available to pick and choose from. This is a welcoming change as IT can now focus on the 'value essentials' (i.e. analysis, processes, design, innovation, strategy, user experience, integration, reports, dashboards and other features). This is enabling the gap between what the business expects and what IT tries to provide to reduce. This is a striking difference as IT organizations will now create and own 'process' rather than just hone 'tools'.

 

The fact that the process is the focus changes the pattern of dialogue. IT teams will now be expected to participate and engage with richer thought contributions to business. The role will be more of an advisory. The shared knowledge contributions will be beneficial to building process ownerships and this will be what the organizations will find competitive advantage in. A successful process design will need to be tool agnostic. Conversely, a great SaaS offering will need to be process absorbing (following some best practices and being domain aligned). The best SaaS tools will be able to manage multiple permutations as needed with pure configuration. IT will need to understand and learn to operate faster, leaner and higher up the value chain with focus on business value by helping with fitment at the macro as well as the micro level.

Unfortunately, there is no single magic (or pill) to overcome the 'Service anxiety Syndrome' as this is no 'common cold'. Yes, SaaS alone does not cure SaS.  It is also not just about jumping into SaaS by signing-up or bringing in some consulting/technical expertise to fix things up. It's a lot lot more and rather combined. As in the case of all anxiety cures the healing has to first start from within and with eating well. In the case of 'Service anxiety Syndrome' it starts with having an appetite for change!

Posted by Vicrant Kumar Pradhan at 6:09 AM | Permalink | Comments (1) | TrackBacks (0)

In my last blog I mentioned about agile model and its unique features. I also talked about that agile allows for direct customer inclusion, adjustment and even redirection utilizing a type of iterative/incremental approach that deals with the level of uncertainty encountered. Here I would like to elaborate further on critical success factors and challenges.  I will focus on some seemingly obvious but mostly ignored concepts. Link to my previous blog Service Matters! ITSM & IT Management: ITSM Implementation best practices part - 2 "Rapid ITSM deployment using an "AGILE" Approach"

 

ITSM tool deployment is not just a technical concern, many other factors such as organizational, management, people, cost, time etc. can lead the project to success or failure. Here below I tried collating some of the key success factors for agile deployment:

 

Critical Success Factors:

-      Customer Collaboration, requirements can never be fully collected at the beginning of the development cycle therefore continuous customer or stakeholder involvement is very important

 

-      Simplicity, approach baby steps & address one thing at a time, build multiple smaller increments of less complexity. When it comes to making changes, it is often easier to bring people along when they only have to support small changes at one time, remember "Implementing ITIL is really changing behavior and changing people"

 

-      Communication & Coordination continues to be one of the major significant factors. Agile methods promote a team working together from beginning to end, communicating face-to-face (including formal daily meetings) than separate teams communicating through formal requirement documents

 

-      Integrate and test each increment with the end to end project, on addition of a new functionality, new test cases must be added to the regression test suite. Testing team must test and report on incremental builds

 

-      Organizational acceptance of team decisions, top management support in agreement of team decisions

 

-      Continuously measure project progress, metrics like "Schedule Variance" , "Scope Variance, "Planned Requirements vs. Delivered Requirements" etc are recommended to ensure adherence

 

 

Challenges:

Let's flip the coin and see other part of the story as wellJ, just like any other methodology agile does pose certain challenges. Here below are some:

 

-      Progress on tool development status is hard to judge due to level & short timelines of increments.  For a yearlong end to end ITSM tool deployment project there may be as high as 100 increments with duration of each may varies between 1-4 weeks

 

-     Quality of each increment may not be at highest level, remember focus of Agile is on accelerated delivery and inclusion of continuously changing business requirements. Hence some compromise has to be made between shorter cycle time and quality of product. For e.g. Nonfunctional requirement may not be perfect initially however we can certainly improve with time

 

-      Contractual Issues unlike conventional approaches no single copy of contract is possible in Agile (due to continuously change in requirements)

 

-     Difficult to provide right priority to the changes especially where interest of multiple stakeholders are involved

 

-     Minimal focus on documentation makes difficult to judge what has been done till date  

       and what is the amount of work remaining to be done

 

-     Validation issues no formal method of validation can be applied due to continuous change in specifications, informal user feedback is the only possible way to validate

 

 

Summary:

ITIL version 3 books provide standard set of best practices that needs to be adapted to the organizational requirements. This same reasoning applies to the ITSM tools, all industry leading ITSM toolsets require significant levels of customization for an effective process-led tool implementation. This development cycle needs serious investment on time and money along with the bandwidth of subject-matter experts. In this respect, agile practices of frequent iterations, increments, and focused teams inclusive of users, specialists and customer can surely provide greater value, which further ensures ITIL and Agile as complimentary partners despite of their uncommon characterization of "Agile" being flexible and "ITIL" being composed and directive

Posted by Ashwani Aggarwal at 10:35 PM | Permalink | Comments (0) | TrackBacks (0)