プラットフォームエンジニアリングは社会技術的な視点からアプローチされるべきであり、開発者だけでなくすべてのステークホルダーによって形成されるべきである、とSergiu Petean氏はDev Summit Munichでの講演 Driving the Future of Insurance through Platform Engineeringで述べた。プラットフォームの成功はチームがソフトウェアを構築、実行、リリースできるようにするために、変化を主要デザインの原動力として受け入れつつも、変化に耐えうる明文化された原則に依存している。
効率性はそこから生まれるものであるため、誰もがビジネスや業務システムの背後にある何らかのプラットフォームを消費している、とPetean氏は述べた。金融分野にはあらゆるイニシアチブやプロジェクトの成功を測定するための明確なKPIのセットが存在する。残念ながらそれはプラットフォームエンジニアリングには当てはまらない、と彼は主張した：
技術プラットフォームを支えるリーダーに自身のプラットフォームがどれほど成功しているか、また他社と比べてどうかを尋ねてみてください。驚くべき結果になるでしょう。
プラットフォームの目的、役割、そして影響は業界によりはるかに良く理解されなければならない、とPetean氏は述べた。場合によってはプラットフォームの成功と影響はいくつかの標準的KPIを使用して、単一ステークホルダー視点から測定されることがある。内部開発ポータル（IDP）とそのオンボーディング時間、デプロイ頻度、リードタイム、平均復旧時間のようなエンジニアリングチーム向けKPIを考えてほしい。
しかしながら、すべてのステークホルダーに対する全体的なインパクトを深く理解できることは極めて稀であるとPetean氏は述べた：
イノベーションの未来が実際に描かれるのは財務的および戦略的な能力やインパクトの領域ですが、それらが測定されることはほとんどありません。
Petean氏はプラットフォームエンジニアリングを「組織全体により良く貢献するためにツールの選択の自由よりもエクスペリエンスを優先する、社会技術的な一連の実践」と定義した。どのような技術を使用するかは対応しなければならない力学やステークホルダーによって形成される：
私の場合、もっとも強力なステークホルダーは開発者ではありませんでした。セキュリティ、コンプライアンス、CEOオフィス、そして最高変革責任者組織といった、はるかに大きな力学が存在していました。彼ら全員が強力で継続的なデザインパートナーとなったのです。
プラットフォームチームはそのビジョン、人材、ミッション、ステークホルダー、そして原則によって推進されるとPetean氏は述べた。最初の4つはより頻繁に議論されるようになってきている。これは素晴らしいことだがコミュニティがより強く発信すべきなのは最後のひとつ、原則であると彼は説明する：
原則が時間や変化に耐えるためにはバランスが取れており、理想的には全体論的に表現されている必要があります。すでに存在している組織的および文化的な原則は、チームや個人の原則と調和している必要があります。
Petean氏はプラットフォームの原則とミッションを書き留めておくことが重要であると述べた。なぜなら、それらがチームのカルチャーとアイデンティティを構築し、維持していくことになるからである：
私たちは内部および外部のアイデンティティを定義し、プロダクトのステークホルダーにより良く貢献するために内部および外部のトポロジーを継続的に適応させました。私たちはあらゆる場所で変化を受け入れました、ただ1つの例外：原則を除いて。
バリューストリームチームとし、彼らはチームが独自の本番環境を記述し、デプロイ、監視、維持できるようにするための、将来にわたって有効なプラットフォームを構築した、とPetean氏は述べた。彼らはソフトウェアのリリースプロセス全体を変更し、それを民主化しました。彼らのDevOpsのモットーは「自分が作ったものを自分が動かす。ただし、決して一人ではない」であった、と彼は締めくくった。
InfoQは変化の推進とプラットフォームチームの影響について、Sergiu Petean氏にインタビューした。
InfoQ：組織において変化を推進するために、どんなアプローチをされているでしょうか？
ergiu Petean氏：変革が起こるための第一条件はオーナーシップです。チームは変革対象に関する知識を完全に所有する必要があります。
変化がグローバルなプラットフォーム（およびそのオペレーティングモデル）のような、極めて複雑なものに適用される場合、社内の人材と全体的な視点が不可欠です。エグゼクティブチームのビジョンとサポートも同様に不可欠となります。彼らは文化（これは無料では手に入りません）と安全性（あらゆる重大な変化には重大な潜在的リスクが伴います）の両方に投資する必要があります。
InfoQ：プラットフォームチームとしてインパクトをどのように測定しましたか、そこから何を学びましたか？
Petean氏：私たちが初日に全員で合意した主要な原則の1つは、測定可能性でした。私たちは構築しているすべてのものを測定することに決めました。より多くのステークホルダーに貢献し、より大きな影響を与えるようになるにつれて、私たちのインパクトKPIはますます重要になりました。その後、欧州のITコストセンターの「呪い」が私たちに見つかったとき、私たちのインパクトKPIは最良の味方となりました。
これを説明するために例を挙げてみましょう。CFOがコスト削減を要求していると想像してください。あなたのプラットフォームチームは大きすぎます。それを縮小する必要があります。その一方で、COOは100%のコンプライアンス対応について冗談を言っているわけではありません。あなたのプラットフォームチームはコンプライアンスに多大な投資をしています。FTEの削減はコンプライアンスに重大な影響を及ぼすことになります。コンプライアンスとプラットフォームチームの間に明確な相関関係がある限り、COOはチームを維持するための最良の支持者になってくれるでしょう。