リーンエンタープライズにおけるエンタープライズアーキテクトの役割

ビジョンを持ち、共有する

一貫性を促進するための最初の重要なステップは、エンタープライズポートフォリオの長期的なビジョンを持つことです。プロジェクトを整合させるには、現在の状態と将来の状態のアーキテクチャの両方を記述できることが不可欠です。まず、現在のポートフォリオを評価することから始めます。どのようなシステムが存在し、それらが何をしているのかをマッピングします。これは詳細に記述したり、個々のサーバーを呼び出したりする必要はありません。代わりに、アプリケーションと製品、およびそれらの関連性に焦点を当てます。複数のレイヤーが必要になる場合があります。企業が十分に大きい場合は、問題を機能領域に分割し、個別にマッピングします。基礎となるアーキテクチャパターンまたは戦略がある場合は、それを特定し、それがどこで守られ、どこで守られていないかを特定します。たとえば、企業戦略がサービス指向アーキテクチャである場合、どのアプリケーションがそれを回避してマスターデータに直接アクセスしますか？アプリケーションはどこで共通データベースを介して通信していますか？

現在の状態をマッピングしたら、将来のアーキテクチャをどのようにしたいかを考えてください。同じ基本戦略を維持しますか？まったく異なるモデルに方向転換する方が良いでしょうか？現在の戦略の長所と短所は何ですか？現在の戦略を進化させたい場合は、矛盾する領域が他の領域と一致するように、アーキテクチャの更新されたビューを作成します。抜本的な戦略変更が必要だと考える場合は、理想的な最終状態がどうなるかをマッピングします。これは長期的なビジョンですが、他のテクノロジーグループが従うことを望んでいるビジョンであることを理解してください。

ビジョンができたので、組織のプロジェクト技術リーダーに理解されていることを確認する必要があります。主要な開発者にビジョンを提示し、彼らのフィードバックと意見を求めます。彼らは、なぜ物事がそのようになっているのかをあなたよりもよく知っている可能性が高く、あなたが理解するのを助けることができます。彼らの反応に基づいてビジョンを調整することをいとわず、むしろ熱心に調整してください。アーキテクチャ全体または特定のグループの領域を根本的に変更する場合、変更に彼らを巻き込もうとしてください。それはあなたのビジョンを実現することを容易にします。アーキテクチャを義務付けることを避け、代わりに開発者とそのチームとの共通理解のためのツールとして使用してください。あなたは彼らをあなたのコラボレーターおよび仲間にすることを試みていることを忘れないでください。ビジョンへの彼らの積極的な関与は、ビジョンをあなたが望むとおりに正確に得ることよりも価値があります。

ある程度のコンセンサスを感じたら、現在と将来の状態のアーキテクチャを可視化します。これは、ドライブ上のフォルダ、Sharepointサイト、またはWikiにあるという意味ではありません。ポスターまたは壁サイズのプリントを作成します。それらを複数の領域に表示します。目標は、誰もがビジョンを共有し、ビジョンに向かって前進し続けることができるようにすることです。アーキテクチャが進化するにつれて、ビジュアルを更新して、行われた作業と方向の変更を反映します。改善が行われている場所を示し、改善を行っているチームを認めましょう。素晴らしいものを構築するために集まることに誇りを持てるように他の人を助け、彼らはそれをサポートします。

橋渡しをする

ビジョンができたので、あなたはそれが実現するのを見たいと思うでしょう。しかし、あなたとあなたのチームはプロジェクトを開発または管理していないので、どのようにすればこれを達成できますか？最良の方法は、開発チームのパートナーおよびリソースになることです。あなたの目的は、進歩を制限または阻止することではなく、それを可能にすることです。開発作業が開始されたら、技術およびプロジェクトのリーダーシップに連絡してください。ターゲットエンタープライズアーキテクチャの最新のビューを提供し、プロジェクトがそのビジョンをどのように実現できるかについて話し合います。多くの場合、チームは、企業内で進行中または完了した他のプロジェクトと同様の作業に従事しています。共有された経験から実際のコードや成果物まで、あらゆるものを活用できるように、これらのプロジェクトを認識していることを確認してください。実装の詳細にこだわらないようにしてください。どのライブラリまたはバージョンが使用されるかについては心配しないでください。代わりに、プロジェクトの高レベルの目標と設計、およびそれが全体的なビジョンにどのように合致するかに焦点を当てます。

プロジェクトについて話し合うと、必然的にテクノロジーの選択が出てきます。ほとんどの場合、チームは企業内の他のプロジェクトと同様のテクノロジーを使用することに満足しています。しかし、時折、技術者は新しいテクノロジーについて学び、それを使用して問題を解決したいと考えています。すぐにノーと言ったり、新しいツールが新しい、楽しいという理由だけで選択していると想定したりしないでください。それは起こりうることであり、実際に起こりますが、新しいツールは問題を解決するために作成されたものであり、前進するのにちょうど良い時期かもしれません。テクノロジーチームと選択肢について話し合い、新しいテクノロジーを使用するための適切な議論があるかどうかを判断します。新しいプラットフォームを本番環境に移行するためのコストと難しさを理解し、そのメリットがこのコストを上回ることを確認してください。話を聞く前に少し聞いてから、調査を行う必要があるかもしれません。実現可能性を判断するために、実際の測定値と境界を持つ時間制限付きの概念実証を行うことを検討してください。最終的に、新しいテクノロジーが正しい選択ではない場合は、開発者またはそのリーダーシップからコンセンサスを得ようとします。可能な限り、それを義務付けることは避けてください。これは、開発チームとの良好な関係を築き、将来の意思決定に彼らがあなたを参加させることを保証するのに役立ちます。新しいツールやテクノロジーを試すときは、企業内で同時に進行中の実験の数を制限してください。あまりにも多くの同時変更があると、効果を正確に測定することは困難になります。

