Follow by Email

Search

Posts

Infrastructure as
Code – is a common term among developers, architects, and operational staff
and the practice has evolved in response to demand for quality and efficiency
in the industry. Over the last decade
many organizations have come to realize that the essence of Infrastructure as Code is to treat the configuration of systems
the same way that software source code is treated. Frequent code integration, automated builds,
and integrated testing have resulted in stronger IT performance and therefore business
value. Security as Code
– An increase in security breaches across all industries has brought forward a
similar concept, and that is to look at “Security as Code”. This concept would include the usage of
repeatable algorithms to integrate security checks with each code check. This expands the scope of traditional “Continuous
Integration” and automation. Organizations
realize that security is no longer a second thought and must be addressed at
the front of the value stream. …

We are all customers of someone right? What was your last customer experience
like? Was it so good that it completely
changed how you thought about the product or the organization you were
receiving services from? On the other hand was the service you received so poor
that you vowed never to use their products or services ever again. We have all been in those situations. You may
not have realized it, but how that interaction was designed can have a huge
impact on the perception you, the customer, walk away with. I recently read a series of articles in the
September issue of Harvard Business Review magazine. The entire series was titled “The Evolution
of Design Thinking” - It’s no longer just for products. It speaks to how executives
are using this approach to devise strategy and manage change. I can’t tell you what an absolute must read
this is for all. It will make you take a
second look at how you design, deliver and support the services to your
customers. For me personally …

I was recently asked what the compliance requirements, architectural constraints and interface requirements are in designing the service design package for a new app.

The short answer is that the Service Design Package (SDP) would have ALL of the documents and information related to how the app was designed and developed including any policies or known compliance or other constraints. The purpose of the SDP is to provide a living set of knowledge assets that can be passed around the lifecycle for use in each stage (e.g. deployment, operations, support, updating, etc.).

For more information the the SDP please use this link: http://www.itsmacademy.com/itil-sd/

Operating under a constant threat of cyber attacks is the new
normal for many organizations in today’s virtual business environment. These attacks can come from anywhere, from
anybody and at any time. It is no longer
a question of reacting to and then fixing the problem. Today the question is “How do we prepare the
entire organization to be prepared and vigilant to deal with cyber security
threats each and every day.
A defensive approach is no longer adequate. A proactive strategy by cyber security teams
with the appropriate expertise, capabilities and best practice processes and
policies is an absolute must have in order to meet the challenge of recurring
engagement with those whose intent is to harm the organization in some way.
There must be well defined and documented processes to prevent, where possible,
detect and respond with control and countermeasures as quickly as possible
while predicting what will happen next. The introduction of effective cyber resilience
requires …

Flexibility and agility are key to success and business performance. Many Service providers have adopted Agile methods to ensure that they can meet demand for increasing changes in business requirements. Product Backlogs are common and are generally understood; but what about Process Backlogs? Product Backlog – In the
“Scrum Guide” Ken Schwaber and Jeff Sutherland describe the Product Backlog as
an ordered list of everything that might be needed in the product. It is the single source of requirements for
changes to be made to the product. The Product Owner is responsible for the
Product Backlog, including its content, availability, and ordering. A Product Backlog is never complete. The
earliest development of it only lays out the initially known and best-understood
requirements. The Product Backlog evolves as the product and the environment in
which it will be used evolves. The Product Backlog is dynamic; it constantly
changes to identify what the product needs to be appropriate, …

If a product
backlog is growing faster than you deploy, if it cannot be prioritized
properly, and business outcomes suffer, are your “Agile” efforts really
working? Agile software
development is a group of
software development methods in which requirements and solutions evolve through collaboration between
self-organizing, cross-functional
teams. It promotes
adaptive planning, evolutionary development, early delivery, continuous
improvement, and encourages rapid and flexible response to change. A broken product
backlog is only one of many symptoms that something is broken. If there are
bottlenecks in change, delivery and deployment than what real value can
evolutionary and faster development bring to the business? It is time to consider “Agile Service
Management”. Agile Service Management ensures that agile principles and methods go
beyond software development to
ensure the product backlog is in control and that we, as service providers, can
meet the speed of delivery while producing…

