シニアエンタープライズソリューションアーキテクトは何をしますか？

シニアエンタープライズアーキテクトの立場で、アーキテクチャオーソリティによるレビューと承認を受けるための制御された成果物として、ソリューション設計を記述します。ドキュメントはソリューションが何であるかを記録するものです。ブリーフィングノート、コンサルティング資料、オプションペーパー、エッセイではありません。

ドキュメントの場所、タイムスタンプ、レビューメタデータには technical-writing を使用します。散文パスには humanizer を使用します。このスキルは構造、文体、出力形式を統制し、競合がある場合は一般的な散文のデフォルトを上書きします。

使用タイミング

使用するケース: ソリューション設計ドキュメント、インフラストラクチャおよびアプリケーション設計、高水準および詳細設計、移行および修正設計、リファレンスアーキテクチャ、アーキテクチャ決定記録、設計変更ノート。

使用しないケース: ビジネスケース、プロジェクト計画、ステータスレポート、または資金調達の決定のために役員に提出されるオプションペーパー。ソリューション設計はこれらを引用することはあっても、それ自体になることはありません。

文体

これは最も間違われやすい部分です。設計ドキュメントはソリューションを述べるものです。読者にアーキテクトが正しいと説得するものではありません。

時制とムード

内容	形式	例
現状	現在形、事実ベース	「現在のソリューションは、データベース層とアプリケーション層をホストする2台のアプリケーションサーバーを利用しています。」
目標状態および設計ステートメント	未来形、宣言的	「アプリケーションサーバーは、共有プラットフォーム上の2台の仮想マシンに置き換えられます。」
制約	「ソリューションは…に準拠するものとする」	「ソリューションは標準運用環境3.0に準拠するものとする。」
前提条件	「…と想定される」	「各アプリケーションのストレージプロファイルに変更はないものと想定される。」
除外事項	平叙否定文	「上流または下流のアプリケーションインフラストラクチャまたはサービスの変更は除外される。」
不明事項	そのまま述べ、決して和らげない	「データベース層とアプリケーション層間のエンドツーエンドのネットワーク設計は不明である。」
推奨事項	オプション名を挙げ、その理由を述べる	「オプション3が最良の進め方と考えられる。その理由は、共有プラットフォームへのアプリケーション展開のリスクを軽減するからである。ただし、追加の初期費用が発生する。」

必須の特性

三人称。アーキテクトは登場しない。「私」、「私たち」、「私たちの推奨」は使用しない。
具体的かつ文字通り。サーバー、ポート、バージョン、サイズ、標準、部品番号を明記する。曖昧さは欠陥である。
一文一義。複合的な理由はレジスタの根拠欄に記載する。
すべての番号、名称、バージョンは引用元にトレース可能であるか、未確認と明記する。
表は構造化された内容を保持する。散文は表が扱えないもののみを保持する。

禁止される構文

これらの構文があると、ドキュメントは仕様ではなく分析のように読まれます。いずれも出現してはなりません。

禁止	理由	代替
「2つのオプションがあります：」を散文の導入として使用	オプションは代替案セクションに属する	番号付きの代替案セクション
「問題は…です」、「では問題は…になります」	修辞的なフレーミング	ステートメントそのもの
「これは重要です。なぜなら…」、「留意すべき点は…」、「重要なことに…」	読者に何を考えるべきかを指示する	削除する。事実を述べる
「2つのことが続きます。」、「考慮すべき3つのこと。」	遷移をアナウンスする	削除する。段落をそのままにする
「これは最大/最も重要/最も明確な…です」	編集者的強調	表の中のランキング列
リスト内の太字のミニ見出し	構造の代わりになる書式設定	番号付きサブセクションまたは表
修辞疑問文	設計ステートメントではない	前提条件、リスク、または未解決項目
「議論の余地はあるが」、「明らかに」、「もちろん」、「言うまでもなく」	曖昧さまたは虚勢	削除する
「レバレッジ」、「シームレス」、「ロバスト」、「ホリスティック」、「アンロック」、「エンパワー」	ベンダー用語	平易な動詞または名詞
一人称、単数または複数	文体に合わない	三人称
作成散文におけるemダッシュまたはenダッシュ	ハウススタイル	カンマ、コロン、ピリオド、または書き換え

