Service Matters! ITSM & IT Management

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.

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)

Imagine managing IT Services in an organization where there is no limit on spending!! Imagine you have all the liberty to spend on whatever it takes to create a frictionless, fast-paced and easy-to-access Services environment. What would you do to make the make the end-user experience awesome? Specifically, what would the Service Strategy & Processes contour look like?

This is an interesting problem to solve, for several reasons. Service strategy, like any discipline of management, grapples mainly with the problem of optimization in a resource-constrained environment. But the scenario in question deals with relaxed budgetary constraints, which is uncommon. And secondly, it would be an interesting exercise to hypothesize what the upper limit for potential of IT would look like within an organization.

In this first part of the 'Service Management Unlimited' series, I am attempting to set the platform for conceptualizing Service Strategy & Processes in a resource-rich IT environment. Based on my project experience with a social networking giant in US, following are attributes of the said environment.

IT Infrastructure:

Not surprisingly, the IT infrastructure here is state-of-the-art. A majority of their enterprise systems are run on cloud services. There is a conscious effort to push as many IT business applications on to cloud as feasible.

On the user end, mobile devices, desktop equipment, computer & mobile accessories, and software applications - the entire infrastructure is technologically sophisticated, on par with the latest in industry. Asset management philosophy revolves around greater mobility and high availability of resources for users. There are supply depots for IT hardware accessories located within easy reach of all users, where the users can just pull things off cabinet and use! The whole approach towards distribution and maintenance of user assets is relaxed and free of regulations. This is precisely why user asset portfolio management is tricky and challenging. Innovative ways of managing and reporting user assets are needed to maintain visibility on spending.

Food for thought - given all this, how should the process & tool solution for Asset Management look like? Will the relaxed approach towards asset distribution work if the organization scales up steeply? What are the responsibilities of end users in such an environment? [Stayed tuned for part II for answersJ]

ITSM Processes:

One of the many facets of defining a robust Service Strategy is compliance to industry standards in ITSM domain (mainly ITIL). But an ITIL purist would wince at state of processes here. I found that the processes being followed are far less rigorous in nature than I had seen in organizations of similar scale. Sometimes, they are haphazard and inconsistent, or even absent. As mentioned before, there is strong emphasis on frictionless interfacing between IT and business and end users. So defining processes in this situation is far from straightforward. One has to always maintain a fine balance between a process being robust and a process becoming an unnecessary hindrance to the users.

So questions galore - in a fast paced environment with little regard for protocols, how relevant are ITIL processes? How do we determine the ideal balance between process rigor versus process overhead?

Business Applications:

One of the central functions of IT within an organization is building and maintaining tools to automate business processes. Given a resource-rich environment, how would one approach internal software application development? If you could attract the very best of developers and breed a rich application development environment within the organization, would you still go for out of the box tool suites which may or may not suit your business needs?

IT is a function which essentially thrives on discipline and processes. Honing a highly flexible and functional IT environment requires a novel approach. I will attempt explore some of these approaches and answers to questions raised in this post in the next part of the blog post series.

Posted by Vijay Bhargava at 11:54 PM | Permalink | Comments (2) | TrackBacks (0)

In my last blog I mentioned about the importance of Data Governance and its evolution. I also tried to focus on the reasons behind the need and the opportunities that lie ahead.  In this blog I would like to elaborate further on the challenges/needs mentioned and also try to outline ways to prevent/resolve them. I will focus on some seemingly obvious but mostly ignored concepts. Link to my previous blog Data Governance for SaaS (Part 1 of 2)

1. Firstly, the most obvious one... Involve all stakeholders and have expectations and solutions balanced and agreed upon at all times.

In IT Asset Management certain asset types carry confidential information (mobile sim PIN, User password, delegation rights control etc.). Managing security breach due to access of vital data via different screens or unforeseen entry points (i.e. via the reporting module or direct target url entry) is always a challenge.

