円卓会議「ITプロジェクトの建築家」、2018年9月

9月5日、モスクワはHSEでラウンドテーブル「ITプロジェクトアーキテクト」を開催しました。 ラウンドテーブルの主催者であるマキシム・スミルノフは、 アーキテクチャとFacebookチャンネル に関するブログです。



そのようなイベントが開催されていることを非常に嬉しく思います。 クールな建築家になることは私の夢であり、これからも変わりません。 非常に長い間、建築家が一般的にどのように入手し、どのように開発し、どの方向を選択して建築につながるのかは明確ではありませんでした。 建築家に質問をすることができるコミュニティがあることは素晴らしいことです。



ラウンドテーブルでは、15〜20分の4つのレポートが提示され、その後、聴衆からの質問とディスカッションがありました。



報告書は簡潔で要点まであり、議論は非常に活発で広範でした。







さらに、レポート中のメモ。

報告1

プロジェクトの意思決定アーキテクトのゼロからの重要なスキル

ゲンナディ・クルグロフ

認定SOAアーキテクト、ctn



プレゼンテーションの一環として、建築プロセスの主要な段階に触れました。

1. ビジネスへの関与。
2. 魅力的なエンジニア。
3. プロトタイピング。
4. アーキテクチャスタイルと技術スタック（マイクロサービス、モノリス、SOA）の選択。
5. ドラフトアーキテクチャの開発。
6. 顧客へのデモンストレーション。
7. ソリューション設計。
8. アーチソリューションの文書化。
9. 建築監督。

パフォーマンスのハイライト：



プロトタイプを作成してビジネスに見せることをお勧めします。 建築スタイルを選択する場合、可能であれば、開発者、セキュリティ、運用など、さまざまな関係者が関与する必要があります。 スケッチを設計するときは、ビジネス、テクノロジー、セキュリティなど、アーキテクチャのさまざまなセクションを作成する必要があります。



可能であれば、システムのこの部分で直接作業する人々を引き付ける必要があります。



関係者との議論の後、プロトタイプが実証されます。 プロジェクトが開始されると、アーキテクチャの各レベルのより詳細な調査が実行されます。

開発中、プロセスが選択されたパスに従っていることを確認するには、アーキテクトとの同期が必要です。



スピーカーによると、建築家が必要とするスキル：

• コミュニケーションスキル（説得、交渉）
• プレゼンテーション
• ブレーンストーミングとワークショップ
• 建築様式の知識
• 現代のテクノロジーの幅広い視野（長所と短所を理解することが重要です）
• 設計およびアプリケーション設計スキル
• さまざまなフレームワーク、製品、プログラミング言語を使用した開発スキル
• 意思決定文書化フレームワークの知識
• さまざまな種類のSDLC（システム開発ライフサイクル）を理解する
• プロフェッショナルな接続の幅広いネットワーク
• 開発チームを管理するスキル

報告2

ITプロジェクトのアーキテクチャサポート

ドミトリー・ロマノフ、ITSK



ITソリューションの設計、プロジェクトのアーキテクチャサポート、年間約80プロジェクト、約50人のアーキテクトがプロセスに関与しています。



チーフITアーキテクトのサービスは、ITプロジェクトアーキテクトによって実装されたIT分野の技術ポリシーを決定します。 建築家が通常必要な専門知識を収集するという質問に答えて、Dmitryは次のソースを示しました。

1. 経験-同様のシステムの作成
2. 同僚-社内または他社の誰か
3. ベンダー-開発者との協議
4. テーマ別フォーラム
5. テクノパーク-テクノパークに基づく承認またはサンドボックス

ITSKでのアーキテクトの役割の必要性を考慮して、Dmitryは、たとえば、ITプロジェクトのアーキテクトが必要であると指摘しました。たとえば、1年間プロジェクトを行い、その後6か月間働いてからスケーリングがないことを認識し、2年間それをやり直したという状況はありません。 提案されたアーキテクチャを実装できることを明確に理解することが重要です。 プロジェクト管理の方法論に応じて、ITSKでアーキテクトはチーム（アジャイルの場合）に入るか、プロジェクトエキスパートグループに入ります。

報告3

組織のITプロジェクトのアーキテクチャ：主な焦点

Ivan Lukyanov、モスクワ情報技術局、製品「State services and MFC」