When an organization is planning on a major change that will
incur significant cost, risk, time and engagement of resources along with
organizational impact, it is best practice to initiate this activity through
the Service Portfolio process. Before
this new or significantly changed service is chartered, it is important that it
be reviewed for how it may impact the short, medium and long term support of
other services currently being delivered, the pool of limited resources that
will be utilized for this undertaking and on the change schedule itself.
The Change Proposal is used to communicate a high level
description of the change and is normally submitted to Change Management for
authorization. Authorization, however, is
not an approval for implementation, but is a measure to allow the service to be
chartered so design activity on the service can begin. In some cases the
proposal may be created by someone other than Portfolio Management, such as the
PMO or SMO.
This high level des…

A developer recently asked me “What is the real difference
between Cadence and Velocity? Aren’t
they both just talking about speed?” Hmmm… Good Questions.
Cadence
Generally thinking
cadence can be tied to rhythm. One thing
to remember is that the DevOps value stream is much broader in scope than just
Dev and Ops. So what are we looking at
here? The rhythm of code integration,
and how we align with that things like integrated testing? Yes, but also consider that the code development
integration and deployment has to be in rhythm with the demand that is coming from
your Customer and Business side. If we
are not in sync or have the same cadence as the business demand all other measurements
may not be beneficial. Alright, now let’s
consider that your design and development teams work diligently to implement
Agile Software Development principles to align and sync with the business. If the cadence in test and deployment is not
in sync then you have a potential bottleneck an…

So unlike
the Billy Joel lyric “Love you just the way you are”, we can never be satisfied
with our processes being just the way they are.
As the organizations that we are engaged by continually change and
mature to meet customers dynamic requirements, our processes must be
continually assessed, measured and matured to ensure that they stay relevant
and deliver value long into the future.
This takes real time, effort and resources. Organizations cannot possibly move from being
informal or ad-hoc to having a fully integrated ITSM program in a short period
of time. Just being able to gather the
correct components (people, process, technology and information) can be a
lengthy process and, of course, there is the decision of which processes do I
begin with. The saying
“Rome was not built in a day” really applies in this situation. We must begin from the perspective that each
level of maturity forms the foundation for the next level of maturity. Trying
to jump over levels will almost al…

Let’s face it, IT service
management (ITSM) processes get a bad rap. Sometimes deservedly so. Bureaucratic
and overly risk-adverse processes can be a real constraint in the IT value
stream; particularly in organizations that are adopting agile, lean and DevOps
practices. To keep pace, today’s IT organizations must be built on ITSM policies
and processes that facilitate speed and change. So who ensures that ITSM
processes are designed with ‘just enough’ control to meet an organization’s
needs? Here’s where the role of Certified
Agile Process Owner comes into play.
A Certified
Agile Process Owner (CAPO)SM adapts agile and Scrum values
and practices to ITSM processes and process design and improvement activities.
Much like a Scrum
Product Owner, a Certified Agile Process
Owner manages stakeholder requirements and strives to translate those
requirements into process activities and features that deliver value.
What’s different is that CAPOs and Process
Improvement Teams use Sprints to de…

Would you buy a product or service that did not include some
type of warranty? If the manufacturer or
reseller does not explicitly set the expectations, then you will form them for
yourself. It is the same with the
customers of your IT services. Either IT
clearly sets the expectations, or end-users will develop them on their own. Best
practice tells us that during the negotiation and acceptance of Service Level
Agreements, IT commits that services not only meet business and customer
outcomes but also that they will meet requirements for availability, capacity,
continuity and security.
Ok… that is good.
Best practice tells us to include these so called “non-functional”
requirements early in the lifecycle of a service. In reality these warranty requirements are
often considered somewhat in the Strategy/Design stage but more often than we
would like to admit the majority of the work and effort for security and
availability are performed reactively in the Service Operation lifecyc…

User stories are one of the primary development artifacts for Scrum teams. They are a short description of the feature as told from the perspective of the person (stakeholder) who desired some new capability from a current service, system or application. Many Scrum teams have adopted the user story template developed by Mike Cohn, which identified who the end user is, what the end user wants and why in a single sentence. This template is most often written like this: "As a (type of user), I want (some goal) so that (some reason)." Example: As an Incident Process Owner, I want to see a release of known errors in order to do appropriate service desk staff training. In this way team members are encouraged to think of their work from the perspective of who will use it, ensuring requirements get met and value is delivered. User stories are narrative texts that describe an interaction of the user and the service. It focuses on the value that a user gains from utilizing the s…

