IICTP Bloghttps://blogs.iictp.org/Technical practice explained, and how IICTP compares with project management credentials. Each item is the full content of one page of the International Insignia of Certified Technical Practitioners website.en© IICTP. All rights reserved. Use is governed by https://iictp.org/termsIICTP site build (scripts/feeds.mjs)https://www.rssboard.org/rss-specification1440Mon, 26 Oct 2026 09:36:55 GMThttps://iictp.org/favicon.svgIICTP Bloghttps://blogs.iictp.org/IICTP Blog: Technical Practice, Architecture & Leadership | IICTPhttps://blogs.iictp.org/https://blogs.iictp.org/Mon, 26 Oct 2026 09:36:55 GMTBlogIICTPPlain-language guides on the knowledge behind the IICTP credentials, and on how they compare with project management credentials. Every claim names its source.

IICTP blogs

Technical practice, explained.

Plain-language guides on the knowledge behind the IICTP credentials, and on how they compare with project management credentials. Every claim names its source.

/
  • Popular:

64 posts, newest first

IICTP vs PMI

IICTP and PMI: two credentials for two different jobs

COMPARISON · 7 MIN READ
Featured · IICTP and PMI

People often ask how IICTP compares with PMI. The honest answer is that they certify different things. PMI certifies project management. IICTP certifies technical practice. Whether one is better for you depends on the decisions y…

21 October 20267 min readRead the post
Local LLMsLLMP

How to run an LLM on your own server: Ollama, llama.cpp and vLLM compared

GUIDE · 7 MIN READ

Running a language model on hardware you control means prompts and documents never leave your building, the cost is the hardware…

26 October 2026
Local LLMsLLMP

Small language models explained: when smaller beats bigger

GUIDE · 5 MIN READ

A small language model (SLM) is a language model small enough to run on modest hardware, such as one workstation, a phone or an e…

26 October 2026
TPBOK

What is the TPBOK? The Technical Practitioner Body of Knowledge, explained

GUIDE · 4 MIN READ

The TPBOK, the Technical Practitioner Body of Knowledge, is the written standard behind every IICTP exam. It describes what a tec…

26 October 2026
Certification & career

The technical practitioner career path: from Associate to Portfolio level

GUIDE · 5 MIN READ

A credential ladder is only useful if each step matches a real change in the work. IICTP’s four core credentials are built around…

26 October 2026
Certification & career

How to prepare for a scenario-based certification exam

GUIDE · 6 MIN READ

A scenario-based exam does not ask you to recall a definition. It describes a situation and asks what you would do. That changes…

26 October 2026
Certification & career

How employers verify a certification, and why a public registry matters

GUIDE · 4 MIN READ

A certificate is a claim. Anyone can type a credential onto a CV, and a PDF is easy to alter. Verification is the step that turns…

26 October 2026
Certification & career

Digital badges and verifiable credentials, explained

GUIDE · 5 MIN READ

A digital badge is a credential in a form that travels: it can be shared on a profile, checked by a machine and revoked by the is…

26 October 2026
Certification & career

Technical practitioner interview questions, and what good answers show

GUIDE · 6 MIN READ

Good interview questions for a technical lead or practitioner ask about decisions, not trivia. Here are twelve, each with what a…

26 October 2026
AIAIP

AI agents explained: how agentic AI works in production

GUIDE · 6 MIN READ

An AI agent is a program that uses a language model to decide what to do next, takes actions through tools, looks at the result a…

26 October 2026
AIAIP

RAG explained: retrieval-augmented generation, step by step

GUIDE · 6 MIN READ

Retrieval-augmented generation (RAG) gives a language model the documents it needs at the moment it answers, instead of relying o…

26 October 2026
AIAIP

RAG vs fine-tuning: how to choose

GUIDE · 5 MIN READ

Both RAG and fine-tuning adapt a model to your needs, but they change different things. RAG changes what the model can see at ans…

26 October 2026
AIAIP

Prompt engineering in 2026: beyond prompts, context engineering

GUIDE · 5 MIN READ

Writing a good prompt matters, but in a real system the prompt is only part of what the model sees. Context engineering is the wi…

26 October 2026
AIAIP

How to evaluate an LLM application: evals, hallucination tests and guardrails

GUIDE · 6 MIN READ

You cannot improve what you cannot measure, and an AI feature that “seems fine” in a demo can fail quietly in production. An eval…

26 October 2026
AIAIP

LLMOps: running AI in production, covering cost, monitoring and versioning

GUIDE · 6 MIN READ

LLMOps is the operational side of language-model applications: keeping them reliable, affordable and improvable once real users d…

26 October 2026
AIAIP

Responsible AI in practice: bias, privacy and governance checklists

GUIDE · 5 MIN READ

Responsible AI is less about principles on a poster and more about decisions made at specific points in a project. Here is a shor…

26 October 2026
AIAIP

AI copilots at work: where they help and where they fail

GUIDE · 4 MIN READ

AI copilots draft, summarise, suggest and search. They are strongest when a person is still doing the thinking and can check the…

26 October 2026
AIAIP

LangChain and LangGraph: what practitioners need to know

GUIDE · 5 MIN READ

LangChain and LangGraph are open-source libraries for building applications around language models. They are tools, not requireme…

26 October 2026
AIAIP

Multimodal AI explained: text, image and audio in one system

GUIDE · 4 MIN READ

A multimodal model takes more than one kind of input, such as text with images or audio, and can sometimes produce more than one…

26 October 2026
Local LLMsLLMP

Private AI for regulated industries: on-premise LLMs for law, health and finance

GUIDE · 6 MIN READ

Law firms, clinics and financial teams handle material they may not be free to send to an outside service. Running a model on inf…

26 October 2026
Local LLMsLLMP

Local LLM vs cloud AI: cost, privacy and latency compared

GUIDE · 5 MIN READ

The honest answer to “local or cloud?” is a comparison you do with your own numbers. Here is how to set it up, so you do not rely…

26 October 2026
Local LLMsLLMP

Quantization explained: GGUF, AWQ and running big models on small hardware

GUIDE · 6 MIN READ

Quantization stores a model’s weights using fewer bits, so the model takes less memory and often runs faster. The trade-off is so…

26 October 2026
Local LLMsLLMP

Choosing hardware for local AI: GPUs, NPUs and Apple Silicon

GUIDE · 6 MIN READ

For local models, the main constraint is memory, followed by memory speed, and only then raw compute. Match the hardware to the m…

26 October 2026
Local LLMsLLMP

RAG on a local LLM: private document search that never leaves your building

GUIDE · 5 MIN READ

Combine retrieval with a locally hosted model and you can answer questions from sensitive documents without sending them anywhere…

26 October 2026
Local LLMsLLMP

Edge AI inference: small models on devices, offline and in real time

GUIDE · 5 MIN READ

Edge inference runs a model on or near the device that produces the data: a phone, a gateway, a vehicle, a factory machine. It cu…

26 October 2026

Prefer a feed reader? Subscribe to the blog RSS feed.

Where do you stand?

Find the credential that fits the work you do.

]]>Architecture and Systems Design: Decisions That Are Expensive to Undo | IICTPhttps://blogs.iictp.org/architecture-decisions-expensive-to-undohttps://blogs.iictp.org/architecture-decisions-expensive-to-undoWed, 21 Oct 2026 09:00:00 GMTBlogIICTPMost engineering choices can be reversed in an afternoon. A few cannot: how a system is divided, where its data lives, and which parts must agree with each other in real time. This is the first of five TPBOK domains, Architecture & Systems Design, and it is about making those choices well.

Blog / TPBOK domains

Domain 121 October 20266 min read

Architecture decisions are the ones that are expensive to undo

Most engineering choices can be reversed in an afternoon. A few cannot: how a system is divided, where its data lives, and which parts must agree with each other in real time. This is the first of five TPBOK domains, Architecture & Systems Design, and it is about making those choices well.

In this post
  1. Hide the decisions most likely to change
  2. Separate essential complexity from accidental complexity
  3. Your system will look like your organisation
  4. Distributed systems force trade-offs you cannot avoid
  5. A short checklist before you split a system
  6. How this appears in IICTP exams
  7. Sources and further reading

Hide the decisions most likely to change

In 1972 David Parnas argued that the way to divide a system into modules is not by the steps of a process but by the design decisions each module hides. If a decision is likely to change, such as a data format or a vendor, only one module should know about it. When that decision changes, one module changes, not forty.

This is still the best test of a boundary. Ask of any proposed split: what is hidden behind it, and how likely is that thing to change?

Separate essential complexity from accidental complexity

Fred Brooks, in “No Silver Bullet”, separated the difficulty that comes from the problem itself (essential) from the difficulty we add through our tools and choices (accidental). Better tools can remove accidental complexity. Nothing removes the essential kind, so a practitioner’s job is to avoid adding to it. A design that needs three services, two queues and a cache to do what one function could do has added accidental complexity.

Your system will look like your organisation

Melvin Conway observed in 1968 that organisations design systems that mirror their own communication structure. If three teams must agree on every change, you will end up with three tightly bound components. Practitioners use this deliberately: change the team boundaries first if you want different system boundaries.

Distributed systems force trade-offs you cannot avoid

When a network can fail, a system cannot be both fully consistent and fully available. Eric Brewer put this forward as a conjecture, and Seth Gilbert and Nancy Lynch proved a formal version in 2002. The practical lesson is not to memorise the theorem. It is to decide, per feature, which you would rather give up under failure, and to say so in writing.

A short checklist before you split a system

  1. What decision does this boundary hide, and how likely is it to change?
  2. Which team owns each side, and can they release independently?
  3. What happens to each side when the other is down?
  4. What will it cost to run, monitor and debug as two things instead of one?
  5. How would we undo this in a year if we were wrong?

How this appears in IICTP exams

Architecture & Systems Design carries 30% of the CTP exam and 24% of the ATP exam. The ATP asks whether you can read a baseline architecture and see how its parts depend on each other. The CTP gives scenarios, such as whether and how to split a system under load, and asks for the best decision, not a perfect one. See the exam facts for every credential’s share.

Record your decisions as you make them. A short written note, with the options you rejected, is worth more than a diagram nobody updates.

Sources and further reading

  1. Brooks, F. P. (1987). “No Silver Bullet: Essence and Accidents of Software Engineering.” IEEE Computer 20(4).
  2. Conway, M. E. (1968). “How Do Committees Invent?” Datamation 14(4).
  3. Evans, E. (2003). Domain-Driven Design. Addison-Wesley.
  4. Gilbert, S. and Lynch, N. (2002). “Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services.” ACM SIGACT News 33(2).
  5. Nygard, M. (2011). “Documenting Architecture Decisions.” Cognitect blog.
  6. Parnas, D. L. (1972). “On the Criteria To Be Used in Decomposing Systems into Modules.” Communications of the ACM 15(12).

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>Engineering Governance and Agile Delivery: Speed and Stability Together | IICTPhttps://blogs.iictp.org/speed-and-stability-engineering-governancehttps://blogs.iictp.org/speed-and-stability-engineering-governanceWed, 21 Oct 2026 09:00:00 GMTBlogIICTPMany teams believe they must choose between shipping fast and shipping safely. The research behind the second TPBOK domain, Engineering Governance & Agile Delivery, points the other way: the practices that make delivery fast, mainly small changes and automated checks, are the same ones that make it

Blog / TPBOK domains

Domain 221 October 20266 min read

Speed and stability are not a trade-off: the case for small batches

Many teams believe they must choose between shipping fast and shipping safely. The research behind the second TPBOK domain, Engineering Governance & Agile Delivery, points the other way: the practices that make delivery fast, mainly small changes and automated checks, are the same ones that make it stable.

In this post
  1. The four measures that matter
  2. Why small batches work
  3. Waterfall was never the plan
  4. Define “done” so a reviewer can check it
  5. Anti-patterns
  6. What to do on Monday
  7. Sources and further reading

The four measures that matter

The DORA research programme, summarised by Nicole Forsgren, Jez Humble and Gene Kim in Accelerate (2018), found that delivery performance can be described by four measures: how often you deploy, how long a change takes from commit to production (lead time), how often a change fails, and how quickly you recover when one does. The first two measure speed. The last two measure stability. In their data, the same teams tended to do well on both.

  • Deployment frequency. How often you release to production.
  • Lead time for changes. From code committed to code running.
  • Change failure rate. The share of changes that cause a failure needing a fix.
  • Time to restore service. How long recovery takes.

Why small batches work

A large change is hard to review, hard to test and hard to undo. When it fails, you do not know which part failed. A small change fails in a way you can see and fix quickly. There is also arithmetic behind this. Little’s Law, proved by John Little in 1961, says that the average time work spends in a system equals the amount of work in progress divided by the rate at which it finishes.

Waterfall was never the plan

Winston Royce’s 1970 paper is often cited as the origin of the strict sequential “waterfall”. Read it and you find the opposite: he warned that a single sequential pass is risky and recommended building a pilot first so the hard problems appear early. The lesson is to find risk early, not to follow phases in order.

Define “done” so a reviewer can check it

A good quality bar is binary. Tests pass, the change is reviewed, security checks have run, the feature can be switched off. If “done” depends on someone’s feeling, it will drift under pressure. Automating the bar, in a pipeline that blocks release when a check fails, replaces a meeting with a rule.

Anti-patterns

  • Water-Scrum-Fall. Sprints in the middle, but requirements are fixed up front and release is a separate big event at the end.
  • Velocity inflation. Points are used to compare teams, so they inflate, and the number stops meaning anything.
  • Long-lived branches. Integration is deferred until it hurts.

What to do on Monday

  1. Measure your lead time for the last 20 changes. Do not guess.
  2. Limit work in progress so that finishing matters more than starting.
  3. Pick one manual gate and automate it.

Engineering Governance & Agile Delivery is 28% of the ATP exam and 24% of the CTP exam. The specialist Agile Delivery Practitioner (ADP) goes deepest. See exam facts.

Sources and further reading

  1. Forsgren, N., Humble, J. and Kim, G. (2018). Accelerate. IT Revolution Press.
  2. Humble, J. and Farley, D. (2010). Continuous Delivery. Addison-Wesley.
  3. Little, J. D. C. (1961). “A Proof for the Queuing Formula: L = λW.” Operations Research 9(3).
  4. Royce, W. W. (1970). “Managing the Development of Large Software Systems.” Proceedings of IEEE WESCON.
  5. Takeuchi, H. and Nonaka, I. (1986). “The New New Product Development Game.” Harvard Business Review 64(1).

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>Applied AI and Emerging Tech Integration: A Practitioner’s View | IICTPhttps://blogs.iictp.org/applied-ai-verify-what-the-machine-produceshttps://blogs.iictp.org/applied-ai-verify-what-the-machine-producesWed, 21 Oct 2026 09:00:00 GMTBlogIICTPThe third TPBOK domain, Applied AI & Emerging Tech Integration, is not about knowing the newest model. It is about a durable skill: deciding where a probabilistic tool belongs in a system that must behave predictably, and how to check its output before anyone relies on it.

Blog / TPBOK domains

Domain 321 October 20266 min read

Applied AI: use it where it helps, and verify what it produces

The third TPBOK domain, Applied AI & Emerging Tech Integration, is not about knowing the newest model. It is about a durable skill: deciding where a probabilistic tool belongs in a system that must behave predictably, and how to check its output before anyone relies on it.

In this post
  1. The core problem: output is probable, not guaranteed
  2. Where to start: low-risk, reversible, checkable
  3. Checks that belong before anything merges
  4. Designing systems that include a model
  5. Follow the published frameworks
  6. Sources and further reading

The core problem: output is probable, not guaranteed

A traditional function returns the same answer for the same input. A language model returns a likely answer. That is useful, and it means the cost of verification moves to the user. Brooks’s point that the hard part of software is its essential complexity applies here too: AI can draft code quickly, but someone still has to decide whether the code is right.

Where to start: low-risk, reversible, checkable

A practitioner’s first question is not “can AI do this?” but “what happens if it is wrong, and how will we know?” Good first uses have three properties: a mistake is cheap, a mistake is visible, and a person or a test can check the result.

  • Drafting tests, documentation or boilerplate that a reviewer will read.
  • Searching and summarising internal material, with sources shown.
  • Suggesting changes in a pull request that still needs human approval.

Checks that belong before anything merges

  • Automated tests that fail when behaviour changes, so generated code is held to the same bar as human code.
  • Human review of anything touching security, money or personal data.
  • Secrets and personal data kept out of prompts and out of generated code.
  • A record of which output came from a tool, so problems can be traced.

Designing systems that include a model

