The Case for Simplicity in ITSM

# The Case for Simplicity in ITSM

I have spent the better part of 25 years watching organisations build elaborate service management machinery, and I have noticed something rather consistent: nobody ever sets out to create something complicated. Complexity is not a decision. It is a residue. It accumulates one well-intentioned exception at a time, until the process that was meant to help people now requires a process to explain it. In my opinion, the most underrated skill in ITSM is the willingness to do something simple and then resist the urge to improve it into something nobody understands.

## **Why Complexity Wins by Default**
### *The path of least resistance leads somewhere expensive*

Every workflow I have inherited started life as a sensible idea. The trouble is that sensible ideas compound. Someone asks for an extra approval, someone else wants a custom field, and a third party insists their team needs a separate queue. Each request is individually reasonable and collectively ruinous.

- **Additions feel safe, removals feel risky** — adding a step rarely gets challenged, whilst removing one invites the question "but what if we need it?"
- **Complexity is rarely measured** — we track incident volumes and SLA breaches, but almost nobody tracks how many clicks it takes to log a request properly.
- **Ownership fragments over time** — the person who understood why a step existed has long since left, so the step survives out of sheer institutional politeness.

My experience has been that complexity does not arrive as a flood. It arrives as a slow drip, and by the time you notice the puddle, the carpet is ruined.

## **What "Simple" Actually Means**
### *Not fewer features, but less friction*

Simple is frequently confused with basic, and the two are not the same thing at all. A simple process can be sophisticated underneath; what matters is that the person using it does not have to think about that sophistication.

- **Simple for the user, not the architect** — the cleverness should sit in the design, not in the daily experience of the person raising a ticket.
- **Predictable beats configurable** — a process that behaves the same way every time is worth more than one with forty options nobody can remember.
- **Fewer decisions at the point of use** — every choice you push onto the requester is a choice they can get wrong, and then you own the consequences.

In my opinion, the ITIL 4 guiding principle "keep it simple and practical" is the one most often quoted and least often obeyed. We nod along to it in workshops and then design a twelve-stage approval chain by lunchtime.

## **The Minimum Viable Process**
### *Start with the smallest thing that works*

I have become rather fond of the idea of a minimum viable process, borrowed shamelessly from the product world. The principle is straightforward: design the smallest process that delivers the outcome, put it into use, and only add to it when reality demands it.

- **Begin with the happy path** — design for the ninety percent of cases that are ordinary, and handle the exceptions as exceptions rather than baking them into the core.
- **Earn every step** — each stage, field, and approval must justify its existence in terms of an outcome, not a hypothetical risk.
- **Add later, with evidence** — when you genuinely need more, you will have data telling you so, rather than a nervous guess made at design time.

My preference is always to launch something slightly too simple and let the gaps reveal themselves. A process with obvious gaps gets fixed. A process drowning in pre-emptive controls just gets quietly bypassed, which is far worse because you cannot fix what people are routing around.

## **Tooling Will Not Save You**
### *A complicated process in ServiceNow is still a complicated process*

There is a persistent fantasy that the right platform will absorb complexity on your behalf. It will not. Tools like ServiceNow or JSM are extraordinarily capable, and that capability is precisely the danger. They make it effortless to build something baroque.

- **Configuration is not design** — the ability to add a field does not mean you have thought about whether the field should exist.
- **Automation amplifies whatever you give it** — automate a sound process and you get speed; automate a muddled one and you get muddle delivered at scale.
- **Every customisation is a future maintenance cost** — I am always conscious that today's clever workflow is next year's upgrade headache.

I have seen organisations spend a fortune implementing a platform and then recreate, pixel for pixel, the dreadful manual process they were trying to escape. The tool did exactly what it was told. That was the problem.

## **Accountability Keeps It Simple**
### *Clear ownership is the best defence against creep*

Simplicity is not a one-off achievement; it is a discipline you maintain. The most reliable mechanism I know for maintaining it is unambiguous accountability. When someone owns a process and is answerable for its health, they tend to defend it against unnecessary additions.

- **A clean RACI prevents drift** — when it is clear who is accountable, requests for changes go through someone with the standing to say no.
- **Review for removal, not just addition** — most process reviews only ever add. A genuinely useful review asks what can now be retired.
- **Measure the experience, not just the metrics** — an XLA that captures how the process actually feels to use will surface friction long before an SLA does.

In my opinion, a process without a named, accountable owner is a process that will become complicated. It is not a question of if, merely when, because nobody is standing at the door politely declining the next reasonable-sounding addition.

## **Where to Start**
### *Practical steps you can take this week*

If you are looking at a process that has grown unwieldy, you do not need a transformation programme to begin. You need a willingness to ask awkward questions.

- **Map the actual journey** — walk through your most common request end to end and count every step, field, and approval a real person encounters.
- **Challenge each step once** — for every step, ask what breaks if it is removed. If the answer is "nothing obvious", you have found a candidate.
- **Pilot the leaner version** — change one process, measure the before and after, and let the result make your argument for you.
- **Name an owner** — give the simplified process a custodian whose job includes keeping it simple, not merely keeping it running.

The goal is not minimalism for its own sake. The goal is a service management practice that people can use without a manual, that survives a platform upgrade without panic, and that does the job it was built to do. Simple is harder than complicated. It is also, almost always, better.

Hopefully this has been useful to you and I wish you well on your ITSM journey…

*Estimated reading time: 6 minutes*

Zero Ticket IT and Agentic AI: The End of the Ticket-Centric Model?

# Zero Ticket IT and Agentic AI: The End of the Ticket-Centric Model?

The ticket has been the atomic unit of IT service management for as long as most of us have been doing this. We measure it, route it, escalate it, breach it, close it, and reopen it when we close it too soon. So when a concept called "Zero Ticket IT" starts trending, and agentic AI is positioned as the mechanism to deliver it, I pay attention. The recognition of Resolve as a Major Contender in Everest Group's 2026 ITSM Platform PEAK Matrix on 10 June 2026 has given this conversation a focal point, and the community debate around applying agentic AI to major incident response has given it teeth. My intention here is to separate the genuinely significant shift from the marketing froth, because there is a respectable amount of both.

## **1. What "Zero Ticket IT" Actually Means**
### *Removing the ticket, not removing the work*

The phrase is unfortunate, because it implies the absence of something rather than the presence of something better. Zero Ticket IT does not mean issues stop happening. It means the conventional ticket handling workflow, with its queues and human triage and status fields, is no longer the primary vehicle for resolution.

- **The ticket becomes an artefact, not an event** — Where work is detected and resolved autonomously, the record is generated as evidence after the fact rather than as the trigger for action.
- **The operating assumption inverts** — Traditional ITSM assumes a human raises an issue and a human resolves it. Zero Ticket IT assumes a system detects an issue and a system resolves it, with humans handling the exceptions.
- **Self-service is not the same thing** — A well-designed portal still produces a ticket. The distinction here is that the resolution path never required one.

In my opinion the terminology will age badly, but the underlying idea is sound. We have spent twenty years optimising the handling of tickets when the more valuable question was always how to avoid generating them in the first place.

## **2. From Siloed Automation to Agentic Orchestration**
### *Why this is different from the automation you already have*

Most organisations already automate. Password resets, account provisioning, scripted remediations. The difference with agentic AI is the move from deterministic, single-purpose automation to autonomous, outcome-driven agents that can reason across a chain of steps without a pre-defined runbook for every permutation.

- **Deterministic automation does what you told it** — It executes a known sequence and stops when it hits something unexpected. This is reliable and limited in equal measure.
- **Agentic AI pursues an outcome** — It is given a goal, has access to tools and context, and decides the sequence itself, adapting when conditions change.
- **Orchestration is the layer that matters** — Resolve's positioning as an intelligent layer over existing tooling is the pragmatic version of this. You are not ripping out ServiceNow or your monitoring stack. You are placing an agentic layer above them.

My experience has been that the "rip and replace" pitch fails in enterprise environments every single time, so the orchestration-over-existing-tooling model is the one I would back. It respects the investment already made and reduces the political surface area of adoption, which is frequently the harder problem than the technical one.

## **3. Agentic AI in Major Incident Response**
### *The hardest test, and the most revealing*

The community debate has gravitated towards major incidents, and rightly so. If agentic AI can hold up under a P1, it can hold up anywhere. If it cannot, we learn exactly where the boundaries sit.

- **Detection and correlation are the obvious wins** — Pulling together signals from disparate monitoring tools and forming a coherent picture faster than a human bridge call ever could. This is genuinely valuable and reasonably low risk.
- **Autonomous remediation is where nerves fray** — Granting an agent the authority to restart services, reroute traffic or roll back deployments during a live incident is a different proposition entirely, and the blast radius of a wrong decision is considerable.
- **The communication burden is underrated** — A meaningful proportion of major incident effort is keeping stakeholders informed. Agentic drafting of status updates, with human approval, is a sensible early use case that nobody seems excited about because it is not glamorous.

I am always conscious that major incidents are precisely the moment when trust in automation is lowest and scrutiny is highest. In my opinion the right model is human-in-the-loop for any action with material blast radius, and full autonomy reserved for diagnosis, correlation and the dull mechanical work. Anyone selling you autonomous P1 remediation with no human gate is selling you a future incident review.

## **4. What This Does to ITIL and the Operating Model**
### *Practices do not disappear, they relocate*

There is a temptation to declare ITIL obsolete every time something new arrives. This is lazy and usually wrong. ITIL 4 is a set of practices and a value system, not a mandate to handle everything as a ticket.

- **Incident management as a practice survives** — The capability to restore service still matters. What changes is who, or what, executes it and how the record is created.
- **Change enablement becomes more important, not less** — If agents are taking autonomous action, the governance around what they are permitted to do is a change concern. Your guardrails are your change policy.
- **The RACI needs rewriting** — When an agent is Responsible for resolution, who is Accountable? That question does not have a comfortable answer yet, and pretending otherwise is unwise.

My preference is to treat the agentic layer as a new type of actor within existing practices rather than as a replacement for the practices themselves. ITIL 4's guiding principles, particularly "start where you are" and "keep it simple and practical", remain entirely applicable. The framework was never the problem. The dogmatic, ticket-for-everything interpretation of it was.

## **5. The Metrics Problem Nobody Wants to Discuss**
### *You cannot measure what you have stopped recording*

Here is the awkward part. A great deal of ITSM measurement is built on ticket volume, mean time to resolve, first contact resolution and similar. If you remove the ticket, you remove the data those metrics depend on.

- **Volume metrics become misleading** — A falling ticket count could mean improved service or it could mean your agentic layer is silently resolving things you can no longer see. Without instrumentation you cannot tell the difference.
- **XLAs become more relevant than SLAs** — Experience-level agreements, focused on outcomes and perceived value rather than ticket timestamps, are far better suited to a world where the ticket is no longer the unit of work.
- **You must instrument the agents themselves** — If an agent resolves something autonomously, that action needs to be logged, auditable and measurable, or you have traded a visible queue for an invisible one.

In my opinion this is the area most organisations will underinvest in, because it is unglamorous and nobody gets promoted for building good observability. The result will be a wave of "we don't get tickets any more" claims that translate, on inspection, to "we stopped looking".

## **6. Where to Start**
### *Practical advice over hype*

If you want to engage with this seriously rather than performatively, there is a sensible order of operations.

- **Map your highest-volume, lowest-risk repetitive work first** — This is where agentic resolution earns trust cheaply. Prove the model on the boring stuff before going near a P1.
- **Define your guardrails as change policy from day one** — Decide explicitly what an agent may do autonomously and what requires a human gate, and treat that boundary as a governed artefact.
- **Instrument before you automate** — Build the logging and observability that lets you measure agentic actions before you let agents take them, not after.
- **Pilot the orchestration layer over what you already own** — Resist the urge to replace your platform. The intelligent-layer approach lets you realise value without a multi-year migration programme.
- **Rewrite your RACI honestly** — Work out who is accountable when an agent acts, before an incident review forces you to.

My experience has been that the organisations who succeed with new capability are the ones who treat it as an evolution of their operating model rather than a revolution against it. Zero Ticket IT, stripped of its slightly breathless branding, is a genuine and overdue shift. The ticket-centric model was always a means to an end, and we forgot that somewhere along the way. Agentic AI is a useful reminder.

Hopefully this has been useful to you and I wish you well on your ITSM journey…

*Estimated reading time: 8 minutes*

A Day in the Life of an IT Service Architect

# The Daily Grind of an IT Service Architect

## *What it really looks like behind the diagrams*

The role of IT Service Architect is one of those jobs that sounds fun on a LinkedIn profile and feels considerably less fun on a Tuesday morning at 09:47 when three people are asking you three different questions about the same Service Design Document. It sits at the intersection of strategy, delivery, governance and politics — and on any given day you may be wearing all four hats before lunch.

This post is a candid look at what the daily grind actually involves, the rhythm of the work, the small habits that keep me sane whilst doing it — and the deliberate space I carve out every day to think about innovation, because without it, the grind quietly becomes the ceiling.

---

## 1. **The Morning Triage**

Every day starts with what I think of as triage — not of incidents, but of attention.

* **Inbox sweep:** Overnight emails from offshore delivery teams, client stakeholders in different time zones, and the occasional 04:00 escalation that someone else has already (mercifully) handled.
* **Diary check:** Working out which meetings genuinely need me versus which I can decline, delegate, or contribute to asynchronously.
* **Priority reset:** Reviewing the action log from yesterday and deciding what *must* move today versus what is simply noisy.

In my opinion, the single most underrated skill in this role is the discipline to *not* react to everything immediately. Architects who answer every Teams ping within thirty seconds end up architecting nothing. The morning triage is where you reclaim the day before it reclaims you.

---

## 2. **Living in the Service Design Document**

If you are a Service Architect on an EUS or wider ITSM engagement, the Service Design Document (SDD) is your home address. You will live in it. You will dream about it. You will absolutely find a missing semicolon in the SLA matrix on a Sunday evening.

A typical day involves:

* **Drafting or revising sections** — process narratives, RACI matrices, toolset diagrams, RAID entries.
* **Chasing inputs** from SMEs who owe you a paragraph on Problem Management and have owed it to you for nine days.
* **Reconciling contradictions** between what the bid said, what the client expects, and what the operations team can actually deliver.
* **Version control hygiene** — because nothing destroys credibility faster than two versions of the same document circulating with conflicting SLAs.

The SDD is never "finished." It is baselined, then it evolves. A good architect treats it as a living artefact rather than a one-off deliverable.

---

## 3. **Meetings, Workshops, and the Art of the Whiteboard**

A meaningful chunk of the day is spent in conversation. Not status meetings (those should be killed wherever possible) but genuinely productive sessions:

* **Discovery workshops** with the client to understand current-state pain points.
* **Design reviews** with internal architects, transition managers, and service owners.
* **Stakeholder alignment** with commercial, legal, and delivery leads.
* **Whiteboarding** — still, in 2026, the fastest way to align five people on a service flow.

My preference is to keep workshops short, outcome-driven, and ruthlessly facilitated. A two-hour workshop with no agenda is a confession that nobody knew what they wanted out of it. A 45-minute session with three explicit decisions to make is worth its weight in gold.

---

## 4. **The Tooling Tax**

Service Architects pay what I call the *tooling tax* — the cumulative cognitive overhead of operating across half a dozen platforms simultaneously. On any given day you might touch:

* **ITSM platform** (ServiceNow, Jira Service Management, BMC Helix) for process modelling and workflow design.
* **CMDB** for understanding the configuration baseline you are designing services around.
* **Diagramming tools** (Lucidchart, Visio, Miro) for high-level service architecture and process flows.
* **Office suite** for the ever-present Word, Excel and PowerPoint trinity.
* **Collaboration tools** (Teams, Slack, Confluence) where decisions actually happen.
* **Increasingly, AI assistants** for accelerating drafting, gap analysis, and reviewing dense vendor documentation.

I am always conscious that tools should serve the work, not the other way round. When you find yourself spending more time formatting a diagram than designing the service it represents, something has gone wrong.

---

## 5. **The Quiet Technical Work**

Underneath the meetings and the documents, there is the actual *thinking*. This is the part of the role that nobody schedules for you and that you must protect ferociously.

This is where you:

* Map the end-to-end service against ITIL® practices and identify the genuine gaps.
* Pressure-test the SLA matrix to ensure the priority definitions actually align with business impact.
* Design the reporting catalogue so it tells a story rather than dumping numbers.
* Think about transition risk — what could go wrong at go-live, and what mitigations need to be in place.
* Consider the *experience* layer — what does this look like for the end user on day one?

Without protected thinking time, you become a glorified document scribe. With it, you become an architect.

---

## 6. **Making Time for Innovation**

Here is the section I almost did not include, because it is the one most likely to be quietly skipped on a busy day. But it is, genuinely, the difference between an architect who is *useful* and an architect who is *valuable*.

Every single day, I block out 30 minutes — sometimes an hour if the calendar allows — to deliberately think about innovation and new ways of working. Not delivery. Not the SDD. Not the action log. Just: *how could this be done better?*

That time gets spent on things like:

* **Reading something outside my immediate remit** — a vendor whitepaper, a thoughtful LinkedIn post, an analyst note on emerging service models.
* **Experimenting with AI assistants** to see whether they can take a genuine bite out of repetitive drafting, gap analysis, or document review work.
* **Sketching a "what if" diagram** — what would this service look like if we removed L2 entirely? If self-service genuinely worked? If we measured experience instead of throughput?
* **Talking to peers** outside my current engagement to find out what they are seeing in their corner of the industry.
* **Challenging an assumption** in the current design — usually something that has been carried forward from a previous engagement and never properly re-examined.

In my opinion, this is the single most important habit a Service Architect can build. Delivery work expands to fill the time available, and if you do not actively defend space for innovation thinking, it simply will not happen. You will deliver competently for years and never produce anything genuinely new.

The tricky part is that this time is invisible to most of your stakeholders. Nobody is going to thank you for spending half an hour thinking about whether XLAs could replace half your SLA matrix. But six months later, when you propose a service model that the competition has not thought of, that is where the time was paid back — with interest.

My rule of thumb: if a week goes by and I have not had at least one "I wonder if…" thought worth writing down, I have been too operational and not enough architect.

---

## 7. **The Inevitable Curveball**

Every day has at least one. A change in scope. A vendor pulling out. A client suddenly insisting on 24x7 coverage when the commercial model assumed 8x5. An OEM update that invalidates a tooling assumption you made two weeks ago.

Curveballs are the job, not an interruption to it. A useful mental model is to assume that roughly **20% of any given day will be reactive**. If you plan your calendar at 100% capacity, that 20% will eat your evenings. If you plan it at 80%, you absorb the curveball and still finish on time.

---

## 8. **End-of-Day Wind-Down**

The final 20 minutes of the day are, for me, the most valuable. I use them to:

* **Update the action log** so tomorrow's triage is faster.
* **Write a brief note** to my future self about where I left off on whichever section of the SDD I was wrestling with.
* **Send the one outstanding email** I have been procrastinating on (there is always one).
* **Close the laptop properly** — not with a vague intention to "just check one more thing in an hour."

This last point matters. The job is largely cognitive, and cognitive work needs recovery time. Architects who burn out tend to do so quietly and then suddenly.

---

## Final Thoughts

The daily grind of an IT Service Architect is not glamorous, but it is genuinely interesting work. You are translating ambiguity into clarity, drawing the lines that operations teams will live by for years, and quietly shaping how thousands of end users experience their working day.

It rewards patience, structure, and a willingness to keep refining the same diagram until it actually says what it needs to say. It punishes shortcuts, vague thinking, and the temptation to mistake activity for progress. And it quietly rewards the architects who protect a small slice of every day for asking *"is there a better way to do this?"* — because that is where the next generation of services gets designed.

If you are considering the role, or if you are already in it and wondering whether everyone else's days look like yours — they probably do. The grind is real, but so is the craft.

> *Hopefully this has been useful to you and I wish you well on your ITSM journey…*

ITSM and AI Governance: A Partnership Whose Time Has Come

# ITSM and AI Governance: A Partnership Whose Time Has Come

## Why IT Service Management is Becoming the Backbone of Responsible AI Adoption

The rise of AI within enterprise environments is no longer a distant prospect — it is happening now, across industries, at pace. Organisations are deploying AI-powered tools for everything from intelligent incident triage to predictive change risk analysis. Yet, for all the enthusiasm, a quieter and arguably more important conversation is beginning to emerge: *who is responsible when AI goes wrong, and how do we ensure it behaves the way we intend?* In my view, the answer increasingly points to ITSM — and the two disciplines are becoming more intertwined by the day.

---

## 1. **What Is AI Governance, and Why Should ITSM Teams Care?**

AI governance refers to the frameworks, policies, and controls that ensure AI systems operate safely, transparently, and in alignment with organisational objectives and ethical standards. It covers areas such as:

* **Accountability** — who owns an AI decision or outcome?
* **Transparency** — can the AI's reasoning be explained and audited?
* **Risk management** — how do we identify and mitigate AI-related failures?
* **Compliance** — are we meeting regulatory requirements (e.g., the EU AI Act)?
* **Continuous oversight** — how do we monitor AI behaviour post-deployment?

If you read that list and thought it sounded rather familiar, you would not be wrong. These are the same foundational concerns that ITSM has been addressing for services and systems for decades. That is precisely why ITSM teams should be paying very close attention.

---

## 2. **The Convergence: Where ITSM Meets AI Governance**

ITIL® 4 has already laid the groundwork here. Its service value system and guiding principles — particularly *"progress iteratively with feedback"* and *"keep it simple and practical"* — translate remarkably well into the continuous, feedback-driven nature of AI governance.

Here is where the overlap becomes tangible:

### Change Management
AI models are updated, retrained, and versioned. Without a structured change process, an update to a machine learning model can introduce regression, bias, or unpredictable behaviour into production. ITSM's Change Management practices — including risk assessment, approval workflows, and post-implementation review — are a natural fit for governing AI model changes.

### Incident and Problem Management
When an AI system produces an incorrect recommendation or fails outright, it needs to be treated like any other service failure. ITSM's Incident Management process provides the triage, escalation, and resolution structure. Problem Management, meanwhile, can be used to investigate root causes — whether that is data quality issues, model drift, or integration failures.

### Configuration Management
AI systems have dependencies: training data sets, model versions, APIs, and integration points. A well-maintained CMDB that includes AI components as Configuration Items (CIs) gives organisations the visibility they need to understand what is deployed, where, and how it connects to broader services.

### Service Level and Experience Management
AI tools used by employees or customers should be subject to the same performance expectations as any other service. SLAs and XLAs can be extended to cover AI-powered interactions — measuring not just availability, but accuracy, relevance, and user trust.

---

## 3. **The Regulatory Dimension**

It would be remiss to discuss AI governance without acknowledging the regulatory landscape. The EU AI Act, which began applying provisions in 2024 and beyond, classifies AI systems by risk level and imposes obligations accordingly. High-risk AI systems — those used in HR decisions, infrastructure management, or critical service delivery — face particularly stringent requirements around transparency, human oversight, and audit trails.

ITSM organisations are already well-versed in audit trails and evidence management. Service desk platforms, CMDB records, and change logs are precisely the kinds of artefacts that regulators will want to see. The challenge is ensuring these artefacts are being applied intentionally to AI systems, not just traditional IT services.

In my opinion, organisations that fail to integrate their ITSM practices with their AI governance strategy are effectively running two parallel risk management regimes — and that is an inefficiency that will eventually surface in a compliance gap or a very public failure.

---

## 4. **Practical Steps for ITSM Teams**

So how does an ITSM team begin bridging this gap? Here is a pragmatic starting point:

* **Inventory your AI services** — treat every AI tool in use (internal or third-party) as a managed service. Add it to your CMDB with clear ownership and dependency mapping.
* **Extend your change process** — ensure that AI model updates, retraining events, and prompt engineering changes go through formal change assessment. Even low-risk changes benefit from a lightweight review.
* **Define AI-specific incident categories** — create incident types for AI-related failures such as hallucinations, biased outputs, or unexpected behaviour. This enables trend analysis over time.
* **Establish an AI service owner** — governance without accountability is theatre. Assign clear ownership for each AI service, aligned to your existing service ownership model.
* **Build AI clauses into your SLAs** — work with service owners and business stakeholders to define what "good" looks like for AI-powered services, and hold them to it.
* **Educate your service desk teams** — frontline staff need to understand how to recognise, log, and escalate AI-related issues. This is a training and awareness challenge as much as a process one.

---

## 5. **The Human Element**

There is a dimension to AI governance that no framework alone can address: trust. Employees and customers need to trust that AI systems are being deployed responsibly. That trust is built — and sometimes lost — through the everyday interactions people have with IT-supported services.

The service desk is often the first point of contact when something goes wrong with an AI tool. How that interaction is handled — whether the person feels heard, whether the issue is resolved promptly, whether there is transparency about what happened — matters enormously. ITSM has always been as much about people as it has been about process and technology. That human-centred approach is just as vital in an AI governance context.

---

## Conclusion

The relationship between ITSM and AI governance is not merely a convenient overlap — it is a strategic necessity. As organisations accelerate their AI adoption, the disciplines of service management provide a ready-made structure for ensuring that AI systems are deployed, managed, and governed responsibly. The frameworks are there. The processes are there. What is needed now is the deliberate application of both to the AI services proliferating across our organisations.

Embracing AI governance through an ITSM lens is not just good practice — it is how responsible, resilient organisations will differentiate themselves in the years ahead.

> *Hopefully this has been useful to you and I wish you well on your ITSM journey…*

---

*Tagged: ITSM, AI Governance, ITIL® 4, Artificial Intelligence, Service Management, EU AI Act*

Multi-Agent Capital System

# Building a Survival-First Multi-Agent Capital System

*How I designed a fleet of specialised AI agents governed by hard mathematical constraints — and why “don’t die” beats “grow fast” every time.*

-----

## The Problem With Most AI Agent Systems

Most multi-agent architectures are built around capability: what can each agent *do*? I built mine around a different question — what can each agent *spend*, and what happens if it’s wrong?

When you’re deploying autonomous agents against real capital, optimism is a bug. An agent that confidently recommends scaling spend based on five data points isn’t being helpful; it’s being dangerous. I needed a system where the architecture itself enforced epistemic humility, not just the prompts.

This is the story of how I built the MCP (Multi-Agent Capital Protocol) system — a fleet of seven specialised agents governed by a single inviolable principle: **survival dominates all upside considerations.**

-----

## The Architecture: A Fleet With a Constitution

The system is made up of seven agents, each with a tightly scoped role, a defined capital authority, and a set of hard prohibitions. No agent operates in isolation. Every allocation decision flows through a central governance layer before it touches real capital.

Here’s how the fleet breaks down:

### 🔭 Opportunity Discovery Agent

The ideation engine. It generates hypotheses and scans for opportunities — but critically, it has **zero capital authority**. Its only job is to produce falsifiable ideas with qualitative rationale and rough demand estimates. By capping its Information Quality Score (IQS) at 0.4, I’m formally acknowledging that raw hypotheses are low-confidence by definition. An agent that can’t spend money can’t cause financial harm by being over-optimistic.

### ✅ Validation Agent

Before a hypothesis becomes a commitment, it gets tested. The Validation Agent runs rapid falsification experiments with a hard ceiling of **£150 per test** and a maximum of three tests running in parallel. I require pass/fail metrics to be defined before a test begins — not after — and results must land within 72 hours. If more than half the tests fail, the budget is automatically halved. The IQS cap only lifts to 1.0 after real transactions are on the board.

### 🎯 Offer Engineering Agent

Once demand is validated, the Offer Engineering Agent translates signals into concrete offers: exact pricing, sales mechanism, and positioning. Crucially, it has **no capital authority at all** — it cannot run ads, cannot purchase tooling, and cannot assume conversion uplift without validation data backing it up. I designed it as a pure design function, nothing more.

### 📣 Distribution Growth Agent

Customer acquisition and channel execution. This agent can spend, but within tight guardrails I set deliberately: a maximum of 20% of remaining capital and a daily spend cap of £50. Every proposal must specify channel, volume, and CAC assumptions upfront. If cost-per-acquisition worsens across the majority of simulation runs, spend is automatically cut by 50%. I made speculative scaling an explicit prohibition — not a guideline, a prohibition.

### ⚙️ Automation Ops Agent

This agent removes human bottlenecks and reduces execution cost. Any automation it proposes must break even within 14 days, and its capital draw is capped at 10% of remaining funds. I set the IQS cap conservatively at 0.6 unless the automation is already directly linked to revenue — I’m not interested in building infrastructure for a future that hasn’t arrived yet.

### 🛡️ Risk Reality Check Agent

My favourite part of the system. This is an adversarial governance agent with veto power over any allocation exceeding 10% of capital. It can downgrade the IQS of any other agent, flag over-optimistic assumptions, and surface legal, financial, and execution risks. It cannot allocate capital itself — its power is purely preventative. I measure its success not by revenue generated, but by **capital-destructive decisions prevented**.

### 🧮 Controller Agent

The authoritative brain of the whole system. The Controller owns and mutates the global capital state, runs all Monte Carlo simulations, computes Kelly fractions, and enforces kill switches. It has the final say on every allocation — and I deliberately made that authority non-delegable. The system invalidates itself if the capital survival probability (`P_survive`) drops below 70%, or if the probability of total wipe-out (`P_wipe`) exceeds 10%.

-----

## The Design Principles That Shaped Everything

### 1. Separation of Ideation From Execution

The Opportunity Discovery Agent can dream freely precisely *because* it cannot spend. The Validation Agent can run experiments precisely *because* it cannot scale. Separating the permission to imagine from the permission to act creates a natural firewall against wishful thinking propagating into capital decisions.

### 2. IQS as a Formal Confidence Register

The Information Quality Score isn’t a vibe check — it’s a hard gate. Every agent has an IQS ceiling that reflects how much real-world evidence backs its claims. An agent working from hypotheses alone is capped at 0.4. One that has seen real transactions can reach 1.0. This means the system automatically demands more proof before granting more authority.

### 3. Survival as the North Star

The Controller’s governing invariant is stark: *survival dominates all upside considerations.* This isn’t pessimism — it’s the mathematically correct response to operating under genuine uncertainty. Kelly criterion theory tells us that overbetting destroys compounding returns even when the underlying edge is real. The MCP system encodes this at the architectural level.

### 4. Adversarial Governance by Design

The Risk Reality Check Agent exists to be the voice of doubt. In most organisations, the person who raises concerns is swimming against cultural current. Here, that voice has structural veto power. Building in adversarial governance means the system gets robustly stress-tested without relying on any individual’s courage to speak up.

### 5. Hard Constraints Beat Soft Guidelines

Every agent contract specifies not just what an agent *should* do, but what it *cannot* do. Prohibitions are explicit: no speculative scaling, no spend without validated demand, no grandfathered allocations, no delegation of final approval. Soft guidelines get eroded under pressure. Hard prohibitions don’t.

-----

## What We Learned

The most counterintuitive lesson from building this system is that **constraint is a feature, not a limitation.** Agents with tightly bounded authority are faster to reason about, safer to deploy, and easier to audit when something goes wrong. The system’s conservatism in early stages (low IQS caps, small spend limits, mandatory break-even windows) is precisely what creates the evidence base needed to act more boldly later.

We also learned that versioning agent contracts matters. Each contract carries an explicit changelog — even when the version increment has no semantic changes, the discipline of versioning creates accountability and makes it possible to trace exactly when the system’s behaviour changed and why.

The MCP system is not finished. It’s designed to be iterated on as the evidence base grows, IQS ratings update, and capital state changes. That’s the point: a governance architecture that evolves with its own track record, always anchored to the one constraint that can’t be negotiated away.

Don’t die first. Everything else is upside.

-----

*This post describes the v1.1 agent contract architecture. All capital authority figures and IQS thresholds reflect current system configuration.*

Release and Deployment Management in the Age of Vibe Coding

# Release and Deployment Management in the Age of Vibe Coding
## Why Your Release Pipeline Needs to Grow Up — Fast

The way software gets written is changing faster than most IT organisations are prepared to handle. Vibe coding — the practice of describing what you want in natural language and letting an AI model generate the code — has moved from a novelty to a genuine productivity multiplier in the space of just a couple of years. Developers are shipping features in hours that would previously have taken days. Non-developers are building functional tooling without ever learning a programming language. It is, frankly, remarkable.

But here is the problem nobody is talking about loudly enough: **your release and deployment management processes were not designed for this.**

ITIL® has long told us that Release Management is about planning, scheduling, and controlling the movement of releases into test and live environments. Deployment Management is about physically getting those releases where they need to be. Both practices assume a degree of deliberate, human-authored change — code that someone has read, understood, reviewed, and signed off. Vibe coding challenges every single one of those assumptions.

So let's look at what needs to evolve, and how.

---

## 1. **The Vibe Coding Reality Check**

Before we talk about process, it is worth being honest about what vibe coding actually produces.

* **Speed without comprehension**: A developer can generate a working microservice in minutes without necessarily understanding every line of what has been produced. The code works — until it doesn't.
* **Inconsistent quality**: AI-generated code varies enormously depending on the prompt, the model, and the context provided. Two developers asking for "the same thing" can get meaningfully different implementations.
* **Opaque dependencies**: AI tools will happily pull in libraries, frameworks, and patterns that your organisation may not have approved, tested, or even licensed.
* **Volume amplification**: If your team used to raise ten change requests a sprint, they may now raise fifty. Your CAB was not built for that cadence.

In my opinion, the biggest risk isn't that vibe coding produces bad code — it's that it produces *unreviewed* code at *reviewed* velocity. That gap is where incidents are born.

---

## 2. **Rethinking the Release Unit**

Traditionally, a release is a discrete, versioned bundle of changes. You build it, test it, approve it, deploy it. Clean and understandable.

Vibe coding disrupts this model because the unit of work has shifted. Developers are making micro-changes constantly — iterating with AI assistance in rapid cycles that don't map neatly to a two-week release cadence. Trying to force that into a traditional release package is like trying to fill a bath with a fire hose and a plug that doesn't quite fit.

Release Management will need to adapt in several ways:

* **Shift from release-level to change-level governance**: Rather than reviewing a bundle of changes at the end of a sprint, organisations need tooling and processes that can evaluate individual changes in near real-time — flagging risk, checking compliance, and routing appropriately.
* **Risk-tiering by source**: AI-generated code should, at least initially, attract a higher scrutiny tier than human-authored changes. This isn't a slight on the tools — it's prudent risk management until your organisation builds confidence in the patterns being produced.
* **Automated release notes**: If your teams are generating code at speed, they certainly aren't going to hand-write release documentation. AI-assisted release note generation — pulling from commit messages, ticket metadata, and diff analysis — will become a necessity rather than a nice-to-have.

---

## 3. **The Change Approval Problem**

Let's talk about the CAB. Or, more specifically, let's talk about why the traditional Change Advisory Board model will buckle under vibe coding pressure.

A CAB that meets weekly to review a scheduled list of normal changes was already feeling the strain in a DevOps world. In a vibe coding world, where a single motivated developer can generate and test a dozen deployable changes in an afternoon, that model simply doesn't scale.

Here's how I think this needs to evolve:

* **Intelligent pre-approval via policy-as-code**: Define your change acceptance criteria in code — blast radius, affected services, dependency risk, test coverage — and automate the approval gate. Low-risk, well-tested, AI-generated changes that meet the policy threshold get approved without human review. Everything else gets flagged.
* **AI-assisted impact assessment**: Use AI (yes, genuinely — fight fire with fire) to analyse proposed deployments against your CMDB and dependency map. Surface potential conflicts before the deployment window, not after.
* **Human review for novel patterns**: Where AI tooling generates code using libraries, frameworks, or architectural patterns not previously seen in your estate, that is your trigger for human review. The CAB's job becomes curating exceptions, not rubber-stamping the routine.

My preference when advising on this is to treat the CAB as a risk escalation body, not a release approval factory. That shift in mindset matters enormously.

