• 37 ans
  • Conseil en organisation des Services IT
  • IT Service Manager | ITIL Expert
  • ITIL, Cobit & CMMI certifié
  • processus IT | Excellence Opérationnelle
  • Auditeur AFNOR Référencé


Situation professionnelle

En poste


IT Service Manager / Qualité Méthodes et Processus IT

10 ans d'expérience professionnel dans le domaine des systèmes d'information.
- Service manager Qualité Méthodes et Processus IT
- Gestionnaire d'application métier


- Identifier, planifier, lancer, suivre, analyser et présenter les actions afin d'optimiser les couts, les risques et les ressources

- Implémentation, surveillance et optimisation des processus d'exploitation liés à la livraison de nos services IT conformément au QCD

- Construction et du suivi du référentiel documentaire en accord avec les exigences opérationnels, d'audits
et de contrôles (basé sur les référentiels ITIL, Cobit)

- Conduite d'audit:
-- de service
-- de projet
-- de processus

- Conduite de l'amélioration de la performance par l'amélioration du SMS (Système de Management des Services)

- Conduite de projet d'amélioration selon Lean Six Sigma

ITSM Professor

A positive place to share ITSM, DevOps and Agile knowledge and insight.

DevOps Test Engineer Question…What is the difference between Static Testing and Dynamic Testing for Continuous Deployment?
18 juil. 2017
Every organization that delivers products or services will need to shift their ideas for how they plan, build, test and deploy a service that is resilient and for one that truly delivers value for both customers and the internal business.  Continuous Integration, Continuous Delivery and Continuous deployment are all supported by Continuous testing.    Continuous anything will not be assured of success without Continuous Testing.   Continuous testing is the process of executing automated tests as part of the software delivery pipeline to obtain immediate feedback on the business risks associated with a software release candidate. Shifting left ensures that the test takes place early, up front in the pipeline of delivery, NOT after the development.  Testing after development is too late because then we do not have the time, money or resources available to re-engineer, re-design or to re-develop appropriately.   When we test after the development of an application the best we can do with negative test results is try to put in band-aid fixes.  This frequently results in technical debt that sometimes never gets paid down.  Security and other non-functional requirements cannot be applied properly afterthe test.  In comes this idea of “Static Testing” vs. “Dynamic Testing”.  

Static Testing would test all elements having to do with the service that are not software related.  Static testing gives us the opportunity to give some assurance and warranty for security, availability requirements, and also for current and forecasted patterns of business activity and demand for this new or changed service.   This type of assurance does not mandate that you have a DevOps initiative nor does it infer that automation or new tooling must be in place.  Additional tools and automation might evolve later but the key is that static testing is everything that does not require a user interface and should be performed for all things before the development of the application.

Static Testing is different from Dynamic Testing.   Dynamic testing would test all things functional.  Dynamic testing in contrast to Static Testing includes testing the software and also includes things like your user acceptance testing.   When shifting left to ensure that the service is fit for purpose and fit for use be sure to consider when, how and where you will perform integrated Static and Dynamic tests.

I found this answer to this question in a recent webinar titled “ DevOps Test Engineer” delivered by Anne Hungate.

The recording and slides from this webinar and other resources are available here!

Voir l'article
Business–Provider Alignment Model
11 juil. 2017
The purpose of the (IT) Service Provider is to serve the needs of the business.  This is carried out by providing services to the business which are then engaged to provide some form of value to both the business and the Service Provider. Often the value delivered is less than optimal because the Service Provider and the business have different perspectives, culture goals, objectives and incentives.

The Business-Provider Alignment Model (BPAM) provides a framework for being able to analyze and understand these differences between the provider and its business partners. By engaging the BPAM we can begin to surface dialog about the relationship between the provider and the business and begin constructive discussions about the partnership that needs to be created. It does this by allowing each party to exam the four key elements of alignment – business environment within which the business operates, strategic context for the business, provider strategy and the provider portfolio of investments, assets and capabilities.  It also identifies the barriers that typically exist between these elements inhibiting alignment or convergence. These barriers are identified as the Expression Barrier, Specification Barrier, Contextual Barrier and the Implementation Barrier.

Let’s first examine the four elements to alignment:

Environment – these are the boundaries within which the business operates. It helps to define opportunities, threats and constraints.  These factors can have an impact on the Strategic Context and the IT Provider Portfolio.

Strategic Context – relates to the businesses products, markets, investments and customers.  Also with in the strategic context are the elements of strategic intent, core competency, business governance and the current strategy.  The Strategic Context will drive the overall IT Strategy.

IT Strategy – The components of the IT Strategy are roles of IT, deliver IT services and architecture.  These articulate how the provider will enable the business partners to achieve their goals and objectives. The IT Strategy and the IT Portfolio must align.

IT Portfolio – This describes the total investment in IT.  Within the portfolio we have four types of investments.  Informational which provide better information for the business, strategic which help the business to gain a strategic advantage in the market space, transactional which helps to reduce the cost of doing business and finally infrastructure which helps to provide a base capability.

 Let’s now examine the four barriers to alignment:

Contextual Barrier – What drives our behaviors?  Culture can be deeply ingrained in an organization especially one that has been around for any length of time and can include such factors as the culture of accountability, clarity of roles, rules of engagement, the degree to which an organization is relationship driven versus rules and roles drivenand the organizations over all resilience and resistance to change.

Expression Barrier - Strategic Context can be hard to define in any specific terms. There can be a lack of clarity because of this ambiguity. There is usually some form of articulated business strategy, but sometimes it is vague and unclear as to what is actually meant by the strategy. Often there is this disconnect between articulated strategy (Strategic Intent) and the actual strategy in action. Talking to the most senior executives will often give you a reasonable sense of Strategic Intent, but talking to line business managers reflects something quite different—often driven by performance management systems and prior strategies that have supposedly been replaced.

Specification Barrier - This relates to the difficulty of determining just what the Business Partner wants the IT Service Provider to do.  The business Strategic Context can be ambiguous due to the Expression Barrier that surrounds it.  The Provider strategy can be equally unclear due to the Specification Barrier that surrounds it, too. Getting clear on the Role of the Provider in the enterprise can be challenging.  Is it an enabler or a strategic driver?  Should it respond to the business strategy or inform it? Reaching consensus on this across key stakeholders can be very difficult. Once the Provider role is clarified, figuring out what Provider capabilities are needed, and how they should be best sourced can be extremely challenging. Finally, governing the Provider as a strategic business capability is a constant challenge for most organizations. Getting business executives to understand and agree to the necessary priorities for IT investments demanded by the business strategy is complex and difficult. They would much rather let the Provider organization figure out how to meet that demand. The Business Relationship Manager (BRM) plays a key role in overcoming the Specification barrier.

Implementation Barrier – This refers to the things that prevent the development of an IT Portfolio that support the Business Strategy. There are many things that work together to form a barrier to implementing a portfolio that properly enables the business Strategic Context and aligns with the Provider strategy.  A poorly integrated Provider infrastructure in part due to both the Expression and Specification barriers where years of unrelated acquisitions of technology and infrastructure drove up the cost of that infrastructure, restricted its flexibility, and then starved investments from Utility transaction processing, IT capabilities that Enhance business capability and new leading edge capabilities that could drive growth and business innovation.

By engaging the Business/Provider model, these elements of alignment and barriers to preventing alignment become more visible and easier to identify and overcome.

Voir l'article
What is a Botnet - Why do I care?
27 juin 2017
Today every business is an internet business.  The performance of any business is directly related to the capability and performance of IT.  Therefore, we must all take cyber security seriously.  

