アーキテクトエレベーター ― 上層階への訪問

アーキテクトエレベーター

アーキテクトがソフトウェア開発者を指導すること以外にも多くの仕事があることを示すために、「アーキテクトエレベーター」という比喩を使います。このエレベーターは、企業の機関室から、経営層が戦略を策定するペントハウスまで伸びています。デジタル企業はテクノロジーを利用して新たなビジネスチャンスを開拓していますが、伝統的な組織では、しばしばITを単なるコスト要因と見なし、ビジネス戦略から遠く離れています。無数の管理層が上層階と下層階を隔てており、情報は階層を階段で伝達されるため、よく知られている「伝言ゲーム」効果が発生します。メッセージが多くのステーションを通過すると、時間がかかるだけでなく、意味が完全に変わってしまう可能性があります。

アーキテクトと開発者にとって、これは2つの大きな問題を意味します。まず、上層階の担当者が投資の必要性を感じないため、革新的なプロジェクトの支援や資金調達を得ることが困難な場合があります。しかし、新しいテクノロジーが導入されたとしても、既存のプロセスや政治的な問題により、期待される効果が得られない可能性があります。どちらの場合も、アーキテクトは上層階を訪れて、障害を取り除いたり、組織的な変更を促進する必要があります。

組織がすぐに管理層を削減する可能性は低い（多くの別荘と子供の教育がかかっているため）ので、アーキテクトは階層間を迅速に移動して、ビジネス戦略とITアーキテクチャ、技術的な実装を連携させる必要があります。機関室からペントハウスまでのエレベーターの旅は、現代のアーキテクトが各階で何を求められているかを浮き彫りにします！

クラウド対応アプリケーションは、ランタイムアーキテクチャを必要とする

現代のアプリケーションに日常的に課せられるアーキテクチャ上の要求を考えると、アーキテクトは依然として機関室に必要とされています。かつては分散システムを、異例でやや複雑なもので、できれば避けた方が良いものと考えていました。今日では、分散されていないアプリケーションを構築することはまれです。事実上、意味のあるアプリケーションはすべてサービスAPIを公開し、他のサービスを呼び出し、グローバルにクラウドで分散して実行されます。さらに、それらはゼロダウンタイムで更新され、水平方向にスケールし、ハードウェアとソフトウェアの障害に加えて、Chaos Monkeyがプロセスを面白半分に破壊するような状況にも耐えることが期待されています。これらを実現するには、かなりのアーキテクチャが必要です！

数年前までは、Java EEやSpringなどのアプリケーションフレームワーク内で主要なアーキテクチャ上の決定事項の大部分が既に決定されており、開発者はコーディング機能とユーザーインターフェースに集中できると考えられていました。この約束は、MVCを使用するかどうかなど、設計時の決定に関しては部分的に実現しましたが、現代のアプリケーションは通常、ランタイムに関連する重要なアーキテクチャ上の要求をもたらします。この傾向はオープンソースコミュニティにも反映されています。Docker、Kubernetes、Mesos、CloudFoundry、Prometheus、Hystrix、Vizceral、Kibanaなど、プロジェクト名はスペルが難しくなるだけでなく、アプリケーションのランタイム管理と監視にますます焦点を当てています。

したがって、現代のアーキテクトは、デプロイメントと構成の自動化、スケーラビリティ、監視などを含む、ランタイムアーキテクチャに関する考慮事項をよく理解している必要があります。彼らはクラス図をデプロイメント図と交換するかもしれません！

ソフトウェア製造を自動化して、価値創出までの時間を短縮する

ソフトウェア開発の工業化は、プロジェクトのコストとリスクを削減すると長い間信じられてきました。この取り組みの多くは当初、ソフトウェアの設計面、つまり堅牢な要件をどのように記述し、アセンブリラインのようにプロジェクトチームを管理するか、に焦点を当てていました。しかし、この多くはせいぜい中程度の成功しか収めませんでした。ジャック・リーブスは四半世紀前に既に結論付けています。コーディングは実際には設計作業であり、生産作業ではないと。本質的に創造的な活動である設計を工業化しようとすることは、したがって疑問視されるべき試みです。代わりに工業化されるべきものは、ソフトウェアの生産、つまり稼働システムを形成するためのソフトウェアアーティファクトのアセンブリと配布です。

