Daily Archives: April 2, 2024

企業の運営維持は決してたやすいことではありません。ソフトウェアツールの台頭により、誰にとってもワークフローの多くの部分がより高速で、よりスムーズで、より一貫性のあるものになりましたが、ソフトウェアを稼働させ続けなければならない人たちにとってはそうではありません。それは、池を滑るように進んでいくアヒルについての使い古されたセリフのようなものです。水の上はすべて穏やかに見えますが、水面下では必死に足を動かしているのです。

何気なく使っているだけのエンドユーザーやマネージャー、経営幹部にとって、エンタープライズアーキテクトの仕事は魔法のようなものです。同期化や統合化、安定化などの終わりない作業はすべてコンピューターが行い、人は最も得意とする作業に集中できます。しかし、ウェブポータルやコラボレーションスタック、レポジトリオムニツールなどの順調な実行には、果てしない課題が隠れているのです。すべての進化にとって、エンタープライズアーキテクチャは依然として、誰もが完全に把握できていない作業や責任で溢れた新しい世界なのです。

エンタープライズアーキテクトはまだ、様々なことを学び、試している段階にあります。何をすべきか、さらに重要なことは何をできないかについてさらに学んでいます。ソフトウェアスタックを実行し続け、企業全体のすべての社員のワーキングライフをできる限りシンプルにする方法を模索する過程において多くの間違いを犯してきましたし、今後も何度も間違いを犯していく可能性があります。作業が高度に技術的で複雑なことがその理由の1つですが、エンタープライズアーキテクトが犯す以下のような罪（過ち）もその原因となっています。

保存するデータが多すぎる（または少なすぎる）

ソフトウェア開発者は何でも詰め込みすぎがちです。できることなら、すべてのデータをキャッシュし、すべての事象をログし、企業の限りない進化に関わるバックアップコピーを保管するでしょうが、これらのギガバイトやメタバイトはどんどん多くなっていってしまいます。一部のクラウドベンダーが提供する低コストのコールドストレージでも、データが大量になればコストは高額になります。

さらに困ったことには、データレイクがいっぱいになるにつれて、適切なビットを見つけるのがさらに困難になっていきます。「レイダース／失われたアーク《聖櫃》」の終盤に出てくる聖櫃と同じです。技術的にはすべての情報はそこにありますが、それを見つけることができるのでしょうか。

問題は、保持する情報が少なすぎると、それ自体による不具合やペインポイントが伴ってしまいます。規制が許す限り、すべてを破壊するデータ保持ポリシーを設定しようした企業もあります。しかしそうすると、あらゆる質問への回答を探そうにも、「ファイルが存在しない」という記憶喪失のような状態になってしまいます。誰も何もわからなくなってしまうのです。

正確なバランスを見つけることは不可能かもしれません。私たちにできることはただ、暗闇の中を手探りで電気のスイッチを捜すような事態を避けるために、適切な情報を簡単にアクセスできる構造で保管して、優れたデータストレージアーキテクチャを見つけることです。

1つのプラットフォームに依存しすぎる（または多数を採用しすぎる）

エンタープライズソフトウェアの最もシンプルな構築方法は、外部企業が構築した様々なツールやポータル、プラットフォームのの力を活用することです。作業の90％以上は、発注書にサインして少しだけグルーコードを書けば完了します。

しかし、企業の主要部分の構築に外部企業を頼ることには多くのリスクが伴います。非公開投資会社の中には、外部企業を買収して優秀な社員をすべて解雇し、相手が逃げられないとわかっていて価格を吊り上げるところもあるかもしれません。1つのプラットフォームですべてをインスタンス化することが急にひどくまずいことになり始めます。1つのプラットフォーム、単一のインターフェイスからくるシンプルさと一貫性をもう誰も覚えていないのです。

複数のプラットフォームを採用することもまた、同じぐらいに苦痛が伴います。ツールは相互運用でき、業界標準プロトコルに沿っているとセールスチームは約束するかもしれませんが、それだけではまだ到底十分ではありません。各プラットフォームがデータをSQLデータベータに保管していても、MySQLを使うものもあれば、PostgreSQLやOracleを使うものもあります。

正解は簡単には出ないのです。プラットフォームが多すぎるとバベルの塔のように実現不可能な計画になってしまいます。少なすぎるとベンダーロックインのリスクにつながり、契約更新のメールを開く際の諸々の苦痛が伴います。すべての開発を社内で実行することにかかるコストはまた別の問題です。

クラウドへのアウトソーシングが多すぎる（または少なすぎる）

クラウドによってエンタープライズアーキテクトの作業はかなり楽になりました。特定サイズのマシンが必要であれば、数分で利用できるようになります。発注書を作成する必要もなく、ラックスペースを探す必要もありません。クラウド企業にクレジットカードの番号を渡すだけで、他には何もする必要がないのです。

どんなマシンでも数分または数秒で利用できるメリットは確かに明らかですが、最大の欠点はそれにかかるコストです。クラウドコンピューティングは、社内での管理に比べて驚くほど高額です。そのコストは予想以上に高額なことが多いため、多くのCFOが毎月びくびくしながらクラウドの請求書を確認しています。

