DevOps戦略:エンタープライズ・アーキテクチャ − DDevOps#12

devops-practices-enterprise-architecture1
DADフレームワークは、アーキテクチャに関連する活動や、アーキテクチャ/オーナーという役割を明確に定義しており、エンタープライズ対応(Enterprise-aware)という哲学を前面に打ち出している。我々の経験では、ディシプリンドDevOpsの考え方を組織に適用するにあたって、アジャイル・エンタープライズ・アーキテクチャは、実現のための鍵となることが実証されてきた。
一般的なDevOps戦略に加えて、DevOpsをサポートするエンタープライズ・アーキテクチャの活動がいくつかあるので、以下に見ていこう。
  • 再利用のマインドセット エンタープライズ・アーキテクチャの労力が将来に実を結ぶために重要なことは、IT部門、そして組織全体に再利用のマインドセットを定着させることだ。再利用のマインドセットが定着したデリバリー・チームは、既存のデータソース、サービス、コンポーネント、フレームワーク、テンプレート、および他の多くの資産を活用するように努めている。このマインドセットは、エンタープライズ・アーキテクト(理想的には、アーキテクチャ・オーナーとしてITデリバリー・チームのアクティブメンバーであることが望ましい)による教育、コーチングとメンタリングを通して植え付けられる。また、ITデリバリー・チームが使うべき、あるいは使用すべきではない技術を示す技術ロードマップによって可能となる。そしてもちろん、発見しやすく理解しやすく、適用して真の価値を提供できる高品質なアセットの存在が再利用を可能にする。
  • 技術的負債のマインドセット エンタープライズ・アーキテクチャの取り組みでは、デリバリーチームが技術的負債を発見した時にその負債を返済するよう、彼らを動機付けるアプローチを推進すべきだ。さらに重要なのは、最初の段階でそのような負債をかぶらないようにすることだ。多くの技術的負債戦略が、DADフレームワークに埋め込まれているが、技術的負債のマインドセットなしでは、無駄に終わることが珍しく無い。エンタープライズアーキテクト(しばしば、デリバリー・チームのアーキテクチャ・オーナーとして機能する)は、技術的負債に関連する問題を中心に、開発者をコーチし、メンターとしての役割を果たす必要がある。同様に、この技術的負債にかかわってコラボレートする、よりシニアなマネージャーや利害関係者を教育するために役立つはずだ。技術的負債を回避し取り除くためには投資が必要であり、普通IT投資の判断は彼らの手にあるからだ。
  • 開発のガイドライン エンタープライズ・アーキテクチャの重要な側面は、ITデリバリー・チーム全体で共通の懸念に対処するためのガイドラインの開発である。組織は、セキュリティガイドライン、接続のガイドライン、コーディング標準、および他の多くを開発することがある。共通の開発ガイドラインに準ずることで、ITデリバリーチームはより一貫性のあるソリューションを構築し、それは転じて本番稼働時により簡単に操作できサポートできるソリューションとなり、DevOps戦略をサポートする。共通の開発ガイドラインの潜在的な欠点は、開発者がそれらによって制約を感じるかもしれないということだ。この問題への対抗策は、ガイドラインはデリバリーチームとのコラボレーションを通して開発され進化されるべきであり、上から課せられるべきではない。
  • 技術ロードマップ エンタープライズ・アーキテクチャでは、技術ロードマップの定義、サポート、そしてそれを進化させるという活動が含まれ、そのロードマップが組織の他の活動(同様に重要なビジネスのロードマップはプロダクトマネージメントの範疇)をガイドする。このロードマップは、本番環境に共通の一貫した技術的インフラストラクチャーを構築することを助ける。この技術インフラが共通のDevOpsプラクティス―継続的デプロイ、自動化されたエンドトゥエンドのリグレッションテスト環境、以前のブログでも議論した運用のモニタリング―を実現するのだ。
技術ロードマップの重要な側面は、既存のITインフラストラクチャと、そのインフラの将来ビジョンの両方を捉えることだ。ここでITインフラとは、ネットワーク、ソフトウェアサービス、サーバ、ミドルウェア、および主要な構成要素となる少数のデータ・ソースが含まれている。以下の図に見られるように、技術インフラへのビジョンを作る際、考慮すべき2つの問題があります。
  1. オーナーシップ あなたの組織は自身のインフラストラクチャを所有し運営するのか、あるいは外部の専門家にその一部または全部をアウトソースするのだろうか?アウトソーシングオプションには、他の組織(HPやIBMなど)が外部の組織(AmazonやGoogleのような)が提供するクラウド技術を使ってあなたの会社のデータセンターを運用するという従来のアプローチも含まれる。独自のインフラを所有することの利点は、かなりの部分をコントロールできることだ。これはITソリューションのセキュリティと整合性を保証しなければならないときに非常に重要だ。アウトソーシングは、潜在的に規模の経済からITインフラストラクチャとコスト削減を管理する上でより大きな柔軟性をもたらす。しかし、アウトソーシングは、より洗練されたガバナンスを必要とし、前述した従来のアプローチの場合には、アウトソーサーがあなたの要求にタイムリーに応答できない場合、潜在的なボトルネックになる。
  2. 仮想化 特定のソリューションのニーズを満たすために構築された、あるいは可鍛性(※訳注)と進化のしやすさを実現するためにソフトウェア化(softwarization)されたITインフラストラクチャの構成要素があるか?ソフトウェア化―ソフトウェア定義インフラストラクチャ(SDI)として知られている―では、ITインフラストラクチャの要素が完全に仮想化される。ソフトウェア化は、ソフトウェア定義データセンター(SDDC)、ソフトウェア定義(SDS)、およびソフトウェア定義ネットワーク(SDN)を包含したITインフラストラクチャモデルを含む。ソフトウェア化は、通常、ファイアウォールの両側で、クラウドベースのテクノロジを使って実装される。さらに進んだ仮想化のソリューションでは、ITインフラストラクチャの柔軟性とプログラマビリティを高めており、それによってリソースの最適化を可能にする。その一方で、仮想化がもたらすより大きな柔軟性は、あなたのテスト作業の複雑さを増加させ、運用での課題をシミュレーションすることをより難しくする。
    ※訳注 ”可鍛性”:原文では”malleable”。外的圧力を受けても破壊されることなく変形できる能力。ここでは、ビジネス等の外部環境の変化に呼応して変化できる柔軟性という意味。
ITインフラ戦略クアドラント
オリジナル:DevOps Strategies: Enterprise Architecture
(翻訳 藤井智弘)
Pocket