製造業は半世紀以上前に生産の自動化を劇的に開始し、ほとんどの工場から人間がいなくなりました。皮肉なことに、究極の目的が退屈な手作業を自動化することである可能性のある多くのソフトウェアプロジェクトでは、依然として「職人スタイル」でソフトウェアが提供されています。手動でコピーされたファイル、小さなパッチ、別の構成変更、そして良い味のために更新された権限がいくつか。ああ、そして忘れられていたファイルのコピーがもう1つ。靴屋の子供は裸足であるように、ソフトウェアデリバリープロセスは皮肉にも、ソフトウェアがビジネスにもたらすような自動化を欠いています。

幸いなことに、継続的インテグレーション（CI）と継続的デリバリー（CD）は、クラウドコンピューティングとソフトウェア定義インフラストラクチャによってサポートされる、絶え間ない自動化を通じてソフトウェアデリバリーを工業化することで、大きな改善をもたらしました。これにより、サーバーを使い捨てアイテムとして扱うことが可能になります。サーバーに何らかの問題が発生した場合、修理するのではなく、新しいサーバーをインスタンス化します（牛対ペットのアナロジーを参照）。ソフトウェアデリバリーを自動化する主な推進要因は、経済性、つまりデプロイメントタスクを実行するスタッフのコスト削減ではありません。むしろ、速度と再現性の必要性です。人間は十分に速く、信頼性が高いわけではありません。

したがって、現代のアーキテクトは、設計だけでなく、ソフトウェアの「製造」にも目を向ける必要があります。機関室のこの側面を改善することは、ペントハウスに大きな影響を与えます。迅速で繰り返し可能なデリバリーにより、ソフトウェアがビジネス価値を生み出すまでの時間が短縮されます。上層階を訪れる絶好の理由です。

事前決定を最小限にする

多くのアーキテクトは、自分自身を「取り消しが難しい」決定を行う者と考えており、またそう期待されています。このタイプのアーキテクトは、「マトリックス」の白髪の紳士を連想させるかもしれません。非常に経験豊富で、すべてを知っている人物がすべての決定を行います。この願望には大きな落とし穴があります。マトリックスのアーキテクトはコンピュータプログラムであり、人間ではありません。

プロジェクトの開始時に重要な決定を行うことは、実際には最悪の時期です。なぜなら、それが最も情報が少ない時期だからです。プロジェクトが進むにつれて、より多くの情報が得られるようになり、より情報に基づいた、したがってより良い決定を下すことができます。したがって、すべての重要な決定を1人に委ねるのではなく、取り消せない決定の数を最小限にすることで、プロジェクトのリスクを軽減できます。これは、たとえば柔軟な設計を選択するか、変更の範囲を局所化するモジュール性を使用することによって実現できます。

多くの場合、事前に決定を行いたいという願望は、技術的なニーズではなく、既存の構造とプロセスによって推進されます。たとえば、チームは、時間のかかる予算承認プロセスを満たすために、開発が始まる前に製品の決定を行うことを強いられます。したがって、しばしば善意で事前決定を要求する官僚を阻止することで、取り消せない決定を回避または削減することもできます。

ベンダーも、ツールを選択するだけで、高価なプログラマーの必要性を削減または排除できるなど、管理者に驚異的な成果を約束することで、早期のツールの決定を推進する傾向があります。そうするのは当然であり、非難できません。しかし、あなたはそれを打ち消す必要があります。より速い車はより優れたドライバーを作るわけではありません。さらに悪いことに、場合によっては、車が速くなくても、単に高価なだけであり、操縦が難しすぎるため、溝に落ちることがあります。

