Mike Hepburn
Ilaria Doria
エマージング・アーキテクチャとは、プロダクト開発を前進させるのに十分なアーキテクチャを持ちつつ、より多くの情報が得られるにつれてアーキテクチャの変更ができるほど柔軟であるというプラクティスです。
アーキテクチャはソフトウェアシステムを構築する際に重要な関心事です。ダイナミックな環境での成功には、柔軟性・適応性・変化への意欲が鍵となります。エマージング・アーキテクチャとは、ビジネス・顧客・規制上のニーズが変化するにつれて、アーキテクチャを実験し適応させることを意味します。
ソフトウェアアーキテクチャは、設計・構築の観点だけでなく、複数の視点からうまく機能する必要があります。異なるチームやペルソナは異なる視点を持ちます。
例えば、デプロイ・テスト・運用管理などです。良いソフトウェアアーキテクチャは、これらの懸念点をできるだけ多く対処しようとします。
正しく行うことは、現在および潜在的な将来の要件をレビューし、アーキテクチャがその要件にどう適合しているかを評価する継続的なバランス作業です。\
ある程度のアップフロントなアーキテクチャと設計作業は常に必要であり、不確実な問題への答えが見つかり、問題の集合的理解に情報が加わるにつれて初期アーキテクチャが変化できるよう、柔軟性と正直さが伴わなければなりません。プロダクトのライフサイクルを通じてアーキテクチャを継続的に改善する能力もまた重要な目標です。
エマージング・アーキテクチャの考え方は、高いビジネス価値を持つ機能を提供するために必要な論理アーキテクチャを最低限理解しながら、ビジネスドメインに関する十分な知識と共有理解を得ることにあります。この段階では、疎結合サービス・イベント駆動アーキテクチャ・API・ストリーミングアプリケーションなど、主要なアーキテクチャアプローチを決定でき、その後の反復で洗練されます。\
エマージング・アーキテクチャのアプローチを取ることで、まだビジネス価値を生み出さない包括的なアーキテクチャの構築に時間を投資しません。プロダクトの将来的な方向性や機能の優先度変更により、そのアーキテクチャが結果的に使われないこともあり、時間の無駄を防ぐことができます。
テクニカルリーダーが指示を出すのではなく、方向性を示すとき、チームは開始に必要な情報を探し、コラボレーションして反復できます。
これを実現する一つの方法は、並列思考のエクササイズです。チームの最上位者一人の考え方を追うのではなく、全員が協働して同時にアイデアを出します。焦点は現状ではなく「あり得ること」に置かれ、全員が前進する方法を設計できます。誰が正しくて誰が間違っているかではありません。
知識労働において、人間は通常最もコストのかかるリソースです。したがって、単調な作業や差別化されない手動作業を減らすことが合理的です。これは終わりなく全てを自動化しようとする傾向であり、プロダクトの品質とフィードバックを大幅に向上させます。
テクノロジーの世界では、データに溢れています。しかし、アプリケーションやシステムで利用可能なすべてのデータを最大限に活用しているでしょうか?アーキテクチャ設計にあたっては、アプリケーションとインフラで利用可能なデータの量と質を慎重に検討する必要があります。多くの場合、帯域幅や遅延の制限から中央処理コアにすべてのデータを送り返すことが物理的に不可能なため、またはデータの移動が単純にコスト高(クラウドを考えてみてください)なため、エッジデバイスにデータ処理を近づけるエンジニアリングの判断とトレードオフが必要となります。
私たちはしばしば、失われるデータの量を忘れがちです。この失われたデータは、ビジネスにとって巨大な機会損失の源となりえます。これはクラウド・IoT・産業用途、さらにはモバイル端末でのデータ処理を含むモバイルウェブのユースケースでも発生します。
エマージング・アーキテクチャのプラクティスをどのように採用するかについての詳細は、イベント・ストーミングとビッグピクチャーを参照してください。
エマージング・アーキテクチャ をチームや顧客、ステークホルダーと実施するにあたりより詳細にお知りになりたい場合は、以下のリンクを参照してください。