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: ""
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.


Latest tales from the deep...