最終的に、EAとしての成功は、開発チームのサポートによってのみ可能になります。彼らを部下のように扱うと、彼らはあなたの周りの方法を見つけ、あなたのビジョンと戦略を危険にさらします。あなたはまだ、それらを変更する能力がほとんどない結果に対して責任を負います。代わりに、彼らをパートナーとして扱うと、彼らはあなたのビジョンを実現するのを助け、誰もが成功することができます。変化を受け入れますが、それを測定し、誰もが変化の価値を理解していることを確認してください。最終的には、常にチームをエンタープライズアーキテクチャのビジョンに導くようにしてください。

変化の機会を見つける

大きな変化には時間と機会が必要です。将来のビジョンを持ち、企業内に興奮を構築し始めたら、すぐに結果を見たいと思うでしょう。アーキテクチャの大幅な変更は、段階的に適切なタイミングで行う必要があることを覚えておくことが重要です。ポートフォリオ内の既存のプロジェクトを使用して、変更プロセスを開始します。新しい実装をアーキテクチャビジョンに向けて導きます。コードを変更して希望する方向に進む機会は、必ずしも希望する速度や領域で訪れるとは限らないことに留意してください。どんなに小さくても勝利を祝い、前向きな変化を起こす機会を常に vigilance を怠らないようにしましょう。

そうは言っても、ビジネスと協力して、既存のポートフォリオの最悪の部分に対処するプロジェクトを優先順位付けします。ビジネスリーダーは、技術コンポーネントを変更することの価値や、現状維持のコストを理解していることはほとんどありません。純粋に技術的な変更が必要な場合は、変更の機会を創り出すのはあなた次第です。変更を実装するためのコストを相殺する将来の節約という観点、またはリスク削減という観点から、ビジネスにとっての価値という観点から変更を組み立ててください。必要に応じて、ビジネス機能のパートナーを見つけ、新しいビジネス価値を追加し、アーキテクチャの変更を可能にするプロジェクトを作成します。予算と運用チームの負担となっている古いアプリケーションとハードウェアを廃止する機会を探してください。

変化のペースに patience を持つことで、フラストレーションを回避できます。変更は進行中の作業のコンテキスト内でのみ発生する可能性があるため、予算とポートフォリオのプロジェクトを最大限に活用してください。ビジネスに新しい価値を生み出す、または開発コストよりも多くのお金を節約する新しいプロジェクトを特定することにより、機会を創出します。ビジネス価値を生み出すことがあなたの主な目標であることを忘れないでください。そのため、興味深いものの価値のない、純粋に技術的なプロジェクトは避けてください。ビジネスがあなたのビジョンに従うことで生産性と価値の向上を認識するにつれて、勢いが増し、変化のペースが加速します。そうなるまでは、作業を形成し、ビジョンを洗練し続けてください。

学習コミュニティを構築する

全体的なエンタープライズアーキテクチャのビジョンを持つことに加えて、EA はそのビジョンが適切なスキルとプラクティスで実行されるようにする必要があります。各開発チームは成功に必要なスキルを開発しますが、最高のスキルとプラクティスを異なるチーム間で共有することで、各チームはより適切に実行し、共通の目的意識を持つことができます。チーム間の架け橋として、あなたはコミュニティ意識を醸成するのに最適な立場にあります。

コミュニティの構築は、非公式のランチからサードパーティのトレーニングまで、さまざまな方法で行うことができます。組織にとって何がうまくいくかを判断しようとするのではなく、技術リーダーから開発者まで、自分の craft に情熱を注いでいる技術者のグループを結成し、彼らを支援してもらいましょう。チームが定期的に cadence を満たしてイベントを計画するようにします。開発チームが学んだこと（成功したものと拒否したものの両方）を共有する時間を必ず設けてください。IT 組織全体と共有する機会を持つことで、健全な組織につながるコミュニティ意識が芽生え始めます。

人々にトレーニングや学習活動への参加を強制することは避けてください。すべての人に公開しても、オプションにしてください。興味のない人は、行動したり退屈そうに見えたりすることで気を散らし、発表者の士気をくじきます。情熱を持っている人は、学び、成長する機会を歓迎します。そうでない人は、必須の出席から利益を得ることはありません。

コミュニティ意識と学習の機会は、開発者を活性化し、定着を促進します。コミュニティの中核を率いることで、将来のビジョンに合わせて組織の開発を導くことができます。他の人がこのガイダンスに参加できるようにすることで、内部からリーダーシップを特定し、構築することができます。強い誇りとコミュニティ意識は、より良い品質とより多くのコラボレーションにつながります。