講演者のプロの経歴：Diasoftの開発者、開発チーム（BSC Praha）の責任者、主要コンサルタント（Neoflex）、Alfa Bankのアーキテクチャおよび戦略部門の責任者、アーキテクチャ開発部門（DIT）の責任者。

Ivanは、既存のアーキテクチャの説明から（現状のまま）、ターゲットアーキテクチャを作成し（予定）、「組織の現在」と「組織が行きたい」ポイントの違いを分析して、システムをターゲット状態にする手順を説明することをお勧めします。

アーキテクチャにおけるITプロジェクトの主な重点：

• 解決するビジネスタスクの設定：アーキテクトは、ビジネスタスクが適切に配置され、設計に適した形式で記述され、ビジネスの責任者によって合意されていることを確認する必要があります。
• 方法のビジョン：組織内のアーキテクトの努力により、ビジネスの特定のニーズに合わせて組織のターゲットアーキテクチャを開発する必要があります。 ターゲットアーキテクチャは、それを達成するために具体的な手順（プロジェクト）に分割する必要があります。
• 設計：すべてのソリューションは、開発されたターゲットアーキテクチャを考慮して設計されています。 ターゲットアーキテクチャは、プロジェクトごとに段階的に実装されます。 アーキテクトは、アーキテクチャに関する決定を承認します。
• プロジェクトの実装プロセス：組織には、ビジネスタスクの分析と説明、ターゲットアーキテクチャの開発、設計プロセスを含むプロセスが必要です（開発と運用はレポートに含まれていません）。 このプロセスは、経営陣が関与しサポートするすべての関係者によって合意される必要があります。
• プロジェクト実施プロセスの方法論的サポート：非常に多くの場合、ビジネスタスクと設計の策定を考慮して、組織でITプロジェクトを実施するための方法論の開発を担っているのは、アーキテクトです。 この作業の一環として、組織にITプロジェクトを実装する既存のプロセス（以前にあった場合）または新しいプロセスをゼロから作成する（存在しない場合）を調整できます。 方法論的作業の結果は、記述されたプロセスと、テンプレートの形式で形式化されたサポート文書です。

同社は現在、独自の方法論を開発しており、これには作業で使用されるドキュメントのテンプレートが含まれています。 TOGAFとGartnerの原則が使用されました。



アーキテクチャの原則が承認され、ドキュメント「アーキテクチャおよび技術ソリューション」が作成されました。このドキュメントには、ソリューションのビジネス要件とその実装プロジェクトが記載されています。



アーキテクトの特徴：

• 社交性。 管理者、パフォーマー、サポート、マネージャー、テスターとのコミュニケーションが重要です。 建築家は翻訳者の役割を果たさなければなりません-ビジネスの言語から技術的な言語へ、またはその逆へ翻訳してください。
• 必須要件は、開発者の経験です（まあ、分析もしますが）。
• 同僚を尊重します。
• 継続的な開発。

建築とは、花崗岩で作られた動かないモニュメントではなく、ビジネスサポートの観点から私たちが達成したいことの生きた、進化する視点です。

報告4

ITプロジェクトアーキテクト：考えられる視点の1つ

Evgeny Aslamov Aslamov、Lanit Group of Companiesのリードアーキテクト。



建築家の役割へのユージーンの道：開発者、アナリスト、プロジェクトマネージャー。 短編小説の中で、著者はカスタム開発におけるアーキテクトの役割に関連するいくつかの問題を提起しました。彼を取り巻くもの、彼がすること、彼がそれをどうするかです。



カスタム開発のアーキテクトについて話すEugeneの意見では、さまざまな要因（タイミング、予算、チーム、複雑さ、タスクの量）に依存しています。 原則として、複雑なプロジェクト（数千のユーザーシナリオ、数十のシステムとの統合、大容量のデータ、高可用性と災害復旧の厳しい要件）では、アーキテクチャタスクはアーキテクトチームによって閉じられます。 より控えめなプロジェクトでは、1人がこれらのタスクに対処でき、アーキテクトは常にタスクに専念するわけではありません-彼の役割は他の役割と組み合わせることができます-リード開発者またはアナリスト。



建築家は、他のチームメンバーと同様に、特定のコンテキストで作業します。 そのようなコンテキストの概要：



お客様