When a product calls a model, treat it as an unreliable component. Retrieval-augmented generation, introduced by Patrick Lewis and colleagues in 2020, grounds answers in documents you control. It helps, but it adds its own parts that can fail: how documents are split, how they are ranked, and whether the answer is faithful to the source. Test each part. Measure answers against a fixed set of questions so you can see whether a change made things better or worse.

  • Cost and rate limits. Put limits and fallbacks around every call.
  • Data privacy. Decide what may leave your boundary before you integrate.
  • Observability. Log inputs, outputs and decisions so you can investigate an odd answer.

Follow the published frameworks

You do not have to invent your own risk language. The NIST AI Risk Management Framework and the OWASP list of risks for applications built on language models are public, maintained, and a good starting vocabulary. For evidence on how AI changes delivery performance, read the latest DORA reports directly rather than relying on summaries.

Applied AI & Emerging Tech Integration is 16% of the ATP exam and 18% of the CTP exam, and the largest share (36%) of the specialist AI Practitioner (AIP) exam. See exam facts.

Sources and further reading

  1. Brooks, F. P. (1987). “No Silver Bullet: Essence and Accidents of Software Engineering.” IEEE Computer 20(4).
  2. Lewis, P. et al. (2020). “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks.” Advances in Neural Information Processing Systems 33.
  3. National Institute of Standards and Technology (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1.
  4. OWASP Foundation. OWASP Top 10 for Large Language Model Applications.
  5. DORA (Google Cloud). Accelerate State of DevOps reports, published annually.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>Infrastructure and Security: Designing for Failure | IICTPhttps://blogs.iictp.org/design-for-the-failure-you-will-havehttps://blogs.iictp.org/design-for-the-failure-you-will-haveWed, 21 Oct 2026 09:00:00 GMTBlogIICTPSystems fail, and credentials leak, and people make mistakes. The fourth TPBOK domain, Infrastructure & Security, starts from that fact. The goal is not a system that never breaks, but one where a break is small, visible and quick to recover from.

Blog / TPBOK domains

Domain 421 October 20266 min read

Infrastructure and security: design for the failure you will have

Systems fail, and credentials leak, and people make mistakes. The fourth TPBOK domain, Infrastructure & Security, starts from that fact. The goal is not a system that never breaks, but one where a break is small, visible and quick to recover from.

In this post
  1. Old principles, still the right ones
  2. Limit the blast radius
  3. Measure reliability and spend it deliberately
  4. You cannot fix what you cannot see
  5. Practise recovery before you need it
  6. After the incident
  7. Sources and further reading

Old principles, still the right ones

In 1975 Jerome Saltzer and Michael Schroeder set out design principles for protecting information. Most of them still read as practical advice today.

  • Least privilege. Give every person and program only the access it needs.
  • Fail-safe defaults. Access is denied unless explicitly granted.
  • Complete mediation. Check every access, every time.
  • Economy of mechanism. Simpler designs are easier to verify.
  • Open design. Security should not depend on the design being secret.
  • Separation of privilege. Sensitive actions need more than one condition.

Zero trust, now described in NIST SP 800-207, is these ideas applied to modern networks: do not trust a request because of where it comes from, verify it.

Limit the blast radius

Assume something will go wrong and decide in advance how far the damage can spread. Separate environments, narrow credentials that expire, and isolated components mean one failure stays one failure. Infrastructure defined as code and kept in version control makes environments reproducible, so you can rebuild instead of repair.

Measure reliability and spend it deliberately

The Site Reliability Engineering practice from Google describes service level objectives, a target for how reliable a service should be, and the error budget, the amount of unreliability you can afford before you stop shipping new features. It turns an argument about risk into a number both product and engineering can see.

You cannot fix what you cannot see

Observability rests on three kinds of signal: metrics that show trends, logs that record events, and traces that follow a request across services. Together they let you ask a question you did not plan for when an incident starts.

Practise recovery before you need it

  • Write down how much data you can afford to lose (recovery point objective) and how long you can be down (recovery time objective).
  • Test restores from backup. A backup you have never restored is a hope.
  • Run a game day: break something in a safe environment and watch how the team responds.

After the incident

Hold a review that asks what in the system made the mistake easy, not who made it. Record what you will change, assign an owner, and follow up.

Infrastructure & Security is 20% of the ATP exam and 18% of the CTP exam. The specialist Cloud Architecture Practitioner (CAP) and IoT and Embedded Systems (IESP) exams give it 34% and 30%. See exam facts.

Sources and further reading

  1. Beyer, B., Jones, C., Petoff, J. and Murphy, N. R. (eds.) (2016). Site Reliability Engineering. O’Reilly Media.
  2. Rose, S., Borchert, O., Mitchell, S. and Connelly, S. (2020). Zero Trust Architecture. NIST Special Publication 800-207.
  3. Saltzer, J. H. and Schroeder, M. D. (1975). “The Protection of Information in Computer Systems.” Proceedings of the IEEE 63(9).

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>People Leadership in Engineering: How Structure Shapes Behaviour | IICTPhttps://blogs.iictp.org/structure-shapes-behaviour-engineering-leadershiphttps://blogs.iictp.org/structure-shapes-behaviour-engineering-leadershipWed, 21 Oct 2026 09:00:00 GMTBlogIICTPThe fifth TPBOK domain, People Leadership in Engineering, can sound soft. It is not. It covers how team structure, incentives and learning habits decide whether good engineers produce good systems. Most of its ideas come from research, not opinion.

Blog / TPBOK domains

Domain 521 October 20266 min read

People leadership in engineering: structure shapes behaviour

The fifth TPBOK domain, People Leadership in Engineering, can sound soft. It is not. It covers how team structure, incentives and learning habits decide whether good engineers produce good systems. Most of its ideas come from research, not opinion.

In this post
  1. Look at the system before the person
  2. Cognitive load is a real constraint
  3. Structure comes first, and it shows up in the code
  4. Find the constraint
  5. Safety is how teams learn
  6. How to run a blameless review
  7. Sources and further reading

Look at the system before the person

W. Edwards Deming argued that most failures come from the way work is organised, not from the people doing it. His often-cited estimate puts the large majority of problems on the system and management, and a small remainder on individual causes. You do not need the exact figure to use the idea: when the same mistake keeps happening to different people, the system is the thing to change.

Cognitive load is a real constraint

A team can only hold so much in its head. Matthew Skelton and Manuel Pais, in Team Topologies, treat cognitive load as the limit that decides how much a team can own well. Their answer is to design teams around the work: teams that own a flow of value end to end, platform teams that make that easier, and enabling teams that help others learn. If a team owns too many things, quality drops, however good the people are.

Structure comes first, and it shows up in the code

Conway’s observation that systems mirror the communication structure of the organisation that builds them is a leadership tool. If two teams keep blocking each other, look at ownership and boundaries before blaming individuals. Moving a boundary can remove a recurring conflict that no amount of coaching would.

Find the constraint

Eliyahu Goldratt’s Theory of Constraints says a system’s output is limited by its slowest step. Improving anything else does not help. In engineering the constraint is often review, testing, release approval or a single overloaded expert. Map the flow of work, find where it waits, and fix that first.

Safety is how teams learn

Amy Edmondson’s 1999 study of work teams found that psychological safety, the belief that you will not be punished for speaking up, was linked to how much teams learned from their mistakes. Ron Westrum described a spectrum of organisational cultures, from pathological to generative, and the DORA research has linked generative, high-trust cultures to better delivery performance. In practice this means treating incidents as information.

How to run a blameless review

  1. Write the timeline from what people knew at the time, not from what we know now.
  2. Ask how the system made the mistake easy, and what would have made it hard.
  3. List changes, each with an owner and a date.
  4. Share the write-up widely, so other teams can learn from it.
  5. Check back that the changes happened.

People Leadership in Engineering is 12% of the ATP exam and 10% of the CTP exam, and 15 to 20% of the PgTP and PfTP exams, where leaders work across teams. See exam facts.

Sources and further reading

  1. Deming, W. E. (1986). Out of the Crisis. MIT Center for Advanced Engineering Study.
  2. Edmondson, A. (1999). “Psychological Safety and Learning Behavior in Work Teams.” Administrative Science Quarterly 44(2).
  3. Goldratt, E. M. and Cox, J. (1984). The Goal. North River Press.
  4. Skelton, M. and Pais, M. (2019). Team Topologies. IT Revolution Press.
  5. Westrum, R. (2004). “A Typology of Organisational Cultures.” Quality and Safety in Health Care 13(Suppl 2).

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>IICTP vs PMI: What Each Credential Is Actually For | IICTPhttps://blogs.iictp.org/iictp-and-pmi-two-credentials-two-jobshttps://blogs.iictp.org/iictp-and-pmi-two-credentials-two-jobsWed, 21 Oct 2026 09:00:00 GMTBlogIICTPPeople often ask how IICTP compares with PMI. The honest answer is that they certify different things. PMI certifies project management. IICTP certifies technical practice. Whether one is better for you depends on the decisions your job asks you to make. Here is a fair look at both, including where

Blog / IICTP and PMI

IICTP vs PMI21 October 20267 min read

IICTP and PMI: two credentials for two different jobs

People often ask how IICTP compares with PMI. The honest answer is that they certify different things. PMI certifies project management. IICTP certifies technical practice. Whether one is better for you depends on the decisions your job asks you to make. Here is a fair look at both, including where PMI is clearly ahead.

In this post
  1. What PMI certifies
  2. What IICTP certifies
  3. Side by side
  4. Where PMI is ahead
  5. Where IICTP’s approach fits technical people better
  6. You may want both
  7. Sources and further reading

What PMI certifies

The Project Management Institute is a long-established body for project management. On its certifications page (read 20 October 2026) it lists four core credentials, CAPM, PMP, PgMP and PfMP, and a set of specialised ones, including PMI-ACP for agile, PMI-RMP for risk, PMI-PBA for business analysis, PMI-SP for scheduling, PMI-PMOCP for project management offices, PMI-CP for construction, CSPP for sustainability and PMI-CPMAI for managing AI projects. PMI says it has 1.7 million or more certification holders worldwide and has led the field since 1969.

PMI describes the PMP as demonstrating the ability to lead projects without being tied to any one methodology, industry or geography. That is a credential about running projects: people, processes and business priorities.

What IICTP certifies

IICTP certifies technical practice, meaning the decisions engineers and technical leaders make about systems. Its body of knowledge, the TPBOK, has five domains: Architecture & Systems Design; Engineering Governance & Agile Delivery; Applied AI & Emerging Tech Integration; Infrastructure & Security; and People Leadership in Engineering. There are ten credentials, from the entry-level ATP and the flagship CTP to program and portfolio levels and six specialist credentials.

Side by side

PMIIICTP
Main subjectManaging projects, programs and portfoliosTechnical decisions: architecture, delivery, AI, infrastructure, security, engineering leadership
The question it answersWill this work be delivered within scope, time and budget?What is the best technical decision here, and who does it affect?
Typical holderProject managers, program managers, PMO staff, and others who manage deliveryDevelopers, tech leads, engineering managers, architects, technical program managers
Exam contentProject management knowledge across people, process and business environment (per the PMP page)Scenario-based technical judgement across the five TPBOK domains
Track recordSince 1969, with 1.7M+ holders (PMI’s figures)New in 2026; no holders yet
PMI column from pmi.org, read 20 October 2026. IICTP column from iictp.org.

Where PMI is ahead

PMI is established and widely recognised. It has decades of history, a very large community and chapter network, a mature continuing-education system and an extensive training-partner network. PMI also states that its PMI-ACP exam is ISO-accredited. IICTP is a new independent credential and is not ISO/IEC 17024 accredited, and we do not claim otherwise. If an employer specifically asks for a PMP, an IICTP credential will not substitute for it.

Where IICTP’s approach fits technical people better

  • It tests the decisions technical people make. A project management credential, by design, does not ask whether you can choose between two architectures, contain a failing dependency or set guardrails for AI-generated code. IICTP exams do.
  • Scenario-based, not recall-based. CTP candidates face 150 scenario questions in 180 minutes and are asked for the best decision, not a memorised definition.
  • The exam is described in the open. Questions, time, pass mark and the share of questions per domain are published for all ten credentials on the exam facts page, with a blueprint PDF for each.
  • Vendor-neutral. Nothing in the TPBOK depends on one cloud, tool or framework.
  • Renewal tied to technical growth. Credentials renew through Technical Development Units earned from learning and from giving back, such as mentoring and open source. See how renewal works.

You may want both

A tech lead who also runs delivery might reasonably hold a project management credential and a technical one. They answer different questions. The decision guide in our third post in this series maps common roles to the credential that fits.

Sources and further reading

  1. Project Management Institute. “Project Management & Specialized Certifications.” pmi.org/certifications. Read 20 October 2026.
  2. Project Management Institute. “Project Management Professional (PMP)® Certification.” pmi.org/certifications/project-management-pmp. Read 20 October 2026.
  3. Project Management Institute. “PMI Agile Certified Practitioner (PMI-ACP)® Certification.” pmi.org/certifications/agile-acp. Read 20 October 2026.
  4. IICTP. Exam facts and eligibility. iictp.org/certifications/exam-facts.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>PMP vs CTP: Exam and Eligibility Compared | IICTPhttps://blogs.iictp.org/pmp-and-ctp-exam-eligibility-side-by-sidehttps://blogs.iictp.org/pmp-and-ctp-exam-eligibility-side-by-sideWed, 21 Oct 2026 09:00:00 GMTBlogIICTPThe PMP is PMI’s best-known credential and the CTP is IICTP’s flagship. They serve different jobs, but people want to know how the exams and entry requirements compare. This post lays out the published facts, with sources, and says plainly what is not being compared.

Blog / IICTP and PMI

PMP vs CTP21 October 20266 min read

PMP and CTP side by side: exam, eligibility and what you prepare for

The PMP is PMI’s best-known credential and the CTP is IICTP’s flagship. They serve different jobs, but people want to know how the exams and entry requirements compare. This post lays out the published facts, with sources, and says plainly what is not being compared.

In this post
  1. The numbers, from each body’s own pages
  2. What the experience requirements actually ask
  3. What you would study
  4. One rule change worth knowing about
  5. Which is easier?
  6. Sources and further reading

The numbers, from each body’s own pages

PMP (PMI)CTP (IICTP)
Questions180150, scenario-based
Time240 minutes180 minutes
Experience with a bachelor’s degree3 years managing projects36 months of technical leadership
Experience with a high school diploma5 years managing projects60 months of technical leadership
Other routesAssociate’s degree: 4 years. Degree from a PMI Global Accreditation Center program: 2 yearsNone
Required training35 hours of project management trainingNone for the CTP
Pass markNot covered in this comparison70% scaled score; no negative marking
What it coversPeople, processes and business environment (PMI’s description)Five TPBOK domains; Architecture & Systems Design is the largest share at 30%
PMP column from pmi.org/certifications/project-management-pmp, read 20 October 2026. CTP column from iictp.org/certifications/exam-facts.

We have not compared pass marks because we did not capture PMI’s on the pages we read. We would rather leave a cell out than guess it.

What the experience requirements actually ask

Both credentials gate on experience, and both count years rather than titles. The difference is the kind of experience. PMI asks for time spent managing projects in a professional setting, taking responsibility for planning, decisions, delivery and outcomes. IICTP asks for time in technical leadership: owning technical decisions for a team’s systems and delivery. Someone can have years of one and little of the other.

What you would study

For the PMP, PMI points candidates to its Exam Content Outline, which describes three domains: people, process and business environment. For the CTP, the blueprint lists the five TPBOK domains with their share of the exam.

CTP domainShare of questions
Architecture & Systems Design30%
Engineering Governance & Agile Delivery24%
Applied AI & Emerging Tech Integration18%
Infrastructure & Security18%
People Leadership in Engineering10%
From the CTP exam blueprint, version 1.0.

One rule change worth knowing about

PMI’s PMP page states that from 1 December 2026, live instructor-led classes count toward the 35 training hours only if delivered by a PMI Authorized Training Partner, a China Registered Education Provider, or an eligible accredited higher-education program. If you plan to take the PMP, check PMI’s current rules before booking a course.

Which is easier?

That depends on your background, so we will not claim either is. A strong engineer with no project management experience will find the CTP closer to daily work. An experienced project manager with a light technical background will find the PMP closer to theirs. Neither exam rewards memorising a list.

Sources and further reading

  1. Project Management Institute. “Project Management Professional (PMP)® Certification.” pmi.org/certifications/project-management-pmp. Read 20 October 2026.
  2. IICTP. “Exam facts, eligibility and blueprints.” iictp.org/certifications/exam-facts.
  3. IICTP. “CTP® exam blueprint,” version 1.0, 21 October 2026. iictp.org/blueprints/IICTP-CTP-Exam-Blueprint.pdf.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>PMP, PMI-ACP or CTP? Which Certification to Take First | IICTPhttps://blogs.iictp.org/pmi-or-iictp-which-to-take-firsthttps://blogs.iictp.org/pmi-or-iictp-which-to-take-firstWed, 21 Oct 2026 09:00:00 GMTBlogIICTPIf you are weighing a PMI credential against an IICTP one, start with the work you actually do. Both are respectable; they point at different jobs. This guide maps common roles to the credential that fits, and says when the answer is “both”.

Blog / IICTP and PMI

Which first21 October 20266 min read

PMI or IICTP: which should you take first?

If you are weighing a PMI credential against an IICTP one, start with the work you actually do. Both are respectable; they point at different jobs. This guide maps common roles to the credential that fits, and says when the answer is “both”.

In this post
  1. Start with your daily decisions
  2. A guide by role
  3. When the answer is both
  4. What employers may ask for
  5. Questions to ask yourself
  6. Sources and further reading

Start with your daily decisions

  • If your week is plans, budgets, stakeholders and status, you manage delivery. A project management credential fits.
  • If your week is design reviews, release calls, incident response and mentoring engineers, you make technical decisions. A technical credential fits.
  • If it is a mix, which most tech leads and technical program managers find, you may eventually want both.

A guide by role

If you are…ConsiderWhy
Early career, aiming at project managementPMI CAPMPMI describes it as the foundation for project management skills, with no experience required.
Early career developer or QAIICTP ATPCovers the software life cycle, baseline architecture and delivery fundamentals. 100 questions in 120 minutes; no work experience required.
Managing projects for 3 or more yearsPMI PMPThe established credential for leading projects across industries.
Tech lead or engineering managerIICTP CTPTests system design, trade-offs, technical risk and delivery governance.
Running agile ways of working with teamsPMI-ACP, or IICTP ADPPMI describes PMI-ACP as validating how you engage stakeholders, apply agile approaches and lead teams. ADP focuses on technical agile governance: pipelines, technical debt and release flow.
Leading AI projects as a managerPMI-CPMAIPMI positions it for leading AI projects and driving business impact.
Building and securing AI systemsIICTP AIPCovers applied AI engineering, retrieval systems, edge deployment and safety guardrails.
Leading sustainability in project deliveryPMI CSPPPMI describes it as leading resilient, sustainable projects.
Building greener softwareIICTP CSTPCarbon-aware development, efficient computing and hardware life cycle.
Running a program or portfolio of technical workPMI PgMP / PfMP or IICTP PgTP / PfTPChoose by whether the role is mainly managing programs and portfolios, or governing the technology inside them.
PMI descriptions from pmi.org/certifications, read 20 October 2026. IICTP descriptions from iictp.org.

When the answer is both

A tech lead who has become accountable for a delivery date and a budget is doing two jobs. A project management credential covers the delivery job. A technical credential covers the judgement job. Holding both costs time and fees, so choose based on which gap hurts more today.

What employers may ask for

Some job posts name a specific credential. If a role requires a PMP, take the PMP. If you are applying for engineering leadership roles, there is no single credential that every employer asks for. A public, checkable credential can help you show your judgement, but we will not promise that it gets you a job or a raise. No credential can.

Questions to ask yourself

  1. What decision did I make last month that I am most proud of, and which credential would have tested it?
  2. What is the next role I want, and what do people in it hold today?
  3. Do I need a recognised name for this employer, or evidence of technical depth?
  4. Am I eligible now? Check the eligibility planner for IICTP and PMI’s own requirements for theirs.

To go deeper, see the first post in this series on what each body certifies, and the exam facts for every IICTP credential.

Sources and further reading

  1. Project Management Institute. “Project Management & Specialized Certifications.” pmi.org/certifications. Read 20 October 2026.
  2. Project Management Institute. “Certified Associate in Project Management (CAPM)® Certification.” pmi.org/certifications/certified-associate-capm. Read 20 October 2026.
  3. Project Management Institute. “PMI Agile Certified Practitioner (PMI-ACP)® Certification.” pmi.org/certifications/agile-acp. Read 20 October 2026.
  4. IICTP. Credential pages and exam facts. iictp.org/certifications.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>Run an LLM Locally: Ollama vs llama.cpp vs vLLM (Local LLM Setup Guide) | IICTPhttps://blogs.iictp.org/run-an-llm-on-your-own-serverhttps://blogs.iictp.org/run-an-llm-on-your-own-serverMon, 26 Oct 2026 09:00:00 GMTBlogIICTPRunning a language model on hardware you control means prompts and documents never leave your building, the cost is the hardware rather than a meter, and the system keeps working offline. It also means you own sizing, updates and failure. This guide covers the three tools most people start with and

Blog / Guides

Local LLMs26 October 20267 min read

How to run an LLM on your own server: Ollama, llama.cpp and vLLM compared

Running a language model on hardware you control means prompts and documents never leave your building, the cost is the hardware rather than a meter, and the system keeps working offline. It also means you own sizing, updates and failure. This guide covers the three tools most people start with and how to choose between them.

In this post
  1. Start with memory, not the tool
  2. The three starting points
  3. A sensible path
  4. What “private” does and does not cover
  5. Sources and further reading

Start with memory, not the tool

A model is mostly a large table of numbers called weights. The memory they need is roughly the number of parameters times the bytes stored per weight. A 7-billion-parameter model at 16-bit precision needs about 14 GB for weights alone. At 4-bit precision it needs about 3.5 GB. Add room for the context (the conversation the model is holding) and for the runtime itself.

So the first question is never which tool, but whether the model you want fits in the memory you have. Quantization, which stores weights at lower precision, is how large models are made to fit. Formats such as GGUF carry quantized weights in one file.

The three starting points

ToolWhat it isBest forWatch out for
OllamaA packaged runner: one command downloads a model and serves it, with a local HTTP API.A laptop or single workstation; trying models quickly; developers building a prototype.Less control over scheduling and batching than a dedicated serving engine.
llama.cppA C/C++ inference engine that reads GGUF files and runs on CPU, on GPU, and on Apple Silicon.Constrained or mixed hardware; fine control over quantization and offloading.You assemble more of the surrounding system yourself.
vLLMA serving engine for GPUs, built for many concurrent requests, with an OpenAI-compatible API.A shared team service on server GPUs where throughput matters.It expects a capable GPU; it is not the tool for a laptop.
Choose by hardware and by how many people will use it at once.

A sensible path

  1. Write down the task and the smallest model that might do it. Smaller models are cheaper to run and often enough.
  2. Try it on a workstation with Ollama or llama.cpp. Measure the answer quality on your own examples, not on a leaderboard.
  3. Decide how many people will use it at once. One user and fifty users are different engineering problems.
  4. If many users share it, move to a serving engine such as vLLM on server GPUs, and put it behind your normal authentication and logging.
  5. Plan updates: models, runtimes and drivers all change, and a local deployment is yours to patch.

What “private” does and does not cover

Keeping inference local removes the third-party provider from the data path. It does not by itself secure the system. You still need access control, logging, network isolation and a plan for what the model is allowed to read. Treat the model server like any other service that touches sensitive data.

Sources and further reading

  1. llama.cpp project. github.com/ggml-org/llama.cpp. Read 26 October 2026.
  2. vLLM project documentation. docs.vllm.ai. Read 26 October 2026.
  3. Ollama documentation. ollama.com. Read 26 October 2026.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>Small Language Models (SLMs) Explained: When a Smaller Model Is the Better Choice | IICTPhttps://blogs.iictp.org/small-language-models-explainedhttps://blogs.iictp.org/small-language-models-explainedMon, 26 Oct 2026 09:00:00 GMTBlogIICTPA small language model (SLM) is a language model small enough to run on modest hardware, such as one workstation, a phone or an edge device. There is no agreed size cutoff; people usually mean models from a few hundred million up to a handful of billions of parameters, against the much larger models

Blog / Guides

Local LLMs26 October 20265 min read

Small language models explained: when smaller beats bigger

A small language model (SLM) is a language model small enough to run on modest hardware, such as one workstation, a phone or an edge device. There is no agreed size cutoff; people usually mean models from a few hundred million up to a handful of billions of parameters, against the much larger models offered as cloud services.

In this post
  1. Why a smaller model can be the better engineering choice
  2. Where a smaller model is the wrong choice
  3. How to decide
  4. Sources and further reading

Why a smaller model can be the better engineering choice

  • Cost and latency. Fewer parameters means less memory and less compute per token, so answers arrive faster and cost less to serve.
  • Privacy and control. A model that fits on your own hardware can run where the data already lives, including offline.
  • Predictability. A narrow task with a fixed output shape, such as classification, extraction or routing, rarely needs a general-purpose giant.
  • Specialisation. A small model tuned on your own task can match a larger general one on that task, though it will be worse outside it.

Where a smaller model is the wrong choice

Open-ended reasoning across many topics, long and tangled documents, and tasks you cannot describe ahead of time still favour larger models. A small model is a specialist, and the cost of using one for the wrong job is wrong answers delivered cheaply and quickly.

How to decide

  1. Define the task and write 50 real examples with the answers you expect.
  2. Test the smallest candidate model first, then move up only as far as the examples demand.
  3. Check the failure cases, not the average. A model that is usually right and occasionally dangerous may be unusable.
  4. Add a verification step for anything that matters. See applied AI: verify what the machine produces.

Running the chosen model yourself is covered in how to run an LLM on your own server.

Sources and further reading

  1. IICTP. Local LLM Practitioner credential page. iictp.org/certifications/llmp.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>What Is the TPBOK? The Technical Practitioner Body of Knowledge Explained | IICTPhttps://blogs.iictp.org/what-is-tpbokhttps://blogs.iictp.org/what-is-tpbokMon, 26 Oct 2026 09:00:00 GMTBlogIICTPThe TPBOK, the Technical Practitioner Body of Knowledge, is the written standard behind every IICTP exam. It describes what a technical practitioner is expected to know and do, so that a credential means the same thing to every candidate and every employer who reads it.

Blog / Guides

TPBOK26 October 20264 min read

What is the TPBOK? The Technical Practitioner Body of Knowledge, explained

The TPBOK, the Technical Practitioner Body of Knowledge, is the written standard behind every IICTP exam. It describes what a technical practitioner is expected to know and do, so that a credential means the same thing to every candidate and every employer who reads it.

In this post
  1. The five domains
  2. How it relates to the exams
  3. What it is not
  4. Sources and further reading

The five domains

  1. Architecture & Systems Design
  2. Engineering Governance & Agile Delivery
  3. Applied AI & Emerging Tech Integration
  4. Infrastructure & Security
  5. People Leadership in Engineering

Each domain has its own post in this blog, starting with architecture decisions that are expensive to undo.

How it relates to the exams

Exam questions are written against the domains, and each credential weights them differently. The exact numbers for every credential are published on the exam facts page, and the standard itself is on the TPBOK page.

What it is not

The TPBOK is IICTP’s own standard. It is not an ISO standard, and IICTP is not ISO/IEC 17024 accredited. It is also vendor-neutral by design: it describes practice, not a particular company’s products.

Not sure where you would start? Use the eligibility planner.

Sources and further reading

  1. IICTP. TPBOK. iictp.org/standards/tpbok.
  2. IICTP. Exam facts. iictp.org/certifications/exam-facts.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>Technical Practitioner Career Path: ATP, CTP, PgTP and PfTP Explained | IICTPhttps://blogs.iictp.org/technical-practitioner-career-pathhttps://blogs.iictp.org/technical-practitioner-career-pathMon, 26 Oct 2026 09:00:00 GMTBlogIICTPA credential ladder is only useful if each step matches a real change in the work. IICTP’s four core credentials are built around that idea: each one is aimed at a different stage of a technical career, and each asks for experience that fits the stage.

Blog / Guides

Career path26 October 20265 min read

The technical practitioner career path: from Associate to Portfolio level

A credential ladder is only useful if each step matches a real change in the work. IICTP’s four core credentials are built around that idea: each one is aimed at a different stage of a technical career, and each asks for experience that fits the stage.

In this post
  1. The four steps
  2. What changes at each step
  3. Where the specialist credentials fit
  4. How to choose your starting point
  5. Sources and further reading

The four steps

  1. ATP®, Associate Technical Practitioner, for people with roughly 0 to 2 years in technical work.
  2. CTP®, Certified Technical Practitioner, the flagship, for tech leads, engineering managers and senior IT project managers, around 3 to 7 years in.
  3. PgTP®, Program Technical Practitioner, for people running several related technical efforts, around 7 to 12 years in.
  4. PfTP®, Portfolio Technical Practitioner, for people steering a whole portfolio, 12 years or more.

What changes at each step

The work shifts from doing to deciding to coordinating to steering. At the associate level you are judged on sound fundamentals. At CTP you are judged on design trade-offs, risk and how well a team delivers. At programme and portfolio level the question becomes how many efforts you can keep coherent at once, and which ones to stop.

Exam depth follows the same curve. Exact question counts, durations and pass marks for each credential are on the exam facts page.

Where the specialist credentials fit

Alongside the ladder sit six specialist credentials: AI, cloud architecture, agile delivery, IoT and edge, local LLMs, and clean software telemetry. They are not rungs. You take one when your day-to-day work lives in that area, whatever your level.

How to choose your starting point

  1. Count your relevant years honestly and check each credential’s eligibility rules.
  2. Pick the step that matches what you do now, not the one you hope to reach.
  3. Use the eligibility planner to see your options in one place.

Sources and further reading

  1. IICTP. Credential pages. iictp.org/certifications.
  2. IICTP. Exam facts. iictp.org/certifications/exam-facts.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>How to Prepare for a Scenario-Based Certification Exam: A Practical Method | IICTPhttps://blogs.iictp.org/prepare-for-a-scenario-based-certification-examhttps://blogs.iictp.org/prepare-for-a-scenario-based-certification-examMon, 26 Oct 2026 09:00:00 GMTBlogIICTPA scenario-based exam does not ask you to recall a definition. It describes a situation and asks what you would do. That changes how to study: you are training judgement, not memory.

Blog / Guides

Exam prep26 October 20266 min read

How to prepare for a scenario-based certification exam

A scenario-based exam does not ask you to recall a definition. It describes a situation and asks what you would do. That changes how to study: you are training judgement, not memory.

In this post
  1. Read the question the way an architect reads a brief
  2. A study method that fits
  3. What to avoid
  4. On the day
  5. Sources and further reading

Read the question the way an architect reads a brief

Each scenario carries constraints: a deadline, a risk, a team, a system that already exists. The wrong answers are usually reasonable ideas that ignore one constraint. Before choosing, name the constraints out loud.

A study method that fits

  1. Start from the published blueprint for your credential and list its domains.
  2. For each domain, write the decisions a practitioner has to make, not the terms they have to know.
  3. Practise on your own past work: for a decision you made, write the options you rejected and why.
  4. Time yourself on scenario sets. Long scenarios are a reading-speed problem as well as a knowledge problem.
  5. Review every miss by asking which constraint you overlooked.

What to avoid

  • Memorising lists with no situation attached.
  • Studying only your strongest domain.
  • Treating practice scores as a promise. Practice material is not the exam.

On the day

Read all of each scenario, mark questions you are unsure of rather than stalling, and keep an eye on the clock. The format for each credential, such as the number of questions and the time allowed, is on the exam facts page.

Sources and further reading

  1. IICTP. Exam facts. iictp.org/certifications/exam-facts.
  2. IICTP. Exam blueprints. iictp.org/blueprints.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>How to Verify a Certificate Online: Why a Public Credential Registry Matters | IICTPhttps://blogs.iictp.org/how-to-verify-a-certificationhttps://blogs.iictp.org/how-to-verify-a-certificationMon, 26 Oct 2026 09:00:00 GMTBlogIICTPA certificate is a claim. Anyone can type a credential onto a CV, and a PDF is easy to alter. Verification is the step that turns the claim into evidence, and it only works if the issuer publishes something a third party can check.

Blog / Guides

Verification26 October 20264 min read

How employers verify a certification, and why a public registry matters

A certificate is a claim. Anyone can type a credential onto a CV, and a PDF is easy to alter. Verification is the step that turns the claim into evidence, and it only works if the issuer publishes something a third party can check.

In this post
  1. What a good verification looks like
  2. How to check someone’s credential
  3. Spotting a fake
  4. IICTP’s approach
  5. Sources and further reading

What a good verification looks like

  • The issuer runs a public lookup that anyone can reach without an account.
  • The lookup confirms the holder, the credential, the issue date and the current status.
  • The status can change: a credential can lapse, be suspended or be withdrawn, and the lookup shows it.
  • The record tells you what the issuer stands behind, and what it does not.

How to check someone’s credential

  1. Ask for the credential ID and the holder’s name as it appears on the record.
  2. Go to the issuer’s own website, typed in yourself, not through a link in the CV.
  3. Compare the record with what the candidate said: credential, date and status.
  4. If the issuer has no public lookup, treat the claim as unverified.

Spotting a fake

Be wary of a certificate that cannot be looked up, a “registry” run by someone other than the issuer, an ID format that does not match the issuer’s, or a credential name that is a near-copy of a well-known one.

IICTP’s approach

IICTP publishes a public registry so a credential can be checked directly. Its registry policy explains what a record contains and how status changes. Sample records on the site are illustrative only.

Sources and further reading

  1. IICTP. Verify a credential. iictp.org/verify.
  2. IICTP. Registry policy. iictp.org/registry-policy.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>Digital Badges Explained: Open Badges, Verifiable Credentials and How They Differ | IICTPhttps://blogs.iictp.org/digital-badges-and-verifiable-credentials-explainedhttps://blogs.iictp.org/digital-badges-and-verifiable-credentials-explainedMon, 26 Oct 2026 09:00:00 GMTBlogIICTPA digital badge is a credential in a form that travels: it can be shared on a profile, checked by a machine and revoked by the issuer. Two standards come up most often, and they solve slightly different problems.

Blog / Guides

Digital badges26 October 20265 min read

Digital badges and verifiable credentials, explained

A digital badge is a credential in a form that travels: it can be shared on a profile, checked by a machine and revoked by the issuer. Two standards come up most often, and they solve slightly different problems.

In this post
  1. Open Badges
  2. Verifiable Credentials
  3. What to look for in a badge
  4. What a badge cannot do
  5. Sources and further reading

Open Badges

Open Badges is a specification maintained by 1EdTech for packaging a credential with its metadata: who issued it, who earned it, what it was for and the criteria. The point is portability and a link back to the issuer, so the badge can be checked later.

Verifiable Credentials

Verifiable Credentials is a W3C standard for credentials that are cryptographically signed. A verifier can confirm that the issuer signed it and that it has not been altered, without phoning the issuer each time.

What to look for in a badge

  • A stable link back to the issuer’s record.
  • Clear criteria: what was assessed, and how.
  • An issue date and a status that can change.
  • Signing or hosting that lets a third party check it independently.

What a badge cannot do

A badge proves that an issuer made a claim. It does not make the issuer credible. Judge the badge by the body behind it. IICTP issues digital badges tied to its public registry, and it is a new independent body that is not ISO/IEC 17024 accredited.

Sources and further reading

  1. 1EdTech. Open Badges. 1edtech.org/standards/open-badges.
  2. W3C. Verifiable Credentials Data Model. w3.org/TR/vc-data-model-2.0/.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>Technical Practitioner Interview Questions (With What Strong Answers Look Like) | IICTPhttps://blogs.iictp.org/technical-practitioner-interview-questionshttps://blogs.iictp.org/technical-practitioner-interview-questionsMon, 26 Oct 2026 09:00:00 GMTBlogIICTPGood interview questions for a technical lead or practitioner ask about decisions, not trivia. Here are twelve, each with what a strong answer tends to show. Use them to prepare, or to interview.

Blog / Guides

Interviews26 October 20266 min read

Technical practitioner interview questions, and what good answers show

Good interview questions for a technical lead or practitioner ask about decisions, not trivia. Here are twelve, each with what a strong answer tends to show. Use them to prepare, or to interview.

In this post
  1. Architecture and design
  2. Delivery and quality
  3. Applied AI
  4. People and leadership
  5. Sources and further reading

Architecture and design

  1. Tell me about a design decision you wish you had made differently. Strong answers name the constraint they missed and what they changed afterwards.
  2. How do you decide where to draw a service boundary? Look for hiding likely change and for data ownership.
  3. When have you chosen a simple solution over a clever one? Look for cost awareness and for restraint.

Delivery and quality

  1. How do you keep releases small without slowing the team down? Look for automation, feature flags and fast feedback.
  2. Describe an outage you were part of. Strong answers cover detection, response and what changed in the system, not blame.
  3. How do you handle technical debt with a manager who wants features? Look for pricing the debt in terms the manager cares about.

Applied AI

  1. Where have you used AI in your work, and where did you decide not to? Look for verification of output and awareness of failure modes.
  2. How would you test a feature built on a language model? Look for examples, edge cases and guardrails.

People and leadership

  1. How do you give feedback that someone does not want to hear? Look for specifics and respect.
  2. What would you do when two strong engineers disagree on an approach? Look for decision records and a clear way to decide.
  3. How do you grow someone who is more junior than you? Look for deliberate practice, not just delegation.
  4. What do you stop doing when you take on more scope? Look for honesty about the shift from doing to leading.

Sources and further reading

  1. IICTP. TPBOK domains. iictp.org/standards/tpbok.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>AI Agents Explained: How Agentic AI Actually Works in Production | IICTPhttps://blogs.iictp.org/ai-agents-explainedhttps://blogs.iictp.org/ai-agents-explainedMon, 26 Oct 2026 09:00:00 GMTBlogIICTPAn AI agent is a program that uses a language model to decide what to do next, takes actions through tools, looks at the result and repeats until a goal is met. The model is the decision-maker; the rest of the system is what makes it safe and useful.

Blog / Guides

Applied AI26 October 20266 min read

AI agents explained: how agentic AI works in production

An AI agent is a program that uses a language model to decide what to do next, takes actions through tools, looks at the result and repeats until a goal is met. The model is the decision-maker; the rest of the system is what makes it safe and useful.

In this post
  1. The loop
  2. What makes it work in production
  3. Where agents fail
  4. When not to use one
  5. Sources and further reading

The loop

  1. Receive a goal and the current state.
  2. Ask the model to choose the next step: answer, or call a tool.
  3. Run the tool (search, query, code, an API) under strict limits.
  4. Feed the result back and repeat, or stop.

What makes it work in production

  • Narrow tools. Give the agent a few well-described actions rather than open access.
  • Limits. Cap steps, time, spend and permissions.
  • Human checkpoints for actions that are costly or hard to undo.
  • Logging of every step, so a failure can be reconstructed.

Where agents fail

Agents compound small errors: a wrong early step leads the rest astray. They can also follow instructions hidden in the content they read. Treat anything the agent reads from outside as untrusted input, and never give it more authority than the task needs.

When not to use one

If the steps are known in advance, write a normal workflow and call the model only where judgement is needed. It is cheaper, faster and easier to test. Reach for an agent when the path genuinely depends on what is found along the way.

Sources and further reading

  1. Anthropic. “Building effective agents.” anthropic.com/engineering/building-effective-agents.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>What Is RAG? Retrieval-Augmented Generation Explained Step by Step | IICTPhttps://blogs.iictp.org/rag-explainedhttps://blogs.iictp.org/rag-explainedMon, 26 Oct 2026 09:00:00 GMTBlogIICTPRetrieval-augmented generation (RAG) gives a language model the documents it needs at the moment it answers, instead of relying only on what it learned in training. It is the standard way to make a model answer from your own material.

Blog / Guides

Applied AI26 October 20266 min read

RAG explained: retrieval-augmented generation, step by step

Retrieval-augmented generation (RAG) gives a language model the documents it needs at the moment it answers, instead of relying only on what it learned in training. It is the standard way to make a model answer from your own material.

In this post
  1. The pipeline
  2. Where quality is won or lost
  3. How to know it works
  4. Limits
  5. Sources and further reading

The pipeline

  1. Ingest. Split documents into chunks and store them with an embedding for each, in a vector index or a search engine.
  2. Retrieve. For a question, find the chunks most relevant to it.
  3. Augment. Place those chunks in the prompt with the question.
  4. Generate. The model answers, ideally citing the chunks it used.

Where quality is won or lost

  • Chunking: chunks that cut a table or a thought in half retrieve badly.
  • Retrieval: combining keyword and semantic search often beats either alone.
  • Prompting: tell the model to answer only from the supplied text and to say when it cannot.
  • Freshness: re-index when the source changes.

How to know it works

Build a set of real questions with known answers and measure two things separately: did retrieval find the right chunk, and did the model use it correctly. A wrong answer with the right chunk retrieved is a different bug from one where nothing relevant was found.

Limits

RAG reduces unsupported answers but does not remove them. Keep citations visible, restrict what each user can retrieve to what they may see, and test for prompts that try to pull in other people’s documents.

Sources and further reading

  1. Lewis et al. “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks.” arXiv:2005.11401.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>RAG vs Fine-Tuning: How to Choose Between Them (Cost, Accuracy, Maintenance) | IICTPhttps://blogs.iictp.org/rag-vs-fine-tuninghttps://blogs.iictp.org/rag-vs-fine-tuningMon, 26 Oct 2026 09:00:00 GMTBlogIICTPBoth RAG and fine-tuning adapt a model to your needs, but they change different things. RAG changes what the model can see at answer time. Fine-tuning changes how the model behaves.

Blog / Guides

Applied AI26 October 20265 min read

RAG vs fine-tuning: how to choose

Both RAG and fine-tuning adapt a model to your needs, but they change different things. RAG changes what the model can see at answer time. Fine-tuning changes how the model behaves.

In this post
  1. Use RAG when…
  2. Use fine-tuning when…
  3. Maintenance
  4. A practical order
  5. Sources and further reading

Use RAG when…

  • The answer depends on facts that change or that are private.
  • You need to show where an answer came from.
  • Different users may see different documents.

Use fine-tuning when…

  • You need a consistent style, format or tone.
  • The task is narrow and repeated, and prompts alone are not reliable enough.
  • You want a smaller model to do one job well.

Maintenance

RAG is updated by updating the index. Fine-tuning is updated by training again, so facts that change quickly are a poor fit. Knowledge baked into weights is also hard to audit or remove.

A practical order

  1. Try a clear prompt with examples.
  2. Add retrieval if the model lacks facts.
  3. Consider fine-tuning only if behaviour is still wrong and you have good examples.
  4. Measure each step on your own test set before moving on.

Sources and further reading

  1. Lewis et al. “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks.” arXiv:2005.11401.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>Prompt Engineering vs Context Engineering: What Practitioners Actually Do | IICTPhttps://blogs.iictp.org/prompt-engineering-and-context-engineeringhttps://blogs.iictp.org/prompt-engineering-and-context-engineeringMon, 26 Oct 2026 09:00:00 GMTBlogIICTPWriting a good prompt matters, but in a real system the prompt is only part of what the model sees. Context engineering is the wider job: deciding everything that goes into the model’s context for a given call.

Blog / Guides

Applied AI26 October 20265 min read

Prompt engineering in 2026: beyond prompts, context engineering

Writing a good prompt matters, but in a real system the prompt is only part of what the model sees. Context engineering is the wider job: deciding everything that goes into the model’s context for a given call.

In this post
  1. What goes into context
  2. Principles
  3. Test the prompt like software
  4. Treat outside text as untrusted
  5. Sources and further reading

What goes into context

  • Instructions and role.
  • The user’s request and recent conversation.
  • Retrieved documents and tool results.
  • Examples of the desired output.
  • Constraints and output format.

Principles

  • Be specific. State the task, the audience and the format.
  • Show, don’t just tell. A few good examples beat a long description.
  • Keep it relevant. More context is not better context; irrelevant text can mislead the model.
  • Order matters. Put the most important instructions where the model will weigh them.
  • Version it. Prompts are code: review, test and track them.

Test the prompt like software

Keep a set of inputs with expected qualities, run every prompt change against it, and look at regressions as well as improvements.

Treat outside text as untrusted

Documents and web pages can contain instructions aimed at the model. Separate trusted instructions from untrusted content, and never let retrieved text widen what the system is allowed to do.

Sources and further reading

  1. Anthropic. Prompt engineering overview. docs.anthropic.com.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>LLM Evaluation: How to Test an AI Application (Evals, Hallucinations, Guardrails) | IICTPhttps://blogs.iictp.org/how-to-evaluate-an-llm-applicationhttps://blogs.iictp.org/how-to-evaluate-an-llm-applicationMon, 26 Oct 2026 09:00:00 GMTBlogIICTPYou cannot improve what you cannot measure, and an AI feature that “seems fine” in a demo can fail quietly in production. An evaluation set is to an AI application what a test suite is to ordinary code.

Blog / Guides

Applied AI26 October 20266 min read

How to evaluate an LLM application: evals, hallucination tests and guardrails

You cannot improve what you cannot measure, and an AI feature that “seems fine” in a demo can fail quietly in production. An evaluation set is to an AI application what a test suite is to ordinary code.

In this post
  1. Build the eval set from real use
  2. Ways to score
  3. Hallucination tests
  4. Guardrails
  5. Sources and further reading

Build the eval set from real use

  1. Collect real or realistic inputs, including the awkward ones.
  2. Write down what a good answer must contain and what it must never contain.
  3. Add cases for each failure you find, so it cannot return unnoticed.

Ways to score

  • Exact checks for structured output: valid format, required fields.
  • Reference answers compared by a person or by another model.
  • Rubrics for qualities such as tone, safety and use of sources.
  • Human review of a sample, to keep the automated scores honest.

Hallucination tests

Include questions the system should refuse or say it cannot answer, and questions with a false premise. Check that answers stay within the supplied sources.

Guardrails

Add checks around the model, not only inside the prompt: validate output format, filter unsafe content, limit tool permissions, and log inputs and outputs for review. Run the eval set again whenever the model, the prompt or the data changes.

Sources and further reading

  1. OpenAI. Evals guide. platform.openai.com/docs/guides/evals.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>LLMOps Explained: Running LLM Applications in Production | IICTPhttps://blogs.iictp.org/llmops-running-ai-in-productionhttps://blogs.iictp.org/llmops-running-ai-in-productionMon, 26 Oct 2026 09:00:00 GMTBlogIICTPLLMOps is the operational side of language-model applications: keeping them reliable, affordable and improvable once real users depend on them. Much of it is ordinary operations with a few new failure modes.

Blog / Guides

Applied AI26 October 20266 min read

LLMOps: running AI in production, covering cost, monitoring and versioning

LLMOps is the operational side of language-model applications: keeping them reliable, affordable and improvable once real users depend on them. Much of it is ordinary operations with a few new failure modes.

In this post
  1. What to monitor
  2. What to version
  3. Controlling cost
  4. Change safely
  5. Sources and further reading

What to monitor

  • Latency and error rates, as with any service.
  • Token use and cost per request and per feature.
  • Quality signals: user feedback, refusals, retries, escalations.
  • Drift: answer quality changing after a model or data change.

What to version

  • Prompts and prompt templates.
  • The model and its settings.
  • The retrieval index and its source data.
  • The evaluation set.

Controlling cost

  • Use the smallest model that passes your evals.
  • Cache repeated work.
  • Trim the context you send.
  • Set per-user and per-feature limits.

Change safely

Treat a model upgrade as a release: run the eval set, roll out to a small share first, compare, and keep a way back. Log enough to reproduce a bad answer, while keeping personal data out of logs that do not need it.

Sources and further reading

  1. Google Cloud. “MLOps: Continuous delivery and automation pipelines in machine learning.” cloud.google.com/architecture.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>Responsible AI in Practice: Bias, Privacy and AI Governance Checklists | IICTPhttps://blogs.iictp.org/responsible-ai-in-practicehttps://blogs.iictp.org/responsible-ai-in-practiceMon, 26 Oct 2026 09:00:00 GMTBlogIICTPResponsible AI is less about principles on a poster and more about decisions made at specific points in a project. Here is a short checklist for each point.

Blog / Guides

Applied AI26 October 20265 min read

Responsible AI in practice: bias, privacy and governance checklists

Responsible AI is less about principles on a poster and more about decisions made at specific points in a project. Here is a short checklist for each point.

In this post
  1. Before you build
  2. Data and privacy
  3. Bias and fairness
  4. In operation
  5. Sources and further reading

Before you build

  1. Say what decision the system supports and who is affected by it.
  2. Decide whether AI is needed at all.
  3. Name who is accountable for the system.

Data and privacy

  • Know what data is used, where it came from and whether you may use it for this purpose.
  • Minimise personal data and keep it out of prompts and logs where you can.
  • Check where a provider stores and processes data, and under what terms.

Bias and fairness

  • Test results across the groups the system affects, not only on average.
  • Look at how errors are distributed, not just how many there are.
  • Give people a way to challenge an outcome.

In operation

  • Keep a human in the loop for consequential decisions.
  • Monitor for drift and for new misuse.
  • Keep records so decisions can be explained and audited.
  • Review the system on a schedule, and when the law or the use changes.

Sources and further reading

  1. NIST. AI Risk Management Framework (AI RMF 1.0). nist.gov/itl/ai-risk-management-framework.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>AI Copilots at Work: Where They Help, Where They Fail | IICTPhttps://blogs.iictp.org/ai-copilots-at-workhttps://blogs.iictp.org/ai-copilots-at-workMon, 26 Oct 2026 09:00:00 GMTBlogIICTPAI copilots draft, summarise, suggest and search. They are strongest when a person is still doing the thinking and can check the output quickly.

Blog / Guides

Applied AI26 October 20264 min read

AI copilots at work: where they help and where they fail

AI copilots draft, summarise, suggest and search. They are strongest when a person is still doing the thinking and can check the output quickly.

In this post
  1. Where they help
  2. Where they fail
  3. Working with one
  4. For teams
  5. Sources and further reading

Where they help

  • First drafts of text and code that a person will review.
  • Summarising long material the person could read if needed.
  • Boilerplate, translation and format changes.
  • Searching and explaining unfamiliar material.

Where they fail

  • Confident, wrong answers, especially on specifics.
  • Work that needs context the tool cannot see.
  • Anything where checking is as slow as doing.
  • Subtle errors in code, numbers and citations.

Working with one

  1. Ask for a draft, not a final.
  2. Check every fact, figure and reference you will rely on.
  3. Run and test generated code like any other code.
  4. Keep sensitive data out unless your organisation has approved the tool.

For teams

Agree what the tools may be used for, what must be reviewed, and who is accountable. See applied AI: verify what the machine produces.

Sources and further reading

  1. IICTP. TPBOK, Applied AI & Emerging Tech Integration. iictp.org/standards/tpbok.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>LangChain and LangGraph Explained: What Practitioners Actually Need to Know | IICTPhttps://blogs.iictp.org/langchain-and-langgraph-what-practitioners-needhttps://blogs.iictp.org/langchain-and-langgraph-what-practitioners-needMon, 26 Oct 2026 09:00:00 GMTBlogIICTPLangChain and LangGraph are open-source libraries for building applications around language models. They are tools, not requirements; knowing what they do helps you decide whether you need them.

Blog / Guides

Applied AI26 October 20265 min read

LangChain and LangGraph: what practitioners need to know

LangChain and LangGraph are open-source libraries for building applications around language models. They are tools, not requirements; knowing what they do helps you decide whether you need them.

In this post
  1. What they do
  2. What they save you
  3. What they cost you
  4. A sensible rule
  5. Sources and further reading

What they do

  • LangChain provides building blocks: model wrappers, prompt templates, retrievers and tool interfaces.
  • LangGraph models an application as a graph of steps with shared state, which suits agents that loop, branch and wait for people.

What they save you

Common plumbing: connecting to many model providers, loading documents, calling tools and managing state between steps.

What they cost you

  • Another layer to learn and to keep up with as it changes.
  • Abstractions can hide what is actually sent to the model, which makes debugging harder.

A sensible rule

Start with the model provider’s own client and plain code. Adopt a framework when you are repeating the same plumbing, and make sure you can still see every prompt and tool call. The skill that transfers is the design: tools, state, limits and evaluation.

Sources and further reading

  1. LangChain documentation. python.langchain.com.
  2. LangGraph documentation. langchain-ai.github.io/langgraph.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>Multimodal AI Explained: How Models Work With Text, Images and Audio | IICTPhttps://blogs.iictp.org/multimodal-ai-explainedhttps://blogs.iictp.org/multimodal-ai-explainedMon, 26 Oct 2026 09:00:00 GMTBlogIICTPA multimodal model takes more than one kind of input, such as text with images or audio, and can sometimes produce more than one kind of output. It lets a single system read a chart, describe a photo or answer a spoken question.

Blog / Guides

Applied AI26 October 20264 min read

Multimodal AI explained: text, image and audio in one system

A multimodal model takes more than one kind of input, such as text with images or audio, and can sometimes produce more than one kind of output. It lets a single system read a chart, describe a photo or answer a spoken question.

In this post
  1. Typical uses
  2. Design points
  3. Testing
  4. Sources and further reading

Typical uses

  • Reading documents with tables, forms and diagrams.
  • Describing images for accessibility.
  • Transcribing and summarising audio.
  • Answering questions about a screenshot.

Design points

  • Check the input quality. Blurry or cropped images and noisy audio lower accuracy.
  • Verify the reading. Extracted numbers from a chart or form should be checked.
  • Mind the privacy. Images and audio can contain people and personal data.
  • Cost. Images and audio often cost more to process than text.

Testing

Build an evaluation set from your real inputs, including bad ones, and score extraction and description separately. See how to evaluate an LLM application.

Sources and further reading

  1. IICTP. AI Practitioner credential page. iictp.org/certifications/aip.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>On-Premise LLMs and Private AI for Regulated Industries (Law, Health, Finance) | IICTPhttps://blogs.iictp.org/private-ai-on-premise-llms-regulated-industrieshttps://blogs.iictp.org/private-ai-on-premise-llms-regulated-industriesMon, 26 Oct 2026 09:00:00 GMTBlogIICTPLaw firms, clinics and financial teams handle material they may not be free to send to an outside service. Running a model on infrastructure you control can keep that material inside your boundary, but it does not make a deployment compliant by itself.

Blog / Guides

Local LLMs26 October 20266 min read

Private AI for regulated industries: on-premise LLMs for law, health and finance

Law firms, clinics and financial teams handle material they may not be free to send to an outside service. Running a model on infrastructure you control can keep that material inside your boundary, but it does not make a deployment compliant by itself.

In this post
  1. Why organisations choose it
  2. What you still have to do
  3. Questions to answer first
  4. A note on compliance
  5. Sources and further reading

Why organisations choose it

  • Data stays on systems the organisation controls.
  • Data-residency and contract limits are easier to meet.
  • The system can run in a network with no outside access.
  • Costs are predictable once the hardware exists.

What you still have to do

  • Access control. Restrict who can use the model and what documents it can read.
  • Logging and retention. Decide what is recorded, who sees it and for how long.
  • Isolation. Segment the network; log and review administrator access.
  • Updates. You own patching for the runtime, the drivers and the model.

Questions to answer first

  1. What data will the system touch, and under which rules?
  2. Who may use it, and for what?
  3. What happens when it is wrong, and who checks?
  4. Who is accountable for the system?

A note on compliance

Regulations differ by country and sector. Ask your compliance or legal team what applies. Nothing in this post is legal advice.

Sources and further reading

  1. NIST. AI Risk Management Framework (AI RMF 1.0). nist.gov/itl/ai-risk-management-framework.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>Local LLM vs Cloud AI: How to Compare Cost, Privacy and Latency | IICTPhttps://blogs.iictp.org/local-llm-vs-cloud-ai-cost-privacy-latencyhttps://blogs.iictp.org/local-llm-vs-cloud-ai-cost-privacy-latencyMon, 26 Oct 2026 09:00:00 GMTBlogIICTPThe honest answer to “local or cloud?” is a comparison you do with your own numbers. Here is how to set it up, so you do not rely on anyone else’s claims.

Blog / Guides

Local LLMs26 October 20265 min read

Local LLM vs cloud AI: cost, privacy and latency compared

The honest answer to “local or cloud?” is a comparison you do with your own numbers. Here is how to set it up, so you do not rely on anyone else’s claims.

In this post
  1. Cost: compare the whole bill
  2. Privacy
  3. Latency
  4. How to compare
  5. Sources and further reading

Cost: compare the whole bill

  • Cloud: price per token or request, times your expected volume, plus any minimum commitments.
  • Local: hardware, power, hosting, staff time to run and patch it, and the cost of replacing it.
  • A local deployment pays off when use is steady and high; a cloud service often wins when use is low or spiky.

Privacy

  • Local keeps prompts and documents inside your boundary.
  • Cloud can still meet strict needs through contracts and regional options; read the terms.

Latency

  • Local removes a network round trip but is limited by your hardware.
  • Cloud offers more powerful models but adds network time and can queue under load.

How to compare

  1. Pick a realistic task and 50 real examples.
  2. Run both options and score quality.
  3. Measure time to first token and total time.
  4. Cost out a month of expected use for each.

Sources and further reading

  1. IICTP. Local LLM Practitioner credential page. iictp.org/certifications/llmp.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>LLM Quantization Explained: GGUF, AWQ and Running Large Models on Small Hardware | IICTPhttps://blogs.iictp.org/llm-quantization-explained-gguf-awqhttps://blogs.iictp.org/llm-quantization-explained-gguf-awqMon, 26 Oct 2026 09:00:00 GMTBlogIICTPQuantization stores a model’s weights using fewer bits, so the model takes less memory and often runs faster. The trade-off is some loss of accuracy, which grows as the precision falls.

Blog / Guides

Local LLMs26 October 20266 min read

Quantization explained: GGUF, AWQ and running big models on small hardware

Quantization stores a model’s weights using fewer bits, so the model takes less memory and often runs faster. The trade-off is some loss of accuracy, which grows as the precision falls.

In this post
  1. The idea
  2. Formats you will meet
  3. Choosing a level
  4. Pitfalls
  5. Sources and further reading

The idea

A full-precision weight might use 16 bits. Quantizing to 8 or 4 bits maps each weight to a coarser set of values. Memory falls roughly in proportion: a model at 4 bits needs about a quarter of the weight memory of the same model at 16 bits.

Formats you will meet

  • GGUF: a single-file format used by llama.cpp and tools built on it, with many quantization levels.
  • AWQ: a method that protects the weights that matter most to the output, designed for GPU inference.
  • GPTQ: another post-training method, also aimed at GPU inference.

Choosing a level

  1. Start from the memory you have.
  2. Pick the highest precision that fits with room for context.
  3. Test on your own examples; compare a lower level against it.
  4. Stop lowering when quality drops in ways that matter.

Pitfalls

  • Quantization loss shows up unevenly: maths, code and rare languages are often hit first.
  • Leave memory for the context cache, which grows with the conversation.
  • Re-test after changing quantization, like any other change.

Sources and further reading

  1. Lin et al. “AWQ: Activation-aware Weight Quantization.” arXiv:2306.00978.
  2. llama.cpp project. github.com/ggml-org/llama.cpp.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>Best Hardware for Running Local LLMs: GPUs, NPUs and Apple Silicon Explained | IICTPhttps://blogs.iictp.org/hardware-for-local-ai-gpus-npus-apple-siliconhttps://blogs.iictp.org/hardware-for-local-ai-gpus-npus-apple-siliconMon, 26 Oct 2026 09:00:00 GMTBlogIICTPFor local models, the main constraint is memory, followed by memory speed, and only then raw compute. Match the hardware to the model you intend to run, not the other way round.

Blog / Guides

Local LLMs26 October 20266 min read

Choosing hardware for local AI: GPUs, NPUs and Apple Silicon

For local models, the main constraint is memory, followed by memory speed, and only then raw compute. Match the hardware to the model you intend to run, not the other way round.

In this post
  1. What matters, in order
  2. The families
  3. Sizing steps
  4. Sources and further reading

What matters, in order

  1. Memory capacity: the model has to fit, with room for context.
  2. Memory bandwidth: generating each token reads the weights, so bandwidth limits speed.
  3. Compute: matters most for processing long prompts and for serving many users.
  4. Software support: the runtime must support your hardware.

The families

  • Discrete GPUs: the usual choice for servers; fast, with a fixed memory size.
  • Apple Silicon: unified memory shared by CPU and GPU lets a laptop or desktop hold large models, at lower speeds than server GPUs.
  • NPUs: low-power accelerators in new laptops and phones, good for small models; check what your runtime supports.
  • CPU only: workable for small or heavily quantized models and for light use.

Sizing steps

  1. Choose the smallest model that passes your tests.
  2. Work out its memory at your chosen quantization, plus context.
  3. Pick hardware with comfortable headroom.
  4. Measure speed on your own prompts before you buy in volume.

Sources and further reading

  1. IICTP. Local LLM Practitioner credential page. iictp.org/certifications/llmp.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>Local RAG: Build Private Document Search With a Local LLM | IICTPhttps://blogs.iictp.org/local-rag-private-document-searchhttps://blogs.iictp.org/local-rag-private-document-searchMon, 26 Oct 2026 09:00:00 GMTBlogIICTPCombine retrieval with a locally hosted model and you can answer questions from sensitive documents without sending them anywhere. Every component has to run on your side, which is where most of the design work lies.

Blog / Guides

Local LLMs26 October 20265 min read

RAG on a local LLM: private document search that never leaves your building

Combine retrieval with a locally hosted model and you can answer questions from sensitive documents without sending them anywhere. Every component has to run on your side, which is where most of the design work lies.

In this post
  1. The parts you host
  2. Design points
  3. Test it
  4. Sources and further reading

The parts you host

  • An embedding model to turn text into vectors.
  • A vector store or a search engine.
  • The language model that writes the answer.
  • A thin service that ties them together and enforces permissions.

Design points

  • Permissions: retrieve only documents the asking user may see. Do not leave this to the model.
  • Ingestion: handle scanned pages, tables and updates.
  • Citations: show the passages used so answers can be checked.
  • Offline updates: plan how new models and software reach a machine with no internet.

Test it

Use real questions and measure retrieval and answers separately. See RAG explained for the pipeline.

Sources and further reading

  1. IICTP. Local LLM Practitioner credential page. iictp.org/certifications/llmp.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>Edge AI Inference Explained: Running Small Language Models on Devices | IICTPhttps://blogs.iictp.org/edge-ai-inference-slms-on-deviceshttps://blogs.iictp.org/edge-ai-inference-slms-on-devicesMon, 26 Oct 2026 09:00:00 GMTBlogIICTPEdge inference runs a model on or near the device that produces the data: a phone, a gateway, a vehicle, a factory machine. It cuts delay, reduces data sent over the network and keeps working when the connection drops.

Blog / Guides

Local LLMs26 October 20265 min read

Edge AI inference: small models on devices, offline and in real time

Edge inference runs a model on or near the device that produces the data: a phone, a gateway, a vehicle, a factory machine. It cuts delay, reduces data sent over the network and keeps working when the connection drops.

In this post
  1. Why run at the edge
  2. What you give up
  3. Making it fit
  4. Related reading
  5. Sources and further reading

Why run at the edge

  • Responses in real time, without a network round trip.
  • Sensitive data stays on the device.
  • Operation continues offline.
  • Less data sent upstream.

What you give up

  • Smaller models and less capability.
  • Limited memory, power and cooling.
  • Harder updates across many devices.

Making it fit

  • Use a small model suited to one task.
  • Quantize, and test the quality loss.
  • Use the device’s accelerator if its software supports it.
  • Plan updates, rollback and monitoring from the start.

See small language models explained and edge computing explained.

Sources and further reading

  1. IICTP. Local LLM Practitioner credential page. iictp.org/certifications/llmp.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>Multi-Cloud Architecture: Patterns That Work and Lock-In Traps to Avoid | IICTPhttps://blogs.iictp.org/multi-cloud-architecture-patterns-and-lock-inhttps://blogs.iictp.org/multi-cloud-architecture-patterns-and-lock-inMon, 26 Oct 2026 09:00:00 GMTBlogIICTPUsing more than one cloud provider can improve resilience, meet regional rules or use a strength of one provider. It also multiplies complexity. Decide why you want it before deciding how.

Blog / Guides

Cloud26 October 20266 min read

Multi-cloud architecture: patterns that work and lock-in traps

Using more than one cloud provider can improve resilience, meet regional rules or use a strength of one provider. It also multiplies complexity. Decide why you want it before deciding how.

In this post
  1. Reasons that hold up
  2. Patterns
  3. Lock-in traps
  4. A decision test
  5. Sources and further reading

Reasons that hold up

  • A regulator or customer requires a particular provider or region.
  • One provider offers a service you genuinely need.
  • An acquisition left you with two clouds.
  • You want a real exit option for a critical workload.

Patterns

  • Workload per cloud: each application runs on one cloud, chosen for fit. Simple, and the most common.
  • Portable core: containers and open standards for the parts you may move.
  • Active-passive recovery: a second cloud holds backups or a standby.

Lock-in traps

  • Building on a proprietary service without an exit plan.
  • Data that is cheap to enter and costly to leave.
  • Team skills spread too thin across providers.
  • Treating “portable” as free; abstraction layers have a cost too.

A decision test

For each dependency, ask what it would cost and how long it would take to replace. Accept lock-in knowingly where the benefit is high, and avoid it where the exit cost is out of proportion.

Sources and further reading

  1. IICTP. Cloud Architecture Practitioner credential page. iictp.org/certifications/cap.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>FinOps for Engineers: Cloud Cost Optimization Without Cutting Corners | IICTPhttps://blogs.iictp.org/finops-for-engineers-cloud-cost-optimizationhttps://blogs.iictp.org/finops-for-engineers-cloud-cost-optimizationMon, 26 Oct 2026 09:00:00 GMTBlogIICTPFinOps is the practice of making cloud spending visible and shared between engineering, finance and the business. For engineers, it means treating cost as a design property alongside performance and reliability.

Blog / Guides

Cloud26 October 20266 min read

FinOps for engineers: how to cut cloud cost without cutting corners

FinOps is the practice of making cloud spending visible and shared between engineering, finance and the business. For engineers, it means treating cost as a design property alongside performance and reliability.

In this post
  1. Visibility first
  2. Common savings
  3. What not to cut
  4. Make it a habit
  5. Sources and further reading

Visibility first

  • Tag resources by team, service and environment.
  • Report cost per team and per product, not one big bill.
  • Show engineers the cost of what they run.

Common savings

  • Right-size over-provisioned instances and databases.
  • Switch off idle and non-production environments out of hours.
  • Commit to steady usage through the provider’s discount schemes, only for load you are sure of.
  • Choose storage tiers that match access patterns.
  • Delete orphaned disks, snapshots and old data.

What not to cut

Cost cuts that remove backups, redundancy or monitoring save money until the day they matter. Weigh each saving against the risk it adds.

Make it a habit

  1. Review spend regularly with the people who control it.
  2. Set budgets and alerts.
  3. Track unit cost, such as cost per customer or per request, not only the total.
  4. Review commitments before they renew.

Sources and further reading

  1. FinOps Foundation. What is FinOps. finops.org/introduction/what-is-finops/.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>Kubernetes Cost Allocation: How to Find Which Team Spent What | IICTPhttps://blogs.iictp.org/kubernetes-cost-allocationhttps://blogs.iictp.org/kubernetes-cost-allocationMon, 26 Oct 2026 09:00:00 GMTBlogIICTPA Kubernetes cluster is a shared pool, so the cloud bill does not say which team or product caused it. Allocation means attributing the cluster’s cost back to its users in a way people accept.

Blog / Guides

Cloud26 October 20265 min read

Kubernetes cost allocation: finding which team spent what

A Kubernetes cluster is a shared pool, so the cloud bill does not say which team or product caused it. Allocation means attributing the cluster’s cost back to its users in a way people accept.

In this post
  1. The basics
  2. The pitfalls
  3. Use the numbers
  4. Sources and further reading

The basics

  • Label every workload with team, service and environment, and enforce it at admission.
  • Attribute cost by the resources each pod requests, and compare it to what it actually uses.
  • Share the cost of common services, such as the control plane and ingress, by an agreed rule.

The pitfalls

  • Unlabelled workloads pile up in an “unallocated” bucket.
  • Requests set far above real use waste capacity for everyone.
  • Idle capacity has to belong to someone.

Use the numbers

  1. Show each team its own cost.
  2. Flag the largest gaps between requested and used resources.
  3. Set requests from measured use.
  4. Review after each change.

Sources and further reading

  1. Kubernetes documentation. Resource management for pods and containers. kubernetes.io/docs.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>Cloud Landing Zones and Infrastructure as Code: Terraform, Policy-as-Code and Guardrails | IICTPhttps://blogs.iictp.org/cloud-landing-zones-and-infrastructure-as-codehttps://blogs.iictp.org/cloud-landing-zones-and-infrastructure-as-codeMon, 26 Oct 2026 09:00:00 GMTBlogIICTPA landing zone is the prepared foundation for an organisation’s cloud accounts: structure, identity, networking, logging and security baselines set up before teams start deploying. Infrastructure as code keeps it repeatable.

Blog / Guides

Cloud26 October 20266 min read

Cloud landing zones and IaC: Terraform, policy-as-code and guardrails

A landing zone is the prepared foundation for an organisation’s cloud accounts: structure, identity, networking, logging and security baselines set up before teams start deploying. Infrastructure as code keeps it repeatable.

In this post
  1. What a landing zone sets up
  2. Why code
  3. Guardrails, not gates
  4. Starting out
  5. Sources and further reading

What a landing zone sets up

  • Account or subscription structure, mapped to teams and environments.
  • Central identity and least-privilege access.
  • Network layout and connectivity.
  • Logging, audit trails and monitoring from day one.
  • Baseline security settings.

Why code

Describing the environment in code, for example with Terraform, makes changes reviewable, repeatable and reversible. It also removes the drift that builds up when people change things by hand.

Guardrails, not gates

Policy as code checks changes against rules automatically: no public storage by default, required tags, approved regions. Teams get fast feedback and a clear reason, instead of waiting for a manual review.

Starting out

  1. Start with the smallest baseline that is safe.
  2. Put it under version control and review changes.
  3. Add policies as you find real risks.
  4. Test changes in a non-production environment first.

Sources and further reading

  1. HashiCorp. Terraform documentation. developer.hashicorp.com/terraform.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>Running AI Workloads on Kubernetes: GPU Scheduling and Inference Cost | IICTPhttps://blogs.iictp.org/running-ai-workloads-on-kuberneteshttps://blogs.iictp.org/running-ai-workloads-on-kubernetesMon, 26 Oct 2026 09:00:00 GMTBlogIICTPKubernetes can run model training and inference alongside other services, but GPUs behave differently from CPU and memory, and mistakes with them are expensive.

Blog / Guides

Cloud26 October 20265 min read

Running AI workloads on Kubernetes: GPU scheduling and inference cost

Kubernetes can run model training and inference alongside other services, but GPUs behave differently from CPU and memory, and mistakes with them are expensive.

In this post
  1. GPUs in a cluster
  2. Inference specifics
  3. Controlling cost
  4. Sources and further reading

GPUs in a cluster

  • GPUs are exposed to pods as a resource through a device plugin.
  • A GPU is usually assigned whole to one pod unless sharing is set up.
  • Nodes with GPUs should be tainted so that ordinary workloads do not land on them.

Inference specifics

  • Models are large; loading time affects start-up, so plan scaling carefully.
  • Batching requests raises GPU use but adds delay.
  • Scale on a signal that reflects load, such as queue depth or request rate.

Controlling cost

  • Use the smallest GPU that meets your latency target.
  • Scale to zero where start-up time allows.
  • Watch utilisation; an idle GPU is the costliest waste.

Sources and further reading

  1. Kubernetes documentation. Schedule GPUs. kubernetes.io/docs/tasks/manage-gpus/scheduling-gpus/.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>Serverless vs Containers: How to Choose (Cost, Control and Operations) | IICTPhttps://blogs.iictp.org/serverless-vs-containershttps://blogs.iictp.org/serverless-vs-containersMon, 26 Oct 2026 09:00:00 GMTBlogIICTPServerless and containers are two ways to run code without managing physical servers. They trade control for convenience in different amounts.

Blog / Guides

Cloud26 October 20265 min read

Serverless vs containers: a cost-and-control comparison

Serverless and containers are two ways to run code without managing physical servers. They trade control for convenience in different amounts.

In this post
  1. Serverless functions
  2. Containers
  3. How to choose
  4. It is not either/or
  5. Sources and further reading

Serverless functions

  • You supply code; the provider runs it on demand and scales it, including to zero.
  • You pay for use, which suits spiky or occasional load.
  • Limits on run time, memory and start-up latency apply.

Containers

  • You package the application with its dependencies and run it on a platform you configure.
  • More control over runtime, networking and long-running work.
  • More to operate, and you pay for capacity while it runs.

How to choose

  1. Short, event-driven, spiky work leans towards serverless.
  2. Steady, long-running or specialised work leans towards containers.
  3. Check limits and start-up behaviour against your latency needs.
  4. Estimate cost at your real volume before deciding.

It is not either/or

Many systems use both. Pick per workload, and keep the boundaries clean so you can move one later.

Sources and further reading

  1. IICTP. Cloud Architecture Practitioner credential page. iictp.org/certifications/cap.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>What Is Platform Engineering? Why Teams Build Internal Platforms | IICTPhttps://blogs.iictp.org/what-is-platform-engineeringhttps://blogs.iictp.org/what-is-platform-engineeringMon, 26 Oct 2026 09:00:00 GMTBlogIICTPPlatform engineering builds the shared tools and paved roads that product teams use to ship software. The aim is that a team can create, deploy and run a service without becoming experts in every layer underneath it.

Blog / Guides

Delivery26 October 20266 min read

Platform engineering explained: why it is replacing the DevOps team

Platform engineering builds the shared tools and paved roads that product teams use to ship software. The aim is that a team can create, deploy and run a service without becoming experts in every layer underneath it.

In this post
  1. The problem it answers
  2. What a platform team provides
  3. How it differs from a DevOps team
  4. Making it work
  5. Sources and further reading

The problem it answers

When every team assembles its own pipelines, infrastructure and monitoring, the cognitive load is high and the results are inconsistent. A platform removes the repeated work and puts good defaults in one place.

What a platform team provides

  • Self-service creation of services, environments and pipelines.
  • Standard, secure and observable defaults.
  • Documentation and support for the people who use it.

How it differs from a DevOps team

DevOps is a way of working that joins development and operations. A platform team is a team that builds a product for developers. The two fit together: the platform makes the DevOps practices easy to follow.

Making it work

  • Treat developers as customers and ask them what slows them down.
  • Make the right path the easiest path, rather than mandating it.
  • Measure whether teams actually use it and ship faster.

Sources and further reading

  1. CNCF Platforms White Paper. tag-app-delivery.cncf.io/whitepapers/platforms/.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>DORA Metrics Explained: The Four Software Delivery Measures | IICTPhttps://blogs.iictp.org/dora-metrics-explainedhttps://blogs.iictp.org/dora-metrics-explainedMon, 26 Oct 2026 09:00:00 GMTBlogIICTPThe DORA research programme identified a small set of measures that describe how well a team delivers software: two for speed and two for stability. They are useful as a conversation starter, and harmful when used as targets to rank people.

Blog / Guides

Delivery26 October 20265 min read

DORA metrics explained: the four measures of software delivery

The DORA research programme identified a small set of measures that describe how well a team delivers software: two for speed and two for stability. They are useful as a conversation starter, and harmful when used as targets to rank people.

In this post
  1. The four measures
  2. What they tell you
  3. Using them well
  4. Improving them
  5. Sources and further reading

The four measures

  • Deployment frequency: how often you deploy to production.
  • Lead time for changes: how long a change takes from commit to production.
  • Change failure rate: the share of deployments that cause a failure needing a fix.
  • Time to restore service: how long it takes to recover from a failure.

What they tell you

Speed and stability tend to move together in strong teams, which is why small, frequent, well-tested changes work. The measures show where the pipeline is slow or fragile.

Using them well

  • Measure per service or team to find bottlenecks, not to compare people.
  • Look at trends, not single readings.
  • Pair them with how the team feels about its work.
  • Beware gaming: a number made into a target stops measuring what it did.

Improving them

Shorten feedback loops, automate tests and deployment, keep changes small and practise recovery. See speed and stability are not a trade-off.

Sources and further reading

  1. DORA. Software delivery performance metrics. dora.dev/guides/dora-metrics.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>Internal Developer Platforms Explained: Golden Paths, Self-Service and Backstage | IICTPhttps://blogs.iictp.org/internal-developer-platforms-golden-pathshttps://blogs.iictp.org/internal-developer-platforms-golden-pathsMon, 26 Oct 2026 09:00:00 GMTBlogIICTPAn internal developer platform (IDP) is the set of tools and workflows a company offers its developers so they can build and run services with little friction. The user-facing part is often a developer portal.

Blog / Guides

Delivery26 October 20265 min read

Internal developer platforms: golden paths, self-service and Backstage

An internal developer platform (IDP) is the set of tools and workflows a company offers its developers so they can build and run services with little friction. The user-facing part is often a developer portal.

In this post
  1. Golden paths
  2. Self-service
  3. The portal
  4. Pitfalls
  5. Sources and further reading

Golden paths

A golden path is a well-supported way of doing a common task, such as creating a new service with a pipeline, monitoring and security checks already in place. Teams can leave the path, but the path is the easiest option.

Self-service

Developers should be able to create what they need without raising a ticket and waiting. Guardrails in the platform, rather than approval queues, keep this safe.

The portal

Backstage, an open-source framework originally from Spotify and now part of the CNCF, is a common basis for a developer portal: a catalogue of services, templates for new ones and links to documentation.

Pitfalls

  • Building a portal before there is anything worth putting in it.
  • A platform nobody asked for.
  • Mandating use rather than earning it.

Sources and further reading

  1. Backstage. backstage.io.
  2. CNCF Platforms White Paper. tag-app-delivery.cncf.io/whitepapers/platforms/.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>Developer Experience (DevEx) and the SPACE Framework Explained Practically | IICTPhttps://blogs.iictp.org/developer-experience-and-the-space-frameworkhttps://blogs.iictp.org/developer-experience-and-the-space-frameworkMon, 26 Oct 2026 09:00:00 GMTBlogIICTPDeveloper experience (DevEx) is how it feels to do development work in your organisation: how quickly feedback arrives, how clear the work is and how much gets in the way. The SPACE framework offers a way to measure productivity without reducing it to one number.

Blog / Guides

Delivery26 October 20265 min read

Developer experience and the SPACE framework, practically

Developer experience (DevEx) is how it feels to do development work in your organisation: how quickly feedback arrives, how clear the work is and how much gets in the way. The SPACE framework offers a way to measure productivity without reducing it to one number.

In this post
  1. The five dimensions of SPACE
  2. The key idea
  3. Practical steps
  4. What to avoid
  5. Sources and further reading

The five dimensions of SPACE

  • Satisfaction and well-being.
  • Performance: outcomes of the work.
  • Activity: counts of actions, such as commits or reviews.
  • Communication and collaboration.
  • Efficiency and flow: time without interruption or waiting.

The key idea

No single measure captures productivity. Use several across more than one dimension, and include what people say as well as what systems record.

Practical steps

  1. Ask developers what slows them down most.
  2. Measure waiting: builds, reviews, environment provisioning.
  3. Fix the biggest friction first.
  4. Re-measure and share the result.

What to avoid

Using activity counts, such as lines of code or commits, to judge individuals. They are easy to count and misleading to read.

Sources and further reading

  1. Forsgren et al. “The SPACE of Developer Productivity.” ACM Queue, 2021.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>GitOps Explained: Argo CD, Flux and Policy-as-Code in Practice | IICTPhttps://blogs.iictp.org/gitops-in-practicehttps://blogs.iictp.org/gitops-in-practiceMon, 26 Oct 2026 09:00:00 GMTBlogIICTPGitOps keeps the desired state of a system in Git and uses an automated agent to make the real system match it. Changes happen by pull request, and the history of Git becomes the audit trail.

Blog / Guides

Delivery26 October 20265 min read

GitOps in practice: Argo CD, Flux and policy-as-code

GitOps keeps the desired state of a system in Git and uses an automated agent to make the real system match it. Changes happen by pull request, and the history of Git becomes the audit trail.

In this post
  1. The principles
  2. The tools
  3. Benefits
  4. Adding policy
  5. Sources and further reading

The principles

  • The desired state is declared, for example as Kubernetes manifests.
  • It is stored in Git and versioned.
  • An agent in the cluster pulls changes and applies them.
  • The agent keeps correcting drift.

The tools

Argo CD and Flux are two widely used CNCF projects that do this for Kubernetes. They watch a repository and reconcile the cluster with it.

Benefits

  • Every change is reviewed and recorded.
  • Rollback is a revert.
  • Rebuilding an environment is repeatable.

Adding policy

Policy-as-code tools check changes against rules before they are applied, for example blocking images from unapproved registries. Keep secrets out of Git, and use a secrets manager instead.

Sources and further reading

  1. OpenGitOps. GitOps Principles. opengitops.dev.
  2. Argo CD. argo-cd.readthedocs.io.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>Platform as a Product: How to Treat Developers as Customers | IICTPhttps://blogs.iictp.org/platform-as-a-producthttps://blogs.iictp.org/platform-as-a-productMon, 26 Oct 2026 09:00:00 GMTBlogIICTPInternal platforms fail most often because nobody uses them. Treating the platform as a product, with customers, a roadmap and feedback, is the usual remedy.

Blog / Guides

Delivery26 October 20264 min read

Platform as a product: treating developers as customers

Internal platforms fail most often because nobody uses them. Treating the platform as a product, with customers, a roadmap and feedback, is the usual remedy.

In this post
  1. What changes
  2. Product habits
  3. Warning signs
  4. Sources and further reading

What changes

  • You talk to your users regularly.
  • You have a roadmap based on their problems.
  • You measure adoption and satisfaction.
  • You support and document what you build.

Product habits

  • A named owner for the platform.
  • A short list of problems it will solve, and a longer list it will not.
  • Release notes and a way to ask for help.
  • The courage to retire features nobody uses.

Warning signs

  • Teams build workarounds instead of using it.
  • Support questions about the same things repeat.
  • Adoption only happens because it was mandated.

Sources and further reading

  1. CNCF Platforms White Paper. tag-app-delivery.cncf.io/whitepapers/platforms/.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>Engineering Governance Without Bureaucracy: Guardrails, Not Gates | IICTPhttps://blogs.iictp.org/engineering-governance-guardrails-not-gateshttps://blogs.iictp.org/engineering-governance-guardrails-not-gatesMon, 26 Oct 2026 09:00:00 GMTBlogIICTPGovernance exists to manage risk, not to slow work down. A gate stops everything until someone approves it. A guardrail lets work continue at speed but keeps it from going somewhere dangerous.

Blog / Guides

Delivery26 October 20265 min read

Engineering governance without bureaucracy: guardrails, not gates

Governance exists to manage risk, not to slow work down. A gate stops everything until someone approves it. A guardrail lets work continue at speed but keeps it from going somewhere dangerous.

In this post
  1. Gate or guardrail?
  2. What to automate
  3. Keep humans for the hard calls
  4. Test your governance
  5. Sources and further reading

Gate or guardrail?

  • Gate: a manual approval before every change. Slow, and people learn to route around it.
  • Guardrail: an automatic check built into the pipeline. Fast, consistent and visible.

What to automate

  • Security and licence scanning.
  • Required tests and reviews.
  • Infrastructure and configuration policies.
  • Records of who changed what, and when.

Keep humans for the hard calls

Reserve manual review for decisions that carry real risk and cannot be checked by a rule, such as a significant architecture change or a new type of data use.

Test your governance

If a rule has no owner, no stated purpose and no way to ask for an exception, remove it or fix it. Review rules on a schedule. See speed and stability are not a trade-off.

Sources and further reading

  1. IICTP. TPBOK, Engineering Governance & Agile Delivery. iictp.org/standards/tpbok.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>Edge Computing Explained: When to Process at the Edge vs the Cloud | IICTPhttps://blogs.iictp.org/edge-computing-explainedhttps://blogs.iictp.org/edge-computing-explainedMon, 26 Oct 2026 09:00:00 GMTBlogIICTPEdge computing processes data close to where it is produced instead of sending everything to a distant data centre. The question is rarely edge or cloud, but which work belongs where.

Blog / Guides

IoT & edge26 October 20265 min read

Edge computing explained: when to process at the edge and when in the cloud

Edge computing processes data close to where it is produced instead of sending everything to a distant data centre. The question is rarely edge or cloud, but which work belongs where.

In this post
  1. Reasons to process at the edge
  2. Reasons to use the cloud
  3. A common split
  4. Costs to plan for
  5. Sources and further reading

Reasons to process at the edge

  • Latency: a decision that must happen in milliseconds cannot wait for a round trip.
  • Bandwidth: sending raw video or sensor streams is costly; send results.
  • Resilience: the site keeps running if the link fails.
  • Privacy: keep raw data local.

Reasons to use the cloud

  • Large-scale storage and analytics across many sites.
  • Training models and fleet-wide reporting.
  • Easier management and elastic capacity.

A common split

Do the time-critical work and first filtering at the edge, and send summaries and exceptions to the cloud. Design for disconnected operation, and for catching up when the link returns.

Costs to plan for

More sites mean more hardware to install, secure, monitor and update. Count that operational load before choosing the edge.

Sources and further reading

  1. IICTP. IoT & Embedded Systems Practitioner credential page. iictp.org/certifications/iesp.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>IoT Security Best Practices: Common Failures and How to Avoid Them | IICTPhttps://blogs.iictp.org/iot-security-best-practiceshttps://blogs.iictp.org/iot-security-best-practicesMon, 26 Oct 2026 09:00:00 GMTBlogIICTPConnected devices are hard to secure: they are numerous, long-lived, physically exposed and often hard to update. These are common failures and the habits that prevent them.

Blog / Guides

IoT & edge26 October 20266 min read

IoT security: ten failures that lead to real breaches, and how to avoid them

Connected devices are hard to secure: they are numerous, long-lived, physically exposed and often hard to update. These are common failures and the habits that prevent them.

In this post
  1. Ten failures to design out
  2. What to do instead
  3. Standards to read
  4. Sources and further reading

Ten failures to design out

  1. Default or shared passwords.
  2. No way to update firmware, or updates that are not signed.
  3. Services left open that the device does not need.
  4. Unencrypted communication.
  5. Secrets and keys stored in plain text on the device.
  6. No device identity, so a fake device can join.
  7. Flat networks where one compromised device reaches everything.
  8. No logging or alerting from the fleet.
  9. No plan for end of life, so old devices stay online unpatched.
  10. Security treated as a launch task rather than a lifecycle one.

What to do instead

  • Give every device a unique identity and credentials.
  • Sign firmware and verify it at boot.
  • Segment networks and allow only what is needed.
  • Encrypt data in transit and at rest.
  • Monitor the fleet and be ready to revoke a device.

Standards to read

ETSI EN 303 645 and the OWASP IoT guidance set out baseline practices for consumer and general IoT.

Sources and further reading

  1. ETSI EN 303 645. Cyber Security for Consumer Internet of Things. etsi.org.
  2. OWASP. Internet of Things Project. owasp.org/www-project-internet-of-things/.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>OTA Firmware Updates Done Right: Safe Delivery to Devices at Scale | IICTPhttps://blogs.iictp.org/ota-firmware-updates-done-righthttps://blogs.iictp.org/ota-firmware-updates-done-rightMon, 26 Oct 2026 09:00:00 GMTBlogIICTPOver-the-air (OTA) updates let you fix and improve devices after they ship. They are also the most dangerous thing you do to a fleet: a bad update can brick thousands of devices at once.

Blog / Guides

IoT & edge26 October 20265 min read

OTA updates done right: safe firmware delivery at scale

Over-the-air (OTA) updates let you fix and improve devices after they ship. They are also the most dangerous thing you do to a fleet: a bad update can brick thousands of devices at once.

In this post
  1. Requirements
  2. Rolling out
  3. Plan for the field
  4. Sources and further reading

Requirements

  • Signed images, verified by the device before use.
  • Rollback: keep the previous version and return to it if the new one fails.
  • Atomic updates, so a power cut mid-update cannot leave a half-written device.
  • Version checks, to stop downgrade attacks.

Rolling out

  1. Test on a bench and on a small internal group.
  2. Release to a small share of the fleet and watch health.
  3. Widen in stages; pause automatically on failures.
  4. Keep the ability to stop an update quickly.

Plan for the field

Devices have weak or intermittent links, low battery and limited storage. Make downloads resumable, schedule them for safe moments and report status back.

Sources and further reading

  1. IETF RFC 9019. A Firmware Update Architecture for Internet of Things. rfc-editor.org/rfc/rfc9019.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>Digital Twins and Predictive Maintenance in Manufacturing Explained | IICTPhttps://blogs.iictp.org/digital-twins-and-predictive-maintenancehttps://blogs.iictp.org/digital-twins-and-predictive-maintenanceMon, 26 Oct 2026 09:00:00 GMTBlogIICTPA digital twin is a software model of a physical asset, kept up to date with data from sensors. Predictive maintenance uses that data to spot when a machine is likely to fail, so it can be fixed on your schedule rather than the machine’s.

Blog / Guides

IoT & edge26 October 20265 min read

Digital twins in manufacturing: predictive maintenance that pays

A digital twin is a software model of a physical asset, kept up to date with data from sensors. Predictive maintenance uses that data to spot when a machine is likely to fail, so it can be fixed on your schedule rather than the machine’s.

In this post
  1. How it works
  2. What makes it pay
  3. Where it goes wrong
  4. Sources and further reading

How it works

  • Sensors report vibration, temperature, current and other signals.
  • The data flows to a model of the asset.
  • The model compares current behaviour with normal and with known failure patterns.
  • Maintenance is triggered by condition, not only by the calendar.

What makes it pay

  • Pick assets where failure is costly and gives warning.
  • Start with a clear failure mode and enough history to learn from.
  • Connect predictions to a maintenance process that acts on them.

Where it goes wrong

  • Not enough failure examples to learn from.
  • Alerts that nobody trusts because of false alarms.
  • A model with no owner, drifting as equipment and conditions change.

Sources and further reading

  1. ISO 23247 series. Digital twin framework for manufacturing. iso.org.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>MQTT vs HTTP vs CoAP: How to Choose an IoT Protocol | IICTPhttps://blogs.iictp.org/mqtt-vs-http-vs-coaphttps://blogs.iictp.org/mqtt-vs-http-vs-coapMon, 26 Oct 2026 09:00:00 GMTBlogIICTPThe right protocol depends on the device, the network and how data needs to flow. Here are the three you will meet most often.

Blog / Guides

IoT & edge26 October 20265 min read

MQTT vs HTTP vs CoAP: choosing an IoT protocol

The right protocol depends on the device, the network and how data needs to flow. Here are the three you will meet most often.

In this post
  1. MQTT
  2. HTTP
  3. CoAP
  4. Choosing
  5. Sources and further reading

MQTT

A lightweight publish/subscribe protocol that runs over TCP and routes messages through a broker. It offers three delivery levels (at most once, at least once, exactly once) and suits many devices sending small messages on unreliable links.

HTTP

The web’s request/response protocol. Universally supported and easy to debug, but heavier for tiny devices and not designed for pushing messages to them.

CoAP

A protocol modelled on HTTP but built for constrained devices and networks, running over UDP. It keeps the familiar request/response style with a much smaller footprint.

Choosing

  1. Many devices, small frequent messages, need to push to devices: MQTT.
  2. Existing web infrastructure and larger, less frequent exchanges: HTTP.
  3. Very constrained devices and lossy networks: CoAP.
  4. Whichever you choose, secure it with TLS or DTLS and authenticate devices.

Sources and further reading

  1. OASIS. MQTT Version 5.0. docs.oasis-open.org/mqtt/mqtt/v5.0/.
  2. IETF RFC 7252. The Constrained Application Protocol (CoAP). rfc-editor.org/rfc/rfc7252.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>TinyML Explained: Running Machine Learning Models on Microcontrollers | IICTPhttps://blogs.iictp.org/tinyml-embedded-aihttps://blogs.iictp.org/tinyml-embedded-aiMon, 26 Oct 2026 09:00:00 GMTBlogIICTPTinyML runs machine-learning models on microcontrollers with very little memory and power. It suits simple, always-on tasks such as detecting a keyword, a vibration pattern or an anomaly in a sensor stream.

Blog / Guides

IoT & edge26 October 20265 min read

Embedded AI and TinyML: running models on microcontrollers

TinyML runs machine-learning models on microcontrollers with very little memory and power. It suits simple, always-on tasks such as detecting a keyword, a vibration pattern or an anomaly in a sensor stream.

In this post
  1. Why do it
  2. Making a model fit
  3. Limits
  4. Sources and further reading

Why do it

  • Responds immediately, without a network.
  • Uses very little power, so it can run on a battery for a long time.
  • Raw data, such as audio, never leaves the device.

Making a model fit

  • Choose a small architecture for one narrow task.
  • Quantize the model to 8-bit integers.
  • Convert it with a runtime built for microcontrollers, such as TensorFlow Lite for Microcontrollers.
  • Measure memory, speed and energy on the real chip.

Limits

Models are small and capabilities limited. Updating them in the field is harder than updating a cloud service, so plan for it. Test on the real sensor data and in the real environment, since a model can behave differently away from the lab.

Sources and further reading

  1. TensorFlow Lite for Microcontrollers. tensorflow.org/lite/microcontrollers.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>OpenTelemetry Explained: One Open Standard for Traces, Metrics and Logs | IICTPhttps://blogs.iictp.org/opentelemetry-explainedhttps://blogs.iictp.org/opentelemetry-explainedMon, 26 Oct 2026 09:00:00 GMTBlogIICTPOpenTelemetry (OTel) is an open-source, vendor-neutral set of APIs, SDKs and tools for producing and exporting telemetry. It is a project of the Cloud Native Computing Foundation. Instrument once, and send the data to the backend you choose.

Blog / Guides

Telemetry26 October 20266 min read

OpenTelemetry explained: one standard for traces, metrics and logs

OpenTelemetry (OTel) is an open-source, vendor-neutral set of APIs, SDKs and tools for producing and exporting telemetry. It is a project of the Cloud Native Computing Foundation. Instrument once, and send the data to the backend you choose.

In this post
  1. The three signals
  2. The pieces
  3. Why it matters
  4. Getting started
  5. Sources and further reading

The three signals

  • Traces: the path of one request through many services.
  • Metrics: numbers over time, such as request rate or error rate.
  • Logs: records of events.

The pieces

  • APIs and SDKs for your language, to create telemetry in code.
  • Auto-instrumentation for common libraries.
  • OTLP, the protocol for sending telemetry.
  • The Collector, a service that receives, processes and forwards telemetry to one or more backends.

Why it matters

Because the instrumentation is standard, switching or adding a backend does not mean re-instrumenting every service. That lowers lock-in and makes consistent telemetry across teams realistic.

Getting started

  1. Pick one service and add auto-instrumentation.
  2. Run a Collector and send data to a backend.
  3. Add custom spans for your key business operations.
  4. Agree naming conventions across teams.

Sources and further reading

  1. OpenTelemetry. What is OpenTelemetry? opentelemetry.io/docs/what-is-opentelemetry/.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>Observability Cost Reduction: Cut Telemetry Spend Without Losing Visibility | IICTPhttps://blogs.iictp.org/observability-cost-reductionhttps://blogs.iictp.org/observability-cost-reductionMon, 26 Oct 2026 09:00:00 GMTBlogIICTPTelemetry grows faster than the system it describes unless someone manages it. The goal is not to collect less for its own sake, but to keep the data that helps you make decisions and drop the rest.

Blog / Guides

Telemetry26 October 20265 min read

Observability costs too much: how teams cut telemetry spend without going blind

Telemetry grows faster than the system it describes unless someone manages it. The goal is not to collect less for its own sake, but to keep the data that helps you make decisions and drop the rest.

In this post
  1. Where the money goes
  2. Practical levers
  3. Stay safe
  4. Sources and further reading

Where the money goes

  • High-volume, low-value logs.
  • Metrics with high-cardinality labels, which multiply the number of series.
  • Traces kept at full detail for every request.
  • Data kept for longer than anyone looks at it.

Practical levers

  • Sampling: keep all errors and slow traces, and a share of the rest.
  • Filtering at the Collector: drop noisy events before they are stored.
  • Cardinality control: avoid unbounded values, such as user IDs, in metric labels.
  • Tiered retention: keep recent data hot and older data cheap.

Stay safe

  1. Decide what questions you need telemetry to answer.
  2. Measure how often each source is actually used.
  3. Cut the unused first and watch for gaps.
  4. Review costs per team, regularly.

Sources and further reading

  1. OpenTelemetry. Sampling. opentelemetry.io/docs/concepts/sampling/.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>Green Software Explained: Measuring Software Carbon Intensity (SCI) in Practice | IICTPhttps://blogs.iictp.org/green-software-and-software-carbon-intensityhttps://blogs.iictp.org/green-software-and-software-carbon-intensityMon, 26 Oct 2026 09:00:00 GMTBlogIICTPSoftware uses electricity, and the electricity has a carbon cost that varies with where and when it is used. Green software engineering aims to deliver the same value with less energy and a cleaner energy supply.

Blog / Guides

Telemetry26 October 20266 min read

Green software: measuring software carbon intensity in practice

Software uses electricity, and the electricity has a carbon cost that varies with where and when it is used. Green software engineering aims to deliver the same value with less energy and a cleaner energy supply.

In this post
  1. The Software Carbon Intensity specification
  2. Three levers
  3. Start measuring
  4. A note on honesty
  5. Sources and further reading

The Software Carbon Intensity specification

The Green Software Foundation’s SCI specification gives a rate of carbon emitted per functional unit, such as per user, per request or per transaction. It counts the energy the software uses, the carbon intensity of that energy and the hardware’s embodied emissions, so progress can be compared over time.

Three levers

  • Use less energy: efficient code, right-sized servers, no idle resources.
  • Use cleaner energy: run flexible work in regions or at times when the grid is cleaner.
  • Use less hardware: longer life and higher utilisation reduce embodied emissions.

Start measuring

  1. Pick a functional unit that fits your product.
  2. Gather energy or resource use from your platform.
  3. Apply the carbon intensity of the grid you use.
  4. Track the rate and look for the largest contributors.

A note on honesty

Measurements are estimates. Say how you calculated them, and avoid claims you cannot support.

Sources and further reading

  1. Green Software Foundation. Software Carbon Intensity (SCI) Specification. sci.greensoftware.foundation.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>Carbon as an SLO: Adding Emissions to Your Observability Stack (GreenOps) | IICTPhttps://blogs.iictp.org/carbon-as-an-slohttps://blogs.iictp.org/carbon-as-an-sloMon, 26 Oct 2026 09:00:00 GMTBlogIICTPTeams already track reliability with service-level objectives. The same habit can apply to carbon: set a target, measure it with the rest of your telemetry and treat a regression as a defect.

Blog / Guides

Telemetry26 October 20265 min read

Carbon as an SLO: adding emissions to your observability stack

Teams already track reliability with service-level objectives. The same habit can apply to carbon: set a target, measure it with the rest of your telemetry and treat a regression as a defect.

In this post
  1. What it looks like
  2. Joined-up with cost
  3. How to start
  4. Sources and further reading

What it looks like

  • A carbon-per-unit measure, calculated from resource use and grid intensity.
  • A target for each service, reviewed as part of the normal cycle.
  • Dashboards that show it next to latency and cost.

Joined-up with cost

Energy and cloud cost are closely linked, so many efficiency changes help both. Where they diverge, make the trade-off visible rather than optimising one in secret.

How to start

  1. Choose one service and one carbon measure.
  2. Add it to the existing dashboard.
  3. Set a modest target and watch for a quarter.
  4. Add it to design reviews for new work.

Sources and further reading

  1. Green Software Foundation. Software Carbon Intensity (SCI) Specification. sci.greensoftware.foundation.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>LLM Observability: How to Trace LLM Calls, Track Tokens and Spot Drift | IICTPhttps://blogs.iictp.org/observability-for-ai-systemshttps://blogs.iictp.org/observability-for-ai-systemsMon, 26 Oct 2026 09:00:00 GMTBlogIICTPA language-model application fails in ways ordinary monitoring does not see: the service is up and fast, yet the answers are poor. Observability for AI adds visibility of what went in, what came out and what it cost.

Blog / Guides

Telemetry26 October 20265 min read

Observability for AI systems: tracing LLM calls, tokens and drift

A language-model application fails in ways ordinary monitoring does not see: the service is up and fast, yet the answers are poor. Observability for AI adds visibility of what went in, what came out and what it cost.

In this post
  1. What to trace
  2. What to measure
  3. Privacy
  4. Sources and further reading

What to trace

  • Each model call: model, settings, latency and token counts.
  • Retrieval steps: what was fetched and how relevant it was.
  • Tool calls and their results.
  • The full chain for one user request, as a single trace.

What to measure

  • Cost per request and per feature.
  • Quality signals: feedback, retries, refusals, evaluation scores.
  • Drift: quality changing after a model, prompt or data change.

Privacy

Prompts and outputs can contain personal data. Decide what to store, mask sensitive fields and limit access and retention. OpenTelemetry has emerging conventions for generative-AI telemetry; check their current status before depending on them.

Sources and further reading

  1. OpenTelemetry. Semantic conventions for generative AI. opentelemetry.io/docs/specs/semconv/gen-ai/.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>Clean Telemetry: Sampling, Filtering and Collecting High-Signal Data | IICTPhttps://blogs.iictp.org/clean-telemetry-sampling-and-filteringhttps://blogs.iictp.org/clean-telemetry-sampling-and-filteringMon, 26 Oct 2026 09:00:00 GMTBlogIICTPMore data is not more insight. Clean telemetry means each signal is there for a reason, is consistent across services and can be trusted when something goes wrong.

Blog / Guides

Telemetry26 October 20265 min read

Clean telemetry: sampling, filtering and high-signal data

More data is not more insight. Clean telemetry means each signal is there for a reason, is consistent across services and can be trusted when something goes wrong.

In this post
  1. Principles
  2. Techniques
  3. Keep it clean
  4. Sources and further reading

Principles

  • Purpose: every signal answers a question someone asks.
  • Consistency: the same names, units and labels across services.
  • Context: traces linked to logs and metrics through shared identifiers.
  • Restraint: drop what is never used.

Techniques

  • Head sampling decides at the start of a trace; tail sampling decides once the trace is complete and can keep errors and slow requests.
  • Filtering and redaction in the Collector remove noise and sensitive data.
  • Structured logs with stable fields are easier to search and cheaper to store.

Keep it clean

  1. Write down the telemetry standard and share it.
  2. Review new instrumentation like new code.
  3. Check periodically which data is used.
  4. Remove what is not.

Sources and further reading

  1. OpenTelemetry. Sampling. opentelemetry.io/docs/concepts/sampling/.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>System Design Interview Guide: A Framework Senior Engineers Use | IICTPhttps://blogs.iictp.org/system-design-interview-frameworkhttps://blogs.iictp.org/system-design-interview-frameworkMon, 26 Oct 2026 09:00:00 GMTBlogIICTPA system design interview asks you to design something open-ended in under an hour. The interviewer is watching how you think, not whether you reach a particular diagram. A repeatable framework keeps you calm and on track.

Blog / Guides

Architecture26 October 20267 min read

System design interviews: a framework senior engineers use

A system design interview asks you to design something open-ended in under an hour. The interviewer is watching how you think, not whether you reach a particular diagram. A repeatable framework keeps you calm and on track.

In this post
  1. The framework
  2. What interviewers look for
  3. Common mistakes
  4. Practise
  5. Sources and further reading

The framework

  1. Clarify. Ask what the system must do, for whom and at what scale. State your assumptions.
  2. Define the interface. Sketch the main operations and the data they use.
  3. Draw the simple version. One box, one database. Make it work first.
  4. Find the bottleneck. Where does it break as load grows? Data size, writes, hot keys, latency?
  5. Evolve the design. Add caching, partitioning, queues or replication, each in answer to a named problem.
  6. Discuss trade-offs and failures. What does each choice cost, and what happens when a part fails?

What interviewers look for

  • Questions before answers.
  • Reasoning about trade-offs, not name-dropping technologies.
  • Awareness of failure, cost and operations.
  • Clear communication and willingness to change course.

Common mistakes

  • Starting with a complex diagram.
  • Adding components with no stated reason.
  • Ignoring data consistency and failure.
  • Not checking the design against the requirements at the end.

Practise

Design systems you already use, out loud, with a friend. Write down what you would change after the first user and after the thousandth. See architecture decisions are expensive to undo.

Sources and further reading

  1. IICTP. TPBOK, Architecture & Systems Design. iictp.org/standards/tpbok.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>Tech Lead vs Engineering Manager vs Architect: Which Path Fits You? | IICTPhttps://blogs.iictp.org/tech-lead-vs-engineering-manager-vs-architecthttps://blogs.iictp.org/tech-lead-vs-engineering-manager-vs-architectMon, 26 Oct 2026 09:00:00 GMTBlogIICTPThree roles are often confused because they overlap. Each is a different kind of work, and picking one is mostly about what you want to spend your days doing.

Blog / Guides

Leadership26 October 20265 min read

Tech lead vs engineering manager vs architect: which path fits you?

Three roles are often confused because they overlap. Each is a different kind of work, and picking one is mostly about what you want to spend your days doing.

In this post
  1. Tech lead
  2. Engineering manager
  3. Architect
  4. How to choose
  5. Sources and further reading

Tech lead

Guides the technical direction of one team, stays close to the code and unblocks colleagues. You still build, and you also set standards, review designs and help others grow.

Engineering manager

Is responsible for the people and the team’s results: hiring, feedback, careers, priorities and delivery. The work is conversations and decisions about people and process, more than code.

Architect

Is responsible for how systems fit together across teams: boundaries, standards and long-term technical decisions. The work is design, influence and communication more than direct delivery.

How to choose

  • Which problems do you enjoy: technical, people or system-wide?
  • Where do you find you add the most value?
  • Try a stretch: lead a project, mentor, or write a design that crosses teams.
  • Remember that moving between these paths is normal.

Sources and further reading

  1. IICTP. TPBOK, People Leadership in Engineering. iictp.org/standards/tpbok.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>Technical Debt Management: Measure It, Price It and Persuade Leadership | IICTPhttps://blogs.iictp.org/technical-debt-measure-price-persuadehttps://blogs.iictp.org/technical-debt-measure-price-persuadeMon, 26 Oct 2026 09:00:00 GMTBlogIICTPTechnical debt is the future cost of shortcuts taken today. It is not always bad: like financial debt, it can buy speed. The problem is unmanaged debt that nobody has priced.

Blog / Guides

Leadership26 October 20266 min read

Technical debt: how to measure it, price it and persuade leadership

Technical debt is the future cost of shortcuts taken today. It is not always bad: like financial debt, it can buy speed. The problem is unmanaged debt that nobody has priced.

In this post
  1. Make it visible
  2. Price it
  3. Persuade
  4. Pay it down steadily
  5. Sources and further reading

Make it visible

  • Keep a list of known debt, with the area and the pain it causes.
  • Record where the team loses time: slow builds, fragile modules, repeated incidents.
  • Link each item to a cost: delay, risk or both.

Price it

Express debt in terms a manager cares about: days lost per month, incidents caused, features delayed, risk of a serious failure. Estimates are rough, and that is acceptable as long as you say so.

Persuade

  1. Show the cost of leaving it, not the beauty of fixing it.
  2. Propose a small, specific change with a clear benefit.
  3. Tie it to a goal leadership already has.
  4. Report the result afterwards.

Pay it down steadily

Reserve a regular share of capacity and fix debt in the code you are already changing. Avoid the big rewrite unless the case is overwhelming and the plan is incremental.

Sources and further reading

  1. Cunningham, W. “The WyCash Portfolio Management System.” OOPSLA 1992.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>Technical Program and Portfolio Leadership: Running Many Initiatives at Once | IICTPhttps://blogs.iictp.org/program-and-portfolio-leadershiphttps://blogs.iictp.org/program-and-portfolio-leadershipMon, 26 Oct 2026 09:00:00 GMTBlogIICTPA programme is a group of related efforts managed together for a shared outcome. A portfolio is the set of programmes and projects an organisation chooses to fund. The skills change from managing work to managing choices.

Blog / Guides

Leadership26 October 20266 min read

Program and portfolio leadership: running many technical initiatives at once

A programme is a group of related efforts managed together for a shared outcome. A portfolio is the set of programmes and projects an organisation chooses to fund. The skills change from managing work to managing choices.

In this post
  1. Program-level questions
  2. Portfolio-level questions
  3. Habits that help
  4. Sources and further reading

Program-level questions

  • How do these efforts depend on one another?
  • Where are the shared risks and the shared resources?
  • What must be true for the outcome to be delivered?

Portfolio-level questions

  • Which initiatives are worth their cost, and which should stop?
  • Is the mix balanced between running the business and changing it?
  • Do we have the people to do it all?

Habits that help

  • One clear view of status, dependencies and risk.
  • Regular reviews that can end work, not only continue it.
  • Visible trade-offs when capacity is short.
  • Leaders who ask for early bad news.

Sources and further reading

  1. IICTP. Program Technical Practitioner credential page. iictp.org/certifications/pgtp.
  2. IICTP. Portfolio Technical Practitioner credential page. iictp.org/certifications/pftp.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>Build vs Buy Software in the AI Era: A Decision Framework for Leaders | IICTPhttps://blogs.iictp.org/build-vs-buy-in-the-ai-erahttps://blogs.iictp.org/build-vs-buy-in-the-ai-eraMon, 26 Oct 2026 09:00:00 GMTBlogIICTPBuild-or-buy has always been a question about what is core to your business. AI changes some of the costs, but not the logic.

Blog / Guides

Leadership26 October 20265 min read

Build vs buy in the AI era: a decision framework for leaders

Build-or-buy has always been a question about what is core to your business. AI changes some of the costs, but not the logic.

In this post
  1. Questions to ask
  2. What AI changes
  3. A middle path
  4. Sources and further reading

Questions to ask

  • Is it a differentiator? Build what sets you apart; buy what everyone needs.
  • Do we have the skills, and will we keep them?
  • What is the total cost, including running, updating and supporting it?
  • What is the exit? How hard is it to leave a vendor, or to hand over what you built?
  • What data is involved, and where may it go?

What AI changes

  • It lowers the cost of writing some code, but not of owning it.
  • It makes models, not just software, something you can buy.
  • It adds new ways to depend on a vendor: models, prompts and data.

A middle path

Buy the commodity layer, build the part that carries your logic and data, and keep the seam between them clean so either side can change.

Sources and further reading

  1. IICTP. Portfolio Technical Practitioner credential page. iictp.org/certifications/pftp.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>AI Governance for Leaders: How to Roll Out AI Without Chaos | IICTPhttps://blogs.iictp.org/ai-transformation-governance-for-leadershttps://blogs.iictp.org/ai-transformation-governance-for-leadersMon, 26 Oct 2026 09:00:00 GMTBlogIICTPTeams will adopt AI tools whether or not the organisation has a plan. Governance gives people a safe, clear way to do it, so the good uses spread and the risky ones are caught.

Blog / Guides

Leadership26 October 20266 min read

AI transformation governance: how leaders roll out AI without chaos

Teams will adopt AI tools whether or not the organisation has a plan. Governance gives people a safe, clear way to do it, so the good uses spread and the risky ones are caught.

In this post
  1. Start with a simple policy
  2. Assign accountability
  3. Manage risk in proportion
  4. Build capability
  5. Sources and further reading

Start with a simple policy

  • Which tools are approved and for what.
  • What data may and may not be entered.
  • What must be reviewed by a person before use.
  • Who to ask when unsure.

Assign accountability

Name an owner for AI use in the organisation and for each system that makes or informs a decision. Keep a list of where AI is used.

Manage risk in proportion

A drafting assistant and a system that decides on loan applications need different levels of control. Classify uses by impact and apply controls to match.

Build capability

  1. Train people on what the tools do and their failure modes.
  2. Share examples of good use.
  3. Collect incidents and near-misses and learn from them.
  4. Review the policy regularly as tools and rules change.

Sources and further reading

  1. NIST. AI Risk Management Framework (AI RMF 1.0). nist.gov/itl/ai-risk-management-framework.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>How to Verify a CTP Credential and Spot a Fake | IICTPhttps://blogs.iictp.org/how-to-verify-a-ctp-credentialhttps://blogs.iictp.org/how-to-verify-a-ctp-credentialMon, 26 Oct 2026 09:00:00 GMTBlogIICTPAnyone can write a credential on a CV. If you are hiring or working with someone who claims to hold an IICTP CTP®, here is how to check.

Blog / Guides

Verification26 October 20263 min read

How to verify a CTP credential, and spot a fake

Anyone can write a credential on a CV. If you are hiring or working with someone who claims to hold an IICTP CTP®, here is how to check.

In this post
  1. Check it yourself
  2. Warning signs
  3. What the registry does not tell you
  4. Sources and further reading

Check it yourself

  1. Ask for the holder’s name and credential ID.
  2. Go to the IICTP public registry by typing the address yourself.
  3. Search the record and compare the holder, credential and status with the claim.
  4. A credential that has lapsed or been withdrawn will show that in its status.

Warning signs

  • A certificate image that cannot be found in the registry.
  • A lookup page hosted anywhere other than iictp.org.
  • An ID format that does not match the registry’s.
  • Pressure to skip verification.

What the registry does not tell you

A record confirms that IICTP issued the credential. It does not tell you how well someone performs. IICTP is a new independent body and is not ISO/IEC 17024 accredited, so weigh the credential accordingly. See the registry policy.

Sources and further reading

  1. IICTP. Verify a credential. iictp.org/verify.
  2. IICTP. Registry policy. iictp.org/registry-policy.

IICTP is a new independent credential and is not ISO/IEC 17024 accredited.

Keep reading

← All posts

Where do you stand?

Find the credential that fits the work you do.

]]>