---

## 4. **Testing, Validation, and the Trust Problem**

One of the quiet assumptions behind most deployment pipelines is that the developer who wrote the code also has a reasonable mental model of what it does. They can review a diff, spot an anomaly, and raise a flag. With vibe coding, that assumption weakens considerably.

This creates what I'd call the **trust problem**: you are deploying code that may have been generated, iterated, and committed without anyone truly understanding its behaviour at a line level. Your test suite — if it exists — becomes the primary safety net rather than a secondary one.

This means:

* **Test coverage gates become non-negotiable**: Organisations that have treated test coverage targets as aspirational will need to enforce them as hard deployment gates. No tests, no deployment. Full stop.
* **Behavioural testing over structural testing**: It matters less that the code looks right and more that it behaves correctly. Shift investment toward integration tests, contract tests, and end-to-end scenario coverage.
* **Canary and progressive deployment as standard**: Rather than deploying to 100% of users and hoping for the best, progressive rollout strategies — canary releases, feature flags, traffic splitting — should become the default posture for AI-generated changes. This limits blast radius and gives your observability tooling time to catch anomalies before they become incidents.

---

## 5. **Observability Is Now a Release Discipline**

Historically, observability — logging, tracing, alerting — has sat firmly in the Operations camp. Release Management worried about getting the code out; Operations worried about what happened next.

That separation doesn't serve organisations well in a vibe coding world. If you are deploying more frequently, with less human comprehension of the code in flight, you need your observability posture to be part of the release definition — not bolted on afterwards.

Practically, this means:

* **Deployment markers in your observability platform**: Every release should automatically inject a marker into your monitoring dashboards. When something breaks, you should be able to correlate it to a specific deployment within seconds.
* **Automated rollback triggers**: Define the conditions under which a deployment should automatically roll back — error rate thresholds, latency spikes, health check failures — and make those triggers part of your deployment pipeline configuration, not a manual oncall decision.
* **AI-assisted anomaly detection post-deployment**: Your observability platform should be working as hard as your code generation tool. Use AI-powered anomaly detection to identify unusual patterns in the minutes following a deployment, before users start raising tickets.

---

## 6. **Governance, Compliance, and the Audit Trail**

For organisations operating in regulated industries — financial services, healthcare, government — the vibe coding era introduces a genuinely thorny governance challenge. Regulators want to know who wrote the code, when, why, and what review it received. "A language model generated it and it looked fine" is not, currently, an acceptable audit response.

This is an area where Release Management has a real opportunity to add value:

* **Provenance tracking**: Tooling is emerging that tags AI-generated code at the point of creation, maintaining a clear lineage through to deployment. Organisations should be actively evaluating and adopting this capability now, before it becomes a regulatory requirement.
* **Documented review steps**: Even if a human didn't write every line, a human should be signing off on the release. Make that sign-off explicit, documented, and traceable — not an implicit assumption buried in a Git merge.
* **Policy libraries for AI tooling**: Define, document, and enforce which AI coding tools are approved for use, under what conditions, and with what constraints. Your Information Security and Architecture functions should be involved in this — it is a platform governance question as much as a release one.

---

## Conclusion

Vibe coding is not a passing trend. It is a fundamental shift in how software gets created, and it is accelerating. Release and Deployment Management practices that were designed for a world of deliberate, human-authored change will need to evolve — not eventually, but now.

The good news is that the principles underpinning good release governance haven't changed: control risk, validate quality, protect the production environment, and maintain a clear audit trail. What is changing is the tooling, the cadence, and the assumptions we can safely make about the code moving through our pipelines.

Organisations that adapt their release practices proactively — embracing policy-as-code, progressive deployment, AI-assisted impact assessment, and robust observability — will be well placed to capture the productivity benefits of vibe coding without exposing themselves to the associated risks. Those that don't will find out the hard way, usually at 2am on a Friday.

---

> *Hopefully this has been useful to you and I wish you well on your ITSM journey…*

Building: Contrails & Cordite

# Building *[Contrails and Cordite](https://contrails-and-cordite.vercel.app/)*: A WW2 Aircraft Reference Site in Next.js

**A deep-dive into the design decisions, architecture, and image-handling challenges behind a passion project for warplane enthusiasts.**

---

### ## Where It Started

The brief was deceptively simple: build a comprehensive, image-forward reference site for WW2 aircraft enthusiasts using Next.js. No half-measures — every aircraft entry should feel like pulling a dossier out of an intelligence archive. Photographs front and centre, historical detail on every page, and a structure that lets visitors explore by aircraft or by theatre of war.

What followed was an education in the hidden complexity of building a visually rich site around a public image commons that was never designed to be depended upon.

---

### ## Information Architecture

I organised the site around two core content types that mirror how enthusiasts actually think about the subject:

****Aircraft**** — individual entries for twelve iconic types, spanning every major air force. The roster covers the Supermarine Spitfire, P-51 Mustang, Bf 109, Mitsubishi Zero, B-17 Flying Fortress, Avro Lancaster, Focke-Wulf Fw 190, Hawker Hurricane, Junkers Ju 87 Stuka, F4U Corsair, P-38 Lightning, and the Messerschmitt Me 262 — the world's first operational jet fighter.

****Theatres**** — five pages grouping aircraft and events by strategic context: Battle of Britain & the West, Eastern Front, Pacific, Mediterranean & North Africa, and Battle of the Atlantic. This axis of navigation exists because the performance envelope of an aircraft only makes sense when you understand the environment it was designed to fight in. A Spitfire and a Zero were contemporaries with broadly similar roles, but they were built for completely different wars.

The site also carries an About page and a hero-driven home screen that sets the atmospheric tone before visitors dive into the catalogue.

---

### ## Visual Design Principles

My overriding aesthetic goal was **dossier-meets-archive**. War photography from 1939–45 has an intrinsic visual authority — grain, contrast, the particular quality of light in a gun-camera frame — and the site's chrome had to earn the right to sit beside it rather than compete with it.

That translated into a handful of hard decisions:

- ****Photography at full bleed.**** No thumbnails relegated to a corner. Hero images fill the viewport; card images fill their containers. Text is layered over images using gradient overlays, not placed beside them.
- ****Dark, muted base palette.**** Near-black backgrounds (`ink-950`) prevent the interface from fighting the photographs for visual dominance. Gold-amber accent tones (`c8a44b`) nod to period military insignia and instrument-panel gauges.
- ****Monospaced type in supporting roles.**** Reference labels, classification stamps, and metadata are set in `Courier New` — a small detail that commits hard to the dossier metaphor without making body text unreadable.
- ****Restraint in motion.**** Hover states use `scale-105` on images — enough to signal interactivity, not enough to feel playful.

---

### ## The Image Problem

The biggest engineering challenge on this project had nothing to do with React or TypeScript. It was photographs.

Wikimedia Commons is the only freely-licensed archive with consistent coverage of WW2 aircraft photography. It has tens of thousands of images. It is also maintained by volunteers who rename, improve, and occasionally delete files without notice. The hash-based CDN URLs that Commons generates (`upload.wikimedia.org/wikipedia/commons/a/b3/...`) change every time a file is reuploaded. A URL that works today can silently 404 tomorrow.

The naive approach — hard-coding `<img src={commonsUrl} />` — produces broken-image icons the moment any URL rots. On a catalogue of twelve aircraft across five theatres, the probability of at least one URL breaking on any given day is uncomfortably high.

The solution I built has three interlocking tiers.

### Tier 1: The Proxy Route and URL Helper

Rather than sending the browser directly to `upload.wikimedia.org`, every image in the data layer is built using a `wm()` helper function that routes requests through a local Next.js API route (`/api/img`):

```ts
const wm = (file: string, width = 1200): string =>
  `/api/img?file=${encodeURIComponent(file)}&w=${width}`;
```

The API route fetches from Commons's stable `Special:FilePath` redirector — a URL that resolves to the current CDN hash for a given filename — on the server side, then streams the result back to the browser with aggressive cache headers (`max-age=86400, stale-while-revalidate=604800`). The browser never touches Wikimedia's CDN directly, which eliminates CORS friction and keeps image load times predictable.

Crucially, `Special:FilePath` URLs are stable for a given **filename**, even when the underlying CDN hash changes. This is a much stronger guarantee than hard-coding the hash URL directly.

### Tier 2: The Wikipedia REST API Fallback

If the Commons filename itself has changed — because a volunteer reuploaded a higher-resolution scan under a new name — the proxy returns a 404, and the browser fires the `onError` event on the image element. At this point, the `SafeImage` component makes a client-side call to the Wikipedia REST API:

```ts
const WIKI_API = 'https://en.wikipedia.org/api/rest_v1/page/summary/';

async function fetchWikiThumbnail(slug: string): Promise<string | null> {
  const res = await fetch(`${WIKI_API}${encodeURIComponent(slug)}`);
  const data = await res.json();
  return data?.originalimage?.source ?? data?.thumbnail?.source ?? null;
}
```

Each aircraft entry carries a `wikiSlug` field (e.g. `'Supermarine_Spitfire'`) that maps to its Wikipedia article, not its Commons filename — a distinction that matters because the two naming conventions often diverge. The REST API returns whatever image Wikipedia is currently using for that article's infobox, which is almost guaranteed to be a high-quality photograph of the correct subject.

### Tier 3: The Branded Placeholder

If both network tiers fail — the Commons proxy 404s **and** the Wikipedia API returns nothing — the `SafeImage` component falls back to a local SVG placeholder stored in `/public/placeholder.svg`. This is not a generic grey rectangle. It is a fully branded, inline SVG that looks like a period intelligence dossier — dark linen background, a geometric aircraft silhouette in the site's gold accent colour, and monospaced type reading **"Photograph unavailable / NO VISUAL RECORD ON FILE"**, with a red rubber-stamp **UNINDEXED** in the corner. It uses only web-safe fonts and zero external resources, so it loads in under a millisecond with complete certainty.

The result is a site where every image position is always occupied by something visually coherent, regardless of what the external archive does.

---

### ## The `SafeImage` Component

The component that orchestrates all three tiers is deliberately a plain `<img>` element wrapper rather than Next.js's built-in `<Image>`. This was a pragmatic choice: `next/image` intercepts `onError` in ways that make progressive fallback chains unreliable. Using a plain `<img>` keeps the error-handling logic fully in React's hands.

I track state across three stages and reset on `src` prop change via `useEffect`, which prevents a subtle bug where navigating from one aircraft detail page to another could leave the component stranded on a previous entry's fallback URL.

```tsx
// stage: 0 = primary src, 1 = wiki thumbnail, 2 = placeholder
const [currentSrc, setCurrentSrc] = useState<string>(src);
const [stage, setStage]           = useState<0 | 1 | 2>(0);
```

Above-the-fold hero images use `loading="eager"` to hit Largest Contentful Paint targets; card grids use `loading="lazy"` so the browser only fetches images as they scroll into view.

---

### ## Data Layer

Every aircraft and theatre entry is a TypeScript object that carries three image-related fields, enforced by type:

```ts
type Aircraft = {
  slug: string;
  name: string;
  image: string;       // proxied URL via wm() helper
  wikiSlug: string;    // Wikipedia article slug for REST API fallback
  imageCredit: string; // free-text credit line for figcaptions
  // ... historical fields
};
```

Separating `image` (the Commons filename, routed through the proxy) from `wikiSlug` (the Wikipedia article identifier) was a design decision that caused me some confusion early in the build — the two values often look similar but refer to different namespaces. Getting this distinction wrong produces fallback chains that skip straight to the placeholder when the primary URL fails, because the Wikipedia API lookup gets called with a Commons filename instead of an article slug.

---

### ## What I'd Do Differently

****Build the image infrastructure first.**** I added the proxy route and `SafeImage` component midway through the project, after discovering that naive image embedding produced a visually broken experience in testing. Starting with the resilient image system and working outward from there would have saved a couple of debugging sessions.

****Abstract the** `**wm()**` **helper earlier.**** I lost several hours to broken references after a routing refactor deleted the `/api/img` route. A centralised image utility with a clear API contract would have made those breakages obvious at compile time rather than runtime.

****Consider a build-time image validation step.**** A CI check that fetches each proxied URL and logs 404s would catch stale Commons filenames before they reach production — something I'd add if I were to revisit the project.

---

### ## The Result

**Contrails & Cordite** is the kind of site that's easy to underestimate from a technical description — "a Next.js catalogue with twelve entries and five category pages" doesn't sound ambitious. The ambition is in the details: in the image system that refuses to show a broken icon, in the placeholder that stays in character when the archive fails, in the design language that earns its place beside seventy-year-old photography.

The codebase is compact and the architecture is straightforward. What took time was getting the small things right — and the image-handling infrastructure, in particular, is a pattern I'd reach for again on any project that depends on community-maintained media archives.

---

**Built with Next.js, TypeScript, and Tailwind CSS. Images sourced from Wikimedia Commons under various public domain and free-use licences.**

Service Design as Code: The Future of Consistent IT Service Delivery

# Service Design as Code: The Future of Consistent IT Service Delivery

## What if your Service Design Document was a living, version-controlled artefact — not a Word file gathering dust on a SharePoint drive?

The idea of treating infrastructure as code revolutionised the way we think about provisioning and configuration. "Infrastructure as Code" (IaC) gave us repeatability, auditability, and the ability to deploy entire environments from a single source of truth. In my opinion, it's time we applied that same discipline to something that has, for too long, remained stubbornly document-centric: **ITSM Service Design**.

Service Design as Code (SDaC) is not a formally standardised practice yet — but the concept is very much within reach, and the organisations that move in this direction first will gain a meaningful advantage in service consistency, quality, and speed of delivery.

---

## 1. **What Is Service Design as Code?**

Service Design as Code is the practice of defining, versioning, and deploying service design artefacts — processes, SLAs, escalation paths, team structures, tooling integrations — in a machine-readable, human-readable format, stored in source control.

Rather than authoring a static Service Design Document (SDD) in Word or PDF, you express the same content as structured data: YAML, JSON, or a domain-specific schema. That definition becomes the canonical description of your service, from which everything else is generated or validated.

Think of it this way: instead of a 60-page Word document describing how an Incident Management process works, you have a version-controlled schema that:

* **Defines** the process steps, ownership, SLA thresholds, and escalation rules
* **Generates** human-readable documentation automatically from that schema
* **Validates** that your ITSM tooling configuration (ServiceNow, Jira Service Management, etc.) matches the defined design
* **Tracks** every change with a full audit trail, including who approved it and when

---

## 2. **Why Service Design Consistency Is Such a Stubborn Problem**

If you have spent any time in ITSM delivery — particularly across large organisations or managed service environments — you will recognise this scenario immediately.

Two teams, ostensibly running the same service for two different customers, have drifted into completely different operating models. One team escalates P2 incidents after 30 minutes; the other does it after an hour. One team uses a five-priority matrix; the other uses three. One team has a formal change advisory board; the other eyeballs it.

This happens not because people are careless, but because service design artefacts are:

* **Static documents** — written once, rarely revisited, and hard to compare across engagements
* **Disconnected from tooling** — the SDD says one thing; the ITSM tool is configured differently
* **Tribal knowledge-dependent** — the person who designed the service has left, and nobody knows why decisions were made
* **Difficult to diff** — comparing two versions of a Word document is painful; spotting when something quietly changed is even harder

Service Design as Code addresses all of these problems directly.

---

## 3. **What It Could Look Like in Practice**

Here's a look at how a practical SDaC implementation might be structured. Imagine a YAML-based schema for an Incident Management process:

```*yaml*
service: "End User Services"
version: "2.1.0"
owner: "IT Operations"
last_reviewed: "2026-04-01"

incident_management:
  priority_matrix:
    P1:
      label: "Critical"
      response_time: "15 minutes"
      resolution_target: "4 hours"
      escalation_path: ["Service Desk", "Team Lead", "Head of IT"]
    P2:
      label: "High"
      response_time: "30 minutes"
      resolution_target: "8 hours"
      escalation_path: ["Service Desk", "Team Lead"]
    P3:
      label: "Medium"
      response_time: "4 hours"
      resolution_target: "3 business days"
      escalation_path: ["Service Desk"]

  sla_review_frequency: "monthly"
  tooling:
    platform: "ServiceNow"
    queue: "INC_EUS_PROD"
    automation_rules:
      - trigger: "unassigned > 15 minutes"
        action: "auto-escalate to Team Lead"
```

That single file, committed to a Git repository, becomes the **source of truth** for how Incident Management works for this service. From it, you can:

* Auto-generate a formatted SDD section using a templating engine
* Run a validation pipeline that checks whether ServiceNow's actual queue configuration matches the defined SLAs
* Issue a pull request when a customer requests an SLA change — triggering a review and approval workflow before anything is actioned
* Tag a release when the design is baselined, giving you a clear audit point

---

## 4. **The Consistency Gains Are Significant**

My preference when working across multiple customer engagements is to establish a **baseline schema** — a canonical service design pattern — and then allow customer-specific overrides in a separate layer. This is essentially the same pattern as environment-specific configuration in IaC.

The consistency gains this enables are considerable:

* **Onboarding acceleration** — new engagements start from a validated baseline, not a blank document
* **Drift detection** — automated pipelines can flag when a live tooling configuration diverges from the agreed design
* **Change governance** — every modification to the service design goes through a peer-reviewed, approved commit, not an informal email
* **Comparative reporting** — you can genuinely compare service designs across customers, identifying where bespoke exceptions have been granted and what the rationale was
* **Regulatory and audit readiness** — full version history, with timestamps and approvals, is inherent to the model

---

## 5. **The Role of AI in Generating and Validating Service Designs**

This is where it gets genuinely exciting. With a well-defined schema and a corpus of existing service designs, AI becomes a powerful co-pilot for service design work.

Imagine prompting an AI assistant with: *"Generate a baseline service design for a Managed Desktop service with 500 users, standard SLAs, and ServiceNow as the ITSM platform."* The AI produces a validated YAML or JSON artefact, conforming to your schema, which your team then reviews and refines — rather than authoring from scratch.

Beyond generation, AI can assist with:

* **Design review** — comparing a proposed service design against best practice patterns and flagging anomalies
* **Natural language documentation** — generating the human-readable SDD narrative from the structured schema automatically
* **Gap analysis** — identifying missing process definitions or undefined escalation paths before they become operational problems
* **Change impact assessment** — when a schema change is proposed, AI can assess downstream impacts on tooling, SLAs, and team responsibilities

This is not about replacing the service designer's judgement — it's about empowering them to work faster and with greater confidence.

---

## 6. **Where to Start**

If you are wondering how to begin moving in this direction, here is a pragmatic approach that does not require you to rearchitect everything overnight:

* **Start with a schema for your most common process** — Incident Management is usually the best candidate, given its complexity and SLA sensitivity
* **Use your existing SDD as the source** — translate one document into structured YAML or JSON; treat it as a learning exercise
* **Store it in Git** — even without automation, version control alone is a significant improvement over SharePoint versioning
* **Build one piece of automation** — a simple script that validates your schema against your ITSM tool's configuration is an excellent first win
* **Expand iteratively** — add Change Management, Request Fulfilment, and Problem Management schemas over time
* **Introduce generation** — once your schema is stable, build a template that produces your SDD Word document from it automatically

The key is to start small, prove the value, and build momentum. This is a journey, not a big-bang transformation.

---

## Conclusion

Service Design as Code represents a natural evolution for ITSM practitioners who are serious about consistency, auditability, and scalability. By treating service design as a living, version-controlled artefact rather than a static document, organisations can close the gap between what they say they deliver and what they actually deliver — and do so in a way that is transparent, repeatable, and auditable.

The tools exist today. The patterns are well-established in adjacent disciplines. The question is simply whether we, as an ITSM community, are willing to bring that same engineering discipline to the way we design and govern our services.

I believe we are — and the organisations that make that move will be markedly better for it.

> *Hopefully this has been useful to you and I wish you well on your ITSM journey…*

Building: The Naval Archive

