ソリューションアーキテクトの報告ラインは、EAマネージャか開発マネージャですか？

Question

私たちは大きなテレコム企業であり、最近私たちの会社に設立されたEAのオフィスであり、技術的ソリューションのアーキテクチャが開発チームかEAチームの責任の一部であるべきかどうかという内部討論がありますか？それに基づいて を使用すると、ソリューションアーキテクトの報告ラインを決定する必要があります。

Answer 1

「正しい」回答は実際にあなたの組織、さまざまなチーム、文化などの構成に依存しているため、答えは非常に難しい質問です。つまり、私はまだあなたに私の意見を与えます:-)

EAのオフィスが設立されたと言われて以来、彼ら（EAチーム）は「エンタープライズ」（EAの「E」）の懸念に焦点を当て、ソリューション固有のアーキテクチャを開発チームに任せています。

例として、私が働く組織には、EAチーム（全員がEAチームを率いている）と9つのアプリケーション開発（AppDev）チームがあります。各AppDevチームにはリード開発者がいます。私たちの視点から見ると、リード開発者はAppDevチームの「アプリケーションアーキテクト」です。主任開発者は、作成/維持するアプリケーションのアーキテクチャービジョンとデザインを提供する責任がありますが、エンタープライズアーキテクト（EAチーム）と協力して、全体的なエンタープライズアーキテクチャ目標EAチームによって伝達されました。

ゴードンは上記のコメントで言及したように、誰もが適切な価値が提供されていることを保証するために協力する必要があります。しかし、あなたはEAチームを持っているので、私はそれらを企業の懸念事項に集中させ、開発チームはアプリケーション固有の問題にすべて集中して、すべてのニーズが満たされていることを保証します。

Answer 2

私の以前の仕事では、開発チームはCIOに報告した開発マネージャーに報告しました。アーキテクチャチームはCTO（その環境でEAに最も近いもの）に報告しました。その意味では、ソリューションチームはEAチームと同じレポートラインに入るべきだと私は言います。

私の意見では、デベロッパーチームが配信に重点を置いているのに対し、アーキテクチャチームは品質と長期的な持続可能性（私の見解では）に重点を置いています。開発チームに報告するアーキテクトチームは、長期的な品質ではなく、短期間の配信利益に向かう可能性があります。また、開発チームの数はいくつですか？アーキテクチャーは重複する懸念事項でなければなりません。複数の開発チームがある場合、それらのチームに取り組んでいるアーキテクトは、自分のチームで何が起きているのか分かりません。さまざまなチームのアーキテクトが集まり、知識を共有し、お互いのソリューションをレビューし、建築基準が全面的に適用されるようにするアーキテクチャボード/フォーラムを設定することもできます。