• プロジェクトを担当する顧客からの最高の（いずれにしても、重要な決定に十分なほど高い）管理。
• 顧客委員会（建築、設計、運用など-頻繁に発生します）;
• 情報セキュリティ専門家のサービスまたは部門;
• プロジェクトを「燃やす」システムを必要とする顧客従業員。
• 現実-かなり平凡なルーチン、人的要因、手続き上の問題、小さな不一致など。

チーム

• マネージャー
• アナリスト
• 開発;
• DevOps
• 質の高いサービス。

契約

• 締め切り;
• 予算
• 法的引用符;
• 私が本当に適用したい新しい技術、アプローチ、チップ。
• 伝統：それは機能し、それは良い、すべてが私たちと一緒です-何を変えるかなど。

コンテキストの一部として、アーキテクトまたはアーキテクトのグループは次のことを行います。

• これは、プロジェクトが開発されて生きるチームの境界を形成します。 まず、機能以外の要件から生じる境界について話します。
• 主要な利害関係者の見解を考慮して、アーキテクチャソリューションを形成、維持、および更新します。
• 通訳として機能します-技術からロシア語へ、またはその逆に翻訳します。 顧客とチームの両方の実際。 アーキテクトは、プロジェクトのすべての側面を（主要なアナリストとプロジェクトマネージャーとともに）理解し、技術部分との関係を説明できる必要があります。
• 多くの不快な質問をします。 チームのメンバーが1人も別のメンバーも参加せずに、いくつかの決定が下されたのはまさにそのためです。 これは正常です。 何かが行われ、システムのアーキテクチャに影響を与えている、または影響を与えている可能性がある場合、現在何かを変更する必要があるのか​​、将来のためのいくつかの対策を講じるのか、それとも単に良い時間まで記録しておくのかを判断する理由を見つける必要があります。

「彼はこれをどうやってやるの？」という質問に答えて、ユージーンはまず建築ソリューションの開発の問題に触れました。 このタスクに役立ついくつかのコンポーネントが特定されました。

• 経験と類推。 これは、アーキテクトの最も重要な資産の1つです。 そして、それは絶えず増加する必要があります-1つのプロジェクト、技術などで停滞しないように
• 地平線。 自分の経験を使用することはできません-同僚の経験、コミュニティの経験、標準。
• プロトタイプ。 新しい、テストされていない、または目に見えるリスクを使用する場合、プロトタイピングが必要です。 同時に、プロトタイプが答えなければならない質問を正確かつ正確に定式化することが重要です。そうしないと、状況が悪化するだけです。
• 意思決定を保護します。 プロジェクトチームの前、建築委員会（あなたまたは顧客）の前、自分の前。 ソリューションの1つとして、 ATAM-Architecture Tradeoff Analysis Methodの導入（完全または個別の要素）があります。 たとえば、多くのプロジェクトでは、意思決定の保護は、プロジェクト外の同僚に代替の意見やコメントを得るための重要な意思決定のプレゼンテーションとして実装されています。

結論の代わりに：建築家および彼の仕事を愛する専門家の非公式な仕事の1つは、チームがプロジェクトの問題をより効率的かつより便利に解決できるようにする知識、技術、アプローチ、およびスキルを普及させることです。



habrに関するEugeneの記事「 Sparx Enterprise Architectでプロジェクトを準備しています。 私たちのレシピ 。 "

質疑応答

次は質問と回答のセクションで、最も記憶に残るものは以下で読むことができます。

建築家はどこから来たのですか？

ジェンナディ：

ソフトウェアアーキテクト-元チームリーダーまたはそれらのリーダーまたは開発者をリードします。

ドミトリー：

アーキテクトは、幅広い専門知識を持つコンサルタントの開発者から選ばれます。

開発者は、プレゼンテーションを話し、描くことができます-ソリューションアーキテクト。

ユージーン：

一般に、開発、テスト、プロジェクト管理など、あらゆる部分から しかし、いずれにせよ、いくつかの専門技術が役立ちます-それらをゼロから開発する必要はありません。

個人的な経験からの例：星の病気のない知的で社交的な人、モスクワ州立大学の機械学部の学生がLanit社に連れて行かれました。 彼は分析、開発、顧客とのコミュニケーションで少し働いた。 その結果、彼は当社の応用建築家になりました。

アイヴァン：

