テスト駆動開発(TDD)を使えば，要求されるビジネス成果を満足していることを検証できる。同じように，適合度関数駆動(fitness function-driven)開発を使うことで，システムのアーキテクチャ目標との整合性を評価するテストの記述が可能になる - Paula Paul，Rosemary Wang両氏はブログ記事でこのように書いて，適合度関数(fitness function)の基本的な考え方とその初め方，さまざまなアーキテクチャ品質を検証する方法の例を説明している。
共にThoughtworks{/0｝に籍を置く両氏は，アーキテクチャ標準は機能要件とは別に，変化する目標と制約によって定常的に評価されるべきであることを強調し，書籍"Building Evolutionary Architecture"の次のような一節を引用する。
進化的アーキテクチャは，多次元にわたる第１原則として，方向性を持った漸進的変化を可能にします。
このような進化をサポートする上で，適合度関数は，設定されたアーキテクチャ目標をシステムがいかに満足しているかを自動的に評価する方法を見出す一助となる，と両氏は考えている。その一例はログ記録である。ログはしばしば後付けされて，重要な情報を欠くことも多いが，適合度関数を活用することで，ログが適切に構造化され，有用な情報が十分に含まれていることを確認できる。
適合度関数の使用を開始する際に氏らが推奨するのは，すべてのステークホルダから情報を収集して，彼らが何を最も重要なアーキテクチャ属性と考えているかを理解することだ。その上で，これらをレジリエンシやセキュリティ，運用性，安定性といった共通テーマでグループ化する。この作業から，相反する目標が明らかになる場合がある。例えば安定性とアジリティは，真っ向から対立することも少なくない。安定性が変化をコントロールすることで達成されるのに対して，アジリティは変化を妨げる障害を低減することで実現するものだからだ。これを克服するには，さまざまな属性に対する動機を評価すると同時に，組織にとって最も重要な品質を最優先する必要がある。
収集したすべての適合度関数は，チームとステークホルダにとって意味を持つ客観的な測定基準を用いて，その意図を説明する必要がある。これはチームが技術的負債を測定する上で役立つと同時に，アーキテクチャの振れを防止する上でも有効である。すべての関数をテストフレームワークに書き起こして，適切なデリバリパイプラインに含めることが必要だ。こうすれば，新たなソフトウェアはすべて適合度関数を通過するようになる。両氏はこれを，継続的インテグレーションの自然な拡張と見ている。
適合度関数の一例はコード品質である。変更可能性，管理性，適応性を測定することにより，品質が過度に低いコードの運用環境へのデプロイを防止することが可能になる。
describe "Code Quality" do
it "has test coverage above 90%" do
expect(quality.get_test_coverage()).to > .9
end
it "has maintainability rating of .1 or higher (B)" do
expect(quality.get_maintainability_rating()).to < .1
end
end
もうひとつの例はパフォーマンスだ。これが別のチームによって評価される場合，納期延長の原因となることが多い上に，その結果が必ずしも開発者に伝えるとは限らない，と両氏は指摘する。パフォーマンスの自動テストを適合度関数として実装し，ビルドパイプラインに追加することにより，テストの早期実施と結果への即時アクセスが実現する。
これら２つの例に加えて著者らは、レジリエンシや可監視性、コンプライアンス、セキュリティ、運用性などに関する例も提供している。
結論として両氏は、適合度関数を使用することによって、アーキテクチャもビジネス機能と同じようにコードで表現できる，ということを強調した上で、適合度関数を使用することによって獲得できると考える３つのメリットを掲げている。
- 技術的負債を客観的に測定し、コード品質を向上することが可能になる。さらに、例えば新たなセキュリティや運用標準によって適合関数がされた場合にも、フィードバックがリアルタイムに提供される。
- 下流プロセスに関連するインターフェースやイベント、APIのコーディング選択について通知することが可能になる。ストラングラーパターン(strangler pattern)を適用する場合には、ビジネスロジック分離時に要件が満足されていることを確認する上で役に立つ。
- コードの形でアーキテクチャ標準を伝達することにより、開発者によるアーキテクチャとの整合性のより高い機能の提供を支援する。ユーザが機能変更を要求するのと同じ方法で、アーキテクトがアーキテクチャ上の問題点の変更を要求し、それをビルドプロセス上で検証することが可能になる。
要約として氏らは、アーキテクチャの目標をコードとして記述することにより、コンフォーマンステストをビルドパイプラインに含めて、目標が達成されたことを検証することができる点を指摘する。組織とテクノロジの進化において、これらのテストは、アーキテクチャ要件が常に満たされていることの保証する役を果たしてくれる。