つまり、基本的にソリューションアーキテクチャを実行しているということです。私が知っている方法論はありません-少なくとも4ページ以下で簡潔に説明されている方法論はありません(私が思いついたもの)。
あなたの質問に答えるには:
1-制約を理解する
明らかなのは、解決しようとしている問題とその背景を理解することです。
あなたはフリーハンドを持っているかもしれませんし、既存の標準に制約されているかもしれません-私が働いている場所(政府機関で)私たちはたくさんの異なる技術とシステムを持っています、そして私たちが何か他のものを見ているときは厄介な順序があります。私たちが好むテクノロジーと私たちが成長しようとしているテクノロジー。
Zachmanはエンタープライズアーキテクチャフレームワークです。面白いと思うかもしれませんが、特にソリューションレベルで多くの関連性があるとは思えません。TOGAFはもう1つです。
2-ビュー
TOGAF(およびZachman)についてのことは、さまざまな「ビュー」の概念があることです。たとえば、次のようになります。
- セキュリティビュー
- データビュー
- テクノロジービュー
- アプリケーションビュー
- プロセスビュー
- サポートビュー
- 運用ビュー
- 請求ビュー
- ユーザービュー
- パフォーマンスなど...
計画/設計しているシステムに関連するビューを慎重に検討する必要があります。プロジェクト/システムが開発されるとき、これらを覚えておく必要があります。彼らは主要な決定を導くのに役立ちます。私はこのアポアーチ/考え方も好きです。なぜなら、それは「征服を分割する」という方針に沿って機能するからです。大きなパズルを小さなパズルに分割します。
3-モデリング
発泡スチロールのボールを使用することはこれまで聞いたことがありませんが、関係を触覚的にモデル化するというアイデアは非常に魅力的です。ただし、大きなシステムの場合は、非常に大きな部屋が必要になる可能性があります:)
ホワイトボードは、クラスがどのように関連しているか(そして実際には何でも)を調査するための私のお気に入りの方法です。私はあなたと一緒にデジタルカメラ、またはカメラが組み込まれた電話を持っていることを強くお勧めします。私は後者を使用します。必要に応じてホワイトボードの写真を撮り、会議後にコンピューターと同期して、出席者にコピーを電子メールで送信します。情報を取得するのは非常に簡単で、あなたも非常にプロフェッショナルに見えます。
UMLは非常に便利ですが、オーディエンスに応じて、使用するビットを選択する必要がある場合があります。これは、物事をどの程度正式に見たいかによって異なります。
モデリングツールでシステムを正式にモデリングする(そして、Visioのように単なるダイアグラム作成ではなく、正式なUMLを使用する)ことも非常に便利です。これを行うことに慣れていない場合は、通過しなければならない痛みのしきい値があることに気付くでしょうが、一般的には次の場合に価値があります。
- システムが特定のサイズ/複雑さを超えている、または
- 使用する小さなシステムがたくさんあります。
4-プロジェクト方法論
私はアジャイル/スクラムの大ファンです。私はアジャイルの原則をslnアーキテクチャに適用する方法を検討していますが、まだ何もありません。
私は昨年Tech-Edでの良いセッションに参加しました(ARC202ケビンフランシスと建築家の役割に挑戦)-私はここに記事を書いています。
これは素晴らしいセッションでした。方法論に関係なく、(ソリューション?)アーキテクトがプロジェクトにどのように取り組むべきかを誰かが説明するのを見たのは初めてです。Kevinsはアジャイルの提唱者であり、彼の講演はそれに焦点を当てていたため、アーキテクチャとアジャイルをどのように適合させるかという2倍の成果が得られました。