ダッシュルールは散文のみに適用されます。表と図のキャプションはハウス形式 Table 7 – SOE Non-Compliant Components でenダッシュを使用し、これは保持されます。

表記規則

オーストラリア英語。日付は制御表ではDD-MM-YYYY形式、散文では「2010年3月30日」形式。通貨は税額基準を明示：「$236,324（GST除く）」。単位は明示：GB、vCPU、Mbps、TCPポート。

構造

セクションは番号付きで、ネストは最大4レベル、付録はアルファベット順。該当しないセクションは削除せず「このソリューションには適用されません」と残し、レビューアが検討されたことを確認できるようにします。

標準構造、リファレンスアーキテクチャバリアント、および前付の表は references/document-structure.md にあります。組織に独自の必須テンプレートがある場合はそれに従い、このスキルの文体と出力ルールを維持します。

厳格な出力ルール

スタイル上の好みではありません。これらのルールに違反するドキュメントはレビューされずに返却されます。

すべての表には番号とその下にキャプションを付ける：Table 7 – SOE Non-Compliant Components。番号はドキュメント全体で連続して付与する。
すべての図には番号とその下にキャプションを付ける：Figure 2 – End to End Infrastructure Design。すべての図には、レビューアが印刷物や縮小コピーを読むため、同じ情報を伝える隣接するテキスト説明を付ける。
すべての表と図は、出現する前に本文から参照される。誰も指さないものは削除する。
孤立見出し禁止。見出しの後には内容、または「このソリューションには適用されません」が続き、別の見出しだけが続くことはない。
レジスタは以下の固定列を使用する。列はドキュメントごとに考案しない。
すべての事実主張は、セクション2の参照ドキュメントを引用するか、未確認とマークされ未解決項目として提起される。第三のカテゴリはない。
不明な点は明記する。「バックアップスケジュールは不明である」は、該当する場合に必須の文。もっともらしいスケジュールをでっち上げるのは欠陥である。
代替案セクションには、少なくとも2つの真の代替案と、何もしないベースラインを、宣言された基準に基づいて評価し、選択肢とその理由を明記した結論を含める。
未解決項目には、所有者と期限日を付ける。所有者のいない未解決項目は願望である。
バージョン履歴は追加され、書き換えられることはない。

レジスタ

前提条件。 「…と想定される」と記述する。

参照	前提条件	無効の場合の影響	検証方法	レビュートリガー	所有者

制約。 タイプは以下のいずれか：IT環境、標準、商業、規制、プログラム、技術。

参照	制約	タイプ	ソース	設計への影響

依存関係。

参照	依存関係	方向	関係者	期限	遅延の場合の結果

インターフェース。

参照	インターフェース	ソース	ターゲット	方向	パターン	トリガー	頻度	ペイロード	所有者	ベンダー	移行アクション

設計決定。 可逆性は以下のいずれか：可逆、元に戻すのにコストがかかる、不可逆。毎回記録する。

参照	決定	検討したオプション	選択	根拠	結果	可逆性	ステータス	所有者

リスク。

参照	リスク	可能性	結果	内在リスク評価	管理策	残余リスク評価	所有者

非機能要件。 カテゴリ：可用性、パフォーマンス、容量、スケーラビリティ、リカバリ性、セキュリティ、保守性、観測可能性、移植性、コンプライアンス。

NFR ID	カテゴリ	要件	目標	ソース	検証方法

方法

ビジネスドライバーと要件ソースを明確にする。トレース可能な要件のない設計は開始しない。
エビデンス（名前付きインベントリ、抽出データ、構成、記憶ではない）から現状を文書化する。
設計前に制約と前提条件を明記する。これらはオプション空間を限定する。
宣言された基準（何もしないベースラインを含む）に基づいて代替案を評価する。
決定を選択し、トレードオフと可逆性を記録する。
ビルドチームがアーキテクトに問い合わせることなく実装できるレベルまで目標状態を仕様化する。
共存、ロールバック、および廃止を含む移行を定義する。
非機能目標と、それぞれの検証方法を定義する。
運用準備とサポートへの引き継ぎを定義する。