これらの例は、IT機関室の効率を向上させるためには、組織の機能を変化させる必要があることを示しています。そのため、アーキテクトは上層階までエレベーターに乗る必要があります。

アーキテクチャオプションを提案する

経営陣にアーキテクチャを説明するのは難しい場合があります。最近の幹部会議で、あるアーキテクトが数分間この話題で苦戦し、参加者の目はうつろになり、首をかしげる様子が見られました。そこで私は口を挟みました。「アーキテクチャとは、オプションを売ることです」。この言葉は、経営陣の注意をすぐに惹きつけました。金融オプションは、将来、既知の条件で金融商品を購入または売却する権利を所有者に与えます。オプションは、特定の将来の日に、例えば100ドルの価格で株式を購入する権利を与えますが、義務ではありません。その日が来たら、オプションを行使するかどうか簡単に判断できます。株価が100ドルより高ければ、オプションを使って100ドルで買い、利益を得ます。そうでなければ、オプションを放棄します。

オプションとは、価格などの主要パラメーターを固定したまま、意思決定を将来の時点に延期する方法です。金融業界は、このオプションに価値があり、したがって価格があることをよく知っています。アーキテクチャをオプションの販売として提示すると、金融用語に精通した上級管理職にとってすぐに意味が通じます。つまり、後で変更できるよう、既知のコストでアーキテクチャに投資するということです。例えば、アプリケーションがスケーラブルで自動的にデプロイ可能であれば、事前にハードウェアを購入する必要はなく、必要が生じたときに将来ハードウェアを追加できます。そうできることは具体的なコスト削減につながり、アーキテクチャへの投資を正当化します。

金融オプションと同様に、アーキテクチャオプションもリスクヘッジを可能にします。私たちは特定の結果を期待していますが、その結果が実現しなかった場合のリスクを軽減し、リスクシナリオの影響を小さくしたいと考えています。

目的に合ったアーキテクチャにする

私たちはしばしば、アーキテクトに「良い」アーキテクチャを求めます。しかし、アーキテクチャが良いか悪いかはめったにありません。それは目的適合か不適合かだけです。目的は、通常、特定のユーザー要件ではなく、システムが動作するコンテキストによって決まります。したがって、アーキテクトの仕事は、商業および法的合意、スキルレベル、既存システムなど、さまざまな要因を含む、より広いコンテキストでアーキテクチャオプションを検討することです。

適切なコンテキストを見つけるには、アーキテクトが組織の多くの階層を訪問する必要があります。特に幅広い調整を必要とする決定は、ソフトウェアデリバリーチームから遠く離れた経営チームによって、財務、プロセスコンプライアンス、またはPowerPointスライドに基づいて行われることがよくあります。アーキテクトの仕事には、影響の透明性を高め、すべてのレベルをアーキテクチャ上のトレードオフに巻き込むことが含まれます。Luke HohmannのBeyond Software Architectureは、アーキテクチャ上の考慮事項の広範囲にわたる内容を分かりやすく示しています。

すべての考慮事項があっても、アーキテクチャ上の意思決定は難しく、間違えるリスクがあります。したがって、その結果を負う人によって決定を行うのが最善です。この考えは、次の階層へと導きます…

フィードバックループを通じて意思決定を検証する

よく知られているアーキテクチャ部門のアンチパターンは「象牙の塔」です。アーキテクトはペントハウスに座って、開発者がどのようにソフトウェアを設計および構築すべきかを定義しますが、自分自身ではソフトウェアを開発しません。このような設定には、決定の効果やコストに関するフィードバックがアーキテクトに提供されないという重大な欠陥があります。さらに悪いことに、一部のアーキテクトは、そのような結果に対処しなくても快適に過ごしているようです。