Building *[The Naval Archive](https://the-naval-archive.vercel.app/)*: Design Notes on a WW2 Warship Enthusiast Site

**April 2026 · Next.js, Tailwind CSS, Wikimedia Commons**

---

There's a particular atmosphere to naval history — salt-worn, severe, and grand. When I look at a photograph of HMS Hood steaming through the Firth of Forth in 1940, or read the signals log from the **Bismarck** chase, I feel the weight of iron and the ruthlessness of the sea. Building a website for WW2 warship enthusiasts posed the same challenge any period archivist faces: how do you honour that atmosphere without tipping into pastiche?

This is my build log for **The Naval Archive** — an eight-section Next.js site covering Top 10 ships by nation, world museums, dedicated profiles for HMS Hood, Rodney, and Belfast, the career of Admiral Cunningham, and a multi-theatre battle timeline. Here's how it came together.

---

### ## The Aesthetic Direction

My first decision was conceptual rather than technical: what **register** does a naval history site live in?

I looked at plenty of existing sites in this space. Most lean military-utilitarian — grey backgrounds, tabular layouts, the visual language of a database dump. Others go the opposite way, reaching for drama with widescreen stock footage and motion graphics that feel more like a streaming platform than an archive. Neither felt right to me.

The direction I committed to was ****editorial archive****: the sensibility of a serious illustrated reference — something like the Imperial War Museum's printed catalogues, or the dusty-but-authoritative volumes I'd find in a university naval library. In practice, that meant:

- ****Deep navy tones**** (`#0b1722`) as the dominant canvas, not black and not grey
- ****Parchment type**** (`#f2e9d5`) rather than pure white — softer on dark backgrounds
- ****Brass accents**** (`#b8933a`) for decorative elements, links, and highlights — the colour of a compass or a telescope barrel
- ****Rust**** (`#8b3a2a`) as the danger/alert accent, echoing oxide and blood
- A ****paper-grain texture**** layered over the whole page — a subtle SVG fractal noise overlay at 12% opacity in `mix-blend-mode: overlay`

The grain is a small touch but it does significant work. On a digital screen it suggests physical media without screaming "retro"; it gives the dark background a slight dimensionality, and it helps the archival photographs feel at home rather than floating in a void.

---

### ## Typography

I settled on three typefaces, each with a distinct job.

****Playfair Display**** carries all the display and heading work. It has the editorial authority of a broadsheet masthead, and its high-contrast strokes feel genuinely period-appropriate for a mid-20th-century archive. I set it at negative tracking (`-0.02em`) and a compressed line-height of `0.95` for the hero and section headings — tight enough to feel monumental without becoming unreadable.

****Lora**** handles body copy. It's a scholarly book serif with optical kerning that reads well at small sizes. The slightly warm letterforms complement Playfair without competing with it.

****Oswald**** plays the third role: stencil face. It appears in figure captions, stat ribbons, and navigational micro-labels — the visual equivalent of the stencilled markings on naval equipment. I set it in uppercase with generous letter-spacing, creating a typographic hierarchy that clearly signals "this is data or a label, not prose."

All three are loaded through `next/font` — no flash of unstyled text, zero layout shift.

---

### ## Structure and Navigation

I built the site across eight distinct sections using a flat Next.js App Router structure:

```
app/
  page.js              # home
  top-10/page.js       # 10 ships per nation, UK/USA/Japan/Germany
  museums/page.js      # 12 preserved vessels worldwide
  hms-hood/page.js     # ship profile
  hms-rodney/page.js   # ship profile
  hms-belfast/page.js  # ship profile
  cunningham/page.js   # career timeline
  timeline/page.js     # tabbed battle chronology
```

All editorial content — ship specs, museum descriptions, ranking data, battle events, and image URLs — lives in a single `lib/data.js` file. This was a deliberate choice on my part: it makes the site easy to edit without touching any component code, and keeps the page files clean, acting purely as presentational consumers of structured data.

I kept the navigation minimal: a horizontal bar with an anchor-chain logo mark, the site name in Playfair Display, and eight text links. On smaller screens it collapses gracefully — no hamburger menu tricks, just straightforward responsive stacking.

---

### ## Imagery: Wikimedia Commons and the Fallback Problem

Every photograph on the site loads from Wikimedia Commons — predominantly public-domain Royal Navy, U.S. Navy, and Imperial War Museum photographs. I whitelisted `upload.wikimedia.org` as a trusted image domain in `next.config.js`, and every `Figure` component links back to the source Commons page for attribution.

There was a problem I had to solve, though: Wikimedia Commons URLs occasionally go stale as files are renamed or reorganised, and `next/image` renders nothing at all on a broken URL — not even a visible error.

My solution was a `SafeImage` component wrapping `next/image` with an `onError` handler that swaps in a branded SVG placeholder. The placeholder renders a silhouette of a warship on the navy background with the brass-coloured site wordmark and the text **"Image unavailable"** — so a broken URL degrades gracefully to something that still looks intentional rather than leaving a blank void on the page.

Every ship card image — on the Top 10 rankings, the museum grid, the home section index — has a verified `1280px-` Wikimedia URL mapped in `lib/data.js`. Anyone who needs to update one can replace it with a fresh Commons URL in a single place.

---

### ## The Photography Treatment

One of the smaller but more satisfying decisions I made: applying a CSS filter to every historical photograph through the `Figure` component:

```css
**filter**: sepia(0.25) saturate(0.8) brightness(0.9);
```

It's subtle — not the full sepia treatment you'd apply to deliberately "age" a photograph, but enough to harmonise the varied source images into a cohesive visual language. A 1944 U.S. Navy official photograph and a 1990s museum shot of HMS Belfast tend to have quite different colour casts; this small filter brings them into the same family without destroying their documentary character.

---

### ## The Timeline Section

The most technically interesting page I built was the battle timeline — a tabbed chronology covering three theatres: the Battle of the Atlantic, the Battle of the Arctic, and the campaigns in the Pacific.

I managed the tab state client-side with a simple `useState` hook. Each theatre has an associated loss statistics strip — total ships lost, tonnage, lives — pulled from `lib/data.js` and displayed in the Oswald stencil face with brass rule separators. Below the stats, events render chronologically as a vertical timeline with alternating card positions: date and classification on one side, narrative and imagery on the other.

The human cost data was the most careful part to research and represent. Numbers like 3,500 merchant ships lost in the Atlantic and 36,000 merchant sailors killed deserve to be shown with weight, not buried in a table. I placed the stats strip above the narrative timeline as a permanent header for each theatre, so the reader is always aware of the scale as they scroll through individual events.

---

### ## Lessons

A few things I'd take away from this build for anyone tackling something similar:

****One content file is enough to start.**** Keeping all data in `lib/data.js` felt like a constraint early on but turned out to be a significant advantage during iteration. When image URLs needed correcting or ship data needed refining, I always knew exactly where to look.

****Dark-mode-first is its own design problem.**** Designing on a dark canvas meant rethinking contrast ratios, image presentation, and typography weight from scratch. My temptation was to over-brighten text and accents to compensate; the result looked like a gaming dashboard. Restraint and warm tones (`#f2e9d5` rather than `#ffffff`) turned out to be the answer.

****Texture does the work that illustration can't.**** The paper grain is two lines of CSS and an inline SVG. It contributes more to the archival atmosphere than anything more elaborate would have.

****Historical subject matter demands accuracy.**** Ship specifications, dates, and career timelines are the kind of thing that naval enthusiasts know cold. I source-checked every fact; a wrong displacement figure or a misattributed quote would undermine the authority the design works so hard to establish.

---

**The Naval Archive is a Next.js 14 site using the App Router, React 18, Tailwind CSS 3, and next/font. Images are served from Wikimedia Commons under various public-domain and open licences.**

ITIL® 4 vs ITIL® (Version 5): Key Differences Explained

# ITIL® 4 vs ITIL® (Version 5): Key Differences Explained

*ITSM · 25 April 2026 · 10 min read*

---

The ITSM world rarely stands still, and January 2026 brought with it one of the biggest moments in the framework's history: the official release of **ITIL® (Version 5)**. If your inbox has looked anything like mine over the past few months, you will have noticed no shortage of opinions — some proclaiming wholesale revolution, others dismissing it as little more than a cover refresh. In my view, the truth sits usefully in between, and it is well worth understanding exactly what has changed before making any decisions about your certification path or your organisation's ITSM strategy.

This article covers the key differences between ITIL® 4 and ITIL® (Version 5), what remains the same, and what it all means in practice. Whether you are an ITSM practitioner, a team lead, or someone considering their certification options, there should be something useful here for you.

---

## 1. **The Big Picture: A Shift in Scope**

Perhaps the most important thing to understand about ITIL® (Version 5) is **what it is now about**. ITIL® 4 was fundamentally a framework for *IT Service Management*. Version 5 expands that scope considerably to encompass *Digital Product and Service Management (DPSM)*.

**ITIL® 4 vs Version 5 — at the highest level:**

* **Scope** — ITIL® 4 covered IT Service Management (ITSM). Version 5 covers Digital Product & Service Management (DPSM).
* **Industrial context** — ITIL® 4 aligned with Industry 4.0. Version 5 aligns with Industry 5.0.
* **Focus** — ITIL® 4 addressed services only. Version 5 addresses products and services together in a unified lifecycle.

This is not merely semantic housekeeping. It reflects a genuine shift in how modern organisations operate. Most organisations today do not deliver services in isolation — they deliver **digital products and services** together, and the old distinction was creating real gaps in practice. ITIL® (Version 5) unifies them into a single, end-to-end lifecycle.

> There has long been a call to drop the "IT" element from IT Service Management, since the framework applies well beyond IT departments. Version 5 recognises this: its courses are explicitly aimed at **every business utilising digital services**, not purely IT teams.

---

## 2. **What Has Remained the Same**

Before we explore the changes, it is worth acknowledging what PeopleCert has deliberately preserved — and why this matters if you already hold ITIL® 4 certifications.

* **The 7 Guiding Principles:** These remain intact and unchanged. Focus on value, start where you are, progress iteratively with feedback — they are as relevant in 2026 as they were in 2019.
* **The Four Dimensions of Service Management:** Organisations & People, Information & Technology, Partners & Suppliers, and Value Streams & Processes — all present, with only minor terminology updates.
* **The Service Value Chain:** The core mechanism of the SVS remains, connecting demand to value through its six activities.
* **All 34 ITIL Practices:** Every one of the 34 management practices carries over, with only minor updates to terminology to reflect modern approaches. No practices have been removed.
* **ITIL Foundation as the entry point:** Foundation remains the mandatory starting point for all advanced certifications, and — importantly — your existing ITIL 4 Foundation certificate still counts.
* **Backward compatibility:** PeopleCert has been explicit that existing ITIL investments are protected. Your certifications carry forward.

Roughly **40% of the framework content is preserved** from ITIL® 4. The remaining 60% has been updated, restructured, or introduced as genuinely new material. This is not a minor revision — but it is a coherent evolution, not a reset.

---

## 3. **Key Differences at a Glance**

Here is how the two versions compare across the areas that matter most:

**Scope and context**
* **Scope** — ITIL® 4: IT Service Management / Version 5: Digital Product & Service Management *(Updated)*
* **Industrial context** — ITIL® 4: Industry 4.0 / Version 5: Industry 5.0 *(Updated)*
* **Core value framework** — ITIL® 4: Service Value System (SVS) / Version 5: ITIL Value System (ITIL VS) *(Renamed)*

**What's new**
* **AI governance** — ITIL® 4: not addressed / Version 5: dedicated ITIL AI Governance publication *(New)*
* **Automation & AI** — ITIL® 4: optional and contextual / Version 5: AI-native; agentic AI a core concept *(New)*
* **Customer experience** — ITIL® 4: SLAs / XLAs emerging / Version 5: Experience Level Agreements (XLAs) formalised *(New)*
* **Sustainability** — ITIL® 4: implicit only / Version 5: explicitly addressed within the framework *(New)*

**What has expanded**
* **Product management** — ITIL® 4: services only / Version 5: products + services in a unified lifecycle *(Expanded)*
* **Terminology** — ITIL® 4: standard ITSM vocabulary / Version 5: XLA, agentic AI, observability, SRE, DPSM added *(Expanded)*
* **Publications** — ITIL® 4: Create, Deliver & Support; High Velocity IT; etc. / Version 5: Strategy, Product, Service, Experience, Transformation, AI Governance *(New set)*

**What has been simplified or preserved**
* **Foundation exam** — ITIL® 4: ~42.5% on practice workflows / Version 5: 0% on detailed practice workflows *(Revised)*
* **Certification scheme** — ITIL® 4: complex module structure / Version 5: practitioner modules bundled into PM certifications *(Simplified)*
* **34 Practices** — both versions: all 34 present, minor terminology updates only *(Preserved)*
* **Guiding Principles** — both versions: all 7, completely unchanged *(Unchanged)*

---

## 4. **AI-Native by Design**

If I were to identify the single biggest philosophical shift in Version 5, it would be this: **AI is no longer an afterthought**. In ITIL® 4, artificial intelligence and automation were contextual topics — acknowledged, but not woven into the fabric of the framework. In Version 5, they are core.

* **Agentic AI:** Version 5 introduces "agentic AI" as a formal concept — autonomous AI agents that act on behalf of organisations and users, not just surface-level chatbots.
* **ITIL AI Governance:** A dedicated publication and standalone certification covering responsible AI adoption, ethical governance, and oversight frameworks — entirely new in Version 5.
* **Observability:** Observability and Site Reliability Engineering (SRE) principles are formalised as part of the vocabulary and practice, reflecting how modern digital operations actually run.
* **Automation as standard:** Automation is treated as a normal part of how work is managed, not an optional add-on. Manual, unscalable approaches are explicitly noted as inadequate for digital-first organisations.

In my opinion, this is a genuinely positive development. For years, ITSM practitioners have been navigating AI adoption without adequate framework guidance. The creation of a dedicated ITIL AI Governance publication is long overdue, and should provide a much-needed structure for organisations deploying AI into their service operations.

---

## 5. **A New Vocabulary to Learn**

One of the most concrete impacts of Version 5 — particularly if you are studying for Foundation — is the significant expansion of the framework's vocabulary. The Foundation exam now tests **terminology at nearly three times the weighting** of ITIL® 4 (30% vs 12%).

Key terminology changes to be aware of:

* **Service Value System (SVS)** is now the **ITIL Value System (ITIL VS)**
* **Service Level Agreement (SLA)** is joined by the formalised **Experience Level Agreement (XLA)**
* **Service Management** is now framed as **Digital Product & Service Management (DPSM)**
* **Service Value Chain** expands into the **Product & Service Lifecycle**
* New terms introduced: **Agentic AI**, **Observability**, and **Site Reliability Engineering (SRE)**

If you are studying for the Foundation exam using ITIL® 4 materials, this is where you will feel the gap most acutely. The new vocabulary is not incidental — it reflects substantive changes in how the framework conceptualises digital operations.

---

## 6. **The Foundation Exam Has Changed Significantly**

This one catches people out. The ITIL® (Version 5) Foundation exam is **not a minor update** to the ITIL® 4 paper. The weighting has shifted considerably:

**Detailed practice workflows**
* ITIL® 4 Foundation: ~42.5%
* ITIL® (Version 5) Foundation: **0%**

**Key concepts and terminology**
* ITIL® 4 Foundation: ~12%
* ITIL® (Version 5) Foundation: **~30%**

**Service / ITIL Value System**
* ITIL® 4 Foundation: ~18%
* ITIL® (Version 5) Foundation: ~22%

**Guiding Principles**
* ITIL® 4 Foundation: ~17%
* ITIL® (Version 5) Foundation: ~18%

In ITIL® 4, the Foundation exam tested your knowledge of seven specific practices in considerable depth — incident management, change control, service desk operations, and so on. In Version 5, that detailed practice knowledge has been moved to the **advanced certifications**, where it genuinely belongs. The Foundation level now focuses on framework fluency, vocabulary, and strategic understanding. Honestly, that is a sensible restructuring.

---

## 7. **New Publications Structure**

Version 5 introduces a completely new set of core publications, replacing the ITIL® 4 books (Create, Deliver & Support; High Velocity IT; Direct, Plan & Improve; etc.).

### Core publications

* **ITIL Foundation (Version 5)** — Entry-level framework overview and prerequisite for all advanced modules.
* **ITIL Strategy** *(New)* — Organisational direction and digital strategy for products and services.
* **ITIL Product** *(New)* — End-to-end digital product management alongside service delivery.
* **ITIL Service** *(New)* — Service management operations, practices, and continual improvement.
* **ITIL Experience** *(New)* — Customer and user experience, XLAs, and stakeholder value realisation.

### Additional publications

* **ITIL Transformation** *(New)* — Guiding organisations through digital and service transformation.
* **ITIL AI Governance** *(New)* — Responsible AI adoption, ethics, oversight, and agentic AI management.

---

## 8. **The New Certification Pathway**

The qualification scheme has been simplified and restructured. Practitioner modules no longer exist as standalone certifications — they are now **bundled into Practice Manager certifications**. There are nine core modules plus one extension module, organised into three learning streams.

The pathway works from the bottom up:

1. **ITIL Foundation (Version 5)** — the mandatory starting point for all advanced certifications.
2. Three professional designations, each with their own stream of modules:
   * **ITIL Managing Professional** — for those with a business and operational focus.
   * **ITIL Strategic Leader** — for those working at strategy and direction level.
   * **ITIL Practice Manager** — for those who need deep practice-level expertise.
3. **ITIL Master** — awarded on completion of all three designations.

In addition, **ITIL AI Governance** is available as a standalone extension module with no Foundation prerequisite required.

---

## 9. **If You Already Hold ITIL® 4 Certifications**

The question I am already hearing most frequently is: *"What do I need to do with my existing ITIL® 4 certifications?"* The short answer is: **nothing urgent**. Your certifications remain valid. Transition pathways are designed to respect your existing investment.

* **ITIL 4 Foundation** → Fully recognised as ITIL Foundation (v5). No further exam needed.
* **ITIL 4 Managing Professional** → Bridge module available for ITIL Managing Professional (v5).
* **ITIL 4 Strategic Leader** → Bridge module available for ITIL Strategic Leader (v5).
* **ITIL 4 Practice Manager** → Updated bundled pathway available for ITIL Practice Manager (v5).
* **ITIL 4 Master** → Structured transition pathway — speak to an Accredited Training Organisation (ATO).

My preference when advising practitioners: if you are close to completing an ITIL® 4 certification path, see it through — the knowledge is still entirely relevant. If you are *starting fresh*, I would recommend going directly to Version 5. It is the most complete and up-to-date starting point available, and there is little to be gained from beginning a journey that will require bridging in the near future.

---

## 10. **What This Actually Means in Practice**

Framework releases can sometimes feel abstract — especially when you are deep in the day-to-day of running a service desk or managing a change advisory board. So let me be direct about what Version 5 means on the ground.

* **If your organisation manages digital products alongside services** — Version 5 finally gives you a framework that reflects how you actually work. The unified lifecycle removes an artificial boundary that has caused real operational friction.
* **If you are deploying AI into your service operations** — the ITIL AI Governance publication will provide a meaningful governance structure. This is the first time ITIL has addressed AI with the seriousness the topic demands.
* **If you are running an ITSM transformation programme** — the new Transformation publication should be directly useful, providing structured guidance for navigating change rather than leaving practitioners to improvise.
* **If your focus is on customer and user experience** — the formalisation of Experience Level Agreements (XLAs) is a welcome development. XLAs have been emerging in practice for several years; it is good to see them given proper framework-level status.
* **If you are training your team** — the simplified certification structure makes it easier to build a coherent learning pathway. Fewer standalone modules, clearer streams.

I am always conscious that frameworks only deliver value when they are actually applied. The question is never purely "what does Version 5 say?" but rather "how do we embed this thinking into how our teams work day-to-day?" The expanded scope and restructured publications of Version 5 should make that application more straightforward — but the real work, as ever, will be done by practitioners.

---

## 11. **A Brief History of ITIL®**

* **1980s — ITIL v1:** Developed by the UK government's CCTA to standardise IT service management across departments. Originally 31 volumes.
* **2007–2011 — ITIL v3 and 2011 Refresh:** A five-volume lifecycle framework covering Service Strategy, Design, Transition, Operation, and Continual Service Improvement. The global standard for a generation.
* **2019 — ITIL® 4:** A significant redesign introducing the Service Value System, Four Dimensions, 34 Practices, and alignment with Agile, Lean, and DevOps.
* **January 2026 — ITIL® (Version 5):** Expands scope to Digital Product & Service Management, introduces AI-native governance, and aligns with Industry 5.0. Backward compatible with ITIL® 4.

---

## Conclusion

ITIL® (Version 5) is a meaningful and well-considered evolution of the framework. It is not a revolution — the foundations remain solid — but it is a genuine step forward in addressing how digital organisations actually operate in 2026 and beyond.

The expansion to Digital Product and Service Management, the AI-native approach, the formalisation of XLAs, and the simplified certification pathway all reflect real-world practice rather than theoretical tidying. In my opinion, that is exactly what a framework update should do.

Whether you are updating your certifications, advising your organisation, or simply keeping up with the profession, the changes in Version 5 are worth understanding properly — not as an academic exercise, but as a practical lens through which to view your ITSM work.

*Hopefully this has been useful to you and I wish you well on your ITSM journey…*

---

*© 2026 Steven Godson · [stevengodson.com](https://stevengodson.com)*

*ITIL® is a registered trademark of the PeopleCert group. Used under licence.*

Building: Iron and Steel

Building *[Iron & Steel](https://ww2-tanks.vercel.app/)*: A WW2 Armour Enthusiast's Website in Next.js

****April 2026 · Design & Development****

---

There's a particular kind of obsession that took hold of me when I started learning about World War 2 armoured warfare. One tank led to another. One battle to the next. Before long I was deep in comparative armour tables, debating whether the Tiger I's 88mm gun was worth its chronic mechanical unreliability, or tracing the T-34's evolutionary line from the BT-7 all the way through to Berlin. **Iron & Steel** started as an excuse to build something for that obsession — and became an exercise in thoughtful frontend engineering along the way.

---

### ## The Concept

My goal was a single, rich reference site covering the major armoured fighting vehicles of WW2 — tanks and tank destroyers — organised by nation, alongside a global museum directory and a historical timeline of key armoured engagements. Not a Wikipedia mirror, but a curated enthusiast's compendium: opinionated, visually distinctive, and fast.

I settled on the following content scope:

- ****60 tanks**** across six nations (Germany, USSR, USA, UK, Japan, Italy) — ten per country
- ****9 tank destroyer profiles**** with full technical specifications
- ****17 global museums**** with location details and Google Maps links
- ****8 timeline entries**** covering key moments in WW2 armoured warfare

---

### ## Design Direction: Military Industrial

My aesthetic brief was unambiguous: **military industrial**. That meant a tight, disciplined colour palette drawn from real-world military hardware — olive drab, khaki, weathered rust, and a deep gunmetal for backgrounds. No pastels. No gradients borrowed from SaaS dashboards. Every visual decision had to feel like it belonged on a field manual or a workshop schematic.

### Typography

Three typefaces do all the work:

- ****Black Han Sans**** — a heavy, condensed display face used for headings and the site name. It reads as monumental without being ornate, which suits the subject matter well.
- ****Barlow Condensed**** — a geometric sans used for UI elements, labels, and navigation. Clean and utilitarian.
- ****Share Tech Mono**** — a monospaced face reserved for specification data: armour thickness, top speed, weight. Monospace for numbers signals precision; it also carries an unmistakeable analogue-instrument quality.

The combination leans into function over decoration, which is exactly right for a site about machines designed to survive shell impacts.

### Motion

I kept animations purposeful and minimal — CSS keyframe scroll-reveal on section entries, subtle lift effects on card hover, and a slow pan on the hero image. Nothing that distracts from the content. If a user has `prefers-reduced-motion` set, the transitions collapse cleanly.

---

### ## Technical Stack

I built the project on ****Next.js 14**** with the App Router, written in TypeScript throughout. Styling is plain CSS with custom properties — no CSS framework, which keeps the build lean and forces every style decision to be intentional.

Data lives in static TypeScript files (`tanks.ts`, `destroyers.ts`, `museums.ts`). For a content set of this size that changes infrequently, a database would be over-engineering. Static data files are trivially auditable, easy to update, and compile-time type-checked.

---

### ## The Image Problem (and How I Solved It)

Sourcing over 70 photographs of WW2 vehicles and museums without licensing headaches meant leaning on ****Wikimedia Commons****, which hosts an enormous catalogue of public domain and Creative Commons military imagery. The challenge: Wikimedia URLs can change, articles get renamed, and some vehicles simply don't have a good Commons photograph.

My solution was a three-stage fallback component — `SafeImage` — that handles failure gracefully at every level:

****Tier 1 — Direct URL.**** Each data entry specifies a `Special:FilePath` URL pointing to a Commons image by filename. This is more stable than hotlinking a specific upload URL, because `Special:FilePath` always resolves to the current canonical file regardless of backend storage changes.

****Tier 2 — Wikipedia REST API.**** If the direct URL fails (network error, renamed file, 404), the component fires a request to the Wikipedia REST API using a `wikiSlug` — the article title for that vehicle or museum. The API returns the article's lead thumbnail, which is almost always a usable photograph.

****Tier 3 — Styled placeholder.**** If both image sources fail, the component renders a CSS-drawn metal-plate placeholder with the vehicle name. No broken image icons. No blank white rectangles. The placeholder is styled consistently with the rest of the UI.

This pattern eliminated all visible image failures in testing, and it degrades gracefully on slow connections — the placeholder appears instantly while image loads are in flight.

One subtlety worth noting: the component initialises its `failed` state to `!src` rather than `false`. This handles the edge case where a data entry has an empty string for its image URL — browsers don't fire `onError` for `src=""`, so without that initialisation the slot would silently render blank.

---

### ## Component Architecture

I composed the page from discrete, self-contained section components:

| Component | Notes |
|---|---|
| `Navbar` | Fixed, collapses to hamburger on mobile |
| `Hero` | Full-bleed image with aggregate stats overlay |
| `TanksByCountry` | Client component — tabbed interface, one tab per nation |
| `TankDestroyers` | Static grid of destroyer cards |
| `Museums` | Client component — filterable by world region |
| `Timeline` | Vertical timeline, CSS scroll-reveal |
| `Footer` | Navigation links and attribution |

I limited client components (`'use client'`) to sections that genuinely need interactivity — the country tabs and the museum region filter. Everything else renders on the server, keeping the JavaScript payload light.

---

### ## Museum Google Maps Integration

Every museum entry in my directory includes a direct Google Maps search link, constructed as:

```
https://www.google.com/maps/search/?api=1&query=Museum+Name+Location
```

This approach requires no API key and no Maps SDK. It opens a pre-populated search in the user's browser or Maps app, which is exactly the right behaviour for "I want to find this place."

---

### ## What I'd Do Differently

A few things I'd change with more time:

****MDX for vehicle write-ups.**** The longer descriptive text for each vehicle is currently a plain string in the data file. Moving it to MDX would allow richer formatting — pull quotes, inline images, footnotes — without giving up type safety.

****Incremental Static Regeneration for images.**** Rather than fetching Wikipedia thumbnails client-side on fallback, a better pattern would be a build-time script that resolves all images and writes a manifest, with ISR to keep it fresh. This would eliminate the client-side fetch entirely and remove the flash of placeholder-then-image on first load.

****Search.**** With 60+ vehicles, a keyboard-accessible search bar filtering across all sections would meaningfully improve navigation. The data is already structured for it — I just ran out of time.

---

### ## Closing Thoughts

**Iron & Steel** is the kind of project that justifies its own existence — a subject I find genuinely interesting, built with tools I wanted to work with, at a scope small enough to finish but large enough to be worth finishing. The image fallback system turned out to be the most interesting engineering problem in the whole build, which is often how these things go: the detail that seems like a footnote ends up teaching you something useful.

The project is available as a zipped Next.js starter for anyone who wants to run it locally or fork it as a template for a similar catalogue site.

---

**Built with Next.js 14 · TypeScript · Plain CSS · Wikimedia Commons**

AI driving ITSM

The integration of Artificial Intelligence (AI) into IT Service Management (ITSM) is redefining the way organizations handle their IT operations, processes, and customer interactions. By automating repetitive tasks, providing intelligent insights, and fostering proactive problem-solving, AI transforms ITSM into a more efficient, resilient, and innovative function. Here's a look at how AI is enhancing ITSM.

## 1. **Automating Routine Tasks**

One of AI’s most impactful contributions to ITSM is its ability to automate repetitive, time-consuming tasks. Examples include:

- **Ticket Routing:** AI-powered systems analyze the nature of IT requests and route them to the most appropriate team or individual.

- **Password Resets and Access Requests:** Virtual agents can handle these straightforward tasks, freeing up IT staff for more complex work.

- **System Monitoring:** AI tools can automatically monitor IT infrastructure, detecting anomalies and generating alerts.

This automation reduces workload, speeds up response times, and allows IT teams to focus on strategic activities.

## 2. **Enhancing Incident Management**

AI improves the incident management process by:

- **Real-Time Diagnostics:** Identifying the root causes of incidents quickly using historical data and machine learning.

- **Predictive Insights:** Anticipating potential failures and alerting teams before issues escalate.

- **Automated Resolution:** Suggesting or even implementing solutions for common problems without human intervention.

The result is faster incident resolution, minimized downtime, and enhanced service reliability.

## 3. **Enabling Proactive Problem Management**

Traditionally, ITSM has been reactive, addressing issues after they occur. AI shifts the focus to proactive problem management by:

- **Identifying Patterns:** Analyzing historical data to uncover recurring issues.

- **Preventive Actions:** Recommending and implementing measures to mitigate potential problems.

- **Improving System Resilience:** Ensuring that systems are optimized to withstand challenges.

This approach minimizes disruptions and fosters a more stable IT environment.

## 4. **Enhancing Change Management**

AI simplifies the complexities of change management through:

- **Risk Analysis:** Evaluating the potential impacts of changes and identifying risks.

- **Best Practices:** Providing recommendations based on successful implementations in similar scenarios.

- **Automated Testing:** Running simulations to predict outcomes and ensure smooth transitions.

With AI, organizations can implement changes more confidently and efficiently.

## 5. **Streamlining Knowledge Management**

A well-maintained knowledge base is essential for ITSM. AI enhances knowledge management by:

- **Organizing Information:** Structuring data into easily accessible formats.

- **Answering Queries:** Using natural language processing to help users and IT staff find relevant information quickly.

- **Learning and Updating:** Continuously updating the knowledge base as new issues and solutions arise.

This ensures that both users and IT teams have access to up-to-date, relevant information.

## 6. **Optimizing Service Delivery**

AI improves the service delivery process by:

- **Personalization:** Tailoring responses and recommendations based on user profiles and preferences.

- **Predictive Analytics:** Anticipating user needs and offering solutions proactively.

- **Virtual Agents:** Providing 24/7 support to handle user queries, ensuring consistent service availability.

These enhancements lead to better user experiences and stronger service outcomes.

## 7. **Empowering IT Teams**

AI is not here to replace IT professionals but to empower them. By taking over repetitive tasks and providing actionable insights, AI allows IT teams to focus on innovation, strategy, and complex problem-solving. This fosters a more engaged and productive workforce.

## Final Thoughts

Artificial Intelligence is revolutionizing ITSM by making it smarter, faster, and more proactive. From automating tasks to enabling predictive insights and enhancing user experiences, AI empowers organizations to deliver superior IT services while adapting to the challenges of a fast-paced digital world. By embracing AI, businesses can not only streamline their operations but also unlock new opportunities for growth and innovation.

Embracing Service Architecture

## **How Service Architecture Boosts Business Effectiveness**

In today’s rapidly evolving business environment, organizations must be agile, efficient, and customer-focused to stay competitive. Service architecture, a strategic design approach for structuring business processes and systems, plays a critical role in achieving these goals.

By aligning services with business needs, it ensures that resources are optimized, processes run smoothly, and customer experiences are enhanced. Here’s how service architecture can transform your business:

### 1. **Streamlining Business Operations**

Service architecture breaks down complex systems into modular, manageable services. Each service represents a specific function or process, such as order management or customer support. By designing these services to work independently yet cohesively, businesses can:

- Reduce inefficiencies by eliminating redundancies and streamlining workflows.\n- Quickly adapt to changes, as individual services can be updated or replaced without disrupting the entire system.

For example, if your organization introduces a new payment method, the payment processing service can be updated without overhauling the entire operational framework.

### 2. **Enhancing Scalability and Flexibility**

As your business grows, so does the demand for resources and capabilities. A well-designed service architecture allows for seamless scaling by enabling the addition of new services or the expansion of existing ones. This flexibility ensures that your operations can handle increased workloads without compromising performance or customer satisfaction.

### 3. **Improving Collaboration and Communication**

Service architecture fosters better collaboration within and across teams by clearly defining roles, responsibilities, and workflows. Each service has a specific purpose and owner, reducing ambiguity and encouraging accountability. Moreover, the use of standardized interfaces and protocols facilitates smoother communication between services, ensuring that data flows efficiently across departments.

### 4. **Driving Innovation and Adaptability**

In a world where customer needs and market conditions change rapidly, businesses must be able to pivot quickly. Service architecture supports innovation by enabling organizations to experiment with new ideas and technologies without disrupting existing operations. Whether it’s integrating AI-driven analytics or launching a new digital product, service architecture provides the flexibility to stay ahead of the curve.

### 5. **Enhancing Customer Experience**

By aligning services with customer journeys, service architecture ensures that each touchpoint delivers value and meets expectations. Whether it’s faster response times, personalized recommendations, or seamless transactions, a customer-centric service architecture can significantly enhance satisfaction and loyalty.

### 6. **Reducing Costs and Risks**

Service architecture promotes cost-efficiency by optimizing resource allocation and reducing waste. Additionally, its modular nature minimizes risks, as failures in one service are less likely to impact the entire system. This resilience is crucial for maintaining business continuity and protecting your reputation.

### Conclusion

Service architecture is more than just a technical framework; it’s a strategic tool for enhancing business effectiveness. By streamlining operations, enabling scalability, fostering collaboration, driving innovation, and improving customer experiences, it empowers organizations to thrive in a competitive landscape. Embracing service architecture isn’t just an investment in technology—it’s an investment in your business’s future success.

Embracing the future

In the ever-evolving IT Service Management (ITSM) landscape, staying ahead of the curve is crucial for organisations aiming to deliver exceptional service and maintain operational efficiency. One of the most exciting innovations in ITSM today is the integration of Artificial Intelligence (AI) and Machine Learning (ML) to revolutionize service delivery and user experience.

**AI-Powered Automation: Transforming ITSM**

AI-driven automation is poised to redefine ITSM by taking over routine tasks, such as password resets, troubleshooting, and system updates. This not only reduces the reliance on human intervention for repetitive support but also frees up IT staff to focus on higher-value tasks. With advancements in Natural Language Processing (NLP), AI agents can understand complex queries, improving response times and reducing human error.

**Experience-Driven ITSM: The Shift to XLAs**

Traditional Service Level Agreements (SLAs) have long focused on system uptime and response times. However, the shift towards Experience Level Agreements (XLAs) is gaining momentum. XLAs prioritise service quality and user satisfaction over mere technical performance. By integrating AI-driven monitoring and real-time sentiment analysis, IT teams can enhance IT services, improve user satisfaction, and align ITIL-driven services more closely with business goals.

**Enhanced AI Governance: Ethical and Effective AI Use**

As organizations increasingly rely on AI, the need for robust AI governance frameworks becomes paramount. These frameworks ensure ethical and effective AI use within ITSM, promoting transparency and accountability. By continuously monitoring AI performance and adjusting algorithms, organizations can maintain accuracy and improve service delivery.

**Holistic ITSM: Integrating Business Functions**

The future of ITSM lies in its integration with other business functions, such as Enterprise Resource Planning (ERP) systems and Customer Relationship Management (CRM) software. This holistic approach improves data sharing and decision-making across departments, aligning business goals with IT capabilities. By leveraging shared data, organizations can develop coordinated strategies that enhance service delivery and operational efficiency.

**Conclusion**

The integration of AI and ML into ITSM is not just a trend; it's a transformative shift that promises to enhance efficiency, improve user experience, and drive innovation. As we embrace these advancements, it's essential to balance AI's capabilities with the human touch, ensuring that technology serves to augment, not replace, human interactions. By adopting AI-driven ITSM solutions, organizations can stay ahead in the competitive landscape and deliver exceptional service to their users.

JIRA Service Management

Greetings!

Automation in JIRA Service Management (JSM) is revolutionising how teams handle their service requests and incident management. By leveraging powerful automation features, organisations can streamline workflows, reduce manual tasks, and improve overall efficiency. 

These automation capabilities allow teams to set up rules that trigger actions based on specific conditions, ensuring that repetitive tasks are handled automatically. This not only saves time but also minimises the risk of human error, leading to more consistent and reliable service delivery. 

Whether it's automating ticket assignments, sending notifications, or updating issue statuses, JSM’s automation features empower teams to focus on more strategic and value-added activities.

In this article, we will explore the possibilities available in JSM.

## Why automate?

Process automation in IT Service Management (ITSM) is a transformative approach that brings numerous advantages to businesses. By automating repetitive and time-consuming tasks, organisations can significantly enhance their operational efficiency.

This means that IT teams can focus on more strategic activities that require human expertise and creativity, rather than getting bogged down by mundane tasks. For instance, automating service desk processes can drastically improve the productivity of IT professionals by automatically assigning service requests to the best-suited IT employee and ensuring that all necessary documentation is stored correctly.

One of the most compelling benefits of IT process automation is the reduction in human errors. Automated processes follow precise instructions and are not susceptible to distractions, ensuring tasks are carried out consistently and accurately. This minimises the risk of costly mistakes and enhances the overall reliability of IT services.

Additionally, automation enables faster and more efficient responses to user requests, which can significantly enhance user satisfaction. Users receive quick and effective responses to their inquiries, leading to a better overall experience.

Moreover, IT process automation can lead to substantial cost savings for businesses. By reducing the need for manual intervention, organisations can lower their operational costs and allocate resources more effectively.

This not only improves the bottom line but also allows businesses to invest in other areas that drive growth and innovation. Furthermore, automation makes it easier to implement process changes and adapt to evolving business needs, providing a flexible and scalable solution for IT management.

## What is available?

### Project Settings

In order to access to automation functionality you need to navigate to **Project settings -> Automation**.  The screen that you will see first is the list of automation templates available to JSM. 

![Settings](https://res.cloudinary.com/xenos-design/image/upload/v1739439721/JSM/automation/img-01_kxmbtz.png)

The templates are grouped into areas such as.

- Rovo - Atlassian's AI capability\n- Service Management\n- Business\n- Change Management\n- Design\n- Human Resources\n- Information Technology (IT) - the largest group of templates

The templates cover scenarios from the manual triggering of request updates through to automatically triggering the running of functions, in MS Azure / AWS, based on set criteria, to run functions systems management functions e.g. reboot a server.

![ITSM templates](https://res.cloudinary.com/xenos-design/image/upload/v1739439721/JSM/automation/img-06_ofyllh.png)

The other tabs in the Automation area are.

**Rules** - which lists all the rules created in your project and allows you to; enable/disable a rule, copy a rule and filter by action type and/or label.

![Rules tab](https://res.cloudinary.com/xenos-design/image/upload/v1739439721/JSM/automation/img-02_aterxq.png)

**Audit log** - which lists all the changes made to your project's automation rules and can be filtered by.

- Date and time\n- Audit log ID\n- Action type\n- Triggers

![Audit log tab](https://res.cloudinary.com/xenos-design/image/upload/v1739439721/JSM/automation/img-03_iyjppt.png)

**Usage** - lists the project automation invocations, which can be filtered by month.

![Usage tab](https://res.cloudinary.com/xenos-design/image/upload/v1739439721/JSM/automation/img-04_enxvwk.png)

## Creating an automation rule

There are three ways to create an automation rule;

- Use a template, either as-is or as a starter\n- Use Atlassian’s AI capability\n- Start from a blank slate

Let’s explore these options in more detail.

### Using a Template

![Settings](https://res.cloudinary.com/xenos-design/image/upload/v1739439721/JSM/automation/img-01_kxmbtz.png)

To use a template, navigate to **Project settings -> Automation -> Templates** and select the template that you want to use from the list.

The rule configuration screen will open and you will be asked to enter the required data. I have selected the *When an incident is created → create a post-mortem page in Confluence* template so, as a minimum, I need to populate the fields marked with an asterisk.

![Template step 1](https://res.cloudinary.com/xenos-design/image/upload/v1739439721/JSM/automation/img-07_gdkkh5.png)

I then need to click on each element within the template and provide any additional information. For example, when I click on *Issue type equals* I am asked to provide a Field, Condition operator, and either Value or Field against which to assess the condition.

![Template step 2](https://res.cloudinary.com/xenos-design/image/upload/v1739439721/JSM/automation/img-08_mjayt8.png)

Clicking on **Next* takes me to the next element in the automation flow. In the example I am using, I am prompted to connect a Confluence instance where the post-mortem page will be created. Once linked, I specify additional information, so that the post-mortem pages are created in the area that I want

![Template step 3](https://res.cloudinary.com/xenos-design/image/upload/v1739439721/JSM/automation/img-09_dmsf6e.png)

At this point I could select **Next** and with the rule on… or I can add additional components to the automation and extend its usefulness.

To add an additional step, simply click on the **New component** element. You will see that the right-hand menu has changed as shown below.

![New component](https://res.cloudinary.com/xenos-design/image/upload/v1739441980/JSM/automation/img-10_mvtaxf.png)

When you click on **Then** you will be presented with a list actions to choose from. For this demo I have selected the *Send email* action and populated the template.

To add in details into the email from the contents of the issue record you use a double set of curly brackets with the attribute name inside, for example *{{issue.reporter.displayName}}*. Thankfully Atlassian don’t expect you to know these and, by clicking on the **{ }** icon in any field where you can add attribute details, provides a searchable list of available attributes.

![curly bracket options](https://res.cloudinary.com/xenos-design/image/upload/v1739441980/JSM/automation/img-12_bg69wt.png)

I then click on **Save** or **Update** to include the new element.

You can also add conditional statements into your automation flow by clicking on **IF: Add a condition**, you will see the following options.

![IF conditions](https://res.cloudinary.com/xenos-design/image/upload/v1739443876/JSM/automation/img-13_aukwuh.png)

As well as a **THEN** and **IF** you can also add a **FOR EACH** element which creates a branch in your automation.

![FOR EACH conditions](https://res.cloudinary.com/xenos-design/image/upload/v1739443875/JSM/automation/img-14_axbaz1.png)

You can add a branch that relates to the

- Current Issue\n- Sub-tasks of the current issue\n- Parent of the current issue\n- Children of the current issue\n- All created issues\n- Most recently created issue\n- Destination issues\n- Issues fixed in version\n- Issues fixed in Sprint\n- Similar issue description\n- JQL (JIRA Query Language) which creates a matchable search string\n- Stories or Epics in JIRA Software

![Branches](https://res.cloudinary.com/xenos-design/image/upload/v1739443876/JSM/automation/img-15_nxue4v.png)

### Use AI

If you want to use the Atlassian AI, to help generate your automation workflow, navigate to **Project settings -> Automation -> Templates**. 

![AI prompts](https://res.cloudinary.com/xenos-design/image/upload/v1739445942/JSM/automation/img-16_fab4kk.png)

The AI field is at the top of the screen. Once you have entered your requirement, click on **Preview rule** and Atlassian will generate an automation workflow based on the criteria you entered.

*Note: As with any Generative AI solution, getting the prompts correct is key to getting the most optimal outcome. My recommendation is to keep your prompts succinct and use ITSM-oriented language.*

![Proposed workflow](https://res.cloudinary.com/xenos-design/image/upload/v1739445942/JSM/automation/img-17_hcadrm.png)

From this screen, you can enter any required information, into the AI proposed elements, and add/remove components as described under the Template section above.

### Blank slate

If you want to create your automation workflow, from a blank slate, navigate to **Project settings -> Automation** and click on **Create**.

Once you have taken the tour, or skipped past it, you will see the following screen where you can art to create your workflow.

For example, the following shows the creation of a simple rule to email the reporter of an issue when the status is changed to ‘Waiting for Customer’.

First, set the *TRIGGER* condition, in this can *Issue Updated*. For this to work in JSM, you need to select an option from the *Issues* part of the list.

![Rule TRIGGER](https://res.cloudinary.com/xenos-design/image/upload/v1739448820/JSM/automation/img-18_iumzpq.png)

Next, I add an **IF** condition, where I specify the issue status.

![Rule IF](https://res.cloudinary.com/xenos-design/image/upload/v1739448819/JSM/automation/img-19_st1bzy.png)

And then a **THEN** action to send an email and populate the form as shown below.

![Rule THEN](https://res.cloudinary.com/xenos-design/image/upload/v1739448819/JSM/automation/img-20_zxtx9r.png)

I then click on **Turn on rule** to same and initiate the rule. I am prompted to specify a name for the automation rule, and which roles can edit it, and Atlassian makes the rule live.

You can just save the rule for further editing by clicking on the arrow, beside the **Turn on rule** button, and selecting the appropriate option.

## Conclusion

In summary, process automation in ITSM offers a multitude of benefits, including increased efficiency, reduced errors, enhanced user satisfaction, and cost savings. By leveraging automation, businesses can optimise their IT operations and focus on strategic initiatives that drive long-term success.

JSM provides an intuitive and robust solution to deliver automation in your ITSM environment.

Embrace the power of JSM and unlock new levels of productivity and reliability in your IT operations.

Hopefully, this has been useful to you and I wish you well on your ITSM journey…

Greetings!

In today's fast-paced IT environment, organisations need robust tools to manage their service management processes efficiently. JSM Premium offers a suite of advanced features designed to supercharge your IT service management (ITSM) practices and help your teams work smarter and faster.

In this article, we will be exploring the key features that come with upgrading to Premium and how to implement them.

I am splitting this article as follows:

- Part 1: Key Features and Customer Engagement\n- Part 2: ITSM Processes\n- Part 3: Asset Management, Governance and Security (this article)

## Asset Management

ITIL Asset Management, also known as IT Asset Management (ITAM), is a framework that assists organisations in efficiently managing their IT assets throughout their lifecycle. This process helps a company maximise value, limit costs, and manage risks by planning and driving the entire lifecycle of all IT assets.

IT Asset Management (ITAM) involves the systematic tracking and utilisation of an organisation’s assets, both physical and digital. It includes cataloguing, deploying, maintaining, upgrading, and responsibly disposing of assets to ensure their optimal use throughout their lifecycle. This lifecycle typically encompasses planning, procurement, deployment, maintenance, and retirement, with a focus on understanding the total cost of ownership and maximising asset value.

### Creating the schema

Once the Premium license has been procured, or you have started the free trial of Premium (currently 30 days), you can create the schema for your Asset Register. 

First, you click on **Assets**, found in the top menu on the screen. This will take you to the schema list page, from which you click on *Create schema*.

![All schemas screen](https://res.cloudinary.com/xenos-design/image/upload/v1738684972/JSM/premium/img-001_sagqu9.png)

You will be given the opportunity to choose an Atlassian template or start with a blank schema. I will be starting with the IT asset Management template for this demonstration.

![Schema template of blank selection](https://res.cloudinary.com/xenos-design/image/upload/v1738684971/JSM/premium/img-002_ub28am.png)

The next screen asks you to provide three pieces of information.

- Schema name\n- Key - this will be the prefix for all assets within this schema\n- Description

![Schema creation](https://res.cloudinary.com/xenos-design/image/upload/v1738684971/JSM/premium/img-003_hspxli.png)

Once you have provided the information you just need to click on *Create schema*. Your schema will be created and you will be redirected to the main view screen for the schema. 

![Main schema screen](https://res.cloudinary.com/xenos-design/image/upload/v1738684971/JSM/premium/img-004_pigj32.png)

From this screen, you will be able to.

- Amend the schema configuration\n- Add, amend or delete Object Types

![Schema config screen](https://res.cloudinary.com/xenos-design/image/upload/v1738684971/JSM/premium/img-007_zxo2ym.png)

As you will see from the below you can create the schema hierarchy to suit your needs by setting the *Parent* field. If you want a new top-level object you need to leave this field blank, see **Software Licenses** in the below screenshot as an example.

![Schema hierarchy](https://res.cloudinary.com/xenos-design/image/upload/v1738684970/JSM/premium/img-006_vv6xuy.png)

- Create objects (Configuration Items in ITIL terms), by clicking on an Object Type in the lowest part of your hierarchy (NMI Workstations in this example) and filling out the form that is presented to you. *Note: different object types have different field sets, so it is worth exploring these before committing to a particular type*

![Object creation form](https://res.cloudinary.com/xenos-design/image/upload/v1738684970/JSM/premium/img-009_pkknlv.png)

- Amend or delete objects from the schema by clicking on the menu shown below. You will see at the top of the object record the Unique ID for the record with the prefix *DEMO*

![Object record](https://res.cloudinary.com/xenos-design/image/upload/v1738684970/JSM/premium/img-010_z47xdd.png)

Now, this is all well and good if you only have a small number of assets to manage and their data is relatively static but, if you have thousands of assets that you need to manage, wouldn’t it be nice to be able to import assets into your Asset Register, either using an extract or through integration with a discovery tool.

### Importing Assets

JSM gives you the ability to import Asset Data from the *Schema Configuration* menu, which is accessed from the main schema view screen.

![Import screen](https://res.cloudinary.com/xenos-design/image/upload/v1738684970/JSM/premium/img-011_qlwlte.png)

From this screen, you can see all the imports that you have done previously, as well as creating a new import by clicking on the **Create import** button. You will need to

- Specify the import type that you want to use\n  - Discovery Import\n  - JSON file Import\n  - CSV file Import\n  - External Import\n- Define your import structure\n  - Import name or reference\n  - Add a description, as needed\n  - Identify the file, or its location, that you want imported\n  - Specify whether you want *Object Types* and *Structures* to be created based on the data in your file. This can be useful, if you are starting with a blank schema and want JSM to create based on the content structure of your file, but should be used with caution if you have manually created a schema or used a template\n  - Additional options include\n    - Being able to specify the encoding format of your data\n    - Specifying the character that will be used if data needs to be concatenated e.g. Field Office becomes Field-Office\n    - Whether to ignore or remove entries with no data\n    - Whether to add or ignore unknown values\n    - Specify a Date or Date/Time format

\n### Asset Reporting

There are a number of templated asset reports that are provided. These are accessed from the side menu, as shown below, from where you can click on **Create Report** which will open up the template selection screen.

![Main report screen](https://res.cloudinary.com/xenos-design/image/upload/v1738684970/JSM/premium/img-012_wxvfdi.png)

From here you simply specify a meaningful name for the report and select the template you want to use.

![Report template selection](https://res.cloudinary.com/xenos-design/image/upload/v1738684970/JSM/premium/img-013_mg6xwq.png)

From your selection, you will be taken to a report configuration screen. This is where you specify the schema, object types, object attributes etc, that you want your reports to be generated from. 

![Report config screen](https://res.cloudinary.com/xenos-design/image/upload/v1738684970/JSM/premium/img-014_hmufzp.png)

Once you click **Save** your report will be listed in the main *Reports* screen.

### Linking assets to records

Now having an accurate record of all of your assets is a splendid thing, which can be enhanced by creating custom fields and adding them to the screen for your various request types.

Linking ITSM Configuration Items (CIs) to ITSM process records is essential for several reasons:

1. **Enhanced Incident and Problem Resolution**: By understanding the relationships between CIs, organisations can quickly identify and resolve issues. This comprehensive view of system configurations and dependencies facilitates troubleshooting and enables faster root cause analysis\n2. **Improved Change Management**: Linking CIs to process records ensures that any changes made to the IT environment are well-documented and understood. This helps in evaluating the impact of changes and reduces the risk of unintended consequences\n3. **Effective Release Management**: Having detailed information about CIs and their relationships allows for better planning and execution of releases. This ensures that all components are correctly configured and reduces the likelihood of release failures\n4. **Efficient IT Service Management**: Configuration Management provides accurate and trustworthy information about IT services, supporting decision-making and service delivery. This helps in maintaining consistency in a product's functionality, physical characteristics, and performance\n5. **Risk Reduction**: Properly linking CIs to process records helps reduce the risk of interruptions and security breaches. It also minimises unnecessary duplication and ensures that all IT services, hardware, and software operate efficiently

**Example: Change Management**

Navigate to **Project settings -> Operations -> Change Management -> Assets**.

This screen enables you to link your asset records to Requests for Change (RfCs). This provides assurance that there is no ambiguity as to which specific assets an RfC relates to, and therefore the business risk of the change can be accurately assessed.

![Assets](https://res.cloudinary.com/xenos-design/image/upload/v1738769163/JSM/premium/img-032_crbxhg.png)

The two steps to do this are 1) creating a custom field that maps to your asset schema, and 2) adding that field to your change request types.

Let’s walk through this. Click on the **Create custom field** link and then the **Create custom field** button at the top right-hand of the screen that appears.

![Custom fields](https://res.cloudinary.com/xenos-design/image/upload/v1738835773/JSM/premium/img-035_f2soaz.png)

In the popup form, choose *Advanced* from the side menu and then the *Asset Objects* option. Now click on **Next**.

![Custom field](https://res.cloudinary.com/xenos-design/image/upload/v1738835773/JSM/premium/img-036_yqvndx.png)

Provide a name for the field and a description. Now click on **Create**.

From the list of Custom fields that will appear, click on the name of your newly created field, then open the Context tab and finally the *Create, edit or delete contexts* link.

From this screen click on the *Edit Assets object/s field configuration* link.

![Add scema](https://res.cloudinary.com/xenos-design/image/upload/v1738835773/JSM/premium/img-039_pcith7.png)

In the next screen, you need to specify, as a minimum.

- Object schema - your asset schema\n- Which fields users can search against in the custom field\n- Which field will appear in the field for the issue view\n- Whether the field allows multiple selects, crucial if your RfCs will relate to more than one asset

Clock on **Save** when ready.

![Schema config](https://res.cloudinary.com/xenos-design/image/upload/v1738835773/JSM/premium/img-040_zmlzo1.png)

Now navigate back to the **Project settings -> Operations -> Change management -> Assets** screen and click on the **Request a change** link. *Note: if you have more than one request type under for changes these will all be listed here*.

Now drag your new custom field from the right-hand of the screen and place it where you want it to be in the list of existing fields. Once you are ready, click on **Save Changes**.

![Add custom field to request type form](https://res.cloudinary.com/xenos-design/image/upload/v1738835773/JSM/premium/img-038_gucdvz.png)

Your field is now visible whenever someone creates or views the assigned request type(s).

## Governance and Security

### Enhanced Security / Governance Controls

The Premium license model provides additional security and governance capability enhancements for JSM. These are;

* **Audit Logs** - Troubleshoot a problem or keep a record of important events, like changes to global permissions\n* **Data Residency** - Choose where key product data at rest is hosted within Atlassian’s global cloud footprint. This helps your business where legislation mandates where data should be held e.g. [GDPR](https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng), [HIPAA](https://www.hhs.gov/hipaa/for-professionals/index.html) etc\n* **Admin Insights** - Gain a better understanding of your product usage with data, like usage, security, and access insights\n* **IP Allowlisting** (White Listing) - Limit site access to trusted IP ranges, giving an extra layer of access security\n* **Sandbox** - Test and control the rollout of updates and new apps in a sandbox copy of your environment\n* **Release Tracks** - With the option to control Atlassian cloud releases, control when and how changes are released to end users

### Single Sign On (SSO) integration (AD / SAML)

Premium also gives you the ability to implement an SSO integration with your project. I have covered this in the 5th post of this series, which can be found [here](https://blog.stevengodson.com/series#JSM).

## Conclusion

In summary, JSM Premium is a comprehensive solution tailored for modern IT service management needs. By harnessing its advanced features, organisations can; streamline their service management processes, enhance efficiency, and provide exceptional service delivery. 

From advanced incident management to AI-powered capabilities, and robust support to enhanced security, JSM Premium equips teams with the tools they need to excel in a fast-paced digital landscape. 

Embrace the power of JSM Premium and unlock new levels of productivity and reliability in your IT operations.

Hopefully, this has been useful to you and I wish you well on your ITSM journey…

Service Excellence

IT security operations (SecOps) involve protecting an organisation’s IT infrastructure, data, and users from cyber threats. This requires a combination of proactive measures, incident response, and continuous monitoring. Integrating the Japanese philosophy of **Ichi-go Ichi-e** can offer unique and valuable benefits to IT security operations.

**Ichi-go Ichi-e**, meaning "one time, one meeting," emphasises the uniqueness and irreproducibility of each moment. This mindfulness philosophy encourages presence, appreciation, and attention to detail, which can significantly enhance IT security operations.

## 1. Improved Incident Response

Approaching each security incident with the Ichi-go Ichi-e mindset ensures that IT professionals are fully present and focused on the specific threat at hand. This heightened attention can lead to quicker identification of attack vectors, more effective containment measures, and faster resolution of incidents, thereby minimising potential damage.

## 2. Enhanced Threat Analysis

Treating each threat as a unique and valuable learning opportunity fosters a deeper and more thorough analysis. This approach can help security teams uncover subtle patterns, understand attacker behaviour, and develop more robust defences against future attacks.

## 3. Better Communication and Collaboration

SecOps require seamless collaboration between various teams, including IT, security, and compliance. Embracing Ichi-go Ichi-e fosters mindful and respectful communication, ensuring that all parties are fully engaged and understood. This can lead to stronger collaboration, better decision-making, and a more cohesive security posture.

## 4. Increased Efficiency and Productivity

By focusing on the present moment and giving full attention to each task, IT security professionals can work more efficiently and effectively. This mindfulness can lead to higher-quality work, reduced errors, and faster completion of tasks, ultimately boosting overall productivity.

## 5. Enhanced User Awareness and Training

Applying Ichi-go Ichi-e to user interactions ensures that each training session, awareness campaign, and security briefing is conducted with full attention and appreciation for the unique needs of the audience. This can lead to more effective training outcomes and a higher level of security awareness among users.

## 6. Reduced Stress and Burnout

The demanding nature of SecOps can lead to stress and burnout among security professionals. Adopting the principles of Ichi-go Ichi-e encourages a mindful approach to work, helping individuals stay calm and composed even during high-pressure situations. This can lead to a healthier work environment and improved well-being for security staff.

## 7. Continuous Improvement

Viewing each security incident and threat analysis as a unique learning opportunity aligns with the philosophy of continuous improvement. By reflecting on the lessons learned from each incident and interaction, security teams can identify areas for enhancement and implement changes that drive ongoing improvement.

## Conclusion

Integrating Ichi-go Ichi-e into IT security operations brings a mindful and human-centred approach to a traditionally technical field. By fostering presence, attention to detail, improved communication, and a focus on continuous improvement, IT security professionals can enhance the effectiveness and efficiency of their operations. As the cyber threat landscape continues to evolve, embracing the timeless wisdom of Ichi-go Ichi-e can provide a significant advantage in safeguarding an organisation’s digital assets and ensuring the smooth functioning of business processes

IT operations encompass a wide range of activities aimed at managing and maintaining an organisation’s IT infrastructure to ensure smooth and efficient business processes. While technical expertise and procedural rigour are essential, integrating the Japanese concept of **Ichi-go Ichi-e** can bring a refreshing and highly beneficial perspective to IT operations.

**Ichi-go Ichi-e**, meaning "one time, one meeting," emphasises the uniqueness and irreproducibility of each moment. This mindfulness philosophy encourages presence, appreciation, and attention to detail, which can significantly enhance IT operations.

## 1. Improved Incident Response

Approaching each incident with the Ichi-go Ichi-e mindset ensures that IT professionals are fully present and focused on resolving the issue at hand. This heightened attention can lead to quicker identification of root causes and more effective solutions, minimising downtime and reducing the impact on business operations.

## 2. Enhanced Preventative Maintenance

Treating each maintenance activity as a unique opportunity to ensure the health of IT systems encourages thoroughness and attention to detail. This proactive approach can help identify potential issues before they escalate into major problems, leading to more reliable and resilient IT infrastructure.

## 3. Better Communication and Collaboration

IT operations often involve coordination between various teams and stakeholders. Embracing Ichi-go Ichi-e fosters mindful and respectful communication, ensuring that all parties are fully engaged and understood. This can lead to stronger collaboration, better decision-making, and a more cohesive team environment.

## 4. Increased Efficiency and Productivity

By focusing on the present moment and giving full attention to each task, IT professionals can work more efficiently and effectively. This mindfulness can lead to higher-quality work, reduced errors, and faster completion of tasks, ultimately boosting overall productivity.

## 5. Enhanced Customer Satisfaction

Applying Ichi-go Ichi-e to customer interactions ensures that each user feels valued and appreciated. By being fully present and attentive during support interactions, IT professionals can provide a higher level of service, leading to improved customer satisfaction and loyalty.

## 6. Reduced Stress and Burnout

The demanding nature of IT operations can lead to stress and burnout among IT professionals. Adopting the principles of Ichi-go Ichi-e encourages a mindful approach to work, helping individuals stay calm and composed even during high-pressure situations. This can lead to a healthier work environment and improved well-being for IT staff.

## 7. Continuous Improvement

Viewing each operational activity as a unique learning opportunity aligns with the philosophy of continuous improvement. By reflecting on the lessons learned from each incident, maintenance task, and interaction, IT teams can identify areas for enhancement and implement changes that drive ongoing improvement.

## Conclusion

Integrating Ichi-go Ichi-e into IT operations brings a mindful and human-centred approach to a traditionally technical field. By fostering presence, attention to detail, improved communication, and a focus on continuous improvement, IT professionals can enhance the effectiveness and efficiency of their operations. As the IT landscape continues to evolve, embracing the timeless wisdom of Ichi-go Ichi-e can provide a significant advantage in delivering exceptional IT services and ensuring the smooth functioning of business processes.

DevOps, the amalgamation of development and operations, emphasises collaboration, automation, and continuous improvement to deliver high-quality software rapidly and efficiently. While technical methodologies are at its core, integrating the Japanese philosophy of **Ichi-go Ichi-e** can provide profound enhancements to the DevOps culture and practices.

**Ichi-go Ichi-e**, meaning "one time, one meeting," emphasises the uniqueness and irreplaceability of each moment. This mindfulness philosophy encourages presence, appreciation, and attention to detail, which can significantly benefit DevOps.

## 1. Enhanced Focus on Each Deployment

Treating each deployment with the Ichi-go Ichi-e mindset ensures that every release is given the attention and care it deserves. This heightened focus can lead to more thorough testing, validation, and monitoring, resulting in higher-quality software releases with fewer issues.

## 2. Improved Collaboration and Communication

DevOps relies heavily on collaboration between development and operations teams. By embracing Ichi-go Ichi-e, team members are encouraged to be fully present and engaged in their interactions. This can lead to more meaningful and productive communication, fostering a stronger sense of teamwork and mutual respect.

## 3. Increased Responsiveness to Feedback

Viewing each piece of feedback as a unique opportunity to improve aligns perfectly with the DevOps culture of continuous improvement. By treating feedback with mindfulness and appreciation, teams can more effectively address user concerns and enhance their products based on real-world experiences.

## 4. Reduced Stress and Burnout

The fast-paced nature of DevOps can lead to stress and burnout. Applying Ichi-go Ichi-e encourages individuals to approach their work with mindfulness, helping them stay calm and composed even under pressure. This can lead to a healthier work environment and improved well-being for team members.

## 5. Better Incident Management

In the event of an incident, approaching it with the Ichi-go Ichi-e mindset can lead to more focused and effective problem-solving. By fully engaging with the incident at hand, teams can quickly identify root causes, implement solutions, and document learnings for future reference.

## 6. Enhanced Innovation and Creativity

Mindfulness fosters an open-minded and reflective approach to problem-solving. By embracing Ichi-go Ichi-e, DevOps teams can tap into their creativity and explore innovative solutions that might not have been considered otherwise. This can lead to more effective and forward-thinking development practices.

## 7. Stronger Continuous Improvement Culture

The philosophy of Ichi-go Ichi-e aligns with the DevOps principle of continuous improvement. By treating each sprint, each deployment, and each feedback loop as unique opportunities for learning and growth, teams can continually refine their processes and deliver better outcomes.

## Conclusion

Integrating Ichi-go Ichi-e into DevOps brings a mindful and human-centered approach to a fast-paced and technical discipline. By fostering attention to detail, improved collaboration, better incident management, and a culture of continuous improvement, DevOps teams can enhance their effectiveness and achieve greater success. As the tech landscape continues to evolve, embracing the wisdom of Ichi-go Ichi-e can provide a significant advantage in delivering high-quality software and fostering a positive work environment.

Change management within IT Service Management (ITSM) involves the controlled process of managing changes to IT services, ensuring minimal disruption and maintaining service quality. While technical procedures and frameworks are essential, integrating the Japanese concept of **Ichi-go Ichi-e** can offer valuable insights and improvements to this critical function.

**Ichi-go Ichi-e**, meaning "one time, one meeting," emphasises the uniqueness and irreplaceability of each moment. This mindfulness philosophy encourages presence, appreciation, and attention to detail, which can significantly benefit ITSM Change Management.

## 1. Enhanced Attention to Detail

Approaching each change with the Ichi-go Ichi-e mindset means giving full attention to every aspect of the change process. This thoroughness can lead to more accurate impact assessments, risk evaluations, and implementation plans, reducing the likelihood of errors and unforeseen issues.

## 2. Improved Stakeholder Engagement

Viewing each change as a unique event fosters a more considerate and collaborative approach to stakeholder engagement. By valuing each interaction and ensuring that all voices are heard, change managers can build stronger relationships with stakeholders, gaining their trust and support for the change.

## 3. Better Change Documentation

Mindfulness in the documentation process ensures that each change is recorded with precision and clarity. Detailed documentation helps create a comprehensive change history, which can be invaluable for future reference, audits, and continuous improvement initiatives.

## 4. Reduced Resistance to Change

When change managers are fully present and empathetic during the change process, they can better understand and address the concerns of those affected by the change. This approach can help mitigate resistance and foster a more positive attitude towards the change, leading to smoother implementations.

## 5. Increased Flexibility and Adaptability

The philosophy of Ichi-go Ichi-e encourages an open-minded and flexible approach to each unique change. This adaptability allows change managers to respond more effectively to unexpected challenges and to tailor their strategies to the specific needs of each situation.

## 6. Enhanced Learning and Improvement

Treating each change as an opportunity to learn and improve aligns with the continuous improvement mindset central to ITSM. By reflecting on the unique aspects and outcomes of each change, teams can identify best practices and areas for enhancement, leading to more effective change management over time.

## 7. Strengthened Team Collaboration

Applying Ichi-go Ichi-e principles can foster a culture of mutual respect and cooperation within the change management team. When team members approach their work with mindfulness and appreciation for each other's contributions, it can lead to stronger collaboration and more innovative solutions.

## Conclusion

Integrating Ichi-go Ichi-e into ITSM Change Management brings a mindful and human-centred approach to a structured process. By fostering attention to detail, improved stakeholder engagement, better documentation, and a culture of continuous improvement, IT professionals can enhance the effectiveness and success of change initiatives. As the IT landscape evolves, embracing the wisdom of Ichi-go Ichi-e can provide a significant advantage in managing changes with grace and efficiency.

Greetings!

In today's fast-paced IT environment, organisations need robust tools to manage their service management processes efficiently. JSM Premium offers a suite of advanced features designed to supercharge your IT service management (ITSM) practices and help your teams work smarter and faster.

In this article, we will be exploring the key features that come with upgrading to Premium and how to implement them.

I am splitting this article as follows:

- Part 1: Key Features and Customer Engagement\n- Part 2: ITSM Processes (this article)\n- Part 3: Asset Management, Governance and Security

## ITSM Processes

### Problem Management

Problem Management in ITIL v4 is a practice aimed at reducing the likelihood and impact of incidents by identifying actual and potential causes of incidents and managing workarounds and known errors. The practice is divided into three main phases:

1. **Problem Identification**: Activities for identifying problems include analysing incident records and identifying duplicate and recurring problems.\n2. **Problem Control**: After identifying problems, this phase involves taking a closer look at them to understand their nature and impact.\n3. **Error Control**: This phase handles recognised mistakes and may allow for the development of potential long-term fixes.

The purpose of Problem Management is to ensure that errors causing incidents are identified, understood, and eliminated quickly and reliably. This helps organisations to move away from daily firefighting and focus on more valuable work.

#### How to switch it on

Problem Management can be switched on by navigating to **Project Settings -> Features** and clicking on the switch at the top right-hand of the Problem Management card.

![Features](https://res.cloudinary.com/xenos-design/image/upload/v1738762236/JSM/premium/img-021_ldo7wz.png)

You will see this message appear at the bottom of the screen.

![Pop-upl](https://res.cloudinary.com/xenos-design/image/upload/v1738762236/JSM/premium/img-022_yrff0l.png)

If you opt to add a request type at this stage you will be taken to the following screen where you can add a request type from…

![Problem request types](https://res.cloudinary.com/xenos-design/image/upload/v1738762236/JSM/premium/img-023_h5dwqz.png)

An Atlassian template…

![Templates](https://res.cloudinary.com/xenos-design/image/upload/v1738762237/JSM/premium/img-024_oszoif.png)

From a blank request type…

![Blank request type](https://res.cloudinary.com/xenos-design/image/upload/v1738762238/JSM/premium/img-025_uwcevu.png)

Or using AI.

![AI](https://res.cloudinary.com/xenos-design/image/upload/v1738762237/JSM/premium/img-026_jy0n9r.png)

#### Managing the request type

Once created you will be able to customise the Problem record through **Project settings -> Request management -> Request types -> Problems**.  

You can configure the request form, used to raise a Problem, the issue view, used by those with the Service Desk Agent role to manage Problems and review/change the workflow statuses. 

You can also view and edit the processes workflow, if required, to align with your business's Problem Management process.

![Manage request type](https://res.cloudinary.com/xenos-design/image/upload/v1738764089/JSM/premium/img-028_oa5oe6.png)

### Post Incident Reviews

#### What is it?

A **Post Incident Review (PIR)** in ITIL v4 is a formal meeting or process that takes place after an incident has been resolved. The goal of a PIR is to analyse the incident, understand its causes, and assess the incident management process itself. This review provides an opportunity for key stakeholders to review the incident, share insights, and document lessons learned. 

The PIR is critical for organisations because it:

* **Uncovers Root Causes**: Identifies the underlying technical and process failures that contributed to the incident\n* **Promotes Learning**: Provides a structured environment for teams to learn from mistakes or missteps\n* **Improves Future Response**: Leads to actionable recommendations that enhance the organisation’s ability to respond to and prevent future incidents\n* **Ensures Accountability**: Ensures that action items are assigned to responsible teams or individuals to prevent recurrence

#### Creating and managing a request type

Creating and managing a PIR request type is the same as Problem Management, so I will not be repeating this. 

![Post implementation review](https://res.cloudinary.com/xenos-design/image/upload/v1738764796/JSM/premium/img-029_rfyes8.png)

### Change Management

#### What is it?\nITIL v4 Change Management, also known as Change Enablement, is a practice within the IT Service Management (ITSM) framework designed to manage changes in a controlled and systematic manner. The primary objective of Change Management is to minimise the risk associated with changes while ensuring that beneficial changes are implemented efficiently.

Key aspects of ITIL v4 Change Management include:

* **Evaluation and Approval**: Assessing the potential impacts of changes and obtaining necessary approvals.\n* **Implementation**: Executing changes in a structured way to reduce risks and increase operational efficiency.\n* **Risk Management**: Identifying and managing risks associated with changes to prevent service interruptions and ensure stability.

#### Creating and managing a request type

Creating and managing a PIR request type is the same as Problem Management, so I will not be repeating this. However, I will highlight that there are plenty on templates to choose from, which allows you to have a request type for most conceivable ITSM scenarios, either out of the box or by customising a template.

![Change management](https://res.cloudinary.com/xenos-design/image/upload/v1738765171/JSM/premium/img-030_avecxc.png)

#### Change management operations

The **Change Management** functionality also opens up an entry under the **Project settings -> Operations** menu which gives you the following functionality.

##### Deployment pipelines

Connecting your Continuous Integration and Continuous Delivery (CI/CD) pipeline with your Change Management process is a great way to ensure that any modifications to production systems are carefully reviewed and approved. By integrating it with CI/CD, you maintain a high level of reliability while benefiting from the speed and automation of CI/CD

![CICD](https://res.cloudinary.com/xenos-design/image/upload/v1738769164/JSM/premium/img-031_pxbrw7.png)

##### Assets

This screen enables you to link your asset records to Requests for Change (RfCs). This provide assurance that there is no ambiguity as to which specific assets an RfC relates to, and therefore the business risk of the change can be accurately assessed.

![Assets](https://res.cloudinary.com/xenos-design/image/upload/v1738769163/JSM/premium/img-032_crbxhg.png)

The two steps to do this are 1) creating a custom field that maps to your asset schema, and 2) adding that field to your change request types.

Let’s walk through this. Click on the **Create custom field** link and then the **Create custom field** button at the top right-hand of the screen that appears.

![Custom fields](https://res.cloudinary.com/xenos-design/image/upload/v1738835773/JSM/premium/img-035_f2soaz.png)

In the popup form, choose *Advanced* from the side menu and then the *Asset Objects* option. Now click on **Next**.

![Custom field](https://res.cloudinary.com/xenos-design/image/upload/v1738835773/JSM/premium/img-036_yqvndx.png)

Provide a name for the field and a description. Now click on **Create**.

From the list of Custom fields that will appear, click on the name of your newly created field, then open the Context tab, and finally the *Create, edit or delete contexts* link.

From this screen click on the *Edit Assets object/s field configuration* link.

![Add scema](https://res.cloudinary.com/xenos-design/image/upload/v1738835773/JSM/premium/img-039_pcith7.png)

On the next screen you need to specify, as a minimum.

- Object schema - your asset schema\n- Which fields users can search against in the custom field\n- Which field will appear in the field for the issue view\n- Whether the field allows multiple selects, crucial if your RfCs will relate to more than one asset

Click on **Save** when ready.

![Schema config](https://res.cloudinary.com/xenos-design/image/upload/v1738835773/JSM/premium/img-040_zmlzo1.png)

Now navigate back to the **Project settings -> Operations -> Change management -> Assets** screen and click on the **Request a change** link. *Note: if you have more than one request type under for changes these will all be listed here*.

Now drag your new custom field from the right-hand of the screen and place it where you want it to be in the list of existing fields. Once you and ready click on **Save Changes**.

![Add custom field to request type form](https://res.cloudinary.com/xenos-design/image/upload/v1738835773/JSM/premium/img-038_gucdvz.png)

Your field is now visible whenever someone creates or views the assigned request type(s).

##### Risk insights

This area lets you set.

- Which risk insights tabs are visible on the *View* screen for Change request types\n- Specify the status to be used for rejected changes and specify time windows if you want to show rejected changes\n- Specify the time window if you want to show failed deployments\n- Create standard forms for use within your Change request type to drive consistency of data capture

![Risks](https://res.cloudinary.com/xenos-design/image/upload/v1738838108/JSM/premium/img-041_ivtsse.png)

##### Other settings

This area links to.

- The list of services that you may or may not have configured within your project. Services are separate from assets as they relate to a service that is delivered to a customer and may consist of one or more assets\n- The automation area of the project where you can create automation rules using existing templates on Atlassian’s AI tool

![Other settings](https://res.cloudinary.com/xenos-design/image/upload/v1738769163/JSM/premium/img-034_bzocfn.png)

## Advanced Alert Integration

Premium gives you the ability to integrate JSM with one or more Enterprise Management tools. This means that your service desk agents will have visibility of alerts that have been generated in your service(s) and, depending on how much automation you want to use, go from automatically raising Incidents to automating Incident response and resolution.

This is a large topic, which deserves a detailed look, so I will cover this later in the series.

## Conclusion

In summary, JSM Premium stands out as a comprehensive solution tailored for modern IT service management needs. By harnessing its advanced features, organisations can streamline their service management processes, enhance efficiency, and provide exceptional service delivery. 

From advanced incident management to AI-powered capabilities, and robust support to enhanced security, JSM Premium equips teams with the tools they need to excel in a fast-paced digital landscape. 

Embrace the power of JSM Premium and unlock new levels of productivity and reliability in your IT operations.

Hopefully, this has been useful to you and I wish you well on your ITSM journey…

In the fast-paced world of IT Service Management (ITSM), incident management is a critical function that ensures the continuity of business operations and the swift resolution of IT issues. Amidst the technical and procedural rigour of ITSM, a Japanese concept known as **Ichi-go Ichi-e** can offer a refreshing and highly beneficial perspective.

**Ichi-go Ichi-e** translates to "one time, one meeting" or "for this time only." It emphasises the uniqueness and irreproducibility of each moment, encouraging mindfulness, presence, and appreciation for the here and now. Applying this philosophy to ITSM Incident Management can bring several significant benefits:

## 1. Enhanced Focus and Presence

When IT professionals approach each incident with the mindset of Ichi-go Ichi-e, they become fully present and focused on the task at hand. This heightened attention can lead to a more thorough and accurate diagnosis of issues, reducing the likelihood of overlooking critical details.

## 2. Improved Customer Satisfaction

Treating each incident as a unique opportunity to provide excellent service fosters a customer-centric approach. By valuing each interaction with the end-user, IT support teams can build stronger relationships, ensuring that users feel heard, respected, and valued. This can lead to higher levels of customer satisfaction and loyalty.

## 3. Reduced Stress and Burnout

The high-pressure environment of incident management often leads to stress and burnout among IT professionals. Adopting Ichi-go Ichi-e encourages a mindful approach to work, helping individuals stay calm and composed, even in the face of challenging situations. By taking each incident one at a time and fully engaging with it, IT professionals can avoid feeling overwhelmed by the volume of incidents.

## 4. Increased Collaboration and Team Cohesion

When team members embrace the principles of Ichi-go Ichi-e, they are more likely to engage in meaningful and respectful communication. This fosters a collaborative environment where ideas and solutions are freely shared, leading to more effective problem-solving and a cohesive team dynamic.

## 5. Continuous Improvement

Viewing each incident as a unique learning opportunity encourages a culture of continuous improvement. By reflecting on the lessons learned from each incident, IT teams can identify patterns, uncover root causes, and implement preventative measures to reduce the likelihood of future incidents.

## 6. Enhanced Incident Documentation

Mindfulness in incident management extends to the documentation process. When IT professionals approach each incident with the intention of capturing its unique aspects, they produce more detailed and accurate records. This improved documentation can serve as a valuable resource for future incidents, providing insights and references that enhance the overall effectiveness of the ITSM process.

## Conclusion

Incorporating Ichi-go Ichi-e into ITSM Incident Management brings a human-centred approach to a traditionally technical field. By fostering mindfulness, presence, and appreciation for each unique incident, IT professionals can improve their focus, reduce stress, enhance customer satisfaction, and promote continuous improvement. As the IT landscape continues to evolve, embracing the timeless wisdom of Ichi-go Ichi-e can offer a significant competitive advantage in delivering exceptional IT services.

In the fast-paced world of IT Service Management (ITSM), efficiency and effectiveness are often prioritised. However, integrating the Japanese philosophy of "ichi-go ichi-e" (一期一会), which translates to "one time, one meeting," can bring a unique and valuable perspective to managing service requests. This philosophy emphasises treasuring each moment and encounter, treating it as a once-in-a-lifetime opportunity. By applying "ichi-go ichi-e" to ITSM, organisations can enhance the quality of their service and improve customer satisfaction.

#### Understanding "Ichi-go Ichi-e"

"Ichi-go ichi-e" encourages individuals to fully appreciate and value each unique moment and interaction. Originating from the Japanese tea ceremony, this concept can be applied to various aspects of life, including business and customer service. By embracing this philosophy, ITSM professionals can transform routine service requests into meaningful and memorable experiences.

#### Applying "Ichi-go Ichi-e" to Service Request Management

1. **Personalised Interactions**: Each service request should be approached as a unique encounter. Personalise interactions by addressing users by their names, understanding their specific needs, and providing tailored solutions. This creates a sense of importance and appreciation for each user.

2. **Active Listening**: Practice active listening to fully understand the user's concerns and requirements. By giving undivided attention to each service request, ITSM professionals can gather valuable insights and provide more accurate and effective solutions.

3. **Empathy and Understanding**: Show empathy and understanding towards users' challenges. Acknowledge their frustrations and reassure them that their issues are being taken seriously. This humanises the interaction and builds trust between users and ITSM professionals.

4. **Timeliness and Quality**: Treat each service request as a priority and strive to resolve issues promptly and efficiently. Ensure that the quality of the solution is not compromised by time constraints. A timely and high-quality response reflects the value placed on the user's unique situation.

5. **Continuous Improvement**: After resolving a service request, seek feedback from users to understand their experience. Use this feedback to continuously improve service delivery and ensure that future interactions are even more valuable.

#### Benefits of "Ichi-go Ichi-e" in ITSM

- **Enhanced User Experience**: By valuing each service request as a unique opportunity, users feel appreciated and respected, leading to higher satisfaction levels.n- **Improved Trust and Loyalty**: Personalised and empathetic interactions foster trust and loyalty, encouraging users to return for future services.n- **Increased Efficiency**: Active listening and a thorough understanding of user needs result in more accurate and efficient resolutions, reducing the need for repeat requests.n- **Positive Workplace Culture**: Embracing "ichi-go ichi-e" cultivates a positive and respectful workplace culture, motivating ITSM professionals to deliver their best.

#### Conclusion

Incorporating the philosophy of "ichi-go ichi-e" into IT Service Management can transform the way service requests are managed. By treating each interaction as a unique and valuable moment, ITSM professionals can enhance the user experience, build trust, and improve overall service quality. In a world where technology often dominates, bringing a human touch to ITSM can make all the difference.nnBy embracing "ichi-go ichi-e," IT organisations can ensure that each service request is not just a task to be completed but an opportunity to create a lasting positive impact.

In the fast-paced world of Information Technology Service Management (ITSM), maintaining meaningful engagement with users and stakeholders can often be a challenging endeavour. However, there is a unique concept from Japanese culture that can significantly enhance ITSM engagement: Ichi-go Ichi-e (一期一会).

## Understanding Ichi-go Ichi-e

Ichi-go Ichi-e, which translates to \"one time, one meeting,\" is a Japanese idiom often used in the context of the traditional tea ceremony. It encapsulates the idea that each encounter is unique and will never happen again in exactly the same way. This philosophy encourages individuals to cherish each moment and interaction, recognising its singular importance.

## Applying Ichi-go Ichi-e to ITSM

Incorporating the principle of Ichi-go Ichi-e into ITSM practices can lead to more meaningful and effective engagement. Here’s how:

### 1. Personalising User Interactions

Each interaction with a user or stakeholder is an opportunity to create a lasting impression. By embracing the concept of Ichi-go Ichi-e, ITSM professionals can focus on personalising each encounter, addressing individual needs, and showing genuine care and attention. This can build stronger relationships and foster trust.

### 2. Enhancing Customer Experience

Ichi-go Ichi-e encourages ITSM teams to view each service request or incident as a unique event. By treating every service interaction as a one-of-a-kind experience, teams can enhance the overall customer experience, ensuring that users feel valued and understood. This approach can lead to higher satisfaction rates and positive feedback.

### 3. Encouraging Active Listening

The philosophy of Ichi-go Ichi-e emphasises the importance of being fully present in the moment. For ITSM professionals, this means actively listening to users’ concerns and feedback without distractions. By practicing active listening, teams can better understand user needs, leading to more effective problem-solving and service delivery.

### 4. Promoting Continuous Improvement

Recognising the uniqueness of each interaction allows ITSM teams to learn and improve continuously. By reflecting on each engagement, identifying areas for improvement, and celebrating successes, teams can evolve their practices and deliver better services over time.

### 5. Fostering a Culture of Respect

Ichi-go Ichi-e teaches respect for the present moment and for the individuals involved. In ITSM, this translates to respecting users' time, opinions, and experiences. By fostering a culture of respect, ITSM teams can create a positive and collaborative environment, enhancing overall engagement and productivity.

## Conclusion

Incorporating the concept of Ichi-go Ichi-e into ITSM practices offers a fresh perspective on engagement. By cherishing each interaction as unique and significant, ITSM professionals can build stronger relationships, enhance customer experiences, and promote continuous improvement. Embracing Ichi-go Ichi-e can transform the way ITSM teams connect with users, leading to more meaningful and impactful engagements.

As we move forward in an ever-evolving technological landscape, let us remember the wisdom of Ichi-go Ichi-e and the value of each unique encounter.

The concept of Ichi-go Ichi-e, emphasising the uniqueness of each moment and interaction, can significantly enhance engagement in Information Technology Service Management (ITSM). However, to effectively incorporate and measure this philosophy within an ITSM environment, Experience Level Agreements (XLAs) can be a valuable tool. XLAs focus on the end-user experience rather than just service-level metrics, making them an ideal framework for assessing the impact of Ichi-go Ichi-e.

## Understanding XLAs

XLAs are agreements that define the desired user experience and outcomes in IT services. Unlike traditional Service Level Agreements (SLAs), which measure technical performance metrics such as uptime and response time, XLAs concentrate on the quality of the user experience, satisfaction, and overall engagement. By using XLAs, ITSM teams can ensure that they are meeting the users' expectations and providing a meaningful, impactful service.

## Measuring Ichi-go Ichi-e with XLAs

To measure the application of Ichi-go Ichi-e within an ITSM environment, it is essential to establish XLAs that capture the essence of this concept. Here are some key steps to achieve this:

### 1. Define User Experience Metrics

Identify and define metrics that align with the principles of Ichi-go Ichi-e. These metrics should focus on the uniqueness and quality of each user interaction. Examples include:\n- **Personalisation Index**: Measure the extent to which service interactions are tailored to individual users' needs and preferences.\n- **Engagement Score**: Assess how engaged and involved users feel during their interactions with IT services.\n- **Satisfaction Rate**: Capture overall user satisfaction with the service provided.

### 2. Collect Qualitative Feedback

In addition to quantitative metrics, gather qualitative feedback from users to gain deeper insights into their experiences. Use surveys, interviews, and feedback forms to understand how users perceive the uniqueness and value of each interaction. Questions to consider include:\n- How personalised did you feel your service experience was?\n- Did the service interaction meet your unique needs and expectations?\n- How likely are you to recommend our IT services to others?

### 3. Monitor Real-Time Data

Utilise real-time data analytics to monitor user interactions and experiences continuously. Track metrics such as response times, resolution times, and user sentiment during each service interaction. Real-time monitoring allows ITSM teams to identify trends and make adjustments to improve user experiences on the fly.

### 4. Conduct Experience Reviews

Regularly review and analyse user experiences to identify areas for improvement. Hold experience review sessions where ITSM teams can discuss feedback, reflect on recent interactions, and brainstorm ways to enhance the uniqueness and quality of service. Use this information to refine XLAs and ensure they remain aligned with the Ichi-go Ichi-e philosophy.

### 5. Foster a Culture of Continuous Improvement

Encourage a culture of continuous improvement within the ITSM team. Emphasise the importance of learning from each interaction and making incremental enhancements to service delivery. By fostering a mindset of continuous improvement, ITSM teams can consistently elevate the user experience and embody the principles of Ichi-go Ichi-e.

## Conclusion

Incorporating the concept of Ichi-go Ichi-e into an ITSM environment can transform the way IT services are delivered and experienced. By using XLAs to measure the uniqueness and quality of each interaction, ITSM teams can ensure they are providing meaningful, personalised, and engaging services. Embracing Ichi-go Ichi-e through XLAs not only enhances user satisfaction but also fosters a culture of continuous improvement and respect for each unique encounter.

As we continue to navigate the evolving landscape of ITSM, let us remember the wisdom of Ichi-go Ichi-e and strive to create memorable and impactful experiences for every user.

Greetings!

In today's fast-paced IT environment, organisations need robust tools to manage their service management processes efficiently. JSM Premium offers a suite of advanced features designed to supercharge your IT service management (ITSM) practices and help your teams work smarter and faster.

In this article, we will be exploring the key features that come with upgrading to Premium and how to implement them.

I am splitting this article as follows:

- Part 1: Key Features and Customer Engagement (this article)\n- Part 2: ITSM Processes\n- Part 3: Asset Management, Governance and Security

## Key Premium Features

1. **Advanced Incident Management**\n   JSM Premium provides advanced incident management capabilities, including alerts, incident data analysis, and service and infrastructure health analysis. These features enable teams to detect and resolve incidents faster, minimising downtime and improving service reliability.

2. **Flexible Asset and Configuration Management**\n   With JSM Premium, you can track assets, configuration items, and resources, gaining visibility into critical relationships between applications. This helps streamline IT operations and ensures that all assets are properly managed and maintained.

3. **Change Management Automation**\n   Automate change management processes with JSM Premium. Automatically create change records for standard changes and pause high-risk changes for review and approval. This ensures that all changes are properly managed and reduces the risk of disruptions.

4. **AI-Powered Features**\n   Leverage AI-powered features like the virtual service agent and generative AI for the issue editor. These tools help automate routine tasks, provide personalised support, and enhance the overall user experience.

5. **No-Code/Low-Code Capabilities**\n   Empower your teams to build and customise their own services using no-code/low-code capabilities within an IT-regulated environment. This allows for greater flexibility and innovation while maintaining compliance with IT standards.

6. **Unlimited Storage**\n   JSM Premium offers unlimited storage, ensuring that you have all the space you need to manage your projects and data without worrying about running out of storage.

7. **24/7 Premium Support**\n   Benefit from 24/7 support with one-hour response times for critical issues from a dedicated team. This ensures that you always have access to expert assistance whenever you need it.

8. **Project Archiving**\n   Reduce clutter in your instance by archiving old projects and their underlying issues. This helps keep your workspace organised and improves overall efficiency.

9. **IP Allowlisting**\n   Bolster security by limiting site access to trusted IP ranges. This helps protect your data and ensures that only authorised users can access your Jira instance.

10. **Sandbox and Release Tracks**\n    Prepare and test product changes and updates before they roll out to your teams using sandbox environments. Control when and how product changes are released to users with release tracks.

The various license plans and their features can be found at [Explore Jira Service Management Pricing Plans](https://www.atlassian.com/software/jira/service-management/pricing).

We will now take a deeper look at some of these and ODWS best to use them to enhance your services.

## Customer Engagement

### Virtual Assistant

The **Virtual Assistant** is a function that your customer(s) will interact with in the portal to ask questions and raise request types. The main benefit of this is that it should, assuming it is configured correctly, empower your customer(s) to answer questions and resolve issues without the need the engage with service desk agents. A secondary benefit is that your service desk agents will have more time available to focus on proactive activities and delivering additional value to your customer(s).

### Help Centre (Customer Portal)

JSM Premium Licensing enables

- Unlimited service portals\n- Customer branding with your company's URL e.g. www.[your company domain]/support\n- Multiple help centres

To customise your Help Centre, and the JSM Projects below it, you need to navigate to your help centre. The link for this can be found at **Atlassian Admin -> Products -> Product URLs -> Jira Service Management**. Once there you should see, assuming you have the appropriate admin permissions, a **Customise** button in the top right-hand side of the screen. Clicking on opens a dropdown with 5 options.

- Manage announcements\n- Customise look and feel\n- Add login page message\n- Manage topics and portals\n- Edit page layout

#### Manage announcements

Adding announcements to your Help Centre or Project Portals is a great way of providing updates on Major Incidents to your users or identifying upcoming outages. This is in addition to other communication routes and should not be taken as the primary mode as you cannot guarantee that people will be looking here.

Permission to add announcements is, by default, restricted to Organisational Admins (Help Centre) and Project Admins (Project Portals), but can be opened up to the Agent role in a projects **Project settings -> Channels & self service -> Portal** screen.

To add a new announcement, or manage existing ones, click on the **Customise** button, populate the form that opens up and click **Save changes** for your message to be visible.

![announcements](https://res.cloudinary.com/xenos-design/image/upload/v1738687869/JSM/premium/img-019_d6ue59.png)

#### Customise look and feel

![look and feel](https://res.cloudinary.com/xenos-design/image/upload/v1738687870/JSM/premium/img-015_xh78jq.png)

You can change some basic areas of your Help Centre to make it to match your companies, or your customers, branding. You can

- Change the name\n- Change the home page title\n- Add a logo\n- Change to banner image\n- Change to banner and button colour\n- Change the banner text colour

![Change look and feel](https://res.cloudinary.com/xenos-design/image/upload/v1738758049/JSM/premium/img-020_belf0e.png)

#### Add login page message

To add a login message, click on the **Customise** button, select **Add login page message** and populate the form that opens up and click **Save changes** for your message to be visible.

![login essage](https://res.cloudinary.com/xenos-design/image/upload/v1738687869/JSM/premium/img-016_jf9ihd.png)

#### Manage topics and portals

To manage topics and portals, click on the **Customise** button, select **Manage Topics and Portals** and use the screen that you are taken to too make the changes that you need to. Click on **Publish layout** for your changes to be visible.

![topics and portals](https://res.cloudinary.com/xenos-design/image/upload/v1738687870/JSM/premium/img-017_st4p8m.png)

#### Edit page layout

To change the order that the sections of your Help Centre appear in, click on the **Customise** button, select **Edit page layout** and use the screen that you are taken to too make the changes that you need to. Click on **Preview** to see what your changes look like and **Publish** for your changes to be visible.

![edit layout](https://res.cloudinary.com/xenos-design/image/upload/v1738687870/JSM/premium/img-018_seb45l.png)

## Conclusion

In summary, JSM Premium stands out as a comprehensive solution tailored for modern IT service management needs. By harnessing its advanced features, organisations can streamline their service management processes, enhance efficiency, and provide exceptional service delivery. 

From advanced incident management to AI-powered capabilities, and robust support to enhanced security, JSM Premium equips teams with the tools they need to excel in a fast-paced digital landscape. 

Embrace the power of JSM Premium and unlock new levels of productivity and reliability in your IT operations.

Hopefully, this has been useful to you and I wish you well on your ITSM journey…

Greetings!

In this article, the second in my series on JIRA Service Management (JSM), I will be exploring the Access Management capabilities available in a JIRA Service Management (JSM) project. It includes a detailed look at the Single Sign-On (SSO) options provided by the Atlassian Guard product. The document aims to guide users on how to manage user access effectively, align with organisational security policies, and implement SSO with the necessary permissions.

*Note: you will need to have Organisation Administrator permissions to implement SSO, as well as having access to your organisations MS Entra ID admin.*

## Key Principles 

The following are a few examples of areas that should be considered, ideally as part of your design for JSM as discussed in the initial article of this series, when planning for managing user access to JSM.

* Managing users should not be an onerous task
* Align with your organisations information security policies 
* Align with your organisations Joiners, Movers and Leavers (JML) process
* Review license usage to ensure you only those that need it have access
* Follow the principle of least privilege access so users only have permission to do what they need to do to fulfil their role

## Available Roles

There are three distinct roles, with JSM, that users can be assigned to.

* ***Administrator*** - access to all functionality plus the ability to access the **Project Settings** and make changes to the project’s configuration 
* ***Agent*** - access to the agent functionality to create and manage request and Incident records
* ***Customer*** - the ability to create requests, view requests that have been raised and search the knowledge base (if access is provided)

These roles can be assigned in a number of ways which we will explore in the next section.

## Basic User Management

JSM provides ‘out of the box’ functionality for managing users. It is accessed from the **Project Settings** menu under **Access -> People and access**.

![People and settings](https://res.cloudinary.com/xenos-design/image/upload/v1735566618/JSM/project-settings/project-settings-image-11-1_ivlzg7.png)

The **People and access** screen is where users of the JSM project can be managed. From this screen you can

- Add users to the project by
  - Clicking on the **Add people** button
  - adding the email of the users you want to give access to OR add from Google, Slack or Microsoft
  - Choose the role that you want them to have
  - Click on **Add**

![Add users](https://res.cloudinary.com/xenos-design/image/upload/v1735566619/JSM/project-settings/project-settings-image-11-2_tytvoi.png)

- Remove users
- View users by file using the **Roles** filter
- Search for specific users in the **Search roles** field

## Single Sign On (SSO)

To use SSO with any Atlassian product a subscription needs to be taken out for [Atlassian Guard](https://www.atlassian.com/software/guard). This provides four methods of authenticating users for SSO. 

From an architectural perspective this sits outside of JSM and can be considered a global Atlassian product as it controls access across all products that your organisation has signed up to with Atlassian.

These setting are accessed via the Atlassian Administration menu.

![Atlassian admin](https://res.cloudinary.com/xenos-design/image/upload/v1735573543/JSM/sso/image-1_y2nfjf.png)

### Domain Verification only

This is the simplest way of deploying SSO as it only requires you to have access to the DNS records for the email domain that you want to use for authentication e.g. stevengodson.com.

In the Atlassian Admin menu select **Settings** then **Domains** and click on the **Verify your company domain** button.

![Verify domain screen](https://res.cloudinary.com/xenos-design/image/upload/v1735573645/JSM/sso/image-2_yc1nz9.png)

Click on **Next** on this screen.

![Screen 1](https://res.cloudinary.com/xenos-design/image/upload/v1735574052/JSM/sso/image-3_jletk4.png)

Enter the domain that you want to verify and click **Next**.

![Screen 2](https://res.cloudinary.com/xenos-design/image/upload/v1735574051/JSM/sso/image-4_xrwen0.png)

On the following screen, select the method of verification that you want to use, follow the instructions and click on **Verify domain** when completed.

![Screen 3](https://res.cloudinary.com/xenos-design/image/upload/v1735574052/JSM/sso/image-5_aygnu8.png)

You should be taken back to the main Domains screen where your domain will be listed. *Note: this may take several hours to verify depending on the method that you choose.

![Domain listing page](https://res.cloudinary.com/xenos-design/image/upload/v1735574652/JSM/sso/image-6_tnjrni.png)

Once your domain is verified you can claim any existing accounts for users under that domain. From this point any users that are logged into their browser using the verified domain can login, using SSO, to Atlassian Cloud.

Access to specific projects within Atlassian will still need to be granted at the project level following the steps shown in the *Basic User Management* section of this article.

### Identity Provider Integration

If you want to be able to control access to your Atlassian projects and products, through your existing federated user management tool, this can be achieved by implementing an **Identity Provider** integration using **SAML** and deploying **Authentication policies**.

This will, with the exception of Google Workspace, require you taking out a subscription to Atlassian Guard, which is licensed based on the number of users claimed rather than active, so I strongly advisee you to check the current pricing and be sure you have a valid business case to proceed.

Once you have setup your Atlassian Guard subscription, or signed up the the free 14 day trial, navigate to the **Atlassian Admin -> Security -> Identity Providers** screen and select your identity provider.

![Identity providers](https://res.cloudinary.com/xenos-design/image/upload/v1735576516/JSM/sso/image-7_dsy5ly.png)

*Note: most of these options will require you to verify your domain prior to setting up any integration.*

If the workflow for your specific integration does not cover setting up *Authentication policies*, I recommend navigating to **Administration -> Security -> Authentication policies** and creating a new policy for your specific *Identity Provider* integration to enforce single sign-on for all sync’d users.

These policies give you control over whether

- A user needs to use Two Factor Authentication
- Login using Third Party login routes
- Use API Tokens to access the JSM APIs
- Set how long users can be idle before they are kicked out. *Note: consult your organisations Information Security Policies to ensure compliance with any mandated periods*

#### Considerations

* If using groups to delineate role access, populate with a test user, wait for it to sync and test the access
* To give sync’d users with a group automatic access to certain projects, you just need to
  * In **Administration -> Directory -> Groups** select the applicable group and give all members access to *JSM* and *Confluence
  * In your JSM project go to **Project Settings -> Access -> People and Access** and add the user group to the appropriate JSM role (Admin, Service Desk Agent and Customer)
* The email addresses of the users, that are sync’d, **MUST** be the ones using a *verified domain*. Failure to do this means users will be treated *External* users and, as such, unmanaged

## Conclusion

We have come to the end of the fourth article in this series. We have explored the User Access Management controls for JSM.

In the next article we will go through the **User Portal** which is the main view for Service Desk Agents when work on different request types.

Hopefully this has been useful to you and I wish you well on your ITSM journey…

Greetings!

In this article, the second in my series on JIRA Service Management (JSM), I will be exploring the **Project Settings** available in a JSM project. Due to the numerous options, and level of detail, available in **Project Settings** I am splitting this article into two as follows.

This first article covered 

- Details
- Summary
- Features
- Access

The second article covers

- Request Management
- Automation

This article covers

- Channels & self-service
- Operations
- Notifications
- Language support
- Apps
- Versions
- Components

In my first article I setup a basic JSM project using the ‘out of the box’ functionality and the Customer Service Management template. Now we will go deeper into the available configuration options and discuss what is possible.

It is worth noting that, where additional functionality can be added as part of a paid subscription or license upgrade, I will be covering these in later articles.

## Key Principles 

The following are a few examples of areas that should be considered, ideally as part of your design for JSM as discussed in the initial article of this series, when planning for the configuration of a JSM project.

- Is your Service Desk going to be managing processes other than Incident Management and Request Management e.g. Problem Management, Change Management or Asset Management?
- What information needs to be captured for each process, both at the initial creation of a record and through its lifecycle?
- Are there existing process templates that can be used for the data capture and workflow?
- What queues and views are needed by the teams?
- How many customers are being supported and is there a need to split the data by customer?
- What integrations are needed? JSM can integrate with
  - Collaboration tools e.g. MS Teams and Slack 
  - Enterprise Management tools e.g. DataDog
  - Email integration for a more seamless service experience 

## Project Settings 

We will now go through the sections of the Project Settings menu and see what each sub element lets us configure.

This is accessed from the link shown below, you must have Admin permissions to see this link.

![Project Settings](https://res.cloudinary.com/xenos-design/image/upload/v1735475430/JSM/project-settings/project-settings-image-1_xpai6z.png)

### Channels & self-service

#### Portal

##### Portal Configuration

![Portal settings](https://res.cloudinary.com/xenos-design/image/upload/c_scale,w_700/v1735038726/JSM/getting-started/Getting-Started-Image-3_jqwvux.png)

- Portal URL - this is the link to your external facing portal for your service desk
- Service project information
  - Portal name - a mandatory title for your service desk project, this is visible internally and externally
  - Introduction text - the text that customers / users will see under the service desk project (Portal) name
  - Logo - allows you to add a logo to the portal which will sit beside the portal name
- Channel access - clicking of *Edit customer permissions* opens a new page where you can
  - Decide who has access to the portal, and other engagement routes, e.g. Restricted to users who have been given access or Open to anyone who has the link
  - Decide what customers can see within the project. This very much depends on whether your service desk project supports multiple customers or just one and the data privacy regulations that you need to comply with

![Channel Access](https://res.cloudinary.com/xenos-design/image/upload/v1735040287/JSM/getting-started/Getting-Started-Image-5_zhcbzf.png)

- Announcements - controls who can add banner announcement messages to the portal e.g. notifying users of an upcoming service outage or major Incident

##### Portal groups

![Portal groups](https://res.cloudinary.com/xenos-design/image/upload/c_scale,w_700/v1735040889/JSM/getting-started/Getting-Started-Image-6_lrwxht.png)

This tab allows you to add sections to your portal to enable a logical grouping of request types e.g. Incidents, Requests, Changes etc. By default it comes with the General group populated with 7 request types, assuming you have that many in your project. The groups can be re-ordered by clicking on the top left of a group tile and dragging around the page

##### Final View

Once you have configured your portal you can use the Portal URL to see what it looks like. I recommend making changes incrementally and checking the portal after each change so you can see the results in real time.

Below is a simplistic view of where your changes will be visible.

![Portal after customisation](https://res.cloudinary.com/xenos-design/image/upload/v1735041252/JSM/getting-started/Getting-Started-Image-7_dexplf.png)

If you look at the top righthand corner you will see me logged in as a user, a search icon and a Customer button, the latter only being available to those with permissions to add announcements.

#### Email

![Email settings](https://res.cloudinary.com/xenos-design/image/upload/v1735059290/JSM/getting-started/Getting-Started-Image-8_xcltez.png)

The Email section provides the capability to manage the email addresses that customers / users can use to report issues and request services.

The default email address is *support@[your-account-name].atlassian.net*. However, this can be amended by clicking the ellipsis, under the **Actions** heading, and selecting **Edit**. This opens the following pop-up from which the email address name can be amended and the Request type that will automatically be created upon receipt.

You will notice that the Request types in the drop down field represent the full list of Request types that were created earlier in this article.

![Manage email popup](https://res.cloudinary.com/xenos-design/image/upload/v1735059290/JSM/getting-started/Getting-Started-Image-9_iqhkjs.png)

If you want to create multiple email addresses then click on the **Create Atlassian email** button which opens the same pop-up form.

It is also possible to link external emails to your project, useful if you want to keep a corporate “feel” to the service desk. Simply click on the **Add external email** button, select the option that fits your use case and follow the instructions to connect to your email provider.

![Email integration](https://res.cloudinary.com/xenos-design/image/upload/v1735060223/JSM/getting-started/Getting-Started-Image-10_d4fszs.png)

#### Chat

The chat options of JSM are shown as four streams.

- Integration - with Slack or Teams to give a more integrated feel to the customer experience, crucial in a world where Experience Level Agreements (XLAs) are ever pushing their way into the foreground of CIO thinking
- Workflows - seamless fulfilment of requests within the chat
- Chat to Request - including triggers within a chat to allow agents to generate request records from a chat message
- Virtual Agent - the ever ubiquitous use of AI and Machine Learning to support customers through automation and knowledge bases

![Chat options](https://res.cloudinary.com/xenos-design/image/upload/c_scale,w_700/v1735060739/JSM/getting-started/Getting-Started-Image-11_jhf0wg.png)

#### Widget

The **Widget** page gives you the functionality to configure a deploy a widget to the customer portal that can be used to 

- raise an issue with the service desk
- search the knowledge base
- engage with a virtual agent

![Add a widget](https://res.cloudinary.com/xenos-design/image/upload/c_scale,w_700/v1735934803/JSM/project-settings/project-settings-image-21-6_jeouji.png)

*Note: you will need to have portal access set to Open before you can add a widget. This can be set from the Portal settings page.*

#### Knowledge base

The JSM knowledge base is a feature that needs to be enabled but, currently, incurs no cost. It essentially deploys Atlassians Confluence product.

![](https://res.cloudinary.com/xenos-design/image/upload/c_scale,w_700/v1735934998/JSM/project-settings/project-settings-image-21-7_vajnev.png)

To add a knowledge base you will need to

- Click on **Try Now**
- Accept the T’s and C’s on the next screen and wait
- Then, once the last screen appears click on **Go to knowledge base**

You will be taken to the following screen where you can see 

- Create spaces
- Link an existing space
- Set who has visibility
- Select which articles are shown

![knowledge base](https://res.cloudinary.com/xenos-design/image/upload/v1735935242/JSM/project-settings/project-settings-image-21-8_emiuzd.png)

#### Virtual service agent

The **Virtual Service Agent** is an AI driven tool that can enhance the customer experience and shift volumes away from the service desk agents, allowing them to focus on more value add activities. 

However, as this incurs an additional cost it is out of scope for this article.

#### External resources

The screen is used to add links to external tools and / or websites, outside of Atlassian, that customers will find useful. To add one you just need to

- Click on **Add link**
- Populate the form, as shown below, and click on **Add**

![Add link form](https://res.cloudinary.com/xenos-design/image/upload/c_scale,w_500/v1735935805/JSM/project-settings/project-settings-image-21-10_kbiuch.png)

The link will now be visible on the customer portal, as shown below.

![Portal with external resource](https://res.cloudinary.com/xenos-design/image/upload/v1735935805/JSM/project-settings/project-settings-image-21-12_gp7szc.png)

#### Issue collectors

![Issue collectors](https://res.cloudinary.com/xenos-design/image/upload/v1735935991/JSM/project-settings/project-settings-image-21-13_ujdvut.png)

**Issue collectors** are a great way to engage your users, from any website that can run JavaScript, to provide feedback or raise an issue. To add one click on **Add issue collector** and populate the screen that appears.

![Collector form](https://res.cloudinary.com/xenos-design/image/upload/c_scale,w_700/v1735988493/JSM/project-settings/project-settings-image-21-14_ckzp1u.png)

Once you have customised the collector configuration to meet your needs, click on **Submit** and you will be taken the the following screens that provide you with the HTML and jQuery code that you need to include in the website that the collector is for.

![HTML](https://res.cloudinary.com/xenos-design/image/upload/v1735988493/JSM/project-settings/project-settings-image-21-15_sejrba.png)
*HTML*

![JQuery](https://res.cloudinary.com/xenos-design/image/upload/v1735988493/JSM/project-settings/project-settings-image-21-16_jpmsww.png)
*JQuery*

### Operations

In the view shown below only Incident Management is listed. However, if you take out a Premium or Enterprise plan, and switch on Problem Management or Change Management, they will appear in this part of the menu as well.

#### Incident Management

This is a summary page that lists useful articles for managing fields, in both Standard and Premium services, configure responder alerts, set communications preferences and Post Incident Reviews, the latter two being Premium services.

![Incident Management](https://res.cloudinary.com/xenos-design/image/upload/c_scale,w_700/v1735989074/JSM/project-settings/project-settings-image-21-17_nskfny.png)

### Notifications

The following screens are used to configure and enable/disable notifications that will be sent internally within your support organisation e.g. issue assigned to agent or Priority 1 Incident raised, and notifications that will be sent to customers e.g. request created or approval required.

Depending on how your service desk operation is designed, you can switch off all customer notifications or customise the templates (Premium functionality).

#### Internal notifications

![Internal notifications](https://res.cloudinary.com/xenos-design/image/upload/c_scale,w_700/v1735989714/JSM/project-settings/project-settings-image-21-18_q4i5xx.png)

#### Customer notifications

![External notification](https://res.cloudinary.com/xenos-design/image/upload/v1735989714/JSM/project-settings/project-settings-image-21-19_mycocr.png)

### Language Support

This setting allows you to add support for additional languages to your JSM project.

![Language support](https://res.cloudinary.com/xenos-design/image/upload/c_scale,w_700/v1735990449/JSM/project-settings/project-settings-image-21-20_x4jcn4.png)

The main page lists the default language for the JSM project. This is what was selected when the JSM project was originally created. From this page you can

- Change the default language
- Add a new language by selecting one or more of the languages shown in the pop-up when you click on **Add Languages** button, as shown below

![Add languages](https://res.cloudinary.com/xenos-design/image/upload/c_scale,w_500/v1735990449/JSM/project-settings/project-settings-image-21-21_q24iho.png)

### Apps
#### Microsoft Teams integration

From this screen you can integrate JSM with your organisations M365 Teams solution. This gives you the ability for customers to engage your service desk through Teams channels, assuming they either sit on your Teams or allow integration with theirs.

You should check with your IT Security Manager, prior to going down this path, to ensure that you are compliant with your organisation’s information security policies.

Once implemented you can expand the capability through the use of integrated workflows, automation and the AI Agent (additional costs apply).

#### Slack integration

From this screen you can integrate JSM with your organisations Slack solution. This gives you the ability for customers to engage your service desk through Teams channels, assuming they either sit on your Teams or allow integration with theirs.

You should check with your IT Security Manager, prior to going down this path, to ensure that you are compliant with your organisation’s information security policies.

Once implemented you can expand the capability through the use of integrated workflows, automation and the AI Agent (additional costs apply).

#### Development tools

![Repository connect](https://res.cloudinary.com/xenos-design/image/upload/v1735991281/JSM/project-settings/project-settings-image-22-1_y2ekfr.png)

As you can see, this screen lets you connect Developer tools to JIRA.

#### Explore apps

This page lists the additional Atlassian Marketplace apps that JSM can integrate with. If you click on one of the tiles it shows you

- Details of the app
- Privacy and security statements
- Support details
- Version information
- Whether there is a cost for using it
- Additional resources

If you want to deploy one just click on the **Get it now** button to initiate the integration.

![Explore apps](https://res.cloudinary.com/xenos-design/image/upload/v1735991475/JSM/project-settings/project-settings-image-22-2_dom7ud.png)

### Versions

This screen gives you the functionality to list Releases of what you are supporting with your JSM service desk.

![Versions](https://res.cloudinary.com/xenos-design/image/upload/v1735991992/JSM/project-settings/project-settings-image-23-1_x6aerd.png)

You can add a new version by clicking on the **Create version** button and populating the pop-up that opens.

![Add version](https://res.cloudinary.com/xenos-design/image/upload/c_scale,w_500/v1735991992/JSM/project-settings/project-settings-image-23-2_gty2to.png)

Once added you can change the status of the record to

- Released
- Archived
- Merged
- Edited
- Deleted

![Updated list](https://res.cloudinary.com/xenos-design/image/upload/v1735992220/JSM/project-settings/project-settings-image-23-3_xkfuyj.png)

### Components

The **Components** screen is where the components of the service(s) that you are supporting, using your JSM instance, are managed. This list populated the *Components* field that can be seen in the **Request Management -> Fields** menu.

![Components](https://res.cloudinary.com/xenos-design/image/upload/v1735992531/JSM/project-settings/project-settings-image-24-1_k1ebnu.png)

From this page you can *Edit* and *Delete* components.

To add additional components, simply click on **Create component**, fill out the pop=up form that appears and click on **Save**.

![Add components](https://res.cloudinary.com/xenos-design/image/upload/c_scale,w_500/v1735992532/JSM/project-settings/project-settings-image-24-2_wsvnct.png)

## Conclusion

We have come to the end of the fourth article in this series. We have explored what JSM is, gone through some of the **Project Settings** feature.

In the next article we will continue to go through the **Access Management** options to discover just how versatile JSM can be.

Hopefully this has been useful to you and I wish you well on your ITSM journey…

Greetings!

In this article, the second in my series on JIRA Service Management (JSM), I will be exploring the **Project Settings** available in a JSM project. Due to the numerous options, and level of detail, available in **Project Settings** I am splitting this article into three as follows.

This article will cover

- Details
- Summary
- Features
- Access

The second article will cover

- Request Management
- Automation

The third article will cover

- Channels & self-service
- Operations
- Notifications
- Language support
- Apps
- Versions
- Components

In my previous article I setup a basic JSM project using the ‘out of the box’ functionality and the Customer Service Management template. Now we will go deeper into the available configuration options and discuss what is possible.

It is worth noting that, where additional functionality can be added as part of a paid subscription or license upgrade, I will be covering these in later articles.

## Key Principles 

The following are a few examples of areas that should be considered, ideally as part of your design for JSM as discussed in the initial article of this series, when planning for the configuration of a JSM project.

- Is your Service Desk going to be managing processes other than Incident Management and Request Management e.g. Problem Management, Change Management or Asset Management?
- What information needs to be captured for each process, both at the initial creation of a record and through its lifecycle?
- Are there existing process templates that can be used for the data capture and workflow?
- What queues and views are needed by the teams?
- How many customers are being supported and is there a need to split the data by customer?
- What integrations are needed? JSM can integrate with
  - Collaboration tools e.g. MS Teams and Slack 
  - Enterprise Management tools e.g. DataDog
  - Email integration for a more seamless service experience 

## Project Settings 

We will now go through the sections of the Project Settings menu and see what each sub element lets us configure.

This is accessed from the link shown below, you must have Admin permissions to see this link.

![Project Settings](https://res.cloudinary.com/xenos-design/image/upload/v1735475430/JSM/project-settings/project-settings-image-1_xpai6z.png)

### Details

The first section of Project Settings is Details. This allows you to

- Change the icon that appears in the top left-hand corder of the project screen
- Change the name of the project
- Change the project key, which is the unique prefix to the various record types
- Change the team type to more closely match how you are using JSM and get more tailored recommendations from Atlassian
- Add a URL
- Choose a category, assuming you have some configured
- Add a project description so that users can clearly understand when the JSM project is being used for
- Change the Project lead, typically to the Service Desk Manager/Team Lead or the owning Service Delivery Manager
- Add a default assignee, so tickets are automatically assigned when raised. This can be useful if you have a single person or role that initially triages tickets

![Details](https://res.cloudinary.com/xenos-design/image/upload/v1735476243/JSM/project-settings/project-settings-image-2_rgydgl.png)

### Summary

This section is a one-stop shop to see the key configuration options that are in JSM, whether the defaults or ones that have been configured is subsequent sections.

![Summary](https://res.cloudinary.com/xenos-design/image/upload/v1735476568/JSM/project-settings/project-settings-image-3_tvvyms.png)

### Features

![Features](https://res.cloudinary.com/xenos-design/image/upload/v1735476854/JSM/project-settings/project-settings-image-4_tzxvdt.png)

The Features section is where you switch on or off, and start top configure additional functionality. There are two tiers of features

- Standard, which can be accessed trough the base JSM license charge, and
- Premium, which incurs an uplift to the license charge and gives you access to a range of use features

In this article I will be covering the Standard features only, with the Premium ones being covered later in the series.

#### Views

![Views](https://res.cloudinary.com/xenos-design/image/upload/v1735478574/JSM/project-settings/project-settings-image-5_zrnimc.png)

Clicking on the **Select views** button opens a pop-up where you can select / de-select which of the available view types the service desk agent role can see and use in your JSM project.

![Select views](https://res.cloudinary.com/xenos-design/image/upload/c_scale,w_500/v1735479243/JSM/project-settings/project-settings-image-6-1_tqjb76.png)

#### Work Categories

![Work categories](https://res.cloudinary.com/xenos-design/image/upload/c_scale,w_700/v1735478574/JSM/project-settings/project-settings-image-6_deeukl.png)

##### Service request management

Enabling this feature provides you with a dedicated Service requests space, that can be accessed from the main project side menu, where you can see, raise and manage all service request records, that haven been created, in dedicated queues.

![Service Requests](https://res.cloudinary.com/xenos-design/image/upload/v1735479637/JSM/project-settings/project-settings-image-7-1_dbplf4.png)

##### Incident Management

Enabling this feature does a couple of things.

Firstly, as with service request management, you get a dedicated area in the main project side menu.

![Incidents](https://res.cloudinary.com/xenos-design/image/upload/v1735480160/JSM/project-settings/project-settings-image-7-2_pq1wnn.png)

It also creates a new **Operations** section in the Project settings menu, which we will come to later in this article. However, it is essentially a consolidation of guides and links to other areas of **Project Settings** that relate to the creation and management of Incidents. 

#### Customer Service

![Customer service](https://res.cloudinary.com/xenos-design/image/upload/v1735478576/JSM/project-settings/project-settings-image-7_qrmqrg.png)

##### Customer and organisation profiles

Enabled by default, this features allows the creation of customer and / or organisation profiles from the **Directory** section of the main left-hand side project menu. These are great for holding information of customers that can be pre-populated in a record, information on key contacts, service entitlement information etc.

##### Products and entitlements

If enabled, this features allows the creation of Products profiles from the **Directory** section of the main left-hand side project menu. You can set specific fields for data capture and define who can see the information. There is also the facility to import data, from external sources e.g. a CRM, using an API.

This feature is useful if you need to hold details of entitlement to support for the products that your organisation sells.

##### Developer escalations

Similar to Incident and Service request, enabling this feature gives a dedicated section under **Queues** in the main left-hand menu of the project. From this area you can add or create specific request types for Developer escalations that will be visible in this queue.

![Developer escalations](https://res.cloudinary.com/xenos-design/image/upload/v1735481666/JSM/project-settings/project-settings-image-8-1_uskqif.png)

#### Operations

![Operations](https://res.cloudinary.com/xenos-design/image/upload/v1735478574/JSM/project-settings/project-settings-image-8_oqblot.png)

##### Services

Enabled by default this feature provides the functionality to create a representation of the services that you are supporting, using JSM, and the linkages between them. A good place to start when trying to work out what needs to represented is your Enterprise Architect or ITSM Architect as they should have clear visibility of the service ties, inter-linkages and how best to represent them.

The menu to access this functionality sits in the **Operations** group in the main left-hand menu on the project itself. I will be covering the detail of these in a separate article, but creating a Service allows you to specify

- Name
- Type
- Tier
- Service Owner(s)
- Change approver(s)
- Responders
- Stakeholders
- Repository (BitBucket)
- Description

All of this is invaluable in managing services through their lifecycle.

##### Alerts

Enabled by default this feature provides the functionality to manage IT alerts. The menu to access this functionality sits in the **Operations** group in the main left-hand menu on the project itself.  

Coupled with JSMs ability to interface with Enterprise Management tools, such as DataDog, and the process automation functionality that exists in Atlassian products, you can monitor alerts coming in from your services, perform an action(s) dependent on the data in the alert and auto-assign to resolvers and / or initiate escalations.
##### On-call

Enabled by default this feature provides the functionality to integrate with OpsGenie to manage your on-call rotas for support start and automate ticket assignment and notification outside of your core support hours.

OpsGenie is separate to JSM and incurs additional charges to use. As such it is out of scope of this article.

#### Issue view

![Issue view](https://res.cloudinary.com/xenos-design/image/upload/v1735478575/JSM/project-settings/project-settings-image-9_bmzdeo.png)

##### Suggestions

If enabled this provides your service desk agents with an AI assistant, for Incidents and Service Requests only, that will provide summarised insight into a ticket and suggested actions that can be followed.

It is automatically enabled for Premium and Enterprise plans in JSM.

##### Similar requests panel

Enabled by default this feature provides the functionality provides your service desk agents with a view on similar records, within a type e.g. Incidents.

This visibility is great as it allows agents to identify and escalate trends or major incident scenarios earlier on that just waiting for dashboards to update. It also maximises efficiency as it reduces the need to “re-invent the wheel”, thus giving your customers a better experience.

##### Customer sentiment analysis

This feat is only available for Premium or Enterprise plans, so is out of scope for this article but will be covered in a later one.

I will highlight though that this kind of user sentiment capture and analysis can be a great way to get a balanced view for Experience Level Agreements (XLAs), which I take a look at in a [two part series](https://blog.stevengodson.com/series#XLA) on them.

#### Feature Lab

![Feature lab](https://res.cloudinary.com/xenos-design/image/upload/v1735478575/JSM/project-settings/project-settings-image-10_xeoyng.png)

##### Default request types

If enabled this functionality lets you assign one of your selected request types as a default for certain issue types.
Simply click on the **Default request type settings** button and the following modal will appear, from which you can assign the defaults.

![Default request types](https://res.cloudinary.com/xenos-design/image/upload/c_scale,w_500/v1735561830/JSM/project-settings/project-settings-image-10-1_twg4k4.png)

This functionality takes some of the guess work away from the service desk agents and ensure that requests will be raised in a consistent manner,

##### Request type groups

Enabling this feature allows you to create and add groups that request types can be assigned to. These can be functional, logical, organisational groupings that help your service desk agents provide a more effective service to your customers.

Once enabled, navigate to the **Request types** section in the main left-hand menu and select on of the options.

Click on the ellipsis under **Actions** for the request type that you want to change and select **Edit** under request type group.

![request type groups](https://res.cloudinary.com/xenos-design/image/upload/v1735562863/JSM/project-settings/project-settings-image-10-2_ihmkyi.png)

Then either select the group that you want to assign to the request type from the **Assign to group** tab.

![assign to group](https://res.cloudinary.com/xenos-design/image/upload/c_scale,w_500/v1735563113/JSM/project-settings/project-settings-image-10-3_azmhrx.png)

Or, go to the **Manage groups** tab, click on **Create group** and, once created, go back to the **Assign to group** tab to assign it to the request type.

![create request type group](https://res.cloudinary.com/xenos-design/image/upload/v1735563114/JSM/project-settings/project-settings-image-10-4_epipa5.png)

If you then go back to the **Request types** menu, you will be able to filed your request types by the grouping that you have added.

![filtered example](https://res.cloudinary.com/xenos-design/image/upload/c_scale,w_500/v1735563621/JSM/project-settings/project-settings-image-10-5_tyj7wx.png)

### Access

In this section we look at the Access management options that a JSM Project Admin can see in the Project Settings. These are not the only options available and the next article in this series will look at the options available to an Organisational Admin in the Atlassian settings menu.

#### People and access

![People and settings](https://res.cloudinary.com/xenos-design/image/upload/v1735566618/JSM/project-settings/project-settings-image-11-1_ivlzg7.png)

The **People and access** screen is where users of the JSM project can be managed. From this screen you can

- Add users to the project by
  - Clicking on the **Add people** button
  - adding the email of the users you want to give access to OR add from Google, Slack or Microsoft
  - Choose the role that you want them to have
  - Click on **Add**

![Add users](https://res.cloudinary.com/xenos-design/image/upload/v1735566619/JSM/project-settings/project-settings-image-11-2_tytvoi.png)

- Remove users
- View users by file using the **Roles** filter
- Search for specific users in the **Search roles** field

#### Project permissions

![Project permissions](https://res.cloudinary.com/xenos-design/image/upload/v1735567227/JSM/project-settings/project-settings-image-12-1_ntabbz.png)

The **Project permissions** page shows all of the permissions available in JSM and what has been assigned to which **Project Roles** in your instance.

These can be adjusted to meet your organisational and security policy requirements. Click on the **Actions** button and select **Edit permissions**. The following screen will appear, from which you can Update or Remove assigned permissions.

*Note: caution should exercised with this to ensure you don’t accidentally break your service desk operation*

![Edit permissions](https://res.cloudinary.com/xenos-design/image/upload/v1735567228/JSM/project-settings/project-settings-image-12-2_qgqrzb.png)

Alternatively you can copy permissions from another project, that you have access to, by simply by clicking on the **Actions** button and select **Use a different schema**. The following screen will appear, from which you can Update or Remove assigned permissions. 

The following screen appears. Just select the project whose schema you want to copy and click on **Associate**.

![Copy schema](https://res.cloudinary.com/xenos-design/image/upload/v1735567934/JSM/project-settings/project-settings-image-12-3_ohkotq.png)

#### Customer permissions

![Customer permissions](https://res.cloudinary.com/xenos-design/image/upload/v1735568102/JSM/project-settings/project-settings-image-12-4_ddll34.png)

The **Customer permissions** functionality lets you set the level at which customers can search for other customers. This is set to three levels

- only search within own organisation (default)
- only search within own organisation or enter the email of a specific customer (if known)
- search within the project or own organisation

You can also determine whether the JSM projects portal is restricted to customers that can login or open to anyone who has the URL. The default is to have access restricted. I do not recommend changing this.

![Portal visibility](https://res.cloudinary.com/xenos-design/image/upload/v1735568101/JSM/project-settings/project-settings-image-12-5_zgsjle.png)

#### Issue security

![Issue security](https://res.cloudinary.com/xenos-design/image/upload/v1735569008/JSM/project-settings/project-settings-image-12-6_y6izul.png)

This function requires a Premium or Enterprise plan, as such it is out of scope for this article. By using this functionality you are enabling  security permissions schema that will be applied to your issues. This can be useful for

- Segregation of roles
- Implementing a Security Incident and Event Management process

## Conclusion

We have come to the end of the first article in this series relating to the **Project Settings**. We have explored what JSM is, gone through some of the **Project Settings** feature.

In the next article we will continue to go through the **Project settings** options to discover just how versatile JSM can be.

Hopefully this has been useful to you and I wish you well on your ITSM journey…

Greetings!

Welcome to a new series of articles in which we will look at Atlassian’s JIRA Service Management (JSM) product and I will explain how to set it up so that you can make the most of the products capabilities.

## So what is JSM?
JSM is a service / support desk tool that provides businesses with that capability to quickly implement one or more service *projects* to cater for a range of business function use cases. Under the hood it is essentially JIRA Software, so any organisation that uses JIRA for developing products will find it all quite familiar. 
In my opinion using both modules together is a good basis for implementing a highly integrated support and development model. 

Out of the box it provides an enough basic functionality to engage with customers and log & track issues and requests. However, with the available extensions and integrations, it has the potential to become the beating heart of an enterprise scale IT operation.

In this initial article we will focus on the initial setup of JSM and getting a basic instance up and running. Then, in subsequent articles, we will be going into the various capabilities in greater depth and looking at the options currently available.

## JSM Design Thinking 
While not wholly necessary, if you are an experienced JIRA administrator, I highly recommend creating a design of some sort prior to creating and configuring a JSM instance.

Such a document should consider the following.

* License requirements e.g. how many users and of what type, this includes
  * JSM (inc upgrades for Asset Management)
  * Confluence 
  * Atlassian Guard
* Access management and role based controls e.g. how you want to manage user access and to what level 
* Scope of the Service Desk that will be using the project. Processes, form design, workflows, and required outputs should all be considered 
* What Service Level Agreements need to be tracked and monitored in the tool
* How will users engage with the Service Desk e.g. portal, email, chat, voice etc How your support teams work and what views they require 
* What standards need to be adhered to and therefore what process controls need to be in place e.g. ISE/IEC 20000-1, ISO/IEC 27001, HIPAA, COBIT etc
* Reporting and dashboard needs should be considered
* Integration with other tools, such as
  * Slack or Teams
  * Enterprise Monitoring tools e.g. DataDog, AWS Cloud Watch or Azure Monitor 
  * Email integration 

Creating a document that describes what you will be deploying helps focus the minds of all stakeholders and provides an auditable baseline of what you intended and agreed to do.

## Initial Setup
The first thing you will need to do, assuming you do not already have an Atlassian account, is to register an account with Atlassian and say that you want to use JSM.
Once registered you will be presented with the below choices. Your selection is obviously dependent on what your business driver is for implementing JSM. This series of articles looks specifically at the **IT Support** use case.

![Project Types](https://res.cloudinary.com/xenos-design/image/upload/v1734982362/JSM/initial/Initial-Setup-Image-6_lp6lwh.png)

This selection	takes you to the **Projects** screen. This where you can create and manage all the JSM projects that your business requires.

![Create a project](https://res.cloudinary.com/xenos-design/image/upload/v1734982362/JSM/initial/Initial-Setup-Image-2_sj0q6o.png)

Select *Customer service management* from the next screen.

![Selection](https://res.cloudinary.com/xenos-design/image/upload/v1734982363/JSM/initial/Initial-Setup-Image-3_ksljg1.png)

The next screen tells you to select a Customer Service Management template.

![Template](https://res.cloudinary.com/xenos-design/image/upload/v1734982362/JSM/initial/Initial-Setup-Image-4_zg71fe.png)

We are now at the point where specific information about the project needs to be provided (most of these can be changed later if needed).

- Name - what you want the project to be called
- Key - this will be automatically populated from the name, but you can override it. This code must be unique within your Atlassian account as it is used as a prefix for tickets and is part of the URL for your project and external facing portal
- Team type - select based on your business use case. I am selecting Information Technology (IT)
- Channel access - defaults to Open, which means anyone with your portal URL can submit a request or raise an Incident. I always start with *Restricted* and open up access when the project is launched
- Template - you can select another template type or just with a blank project

![Project info](https://res.cloudinary.com/xenos-design/image/upload/v1734982362/JSM/initial/Initial-Setup-Image-5_xalbtu.png)

Once you click on *Create Project* you are presented with the Service Request types that come with the template. I recommend investigating these and choosing those appropriate to your business use case. To get the most out of these you may need to switch on specific functionality for IT Service Management (ITSM) specific processes e.g. Incident Management, which come with pre-defined workflows.

![Request types](https://res.cloudinary.com/xenos-design/image/upload/v1734982362/JSM/initial/Initial-Setup-Image-6_lp6lwh.png)

Once you have you completed your selection (you can always revise later) click on *Continue to project*. You will see the projects *Get Started* screen. 

![Getting Started](https://res.cloudinary.com/xenos-design/image/upload/v1734982363/JSM/initial/Initial-Setup-Image-7_sg0tvl.png)

## Getting Started
In this section we will go through the specifics of the *Getting Started* screen.

![Let’s get started!](https://res.cloudinary.com/xenos-design/image/upload/v1735036967/JSM/getting-started/Getting-Started-Image-1_fnteyl.png)

The first section of this allows you to walkthrough raising a request, prioritising it using the queues available in JSM and then resolving it. It is quite intuitive so I will not being going through this.

The second section allows you to review essential project configuration data, and consists of three sections.
- Enable customers to raise requests - these are your engagement channels
- Collect relevant information with request types - here you can review your request types and add/remove fields so that the data collected matches your business requirements and data model
- Manage work with your queues and board - this section allows you to review the views that you have for managing requests and Incidents

The third and final section provides links to Atlassian guides, tutorials, community and support pages. These are generally quite good, the ones that I have used at least, so well worth exploring.

Now we will look at the middle section in greater details and discover what the possibilities are.

### Enable customers to raise requests
![Engagement channels](https://res.cloudinary.com/xenos-design/image/upload/v1735038440/JSM/getting-started/Getting-Started-Image-2_o4lndt.png)

This section covers three modes of communication that your customers can engage through. First is the Portal, which a web front end where your customers / users can raise Incidents, requests and search knowledge articles. If we click on the *Customise Settings* button we are taken to a section or the **Project Settings** that is specific to the Portal. This section has two tabs where choices can be made.

#### Portal
##### Portal Configuration

![Portal settings](https://res.cloudinary.com/xenos-design/image/upload/c_scale,w_700/v1735038726/JSM/getting-started/Getting-Started-Image-3_jqwvux.png)

- Portal URL - this is the link to your external facing portal for your service desk
- Service project information
  - Portal name - a mandatory title for your service desk project, this is visible internally and externally
  - Introduction text - the text that customers / users will see under the service desk project (Portal) name
  - Logo - allows you to add a logo to the portal which will sit beside the portal name
- Channel access - clicking of *Edit customer permissions* opens a new page where you can
  - Decide who has access to the portal, and other engagement routes, e.g. Restricted to users who have been given access or Open to anyone who has the link
  - Decide what customers can see within the project. This very much depends on whether your service desk project supports multiple customers or just one and the data privacy regulations that you need to comply with

![Channel Access](https://res.cloudinary.com/xenos-design/image/upload/v1735040287/JSM/getting-started/Getting-Started-Image-5_zhcbzf.png)

- Announcements - controls who can add banner announcement messages to the portal e.g. notifying users of an upcoming service outage or major Incident

##### Portal groups

![Portal groups](https://res.cloudinary.com/xenos-design/image/upload/c_scale,w_700/v1735040889/JSM/getting-started/Getting-Started-Image-6_lrwxht.png)

This tab allows you to add sections to your portal to enable a logical grouping of request types e.g. Incidents, Requests, Changes etc. By default it comes with the General group populated with 7 request types, assuming you have that many in your project. The groups can be re-ordered by clicking on the top left of a group tile and dragging around the page

##### Final View

Once you have configured your portal you can use the Portal URL to see what it looks like. I recommend making changes incrementally and checking the portal after each change so you can see the results in real time.

Below is a simplistic view of where your changes will be visible.

![Portal after customisation](https://res.cloudinary.com/xenos-design/image/upload/v1735041252/JSM/getting-started/Getting-Started-Image-7_dexplf.png)

If you look at the top righthand corner you will see me logged in as a user, a search icon and a Customer button, the latter only being available to those with permissions to add announcements.

#### Email

![Email settings](https://res.cloudinary.com/xenos-design/image/upload/v1735059290/JSM/getting-started/Getting-Started-Image-8_xcltez.png)

The Email section provides the capability to manage the email addresses that customers / users can use to report issues and request services.

The default email address is *support@[your-account-name].atlassian.net*. However, this can be amended by clicking the ellipsis, under the **Actions** heading, and selecting **Edit**. This opens the following pop-up from which the email address name can be amended and the Request type that will automatically be created upon receipt.

You will notice that the Request types in the drop down field represent the full list of Request types that were created earlier in this article.

![Manage email popup](https://res.cloudinary.com/xenos-design/image/upload/v1735059290/JSM/getting-started/Getting-Started-Image-9_iqhkjs.png)

If you want to create multiple email addresses then click on the **Create Atlassian email** button which opens the same pop-up form.

It is also possible to link external emails to your project, useful if you want to keep a corporate “feel” to the service desk. Simply click on the **Add external email** button, select the option that fits your use case and follow the instructions to connect to your email provider.

![Email integration](https://res.cloudinary.com/xenos-design/image/upload/v1735060223/JSM/getting-started/Getting-Started-Image-10_d4fszs.png)

#### Chat

The chat options of JSM are shown as four streams.

- Integration - with Slack or Teams to give a more integrated feel to the customer experience, crucial in a world where Experience Level Agreements (XLAs) are ever pushing their way into the foreground of CIO thinking
- Workflows - seamless fulfilment of requests within the chat
- Chat to Request - including triggers within a chat to allow agents to generate request records from a chat message
- Virtual Agent - the ever ubiquitous use of AI and Machine Learning to support customers through automation and knowledge bases

![Chat options](https://res.cloudinary.com/xenos-design/image/upload/c_scale,w_700/v1735060739/JSM/getting-started/Getting-Started-Image-11_jhf0wg.png)

### Collect Relevant information with request types

![Request type fields](https://res.cloudinary.com/xenos-design/image/upload/v1735061960/JSM/getting-started/Getting-Started-Image-12_xlm1lj.png)

This section of the Getting Started page is really just a prompt for you to think about what information you want to capture in the forms for the various request types. Clicking on the **View all request types** button takes you to the *Request types* section of *Project settings*.

I will be covering all of the options in **Project settings** in the next JSM article, so we will move on to the next section.

### Manage work with your queues and board

![Queues and board](https://res.cloudinary.com/xenos-design/image/upload/v1735062796/JSM/getting-started/Getting-Started-Image-13_yf7yuv.png)

Both Queues and Boards (now known as Views) are basically ways of view the different tickets yours service desk has open. These can be cut numerous ways depending on how you want to see the information. Both of these take you to the relevant project sections where, assuming you have Admin permissions, you can manage the queues and views.

I will be covering both of these in the third JSM article.

## Conclusion

We have come to the end of the first article in this series. We have explored what JSM is, how to initiate a project and gone through the basic options in the **Getting Started** feature.

In the next article we will be going through all of the **Project settings** options to discover just how versatile JSM can be.

Hopefully this has been useful to you and I wish you well on your ITSM journey…

AI Governance

Greetings!

Governance of how an organisation uses AI will be a key factor in how much value/benefit can be realised in the future.

As AI becomes increasingly present in our everyday lives, both at work and at home, more domestic and international governments will attempt to exert control through legislation and regulatory standards.

This will naturally lead to organisations needing to understand, in-depth, how they are using AI and what data sources/structures are being used so they can monitor, manage and maintain compliance with all of the applicable statutes and industry best practices.

Areas that will need careful consideration include the following.

Business case/usage

A clear idea of what AI can and cannot be used for should be established. This should establish firm use cases and decision trees that teams within the organisation can follow if they want to implement AI to tackle specific scenarios.

Intellectual property

An organisations IP must be protected to ensure that, through the use of AI, whether public platform or internet connected private platform, it isn’t exposed to the threat of theft or loss.

Legislative compliance

The introduction of new legislation, such as the EU AI Act, organisations have new statutory obligations to meet or face significant fines and damage to their reputation.

Organisational culture/Skills evolution

At this stage, AI introduces new and exciting, tools that are lauded as being able to improve an organisation’s productivity by percentages that have not been achieved since the Industrial Revolution. However, picking up a spanner doesn’t automatically make me a mechanic! Therefore, an organisation needs to define, implement and continually refresh its culture to ensure that its resources make effective use of these new tools and that the expected Return On Investment is achieved.

An organisations ITSM capability will need to be at the core of this, ensuring that the appropriate strategies and plans are in place to enable business AI agility whilst robustly managing the associated risks.

“But how?!”, I hear you cry…. Well here are some of my thoughts on the subject.

Robust enterprise architecture to provide

architectural patterns and reusable technology stacks, that evolve with business needs and technology improvements

enterprise management solutions that can manage, monitor, alert, and report on the organisations AI solutions

automated and integrated tracking of key data assets that underpin an organisations AI implementation e.g. Large Language Models

Adhere through the use of policy and process controls designed to meet the regulatory requirements of the geographies that the organisation operates in.

Effective audit and reporting capabilities that can analyse information, in real-time, and facilitate escalations, as appropriate, within the organisation so that risks can be managed. The more this can be automated, possibly with the use of AI for analysis, the more robust this will be.

Enforce policies, at the operational and technology levels, to control

usage (appropriate and inappropriate)

data separation to safeguard company intellectual property

user access controls

Invest in the skills of your team, and encourage experimentation with new technologies. AI is growing at an unprecedented pace and so organisations must adapt quickly to meet business demands.

In summary, ITSM capabilities must embrace the organisations use of AI and provide guidance and guardrails. How fast they can evolve with business needs will have a significant impact on the organisations ability to manage risks and realise value from AI.

Hopefully this has been useful to you and I wish you well on your ITSM journey…

Config Management Database (CMDB)

Greetings!

In this weeks article I will be talking about the concept of a Configuration Management Database (CMDB) and whether it is still relevant in today’s fast paced I.T. world.

## What is a CMDB?

A CMDB is, in essence, the main tool that the Service Asset & Configuration Management function uses to track the state of “stuff”. In the context of an I.T. service “stuff” is anything that the services needs to manage and control the state of in order to be able meet its obligations e.g. levels of service, compliance requirements etc.

Commonly each instance of “stuff” is referred to as a Configuration Item (CI), at least in the world of ITIL&reg;, and has a number of attributes against which pertinent information is stored. For example, the CI record, in a CMDB, for a laptop may hold the following information; 

- Make
- Model
- Warranty Status
- Operating System
- Assigned Owner
- Related Cost Centre
- Previous Incidents
- etc

This information can all be useful to various roles and functions within an I.T. service, for example;

- Operating System - can be used by Technical Management to know which devices to patch with what updates
- Related Cost Centre - can be used by Financial Management for cross charging
- Previous Incidents - may be useful to the Service Desk when trying to diagnose a  reported issue

Now all of this information is undoubtedly useful, but does it all need to be kept in (and typically manually replicated into) a monolithic CMDB?

## Is there a better way?

Better, in a sense of being more efficient, and less prone to human error? Absolutely! In the following sections I will expand upon this and describe the options in a toolset agnostic way.

### Federation

![Federated CMDB!](https://res.cloudinary.com/xenos-design/image/upload/v1689867576/ITSM/CMDB_Federation_zybvzx.png)

The federation model is where the base minimum of data is held in the CMDB to enable ITSM processes but, when further information is required, it points to the single source of truth for that data type. 

The guiding principle is here “Right data, right place and only accessible by those who need it, when they need it”.

This model is my preference when there is a complex service environment spanning multiple delivery models and architectures.

### Integration

![Integrated CMDB!](https://res.cloudinary.com/xenos-design/image/upload/v1689867576/ITSM/CMDB_Integration_p9lipe.png)

The integration model is where the various primary data sources,  that underpin delivery of your service(s), feed into your central CMDB (typically within your ITSM toolset).

Automation is the underpinning point here. This approach can work well where integrations have been proven to work, and most leading ITSM tools will come with standard integration with other leading tools, but I am always conscious that anything new requires time and will undoubtedly need iteration to get it right.

## Conclusion

The CMDB still has an important part to play in delivering and controlling services to ensure consistency and quality.

However, the days of the CMDB being deployed as a single entity, and source of truth for everything, should be reconciled to the past.  Instead consideration should be given to who really needs the information and how that information visibility requirement should be met.

Hopefully this has been useful to you and I wish you well on your ITSM journey…

Inside an XLA

Greetings!

This week we will be diving deeper into what an XLA (eXperience Level Agreement) should be and look at some examples.

If you are not familiar with XLAs then my previous article XLAs - avoiding watermelons give a useful introduction.

An XLA is a combination of objective and subjective measures that give you a balanced measurement of the impact of the service, with a weighting towards how the “users” experience the service. So let’s look at some examples of what that means in reality.

Balanced Measurement

Objective and Subjective

An objective measure is based on data derived, usually, from the systems or toolsets that are used to manage either ITSM processes, e.g. Incident Management tools, or IT systems, e.g. Application Performance Management.

The objective measures, that help to make up an XLA, are important because they bring context and meaning to the subjective measures.

For example, if you have an XLA that is measuring user satisfaction with your Service Desk, then objectively measuring the number of contacts with the Service Desk gives context.

The context is important because if your subjective result shows 50 negative responses then this sounds, on the face of it, to be a bad thing. Now this result is never a “good” thing but, when taken into the context of 20,000 contacts in the Service Desk in a measurement period, thus meaning a 0.25% negative response, it doesn’t sound so bad.

But, is this really an accurate measure?

Again the answer revolves around context. If 20,000 contacts result in 20,000 survey responses, your subjective source, then this could well be a valid measurement. However, this is unlikely to be the case.

So, another objective measure would be the number of survey responses received in your measurement period. For the sake of novelty let’s say you get 420 completed surveys. Now this changes your perspective quite significantly.

Your original 0.25% becomes 11.9%, which is quite a dramatic change and suddenly things don’t seem quite so good.

However, what cannot be emphasised enough is that XLAs are for driving improvement in areas that are important to the business to that the service(s) are being delivered.

An XLA is neither a carrot to reward a service provider, nor is it a stick with which to beat one. An XLA is a point on the horizon that both customer and supplier are walking towards together. The measurement points are simply there to identify whether they are walking forwards, standing still or are walking backwards.

Source: Steven Godson

So, what we have, so far, is a number of objective measurements, which are as follows.

Total contacts to a Service Desk

Total number of survey results and as a % of total contacts

Total number of positive/negative survey responses and their respective percentages

So, what’s next? Well, the next thing is to define what good” actually looks like in your context and ensure balance in your results.

What is “good” anyway?

What good means, in the context of XLAs, will greatly depend on what you are using XLA measurements to achieve.

However, it is true to say that whatever it is there needs to be acknowledgement that the target chosen should be realistic and is a target to be worked towards rather than there being an expectation that it will be achieved from day one.

It is also sensible to apply a balanced approach to reporting the measures that combine to give the overall XLA measure. A pragmatic way to do this is to apply weighting to each of the component measures based on their importance/significance. The weighting is a % split across the number of measures you are using to calculate your XLA score.

For example, if you are working towards users adopting self-service and digital channels, your XLA measurement may look like this.

Weighting % - this weighting allows you to apply a balanced, business-focused, view whilst maintaining transparency

Metric - the objective and subjective numbers captured in the reporting periods

eXperience Performance Indicator - the XPIs expressed as a % of the relevant total

XLA Score - the weighting applied to the XPI

XLA achievement - the figure that you would be reporting for the given measurement period

The examples of what an XLA could be used to measure are;

Gauging the impact of a new supplier or service, so that improvements can be identified

Measuring the end-user experience (UX) for one or more applications, as long as there is a subjective element to the measurement

Impact of a change program

Summary

In this article, I have talked about what makes up an XLA, and the mindset required, and provided a real-life example. Hopefully, this article has been of some use and has given you a good idea of the types of areas that need to be addressed.

I wish you well on your ITSM journey…

Adding Latest posts…

Greetings!

In this post we will be building on the site created in the first two articles, and demonstrating the benefit of having re-usable components, to add your latest *Posts* to your home page.

## Steps 1 - Get the correct data

Open your *./pages/index.js* file and add the following to the end of the file.

```jsx
export async function getStaticProps() {
	// fetches all the post data from your published article folder
    const webpackContext = require.context('../posts', true, /\.\/.*\.md$/);
    // console.log('webpackContext', webpackContext.keys())

    // the list of file names contained inside the "posts" directory
    const keys = webpackContext.keys();

	// reverse the array of posts so the newest one is first
    const reverseKeys = keys.reverse();
    // console.log('keys', keys)

    const values = reverseKeys.map(webpackContext);
    // console.log('values', values)

    // getting the post data from the files contained in the "posts" folder
    const posts = reverseKeys.map((key, index) => {
        // dynamically creating the post slug from the file name
        const slug = key
            .replace(/^.*[\\\/]/, '')
            .split('.')
            .slice(0, -1)
            .join('.');

        // console.log('slug', slug)
        // getting the .md file value associated with the current file name
        const value = values[index];
        // console.log('value', value)

        // parsing the YAML metadata and markdown body contained in the .md file
        const document = matter(value.default);
        // console.log('document', document.data)

        return {
            frontmatter: document.data,
            markdownBody: document.content,
            slug,
        };
    });
    // console.log('posts', posts);

	// cut the list of posts down to the first 4 in the array e.g. the latest 4 
    const topPosts = posts.slice(0, 4);
    // console.log('topPosts', topPosts)

	// export the data for the 4 latest posts
    return {
        props: {
            latestPosts: topPosts,
        },
    };
}
```

If you encounter issues I recommend using the console logs, already written in, to see where the issues are.

Assuming there are no errors you are now ready to move on to Step 2.

## Step 2 - Use the data

Now that you have the data for the posts, that you want displayed, it can be used to display on your home page.

There are only a few changes required to do this which are shown in the following code.

```jsx
import Head from 'next/head';
import Image from 'next/image';
import Layout from '../components/Layout';
import Introduction from '../components/Introduction';
import AnimatedSplash from '../components/AnimatedSplash';
// Change 1 - import the BlogList component, if not already done
import BlogList from '../components/BlogList';
import Contact from '../components/Contact';
import styles from '@/styles/Home.module.css';
// Change 2 - import grey-matter
import matter from 'gray-matter';

// Change 3 - change "props" to "latestPosts" to directly access the export data from Step 1
export default function Home({ latestPosts }) {
    return (
        <Layout>
            <Introduction />
            <AnimatedSplash />
			// Change 4 - add the BlogList component and pass in latestPosts
			// consider adding a heading before the component
            <BlogList allBlogs={latestPosts} />
            <Contact />
        </Layout>
    );
}
```

## Step 3 - View the data

Now that we have got the correct data, and passed it into the correct component, we are ready to see the result.

- Navigate to the *root* folder of your project
- Run `npm run dev`
- Now go to [http://localhost:3000](http://localhost:3000) in your browser

You should now see something like the following.

![Latest Posts!](https://res.cloudinary.com/xenos-design/image/upload/v1690470282/Post_Content/nextjs-md-latestPosts/latestPosts_kmlyxv.png)

And that’s it for now… you have now updated your blogging site, using Next’s and Markdown, and enhanced the experience of your readers. Hopefully, you found this article useful and will continue your journey.

Thanks for stopping by…

ITSM and DevOps

Greetings!

In this week's article, I will be talking about how ITSM can co-exist with DevOps so that the ITSM teams are not seen as blockers and the DevOps team(s) are not seen as “chaos monkeys”.

This can be achieved through two fronts;

1. Culture
2. Understanding and agreeing on the touch points

## Culture

It is easy to say that a good working culture, within an organisation, leads to better interworking between departments and the teams within them. But what does that mean in practical terms when you are aspiring to get ITSM and DevOps working together?

In my experience, this means addressing the following areas, in a program of change that is sponsored from the top but driven from the bottom up.

- Open and respectful dialogue - so that issues can be raised and ideas discussed
- Willingness to change - adopting a one-team approach
- Continual improvement mindset - striving to do better

## Touchpoints

The below diagram is my view on where the key touch points are between ITSM and DevOps as models. I have deliberately used ITIL terminology for the ITSM side, mainly because it is widely used around the globe.

![DevOps and ITSM!](https://res.cloudinary.com/xenos-design/image/upload/v1687544857/ITSM/ITSM_and_DevOps_Interaction_n60p55.png)

### Ticket Creation / Update / Resolve

- The resolution of an Incident or Problem may require the DevOps team so, unless it is critical, it would need to be cross logged onto the appropriate Product Backlog
- A Service Request could be a conduit for “asks” being raised onto a Product Backlog
- Depending on how rigorously the deployment of Release Packages to the production environments is controlled, the DevOps team will be raising Operational Request for Changes (RFCs) to get approval to deploy. This can be seen as a bottleneck that restricts business agility, so consideration must be given to;
	- Agreement on what can be automatically approved based on specific criteria being met i.e. tests passing
	- Pre-agreed windows for deployment

### Authorisation

The Operational Change Management process will provide authorisation to deploy based on what criteria is either defined in the Change Management policy document or as agreed operationally for each Product. 

The key to this is finding the appropriate balance between the business's needs;
	- frequency and rapidity of change
	- ensuring that users / customers, depending on your business environment, do not suffer from change fatigue
	- maintaining the required levels of service availability
	- minimising risks

### Pre/Post Baseline Report

The SACM (Service Asset and Configuration Management) team is responsible for ensuring that there is accuracy in the configuration of the service(s). 

The DevOps team relies on this information to;

- know what *good* looks like, so they can restore the service back to its baseline configurations in the event of an Incident
- identify what might be impacted as a result of planned changes

The typical advice, which I broadly agree with, is to use a CMDB (Configuration Management Database)  to hold this data. 

My view on this is that a CMDB should be seen as a collection of federated data / information repositories that are specific to the type of data / information that is being managed e.g. a Software Configuration Manager tool (CICD pipeline or Github etc) or Wiki / Knowledge Articles (ITSM tool, Gitbook, Confluence).

### Knowledge Share

This touchpoint is important to ensure that changes to the service(s) are understood by the Service Desk, and other support tiers, so that they know what to do when an Incident occurs or a user phones up to query something.

It is also important from a user perspective so that they;

- know what has changed and what, if anything, that change means to them
- can access self-service knowledge to resolve issues themselves

The DevOps team also needs a flow of knowledge not them so that they can understand;

- whether the knowledge that they are providing is actually of use
- how users are reacting to the visible changes that are being made

## Summary
In this article, I have described the key touchpoints between ITSM and DevOps and why they are important. Hopefully, this article has been of some use and has given you a good idea of the types of areas that need to be addressed.

I wish you well on your ITSM journey…

Service Design Package

Greetings!

In this article I will be exploring the concept of the Service Design Package, what it should be and what should be included within its scope.

## What is a Service Design Package?
Service Design Package, abbreviated to SDP, is a term that initially appeared in ITL&reg; v3 which was first published in 2007, is a collection (the package part) of documents and artefacts that describes;  

- Scope - what a service is
- Users / Location - who it can be consumed by
- Compliance - the business, regulatory and statutory constraints that it has to exist within
- Requirements - the warranty, utility, quality and satisfaction characteristics that it has to meet
- Processes - that will be used to manage the service on a day to day basis
- Products - the tools that will be used to deliver the service. This includes everything from SaaS solutions through to bespoke applications
- Partners - the sub-contractors you use to deliver parts of the service
- People - the individual roles and functions that will govern and manage all of the above

> “Good service starts, and ends, with having great people..”. Source: me

## What should it be?
An SDP should be the definitive source of information for anyone requiring an understanding on what a service should deliver and how it delivers that service.

It should provide different views so that it can be used by different stakeholders with different perspectives.

It should be useable, accessible and written in plain English (or whichever language is relevant).

It should be a number of complimentary, and not over lapping, documents that are regularly reviewed and maintained to ensure currency.

## What should be included within an SDP?
The following is based on my years of experience of designing and building ITSM solutions as part of a Managed Services provider. 

Depending on your situation e.g. internal servicer provider (“The IT department”) or a Managed Service provider (external organisation to the one buying the services), you may consider some of these to not be relevant.

And, depending on your situation, you may be correct. However, all of the following areas should at least be considered when creating an SDP.

### Service Description - the what and the when…

A Service Description is the shiny document that, depending on your scenario, your customers and / or users will read to understand what the service is that they are consuming / paying for.

The common scenarios under which these tend to exist are;

- Contractual Service Description - part of a customer / supplier legal agreement where what is being delivered needs to be concise
- Service Catalogue (Public) - part of your businesses website / marketing collateral where you describe the services you offer
- Service Catalogue (Internal) - the portal where your internal IT department lists the services that users get as standard or that can be ordered

However, there is a common set of information, described below, that a Service Description should cover.

SCOPE - this is where you clearly describe what the service is and what it will, and as importantly will not (exclusions), delivers.

SERVICE LEVELS & PATTERNS - this is the level of service that a consumer should expect to receive and when the service will be available to them.

GOVERNANCE - how the service will be governed, who the key points of escalation are and what the measurement periods will be.

CHARGES - inescapable, but possibly less relevant in an internal IT department setting, how much the customer will pay for the service(s) that you are describing is important.

### Service Management Design - the how and tho who…

A Service Management Design (or Architecture or Blueprint or…) is the document where you describe how the service is going to be put together to deliver the service.

It covers the various building blocks needed, and how they interact, to deliver the service(s) covered by the SDP.

Typically, in no particular order, this includes;

SCOPE - this is where you clearly describe what the service is and what it will, and as importantly will not (exclusions), delivers.

RCTM - the Requirements Capture and Traceability Matrix where all the requirements that the service(s) need to meet are captured.

COMPLIANCE - the legislative, regulatory and industry standards that the service(s) need to comply with. Examples include ISO20k, ISO27001, Payment Card Industry (PCI) etc

UTILITY / WARRANTY - what the service(s) provide functionally, the *utility*, and when the customer / user can expect the service to be available to them, the *warranty* or Service Levels.

PROCESSES - the ITSM processes that need to be used for the service(s), whether there is any “localisation” needed or whether bespoke processes are needed.

TOOLSETS - the shiny toys that the service and support functions will use to underpin the ITSM process and technical activities required to manage the service. Given the availability or relatively mature and emergent technologies, the following should be considered;

- Integration
- Robotic Process Automation
- Artificial Intelligence
- Augmented and Virtual Reality
- Smart Locker / Vending solutions
- Self-healing systems

DATA MAP - crucial to both understanding where the data that will feed into your billing and performance measurement of the service, as well as helping you to understand your position as it relates to data residency and access legislation / regulations.

> Data is like garbage. You’d better know what you are going to do with it before you collect it. - Mark Twain

ROLES & FUNCTIONS - the individual roles and functions, within your organisation, that will perform day to day management or technical support functions to support the service(s). Examples are Service Desk, Security Operations Centre, Service Delivery Manager or Release Management.

PARTNERS / SUPPLIER MANAGEMENT - the third parties, and how they will be managed / governed, they will deliver aspects of the service(s). Thought needs to be given as to how Service Levels will be flowed down to them.

INFORMATION SECURITY - either described separately, or interwoven into all of the above, a description of how Information Security will be managed against the defined Information Security Management System (ISMS).

> It takes 20 years to build a reputation and few minutes of cyber-incident to ruin it. - Stephane Nappo

RAID - the identified Risks, Assumptions, Issues and Dependencies of the service(s), both for the transition to live and ongoing.

TECHNICAL REFERENCE DOCUMENTS - such as…
- Enterprise Architecture
- High Level Designs for Networks, Applications, Infrastructure, Integrations, Enterprise Management, Data Management
- ISMS, Role Based Access Controls etc
- Disaster Recovery, Backup, Recovery and Data Retention 

### Ops Policies, Processes and Procedures

A service can be described beautifully and designed to within an inch of its life but, when the brown and sticky hits the spinning blades, it is the operational processes and procedures, based on well thought out policies, run by well trained people that will see you through. Consideration should be given to…

- Incident, Problem and Event
- Call Handling, Knowledge Articles and escalation management
- Major Incident Management
- Change (Normal, Standard and Emergency), Release, Knowledge and SACM
- Information Security, SIEM, Access Control etc
- Applications Management, Agile and DevOps
- Capacity and Availability
- IT Service Continuity
- Technical Management, Patch Management, On Premise vs Hybrid vs Cloud and Technical Refresh
- Request Catalogue and Fulfilment
- Management Information, Billing and Invoice to Cash
- Continual Service Improvement

## Things to avoid…

Based on my, not inconsiderable experience, try to avoid the following.

- Trying to fit all of the above into a single document, it doesn’t work and creates a monolithic document that no-one, other than insomniacs, will want to read
- Re-inventing the wheel, re-use is awesome and helps to create consistency (as long as it is consistently good!)
- Repetition, say it once and cross reference, where practical. Adopting a Document as Code approach can greatly help with this 

> In our company, we all have 2 jobs: 1) to do our job and 2) to improve it - Toyota

## A final word…

Ultimately the SDP scope you use has to meet the needs of the business environment that you are working in. Hopefully this article has been of some use and has given you a good idea of the types of areas that need to be addressed.

I wish you well on your ITSM journey…

XLAs

Greetings!

This weeks article is dedicated to is XLAs (eXperience Level Agreements) and will answer:

- What are they?
- Should you care?
- How can they be used?

## What is an XLA?
A couple of quotes to start us off…

> XLA is a powerful new addition to the traditional IT Service Level Agreement (SLA). One that builds on the SLA concept by measuring human sentiment and using this to break down silos and think and act from the perspective of a user. 
*Source: [Giarte.com](https://www.giarte.com)*

> Xperience Level Agreement (XLA) is the *concept* of consensus between IT service provider and consumer regarding the desired human experience and business impact.  
> 
> It is also an *agreement* that extends the scope of the output-oriented Service Level Agreement (SLA) to describe the collaboration, experience, and business impact associated with IT services – the outcome. This outcome-oriented document defines the agreed goals, metrics that indicate achievement of the goals, and procedures for collaboration.
*Source: [www.xlaconsortium.com](https://www.xlaconsortium.com)*

In my opinion, both of the above quotes work quite nicely.

An SLA is purely an objective measure based on metrics that are gather from tools (ideally). It should be unimpeachable. 

However, beware of watermelons… which is where your shiny SLA dashboard or report is a field of green, but your customer still isn’t happy! This usually signifies you are not measuring the right things.

An XLA is a combination of objective and subjective measures that give you a balanced measurement of the impact of the service, with a weighting towards how the “users” experiences the service.

## Should you care?
Yes, yes you should… assuming that you are providing a service to a customer  rather than a utility type product that is positioned as being a “service”.

## How can XLAs be used?
XLAs can be used in a number of ways.

- Drive a specific business outcome e.g. adoption of digital channels to drive quicker resolution for users
- Improve the relationship between supplier and consumer by measuring what actually matters to your customers and users
- Gauging the impact of a new supplier or service, so that improvements can be identified
- Measuring the end user experience (UX) for one or more applications, as long as there is a subjective element to the measurement
- Impact of a change programme

The possibilities are varied. The key is having the subjective measure as part of any XLA calculation, ideally captured in a consistent way e.g. using a user survey tool.

However, XLAs should *not* be used as a stick to beat a supplier of services with. Rather they should be entered into as a joint exercise between the Service Provider and Customer to drive improvements.

In future posts I will be diving deeper into this space, so keep an eye open!

Agile Service Management

Greetings!

In this article I will be looking at *Agile Service Management&reg;* (ASM) and how it can be practically implemented. This will be based on the real world experience I gained in my 12 years as a Service Architect.

## What is ASM and where did it come from?

ASM is an approach to developing and maintaining ITSM processes. It was developed by the DevOps Institute&reg; in response to the perception that ITSM can be a blocker to the speed and agility of delivering benefit to the business.

So ASM is essentially using the Scrum, but instead of developing software you are developing processes. The following diagram compares ASM to pure Scrum and identifies key differences in terminology and cadence.

![Agile Service Management!](https://res.cloudinary.com/xenos-design/image/upload/v1687715150/ITSM/ASM_high_level_diagram_v0.1_brkh3d.jpg)

So, as you can see, the key differences are;  

- Scrum Master = Agile Service Manager  
- Product Backlog = Process Backlog (or CSI Register if it is a mature process)
- Product Owner = Process Owner  

## Example Implementation: Developing the Service and Support Model

This example of implementing ASM is where I was working with a client, who were creating a new business application using SCRUM to manage the software development, and there was a need to align the development of the service management and support model in alignment with the sprint planning and cycles.

This new application was going to be supported by a well established and mature support organisation. This meant that I didn’t have to look a standing up new processes, rather that I needed to analyse what needed to be designed and implemented to support the smooth transition from project to live service.

What I ended up with, as an output of the analysis, was a number of *Epics*, spanning the various processes, functions and tools, each of which had a number of high level *User Stories*. 

These *User Stories* were classified as either Enablers, which meant they needed to be completed before further work could be undertaken, or Functional, which were delivering specific elements inline with the delivered output from the software development sprints.

Then I brought all of the key protagonists together for a *Backlog* refinement and initial sprint planning session. This turned out to be invaluable as we were able to refine some needs, re-align others and produce the *Sprint Backlog* for the enabler sprint and the first functional sprint.

These sprints went well, or at least better than I was expecting given how new the approach was to all parties, and the project was delivered successfully. 

The following actions / activities certainly paid dividends;

- Establishing the *Minimum Viable Product* (MVP) is less straight forward in a well established ITSM model than if you are building some thing new, so allow time for this, listen to opinions but never be afraid of challenging the “norm” as, just because something is done in a certain way it doesn’t mean it is the best or most efficient way
- Engaging with the local process owners early on, and taking them through the ASM&asm; approach, and listening to their concerns helped to smooth the path to adoption
- Working closely with the software Product Owners and Solution Architects enabled early identification of challenges and producing collaborative responses 
- Acknowledging that issues arise in live operations, that may require the “service development” teams focus, and allowing a reasonable allowance in the *Sprint Plan* worked well and allowed us to meet expectation
- Stabling the correct routes of escalation, so that blockers can be removed as soon as possible, is essential to maintaining the cadence of the team

## Moving Forwards…

In my opinion the ASM approach can be very useful when you need to deliver and maintain an ITSM model for a software product where SCRUM, or another form of Agile, is used. However, as with any tool, it is not a one size fits all answer, so give serious consideration to the environment in which you want to use it.

I recommend that you go to the [DevOps Institute](https://www.devopsinstitute.com/skilbooks/agile-service-management-guide/) site and read about ASM further. 

If you decide that you want to use ASM then there are a couple of certification courses that you can attend, both developed and licensed by the DevOps Institute.

These are *Certified Agile Service Manager* (CASM) and *Certified Agile Process Owner* (CAPO). I have attended both of these courses, and gained the certifications, and see there is a lot of content that is repeated so attending one or the other, depending on what role you will be in, should be suffiicient to get a good baseline of understanding.

I hope that you found this article useful and I wish you good fortune in your ITSM journey.

An Introduction to ITSM

Greetings!

So, assuming you are relatively new to it, I thought I would give a high level overview of what ITSM is.

ITSM is an acronym, we use a lot of these, for Information Technology Service Management.

Since the early days of I.T. there has been a concept of “managing” the services that customers were buying. Initially this was very limited to support the products (hardware or software) that were purchased and, in my opinion, was very much there to drive additional sales rather then deliver any tangible value beyond that derived from the products.

Towards the end of the 1980’s the Central Computing and Telecommunications Agency, a government department in Great Britain, developed a framework for managing IT infrastructure. This methodology was called ITIL&reg; (IT Infrastructure Library), and was series of books that described how IT could be managed in a consistent way. It is now owned by AXELOS&trade;.

My first introduction to ITIL&reg; was in the late 1990’s / early 2000’s as I moved up the career ladder. At that point ITIL&reg; v2 was out and predominantly focused on two areas Service Delivery (SLAs, BCDR etc) and Service Support. My enduring memory is sitting two very long, and handwritten, exams after 2 weeks of training, which felt quite hellish at the time.

Since then ITIL&reg; has kept evolving with v3 coming out in 2007 and v4, the most recent iteration, coming out in 2019.

One of the things I have always found fascinating in this areas is the continual evolution of how close an “IT Department” should be to its “Customer” from a relationship and goal alignment perspective. Initially coming across as quite standoffish through to being closely interwoven with how the business operates.

Also that ITIL&reg; has never positioned itself as a standard that must be followed to the letter. Rather you _adopt_ the methodology and _adapt_ it to the needs and constraints of your organisation. Thankfully this message has never changed but, what has grown up along side this methodology, are a number of other frameworks and standards, such as:

- _[Microsoft Operations Framework](https://learn.microsoft.com/en-us/previous-versions/tn-archive/cc506049(v=technet.10)?redirectedfrom=MSDN)_ - based on ITIL, that came out in 2008
- _[ISO 20000-1](https://www.iso.org/standard/70636.html)_ - the international standard for IT Service Management. This has been heavily influenced by ITIL evolution over the years and could be considered the hard stick for what “good” looks like
- _[IT4IT](https://www.opengroup.org/it4it)_ - developed by The Open Group&trade; who, among other areas, own the TOGAF framework for Enterprise Architecture (I am a big advocate of this) , this is a architectural model for delivering and managing IT service. There is a lot of crossover, in my opinion, between this and ITIL&reg; v4 which makes them very complimentary
- _[Agile Service Management](https://www.devopsinstitute.com/skilbooks/agile-service-management-guide/)_ - developed by The DevOps Institute, which heavily focuses on service management process development as a “product”. Think scrum for process development and maintenance and you will get the picture.

Now, fascinating as this potted history is, it doesn’t quite answer the question of what ITSM actually is.

One definition of ITSM is

> IT service management (ITSM) is a strategic approach to design, build, deliver, operate, and control information technology (IT) services offered to customers. Source: Wikipedia.

This is an ok, if somewhat dry, statement but misses a fundamental point, which is that IT, as a business function / capability, _MUST_ be aligned with the operational, regulatory and governance needs of the business that it delivers to.

If this isn’t achieved the IT will typically be seen as a “problem child”. Sadly even today, this kind of mis-alignment between the business needs and what the “IT department” thinks it reason for existing is, still exists.

Now when you get into the world of Managed IT Services e.g. those procured by a business from a 3rd party organisation, the original definition is still ok, but there still needs to be that alignment between the _consumer_ and _provider_ of IT services, albeit constrained by the boundaries of a commercial agreement (contract) of some kind.

I will be expanding on some of these areas in future posts.

I will sign-off at this point but watch out for future posts and discussions.

Filtering your Markdown posts

Welcome back!

Following on from my previous post [Create a NextJS blog using Markdown](https://www.stevengodson.com/blog/2023-06-15-nextjs-md-blog), I will now show you how to add Category filtering to your blog so that your ordinance can choose to see all posts of a particular type.

Before we begin you will need to have followed the installation steps in Part 1 of this series

## Key Files

The key files that we will be updating or creating are as follows.

**./components/BlogFiltersCategory.js** - this is the component that will render the interactive filter choices in the ./pages/blog/categories/index.js page.

**./components/BlogFiltersMain.js** - this is the component that will render the interactive filter choices in the ./pages/blog/index.js page.

The above two components are essentially the same apart from the href in the Link element, which points to different places.

**./components/BlogList.js** - this will need to be updated to show the categories against each posts card in the list.

**./pages/blog/categories/index.js** - this is the page that will filter your posts, based on the category selected, and render the list.

**./pages/blog/index.js** - this is the main blog page which will require minor updates to enable the filtering.

**./pages/blog/[slug].js** - this will need to be updated to show the categories against each post.

**./global.css** - This is where the styling for the dynamic components will be added.

The posts themselves will require an update to include the appropriate data into a unique entry against which the filtering can take place.

## Creating your filter
### Post Meta Data

The first thing that we will do is look at the metadata, which is at the front of each post, and amend it from this:

![Meta Data!](https://res.cloudinary.com/xenos-design/image/upload/v1687195278/Post_Content/nextjs-md-filters/001_gvyewg.png)

to this:

![Meta Data!](https://res.cloudinary.com/xenos-design/image/upload/v1687195278/Post_Content/nextjs-md-filters/002_bojc8s.png)

It is worth investing some time to consider what categories you want to use on your posts so that you have as complete a list as possible before we continue.

## Creating new files
Now we will create the new files needed to make this work.
### BlogFiltersMain.js

Create this file in the /.\/components/ folder and copy in the following code.

```jsx
import React from 'react';
import Link from 'next/link';
import Row from 'react-bootstrap/Row';
import Col from 'react-bootstrap/Col';

function BlogFilters() {
    const filters = ['Technology', 'Business', 'Freelancing', 'Personal'];

    return (
        <Row>
            {filters.map((filter, index) => (
                <Col md={6} lg={3} key={index}>
                    <Link href={`./blog/categories?category=${filter}`}>
                        <div className={`filterTag_${filter}`}>{filter}</div>
                    </Link>
                </Col>
            ))}
        </Row>
    );
}

export default BlogFilters;
```

Some key points to explain are:
* I have used /react-bootstrap/ for the row and column control
* There is an array of *strings* in this file, this needs to represent all of the categories that you want to actively use. This has been used in place of a table that would typically be used database or CMS-based blog. To avoid duplication you could store these values in a /.env/ file
* The /href/ in the /Link/ component points to one of the new files, that we will create later in this exercise, and passes in the filter name as a URL query so that it can be picked up from the context using getServerSideProps()
* The className content is also set dynamically with the styling controlled from the /global.css/ file

### BlogFiltersCategory.js

Create this file in the /.\/components/ folder, copy in all of the content from the /BlogFiltersMain.js/ files, and simply change the following.

```jsx
<Link href={`./blog/categories?category=${filter}`}>
	<div className={`filterTag_${filter}`}>{filter}</div>
</Link>
```

to

```jsx
<Link href={`./categories?category=${filter}`}>
	<div className={`filterTag_${filter}`}>{filter}</div>
</Link>
```


### Categories index.js

Now we will create the page where the filtered list will render.

Create the following folder /.\/pages/blog/categories\// and created an *index.js* file.

Now copy in the following code.

```jsx
import React from 'react';
import Link from 'next/link';
import matter from 'gray-matter';
import Layout from '../../../components/Layout';
import BlogList from '../../../components/BlogList';
import BlogFilters from '../../../components/BlogFiltersCategory';
import styles from '../../../styles/Blog.module.css';

function Categories({blogData}) {
    return (
        <Layout>
            <h1 className={styles.heading}>Tales from the deep...</h1>

            <hr />
            <h5 className={styles.heading}>Filter by Category or <Link href="../../blog">Back to Full List</Link></h5>
            <BlogFilters />
            <hr />

            <BlogList allBlogs={blogData} />
        </Layout>
    );
}

export default Categories;

export async function getServerSideProps(context) {

    const { req } = context;
    const passedURL = req.url;
    let filterName = passedURL.split('=');
    filterName = filterName[1];

    const webpackContext = require.context('../../../posts', true, /\.\/.*\.md$/);
    const keys = webpackContext.keys();
    const reverseKeys = keys.reverse();

    const values = reverseKeys.map(webpackContext);

    const posts = reverseKeys.map((key, index) => {
        const slug = key
            .replace(/^.*[\\\/]/, '')
            .split('.')
            .slice(0, -1)
            .join('.');

        const value = values[index];
        const document = matter(value.default);

        return {
            frontmatter: document.data,
            markdownBody: document.content,
            slug,
        };
    });

    const filteredPosts = (posts, filterName) => {
        const data = posts.filter((post) => post.frontmatter.category === filterName);
        return data;
    };

    let data = filteredPosts(posts, filterName);

    return {
        props: {
            blogData: data,
        },
    };
}
```

This file is very similar to the main *index.js* in the ./pages/blog/ folder. 

The key differences are:

* The use of *getServerSideProps* instead of *getStaticProps*. The reason for this is so that we can access the *context* API and pull the filter name that is passed from the filter components. This gets stripped from the request URL and passed into the *filteredPosts* function so the list of all posts can be filtered
* Use of the BlogFiltersCategory.js functionality. This ensures that a user clicking on categories after the initial filter will not be thrown back to the main blog page
* Reuse the BlogList component so there is a consistent look and feel to the site

### global.css

If you want to follow the same styling approach then copy the following into the *./styles/global.css* file.

```css
.tag_Technology,
.tag_Freelancing,
.tag_Personal,
.tag_Business {
    text-align: center;
    background-color: var(--secondary-color);
    color: var(--primary-color);
    padding: 0.2rem 0;
    letter-spacing: 2px;
    font-size: 1.5rem;
}
.tag_Freelancing {
    background-color: #00796b;
}
.tag_Personal {
    background-color: var(--primary-color);
    color: var(--secondary-color);
}
.tag_Business {
    background-color: darkblue;
}

.slugTag_Technology,
.slugTag_Freelancing,
.slugTag_Personal,
.slugTag_Business {
    text-align: center;
    background-color: var(--secondary-color);
    color: var(--primary-color);
    padding: 0.2rem 0;
    letter-spacing: 2px;
    font-size: 1.5rem;
    min-width: 250px;
    border-radius: 5px;
    margin-bottom: 2rem;
}
.slugTag_Freelancing {
    background-color: #00796b;
}
.slugTag_Personal {
    background-color: var(--primary-color);
    color: var(--secondary-color);
}
.slugTag_Business {
    background-color: darkblue;
}

.filterTag_Technology,
.filterTag_Freelancing,
.filterTag_Personal,
.filterTag_Business {
    text-align: center;
    background-color: var(--secondary-color);
    color: var(--primary-color);
    padding: 0.2rem 0;
    letter-spacing: 2px;
    font-size: 1.5rem;
    width: 100%;
    border-radius: 5px;
    margin-bottom: 1rem;
    cursor: pointer;
}
.filterTag_Freelancing {
    background-color: #00796b;
}
.filterTag_Personal {
    background-color: var(--primary-color);
    color: var(--secondary-color);
}
.filterTag_Business {
    background-color: darkblue;
}
```

If you are using another approach e.g. SASS, Bootstrap, or TailwindCSS then you can skip this section.

## Updating the existing document

Now that we have created the new pages and components we can move on to updating the existing pages and components to bring it all together.

### Blog index.js

Update the *./pages/blog/index.js* page to include the *BlogFilterMain.js* component as shown below.

![Blog Index!](https://res.cloudinary.com/xenos-design/image/upload/v1687195278/Post_Content/nextjs-md-filters/003_aonw61.png)

### BlogList.js

Now we update the BlogList component to render out the category name that has been added to a blog. I have done this as a conditional statement but, if you are sure it will always be added, you can add it without the conditional.

![Blog List!](https://res.cloudinary.com/xenos-design/image/upload/v1687248085/Post_Content/nextjs-md-filters/004_ua3j8o.png)

### Blog [slug].js

Finally, we will update the page, where all the content of an individual post is shown, to show the category name as well.

![Blog Slug!](https://res.cloudinary.com/xenos-design/image/upload/v1687195278/Post_Content/nextjs-md-filters/005_lww0os.png)

## Let's fire it up…
We are now ready to run the project and see our content. To do this you simply need to:

* navigate to the root folder in your terminal and run `npm run dev`
* open your browser navigate to *[http://localhost:3000/blog](http://localhost:3000/blog)*

The following should be visible on the screen.

![Working Blog!](https://res.cloudinary.com/xenos-design/image/upload/v1687248198/Post_Content/nextjs-md-filters/006_bagl8o.png)

And that’s it for now… you have now updated your blogging site, using Next’s and Markdown, and enhanced the experience of your readers. Hopefully, you found this article useful and will continue your journey.

In the next post of the series, we will be adding further functionality to your main *index.js* page by adding functionality for * latest posts*.

Thanks for stopping by…

Creating a NextJS blogging website using Markdown

Greetings!

In this article, the first in a series, I will take you through creating your own blogging website using the NextJS framework and Markdown files for the content.

A preview of the site can be seen at [https://nextjs-13-markdown-blog-website.vercel.app/](https://nextjs-13-markdown-blog-website.vercel.app/).

The advantage of this approach versus using a CMS backend e.g. Strapi, Ghost etc, is that you can build and deploy your site using Vercel without incurring any costs.

Being open there are limitations / compromises with this model, which I will talk about later on, but having built many CMS-based sites I like the simplicity of this approach.

## Now, let’s get started!

Firstly, you will need to clone the template repo that I have created for this article. This repo contains all you need to get started.

So create your project folder and navigate to it in a terminal. Then run the following.

```
git clone https://github.com/wookiehunter/nextjs-13-markdown-blog-website.git
```

Once the clone is complete, run the following to install the project's dependencies and start the project.

```
npm install && rpm run dev
```

Then, in your browser, navigate to [http://localhost:3000](http://localhost:3000) and you will be able to see the following front screen.

![NextJS Markdown Blog](https://res.cloudinary.com/xenos-design/image/upload/v1686830042/Post_Content/nextjs-md-blog/001_kne8bm.png)

We are now ready to move on and look at the project folder and file structure.

## Project Structure

If you haven’t already, open the project using your chosen Code Editor / IDE. I use [Visual Studio Code](https://code.visualstudio.com/) for all Node.js/ReactJS projects.

### Folder Structure

The repo that I have provided comes with the following folder structure.

![NextJS Markdown Blog](https://res.cloudinary.com/xenos-design/image/upload/v1686830043/Post_Content/nextjs-md-blog/002_ivlaou.png)

/*Components*/ - this is where the reusable React components will be kept.

/*MD\_Templates*/ - used to store any templates that you want to use to create your content.

/*node\_modules*/ - this doesn’t come with the repo as it is created when you run the `rpm install` command.

/*Pages*/ - this is the folder where you create the structure and pages for your NextJs project.

/*Posts*/ - this is where we will store the Markdown documents that will be used for your blog posts.

/*Public*/ - this is the folder where NextJs needs files that will be presented by your website kept, assuming you are not using separate storage or a CDN, such as images and Favicon files.

/*Styles*/ - CSS files are kept here. I have used CSS module files, but you can use any approach you are comfortable with e.g. Tailwind CSS, SASS, or Bootstrap.

/*Utils*/ - used to store utility functions used by your project. I have included one for Google Analytics as an example.

### Key Files

The key files that we will be focusing on are:

![NextJS Markdown Blog](https://res.cloudinary.com/xenos-design/image/upload/v1686830042/Post_Content/nextjs-md-blog/003_nxeabp.png)

/*Components/BlogList.js*/ - this is the component that will render your list of posts.

/*Pages/blog/\[slug\].js*/ - when you click o a post in your list, this is the page that will control how the post content is displayed.

/*Pages/blog/index.js*/ - this is the page that renders when you click on the Blog navigation link. You don’t need to use this if you want to show all of your posts on your home page pages/index.js

/*Posts/0001-my-first-post.md*/ - example of a post.

/*Next.config.js*/ - we need to add a specific config to this the project works correctly.

## How it works…

### Webpack Configuration

The following needs to be added to the next.config.js file. This allows Webpack to use [raw-loader](_https%3A//www.npmjs.com/package/raw-loader_) on .md files and create the arrays of Posts that you will showcase on your website.

![NextJS Markdown Blog](https://res.cloudinary.com/xenos-design/image/upload/v1686830042/Post_Content/nextjs-md-blog/004_gdpwc7.png)

### Using Markdown to create content

![NextJS Markdown Blog](https://res.cloudinary.com/xenos-design/image/upload/v1686830043/Post_Content/nextjs-md-blog/005_aepw3c.png)

The above shows the format used in the example Markdown post. There are two key sections in the file.

The first section, shown below, is written in [YAML](https://yaml.org/) and can be thought of as metadata. This specific format is used by the [gray-matter](_https%3A//www.npmjs.com/package/gray-matter_) dependency package and allows us to use dot notation to access the values e.g. frontmatter.title etc.

```yaml
---
title: 'My first post..?'
author: 'Your Name'
date: '2021-06-01T12:00:00.000Z'
hero_image: /magic.png
intro: "I did a thing..."
keywords: "Next.js, Markdown, blog, tutorial, gray-matter, webpack, React, web development, static site, Vercel"
read: 3
---
```

/Note: when adding images, you can either point to content in the public folder of the project, as shown in the example, or use a URL to content in a CDN, Image site e.g. [Freepik](_https%3A//www.freepik.com_) or [Unsplash](_https%3A//www.unsplash.com_), or cloud-based storage./

The second section is the content of your post and can be written using Markdown syntax, see [https://www.markdownguide.org/basic-syntax/](https://www.markdownguide.org/basic-syntax/) for a basic guide.

Another key consideration is the naming convention that you use for your post .md files.

The repo that I have provided has the following code, in the /*posts/index.js*/ file, which reverses the array of keys that Webpack creates when it interrogates the /*posts*/ folder.

```jsx
export async function getStaticProps() {
    const webpackContext = require.context('../../posts', true, /\.\/.*\.md$/);
    // the list of file names contained
    // inside the "posts" directory
    const keys = webpackContext.keys();
    // this reverses the order of the posts to show the most recent first or alphabetically descending order
    const reverseKeys = keys.reverse();
    const values = reverseKeys.map(webpackContext);
    // getting the post data from the files contained
    // in the "posts" folder
    const posts = reverseKeys.map((key, index) => {
        // dynamically creating the post slug
        // from file name
        const slug = key
            .replace(/^.*[\\\/]/, '')
            .split('.')
            .slice(0, -1)
            .join('.');
        // getting the .md file value associated
        // with the current file name
        const value = values[index];
        // parsing the YAML metadata and markdown body
        // contained in the .md file
        const document = matter(value.default);
        return {
            frontmatter: document.data,
            markdownBody: document.content,
            slug,
        };
    });
```

This is because I use a naming convention that allows for the newest posts to be shown at the top of the web page (the specific format I use is [yyyy-mm-dd-post-name.md](http://yyyy-mm-dd-post-name.md)). If you want to show your posts in alphabetical or some other order, you can amend the code easily.

Just replace the above with.

```jsx
export async function getStaticProps() {
    const webpackContext = require.context('../../posts', true, /\.\/.*\.md$/);
    // the list of file names contained
    // inside the "posts" directory
    const keys = webpackContext.keys();

    const values = keys.map(webpackContext);
    // getting the post data from the files contained
    // in the "posts" folder
    const posts = keys.map((key, index) => {
        // dynamically creating the post slug
        // from file name
        const slug = key
            .replace(/^.*[\\\/]/, '')
            .split('.')
            .slice(0, -1)
            .join('.');
        // getting the .md file value associated
        // with the current file name
        const value = values[index];
        // parsing the YAML metadata and markdown body
        // contained in the .md file
        const document = matter(value.default);
        return {
            frontmatter: document.data,
            markdownBody: document.content,
            slug,
        };
    });
```

At this point, it would be a good idea for you to create some test posts for yourself.

## Showing your content on your website

Now that we have content we can discuss how it is shown on the website.

There are three files that are key to creating, showing, and reading the posts in this project.

The first two are the blog/index.js file

![NextJS Markdown Blog](https://res.cloudinary.com/xenos-design/image/upload/v1686830044/Post_Content/nextjs-md-blog/006_wrlcdh.png)

And the components/BlogList.js file

![NextJS Markdown Blog](https://res.cloudinary.com/xenos-design/image/upload/v1686830043/Post_Content/nextjs-md-blog/007_ql0hpn.png)

The first uses Webpack to get the post data and passes it to the second so it can render on the screen.

/Note: you can easily move the code from the first file to your root index.js file if you don’t want a separate posts page./

The third and final file is /*pages/blog/\[slug\].js*/ which shows all of a post's content, at least that which you choose to show when a post is clicked on in the list.

![NextJS Markdown Blog](https://res.cloudinary.com/xenos-design/image/upload/v1686830042/Post_Content/nextjs-md-blog/008_rep2aw.png)

As you can see this has both the frontmatter data and markdownBody content passed into it so that you have access to all of the content in your .md files.

I have used a combination of react-bootstrap and CSS to create a layout and style the content. As mentioned before you are free to use whatever styling approach works for you.

## Let's fire it up…

We are now ready to run the project and see our content. To do this you simply need to:

* navigate to the root folder in your terminal and run `npm run dev`
    
* open your browser and navigate to /[*localhost:3000*/](http://localhost:3000/)
    

The following should be visible on the screen.

![NextJS Markdown Blog](https://res.cloudinary.com/xenos-design/image/upload/v1686830042/Post_Content/nextjs-md-blog/009_kfxxuk.png)

Now click on the Blog link at the top and…

![NextJS Markdown Blog](https://res.cloudinary.com/xenos-design/image/upload/v1689967164/Post_Content/nextjs-md-blog/11_rv0td8.png)

Your posts are showing on your blog page and the content is accessible.

In Part 2 of this series we will be looking at the filters, discussing how these are used and how best to implement them.

5 things to consider for your business website

As a business owner in this modern world of ours, you want to be able to engage with as wide an audience as possible to maximise your potential revenue.

There are many ways in which you can achieve this but most, if not, in reality, all, rely on having an internet presence. So what should this presence be?

Social media is an obvious place to start. Huge audiences, ready-built platforms, global reach etc. However, whilst social media platforms are superb for marketing and customer/client engagement, they are enhancements rather than a replacement for a website/app.

The benefits of your business having a dedicated website are;

- bespoke styling and theme to match your businesses brand

- having the User Experience (UX) that you need to be driven through the User Interface (UI) that you want

- order lifecycle control from basket creation through to payment and order status management

- integration with your payment service

- you can share specialised content behind a secure login

So you have decided that your business deserves a website. What do you need to consider? the simple answer is \"Lots!\" but there are a number of key areas that will help get you started and ensure success. An overview of each of these areas and what they mean to you is summarised below.

## Where should I host my site?

This decision very much depends on a number of factors.

- how much control do you want to have over the look and feel of your website?

- do you want to build/maintain the website yourself or get a professional to do the work?

- how much traffic are you expecting?

- how frequently will your website structure or functionality, not content, be likely to change?

- what technologies do I want my website built with?

The specifics of which hosting provider you ultimately go with is a decision between you and, assuming you are not self-building, your web developer. The two high-level choices are;

### Hosted Service

This is where you use a service such as Wix.com, GoDaddy.com, WordPress.com et, there are many to choose from, and build your website using their templates, 'wizards' etc.

These are a, relatively, painless approach to building a website, especially for the non-technical, and you can be up and running in a fairly short period of time.

There is, however, a trade-off.

Using one of these services means you have less control over how and where your website/data is hosted, as well as having to live with the constraints that the service provider places upon you in terms of what can and cannot be achieved within their service.

This may be perfectly acceptable to you and your business, especially when starting out where you want something quick and easy, but be mindful of the future when your business is growing rapidly and you need to migrate to a more functionally rich solution.

### Self Hosted

The title of this option is somewhat misleading in that you do not have to build your own data centre, networks etc, rather that you take responsibility, albeit sub-contracted out to cloud providers and professionals, for where and how your website/app is hosted as well as the maintenance of the solution.

This opens up a cornucopia of possibilities and technology choices which, as a business owner, you may not want to spend time on. This is absolutely fine as you can leave a lot of these decisions to your trusted professionals who should be able to guide you down the right path depending on what business outcomes you want to achieve.

There is, of course, a trade-off. See what I did there...

By implementing your website/app in this way it is quite possible that it will be more expensive than using a Hosted Service.

However, the benefits from this approach, which in my experience outweigh the costs, are;

- flexibility

- scalability

- speed of change

- ability to try out new technologies

- ability to swap out providers to get better prices or enhanced services

## Domain name

So firstly \"What is a domain name?\"...

![Domains!](https://res.cloudinary.com/xenos-design/image/upload/v1650973009/Post_Content/web_domain_illustration_15756c7010.png 'Domains')

This is a key decision as the domain name you choose needs to be;

- **Memorable** - choose something that will stick in the memory

- **Meaningful** - relate to your business name or what your business does

- **Available** - you need to make sure that the domain name you want is available

It is also worth considering whether you want to register, although not necessarily use, multiple top-level domains, such as .com, .co.uk, .uk etc.

This is usually done to safeguard your business against competitors from trading under a similar web address and capitalising on your brand and hard work. These can be registered altogether, some Registrars provide bulk discounts, or later on as your business grows.

The one thing to be mindful of is that domain name registration is an ongoing cost, frequency-dependent on which Registrar you choose, and needs to be maintained otherwise you lose rights to the domain name(s) and your website will no longer be reachable.

## SEO / Analytics - putting you on the map, and keeping you there

Search Engine Optimisation (SEO) is all about getting to Page 1 on a Google search (other search engines are apparently available) and can be seen as a form of wizardry at times.

There are many articles that can be found online that go into this subject in much greater depth than I would want to in this article. Suffice to say that there are a few key considerations that you need to give consideration to when thinking about a website/app for your business.

- **Metadata** - this is the, mostly, unseen content in you site that search engines look for and index for users to search against. the main three are;

- **Title** - the text that appears in your browser tab

- **Description** - tells search engines what your site or page is for

- **Keywords** - the words that you specifically would like search engines to include your site in searches for

- **Sitemaps and Robots.txt** - these are files that need to be created and stored in the root directory of your website/app and are specifically there to help search engines by telling what content is important and what can be ignored

All this is great but unless you proactively monitor your performance and adjust accordingly your website is unlikely to rise to the heady heights of Page 1.

There are many, free and paid for, services and tools that will help you do this. My recommendation is that you start off with a free one, such as Google Analytics, and see how you get on before progressing to a paid tool.

If you are time-poor, understandable as you are building the next mega-corporation, then outsourcing this to a professional who will do the monitoring and maintenance for you is a great way to take the stress away.

## Images - stock vs owned

Depending on what your business does or is trying to market with a website then you will need to consider where your images come from and whether you want to pay a license fee or provide your own images, assuming you own the rights to use them and have these on the site.

I always look at it like this.

Am I showing a proprietary product or service that I want to have specific images of on my website?

If **YES**, then either hire a professional photographer to take the images you want (make sure the price includes you owning the right to own/use) or, if you are a budding photographer, take the images yourself and store them securely.

If **NO**, then using stock images, from services such as Getty or Unsplash, is a great way to go. Just make sure you read the licensing terms and understand whether you need to add a 'credit' against each image or somewhere on your website.

**Content / Copy**

Similar to images the written content on your website/app also needs to be considered and either outsourced to professionals or, if you have the experience necessary qualifications/experience/skills, do the job yourself.

Consideration should be given to bringing in professionals for the following areas;

- Legal and Commercial

- Sales and Marketing

- Technical Writing

- Content creation e.g. articles or blogs

## Summary

All of this can seem quite daunting, especially if you don't come from a technical background, so it is always worth speaking with a professional who can guide you through the process and help you make the right decisions for your business.

Securing your Media in WordPress

It may sound like a contradiction, but there are times when you upload content to your web fronted Content Management System but do not want it to be publicly visible.

Business use cases for this scenario include;

- legal services, where the content may be sensitive or covered by legislation such as GDPR
- creative or artistic content, where you have to show your work but do not want anyone to steal it
- members or subscribers only content, where you want to make the content visible to select or fee-paying subscribers

This article will address each of these scenarios and identify options for achieving the desired outcome. The choices I talk about are WordPress specific, but the context and principles are relevant to any technology.

## Legal Services

When your business provides legal services and your CRM uses WordPress, it is vital to keep the documents (images, PDFs) hidden from general view.

If you do not take specific action to secure your data, it will be indexed by search engines and can be accessed via the directory of your website e.g. _<a target=\"\_blank\" rel=\"\" href=\"http://www.example.com/wp-content/[$filename]\">www.example.com/wp-content/[$filename]</a>_.

This means you are unlikely to comply with local data protection regulations e.g. GDPR in the EU. Not to mention being open to litigation from clients who find their data is open to the world!

There are two specific actions you can take to negate these issues. Each has different layers of complexity depending on what needs to be delivered.

## Creative and Artistic Content

If your website is there to showcase your talent you do not want visitors to download it without permission.

Failure to protect your work can have the following consequences:

- Loss of revenue – if you sell your art through your website, and it is not under your control, you are potentially losing revenue.
- Intellectual property – your art is your intellectual property and should be protected against theft.

## Private or Paid for Content

If you produce content and want to monetise it or only make it available to who you want, you need to ensure that it is only accessible to those who should have access.

## So what can you do…?

Depending on your specific use case(s) three options available to you are:

_robots.txt file_

Adding a ‘robots.txt’ file to your website is a way of discouraging search engine crawlers (think leaf cutter ants, collecting info and returning with it to the hive) which URLs on your site they can access.

This is by no means foolproof and is not a guarantee of your content not appearing on search engine results.

**_Redirect_**

Adding redirect functionality to your website is a way of ensuring that direct access to your content, media files etc, is restricted to logged-in users.

In essence, it performs a check against content type and whether the browser trying to access it has an active session. If both conditions are not met, it redirects the browser to a specified URL (typically the home or login page).

This tends to be an “all or nothing” approach and does not differentiate between user roles. It also does not have any impact on search engine indexing.

**_Plugins_**

If you need a more robust solution, then there are plugins available for WordPress that will give you the following:

- Media file protection
- File type protection
- Role-based access to media files
- disable right-click functionality
- Prevent hot-linking to your content
- Enhanced redirects
- Block search engine indexing of media files
- Media file encryption
- Manual or automated creation of private links so you can share media files, with timed expiry capability
- Bulk protection functionality, if you have a lot of existing content you want to protect
- Integration with other plugins to provide enhanced capability

## Summary

Ensuring that your business is compliant with the relevant legislation and industry standards is critical to its continued success in building trust.

Efficiency through automation

In today's fast-paced world, businesses need to have a range of tools to ensure they are current with contacts from potential clients, partners or employees.

A key challenge is the greater the number of tools, the greater the complexity. So how should businesses address this challenge?

A great way to get around this is to integrate priority business systems. This ensures a clear flow of information and alerts to the appropriate communication channels.

I recently completed a project with a fantastic client, addressing this very issue.

Their starting position was quite typical. They had three web forms that sent data to a content management system. The client then took this data and copied it to a CRM. Not very efficient.

![Design 1!](https://res.cloudinary.com/xenos-design/image/upload/v1650975932/Post_Content/JR_1_a51220fe2c.png 'Layout')

Thankfully my client is dynamic and always looking to improve how they work.

This is the point where I got involved with the project. The brief? Integrate our web forms (NextJS/Formik) with our CRM (ClickUp) and messaging tool (Slack).

![Design 2!](https://res.cloudinary.com/xenos-design/image/upload/v1650975858/Post_Content/JR_2_636b77aa4a.png 'Layout')

Once I had reviewed the documentation and experimented with the integration options, the way forwards became clear.

The agreed solution was to integrate the web forms to ClickUp using its REST API to POST the data, as new tasks, to specific 'Lists'.

Then, using its native functionality, integrate ClickUp with Slack so that notifications would be generated, in the correct channels, when a new ClickUp task was created.

![Design 3!](https://res.cloudinary.com/xenos-design/image/upload/v1650975858/Post_Content/JR_3_8fc663b939.png 'Layout')

This took relatively minimal effort. The most time-consuming part was refactoring the functions in the web forms, to the structure for ClickUp and then testing the end to end data flow.

My client was thrilled by the improved workflow and how much time it saved them in manual effort.

Automation can improve customer engagement, improve employee efficiency and reduce operating costs. It doesn't have to be a large project or cost a fortune.

If you want to improve your business's efficiency, get in touch to discuss your requirements.

Using images on your website

It is absolutely true to say that using images on your website is a great way to make it more interesting, break up large sections of text and generally improve the user experience. In this post, I will share some of my experiences to hopefully make you better informed.

## **When should I use images?**

When considering whether an image should be used you should ask yourself the following design question.

_“Will it improve what is already there in some way…?”_

Some great reasons to say yes are:

- You are marketing a product, want to show it off and demonstrate how it works
- You are creating content and want to illustrate it with relevant imagery
- You want to include images that are relevant to your business or brand&nbsp;

If the answer is no, then look no further. However, if your answer is yes, then read on.

## **Where should I get my images from?**

This depends on your answer to the following question.

_“Am I showing a proprietary product or service that I want to have specific images of on my website?”_

If YES, then either hire a professional photographer to take the images you want (make sure the price includes you owning the right to own/use) or, if you are a budding photographer, take the images yourself and store them securely.

If NO, then using stock images is a great way to go. Just make sure you read the licensing terms and understand whether you need to add an ‘attribution’ against each image or somewhere on your website.

Most stock image websites will have ‘free’ content where only attribution is needed as well as ‘premium’ content that you have to pay for on either a subscription or per-image basis.

Examples of stock image sites are:

- [https://www.unsplash.com](https://www.unsplash.com)
- [https://www.istockphoto.com](https://www.istockphoto.com)
- [https://www.stock.adobe.com](https://www.stock.adobe.com)
- [https://www.freepik.com](https://www.freepik.com)
- [https://www.shutterstock.com](https://www.shutterstock.com)
- [https://www.pexels.com](https://www.pexels.com)
- [https://www.gettyimages.co.uk](https://www.gettyimages.co.uk)

## **What is image optimisation?**

Image optimisation is all about ensuring that you only use the largest image needed on your website. The size of an image impacts two things:  
Speed – how fast your website loads when a user has lower bandwidth for their internet connection, and  
Quality – generally the small the image size the worse the quality of the image that is seen.

_Example: a 300 x 300 pixel is unlikely to look great if stretched to 1200 x 1200._

One of the great things about using WordPress is that it will, when you upload an image to the media gallery, automatically create, assuming your image is large enough, a number of different versions of the image in different sizes.

So when you go select an image, to include on a page or in a post, it will present you with these options.

This is the point where you need to think about where you are placing the image and how big it is likely to be on a screen. If the image will be nested within text then there is little point in selecting a high-resolution version. The opposite is also true, if you want the image to be the width of a page you need to select a suitably large image resolution.

If the standard resolutions that WordPress provides, as standard, are not enough do not worry. Custom image sizes can be added with a little development.

My freelance journey continues

It has been a couple of months since I began my adventure into the world of freelancing as a Fullstack Developer and it has been quite eventful.  

Whilst I have only been working part-time, due to continuing in my full time position as a IT Service Management Architect, I have picked up a few contracts covering Strapi CMS, ReactJS, PHP and HTM/CSS. Each of these gigs have provided good and bad experiences, which I thought it worth sharing....  

## The Good  

Being able to work on a range of projects, with clients on both sides of the Atlantic, has been amazing.  

I have worked with a Fitness Start-up, an Info Sec org, a publishers and an established legal services firm. Each has brought their unique challenges and opportunities to grow.  

I was able to \"play\" with technologies such as Strapi CMS (which I love), ReactJS with Redis-Server and MongoDB, PHP (which I always enjoy!) and use SFTP and SSH which I have only had limited experience of so far.  

I also found a solid, and completely irrefutable, reason to finally bite the bullet and buy a MacBook Pro (M1 chip of course), when I discovered a clients build would only run on one.  

## The Bad  

Picking up someone else's code and trying to unpick it can be a very hit and miss. This is just life, isn't it?  

However, what is not excusable, is a developer creating a half-arsed build with no documentation so that the next poor developer that comes along (yes, this was me...) has to waste time fixing it rather than focusing on delivering value to the client.  

If you happen to be one of these types of developers then move along...  

## The Other One  

There was one particular experience that qualified for a \"WTF...\" award.  

I had been doing some work for a client and committing to GitHub as I went along.  

Then came time to raise a PR to get the code merged in prep for deployment. It is worth pointing out that Unit Testing had not been possible at this stage.  

So, I dutifully raise a PR and let the Product Owner know so they could progress.  

The following morning I started seeing increasingly more urgent messages via Slack. An issue had been encountered in the production environment. \"Interesting\", I thought, but not for me to worry about as all I had done was raise a PR for Staging.  

Then I start getting direct messages asking me what had I done. So, somewhat bemused, I said what I had done and included a screenshot from GitHub.  

After various frantic calls and a screen sharing session the issue became clear. So I deleted my PR request and after 20 minutes calm had been restored.  

The reason for this kerfuffle was that the DevOps team had set up the pipeline to pick up all PR requests, regardless of status or target environment, and apply them to all environments in succession with no validation or sign-off.  

Well, once I had stopped laughing, I wrote a recommendation for the client on CICD 'good' practice and carried on with my task.  

Is the moral of this tale worthy of the Brothers Grimm? Assume nothing and always question what is meant to happen.  

## Summary  

I am a firm believer that we are the sum of our experiences, and that without 'bad' experiences we never really for a solid view of what 'good' looks like.  

So, treat every day as a new adventure and, even when things get stressful, try to find the funny side along the way.  

Oh, and caffeine... lots and lots of caffeine!

Dynamic Metadata in NextJS

## Introduction

If you have ever wondered how you can introduce dynamic metadata into your projects using NextJS, then this article is exactly what you’ve been looking for!

I have recently built this into this very site, which is built using NextJS and Strapi CMS.

The same principle will work with any NextJS project that consumes data from a CMS.

## Getting Started

The first thing I did
approached trying to do this was to ensure that I had the correct setup in my Layout component.

This is the component that wraps all of the content within the pages of this site and uses the Head component of NextJS to allow for the passing of different values for the metadata e.g. title, description and keywords which are the main three used.

![Layout!](https://res.cloudinary.com/xenos-design/image/upload/v1650971173/Post_Content/nextjs_layout_9688014fb9.png 'Layout')

Although it is not essential, it is a good idea to add default props layout values for the metadata that you want to cover. This is shown at the bottom of the screen.

Following that, I updated the [slug] page, which is the page that displays an individual article when you click on the card, specifically where you can see that I find it in the title, description and keywords and pointed the value to 3 unique fields within the post content that is being extracted from the Strapi CMS.

![Layout!](https://res.cloudinary.com/xenos-design/image/upload/v1650971173/Post_Content/nextjs_slug_93d0e48f50.png 'stuff')

This allows me to pass in the values that I want, which are stored within each individual article record in the database.

By doing this you can create unique titles for each of your articles, which allows your audience to save them with meaningful titles without having to type something in.

You can also add in whatever page description and keywords they want, therefore making each individual article more usable to search engines.

Once this was done all I needed to was to create the three fields within the article record structure in Strapi CMS (metaTitle, metaDesc and metaKey). The name of the fields does not really matter, as long as it is meaningful to you and to whoever you may be getting to support implementation going forwards.

## Results

At this stage, you are in a position to test your code works as expected. I recommend using the Chrome dev tools. If you implement this correctly you should see the following:

![Results!](https://res.cloudinary.com/xenos-design/image/upload/v1650971173/Post_Content/nextjs_title_ed9402e5d0.png 'Results')

and

![Results!](https://res.cloudinary.com/xenos-design/image/upload/v1650971173/Post_Content/nextjs_meta_94e4f3704f.png 'Results')

as you will see each of my articles on this site have their own unique titles and metadata.

I hope you found this useful and gives you some inspiration to implement into your own projects. If you get stuck and need some advice for free contact me via email or Twitter.

I did it...

After procrastinating for a while ( ok a long while… ) I finally plucked up the courage to enter the Freelance market and these are my main takeaways so far.  

Firstly it is worth mentioning that the contracts I have picked up so far have all been through upwork.com, I chose it for no other reason than seeing people's positive experiences on Twitter.  

I also, due to still working full-time as a Service Management consultant, only put proposals in for small assignments/projects that I could do in the evenings and weekends.  

**Read the small print** – sounds obvious but most of us tend to skip Terms and Conditions. I mention this as there are charges that are not so obvious when using job listing sites such as upwork.com.  

**Be professional** – whether writing your proposal/cover letter or communicating with your client remember that you are a business. This does not mean that you cannot be convivial but at the same time try to maintain a level of detachment so you can be an objection to the work.  

**Don’t be afraid to say “No..”** – there will come times when, as I found out when you will have to take a stance with a client who is trying to change the scope of the work, on a fixed price contract, without paying extra (scope creep).  

I chose to terminate an agreement with a client after having repeated discussions where they kept trying to shoehorn extra work into what should have been a couple of hours of work at most. I didn’t feel great about doing it but the aggravation was just not worth the £££.  

**If you think you can do it, put a proposal in** – just because you are not a 100% match for the required skills don’t be afraid to take a leap of faith in yourself. Use it as an opportunity to grow your skillset whilst getting paid.  

Expect surprises – unless you get an opportunity to review the code prior to starting a project/assignment expect there to be surprises and added complexity.  

My first assignment was posted as creating a simple PHP template that needed styling to match a pdf design. What arrived on day 1 was a set of complicated and interconnected files that I spent the first 2 hours just going over to understand the data flow.  

Ultimately it was a great learning experience but initially, there was a definite “WTF…” moment.  

So in conclusion I am loving my first few weeks as a freelancer and am looking forward to continuing to learn and grow.

Intro to Regex

So I thought it was about time I did some discovery and learned about the use of RegEx and what it can bring to a project.

To ensure that I got a structured introduction I undertook the course called **_REGULAR EXPRESSIONS FOR BEGINNERS – UNIVERSAL_** on Udemy by Edwin Diaz, which I thoroughly recommend as Edwin is great at boiling the essence of a topic down into something that is easily understood.

The following are the notes that I took while working through the course along with some worked-out examples, some of which were derived from the course and some of which I’ve implemented in other projects.

Hopefully, this will be of some use to you and give you a broad understanding of RegEx.

I recommend that you use an online tool for working through this as it will help bring it to life. Personally, I use https://RegEx101.com/ as it will work with a number of languages, has a dictionary of syntax and will actually explain to you what your expression is doing as you write it out.

## REGEX OPTIONS

In its most basic form RegEx will match against a specified set of characters within a target string:

Example:

_/car/g_ - will search for every instance of the string “car” within a target string of text.

_/car/gi_ - will do the same as the above but will be case insensitive.

_/car/gim_ - will do the same as above but will search across multiple lines of text.

_/car/s_ - will search within a single line using a full stop/period to identify the end of the line.

_/car/imgu_ - will be case insensitive, search across multiple lines, will search globally and look at Unicode characters.

It is important that you get the setting of these options correct in your expressions to ensure that you're matching against exactly what you want.

## META CHARACTERS

_/c.r/i_ - adding a full stop/period anywhere in your string is essentially adding a wildcard. This means that, under this example, the expression will match against anything that starts with the letter c and ends with the letter r. It will not care if there is a letter or a symbol in between them, so be careful if you specifically want to search for an actual full stop/period.

## ESCAPING

_/c\\.r/g_ - so if you want to search specifically for full stop/period, or if your search string includes something like a “/” because you are searching a URL for example, then you will need to escape that particular character. This is done by adding a “\\” in front of the character so as you will see an example the expression of only return matches to “c.r” some language engines will automatically escape characters so RTFD…

## MORE CHARACTERS

escaping can also be used to match against a whole host of different characters or actions within your RegEx expression for example _/C\\n\\t\\R/_ will specifically look for C, then a new line, then a tab and then an R.

But be mindful that the characters work in different ways depending on what language engine you are working with e.g. JavaScript or.net or PHP et cetera so refer to the documentation.

## RANGES

_[car]_ - treats this as a range of letters to search for and will return every instance of each individual letter.

_[a-z]_ - search for every alphabetical letter and return every match. This is case sensitive so example only search for lowercase letters whereas [A-Z] will only search for uppercase. They can both be combined in the same range. [0-9] will also do the same thing, but for the range of numbers zero and nine. The ranges do not have to start or finish as stated above just as easily be [b-f]&nbsp;for example.

_[abdq]werty_ - search for all of the letters within the range as well as anything that matches “werty”.

The range, start and endpoint can be anything you want it to be as long as it is separated by a [-] within square brackets.

## NEGATION

negation is when you tell the expression to exclude something and this is done using the ^ symbol (shift + 6 on Windows keyboard). An example of this would be _[^cat]_ which would tell your expression to ignore any of the letters within the range.

## SHORTHAND

so shorthand is, and don’t shout at me for this, a bit like a macro or short name function as you can type in \\ followed by a specific character or letter and it will produce the equivalent of typing out a longer expression range. I have added a couple of examples below but for full details refer to the documentation language engine;

_\\s_ - looks for any whitespace character.

_\\S_ - looks for any non-whitespace character.

_\\d_ - looks for any digit.

_\\D_ - looks for any non-digit.

_\\w_ - looks for any word character.

and the list goes on. What is good about this is that you combine them within ranges and negation to make your code shorter.

But be mindful as some of them produce slightly odd results such as _\\b_ which looks at the boundary of what it considers to be a word but will include digits e.g. it would match against all of Lettuce468.

These can also be used to create a pattern against which to match if you need to be very specific, for example;

_[\\w\\w\\w\\w\\w\\w@xenos\\-design\\.co\\.uk]_ would match against my email address, or any email address under the same domain where the word in front of the @ symbol is six characters long.

**REPETITION**

Quantifiers – these are meta characters when added tell you expression to select varying amounts of the character that proceeds it, for example;

_a?_ - will match zero or one of a, where a represents what you want to match against.

\*a\*\* - will look for from 0 to more of a. I have also seen as described as the Greedy quantify because it will match as many times as possible.

_a+_ - will look for one or more of a.

_a{x}_ - will look for the specified number of a where x equals a number.

_a{x,}_ - will look for xc or more of a where x is a number.

_a{x,y}_ - will look for the number of a’s between x and y.

_a\*?_ - This will match a from zero or more times, but as few times as possible. This is known as a lazy or reluctant quantifier.

These can be combined to create an expression that will search for a pattern, an example of this would be _\\d {5}-\\d {4}_ would match any set of values that look like this 12345-6789 an obvious use case for this could be if you’re searching for telephone numbers in a dataset where there is a specified format. The same could obviously be done for text strings as well or indeed combinations of both.

## GROUPING

must be done outside of the character/range set otherwise parentheses will just be escaped, however, characters set/range can be put inside grouping so _([0-9])_ will work but _[()]_ will not.

An example of how this would work is save(d)? which makes ‘d’ optional and therefore would match against both ‘save’ and ‘saved’.

## ALTERNATION

the use of the pipe symbol ‘|’ (shift + \\ on a windows keyboard) effectively works as an OR statement. However, some nuances of it are;

- whatever is written on the left takes precedence.
- global needs to be switched on for it to work.
- it can be used as many times as needed.

A more effective way to use this is to include grouping i.e. (Bat|Super)man will return against both ‘Superman’ and ‘Batman’.

Example to work in – _(\\w+|file\\d {3}\_export\\. file201_export._ remember that the right of the pipe sign takes precedence and will be classed as an eager function as is looking for all words so would return against an underscore but not a hyphen or a full stop.

Alternation can also be used in a nested group i.e. (soup (bowl|spoon)) will return against ‘soup bowl’ and ‘soup spoon’, be mindful of the spacing as this is quite key to a working.

## ANCHORS

_^s_ - will look for the first ‘s’ in a string e.g. it has to be at the beginning of the string.

_s$_ - as above but at the end of the string.

_^[a-z]_ - will look for any texturing that starts with a lowercase letter.

## WORD BOUNDARIES

_\\b_ - this will match up to the boundary of each word or word character.

_\\B_ -&nbsp;this will match twin non-word boundary, which is somewhat confusing, as it will not match on any string of less than three-word characters but on a string of more than three characters it will match as follows ‘test’ as it treats the beginning and the end characters as the boundaries themselves rather than the spaces around them as the boundary.

## BACK REFERENCES

is a way of referring to the string of text or digits within a grouping.

Typically most engines let you save up to 9 back-references, shown as follows day(light) \\1&nbsp;with the ‘\\1’ being the reference to the “variable”. This would only match if the texturing it is searching is written as follows&nbsp;daylight light.

## NON-CAPTURING GROUP

In this example we see yet another way a ‘?’ can be used to do something different within your expression.

(food) and (?:travel) and \\1 will match against “food and travel and food” because is repeating the first variable, whereas&nbsp;(?:food) and (travel) and \\2 will match against “food and travel and travel” because it is repeating the second variable which is travel.

Using the “?:” switches off that variable.

## POSITIVE AND NEGATIVE ASSERTIONS

_[A-Za-z]+(?=,)_ - this will search for any upper or lowercase letter that is followed by a comma.

_[A-Za-z]+(?!,)_ - this literally does the reverse (if != ,) e.g. does not equal comma and so will match every string of upper and lowercase letters that do not end with a comma.

## POSITIVE AND NEGATIVE LOOKAHEAD

_[A-Za-z]+(?&lt;=,)_ - very similar to the previous section except that by adding the “&lt;” you’re telling the expression to look at what comes before e.g. under this example it would look for every texturing that is preceded by a comma.

_[A-Za-z]+(?-_ - again, literally the reverse, where you are looking for everything that is not preceded by comma.

## MULTILANGUAGE SYMBOL SUPPORT

RegEx includes support for Unicode, so no matter what language you are searching against you will be able to use Unicode to create a match in your expression.

You can find the full Unicode listings at [https://home.unicode.org/](https://home.unicode.org/).

If it is to be included it in your ReEex expression as follows \\u2022 using the “\\” to escape the u so that it is turned into the Unicode character.

## EXAMPLES

Password Validation –&nbsp; the following is an example of an expression that could be used to validate against contents of the users chosen password to ensure that it matches against the policy in place on our project.

Expression: _/^(?=.*[A-Z])(?=.*[a-z])(?=.*\\d)(?=.*[!$£#])\\S{5,20}$/gm_

_(?=.\_[A-Z])\\_ – this validates against the password having at least one upper case character.

_(?=.\_[a-z])\\_ – this validates against the password having at least one lowercase character.

_(?=.\_\\d)\\_ – this validates against the password having at least one number.

_(?=.\_[!$£#])\\_ – this validates against password having at least one of the identified symbols within the square brackets.

_\\S{5,20}_ – this validates him the password being a minimum of 5 and a maximum of 20 characters.

Pretty URLs – the following example is something that I have deployed myself and is commonly seen on websites to make the URL in the browser more human readable. This example is specific to PHP running on an Apache server.

**_Step One_** - ensure your Apache server has the rewrite engine switched on.

**_Step Two_** - create a new file called .htaccess in your website’s root directory.

**_Step Three_** - opening with your code editor and add the following:

**_Step Four_** - RewriteEngine on, this switches the rewrite engine on

RewriteRule _^post/(\\d+)$ post.php?p_id=$1 [NC,L]_ -&nbsp;this tells the server to replace anything with a post.php?p_id=$1, where $1 equals the number identified in the group, and replaces it with post/post number e.g.&nbsp;domainname.com/posts/178, with the&nbsp;NC denoting that it is case insensitive and the&nbsp;L denoting but this is the last rule that should be processed.

## SUMMARY

Hopefully, this brief introduction to RegEx has sparked your interest to go and explore more for yourself and understand how this very powerful tool could be used in your projects.

I’ve enjoyed learning about something that seemed to be quite daunting before but now seems quite simple once you understand the syntax.

I have added some references below to language-specific documentation and a couple of tools that I found useful during this learning process.

## REFERENCES AND RESOURCES

[https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/)

[https://www.php.net](https://www.php.net)

[https://RegEx101.com/](https://RegEx101.com/)

My first #100DaysOfCode!

Although I was never particularly academic at school, which is a bit of an understatement considering I bombed out of secondary school with but a handful of GCSEs, I have always considered myself a lifelong learner if for no other reason than having to constantly adapt and learn new ways of doing things as a result of my disability.

I started to learn to code in the summer of 2020 and by the end of the year had absolutely fallen in love with coding and being able to build cool stuff.

I wanted to give myself a challenge in the New Year, as let’s be fair 2020 was a pretty rubbish year for most people, and having read about the #100DaysOfCode challenge on Twitter decided that this would be a good opportunity to apply some focus to my learning.

So on January 1, 2021, I formally declared my intention to start my _#100DaysOfCode_ journey and this is the story of how I got on, some of the areas I covered and most importantly the lessons I learned along the way.

If you’re reading this I hope it is of some use to you in your journey.

## WHAT DID I LEARN?

**_Read the documentation_** – it cannot be overstated, and is frequently reiterated in Twitter discussions, then reading the documentation for a language/framework/tool et cetera should be your first port of call when trying to understand what you need to do with your project. That being said the level of documentation can vary quite a lot and you will end up going down rabbit holes and tying yourself in knots when the level of documentation is substandard. Whenever I got to that stage my immediate go-to is Google, as it is very likely that what you’re trying to do has been done before and someone will come across the same problem as you and there will undoubtedly be a whole raft of information, and if you’re lucky, a fix or code snippet that you can use.

**_Pause, rewind and absorb_**… - If like me, you like to learn through tutorials and following others building projects online then you may well find yourself getting lost mostly because the speed at which experienced developers build things during their tutorials/courses is rarely at a speed at which you as the viewer can follow along with and build along with, in parallel. What worked for me was watching the tutor and then either pausing the video so that I could bring my version of the project up to the same level or pausing the video before the tutor started to build something, trying to build it myself and then watching the rest of the video and adjusting my code as needed (you need to be reasonably comfortable with the language or framework to start with to do this). One key point around this is that if you are doing online tutorials then make sure you allow enough time to do the tutorial plus whatever time you think you will need for revisions/pauses and rewinds in your learning plan. I found that I needed to add at least 50% additional time to my plan, but my typing speed is absolutely abysmal.

**_TAKING A BREAK IS NOT A CRIME!_** - Whilst the main premise of the #100DaysOfCode challenge is to get you into a regular behavioural pattern of writing code, so that it becomes second nature, what everyone undertaking the challenge should realise is that it is very important to sometimes just say “I need a break” and walk away for a day or two if needed. If you can maintain 100 days of doing anything without needing a break then fair play to you. I couldn’t and, excluding having to stop for a few weeks due to getting Covid-19, would occasionally take a day off just to recharge the batteries and not feel like I was becoming a slave to the challenge. However what I did notice is that in the last 30-ish days of the challenge I started to become more enthused and, even on a day I told myself I was going to have a break, found myself at the keyboard fiddling about with one project or another.

## RESOURCES I USED FREQUENTLY

Documentation – I have said previously but it absolutely warrants reiteration. RTFD…

[https://www.google.com/](https://www.google.com/) – although it often comes across as a bit of a joke it is an absolute truism that any developer, no matter how senior, will often be turning to Google when they either get stumped all are looking for a new shiny toy to put inside their project. Throughout my journey, I have created a library of bookmarks in my browser, but it’s always worth googling to find what else is out there as the pace of change is unbelievable.

[https://stackoverflow.com/](https://stackoverflow.com/) – I will be honest and say that I have a bit of a love-hate relationship with this website. As a source of information or fixes, it is great, if there is an existing thread on the subject. However, my personal experience, of putting new questions to the community has not inspired me to do it again.

[https://developer.mozilla.org/](https://developer.mozilla.org/) – This is literally the standard for HTML, CSS and JavaScript and gives great examples of how to use the baseline code.

[https://www.php.net](https://www.php.net) – as previous but for PHP, this is a great resource when trying to find out what the language is capable of doing. https://www.reactjs.org – the font of knowledge for the baseline react framework. As with the previous two entries, this is a great source of knowledge if you want to get into react.

[https://www.getbootstrap.com](https://www.getbootstrap.com) – the bootstrap framework is absolutely essential when you are starting out and want to quickly prototype your designs without going into all the detail of CSS yourself. Personally, I love it, and the plethora of templates and frameworks that have been built up around it.

[https://www.cdnjs.com](https://www.cdnjs.com) – if you want to include something in your project but don’t want to install the package itself and this site is a great source for the code snippets that you will need to add in your header or footer for either the CSS or JavaScript inclusions.

[https://www.imagecompressor.com](https://www.imagecompressor.com) – if you are just building little projects to test your code that will only be deployed locally then image compression is probably not going to be an issue. However, if you intend to put your project anywhere near the Internet then compressing your images down to a reasonable size is an absolute must. I tried a few different sites over the last few months and found that this one responds the quickest and gives me what I need without going through the nuisance of creating accounts choosing numerous options et cetera. It also does bulk-load which is great.

[https://www.github.com](https://www.github.com) / Github desktop / GitHub pages – if you’re going to build and deploy code in any meaningful way then you will absolutely need some sort of versioning tool. I opted for GitHub and, although I did learn the basic command lines, choose to use GitHub desktop most of the time for convenience. I also like having the ability to put up Github pages to showcase a project without having to deploy it to our hosting provider, and most of my portfolio runs straight out of Github pages.

Vscode and [https://marketplace.visualstudio.com/](https://marketplace.visualstudio.com/) – there are a lot of code editors out there and the choice of which one you use is usually based on personal preference. After having looked at a few different ones I decided to use VS Code as I like the interface and the extension management capabilities. Currently I’m running with a number of extensions active all of which make my life coding a lot easier. These are:

- **_Auto rename tag_** – which automatically changes the opposite end of a tag when you are editing your code
- **_Brackets pair coloriser_** – I found this to be fantastic so you understand where you are within different blocks of code
- **_code spell checker_** – just because…
- **_Code highlight_** – again let’s you see where you are within your various blocks of code
- **_ESLint_** – great integration if you’re using ESLint in your code
- **_Live server_** – so you can see how your code is working in real-time
- **_IntelliSense_** or code snippets for any language you’re using as auto complete saves a lot of time
- **_Prettier_** – for formatting your code into more readable structures. I found this only works, or it could only get it to work, with HTML and JavaScript
- **_Snyk_** vulnerability scanner as this will run scans against all of your public repos but can also tell you if your code is going to work or not is a will highlight code blocks that are not doing anything or will not work
- **_VScode–icon_** – gives you pretty little icons for your file types, which can be quite useful

other than extensions it is or is worth checking out the different colour themes that are available and choosing one that suits your personal preference on colourisation of syntax.

**Multiple screens** – whilst you can absolutely free amazing code on a single screen I’d thoroughly recommend investing in a least one other screen. My personal setup is a 27 inch screen in portrait mode, a 34 inch Ultra wide and 24 inch that I can pivot to landscape or portrait depending on the need. The ability to have multiple applications open and visible at the same time will help you improve your code experience no end.

[https://www.a11yproject.com](https://www.a11yproject.com) - this is a great source of information and checklists that will help you make your web project accessible to everyone.

## WHAT WOULD I DO DIFFERENTLY?

I have reflected on this quite a lot in the last couple of weeks and I think the only thing I would definitely do differently, and in fact, will do differently on my next #100DaysOfCode, is to engage more with the community and put more effort into engaging by social media channels.

From what I’ve experienced so far the dev community is excellent (if somewhat argumentative, just don’t ask which languages are the best!) and is very supportive of us newbies.

## TUTORIALS I ENJOYED

I spent a lot of time during the hundred days learning from experienced developers through articles, YouTube videos, and tutorials. The bulk of my learning came from tutorials on Udemy.com and I thought I would share the list of my top five favorite courses that I completed during my hundred days.

Each of the below helps to enhance my understanding in terms of deepening my knowledge of specific languages as well as giving inspiration as to the different ways that projects can be built.

- 50 projects in 50 days, HTML, CSS &amp; JavaScript – Brad Traversy

- JavaScript Web projects: 20 projects to build your portfolio – Andrei Neagoie

- React front to back - Brad Traversy

- Django with React an e-commerce website - Brad Traversy

- PHP for beginners – become a PHP master – CMS project – Edwin Diaz

now there are obviously many other great content creators out there so this is just based on my personal experience from what I’ve covered so far.

Prior to my hundred days, I had spent a lot of time in courses and tutorials from LinkedIn Learning which has some awesome courses done by some very passionate instructors and I learned a lot of the basics of HTML, CSS, and JavaScript from these tutors.

We all learn differently so you need to be mindful of the best way that works for you when setting out on your journey.

## WHAT NEXT?

Having finished my first go-round of #100DaysOfCode I’m taking a short break body to get this blog going, but also to think about what I want to do next. At the moment it is a tossup between delving deeper into react or learning Python.

Either way, I know it will be a good laugh I will thoroughly enjoy (most of) it!

Late to the party...?

Since starting to learn to code and spending a lot of time interacting with my peers on Twitter it is fair to say that I have had many moments of contemplation as to whether or not I am too old to change careers and get into coding as a full-time profession.  

However, from my perspective, I think the answer has to be that as long as you are open-minded, cognisant of the fact that to start with you will be heavily reliant on others for knowledge, and have a natural interest in what you are doing and is never too late to start learning anything.  

I started my journey by watching courses on LinkedIn learning, which was provided by my employer, then moving on to sources of knowledge such as YouTube videos and Udemy courses/boot camps all of which I found absolutely fantastic as both sources of knowledge and as inspiration to go forward to build things on my own.  

One of the great things about online courses/tutorials is the references to tools and frameworks, that you have not yet tried or may not have known about, which all helps to enhance your wider appreciation of quite how diverse the tools available to you are.  

I personally found all of these references to different things helped me to map out the areas that I wanted to learn and fine-tune my personal learning experience e.g. you start with HTML then you must learn CSS then to do anything meaningful you must learn JavaScript which then leads you onto frameworks such as React/Angular/Vue can then lead to frameworks such as Django/Gatsby and the list goes on.  

Even having spent the best part of the year learning to code and having built all sorts of projects, some of which even got successfully deployed, it is difficult to get away from the “impostor syndrome” mentality and that I have come into this way too late.  

However, I take solace in the fact that during my career I have changed my profession three or four times each of which meant having a very steep learning curve in order to survive rather than sink.  

Therefore I am confident that I will be able to apply the same to coding and make a success of it, or at least have a really entertaining hobby, build some cool stuff and meet some amazing people along the way. I think unless you’re an egomaniac it is always difficult to believe in yourself 100% but what we always need to remember is that we have come this far so why turn back now…

This is me...

Hi..  

I thought it best that I introduce myself so you can have some idea of who I am, although my ramblings may give that away, and why I decided to start writing and publishing articles about my journey.  

I have been working in the IT industry since the late 90s but, other than a brief stint building a very basic website for engineers to access across GPRS, I am new to writing code for websites and applications.  

I started learning coding mid 2020 partly as a way of relieving boredom and partly to have something to focus on as a way of fighting depression/anxiety.  

I don’t have a particularly technical background but do have a broad understanding of application architecture from all the various projects I’ve worked on.  

I initially dipped my toe into Python but quickly switched to front-end development starting with the basics of HTML, CSS and then delving deeper into JavaScript/REACT.  

As I started to get a reasonable grip of the basics, or so I thought, then I started building more complex solutions using the MERN stack and the Django framework.  

I’ve mostly built little bespoke projects for my own amusement or to try out something that I have learnt, as well as having built e-commerce and CMS, I am talking to you from a Next.js / Strapi CMS / Postgresql stack (migrated from a bespoke LAMP stack) site that I built, applications following online tutorials.  

As New Year’s Eve came around in 2020 I decided that I wanted to give myself a challenge and, having heard about the #100DaysOfCode challenge from Twitter, decided to have a crack at that.
Having recently completed my first hundred days, albeit with a pause of a few weeks due to getting Covid-19, and having thoroughly enjoyed the experience I thought I would start to document my journey both reflecting on the last hundred days or so and going forwards as I continue my learning and efforts to move into a development role full-time.  

So this is me…  

Hopefully will find my posts of some use to you in your journey…