Terminology and alignment with other frameworks

This is an area where practitioners expressed different views, and several distinct strands emerged.

• Some contributors argued for stronger alignment with the terminology used in frameworks that many practitioners encounter daily, particularly ITIL and BABOK. They felt this could reduce friction and make SFIA easier to adopt within communities already working with those frameworks .
• Others argued for maintaining or even increasing SFIA’s distance from any single methodology. Their view was that SFIA’s scope is broader than frameworks like ITIL and that its value lies in being methodology agnostic .
• Beyond this central tension, contributors suggested providing explicit references to source materials within skill definitions, increasing the depth of descriptions to include methodologies and standards, and ensuring that Agile language is more visible where relevant .

How we will take these suggestions forward

• This question goes to the heart of how SFIA has been designed. SFIA describes professional accountability rather than the specific tools or methodologies through which that accountability is exercised. This is part of what enables SFIA to span sectors, geographies and ways of working .
• Strengthening alignment with particular frameworks could reduce friction for some communities but may limit SFIA’s reach in others .
• We will work through the suggestions with that balance in mind as we develop SFIA 10. Some ideas may lead to changes in how skills are described or where guidance points to source materials . Others will be explored alongside the Foundation’s broader thinking on SFIA’s position relative to other frameworks. Some may not be the right direction when considered against SFIA’s design principles .

In all cases we will be transparent about what we conclude and why, and will report back through this site as our thinking develops .

Related suggestions raised at SFIA 10 workshops.

Disclaimer: These suggestions reflect the personal views of individual workshop attendees. They are provided substantially verbatim and do not represent the official position or endorsement of the SFIA Foundation.

• Avoid alignment of SFIA with ITIL, on the grounds that ITIL is a methodology that not everyone uses and SFIA's scope is much wider
• ITIL language describing everything as a "service" causes confusion. Include broader terminology such as systems, systems-of-systems and services provided through the use of technology
• Will there be alignment in terminology with ITIL?
• Adopt ITIL 5 terminology such as Product, Service, Experience and Transformation
• Provide references to source materials in skill definitions, for example ITIL, COBIT, DAMA, and relevant ISO standards and guidelines. The collection need not be complete. A start could be made and improved through small changes to the live website version
• Align business analysis language more closely with the BABOK, without duplicating it. This could include explicitly referencing BABOK-style concepts such as needs, solutions, stakeholders and value, and providing a cross-walk for BA communities already using BABOK. Many BA communities already invest in BABOK-based skills models, and closer alignment would reduce friction and duplication between frameworks
• SFIA can feel too generic. Skill and level descriptions could include more depth, including methodologies, technologies, standards and frameworks relevant to each skill
• The absence of Agile terminology can cause resistance. Skills could use Agile language more explicitly