■

「ITアーキテクトの教科書」を読む。

システム設計の先導者 ITアーキテクトの教科書[改訂版]

 ちょっとコンサル案件とか仕事で携わるようになったので、アーキテクトとか技術選定が出来るようになりたいなと思って読んでみた。2018年に出版されてるのに、前提としてウォーターフォールの保守的なシステム導入ストーリーを軸に紹介しており、ＡＤＤ(Attribute Driven Design)を基に、まず最初にハードウェアのサーバの購入選定から始まってしまったり、クラウドやDevOpsの記述が最後の方にちょこっと載ってる程度だったり、ネットワークやシステムのインターフェースの構成についてほとんど記述がなかったりと片手落ちな感じがする。ただ、色々実践で試行錯誤してきて編み出したテンプレートを自分で持ってる感じの記述だったので参考にはなった。特に、データベースの設計については他の領域に比べて異様に詳しい。

また備忘メモ。

・「プロジェクトマネージャが情報システムをリリースするまでの「プロジェクト」に責任を持つ一方、ＩＴアーキテクトはリリース後に残る「プロダクト(=情報システム)」に責任を持つ」

・アーキテクチャ設計に必要な情報とは、「ビジネス上のビジョン」と「システム化対象のドメイン分析結果」です。それらは具体的には、次の5つの成果物として作成する。(１)Vision Document(2)利害関係者マップ(3)概念機能モデル図(4)概念データモデル図(5)用語集(辞書)

・ＱＣＤの観点で要件をまとめる。要求仕様は矛盾や対立などトレードオフになる項目が生じるので合意形成が大切。

・非機能要件から決めてく。ユーティリティ・ツリーを作って、品質構成要素を分解して細かい要件を詰める。

・アーキテクトは全体問題を部分問題の集合に分解すべし。

・ＤＢ設計はまずトランザクションとマスタに分け、さらにマスタをコアとヒトに分けて正規化していく。

・アーキテクチャ分析手法として「ATAM」というものがあり、選定したアーキテクチャに応じてシステムの動きを推論文章にして説明責任を果たす。文章は何度でも練り直し、「なんでこのアーキテクチャにしたんだっけ？」という問いに答えられるようにする。ボトルネックになりそうな部分については対策も講じ、将来的にスケールする時のポイントとかも視野に入れて文章にしておく。

・詳細設計レベルでは、アーキテクトは重複機能をピックアップして共通コンポーネントを作る。

・ＤＢ設計として、createとreadは使っても良いが、update、deleteは使わないというルールを設定する。

・クラスの粒度は適切に。大は小を兼ねる式で大きなクラスを作ると理解するのが難しくなる。

・インデックス設計基準書を作り、メリットデメリットを整理して設定する。

・運用時に課題になりやすいので、排他制御(シリアライズ)仕様書を作って、「システム全体のデータ整合を保ちつつも、トランザクションの同時実行性を最大化するために昨日横断的な立場から排他制御の仕様を決める」必要がある。

・開発工程では、コーディング規約とアプリのフレームワークを固定化してプログラマの不要な自由を奪っておく。自由が多いほどバグが生まれやすくなる。Switch文の条件変数は列挙型(Enum)にするなど。

・保守開発はすればするほどアーキテクチャが崩れる。Immutable Infrastructureの思想。再構築するときはソースコードを正として仕様書を直していく。

・モノリスなシステムと機能単位のサービスに分割したマイクロサービス。スケールアウトしやすいようにトランザクションのスコープを短くする。

・DevOpsはビル建築でなく都市計画のようなもの。