ほとんどの複雑なシステムは、フィードバックループによってのみ機能します。指がキーボードを感じ取るまで腕が伸びる、部屋の温度に達するとヒーターのサーモスタットが炉を切る、またはドライバーが常にステアリングホイールを調整して車を車線内に維持するなどです。ITでは、フィードバックループはプロジェクトのステアリングとアーキテクチャの両方に適用されます。チームの速度が分かれば、プロジェクトのコストとタイムラインの予測がはるかに容易になり、途中で必要な調整を行うことができます。「再利用可能」なAPIが実際に再利用を促進したかどうか、「共通」フレームワークが開発を加速したかどうか、監視フレームワークが計画外のダウンタイムを削減したかどうかをアーキテクトは確認する必要があります。フィードバックを理解するには、明確な指標と目標を特定する必要があり、それ自体が有用な演習となる可能性があります。

アーキテクトがフィードバックを得るための優れた方法は、プロジェクトのデリバリーに直接関与し、責任を負うことです。フィードバックサイクルは短く即時的な場合に最も効果的であるため、合意された一般的な原則または公開されたIT戦略の範囲内で、開発チームにアーキテクチャ上の意思決定を委任することが魅力的です。

テクノロジーの進化に合わせて組織アーキテクチャを設計する

DevOps、クラウド、ビッグデータなど、最近のソフトウェアの革新の多くは、組織構造がテクノロジーと共に進化する場合にのみ、その完全な価値を発揮できます。完全に自動化されたツールチェーンで数秒でソフトウェアをデプロイできても、それを許可するために3ヶ月間の紙ベースの承認プロセスを経る必要があるとしたら、それは役に立ちません。ソフトウェアデリバリーの高速化においては、技術的な側面だけでなく、組織の構築についても検討する必要があります。これは上層部で行うべきことです。

例えば、多くのIT組織は「変更」（ソフトウェアの開発）と「実行」（ソフトウェアの運用）を分離しています。実行中のソフトウェアからのフィードバックは、企業がビルド・メジャー・ラーンサイクルで製品を改良する主要なメカニズムであるため、これはデジタルの世界ではもはやあまり意味がありません。

興味深いことに、組織システムの動作は、技術システムに影響を与えるものと同様の力にしばしば左右されます。例えば、分散システムにおける最大の処理能力キラーの1つは同期ポイントです。非同期メッセージングを好む理由の1つです。同期ポイントの組織的な同等物は会議であり、スループットを低下させることがよく知られています！

レイヤリングは、複雑さを管理し、柔軟性を高めるのに役立つよく知られた概念ですが、レイヤー間の多くの変換によってレイテンシが増加する可能性もあります。このロジックは、技術システムと組織システムの構造の両方で成り立ちます。組織をレイヤリングすることで、依存関係が明確に定義されているため、レイヤーのアウトソーシングが可能になります。しかし、各レイヤーは、「設計時」—契約とサービスレベルアグリーメントを交渉する必要がある—と「実行時」—長々とした要件文書が作成され、多くの「調整会議」が開催される—の両方で変換作業をもたらします。

多くのアーキテクトは、「人材」と政治で満ちているため、組織的な側面に触れることを恐れています。しかし、複雑なシステムの動作における類似性は、アーキテクトが上層部に携わり、組織システムにおけるボトルネックを取り除くのに役立ちます。

適切な「階層」で障害を取り除く

多くの開発者、アーキテクト、プロジェクトマネージャーは、組織から十分なサポートを受けていないことに不満を感じています。イノベーション、重要なプロジェクト、またはリファクタリングなどの重要なタスクのために、人員や資金を獲得するのは困難です。このような抵抗は、組織が開発チームとは異なる信念体系を共有していることが原因であることがよくあります。例えば、多くの伝統的な企業は、スピードよりも予測可能性を重視しています。そのため、彼らは一連の「チェックポイント」と「品質ゲート」を実装しており、これは骨の折れる時間のかかるプロセスにつながります。このような組織では、アジャイルまたはDevOpsの働き方を実装することは困難です。

