Enterprise Architecture（エンタープライズ アーキテクチャ）。
この言葉に最初に引かれたのは、2003年か2004年くらいのことだったと思う。
テクノロジー系コンサルタントとしてお客様先で、パッケージ・ベンダーのコンサルタントと何気ない会話をしていたときに、「Pattern of Enterprise Application Architecture」という書籍を紹介された。
このコンサルタントやこのお客様で知り合った人たちからは非常に多くの事を学んだ。
「エンジニア/コンサルタントであれば、新しいこと、知らないことに対する勉強を惜しんではいけない」という言葉は、今でも私の中で重要な指針のひとつである。
そこから色々とWebをあさり、本をあさったのがEnterprise Architectureであった。
おりしも日経コンピュータでもEAの特集があったり、その後「EA大全」が出版されたりといろいろな情報を収集する助けになった。
ここ１、２年くらいエンタープライズ・アーキテクチャを検討している、あるいはこのフレームを使ってビジネスの戦略ひいてはITアーキテクチャの検討しているお客様を数多く見るようになってきた。
この事実から見ても日本においてもエンタープライズ・アーキテクチャが浸透してきているようである。
経済産業省が情報政策の一環として「EAポータル」等を通して情報の公開を進めている事も後押ししているのではないかと考える。
そんな中、私はいわゆるDBA（データベース管理者）もエンタープライズ・アーキテクチャを見据えてデータベースを設計・運用・管理できようになるべきだと思っている。
データベースやSQLをチューニングをするにあたっては必然的にデータベースの論理設計やその中に蓄えられているデータの量や質を見る事が多い。そして、アプリケーションがどのようにSQLを発行するのか、ループや条件分岐の使い方やメモリの使い方などもあわせてみていく事も多い。
そのような事を繰り返すうちに、当初は知らなかった業務用語や業務フローなども自然と会話の中に入ってくる。データベースという1つのシステム構成要素あるいはリソースの使い方/使われ方から、システム全体のアーキテクチャへの類推やあるべき姿などが見えてくる。と、私は感じている。
このような経験を持つことによって、アプリケーション開発者・設計者とも共通言語・用語で話せるようになってくるし、お客様が考える業務改善の方向なども見えやすくなる。
それはエンタープライズ・アーキテクチャに対する貢献をすることができるようなCapabilityを兼ね備えている事と言えるだろう。
これはデータベースを押さえているからというよりも、データを動きを押さえているからであると思っている。
だから、私はDBAもエンタープライズ・アーキテクチャへの見識を深めるべきだと思うのである。
もちろん、DBA上がりのエンタープライズ・アーキテクトのみでエンタープライズ・アーキテクチャが完成するとは思えない。しかし、それぞれの領域のエキスパートがいるが故により良いエンタープライズ・アーキテクチャの実現ができるのではないかと考えている。
特に、DBAはエンタープライズ・アーキテクチャにおける以下の3つの領域に対して強く貢献する事ができるであろうと考えている。
DA：データ・アーキテクチャ
AA：アプリケーション・アーキテクチャ
TA：テクニカル・アーキテクチャ
詳しい話はまた次の機会にしたいと思う。