What is the difference between a Business Service Catalog and a Request Fulfillment Catalog? One clear way to distinguish the type of service catalog that is required is to ask yourself, who is your audience? I have found that when a lot of IT organizations say that they have a Service Catalog many are talking about a service catalog for end users. Another very important service catalog is one that is mapped to your business customer needs. In this blog I will briefly discuss some characteristics of service catalogs for these very distinct audiences and for the purpose of clarity I will refer to them as Request Fulfillment and Business ServiceCatalog.

Request Fulfillment Service Catalog

Service providers today are striving to automate the first line support for user request fulfillment by providing self-help and also more importantly self-serve end user request fulfillment catalogs. This self-serve catalog is the most common and allows users to fulfill requests directly from a web…

All changes need to be assessed and evaluated. Changes that are considered significant should be subject to a normal change evaluation in which we have well defined criteria for making this determination. In this blog we will focus on the assessment side of the equation.

A logical place to begin assessing the impact of changes on services and configuration assets would be the use of the "Seven Rs of Change Management". Without these questions being answered a proper impact assessment could not be completed. When leading an impact and resource assessment several items should be considered. At the top of the chart we need to determine if there will be an impact to the customer's business operations. Next we might want to know what the effect will be on infrastructure, individual customer services and their performance, reliability, security, continuity and ability to handle various levels of demand. Additionally we will need to understand what the current change sc…

In today's dynamic business climate, service
outages cause real bottom line impact to the business. There are documented
best practice processes and known critical success factors and yet outages that
throw support organizations into reactive firefighting turmoil are far too
common.
Mature processes with just enough control are needed to smoothly
transition new and changed services into production, helping to ensure stability
for IT and the business. Most
organizations will confirm that they do have Change and Release Management processes
in place. Service Providers will usually
have some level of Service Asset and Configuration Management control. There is generally a lot of buzz and focus on
three core processes for Service Transition and the success and integration of
these three are critical to business success.
Three Core Processes for
Service Transition are: Change ManagementService Asset and Configuration ManagementRelease Management
Most IT organizations recognize the …

A systems engineer recently asked “With all of the buzz
around Agile and DevOps, is ITIL Foundation training and certification still
relevant?” The short answer is yes and
its relevance is directly tied to the success of strategic initiatives and the
outcomes of the organization. There is
direct benefit to the learner/candidate also.
It has been a while since this has been discussed so let’s revisit this
once again. For the Consultant or
Third Party Vendor: Gets you on the short list! - ITIL Foundation training gives those who are
consulting in any area of “Service Management” a standard set of vocabulary
critical to communication. Also, knowing
the terms and basic concepts is crucial to the credibility of the
consultant. The improper use of a single
term that is known by your customer could give the impression that you as the
consultant do not know the industry and omit you from the short list. Some organizations will not even consider a
vendor without the proper certificatio…

Stuart Rance wrote in a
blog “Knowledge only has value when it is available to someone, either
because they remember it or because they are guided towards it at the time they
need it”. One of the key elements in support of CSI is Knowledge
Management. An organization must continually gather knowledge about its
services and support processes in order to look for trends, find improvement
opportunities and develop strategies that will move them into the future.
The philosopher and essayist George Santayana wrote, “Those that cannot
remember the past are doomed to repeat it”. In today’s reality of
increased rates of change, increased employee turnover, increased access to
information and greater market completion it is ever more critical to build
meaningful knowledge bases that allow an organization can create and capture
value by insuring that data, information, knowledge and wisdom are being
brought forward to benefit how and what the ITSM organization does to support
business outcomes…

As the current IT organization has grown from a provider of
technology to the Service Provider of choice we have had to incorporate the
principles of service management to ensure that we deliver the outcomes
required by our customers. Given that,
we have to ask ourselves a couple of strategic questions: What outcomes are we trying to
provide?How do we as a service provider
facilitate that?
Delivering an outcome based definition of services will
allow the IT organization to move beyond just business / IT alignment to
towards business / IT integration, which really should have been the goal from
the beginning. Supporting customer /
business outcomes should be the ultimate focus of the IT organization thus
creating value through the delivery of services.
A focus on business outcomes is both a critical and in most
cases a cultural shift for IT service providers. As customer’s preferences and perceptions
change over time so does the value statement that a service provider needs to
remai…

