[Evaluation] Spec-Driven Development for Terraform/IaC on SAP BTP

[lechnerc77]

One major topic in the area of AI-supported development is the spec-driven development.

This ws initiated by GitHub and their Spec Kit (Docs) and has been taken up by several other initiatives like one by IBM targeting Infrastructure as code (IaC Spec Kit). But there are also other initiatives like OpenSpec or end2end tools like kiro.

The content of this issue is to investigate the options we have to integrate the Terraform offerings for SAP BTP into spec-driven development, to anable our customers and partners to make use of this AI-supported approach fpr setting up their infrastructure.

[lechnerc77]

First Analysis of spec-kit

spec-kit is a generic specification-driven development (SDD) toolkit for any software project. As such it is is domain-agnostic. Its templates, commands, and language address general software features — user scenarios, UI flows, data models, APIs, and business logic.

The phases of SDD are given by:

Command/Phase	Purpose
/speckit.constitution	Create project governing principles (Nine Articles of Development)
/speckit.specify	Generate feature specification
/speckit.clarify	Structured Q&A to resolve ambiguities
/speckit.plan	Create technical implementation plan
/speckit.analyze	Cross-artifact consistency analysis
/speckit.tasks	Break plan into actionable task list
/speckit.implement	Execute tasks to build the feature
/speckit.checklist	Generate quality checklists
/speckit.taskstoissues	Convert tasks to GitHub Issues

The content of the template markdown files (abc-template.md) are aligned with the phases targeting goals of software development in general.

One interesting aspect is that the spec-kit contains a well defined extension mechanism for enhancing the scope of the tool.

However, the flow is very generic targeting software projects. It is not a perfect fit for Infrastructure as Code (IaC) projects. Even via enhancements it might be difficult to cover IaC-specifics and ignore software specifc steps.

[cpf-hse]

@lechnerc77 have you checked https://github.com/IBM/iac-spec-kit?

[lechnerc77]

@lechnerc77 have you checked https://github.com/IBM/iac-spec-kit?

@cpf-hse You are a bit too fast: I just wanted to note the result of the first analysis of the IaC spec-kit as a comment :-)

[lechnerc77]

FIrst analysis of iac-spec-kit

iac-spec-kit is a specification-driven development (SDD) toolkit that specifically targets the domain of infrastructure-as-code (IaC). Itis based on GitHubs generic spec-kit but made some modifications to be a better fit for the IaC domain.

The phases of SDD in this kit are defined by:

Command	Purpose
/iac.principles	Establish cloud architecture and IaC code governance
/iac.specify	Create cloud-agnostic infrastructure specification
/iac.clarify	Resolve [NEEDS CLARIFICATION] markers
/iac.plan	Generate cloud-specific architecture plan
/iac.enrichplan	New: Deep research, Well-Architected analysis, module specs
/iac.tasks	Generate infrastructure-tier-ordered task list
/iac.implement	Generate IaC code files (does NOT deploy)
/iac.checklist	Generate security/compliance/cost/performance checklists
/iac.analyze	New: Analyze existing infrastructure for improvements

While several phases remain the same, there are some differences that were introduced improving the fit to IaC:

• constitution → renamed to principles with IaC-specific content (architecture principles + code standards)
• taskstoissues → removed (no GitHub Issues integration)
• /iac.enrichplan added — a distinct deep-research phase producing research.md, architecture.md, modules.md, and quickstart.md
• /iac.analyze repurposed for infrastructure assessment rather than cross-artifact consistency checking

The iac-spec-kit currently supports four main cloud provider namely AWS, Azure, GCP and IBM.

The flow for generating the tasks (iac.tasks) is guided by a tiered approach along the following lines

1. Setup/Foundation
2. Network
3. Compute/Data
4. Application
5. Polish

While these steps make perfect sense for Hyperscaler offerings that cover the stack from Iaas to Serverless, the approach needs to be validated if there are any obstacles when using it with a PaaS offering like SAP BTP.

It is worth to mention that iac-spec-kit adds an explicit constraint missing from spec-kit:

/iac.implement generates IaC code files only — it does NOT deploy or apply resources.

The iac-spec-kit also removed some extension features that are available in the original spec-kit, which should not be an issue as the main features remain in place

Preliminary conclusion

The iac-spec-kit is a much better fit than the generic spec-kit. However some questions remain open from the perspectve of SAP BTP like the PaaS nature and the "generic" flow of the kit including IaaS aspects.
In addition further investigation is needed concerning the combination of different providers (BTP, Cloud Foundry, ...) in one SDD flow which is different compared to AWS and Azure.
As e.g. Azure has an MCP server for their documentation especially the Well-architected framework, we need to check the options to integrate this valuable information (SAP BTP Administrators Guide) as input to the flow. The MCP server https://github.com/marianfoo/mcp-sap-docs could close this gap.