Let’s start with a botnet by breaking down the word itself.  The first syllable, “bot” is short for robot. The second syllable “net” is from the word network.  A botnet is formed when a hacker writes a computer program that will breach security on a single computer.  It does not stop there.  This computer program called a virus has the capability to take over that computer that it just hacked into. It does not stop there either because this is not good enough for the cybercriminal.  With a botnet, the virus will move from one computer to another, take control of each and then connect all of the disparate computers into a powerful system or network of control.  This is known as a botnet.

Cyber criminals are control freaks.  They will sometimes create a virus that controls thousands or even millions of computers.  The more computers that the criminal gets control over the bigger their botnet becomes and the more power they have to do harm.  There has been a bit of glory given in the past and even today for a hacker that has this capability to do harm on a mega scale.  Today they can even change the course of the entire world.   The hacker keeps going and revels in the number of controlled computers that they can get into their botnet.  When the botnet gets very large it is referred to as a zombie network and is sometimes sold to other cyber criminals so that they can grow their own botnet or zombie.

Every business, every home and every internet device is vulnerable.  The internet of things has fueled flames for botnets and zombies and is yet one more avenue for the cybercriminal to get control over devices, access proprietary/personal information, to sell the information, propagate SPAM and more.

Installing security protection on your computer and business systems is crucial but many do not consider their phones, their XBOX, or other internet enabled devices such as thermostats, cars, lights, refrigerators and other appliances. All can be connected through the “Internet of Things” and all can be broken into to become a part of or an avenue to expand a botnet.

Education and Awareness

The public is not aware. Last year a cyber-attack occurred that would randomly call people and ask questions like “Can you hear me ok?”. When the person answers “YES”, then the program records your voice and uses it to confirm the opening of a new credit card or another potentially dangerous ploy.  The public should become aware of the risk and how to avoid cyber-attacks with security monitoring apps, and to keep apprised of what is critical information and not give away key information unintendedly.

Business and government agencies will need to be willing to change their culture. They will need to integrate teams of specialists, build resilient/rugged software and more.  Every business and their employees should be cyber experts. More than that, they will have to CHANGE the way that they think about requirements, development and deployment of products and services. They will need to consider skillsets for new roles such as the DevOps Test Engineer (DTE) and more.   Educate yourself and inspire others. It is a new world! 

For training and certification regarding-à  DTE, DevOps and Agile…

Voir l'article
Business-Provider Maturity Model
20 juin 2017
In today’s business climate it is imperative that the IT Service Provider not only understand what the business strategy is, but be able to initiate and deliver services that not only support it, but help to shape it.  This can be successfully accomplished by ensuring that the service portfolio remain aligned to the business needs.  Over time these requirements and demand for services change and mature.  The Business / Provider Relationship is integral in keeping the demand and supply of these services and capabilities appropriately and continuously aligned.  One of the tools engaged for this task is the “Business-Provider Maturity Model”.

The Business-Provider Maturity Model is a way to help surface and understand the growth in maturity of business demand for Provider services and capabilities, and a Provider organization’s maturity of supply capabilities needed to both satisfy and shape that demand. Many maturity assessments are very IT centric assessing the ability of the Service Provider to satisfy demand from the business. The key difference here is that we also need to understand the businesses ability in being able to exploit the IT Service Providers capabilities to enhance the business strategy. It is a means of driving dialog about business demand and Provider maturity and how these elements continue to mature and grow. The model can be used for the entire enterprise or for a particular business unit or Provider capability.

In its simplest form, the model is an S-shaped learning curve—the business learning to exploit technology and the Provider organization learning to become efficient and effective in delivering services and, especially as maturity increases, shaping business demand.  Business executives find the model’s simplicity appealing. They can easily interpret the concepts behind business demand maturity and are able to use the model to analyze how their demand maturity is evolving over time. This enables them to engage in meaningful dialogue with Provider leadership about the business implications of both demand and supply maturity.  In most cases a basic three level model is utilized, however the number of levels is arbitrary. In some cases a 5-level model can be engaged, which can be useful because it represents a finer-grained approach.

To the left of the S-curve are the characteristics of business demand at each of 3 the levels. To the right are the corresponding goals of Provider supply.  It is important to understand this is a developmental model.  That means it is cumulative.  The demand at lower levels never goes away, the business always wants the lights kept on.  A Service Provider that fails to supply against this demand will lack credibility and the capability to move up the maturity curve.  As business demand matures to Level 2, Level 1 demand does not go away, it becomes a fundamental expectation.

Level 1 business demand is typically generated from functional and geographic silos which means it is often fragmented. This can be frustrating for the Service Provider, who are able to look across the enterprise and see many opportunities for cross functional processes and collaboration, but are often unable to communicate these concepts.

Level 1 demand is to provide basic services and solutions while ensuring stabilized operations and support, with an overarching goal of reducing the costs of doing business.

Level 2 demand, which continues to include Level 1 demand, focuses on enabling business partnerships, enterprise integration and consolidation of management information. Level 2 supply is focused on establishing common infrastructure and management information enterprise solutions. Level 2 supply also focuses on building credibility, improved service/ solution delivery, with attention to portfolio management, service management and getting faster at delivering solutions.

Level 3 demand, which now includes Level 1, 2 and 3 demand, addresses strategic and technology capabilities, which enable the convergence of business and IT capabilities which in turn enable business growth and innovation. It tends to be much more externally focused than Level 1 and 2, interested in business intelligence, rapid experimentation and collaboration with other business units, customers and suppliers.

Voir l'article
Nine Guiding Principles for ITSM or… for Everyday Life
13 juin 2017
ITIL Practitioner focuses on nine guiding service management principles that distil the core message to facilitate improvement and success at all levels.   The principles not only guide providers who want to adopt a good approach for successful products and services but can also be applied to ensure our day to day success.  Yes, that’s right!  These principles could be applied to buying a car, ordering food and more.    

Example:  I want to purchase a car.

Guiding Principles

1) Focus on VALUE-  I need a car but I don’t want to exceed my budget for this.  Value for me means awesome performance and that this car looks amazing. It must be a good fit and be cost effective. Good luck, right?   Value is determined by price but also by performance and perception.

2) Design for Experience –  Here I would be looking for something that is durable, has lots of techno gadgets built into the dash and if it is luxurious  when I get into it… even better.   If it just looks good but is not functional than it is not fit for the experience.   The provider of this vehicle will have to know their audience and who their customer base is. They will have to know the customer needs for such a car and ensure that they are able to meet them viewing the customer experience holistically. Value can only be determined by the consumer, NOT by the designer or the sales rep.

3) Start Where You Are. – Leverage what is already available.  ITIL sayslLook objectively at the current state. Of course I will have to look at any risk involved too. The Engine, carburetor, and overall functionality is a must but I should also have the color and model that deliver value to me.

4)  Work Holistically – All elements must work harmoniously together to deliver results. As with any service the outcome must be fit for purpose and fit for use.  Addressing only one element without looking at the overall product with features could result in a very expensive frustration.  I must focus on the bigger picture rather than just one element.  If I have a great engine but the vehicle is rusted and ugly, that is not an option.  Example:  Let’s say that I have selected a great performing vehicle and then decide that a sun roof is a required element for me.  If the reviews show many consumers are unhappy due to leaks from this then the warranty or assurance of value from that overall vehicle is diminished; even if the engine, carburetor, and all other functional requirements are there.  I not only want the functionality of a good performing car, the beauty and warranty or assurance that it will not cause trouble must also be there to deliver true value.