このような組織の行動を変えるには、その信念を変える必要があります。そうでなければ、文化の壁に頭をぶつけ続けます。例えば、予測可能性を重視する組織は、多くの場合、規模の経済と一貫性を通じて既存のプロセスの最適化に焦点を当てています。デジタルの世界で競争するには、新しい市場機会を収穫することによって価値を生み出す、つまり *スピードの経済* を理解する必要があります。このような姿勢の変化は、ペントハウス近くの最上層で行われる必要があります。進歩を遂げるには、適切な階層までエレベーターに乗る必要があります。

報告ラインは、IT組織の信念体系の有用な指標となる可能性があります。例えば、CIOがCFO（最高財務責任者）に報告する場合、ITは単なるコスト要因として見なされ、市場機会のイノベーターやイネーブラーとしては見なされません。このような組織でテクノロジーのイノベーションを売ろうとすると、経営陣の頭の中ではすぐに「クライアントサーバー、ウェブなどでも同じことを聞きました。費用がかかっただけです。」となります。このような項目に対するペントハウスの見解を変えることは、ITイノベーションを成功させるための前提条件です。

ArchOps：垂直型アーキテクチャチームを構築する

機関室からペントハウスまでエレベーターで短時間移動したことで、アーキテクトが階層間を移動する必要性が強調されました。この洞察は、アーキテクチャチームの構築にも反映されるべきです。一般的に、中央アーキテクチャチームは、ペントハウスに近い位置に配置されていますが、技術革新やプロジェクトデリバリーとは切り離された「高レベル」のアーキテクトで構成されています。

単一のアーキテクトがすべての階層をカバーすることは非常に稀であるため、「垂直型」のアーキテクチャチーム、つまりエンタープライズアーキテクト、戦略アーキテクト、ソリューションアーキテクト、テクノロジー専門家など、さまざまなレベルのアーキテクトで構成されるチームを構築することが理にかなっています。それは、階段しかない既存の超高層ビルにエレベーターを取り付けるようなものです。突然、物事が速く動き始めます。

このようなチームの管理は容易ではありませんが、単一のチームが組織のすべての階層をカバーし、アーキテクトに必要なフィードバックループがあることを保証します。また、組織にスキルまたは設定が不足している場合でも、アーキテクチャチームが実行できるようになります。

エレベーターに乗り続ける

大規模なIT組織の変革に関する私の経験を、皮肉なタイトルの *37 Things One Architect Knows About IT Transformation* という本にまとめました。この本では、37個の楽しくて考えさせられる逸話を通して、上層部に関与するために必要なスキルについて説明しています。この本は、LeanpubでDRMフリーの電子書籍として、またはAmazonから印刷版として入手できます。

上層階で多くのことが起こっているため、一部のアーキテクトは、技術アーキテクトではなく組織デザイナーになるべきかどうか疑問に思うかもしれません。しかし、それは水を替える際に赤ん坊を一緒に捨ててしまうようなものです。組織を設計し、影響を与えるには、ソフトウェアデリバリーと技術革新を十分に理解する必要があります。現代のアーキテクトが価値を持ち、IT変革が成功するのは、技術的専門知識と組織能力の組み合わせによるものです。

ペントハウスの素晴らしい景色を楽しむために、エレベーターに乗って上階へ行き、二度と戻ってこないアーキテクトを見たことがあるかもしれません。急速な技術進化の世界では、そのような態度は、技術スキルをすぐに無価値なものにしてしまうことが保証されています。したがって、重要なのは、エレベーターを上にも下にも乗り続けることです。ペントハウスと機関室を繋げる唯一の方法です。

逆に、多くのアーキテクトは、上層階にアクセスできないと感じています。CEOや副社長が本当に彼らと話したいと思うでしょうか？驚くべきことに、多くの場合、彼らは話したいと思っています。多くのペントハウス居住者は、組織内の現実から切り離され、急速な技術進歩に混乱を感じています。そのため、彼らに手を差し伸べ、彼らの言葉で話し、同時に機関室にもしっかりと足を着けている人がいれば、感謝します。

ですから、アーキテクトのエレベーターに乗り続け、上層階をより頻繁に訪れ、そして必ず戻ってきてください！