開発者から。 優秀な開発者がいれば、彼はプログラミング言語を掘り下げ、さらに深く開発することができます。 しかし、当時、彼が技術的なタスクがどのように生まれ、分析し、誰がこれを行うべきかどうかを決定することに興味があった場合、これは専門家が初心者の建築家の道に着手したというシグナルです。 次のレベルの好奇心は、ビジネスレベルで全体としてソリューションが生まれる方法です。 組織の長に、彼が必要としているものとそうでないものをどのように示すことができますか。 建築家の役割を説明する際に、 Gregor Hohpeはエレベーターの比phorを使用しています。 エレベーターが停止する各階は、組織内の特定のレベルです。1階-機械室-これは開発者、生産者です。 最上階-組織管理。 建築に命を吹き込み、建築家は各フロア（最初から最後まで）でコミュニケーションをとり、各フロアでさまざまな困難（技術、政治、コミュニケーション）に対処する必要があります。



アーキテクトは必要な情報を収集し、各レベルに伝えることができます。 実際、彼は関係者間の仲介役を務めています。

プロジェクトマネージャーとアーキテクトの間で権限をどのように共有する必要がありますか？

権威の間にはバランスが必要です。 建築家の権限は技術的な部分にあり、プロジェクトマネージャーは組織的な部分にあります。



バランスがRPにシフトしている場合-プロジェクトを時間通りに取得できますが、機能していなかったり、スケーラブルではありません。 そして、建築家の方なら、誰も必要としないときに素晴らしいプロジェクトを手に入れることができます。 これは、「ママとパパのどちらをもっと愛していますか」という質問に答える方法です。

さまざまなプロジェクトを大量に抱える企業アーキテクトになるにはどうすればよいですか？

アイヴァン：

大規模な組織では、2,000人を超える人々が1つの企業アーキテクチャを作成し、それに従うことはほぼ不可能です。 DITでは、部門は製品（サービス）に分割され、各製品には独自の技術スタック、独自のアーキテクチャがあります。 企業アーキテクチャに関しては、株主は、アーキテクチャ開発に関して組織がどこに向かっているのかを理解するために、それをさらに必要とします。 この目的のために、組織ではチーフITアーキテクトの役割が強調されることが多く、その主なタスクは企業アーキテクチャの全体的な状況を判断することです。

プロジェクトアーキテクトと企業アーキテクトの間の相互作用はどのように構築されますか？

コミュニケーションは重要です。 あなたはコミュニケーションを構築し、ただコミュニケーションする必要があります。 プロジェクトアーキテクトは企業アーキテクチャの知識を必要としない場合もありますが、統合の対象者と影響を把握することが重要です。 建築委員会を作ることは重要です。企業の建築家だけでなく、設計者も知ることができます。



あなたは価値の観点からそれを見ることができます-誰がより多くの価値をもたらします。 ソリューションが機能する場合、価値があります。 エンタープライズアーキテクチャ自体は価値をもたらしませんが、特定のタスクを既に実装しているアーキテクトのソリューションを通じて価値をもたらします。



ジェネラリストを必要とする人はいません。すべてについて何も知らない人は、ますます必要性が少なくなります。 特定の質問に答えることができる方が良いです。たとえば、RabbitMQはここで十分ですか、Kafkaは必要ですか。

エンタープライズアーキテクチャリポジトリはどのように編成されていますか？

計算、検証などが可能な複雑なモデルはありますか？



Eugene：アーキテクチャリポジトリはありますが、メトリックを計算するための自動化はありません。 モデルとモデル自体の関係により、建築を写真のセットではなく、不可欠なものと考えることができます。 リポジトリのタスクの1つは、影響分析を提供することです。 これに基づいて、変更の価値を見積もることができます。

あとがき

建築家の話に耳を傾け、コミュニティを知ることができるのは素晴らしいことです。 このような会議は、私が必要な知識を見つけるためにどこを掘るかを理解する絶好の機会です。 さらに、作業ケースについて議論し、推奨事項を得ることができます。



建築家の円卓会議を開催してくれたマキシム・スミルノフとHSEに感謝します！

また、レポートの作成者（Evgeny Aslamov、Gennady Kruglov、Ivan Lukyanov）にも感謝します 。元のノートはレポート中に作成されており、修正された誤りや不正確さが含まれていたためです。



写真のフランスのシャンボール城では、各所有者が自分の砲塔に建てたと言われています。 プロジェクトのアーキテクチャがそのように見える場合があります。 私の意見では、すべてができるだけ美しくシンプルになるように、さまざまなスタイルの塔がたくさんあっても美しい城を手に入れるには、建築家が必要です。