5)  Progress Iteratively- I have the big picture now and the look I am going for. OK so maybe I won’t be able to get all of the nice to have features or all of the techno gadgets.  Price matters.  I will need to separate my must haves from nice to haves.  Once that is done then I can begin to add elements accordingly to complete this vision.  My minimum viable product is the functionality of the engine, good gas mileage, and performance.

6) Observe Directly – While it is true that some things can only be understood through observing and measuring, direct observation is the first and preferred option.  Although the car that I have now selected looks right I know that I am going to have to take this for a test drive to observe how it feels and runs on the road.  The reviews and historical data (metrics) alone might not give a true picture of what I thought this car really is.  I do not want to make assumptions here.  Try it on for size.

7) Be Transparent – Best practice for service providers state that leaders at various levels should provide appropriate information relating to the quality or the improvement in their communication with others.  Therefore, I am bringing with me my friend the mechanic.  Before I invest I want a qualified recommendation from someone I know will be open and transparent.

8) Collaboration – Although I value the input from others, my preferences and perceptions must be considered so that the end results are a win/win. Another aspect of transparency and collaboration is that accomplishments are communicated and celebrated so I am sure we will have to leave the dealership and celebrate our decision.   This will emphasize the importance and value of my friend and a sense of pride for participating. 

9)  Keep it Simple – As an IT Service provider we know that when analyzing a process, service or improvement, we have to consider “Does it create value?”.  As it relates to purchasing a car, if I get sidetracked and start looking at too many features in lieu of the functionality and performance that really deliver value I will regret this purchase. 

OK, buying a car not your thing?   Take these nine ITIL practitioner principles and apply them to any purchase or day to day service.  They work.  You might want to have fun and ask your staff to do the same.  It is a fun way to embrace these simple yet critical principles for the provisioning of services.

For ITIL Practitioner Training and Certification -  click here

Voir l'article
The Business Relationship Maturity Model
06 juin 2017
The Business Relationship Maturity Model (BRMM) is a way to help surface and understand the maturity of the relationship between a Provider (internal IT organization) and their Business Partner. This is not about the maturity of the BRM role or process.  This is about the maturity of the Provider/Business Partner relationship and therefore must take into account the perspectives of each party. The BRMM is made up of 5 levels, each with a descriptive tag, and represents a relationship maturity continuum. Level 5 is the highest and described as strategic partnering, Level 4 is trusted advisor, Level 3 is service provider, Level 2 is order taker and Level 1 being the lowest or ad hoc.

Level 1 Ad Hoc: From the Business Perspective (BP) it’s, can’t even get my providers attention, results cost too much, delivers too little and takes too long.   From the Provider’s Perspective (PP) it’s: I’m too busy to think about anything other than I’m too busy.   Characteristics of relationship (COR) are: unmanaged demand, unclear rules of engagement and no clear sense of value. To move to the next level the Business must embrace the reality of the existing capabilities and the Provider must establish demand management principles.

Level 2 Order Taker: (BP) I engage my provider when I need something so they stay out of my way when I don’t need them. (PP) We are asked to be predictable but there is no way to forecast demand so we know we disappoint our business partners more often than not.  (COR) Frequent misperceptions build distrust and reactive course changes.  Prioritized demand based upon weak data, we/they relationship (antagonistic) and provider is completely reactive.  To move to the next level Business must embrace the BRM role and Service MGMT.  The provider must establish BRM and Service MGMT excellence.

Level 3 Service Provider: (BP) My provider prevents me from making big mistakes but I’m not always sure which direction we are heading. (PP) Our business partners help set priorities, but we are always behind. (COR): The routine is routine but innovation is a challenge, services are stable but major project deliverables are inconsistent, costs are transparent but value is subjective. To move to the next level the business must engage the provider in strategic thinking.  The provider must pursue Portfolio and Transition MGMT excellence.

Level 4 Trusted Advisor: (BP) My Provider is helpful and reliable. (PP) Our business partners understand our capabilities, works with them and helps to improve them.  (COR) Mutual understanding of capabilities and needs, portfolio is aligned to business needs and sense of value from investments. To move to the next level the business must embrace business value realization.  The provider must embrace continuous improvement.

Level 5 Strategic Partner: (BP) My provider is integral to business success and growth and helps me succeed.  (PP) We work together with our business partners to survive and prosper.  (COR) Shared goals for maximizing value, shared risks and rewards, quality data is being produced, innovation is cultural, complete convergence.

There are several ways to engage this model in helping your organization build a more agile business. It can be used to assess the current maturity level of your business/provider relationship and create and established an agreed baseline.  You can then incorporate this baseline to establish a strategic plan to identify improvement opportunities and create a timeline for maturing your organization through the 5 levels of the model. It provides the information to educate your BRM team and provider leaders on what the current state is and how they can engage to elevate business relationship maturity. It can also help to shape your approach on how the business & the provider can become strategic partners and move the organization forward and thrive.

For more information: http://www.itsmacademy.com/brmp

Voir l'article
Rugged DevOps
30 mai 2017
Rugged DevOps is a method that includes security practices as early in the continuous delivery pipeline as possible to increase cybersecurity, speed and quality of releases beyond what current DevOps practices can yield alone. (1) “Rugged “describes software development organizations which have a culture of rapidly evolving their ability to create available, survivable, defensible, secure and resilient software. (2)

As business increasingly relies on agile software development, the absence of matching fast-moving security methodologies in the delivery pipeline will essentially increase the risk of a security breach or a cyberattack. Security staff must be imbedded into cross functional teams to ensure a more sustainable and less risky continuous deployment value chain (continuous integration, continuous delivery and continuous testing). The bad guys have already acquired these skills and the use of automation to engage in a continuous attack on our defenses.

Security was named as the number one DevOps obstacle by 28 percent of enterprises. (3)  Security needs to be engaged early and often.  If the Dev organization is at a maturity level where daily builds and releases are common, come up with a suite of models that allow you to do some level of testing and can conform to the condensed cycle times. By moving away from a waterfall set of security methodologies and adopting and adapting scrum practices, security can engage earlier and more often in the development lifecycle.  If you are not part of the solution people will go over or around you.  

DevOps is a cultural movement.  Changing the way we think and do things takes time. Culture doesn’t change until the way think changes.  Think about the things that you may have in common with development and operational teams and try to build on those commonalities.  We are more alike than we are different.

As with any DevOps initiative automation is key.  Reliance on manual testing just doesn’t enable the kinds of delivery speeds businesses are looking for today.  It doesn’t mean that some of that manual testing methodology goes away, but it may be used as a back up to the automated testing when necessary.  Security teams should be thinking about ways to automatically integrate manual testing results back into the pipeline. (4)

Security must be engaged at the strategy and design stages of the lifecycle.  Security concerns and perspectives have to be incorporated into requirements before any code or design work is done.  This way we can ensure that available, survivable, defensible, secure, resilient software and architecture get created.

DevOps is all about securityshifting left to find security issues as early in the development life cycle as possible. By integrating security tools into your continuous integration process, security teams can engage their highly effective skills to uncover and eliminate vulnerabilities early in the development cycle. The earlier you find an issue the cheaper and easier it is to fix, creating big wins for both the provider and the business.

(1)    Forrester Research
(2)    Rugged Software.com

(3, 4) Ericka Chickowski

