Entries from 人とデータと、時々IT tagged with 'Enterprise Architecture'
Enterprise Architecture As Strategy
先日、EMEAのOracleのブログを見ていたら、Enterprise Architecture As Strategyの紹介が書いてありました。 もともと興味がある分野であったので、早速Amazon.comさんで注文しました。もちろん洋書なので、中身は全部英語ですよ。 でも、この本は一読の価値ありです。新たに学ぶところが多いものでした。 最近、M.E.ポーターの日本の競争戦略などにも目を通してみたりと、戦略についても勉強もしているところで、色々日本の企業ITの在り方や日本人の気質なのか日本文化の中で作り出された組織の体質のようなものの変革も迫られているのではないかと思いました。 非常に興味を引かれたのは、以下の2つのポイント。 企業のOperating Modelを分析するのはたった2つの軸。 １．Business Process Standardization ２．Business Process Integration そして、それによって大別されるOperating Modelsは４つ A．Diversification B．Coordination C．Replication D．Unification Unificationは、上記１，２のレベルがそれぞれ高いものと定義されています。 それゆえ、もっとも先進的なArchitectureであり、全ての企業はそうなるべきだと思えるかもしれません。 でも、別にそれだけでもないんですよね。Business Unitがまったく異なる顧客ターゲットをベースに対して、ビジネスプロセスも共有する必要が無ければ、無理に顧客データの統合をしなくてもいいかもしれないですよね。 でも、人事、財務、会計、調達なんかのプロセスの統一や共有は必要かもしれないですけどね。 なので、このような場合には大上段のSOA的な価値訴求だけでは解ではないかもしれないなぁと思いました。企業ITの将来像は何が何でもいきなり統合だSOAというのはちょっとと思っている人にもためになる一冊かと思います。 ----------------------------------- I will translate it in English later....
Enterprise Architectureに対するDBAの想い
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：テクニカル・アーキテクチャ 詳しい話はまた次の機会にしたいと思う。...
Search All Blogs
Google Search
Feed Subscription
If you use an RSS reader, you can subscribe to a feed of all future entries tagged 'Enterprise Architecture'.
