ソフトウェアアーキテクチャのコンサルティング
何を変えるべきか。その判断を、何が支えるのか。
変更しにくいアプリケーションだからといって、必ず作り直す必要があるわけではありません。処理が遅いからといって、必ずインフラを増やす必要があるわけでもありません。アプリケーション、データ、連携、運用環境を調べ、問題を理解します。評価では、分かっていること、不確かなこと、選択肢の比較を明らかにします。
繰り返し起きる問題、アーキテクチャへの懸念、技術評価が必要な技術投資案をお聞かせください。
ソフトウェアアーキテクチャのレビュー
アプリケーションの構成要素、データ、インフラがどのように連携するかをたどります。保守、性能、予定している変更に影響する依存関係と制約を特定します。
- 構成要素・依存関係の図
- アーキテクチャの評価結果
- 追加調査が必要な領域
モダナイゼーション計画
既存アプリケーションの拡張、特定の構成要素の置き換え、段階的な再構築を比較します。各選択肢の前提、移行作業、トレードオフを文書化します。
- 選択肢とトレードオフ
- 順序を付けた優先事項
- 推奨する範囲
連携計画
提案された変更を、現在使っているシステムにどう組み込むか定義します。実装前に、データフロー、インターフェース要件、移行手順を明確にします。
- システムインターフェース要件
- データフローの定義
- 移行・検証手順
運用準備
変更後のシステムを誰が運用・保守するかを明確にします。実装計画の一部として、監視、問題対応、サポートの役割分担を確認します。
- 運用上の責任分担
- 問題対応・エスカレーション手順
- 保守の優先事項
評価の例
対策を選ぶ前に、ボトルネックを調べる。
例えば、月末になるとレポートの生成に大幅に時間がかかるとします。まず、影響を受けるリクエスト、データ量、発生条件を確認します。その後、クエリの動作、アプリケーションの処理、インフラ使用状況を調べられます。評価結果から、限定的な修正と広範なアーキテクチャ変更を区別し、提案した作業で問題が解決するかを確認する方法を定めます。
- 対象の処理と、有用な性能指標を定義します。
- 観測された動作と、原因に関する推測を区別します。
- 各選択肢の工数、依存関係、必要な検証を比較します。
- 定義症状、事業への影響、評価の境界を記録します。
- 調査関連する構成要素と、利用できるシステム上の根拠を確認します。
- 比較選択肢を評価し、未確認の前提を明示します。
- 計画実装の優先順位と、結果の検証方法を合意します。
評価の一例です。調査の深さと利用できる根拠は、合意した範囲およびアクセス権に依存します。
コンサルティングの成果物
次の一歩を明確にする評価結果。
評価の開始前に、問い、利用可能なアクセス、期待する成果を合意します。
評価の境界を定める
必要な判断、事業への影響、関係するシステムを特定します。利用できる資料、コード、設定、測定値を確認し、評価の制限を記録します。
お渡しする成果物評価概要と必要情報評価結果を説明
観測内容を文書化し、現実的な選択肢を比較します。推奨の理由、依存関係、引き続き調査が必要な問いを説明します。
お渡しする成果物技術評価結果と選択肢の比較実装を計画
選んだ方法を、作業順序、責任分担、検証手順に落とし込みます。移行の要件と、各段階へ進む条件を特定します。
お渡しする成果物優先順位付き計画と受け入れ基準
ソフトウェアアーキテクチャのレビューは何を対象にしますか？
範囲は、必要な判断によって異なります。アプリケーションの構成要素、データの流れ、連携、インフラ、運用上の依存関係などを対象にできます。調べる領域と利用できる根拠を合意したうえで、結果、制限、推奨する次のステップを文書化します。
モダナイゼーションと再構築の判断を支援してもらえますか？
はい。必要な変更に対応できるかという観点から、現在のアプリケーションを評価します。既存コードの改善、特定の構成要素の置き換え、段階的な再構築を、依存関係、データ移行、継続運用、実装工数を考慮して比較できます。
提案内容を自社チームで実装できますか？
はい。優先事項、技術要件、検証手順を含め、既存チーム向けの成果物として整えることができます。NorroSoftの開発、データ、クラウドサービスによる実装も相談できます。実装と継続的なサポートには、それぞれ別途合意した範囲が必要です。
次のステップ
今、判断が必要なことをお聞かせください。
システム、懸念事項、検討中の選択肢をご説明ください。役立つ評価の範囲を一緒に定めます。