Skip to main content

Posts

Network Neutrality – Heads Up!

Network Neutrality preserves your right to communicate freely online. The term Network Neutrality was coined in 2003 by a Columbia University media law professor named Tim Wu.  Back in the day it was referred to as “Open”.   Network Neutrality is a principle where internet service providers and government regulators must treat all data  on the Internet the same.  This means that you cannot discriminate or have differential charging and costs based on user, based on content, website, platform, application, equipment type, or mode of communication. It’s because of Net Neutrality that small businesses and entrepreneurs have been able to thrive online.  Our fair and level playing field is at risk.  Big phone and cable companies and their lobbyists filed suit against the FCC guiding principles for Network Neutrality.  Internet Service Providers (ISP’s) have much to gain financially if they can discriminately charge for varied services that are currently free.  Free Press jumped in an

Service Offerings - Activities for Service Portfolio Management

Service Portfolio Management (SPM) is a process that is defined by ITIL best practices in the Service Strategy Lifecycle Stage.  The initiation of activities for Service Portfolio Management is often a result of changes to strategic plans or the identification of a service improvement plan and are triggered by a proposal that must have executive approval to proceed.   For existing services, Service Portfolio Management considers investments that have already been made along with new investments required.  The combined may result in the service being too expensive for what the business will achieve.  Investment decisions will need to be made.  There are many possible procedures and workflows to fulfill all the details of this process but overall the activities can be clearly understood with four high level process activities. Define – In this stage of the process SPM must document and understand existing and new services.  Every proposal for a new or changed service must be accompa

Work Holistically

I TSM best practice frequently suggests working holistically.   This is particularly true when defining a strategy and architecting a design solution but when you think about it, this holistic viewpoint should permeate every investment, improvement, and action in the entire value stream from thought to end of life for every service or product deployed. At a high-level thinking holistically involves looking at things from a people process technology perspective but cannot leave out our partners and suppliers.  No service, process, or functional team stands alone.   Changing one element of a complex system will impact others.  This is a real challenge because no one team can know everything about all aspects of the system.  Therefore, working holistically requires a balance between specialization (functions and departments) and the coordination of complex integrated process activities.  It is only then do we get a clear picture of the lifecycle of a service and any hope of managing

DevOps Testing – Do it Right

One of the key principles of DevOps stresses that we need to fail and fail fast.   A key part that frequently gets omitted.  That key element of the principle is that we fail fast so that we can LEARN. When we learn it is always best to act and to share.   In the spirit of learning and sharing here are some consequences of not performing DevOps testing properly that might help to mitigate some of your challenges. Consequences of NOT doing DevOps testing properly – challenges and thoughts Culture Conflict Culture Conflict can exist between business leaders, developers, QA testers, infrastructure/tools staff, operations staff or any stakeholder in the entire value stream. When there are unclear roles and responsibilities for the testing of a new or changed service or product, a friction begins.  This friction propagates conflict.  Be aware.  Make management of organizational change a priority. Test Escapes (False Positive)           False Positive Test Escapes occur when

Cyber and DDOS – What is it?

We saw in a recent blog from “The Professor” how cybercriminals could create a network of controlled computers to propagate a “BotNet”.   One of the malicious reasons for these powerful networks of control is so that the hacker can perform “Distributed Network Attacks” (DDA’s). We all have experienced this at some level and the outcome is not good for enterprise, corporations, or businesses of any size.  DDA’s create disruption even to our own home operations.   A DDA is sometimes referred to as a Distributed Denial of Service or DDOS attack.  This virus or network of virus’s attacks behind the scenes to take over system resources.  A DDOS could attack switches, hubs, routers. It sometimes will flood the network backbone with nuisance transactions with the intention of sucking up all the bandwidth that might otherwise be necessary for day to day operations. DDOS can bring to a screeching halt the web sites for processing claims, or even shopping cart interfaces for the purchasing o

Portfolio Management & BRM

The purpose of Portfolio Management, when applied to Provider investments (especially, IT investments), is a central mechanism to an overall Value Management approach by making investment allocation explicit against strategic choices such as how much to invest in potentially high value, but usually risky initiatives versus safe but low-value activities. The Service Portfolio represents the complete set of services that are managed by the service Provider.  It is used to manage the entire lifecycle of all services and is defined by three categories of services.  The service pipeline represents service that is under consideration (purposed) or those that are currently in development but are not yet ready for deployment or consumption by the business partners. The next category is the service catalog which represents all live services or services that are available for deployment to the business partners. The final category is retired services.  This represents the services that are

DevOps Test Engineer Question…What is the difference between Static Testing and Dynamic Testing for Continuous Deployment?

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 wit

Business–Provider Alignment Model

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

What is a Botnet - Why do I care?

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

Business-Provider Maturity Model

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 Servi

Nine Guiding Principles for ITSM or… for Everyday Life

ITIL Practitioner focuses on nine guiding service management principles that distill 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 ITSM Academy's ITIL Practitioner course is based on these 9 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 w

The Business Relationship Maturity Model

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 relationshi

Rugged DevOps

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

KPIs and SLAs

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 warranty they 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 pr