Category: Cyber Security

エンタープライズアーキテクチャにまつわる6つの大罪 – Cyber Tech

April 3, 2024
企業の運営維持は決してたやすいことではありません。ソフトウェアツールの台頭により、誰にとってもワークフローの多くの部分がより高速で、よりスムーズで、より一貫性のあるものになりましたが、ソフトウェアを稼働させ続けなければならない人たちにとってはそうではありません。それは、池を滑るように進んでいくアヒルについての使い古されたセリフのようなものです。水の上はすべて穏やかに見えますが、水面下では必死に足を動かしているのです。 何気なく使っているだけのエンドユーザーやマネージャー、経営幹部にとって、エンタープライズアーキテクトの仕事は魔法のようなものです。同期化や統合化、安定化などの終わりない作業はすべてコンピューターが行い、人は最も得意とする作業に集中できます。しかし、ウェブポータルやコラボレーションスタック、レポジトリオムニツールなどの順調な実行には、果てしない課題が隠れているのです。すべての進化にとって、エンタープライズアーキテクチャは依然として、誰もが完全に把握できていない作業や責任で溢れた新しい世界なのです。 エンタープライズアーキテクトはまだ、様々なことを学び、試している段階にあります。何をすべきか、さらに重要なことは何をできないかについてさらに学んでいます。ソフトウェアスタックを実行し続け、企業全体のすべての社員のワーキングライフをできる限りシンプルにする方法を模索する過程において多くの間違いを犯してきましたし、今後も何度も間違いを犯していく可能性があります。作業が高度に技術的で複雑なことがその理由の1つですが、エンタープライズアーキテクトが犯す以下のような罪（過ち）もその原因となっています。 保存するデータが多すぎる（または少なすぎる） ソフトウェア開発者は何でも詰め込みすぎがちです。できることなら、すべてのデータをキャッシュし、すべての事象をログし、企業の限りない進化に関わるバックアップコピーを保管するでしょうが、これらのギガバイトやメタバイトはどんどん多くなっていってしまいます。一部のクラウドベンダーが提供する低コストのコールドストレージでも、データが大量になればコストは高額になります。 さらに困ったことには、データレイクがいっぱいになるにつれて、適切なビットを見つけるのがさらに困難になっていきます。「レイダース／失われたアーク《聖櫃》」の終盤に出てくる聖櫃と同じです。技術的にはすべての情報はそこにありますが、それを見つけることができるのでしょうか。 問題は、保持する情報が少なすぎると、それ自体による不具合やペインポイントが伴ってしまいます。規制が許す限り、すべてを破壊するデータ保持ポリシーを設定しようした企業もあります。しかしそうすると、あらゆる質問への回答を探そうにも、「ファイルが存在しない」という記憶喪失のような状態になってしまいます。誰も何もわからなくなってしまうのです。 正確なバランスを見つけることは不可能かもしれません。私たちにできることはただ、暗闇の中を手探りで電気のスイッチを捜すような事態を避けるために、適切な情報を簡単にアクセスできる構造で保管して、優れたデータストレージアーキテクチャを見つけることです。 1つのプラットフォームに依存しすぎる（または多数を採用しすぎる） エンタープライズソフトウェアの最もシンプルな構築方法は、外部企業が構築した様々なツールやポータル、プラットフォームのの力を活用することです。作業の90％以上は、発注書にサインして少しだけグルーコードを書けば完了します。 しかし、企業の主要部分の構築に外部企業を頼ることには多くのリスクが伴います。非公開投資会社の中には、外部企業を買収して優秀な社員をすべて解雇し、相手が逃げられないとわかっていて価格を吊り上げるところもあるかもしれません。1つのプラットフォームですべてをインスタンス化することが急にひどくまずいことになり始めます。1つのプラットフォーム、単一のインターフェイスからくるシンプルさと一貫性をもう誰も覚えていないのです。 複数のプラットフォームを採用することもまた、同じぐらいに苦痛が伴います。ツールは相互運用でき、業界標準プロトコルに沿っているとセールスチームは約束するかもしれませんが、それだけではまだ到底十分ではありません。各プラットフォームがデータをSQLデータベータに保管していても、MySQLを使うものもあれば、PostgreSQLやOracleを使うものもあります。 正解は簡単には出ないのです。プラットフォームが多すぎるとバベルの塔のように実現不可能な計画になってしまいます。少なすぎるとベンダーロックインのリスクにつながり、契約更新のメールを開く際の諸々の苦痛が伴います。すべての開発を社内で実行することにかかるコストはまた別の問題です。 クラウドへのアウトソーシングが多すぎる（または少なすぎる） クラウドによってエンタープライズアーキテクトの作業はかなり楽になりました。特定サイズのマシンが必要であれば、数分で利用できるようになります。発注書を作成する必要もなく、ラックスペースを探す必要もありません。クラウド企業にクレジットカードの番号を渡すだけで、他には何もする必要がないのです。 どんなマシンでも数分または数秒で利用できるメリットは確かに明らかですが、最大の欠点はそれにかかるコストです。クラウドコンピューティングは、社内での管理に比べて驚くほど高額です。そのコストは予想以上に高額なことが多いため、多くのCFOが毎月びくびくしながらクラウドの請求書を確認しています。 しかし自社で管理すると、スタッフやデータセンタなどを管理し、そのコストを払うことになります。それに伴う悩みや準拠すべき規制リストは延々と続き、低コストはつかの間の喜びになってしまいます。 エンタープライズアーキテクトの中にはクラウドで大きな成功を収めるものもいます。毎週、毎月、毎年のわずかな時間に需要が急増するのであれば、その負荷に対処するために数分または数時間サーバーを起動するだけで、社内で何かするより格段に安価になります。他の企業は皆、クラウドへの投資が多すぎたのか少なすぎたのか悩むことになります。 フレームワークを狂信的に受け入れる（または無視する） 現在のエンタープライズスタックの複雑さに伴い、優れたアーキテクトの中にはそれらを整理するのに役立つフレームワークを構築した人もいます。例えばOpen Group Structure Format (TOGAF)。企業が必要とするほとんどすべてのもを構築する戦略的フレームワークです。TOGAFは、アーキテクチャ開発手法（ADM）やアーキテクチャ・コンプライアンス・フレームワーク（ACF)など、多数のガイドランやベストプラクティスを提供しています。その他、Zachmanフレームワークや連邦エンタープライズアーキテクチャなどのアプローチには、スタック構築において独自の規則や規制があります。 最も大きなメリットは一貫性かもしれません。スタッフ全員がテクニックや理論に慣れてれば、ソフトウェアを使いこなすのが容易になります。データやコードは（通常）構成されており、すべて予想できる場所に収まっています。...
x