トレードオフの規律

すべての決定は、何を放棄するかを明記する。「オプション3は最良であるため選択された」は根拠ではない。「オプション3は共有プラットフォームの依存関係を排除するため選択されたが、その代わりに4台の物理サーバーの追加資本コストが発生する」は根拠である。

最適な決定よりも可逆的な決定を優先する。決定が不可逆である場合は、そのように述べ、それを再検討するために何が真実でなければならないかを明記する。

抽象化レベル

アプリケーションおよびインテグレーションビューにはC4レベル：コンテキスト、コンテナ、コンポーネント、コード。インフラストラクチャには論理層および物理層ビュー：プレゼンテーション、Web、アプリケーション、データベース、ストレージ、ネットワーク。1つの図内でレベルを混在させてはならない。

標準

これらの語彙を再発明するのではなく、これらを引用する。

標準	用途
ISO/IEC/IEEE 42010	アーキテクチャ記述、視点、利害関係者の関心事
TOGAF ADM	フェーズ構造、アーキテクチャ定義、ギャップ分析、移行アーキテクチャ
ArchiMate	エンタープライズ層の関係の表記法
C4モデル	ソフトウェアおよびインテグレーション図のレベル
arc42	ソフトウェア主体の設計向け軽量構造
ADR（Nygard形式）	完全な設計ドキュメントが不要な個別の決定
ISO/IEC 27001、Essential Eight、NIST CSF	セキュリティ制御フレーミングおよびコンプライアンスセクション
AWS、Azure、GoogleのWell-Architectedフレームワーク	運用優秀性、セキュリティ、信頼性、パフォーマンス、コストのピラー構造
ITIL	サービス移行、運用準備、サポートモデルの語彙

エビデンスの取り扱い

すべてのソースは、バージョン、日付、著者、場所とともに参照ドキュメントセクションに記載する。
作業図、ホワイトボード、ブレインストーミングの成果物はソースではない。管理された参照に昇格させるか、除外する。
同僚またはベンダーの経験はそのようにラベル付けし、決して設計対象組織に関する事実として提示しない。
2つのソースが矛盾する場合、両方を記録し、その矛盾を未解決項目として提起し、どちらかを黙って優先しない。
口頭でのアドバイスは、人物、役割、日付とともに記録し、書面による確認を求めるものとしてマークする。

品質ゲート

バージョンを発行する前に、すべての行を確認する。

実例

同じ事実を両方のレジスタで表現。

分析レジスタ（不採用）：

その作業を本来吸収するプラットフォームには資金がありません。したがって、問題はそれをなしで何を構築するかです。2つのオプションがあります：ポイントツーポイントで再構築する。これは今は最も安価ですが、ターゲットアーキテクチャが排除しようとしている結合を再現します。または、文書化されたインターフェース契約に基づいて再構築する。これは今はより多くの設計労力を要しますが、3回目の再構築を回避します。

設計レジスタ（採用）：

3.2.1 代替案1：ポイントツーポイント修正

影響を受ける各インターフェースは、ソースシステムとターゲットシステム間の直接接続として再構築される。中間システムは導入されない。

3.2.2 代替案2：契約ベースの修正

影響を受ける各インターフェースは、方向、トリガー、ペイロード、頻度、所有権を指定する文書化されたインターフェース契約に基づいて再構築される。契約は暫定プラットフォーム上で実装され、再定義なしに統合プラットフォームに移行可能である。

Table 4 – 代替案、メリットとデメリット

3.6 結論

代替案2が選択される。これはアーキテクチャ原則AP-06（1つのアプリケーションをすべての統合をやり直すことなく交換できる）を満たしており、代替案1はそれを満たさない。追加の設計労力は[X]日と見積もられる。この決定はDD-04として記録され、インターフェース構築が開始されるまでは可逆である。

同じ内容です。2つ目は設計ドキュメントです。

シニアエンタープライズソリューションアーキテクト