What
is hurting the capability of service providers to design and deliver service at
the rate of speed and at a cost that is viable to the business? I asked a group of IT managers and
practitioners in a recent training class and all agreed on these common causes: Lack of upper management strategy and
direction.Lack ofadequate or accurate informationResistance to changeCultural issues / Agenda’sInadequate fundingI
am sure you can add to this list.Many
service providers are suffering from the same pain.What is causing this?One area that most will agree upon is the
fact that a lot of challenges for a service provider to deliver come from silos.A classic silo and division that some
organizations are addressing are those that exist between development and
operational teams. That will help, but it’s not only siloed teams that are hurting
this industry.It is the fact that ITSM
processes are also siloed.If your
processes and data are siloed even the best of intentions will not result in
the t…

From an
operational perspective, we are primarily interested in the overall management
of applications as part of IT services.
These can be developed in-house or purchased off the self from third
party developers. Because of our operational point of view, and the focus on
ensuring these services/applications are delivered with both utility and
warranty, we look at their support from a more holistic approach and use what
is referred to as the “Application Management Lifecycle”. It sequences through
six stages or steps which are: Requirements, Design, Build, Deploy, Operate and
Optimize. Requirements: Requirements for new applications are garnered,
based on business/customer needs and takes place primarily during services
design. There are six types of
requirements for any application Functional requirementsManageability requirementsUsability requirementsArchitectural requirementsInterface requirementsService Level requirementsDesign: At this point
the requirements get transformed in…

About two years ago I wrote a blog on the four “Ps” of
Service Strategy. Today we going to
expand on Perspective, the 1st of the four “Ps” of Service Strategy. Perspective is the vision and direction for the services you will provide, and is realized
through conversations with your stakeholders.
A well-defined vision and mission statement allows a common goal to be
pursued by both the business and IT. This enhances the organizations ability to
focus on the customer perspective and the business outcomes that the customer
desires, and to implement a continual service improvement approach so that you
are regularly enhancing and differentiating the services you provide. In this
way the business stays relevant to the changing business environment. The perspective describes
what the organization is, what it does, who it does it for, how it works and
enables this to be communicated easily to both internal and external
stakeholders. It defines the overall
direction for the organization a…

The
NYSE reportedly told floor traders the exchange had to suspend trading due to
an error with a systems upgrade that was rolled out before the market opened. Early in the morning the NYSE sent out a
message alerting traders that there was a reported issue with a number of the
exchange’s gateways. It appears that
performance degraded from there and a few short hours later trading halted! ( http://fortune.com/2015/07/08/nyse-halt/for
full story) How
does this happen? Other issues reported
that same week included United Airlines who closed all flight bookings due to
what was labeled a “Router” issue.
Microsoft GoToTraining impacted several business owners and customers
due to a suspected “Citrix” upgrade. If
ever a case for why do we need Service Management processes that are aligned
with business outcomes can be made, one only needs to listen to the news. Just yesterday a computer system outage disrupted Spirit Airlines
flights at Chicago O'Hare, forcing the carrier to canc…

If you are in the position of providing IT services to
customers then you know the importance of the statement: Utility plus Warranty
equals Value (U+W=V). So when we talk
about value, we must consider who determines that value and what are the components
that go into making up the agreements that will define how value gets created
and delivered. The value of a service is
normally defined as “the level of service that meets customer expectations” and
is often measured by how much the customer is willing to pay for the service.
An industry trend today that may have been excluded in the past is the ability
of the service provider to be able to define and document the costs involved in
providing that service beyond its core value.
Services being intangible and unlike products do not have
much inherent value. This value does not
get realized until the service is actually utilized and enables someone to
create the desired business outcome, which means that the provider of the
service d…

ITSM Best Practice will align five main process with the
lifecycle of “Service Operation”. Incident ManagementProblem ManagementEvent ManagementRequest FulfillmentAccess Management
It was not too long
ago that the idea of some of these processes were new to service providers. Most
will find them to be common in today’s market place. An organization may not literally follow the
best practices for the service operation processes but most likely have some
close facsimile when executing Incident, Problem, Request Fulfilment, and Event
management processes for provisioning IT services and support. In order to ensure identity management and
authorization for access, some form of “Access Management” will also be needed
to support an overall security policy in Service Operation. I would like to focus on some thoughts for
“Event Management” and early engagement of operational staff in the service
lifecycle.
As organizations mature they begin to realize the value of
taking these process ac…