To avoid this there can be data exchange agreements between the data provider and consumption teams. So by virtue of such agreements across the enterprise there can be a defined understanding for handling critical information across the various system records, archives etc. As the impact of these are fairly systemic its build should include expert advice & consent from Enterprise Architects, Information Security, Access & Risk Managers.

2. Follow the middle path... One should not relying on technology or tool alone to solve all their data problems.

Managing sensitive data (i.e. financial, health, legal data) in Incident, Problem, Change, Release, Service Catalog Management etc. often defy security rules. There are times when the business may need urgent solutions and ignorantly attach/share restricted information. This is unavoidable but nevertheless it is possible to have alerts based on the nature of the data that is being shared (A form of context driven help and support).

Sometimes, simple features and a little more thought goes a long way towards preventing inappropriate data sharing and mishandling. Process design, usability and training along with technology should be managed as a single piece to help achieve effective outcomes during implementation. Don't just focus on one aspect too much but rather focus on the whole (Ashwani's blog has some well compiled best practices around this).

3. Innovate... Have an integration framework in place and continuously weigh out options, consolidate and evolve.

Building interfaces, channeling data/triggers for Deployment provisioning, Product Catalog etc. and compliance could be the biggest security juggernaut. Having reliable interfaces to data sources and to be able to equally disperse information is priority for SaaS systems.

In one of our implementations we managed this via 'web services' as it was a strong capability of the platform we chose (Please refer to my earlier blog 'ITSM - Choice Matters'). With the right data structure we were able to have it exchange real-time updates across different tools (i.e. Scheduled jobs via inbound email rules is also effective but not preferred in all cases). The needs can be different but having a consolidate way of managing this maintains predictability and is more reliable & scalable option.

4. Think!... Getting a little more out of the tool by means of customization is tempting but it is important to first challenge the need and thoroughly evaluate the solution.

There will always be a need for new processes and modules (i.e. items which do not form a standard module in some tools). Most SaaS tools generally come with powerful admin configuration features. These are sometimes extendable to create one's own modules which can be integrated to leverage the combined benefits with existing modules (i.e. To avoid email overload to end users the need to build a subscription based project/release communication management module).

It's important to map and keep an alignment on the requirements, processes workflows and overall data architecture of the tool. Of course there is always a fine line between plain configuration and the need to customize (Please refer to Satsang's brilliant blog where he weighs out the options). Customizations are usually an overhead and this should be seriously weighed against priority and needs with the feedback from technical architecture and the vendor.
 
5. Celebrate... Dashboards are infact the most alive part of the system where the benefits of Data Governance become apparent. Groom and cherish it!

Graphical plans and charts (for incident, problem change reports, rollout plans, conflict detection, release schedules etc.) are no more nice-to-have's but rather a must. Data governance is not just about data security but also about combining data to create meaningful information for tracking, reporting, continuous improvement & business value. Reports were usually assumed to be basic and at best just data dumping capabilities.

Powerful visualization and report generation features are a valuable assets of SaaS tools today and some have taken a leap in redefining this. The concept of dashboards is a powerful one and this should be factored in early during requirements so that data structures can be defined with useful outcomes in mind.

Organizations aspire to comply with the ITIL v3 processes and implement an ITSM tool with holistic deployment of these processes. However, the important piece we need to look is the type of data that flows among the various ITSM processes and how quickly we can capture the specific data elements to achieve the optimum results during tools and processes implementation.

Due to numerous data flows it takes enormous amount of time to identify all the data elements, their integration points and relationships which results in the following impacts:

·         Prolonged duration for ITSM tool implementation

·         Less visibility for IT alignment with Business

·         Ineffective rules for Data validation for various processes

·         Identification of internal and external data relationships

Driven by the customer needs, Infosys has built an 'Integrated ITSM Data Architecture Model' that is strongly positioned to enable faster ITSM tools implementations.