Voir l'article
Big Bang - DevOps
19 mai 2017
I learned about ‘The Diffusion of Innovation Theory’ in a DevOps Foundation training course.  I wanted to get my DevOps certification but more than that to learn about what makes a DevOps initiative successful.   When I mentioned the Diffusion of Innovation Theory to a coworker he said “It sounds like Sheldon talking to Raj on “The Big Bang Theory” TV series.  Although the name sounds Big Bangish the usage of this theory could be the real difference for success in any transformational change including DevOps.

To start let’s begin with the definition of DevOps. DevOps is a professional and cultural movement that that stresses communication, collaboration, integration and automation in order to improve the flow of work between software developers and IT operations professionals. Improved workflows will result in an improved ability to design, develop, deploy and operate software and services faster. That’s where this “Big Bang” or Diffusion of Innovation Theory comes in.   DevOps is a culture shift.

DevOps is a cultural movement that requires us to shatter the silos and to quickly integrate our teams to increase the flow of work from idea to end of life for the strategy, development, deployment and the sustaining of service over their life. Adoption of a new idea, behavior, or product (i.e., ‘innovation’) does not happen simultaneously in a social system. It is a process whereby some people are more apt to adopt the innovation than others.  Researchers have found that people who adopt an innovation early have different characteristics than people who adopt an innovation later.  Learning what those characteristics are and then how to apply the proper technique for each will help with the management of organizational change.

The Diffusion of Innovation is a theory that seeks to explain how, why, and at what rate new ideas and technology spread.  While most of the general population tends to fall in the middle categories, it is still necessary to understand the characteristics of a given target population. When promoting an innovation there are different strategies used to appeal to the different adopter categories.

Innovators – want to be the first to try the innovation. They are venturesome and interested in new ideas. These people are very willing to take risks and are often the first to develop new ideas. Very little, if anything, needs to be done to appeal to this population.

Early Adopters – represent opinion leaders. They enjoy leadership roles and embrace change opportunities. They are already aware of the need to change and so are very comfortable adopting new ideas. Strategies to appeal to this population include how‐to manuals and information sheets on implementation. They do not need information to convince them to change.

Early Majority – rarely leaders, but they do adopt new ideas before the average person. That said, they typically need to see evidence that the innovation works before they are willing to adopt it. Strategies to appeal to this population include success stories and evidence of the innovation's effectiveness.

Late Majority – skeptical of change and will only adopt an innovation after it has been tried by the majority. Strategies to appeal to this population include information on how many other people have tried the innovation and have adopted it successfully.

Laggards ‐ bound by tradition and very conservative. They are very skeptical of change and are the hardest group to bring on board. Strategies to appeal to this population include statistics, fear appeals, and pressure from people in the other adopter groups.

When promoting an innovation to a target population, it is important to understand the characteristics of the target population that will help or hinder adoption of the innovation. The Diffusion of Innovation Theory could be the “Big Bang” that you are looking for to ensure the success of your DevOps initiative.

Voir l'article
Pace-Layered Application Strategy
19 mai 2017
Historically, many companies have had a single strategy for selecting, deploying and managing applications. They have had a defined structure for classifying applications by value or functionality, but failed to recognize that applications are fundamentally different based on how and when they are engaged by individuals and the organization as a whole and the pace at which these tools need to be changed and updated.  Many organizations are finding themselves with an enterprise application strategy that fails to satisfy the needs of the business community, which has often led to underutilized applications throughout their portfolio.

Gartner’s Pace Layered Application Strategy is a methodology for categorizing applications based on how they are used and how fast they change.   This strategy helps IT organizations rationalize the use of DevOps practices that ensure a faster response and a better ROI, without sacrificing integration, integrity or governance requirements. The strategy has defined three application categories, or "layers," to distinguish application types and help organizations develop more appropriate strategies for each:

  • Systems of Record — Established packaged applications or legacy homegrown systems that support core transaction processing and manage the organization's critical master data. The rate of change is low, because the processes are well-established and common to most organizations, and often are subject to regulatory requirements.
  • Systems of Differentiation — Applications that enable unique company processes or industry-specific capabilities. They have a medium life cycle (one to three years), but need to be reconfigured frequently to accommodate changing business practices or customer requirements.
  • Systems of Innovation — New applications that are built on an ad hoc basis to address new business requirements or opportunities. These are typically short life cycle projects (zero to 12 months) using departmental or outside resources and consumer-grade technologies. (1)
Yvonne Genovese, vice president at Gartner said ”One of the keys to using pace layering is to take a more granular approach to thinking about applications.  When classifying applications in pace layers, they must be broken down into individual processes or functions.  Gartner analysts said that one of the keys to developing this strategy is listening carefully to the way business people describe their vision for particular parts of the business. These categories of ideas include:
  • Common ideas — aspects of the business in which leaders are happy to follow commonly accepted ways of doing things that change fairly slowly.
  • Different ideas — aspects of the business in which leaders not only want to do things differently from comparable organizations, but also can specify the details of how the different approach should be taken, and can expect these details to change on a regular basis.
  • New ideas — aspects of the business in which leaders are thinking of an early stage concept, and are not at the point where they can be specific regarding the details of how things should work. (2)
By engaging in Pace Layered Application Strategy, DevOps practices, along with a strong Business Relation Management (BRM) process, we can realize the goals of collaboration and integration while using technology to automate the process of software delivery and infrastructure change, while providing a secure and cost-effective environment to support core business processes.

1&2 Source: Gartner - Pace Layered Application Strategy - http://www.gartner.com/newsroom/id/1923014


Voir l'article
Site Reliability Engineering
19 mai 2017
Site Reliability Engineering (SRE) is a discipline that incorporates aspects of software engineering and applies that to operations with the goal of creating ultra-scalable and highly reliable software systems.  Google’s mastermind behind SRE, Ben Treynor, describes site reliability as “what happens when a software engineer is tasked with what used to be called operations.”