しかし自社で管理すると、スタッフやデータセンタなどを管理し、そのコストを払うことになります。それに伴う悩みや準拠すべき規制リストは延々と続き、低コストはつかの間の喜びになってしまいます。

エンタープライズアーキテクトの中にはクラウドで大きな成功を収めるものもいます。毎週、毎月、毎年のわずかな時間に需要が急増するのであれば、その負荷に対処するために数分または数時間サーバーを起動するだけで、社内で何かするより格段に安価になります。他の企業は皆、クラウドへの投資が多すぎたのか少なすぎたのか悩むことになります。

フレームワークを狂信的に受け入れる（または無視する）

現在のエンタープライズスタックの複雑さに伴い、優れたアーキテクトの中にはそれらを整理するのに役立つフレームワークを構築した人もいます。例えばOpen Group Architecture Format (TOGAF)。企業が必要とするほとんどすべてのもを構築する戦略的フレームワークです。TOGAFは、アーキテクチャ開発手法（ADM）やアーキテクチャ・コンプライアンス・フレームワーク（ACF)など、多数のガイドランやベストプラクティスを提供しています。その他、Zachmanフレームワークや連邦エンタープライズアーキテクチャなどのアプローチには、スタック構築において独自の規則や規制があります。

最も大きなメリットは一貫性かもしれません。スタッフ全員がテクニックや理論に慣れてれば、ソフトウェアを使いこなすのが容易になります。データやコードは（通常）構成されており、すべて予想できる場所に収まっています。

しかし人によっては多少行きすぎることもあります。ルールを採用するだけにとどまらず、狂信してしまうのです。スペックを徹底して読み、必ずルールに従って意思決定をしなければならなくなります。道から外れる者は災いなるかな。

全員がフレームワークを狂信し、オフィスの計画会議が喜んでルールに従う人たちで埋め尽くされていたとしても、別の問題が生まれることもあります。完璧なオープンソースコードであっても、自分たちが求めるアーキテクチャフレームワークに適合しないという理由だけでチームが拒否したり、ベンダーが優れたオプションを提供しても、適切な方向性のもとに開発されたものではないという理由だけで拒否してしまうこともあります。

何よりも方法論を遵守

フレームワークは構造を提供してくれますが、ずさんな行為や怠惰な行為、時には悪意のある行為の隠れ蓑になってしまうこともあります。チームの誰かが適切なTOGAFフォームに記入するのを待っているため、決定を長引かせてしまうこともあるかもしれません。改善を支援するルールと閉塞的な煩雑な手続きの違いは紙一重です。

以前一緒に仕事をしたある男性はアジャイル方法論の信者でそれをこじらせてしまったため、チームはアジャイルとは言えないもにになってしまいました。彼はミーティングでの儀式をすべて心得ており、先週書かれたばかりのコードをリファクタリングするために、数多くのストーリーポイントを「スプリント」に詰め込むのが得意でした。チームは、彼が納品することになっていたクレジットカードのチェックアウト方式の再構築においてそれほど速く動いているようには見えなかったのですが、各スプリントで獲得したアジャイルポイントのグラフを見るとオフィス内で最速に作業が進んでいるように見えました。

開発ワークフローを整理するためのなんらかの方法が必要です。プログラマーは、アジャイルかウォーターフォールかについて何日も延々と議論することができます。週末に1人だけで完了できない規模のプロジェクトであれば、なんらかの戦略が必要です。

目に見えるもの以上に方法論を信じるようになると問題が起こります。そうなると、賢いコーダーは、自分のコードがたいしたことをしなくてもシステムを操作して大きな成果を出してしまいます。

トレンドを追う（または無視する）

開発者は、エンタープライズアーキテクチャのための最新のアイディアやモデルに飛びつくのが大好きです。時には運よく新しいトレンドが彼らのニーズに合うこともあります。開発者のアプリケーションが、トレンドセッターが最初にそのアイディアを思い付くきっかけとなった良い例です。

しかしほとんどの場合、部分的にした当てはりません。ユースケースはトレンドに発想を与えたアプリケーションに似ているかもしれませんが、少々ごまかした後でのことです。一方、開発チームはそのコードをトレンドに合わせるために必死になっています。時には、完全に適合したコードの膨大なブロックが、以前流行っていた目標に合わせて書かれたというだけで破棄されてしまうこともあります。

ここで問題になるのは、流行を完全に無視することも命取りになるということです。確かに、ありがたいことに、コードは適切に機能するデータベースやフォーマット、コーディング標準、プロトコルを使い、当初のバージョンに忠実であり続けています。しかし、全世界が何らかのトレンドを追いかけたとしたら、すべてのベンダーやツールメーカー、将来の新入社員もそうしたことになります。トレンドや流行はある時点で標準となり、時にはもっとひどい場合は法的にコンプライアンスが義務付けられた要件となってしまいます。

エンタープライズアーキテクトに勝ち目はないということです。トレンドを追うと大衆が生み出す流行の奴隷になってしまい、トレンドを無視すると取り残されてしまいます。EAにできることは、トレンドを把握すべき組織の技術スタックやIT担当者のために、やるべき正しいことを慎重に行うしかないのです。