The 'Integrated ITSM Data Architecture Model' is a structured and holistic view to demonstrate the data elements and relationships that need to be built for successful deployment of IT Service Management processes into the respective tools and platforms. It can be used as a guiding reference to manage and govern these entity relationships during the overall ITSM tools development lifecycle. This model has an effective future proofing mechanism which will enable an organization to assess their data requirements based on their existing service management processes.

This Data Model was being created by preparing individual data model for key ITSM processes: Incident, Problem, Change, Release, Service Asset and Configuration, Service Level and Access Management, integrating them all to arrive at the comprehensive Data Model. Each process is identified as an entity and respective attributes are listed in entity column to form a reference point for all other associated entities. The explicit data elements are available as related within the entity relationships among various ITSM processes.

Integrated ITSM Data Architecture Model enables the Application Architects and Process Analysts to analyze the organizational needs in terms of process relationships and the respective data elements that are required and managed throughout the information management lifecycle. The Data architecture model also accelerates the requirements elicitation process and enables faster alignment for the overall requirements. This truly reduces the overall systems requirements analysis time by 15% - 20% and also builds the foundation towards better Data Governance.

Posted by Nitin Awasthi at 6:27 AM | Permalink | Comments (0) | TrackBacks (0)

In continuation to my previous blog on "ITSM Implementation Best Practices Part-1", where in I talked about collaboration, integration & orchestration of Business / IT elements, here I would like to touch upon another interesting topic on "Agile based ITIL implementation". ITIL implementation approach is a critical decision that the IT leadership has to take well in advance.

The conventional ITIL implementation approach considers the implementation through the assessment, requirement gathering, design, testing and deployment phases for ITSM processes and tool. This is usually guided by the standard "waterfall" approach and is more focused on defined activities, metrics and feedbacks in a sequence. This is a legacy approach that is proven and has its own set of benefits and challenges. This is well suited for organizations that have appetite for large organizational changes and have done it before.

Another widely spoken approach is "Agile Methodology".  Agile approach is "Iterative", "Incremental" and uses its own set of practices and terminologies for working with people, processes and tools. As the 'Iterative' & 'Incremental' words may signify, this approach largely depends on shorter cycle times, where in to meet the user specific needs every iteration may deal with logically combining the requirements for ITSM processes & tools implementation.

Unlike the conservative approach of presenting capability to the end users only after its development, here users are involved right from the design stage. Agile advocates development of sample prototypes in the design stages itself so a user may review the "To-be Final Product" and provide his/her feedback for any course correction.

The subject matter expertise from the core user group serves as the basis of capturing the organizational requirements on capabilities/features etc., which further helps in producing the capability that matches the customer requirements and hence very little or no rework required in the final deliverable. Time savings, customer satisfaction and the speedy ITSM process delivery are the major outcome of the approach. 

The Agile methodology is proven in terms of delivering end to end project in minimum possible time and ensuring the final product fulfills the customer needs and requirements. Some of the important features of the proposed ITSM implementation methodology are provided below:              

ü  Based on "empirical process control" i.e. it uses the real-world project progress to plan and schedule ITSM process and tools releases.

ü  Projects are divided into succinct work cadences, known as increments, which are typically few weeks in duration.

ü  At the end of each increment, stakeholders meet to assess the progress of a project and plan the next steps. This allows continuous alignment in project direction and leaves little room for speculation or predictions.

ü  Emphasis on an ongoing assessment of completed work through closed-loop activities

ü  Defined set of roles, responsibilities, and meetings

ü  Stability of practices, give teams something to lean on when ITSM platform development gets chaotic.

The real misconception in the ITSM Implementation is that process/product development takes time - it's not. What really takes time is the cultural change resistance, which in reality has nothing to do with ITSM. By using agile methodology principles we can handle cultural changes efficiently (by partnering with the end users in every stage of the product/process design and development) and can definitely make faster and effective progress, at the same time be ensured that the end product would meet the end customer requirements as envisioned......

Posted by Ashwani Aggarwal at 4:15 AM | Permalink | Comments (0) | TrackBacks (0)