Historically, Dev teams want to release new features in a continuous manner (Change). Ops teams want to make sure that those features don’t break their stuff (Reliability). Of course the business wants both, so these groups have been incentivized very differently leading to what Lee Thompson ((formerly of E*TRADE) coined the “wall of confusion”.  This inherent conflict creates a downward spiral that creates slower feature time to market, longer deployment cycles, increasing numbers of outages, and an ever increasing amount of technical debt.

The discipline of SRE can begin to reduce this dilemma by introducing multiple analytics and statistical analyses for green- or red-lighting launches and help to resolve the extreme focus of stability vs. agility, operational work vs. software engineering and proactive vs. reactive work. These SRE teams are staffed with developer/sys-admin hybrids who not only know how to find problems, but according to Googles Melissa Binde “figure out why it happened, what was the root cause, figure out how to detect it sooner and ideally insure that it doesn’t happen again”.  Sounds a lot like ITIL’s Problem Management process only on steroids.

So at a basic level here is how I understand this works.   As we all know from years of experience, and just being human, nothing is perfect. None of our services ever really achieve 100% uptime; it’s why we invented SLAs. Take it from someone who used to write them.  This is the concept I think is just so cool.  If a team agrees to a 99.8% SLA, it gives them an “error budget” of 0.2%.  This is the maximum allowable threshold for service interruptions. The production team can utilize this error budget however they see fit and in turn release whenever and whatever they want given they are within the SLA.  They get green-lighted based on past performance. If they are operating at or below the defined SLA, all launches are red-lighted until they reduce the number of errors to a level that allows the launch to proceed. SREs (Ops) and developers (Dev) have a strong incentive to work together to minimize the number of errors. This ties completely into the cultural and professional movement known as DevOps, which stresses communication, collaboration and integration between software developers and operational professionals while automating the process of software delivery and infrastructure changes. 

For more information; www.itsmacademy.com/devops

Voir l'article
KPIs and SLAs
19 mai 2017
A short while ago I was asked this question from one of our reader: “I want to set a KPI around how much of the time we meet the SLA. Like 'meeting the SLA x% of the time'. Can someone advise what would be that 'x'? What is the common practice?  Is there an industry standard around this?”  I’m going to have to go with the consultant answer and say it depends.   First, are we talking about a single service to a single customer? Are we talking about multiple services to multiple customers or somewhere in between those two extremes?

Your SLAs should include details of the anticipated performance that your customer expects.  First thing you need to do is discuss with your customer what are the levels of utility and warrantythey are expecting? Then document and agree these targets are reachable given the resources that are at your disposal and any constraints that may be discovered. The requirements for functionality (utility) should be defined by your BRM process and documented in the SLR document.

When you say that we want to meet SLA x% of the time, there are many factors that could have an impact on your ability to meet or not meet that target. How well are these services documented in your service portfolio and catalog? How mature is your Service Level Management process, Incident and Problem Management processes?  How often do you have to allow for changes to services, which could possibly impact the availability of your service?   These and other factors can have a distinct impact on meeting SLAs.  So here are a couple of KPIs you might want to explore:
  • KPI: Total number and percentage increase in the number of SLAs in place
  • KPI: Percentage increase in SLAs agreed against operational services being run
  • KPI: Frequency of service review meetings
  • KPI: Reduction in average response time to outages and incidents
  • KPI: Reduction in outstanding (unresolved) problems for services being delivered
  • KPI: Percentage increase on issues being raised at service and SLA review meetings that are being followed up on and resolved
  • KPI: Increase in number of services with timely reports and active service levels
I hope this will be enough to get you started and stay busy for a while.  Good luck! 

For more information on KPIs and SLAs, consider ITSM Academy's ITIL Foundation and check out our Free Resource Center

Voir l'article
What’s New in IT?
02 mai 2017
What isn’t? With the internet of things there are so many options available to consumers that were not available even one month or one week ago.   With technology and job role functions evolving so fast, the best way to stay current is to become educated.  Here are just a few bits of interesting information.

New for Every Day Consumers:

In a recent update Google’s Virtual Globe has introduced a feature called "Voyager." No longer will you be limited to only exploring places you've heard about, nor will you have to resort to randomly clicking on areas of the planet in hopes of finding a gem. Instead, "Voyager" presents you with dozens of curated journeys around the globe. Each voyage is centered around a theme. “Museums Around the World” will take you to a Street View of museums in every corner of the globe. If natural formations are more your speed, "Earth View" will show you "the most striking and enigmatic landscapes available in Google Earth." And… if that does not excite your there are 3d glasses to use with Google Earth that will really make your view realistic.  Not only is the world evolving but how we view it is evolving too.

New Uses for Technology:

Drones. You have probably seen them and heard of them being used for espionage and for research.  I found it interesting to know that drones armed with sensors helped researchers study a volcanic eruption in Guatemala. Now think about the technology that supports services for your organization. Not only is there a lot of legacy hardware and software that doesn’t fit for today’s products and services, new ways to utilize the technology are continuously evolving, like the drone.

New IT Jobs:

New demand for new types of jobs and skillsets are evolving as you read this. Many include titles that would have been meaningless only a year or two ago:

Augmented Reality Designer

Internet of Things Architect

Container Developers

DevSecOps Engineer

Info World reports that it is no surprise, given that the IT job market is in constant flux with new technologies emerging so quickly, that hiring managers struggle to define those positions - let alone give them a title. IBM, for example, has a Director of Blockchains, and Ford Motor is among many companies looking for GPU Cluster Engineers.

New Education:

For more information regarding ITIL Best Practice, Agile Service Management (Agile and beyond), DevOps certification and more, look here!

Voir l'article
Education in a Changing World
18 avr. 2017
In years past you had to have some years behind you so that you could talk about the good old days.  Conversations would start with statements like “Remember when…?”   Today when a conversation starts with those words it could be a young person talking about how they did things last year or last month vs. how they go about their day to day activities today.

Things are changing so fast!  How does this affect educating and training learners and what needs to be tracked and recorded?  Certainly, not the same as it was a decade ago.

 A recent solicitation stated “Use of ed tech is skyrocketing, students on campus tote several devices each, but service needs range from high tech (wifi, connected classroom) to mundane (rat in the cafeteria, dorm toilet won't flush). All those needs have to be logged, serviced, tracked, reported on - hence the high demands on the platform used”.  Opportunity for bigger, better and more technology abounds!

The tools that we use and the infrastructure that supports them are dynamic and keeping apprised of them will have an impact on the value delivered through our colleges and training organizations.  No matter how quickly activities, lifestyles, viewpoints and technologies change, there are some things that stay the same.

Inspiration and Education are required elements for true knowledge transfer.  Inspiration will always be key in education.  To inspire means to fill an individual with the urge or ability to do or feel something, especially to do something creative.  What about education? According to WIKI, “Education is the process of facilitating learning, or the acquisition of knowledge, skills, values, beliefs and habits. Educational methods include storytelling, discussion, teaching, training and directed research. Education frequently takes place under the guidance of educators, but learners may also educate themselves. Education can take place in formal or informal settings and any experience that has a formative effect on the way one thinks, feels, or acts may be considered educational.” 

While Education and Inspiration might remain the cornerstone of teaching, the methodology of teaching is called pedagogy.  The methodology or the way we go about teaching and learning is changing and changing fast!  The tools used by learners, the tools used by teachers and the tools and technology to track and support them are all in a state of flux.

Knowledge transfer and educating learners when you get right down to it has many aspects that will not change.  Instruction delivered with passion and mission could trump the latest and greatest in technology when it comes to learning but the ability for educators and training organizations to keep up with the use of skyrocketing ed tech and the dynamic needs of learners will require both.

Voir l'article
BRM Convergence
18 avr. 2017
I remember reading a quote “Every business today is a technology company” or something close to that. As we move from business-IT alignment to business-IT integration and now convergence, it is becoming more and more critical to understand and manage both the business and IT capabilities so that integration of the business strategy, IT strategy and the IT portfolio are seamless.  In today’s business climate it is imperative that the IT organization not only understand what the business strategy is, but be able to initiate and deliver services that not only support it, but help to shape it.  The Business Relationship role, process and capability is integral in making that happen.

One of the tools that can be engaged to help facilitate this convergence is the “Business Capability Roadmap.   It is made up of three key components:
  • Roadmap Business Capabilities: Identifies how business capabilities need to change to achieve defined strategies.
  • Roadmap Enabling Capabilities: Identifies how provider capabilities need to change in order to underpin new business capabilities.
  • Assess Enterprise Opportunities:  Explores how new provider capabilities will be engaged across the enterprise.
The benefit that the organization derives from this activity is that we understand where the business is taking key capabilities over the next 3 to 5 years so that we can appropriately support its strategic objectives.  We can then ally business and provider processes, information, services and technology to a common vision and mission.  This will accelerate strategic thinking versus short term thinking. It drives the conversation forward to increase understanding between the business and the provider which results in the ability to identify enterprise opportunities more quickly allowing us to be more agile in the delivery of new or improved services.

For more information please see http://www.itsmacademy.com/brmp

Voir l'article
Security in a DevOps Environment
18 avr. 2017
Integrating Development and Operation teams as well as other functions that have previously been silo’d is key to any development project for all service providers today.   We hear a lot about this in DevOps training and certification classes.   What about security?  You may have heard the term DevSecOps.  This idea and term was coined to ensure that architects and developers include into our requirements and code those things necessary for security. Design architects will also want to ensure that security is integrated throughout the value stream of development, deployment and operations and it is done in such a way so that the complexity is as transparent as possible to the functional teams involved.   How can we do this without impeding our flow of work?    How can we still be able to meet compliance for legislative, legal or regulatory requirements relating to security?

This is where Automation comes in.  Collaboration and measurement are key values but automation is also needed to ensure success here. We hear a lot about Continuous Delivery and Continuous Deployment.  Those knowledgeable about this know that these practices include integrated/ automated testing at the same time as we commit code and complete the build.  We cannot simply disregard security. Developers, security architects and testers will be integrating the security requirements in addition to those required for the functionality of the application/code.   Simply put, in DevSecOps we are designing for security and doing that while we design and integrate the code for the functionality of a product or service.  To do this you will need to have clearly defined roles and responsibilities for integrated requirements, integrated development and integrated teams.

Developers, auditors and other members of this integrated system will need to be trained or retrained on how to develop secure code.  They will need to understand those elements required in the code to ensure it is resilient.  If the developers of an application know the security requirements prior to development, the code will look very different.   We no longer want to put security on as a wrapper after the code is developed.  Even though a single team may be responsible, different people in the team will assume different roles. The scope of their capabilities can be managed.  To do this organizations will need support for common DevOps toolchain environments and include security into each. 

For more information relating to DevOps and DevSecOps please see http://www.itsmacademy.com/devops

Voir l'article
BRM, DevOps and Excellence in IT Service Management
21 mars 2017
To say that digital technology has changed the world is an understatement. Digital transformations are revolutionizing entire industries and reshaping every aspect of business. To stay competitive, businesses must accelerate the delivery of digital products and services. To meet business demand, IT organizations must accelerate the delivery of secure, high-quality and reliable software features and functionality (DevOps).

The thing about any transformation, whether it’s the digital transformation affecting the world, or the DevOps transformation affecting IT organizations and their business partners, is that it’s never only about the technology. A successful transformation requires shifts in peoples’ behaviors, mindsets, vocabulary, roles and reporting relationships. It requires changes to processes and to day-to-day operating procedures.

Perhaps most importantly, the ability to undertake and achieve any transformation is determined by whether, or not, the company’s leadership has articulated a clear business strategy and has fostered a culture that embraces innovation, collaboration, and experimentation, taking risks and learning from failure (The Third Way).

Here’s where Business Relationship Management comes into play. As a discipline, Business Relationship Management embodies a set of competencies (knowledge, skills and behaviors) that foster productive, value-producing relationships between an IT organization and its business partners. As a role, a Business Relationship Manager (BRM) is a link between a provider organization and one or more business units. BRM(s) work with business units to understand their needs and plans and to coordinate the delivery of IT services that meet those needs. Ultimately, BRMS help move the IT organization from being viewed as an order taker into a strategic business partner.

But herein lies the reality. Business unit leaders aren’t going to be willing to discuss strategic plans with BRMs until they can trust that the issues of today and this week (incidents, problems, changes, releases) are being taken care of. The road from service provider to trusted advisor to strategic business partner is built on a foundation of IT service management excellence.

The same can be said for DevOps. You sometimes hear that DevOps and IT service management (ITSM) aren’t compatible (but that’s another blog for another day). The reality is that organizations that are successfully adopting DevOps practices such as continuous integration, continuous delivery and continuous testing are performing ITSM processes. Those processes are just so streamlined and, in many cases, automated that people don’t even realize that they are executing ITSM processes.

Will excellence in ITSM guarantee the elevation of the IT organization to strategic business partner? Not necessarily. But BRMs will never get a seat at the table when strategic conversations are happening without it.

Voir l'article
Why RCV?
15 mars 2017
I was recently asked the following: “I want to take the “Release, Control and Validation” (RCV) class.  As a Release Manager, I know it will help but I need to justify this for my manager.  What is the value of taking this class?”

Every organization can be effective with release and deployments.  What is needed today is for us not only to get the job done but to do it efficiently.  Efficiency infers that we deliver value, but that we design and deliver services, BETTER, MORE, FASTER THAN EVER BEFORE and at the same time we are being COST effective.

The role of Release Manager, although it is central to the release and deployment process, is much broader in scope than many organizations or managers realize.  This role in Best Practice is separate from Change Manager and from the actual Validation and Testing Manager or even the Change Evaluation role.   Frequently these roles will be assigned to one or more persons.  It does not mean that you have to open several new req's or that you will have to replace people.  What this does mean is that a clear and concise understanding of these processes, roles and functions must be clearly understood in order for organizations to really reap the benefits that they expect from change and release efforts.  Not only do we need to understand the dependencies, but also the workflow of how we can quickly interface with the various functional teams to respond quickly.  Without the proper knowledge and skill for these best practices, an organization could overtime improve but will be less likely to reap the type of optimization and benefits that they had hoped for. Everyone will agree that we can always do better with what we have.

The course Release Control and Validation (RCV) provides in-depth knowledge of the ITIL RCV areas: Change Management, Release and Deployment Management, Service Validation and Testing, Service Asset and Configuration Management, Request Fulfillment, Change Evaluation and Knowledge Management; most importantly the roles and the process interfaces and dependencies.  Best practice can help get the bigger picture, identify gaps, and allow for the practitioner to be enabled for success.   Business requirements are dynamic and we (throughout the design & delivery) must also have processes and models in place to meet those constantly changing business requirements.

In summary, the RCV processes, integration and knowledge enable:
  • response to CHANGING Business Requirements
  • consistent and Repeatable Workflow that result in and successfully deploy faster into the   environment
  • your staff and your organization for real success resulting in less rework and greater productivity
  • results in cost savings for the business
  • the ability to deploy changes quickly with less defects and therefore less business and customer disruption
  • risk reduction while complying with governance and audit requirements 
  • overall improvement in quality resulting in increased value for consumers

 For more information on Release, Control, and Validation:  click here
Voir l'article
The Business Relationship Manager
07 mars 2017
The Business Relationship Manager is a role that serves as a strategic interface between the IT Service Provider and one or more Business Partners (or Business Units within a single organization) to promote, and influence Business Demand for IT services and products. They also work to ensure that the potential business value from those products and services is realized, optimized and properly documented.  The Business Relationship Manager can accomplish this through the engagement of four core disciplines which are defined as part of the house of Business Relationship Management (BRM).  This house is built upon a foundation of BRM competencies which support the Business Relationship Manager role and ensure it has the skills and aptitudes to be effective and deliver value to both the Provider and its Business Partner.

The Four Core BRM Disciplines:
  • Demand Shaping: This discipline stimulates and shapes business demand for the provider’s services, capabilities and products. It ensures that the business strategies can fully leverage these services, capabilities and products within the provider’s portfolio. BRM also ensures that the provider’s portfolio has the right mix of these items so that the business strategy can be enabled through the engagement of them.
  • Exploring: This discipline identifies and justifies demand. BRM helps to identify business and technology trends to enable discovery and demand identification.  This is an iterative process which facilitates the review of new business, industry and technology trends with the potential to create value for the business environment.  The key benefit here, is the identification of prioritized business value initiatives that will then manifest themselves as aligned and supportive services, capabilities and products within the provider’s portfolio.
  • Servicing: The servicing discipline coordinates resources, manages Business Partner expectations and integrates activities in accordance with the business-provider partnership. This will ensure that business-provider engagement will translate into effective supply requirements.  Servicing enables the alignment to the business strategy through the use of Business Capability Roadmapping along with portfolio and program management.
  • Value Harvesting: This discipline ensures the success of the business change initiatives that result from the exploring and servicing activities.  Value harvesting includes activities to track and review performance, identify ways to increase business value from the business-provider initiatives and services and instigates feedback that will trigger the continuous improvement cycles.  This process provides the stakeholders with the appropriate insights into the results of business change and initiatives.
These four core disciplines, along with best practice capabilities and defined competencies, allow the BRM to be fully integrated with business processes that generate demand and the provider capabilities for servicing it.


For more information:  http://www.itsmacademy.com/brmp
Voir l'article
Business Relationship Management (BRM) Metaphors
28 févr. 2017
The Metaphors for Business Relationship Management (BRM) can be helpful ways to think about and describe the BRM role, discipline and organizational capabilities. There are three metaphors we currently use today.  They are as follows:

BRM as a Connector:

The BRM acts as a connector between the Service Provider organization and its Business Partners – forging productive connections between Provider resources and the Business Partner and among Business Partners.  There are three primary aspects to the BRM’s role as a connector:

  1. Facilitate productive connections and mobilize projects and programs.
  2. Stimulate, surface and shape business demand for the Business Partner while increasing the savviness within the Business Partner regarding the Provider’s services and products.
  3. Influence the Provider to ensure appropriate supply of services and products, both in terms of quality and capacity. (1) 
BRM as an Orchestrator:

The BRM also acts as an orchestrator between the Provider organization and its Business Partners – orchestrating key roles, resources and capabilities to stimulate, surface, shape and harvest business value.  There are three primary aspects to the BRM role as an orchestrator:

  1. Orchestrate capabilities to drive value from Provider services
  2. Coordinate and aggregate business demand for the Business Partner
  3. Orchestrate key Provider roles on behalf of the Business Partner (Enterprise Architecture, Subject Matter Experts, Project Managers and Program Managers) (2)
BRM as a Navigator:

The BRM also acts as a navigator between the Provider organization and its Business Partners, navigating both the Business Partner and the Provider along a path to realized business value.  There are three primary aspects to the BRM’s role as a navigator:

  1. Facilitate convergence between the Provider and the Business Partners.  Convergence breaks down walls and embeds Provider capabilities within the Business Partners so as to increase agility and business value.
  2. Facilitate business strategic planning and road mapping for the Business Partner.
  3. Guide key Provider roles on behalf of the Business Partner such as Enterprise Architecture, Portfolio and Program Management. (3)

Ref: 1,2,3 BRMIBOK

For more information on BRM click here:  http://www.itsmacademy.com/brmp
Voir l'article
The Service Management Trinity
21 févr. 2017
In a previous blog from the ITSM Professor we focused on the relevance of ITIL and ITSM Best Practices to contemporary IT service providers.  We learned how a successful DevOps initiative must embrace ITSM, Lean, Agile and other frameworks and practices to ensure success.  The solution to value is like a diamond and has many facets!  In 1992 I read an article that talked about the key to delivering value and the topic was all about People, Process and Technology.

Twenty-five years later I must agree this is still the winning formula.  What might be different is how we view and utilize these for success.

What will Change?

People – Integrated teams with ownership and accountability. Visualized workflow and clear direction.  Communication, Education and Collaboration required.  Inspire and Educate!

Process – NO MORE overburdened bureaucratic difficult processes to follow.  We want just enough process, just enough governance and the process activities will no longer be siloed to just Design or to just Operational lifecycles.  They will be integrated.  Shatter the departmental and the process silo’s.   Have you embraced ITSM Best Practicesand Agile Service Management?  This is not an oxymoron.

Technology – We should now have an outside in approach.  “Information, Technology, and Infrastructure are key but our focus will shift from those to the “Value” that that they produce.  The voice of the customer and dynamic business requirements becomes the focus.  Today with cloud services, infrastructure on demand and other innovation yet to be seen we are more than ever enabled to shift our focus from the technology to outcomes.  Automation will be key but we now look at microsystems and Tool Chains that support the flow of integrated teams, integrated processes and brilliant results.

The trinity still stands.  Some organizations talk about a focus on People, Process and Technology but in the wrong order.   If you are focusing more on Technology and Process than you may be at risk.  It is still all about PEOPLE, PROCESS, and TECHNOLOGY but most importantly is that it is in that order.
Voir l'article
Is ITIL Still Relevant?
14 févr. 2017
With the onset of practices such as DevOps, Continuous Delivery, Rugged Code, and Value stream mapping, is ITIL / ITSM Best Practice still relevant?

The short and emphatic answer is YES!

Let’s look at how ITSM Best Practices are relevant and enable some of the initiatives that are in the foreground of Service Management for many contemporary IT organizations today.

DevOps – DevOps is a cultural and professional movement that focuses on communication and collaboration to ensure a balance between responsiveness to dynamic business requirements and stability.   Therefore, things like Lean and Value Stream Mapping, practices like Continuous Delivery and Continuous Deployment, all become a subset or a building block to a successful DevOps initiative.  DevOps is frequently an organic approach toward automating workflow and getting products to market more efficiently. Ok, if we can accept that then the next question is … What are you going to automate?  

ITSM Best PracticeProvides the cornerstone for the activities referred to as “ITSM Processes”.  The need for these activities does not go away.  They need to be performed to get any hope of meeting compliance, mitigating risk and to ensure value for any product or service that is being designed, deployed and more importantly sustained over the life of that product or service.  If DevOps integrates teams throughout the value stream including Service Operation teams the better question is how could you even think about omitting best practice?  What is going to change is how we go about creating and fulfilling the processes throughout the service lifecycle.  Agile software development is money out the window if we do not have Agile processes and workflow. The backbone will still be People, Process and Technology.  And… in that order.

It is mandatory for our teams to get a common understanding of just how DevOps is enabled by Agile, ITSM and Lean best practices.  It is not just the tool, automation and continuous delivery but how we go about doing this that is key.  We need to inspire and to educate our teams for how these practices can dove tail together to enable them and your company for success. 

Voir l'article
IT Service Management - Tools
07 févr. 2017
In today’s world where demand for up to date services has grown and the lead times for delivery has continued to be shortened I am often asked, what is the best tool? The answer is, of course, “it depends!” Every organization has different needs, budgets and resources, however the requirements for automated building, testing and delivering new functionality has never been greater.

Every organization must be able to look at the list of requirements for tools from both the operational and development sides of the IT organization as the functions become more and more integrated.

The starting point is a list of generic requirements. An integrated suite is preferable and should include options such as:
  • Service Portfolio
  • Service Catalog
  • Service Design Tools
  • Discovery/Deployment/Licensing Technology
  • Workflow or process engines
  • CMDB’S
  • Configuration Management Systems (CMS)
  • Self Help for Users
  • Remote Control
  • Diagnostic Utilities
  • Reporting Tools/Dashboards
  • Service Knowledge Management System (SKMS)
Depending on your requirements, goals, budget and maturity level, you may need one, several or all of the above technologies. A good suite will offer the flexibility to purchase only those modules that are currently needed by your organization with the option to add more over time.

The next step is to assess your current tools and their use. The assessment may reveal that you are not using existing tools to their fullest capability. Consider the following when evaluating existing tools and possible new purchases:
  • Support for monitoring service levels, data structure, data handling and integration
  • Integration of multi-vendor infrastructure components
  • Conformity to international open standards
  • Flexibility in implementation usage and data sharing
  • Usability
  • Distributed clients with a centralized shared database
  • Conversion requirements
  • Data backup, control and security
  • Support and scalability
The following are useful evaluation techniques:
  • Gather your Requirements. (Use the MoSCoW strategy for evaluating your requirements. Must haves (M), Should haves (S), Could haves (C), and our Won’t haves but would like to have (W)?)
  • From the MoSCoW list, create a Statement of Requirements (SOR).
  • Identify possible products
  • Determine a selection criteria
  • Evaluate products
  • Put together a short list of products
  • Score the final products
  • Rank the products
  • Select the product that meets your needs and budget
Please remember that any tool is NOT a silver bullet. Effective internal processes are critical to gaining efficiencies through tools. Tool success will likely depend on your planning, deployment, management and improvement of process.

While there are many good technologies in the marketplace today, it is important to select the one that meets your specific and unique requirements.

Voir l'article
Service Acceptance Criteria
31 janv. 2017
I have often been asked what value does the Service Acceptance Criteria (SAC) provide?  Along with other criteria and elements, the Service Acceptance Criteria forms what is described in ITIL and the Service Design Package.  With so much importance on Design, Development and Deployment, the significance of the SAC increases as we look to optimize service value.  Do you want to increase value to your business and customers? First let’s understand what the SAC is. 

Service Acceptance Criteria: 

A set of criteria used to ensure that an IT Service meets its functionality and quality requirements and that the IT Service Provider is ready to operate the new IT Service when it has been deployed. This set of criteria is in the form of a formal agreement that an IT Service, Process, Plan or other deliverable is complete, accurate, reliable and meets the specified requirements. 

In the past, this has sometimes been thought of and enacted on at the end of the value stream. High performing service providers will frequently apply other methodologies such as lean, agile and ITIL process improvements to ensure that the SAC is defined and improved throughout the development/deployment lifecycle.  This is how ITIL intends it to be utilized.

We must understand that all design activities are triggered by changes in business needs or service improvements. In order to design and deliver IT services that meet the changing needs of the customers and the business, we must ensure that the contents of the Service Acceptance Criteria are incorporated and required achievements are planned into the initial design.  What?  Does this mean that the SAC starts in the requirements gathering stage and evolves throughout the delivery?  Yes, and in doing so, a service provider could help to shift their organization to focus on value from a customer’s perspective rather from that of the IT service providers view point. 

The SAC is the document that will ensure the Service Provider is ready to deliver the new service by answering the following criteria:
  • Has the go live date been agreed to with all parties?
  • Has the deployment project and schedule been agreed to and made public to all stakeholders?
  • Have all SLR/SLA’s been reviewed, revised and agreed to with all stakeholders?
  • Has the Service Catalog/Portfolio been updated and all appropriate relationships established within the Configuration Management System?
  • Have all users been identified/approved and appropriate accounts created for them?
  • Can all SLR/SLA targets be monitored, measured, reported and reviewed?
  • Can performance and capacity targets be measured and incorporated into the Capacity Plan?
  • Have incident and problem categories and processes been reviewed and revised for the new service?
  • Has appropriate technical support documentation been provided and accepted by Incident, Problem and all IT support teams?
  • Have all users been trained and user documentation been supplied and accepted?
  • Have appropriate business managers signed off acceptance of the new service?

Consider now how the flow of work, the velocity of your team and value to the business and external customers could be optimized with a focus on the SAC early in the ­­­­­­­­­­­­­­­­value stream. With these documented criteria in hand we can insure that the Service Provider will meet the agreed needs of the customer and the business. It will insure that availability, capacity, security and continuity can be assured and thereby deliver value to the business.

For more information see ITIL Service Design

Voir l'article
Incident vs. Problem
25 janv. 2017
You may have seen a similar blog from the Professor a few years back that talked about the distinction between the idea of an incident vs problem.  Everything from that article is still relevant.  As process and methods for development and deployment have matured so has the usage of Incident and Problem Management.

This is one of the most often confused points in for Agile, LEAN and ITIL adaptations.
The ITIL definition is the same.

Incident: Any unplanned event that causes, or may cause, a disruption or interruption to service delivery or quality
Problem: The cause of one or more incidents, events, alerts or situation­­­­­­­
Where and how we apply Incident and Problem Management is evolving.
A decade ago, and still in some organizations, Incident and Problem Management are processes exclusive to Service Operation.   ITIL is so very relevant and today we find, with the onset of DevOps and cultural shifts, many organizations are adopting little or zero tolerance for allowing defects through the development/deployment lifecycle.  ITIL processes and principles will help.

High performing service providers have discovered that by integrating Incident and Problem Management early in the lifecycle, such as in design, development, build and test activities, they can become much more proactive to ensure true value to the customer. This aligns with and allows for the DevOps principle for shortened and amplified feedback loops throughout the value stream of Design and Delivery. If this concept is also applied to the process improvements of that value stream then the time, the amount of resources and certainly the cost will be much less for the service provider.

If Incident and Problem Management are applied early in the lifecycle and a defect is discovered, “Problem Management” would determine the root cause or the reason “Why” and propose a solution to prevent the repeat of this type of defect (incident) or cause (problem) so that it will never happen again.  This in turn prevents the “defect/incident” from occurring in the future.  This is very different then those that focus on Problem Management after the defect has done its damage and consider it only as an operational task.

If we continue to look at Incident and Problem Management as merely for Service Operation, it is likely that we will have a lot of business impact and potentially frustrated technicians who do not feel enabled for success and a likely dissatisfied customer.  By thinking out of the box and considering how you can increase the flow of work for Design and Delivery by applying Incident and Problem Management activities early in the lifecycle, an organization can truly become proactive.  
For further information, ITIL training, resources and more …  click here!
Voir l'article
Service Asset & Configuration Management (SACM)
24 janv. 2017
Service Asset & Configuration Management (SACM) is the one process that touches all of the other ITIL processes. SACM’s purpose is to deliver accurate and up-to-date data and information to every other process across the lifecycle.  The fascinating fact about SACM is that in many cases it depends on those other processes through their defined, documented and agreed to activities, to insure that the data and information about those assets is up to date, accurate and properly recorded through the Configuration Management System (CMS),  No organization can be truly efficient and effective without having a configuration management process to insure we understand how and where that infrastructure, application, tools, documentation and sometimes even people are being utilized in delivering business outcomes and creating value.

SACM ensures that CIs (configuration items) are properly identified; baselined and that changes made to them are properly controlled and recorded.  This is accomplished by closely integrating Change, Release and Deployment and SACM.  Most organizations have a process that will track and report on the value and ownership of fixed assets throughout their lifecycle.  Much of this is done by a part of the business known asfixed asset management or financial asset management. Their goal is to keep financial information on these resources. In most cases they are not usually within the same business unit as Information Technology.  For the most part they are not concerned with the relationships between these resources and how these assets are being utilized and what IT and business services they support.  SACM must ensure the proper care and maintenance of these CIs that are under the control of IT services.  There should be well established intersections between these groups in order to provide the overall business a more defined and detailed view of these capital assets.

By having an accurate representation and clear visibility to your service assets:
  • Staff is better able to forecast and plan changes.
  • IT staff have a better understanding of the relationship between CIs and the services they support
  • Assessments are more accurate for Availability, Capacity and Continuity planning.
  • There is a greater effectiveness in delivery of service levels.
  • You have the ability to precisely identify the costs of a service.
  • You can provide greater flexibility to the business in meeting market opportunities.
  • As technological changes happen it allows SACM to create more effect CIs and CI definitions to meet the new reality.
For more information:

Voir l'article