ITアーキテクチャーのセオリー読んだ
正月は特にどこかに行ったりもしてないけど、こんないい機会もないなと思ってとりあえず2冊本を読んでみました。
1つ目は「ITアーキテクチャーのセオリー」2つ目は「暇と退屈の倫理学」という本です。
今日は前者について書いてみます。
「ITアーキテクチャーのセオリー」はまさに会社で直面している課題にピンポイントで回答している書籍。
弊社は教育から人材紹介まで一気通貫に手掛けているという点で他社との大きな差別化ができている企業ではあるけど、まさにこの本で言うところの（というより一般的な用語でもあるが）エンタープライズアーキテクチャー（EA)を考えていく必要があると教えてくれた本でした。漠然とEAを考えてもわからないけど、細分化するとBA(Business Architecture)とかDA(Data Architecture)やAA(Application Architecture), TA(Technology Architecture)とかになっていきます。
ビジネスアーキテクチャ（Business Architecture）
ビジネスに直結する、ヒト、モノ、カネなどの構造や業務プロセス、ビジネスの設計思想など、事業全体として整理したもの。データアーキテクチャ（Data Architecture）
事業に必要とされるデータを主軸に捉え、可視化したものを指します。各データの関連性や構造を示したものアプリケーションアーキテクチャ（Application Architecture)
業務を推進する上で必要となる個別のシステムの機能や関連性、システム間の互換性など、アプリケーションの構成を全体的に示したものテクノロジーアーキテクチャ（Technology Architecture）
ハードウェアやソフトウェアという技術の変化を考慮し、企業全体のシステム基盤をどのように構成するのか、技術標準についての検討や考え方を可視化したもの
BA部分はドメイン知識は必要になるので、現場担当者によろしくーってなってしまう箇所ですが、エンジニアがその部分を積極的に理解しようと務めるのは私は結構大事だと思ってます。その方がビジネスサイドの人がITを勉強して要件作るより近道だと思うからです。
会社の業務を俯瞰して、すべてがシステム化されてなければサステナブルとは言えないしひたすら人を増やすことで収益を上げるのは労働集約になりがちです。
そこにITが存在する価値があると思う。
業務をシステムに置き換える際に当然レイヤーという視点が必要なのでその分類に役に立ったし、TA＝テクノロジー箇所をボトルネックにするような設計にするのがコツというのはなるほどーと思わず唸ってしまいました。
技術が一番進化や変化が激しく、BA,DA,AA部分は割と普遍的に変わらないからだとか。
BA,DA,AA部分を変えてしまえばその影響は大きく、コストも掛かってしまうけどTAは最下層に位置するので、ここだけ変えればいいだけにするのは思想的にもわかりやすい気がします。
また、会社のシステムを疎結合にするという発想も、すべてをモノリシックに束ねて一つにしたほうがわかりやすいんじゃないか（メンテナビリティも）と思っていたところでもあり違う視点を与えてくれたように感じます。
筆者は伝説の情報システム部長と言われる中山嘉之氏でIT協会（日本能率協会グループ・公益社団法人企業情報化協会）「ITマネジメント賞」を受賞した「疎結合データHUBアーキテクチャ」も紹介されてました。
自分の仕事は技術部門のリーダーでもあるけど、時にアーキテクトとしてもやらなきゃいけないときがあります。まさにそんなときにメンターになってくれる存在っていいですよね。エンジニアのペインポイントにこれだけ的確に回答している書籍はありがたい。
また、明日から頑張ろう。