Wikipedia 세번째 작품

번역 원문 : 法輪功
번역 본    : 파룬궁
번역 기간 : 7월 둘째주,셋째주

번역한 부분:
중국정부의 파룬궁 탄압,
중국 정부에 의한 투옥.고문.옥중 의문사,
파룬궁의 주장,
중국정부의 주장

느낀점 : 짧은 문장이지만 간결하게 표현하는 것이 어려웠다. 역시 평소에 책을 많이 읽어야 한다는 ㅠ.ㅠ

Wikipedia 두번째 작품

번역 원문 : 大江健三郎
번역 본    : 오에 겐자부로
번역 기간 : 6월 둘째주

번역한 부분:
노벨상 수상까지,
후기의 일(근황),
북한 관련 발언

느낀점 : 문학작품에 관련된 용어나 소설 제목을 어떻게 표현해야 할지 등이 가장 어려운 부분이었다. 이번주는 시간도 좀 없어서 제대로 교정하지 못한게 아쉬움이 남는다.평소에 문장력을 기를수 있도록 책을 많이 읽어야겠다.
Wikipedia 첫번째 작품

번역 원문 : モスクワ地下鉄爆破テロ (2010年)
번역 본    : 2010년 모스크바 지하철 폭탄 테러
번역 기간 : 6월 첫째주

느낀점 : 해당 글 외에도 배경지식이 있어야 매끄러운 번역이 된다는 사실을 알았다. 실제로 글 자체를 번역하는 것 보다
지식을 검색하고 이해하는 것에 시간을 더 할애했다. 또한, 지역명이나 사람이름 등을 어떻게 우리말로 표기하면 되는지
도 꽤 고민되었다.
「6年目の彼氏がいますが、私は結婚願望ゼロ」(29歳)、「彼は結婚したがるけど、私は今のままがいい」(27歳)、「結婚=束縛のイメージ」(30歳)など、読者アンケートで見つけた「結婚したいと思えない」発言。しかも結構多いんです!『「婚・産・職」女の決めどき』(大和書房)著者でマーケティングライターの牛窪 恵さん、これって変ですか?

「上の世代に結婚しない女性のモデルパターンが少ないので、『私って変?』と思いがちですよね。でも結婚に興味が持てない女性は確かに増えています。みんな結婚に夢もリアリティも描けないんでしょうね。

そうなんです! それに独身の方が、時間もお金も自由に使えるし、気楽だし…。

「でもそれは”今”ですよね? 出産のリミットや親の介護問題、仕事などを含めた”未来”のことを考えたら、また違ってくるかもしれません。結婚しない覚悟がるならいいですが、結論を先送りしているだけなら、真剣に悩んだり動いてみた方がいいですよ」

結婚しない選択も、もちろんアリ。でももしノープランナだけなら、一度真剣に悩む必要がある。今がその時なのかもよ…?


의외로 많은 [결혼하고싶은 생각이 없다] 는 증후군

[6년째 애인이 있지만 결혼하고 싶은 마음은 제로](29살), [남자친구는 결혼하고 싶어하지만 나는 지금 그대로가 좋음](27살), [결혼=속박의 이미지](30살) 등, 독자 앙케이트에서 나타난 [결혼하고 싶지 않다] 는 발언이다. 게다가 꽤 많다라는 것!
[결혼, 출산, 직업] 여자가 정해야 할 것 (야마토서재) 저자인 마케팅 라이터 우시쿠보 케이씨, 이런것 이상한 겁니까?

[요즘 시대에 결혼하지 않는 여성모델의 패턴이 적으므로 [나는 이상한 사람?] 이라고 생각해버리죠. 하지만 결혼에 흥미가 없는 여자는 확실히 늘고있는 추세입니다. 모두 결혼에 대한 꿈도 현실도 그릴 수 없는것이죠]

그런거예요! 게다가 독신인 편이 시간도 돈도 자유롭게 쓸수 있고, 마음도 편하고...

[하지만 그것은 "지금"만 이죠? 출산의 한계나 부모의 간병문제, 일등을 포함한 "미래"를 생각하면 다시 틀리게 생각될지도 몰라요. 결혼하지 않는 각오가 있으면 괜찮지만 결론을 먼저 내고 있는것 뿐이라면, 신중하게 고민하거나 움직여보거나 하는 쪽이 좋을꺼예요]

결혼하지 않는 선택도 물론 있어요. 하지만 No-Plan 이라면 한번 더 신중하게 고민해볼 필요가 있어요. 지금이 그때일지도...

출처> r25 http://r25.yahoo.co.jp/fushigi/girlscolumn_detail/?id=20100225-00001562-r25

夢を語りすぎて混迷した反省
対象絞り、これから本番を迎える

長年、SOAを実現する製品を提供してきたIT企業のエンジニアは、これからの流れをどう考えているのか。議論を通じて得られた結論は「むしろこれからが本番」ということだ。

高野 忍 氏
ソフトウェア・エー・ジー システムエンジニアリング マネージャ大手製造業や通信会社に勤務し、多くのプロジェクトにマネージャーとして参画。2006年8月、ウェブメソッド(現ソフトウェア・エー・ジー)に入社。ユーザー時代の経験を生かし、顧客視点からEAIやSOA、BPMの提案、実装を支援。現在、システムエンジニアリング部門を統括している

中村 秀樹 氏
日本オラクル Fusion Middleware事業統括本部 ビジネス推進本部パートナービジネス開発部 シニアマネジャー
BPMベンダーとEAIベンダーで勤務した後、2006年に日本オラクルに入社。
SOAの概念を広く普及するアーキテクト部門を経て、現在はOracle FusionMiddlewareのSOA/BPM領域に関する製品戦略を担当している

三次 啓太 氏
SAPジャパン ビジネスユーザ&プラットフォーム事業部 プラットフォーム事業部 シニアソリューションセールス
国内SIベンダーのシステム開発部門にて、企業システムの設計/開発などに従事した後、日本BEAシステムズのプリセールスとして日本のSOA先進事例に携わる。その後、SAPジャパンに入社。現在は、SAPのビジネス・プロセス・プラットフォームのセールス活動や事業開発を担当する

渡辺 隆 氏
日本アイ・ビー・エム ソフトウェア事業 SWブランド&チャネル・マーケティング WebSphereマーケティング・マネジャー
国内ベンダーでデータモデリングやOracle周辺ツールのマーケティングに従事した後、2000年より日本ラショナルソフトウェアのマーケティングを担当。UMLやRUP,構成管理の普及に努める。Rational社のIBMへの合併を経て、現在は、BPMやSOAのマーケティングを担当している。

2003年から2005年にかけて、SOAが現在のクラウド並びの関心を集めました。しかし、振り返ってみれば、あまり普及しなかった。その要因は、どんなことにあったと思いますか。

三次色々な要因があると思いますが、当時、SOAを顧客に提案すると、「考えは素晴らしいが、肝心のサービスはどこにあるんですか?」と、必ず指摘されました。確かにレガシーシステムやクライアント/サーバー型システムなどが混在する環境では、サービス化しにくいものが多い。サービスを用意するためには既存システムに手を加える必要があり、これが普及を阻害する足かせの1つだったことは間違いないでしょう。

中村:結局SOAという言葉が先行し、顧客に正しくSOAを理解してもらうことができなかったと思います。SOAについて説明した後、「で、どうしてSOAが必要なの?」と話がループすることもありましたよね。”サービス”という概念が難しかったのではないでしょうか。

渡辺:それに加えて、業務プロセスのモデリングや可視化などのBPM、ユーザーインタフェースのポータルwお含め、当時はすべてをSOAで括っていた気がします。

一言で言えば「夢を語りすぎた」と(笑)?最近は、変わった着ましたか。

渡辺
:我々は、SOAとBPMを切り分けて説明するようにしています。SOAという言葉が指す範囲を、あえて狭くしているんです。

高野:実際問題として、SOAという言葉にとらわれるのは良くないと思いますよ。顧客の中には「当社もSOAに取り組みたい」と言うものの、聞くとSOAを正しく理解していないケースが少なくありません。そこで顧客からSOAという言葉が出てきたときには、「その言葉を使うのは止めましょう」と提案しています。

そこまで。。。

渡辺:我々もSOAという言葉を全面に出さず、システムをつなぐという意味で「コネクティビティ」と実現します。「サービス指向アーキテクチャ」も、出しませんね。

三次:SAPでは一頃言っていた、エンタープライズSOAという言葉を使わず、「ビジネスプロセスプラットフォーム」と言ってます。

時代の流れと共にSOAの範囲が変化してきた

以前と現在では、SOAという言葉の範囲が変わり、またこの言葉そのものを、強調しなくなったわけですね。どうりで「SOAは死んだ」という議論が出てくるわけです。(笑)。しかし、「ある機能の周りを標準的なインタフェースを持つサービスという形で実現し、それをリポジトリに登録。BPMの手法でサービス同士を連携させて、アプリケーションを構築する。実行時にサービス同士を疎結合で連携させる基盤としてESBを使う」という、SOAの考え方に意味がなくなったわけではないと思います。その点は、いかがでしょう?

渡辺:その概念こそがSOAの「リファレンスアーキテクチャ」であり、SOAの理想刑です。それは今も変わっていません。

高野:私も同じ意見です。リファレンスアーキテクチャは、ユーザーインタフェース層やモニタリング層、ESB層やデータ層などで構成され、これはあるべき姿を示していると思います。ただ、このうちのどの層までをSOAとして括るのかが変化しているんです。

中村:サイロ化したシステムを、横断的に連携させようとした時、優先度が高いのはESBでしょう。理想は理想として、大括りなSOAを細分化する流れは必然と言えますね。

適用範囲が広がるESB
厳しい性能要件に対処

では、そのESBに話を進めます。現状のESBの使われ方はどうか、あるいは今後、急ピッチで普及が進んでいくのでしょうか。

三次:リファレンスアーキテクチャを参考に、インタフェースの標準化やアプリケーションの作り方をルール化できれば、自ずとESBの導入は進むと思います。そこまで至らない顧客に対しては、追い求めるべきアーキテクチャを確立していくよう説いていかなかればなりません。

渡辺:我々は、まずシステムを連携させるための1つの手段としてESBを使うことを推奨しています。
あまり大上段に構えず、まずは現在の課題を解決する1手段としてESBを活用すればいいというスタンスです。実際に経験しないと分からないことも多いですから。もちろん、将来的にアーキテクチャ全体を見据えることは必要ですよ。

高野:以前のESBは単にシステムをつなぐ仲介役でしかありませんでした。しかし現在のESBは充実した機能を備えるものが多く、結果として適用範囲が広がっている。つまりシステム連携の手段として定着したか、定着しつつある手段だといえます。

今の高野さんの話に関連しますが、何年か前に「ESBとEAIは何が違うのか」という議論がありました。

中村:EAIベンダーとESBベンダーに所属していたことがある私が答えましょう(笑)。結論を言えば、基本的な目的はどちらも同じです。「これがESB、これがEAI」という議論に意味はありません。
実際、EAIから発展したESBも多いですから。ただしデータを同期するために用いるのか、機能を共有するために用いるのか。使い方については検討の余地があると思います。

三次:SAPの場合、ESBもEAIも「SAP NetWeaver PI」として1つの製品です。ESBでありEAIであり、両者の機能差がないというか、それを云々する必要がなくなったのが実情です。

中村:ESBそのものの話をさせていただくと、本格的に利用されるようになった結果、ESBは大量のデータを高速に処理する必要が生じています。あるサービスから別のサービスに、高速にトランザクションを引き渡す必要があるわけです。そこでオラクルでは、インメモリー技術を使ってレスポンスを高速化できるようにしています。

渡辺:確かにESBに対する性能要件は、厳しくなっていますね。そこでIBMの場合は、ESBの付加を軽減する「WebSphere DataPower SOAアプライアンス」という専用装置を提供しています。ESBに流れ込むデータを事前に分析し、必要なデータのみをESBに流すことが機能です。日本では、まだここまでの性能を求めるケースは少ないですが、欧米では大量のデータを処理する通信業や金融業を中心に導入が進んでいます。

なるほど。外資系大手ITベンダーでは、EAIとESBの違いは、今や議論にならない。ESBの性能を高めることが最近の焦点、というわけですね。では改良が進むESBを導入すれば、SOAの利点として言われていた「変化に対する柔軟性」を確保できるのでしょうか。言い換えれば、ESB=SOAは成立するか、という意味ですが。

中村:答えはイエスです。柔軟性の確保にまずESBが重要です。ESBでサービスごとのデータフォーマットや通信プロトコルの違いを変換して整流化できれば、個々のサービスの独立性を担保できますから。

渡辺:新規システム開発で軽視しがちなのが、既存システムを含めたシステム連携の方法です。力技でも連携させることが可能ですが、将来の保守やシステム変更を考えるとESBを使うべきでしょう。将来のことをさておいても、システム連携が容易になるメリットは大きい。ESBを使う顧客は、それを理解しています。これもESB導入による変化対応力の現われだと考えます。

今やシステム開発をする際にポイントとして、他のシステムと連携するための標準的なインタフェースを用意することは重要です。そこでESBを前提にシステムを設計する。こう考えていいのでしょうか?

渡辺:その考え方こそが、アーキテクチャをどのようにデザインしていくかだと思います。

三好/中村/高野:同感です。

ESBに関して、あるいはSOAに関して、そのような説明はほとんど答えてこなかったように思いますが。。。

中村:我々はこの2年、顧客が目指す目的とそのために必要なアーキテクチャの意義が合致するよう、SOAに関するアセスメントサービスを提供してきています。その中で説明はしてきたつもりですが、おっしゃる通り、説明が不足していたかも知れません。

少し角度を変えますが、最近のSOAに関するユーザーの理解やニーズについてはいかかでしょう。

中村:業界により異なりますね。例えば通信や金融系は、SOAが登場する前から「サービスプラットフォーム」という考え方を持ち、アプリケーションをサービスとして開発する印象があります。もちろん個々の企業によって異なるのも事実ですけど、大まかに言ってアプリケーションの機能をサービスとして提供する考えが根付いています。そのため、ESBがスッと入りやすい。一方、製造や流通、小売り業は業種ごとにアプリケーションの作り方が異なるようです。

高野:私は以前、通信業と製造業という相反する企業で、その違いを感じていました。通信業は業務プロセスをいかに自動化するのかに注力しています。当然、システムを連携する仕組みが強く求められます。一方の製造業はバッチ処理を優先します。サイロかした業務システムで特段の問題が生じないため、システム間連携やサービスプラットフォームという意識は希薄ですね。

今後はどうでしょう。

中村:多くの企業のIT部門はリーマンショック以降、IT投資を迎えて構想策定に時間を割いてきました。これがいい方向に作用し、システムを統合するアーキテクチャを描くケースが増えています。来年以降は投資が進み、新たな構想に基づきプラットフォームを見直す動きが活発になるのではと見ています。

渡辺:この経済状況では全面的なシステムの見直しは難しい。だからこそ企業内のITアーキテクチャをどう管理していくかは、重要なテーマになります。そこには、例えば外部の事業者が提供するSaaSが新たに含まれるかもしれません。それらを含めアーキテクチャを整理し、どう維持/運用していくべきかを検討していく動きが出てくるはずです。

システムを俯瞰する専任者の擁立が不可欠

世界的に見ると、そういった動きはどう評価されるんでしょう。日本企業のシステムのアーキテクチャは遅れているのでしょうか。

三好:時間的な差ではなく、アプリケーションの作り方などがそもそも違うのではないでしょうか。先ほど指摘があったように、業界によってはアプリケーションをモジュール化しているが、必ずしもそうでない業界もあります。こうした根本的な違いが背景にあるように感じます。

渡辺:やや挑戦的な言い方を許してもらうとすると、日本企業は組織体制に問題がある。情報システム部門に、ITアーキテクトがいるかどうかが重要だと思います。IBMもそうですが、日本ではITベンダーがユーザー企業のアーキテクトであるかのように提言しているケースが多い。ここに問題があるのでしょう。

ユーザー企業の中に、システムを俯瞰し、アーキテクチャを描く専任者がいないといけない?

渡辺:イベントやセミナーで自社の導入事例を紹介するような先進的な企業では、CIOがアーキテクトの役割を担っているケースが多いですね。

中村:CIOやアーキテクトであっても財務的な権限を持つ人が後ろ盾としてなければ、目指すべきアーキテクチャへの推進は難しいでしょう。アーキテクチャの改革の進める日本企業は、こうした人材が「必要要件」として存在しますね。

高野:例えば海外のSOA関連イベントでは、ユーザー企業のCIOやマネジャークラスの方が事例を紹介するために登壇します。こうした方々は製品の機能についても実に詳しく、よく知っている。バージョンの違いによる機能差まで把握し、アーキテクチャを考えているんですよ。日本企業の方と話して「なぜ、そんなに古いバージョンの製品を使っているのか?」と驚くことがおおいのとは、大きな違いですね。

目指す目標を明確化し手段の1つとしてSOA活用を

最後に、ユーザー企業が今後、SOAを生かしたシステムの高度化に取り込むにあたり、どんな点に注意すればよいのでしょう?

高野:SOAという言葉や技術に、あまり惑わされないようにすることです。SOAも、あるいはBPMも所詮はITとしての方法論です。目的はあくまで、企業価値や財務的な効果を生むことにある。とすれば、それを実現する策として、SOAやBPMを捉え、取り込むべきです。

三好:私も同感です。SOAはあくまで手段であり、目的ではありません。業務最適化や変化対応力強化などを、どうやって達成するかを検討する。その結果、それを支援する仕組みとしてSOAを活用するのが自然ではないでしょうか。

中村:数年前からSOAに取り組む企業の中から、徐々に効果が出始めた事例が登場しています。7月にはオムロンの導入事例を発表しました。こうした事例から必要な情報を収集して、SOAに取り込んでいただきたいですね。

渡辺:今日の議論によってSOAの”A"はアーキテクチャであり、ここをユーザー企業に対して訴求し、理解していただくことの重要性を再認識したと思います。これから数年の間に、SaaSyaクラウドといった外部のサービスを、企業システムに取り込む動きが進みます。その時、部分最適、あるいはその場しのぎで取り込むのか、それとも全体のアーキテクチャを俯瞰して活用できるのか。我々は、後者になるように支援する必要があります。同時に、ユーザー企業には専任のアーキテクトを置く必要性を認識していただければと思います。

なるほど、今日はみなさん、どうもありがとうございました。


IT Leaders 에서 발췌
http://it.impressbm.co.jp/e/2010/12/07/3097

혼란기를 벗어난 지금부터가 실전이다!

꿈을 너무 이야기해버려 혼란한 반성
대상을 선정하고 지금부터 실전을 준비한다

오랜 세월 SOA를 실현한 제품을 제공해 온 IT기업의 엔지니어는 이제까지의 흐름을 어떻게 생각하고 있을까.
토론을 통해 얻을 수 있는 결론은 [오히려 지금부터가 실전이다]라는 것이다.

타카노 시노부 씨
소프트웨어 에지 시스템 엔지니어링 매니져
대기업 제조업과 통신회사에 근무하고 많은 프로젝트에서 매니저로서 참여.2006년 8월 웹메소드(현재는 소프트웨어 에지)에 입사.유저때의 경험을 살려 고객관점에서 EAI,SOA,BPM을 제안하고 실현을 지원함.현재 시스템 엔지니어링 부문을 통괄하고 있음.

나카무라 히데키 씨
일본 오라클 Fusion Middleware사업 통괄본부. 비지니스 추진본부 파트너 비지니스 개발부. 시니어 매니저
BPM벤더와 EAI벤더에서 근무한 후, 2006년에 일본 오라클에 입사.
SOA의 개념을 널리 보급하는 아키턱쳐부문을 거쳐, 현재는 Oracle FusionMiddleware의 SOA/BPM영역에 관한 제품전략을 담당하고 있다.

미요시 케이타 씨
SAP Japan 비지니스 유저 & 플랫폼 사업부.플랫폼 영업부 시니어 솔루션 세일즈.
국내 SI벤더의 시스템 개발부문에서 기업 시스템의 설계/개발등에 종사한 후, 일본 BEA시스템 프리 세일즈로써 일본 SOA선진사례에 참여했다.그 후, SAP Japan에 입사.현재는 SAP비지니스 프로세스 플랫폼 세일즈 활동과 사업개발을 담당하고 있다.

와타나베 류 씨
일본 IBM 소프트웨어 사업 SW 브랜드 & 채널 마케팅 WebSphere 마케팅 매니저.
국내 벤더에서 데이터 모델링과 Oracle 주변 툴의 마케팅에 종사한 후,2000년부터 일본 래셔널 소프트웨어 마케팅을 담당.UML과 RUP, 구성관리 보급의 역할을 맡고 있다.Rational사가 IBM에 합병되어 현재는 BPM, SOA의 마케팅을 담당하고 있다.

2003년부터 2005년에 걸쳐 SOA가 현재 클라우드 행보에 관심이 모아지고 있습니다. 하지만 돌아보면 그다지 보급되지 않았습니다.그 원인은 어디에 있었다고 생각합니까?

미요시 : 여러가지 원인이 있다고 생각하지만, 그 당시 SOA를 고객에게 제안하면 [생각은 훌륭하지만, 중요 서비스는 어디있습니까?] 라고, 매번 지적받았습니다. 확실히 레거시 시스템이나 클라이언트/서버 형 시스템등이 혼재되어있는 환경에서는 서비스 하기 어려운 것이 많습니다. 서비스를 준비하기 위해서는 기존 시스템에 손을 댈 필요가 있고 그것이 보급을 방해하는 족쇄의 하나라는 것이 틀림없겠죠.

나카무라 : 결국 SOA라는 말이 선행되고 고객에게 제대로 SOA를 이해시키는 것이 실패한 것이라고 생각합니다.SOA에 대해서 설명한 후 [그래서 왜 SOA가 필요하지?] 라고 이야기가 번복된 적도 있었습니다."서비스"라는 개념이 어려웠던건 아닐까요.

와타나베 : 거기에 더해서 업무 프로세스의 모델링이나 가시화등의 BPM, 유저 인터페이스의 포탈을 포함해 당시엔 전체를 SOA로 묶었던 생각이 듭니다.

한마디로 말해서 [꿈을 지나치게 말해버렸다] 라는건요? 최근엔 달라지고 있습니까?

와타나베 : 우리는 SOA와 BPM을 나누어 설명하도록 하고 있습니다.SOA라는 단어가 가리키는 범위를 일부러 적게 만들고 있습니다.

타카노 : 실제문제로써 SOA라는 말에 얽매이는 것은 좋지 않다고 생각합니다.고객중에는 [당사도 SOA를 도입하고 싶다]라고 말하는 사람들조차도 SOA를 정확하게 이해하지 않은 경우가 적지 않습니다.고객에게서 SOA라는 말이 나왔을땐 [그 단어를 사용하는건 관두죠]라고 제안합니다.

거기까지...

와타나베 : 우리들도 SOA라는 단어를 전면에 내세우지 않고 시스템을 연계하는 의미로 [커넥티비티]라고 표현합니다.[서비스 지향 아키텍쳐]라는 말도 하지 않네요.

미요시: SAP에서는 한때 거론되었던 엔터프라이즈 SOA라는 말을 쓰지않고 [비지니스 프로세스 플랫폼]는 용어를 사용합니다.

시대의 흐름과 함께 SOA의 범위도 변화하고 있다

이전과 현재에서는 SOA라는 말의 범위가 변하고, 또한 그 단어 그 자체를 강조하지 않게 되었단말이군요.어쩐지 [SOA는 죽었다]라는 논의가 나올만 하네요.하지만 [어떤 기능의 덩어리를 표준적인 인터페이스를 가진 서비스라는 형태로 실현시키고 리포지터리의 등장.BPM의 방법으로 서비스간 연계를 시켜 어플리케이션을 구축한다.실행시에는 서비스를 소결합으로 연계시키는 기반으로 EBS를 사용한다] 라는 SOA의 생각에 의미가 사라져가는 것은 아닌가하는 생각이 듭니다.이 점에 대해서 어떻게 생각하십니까?

와타나베 : 그 개념 자체가 SOA의 [레퍼런스 아키텍쳐]에 있고 SOA의 이상향입니다.그건 지금도 달라지지 않습니다.

타카노 : 저도 같은 생각입니다. 레퍼런스 아키텍쳐는 유저 인터페이스층이나 모니터링층,EBS층이나 데이터층으로 구성되어 있어야할 모습을 하고 있다고 생각합니다.단지 그 중에서 어떤 층까지를 SOA로 활용할까 하는 것이 변화하고 있는 것입니다.

나카무라 : 사이로화 된 시스템을 병렬적으로 연계시키려고 할때 우선되는 건 EBS이겠죠. 이상은 이상으로 두고, 큰 범위의 SOA를 세분화 하는 흐름은 반드시 필요하다라고 말할수 있겠네요.

적용범위가 넓어지는 ESB
엄격한 성능 요건에 대한 대처


그럼 EBS로 이야기를 전개하겠습니다. 현재 ESB를 사용하고 있는 분은 어떨까, 또는 앞으로 급템포로 보급이 진행될까요?

미요시 : 레퍼런스 아키텍쳐를 참고로 인터페이스의 표준화나 어플리케이션의 작성법을 룰로 정하면, ESB도입은 잘 진행될것이라 생각합니다. 거기까지 미치지 못하는 고객에 대해서는 요구해 마땅한 아키텍쳐를 확립할 수 있도록 설득해야만 합니다.

와타나베 : 우리들은 우선 시스템을 연계시키기 위해 하나의 방법으로 ESB를 사용하는 것을 추천합니다.많은 단계로 구성하지 않고 우선은 현재의 과제를 해결하기 위한 한가지 수단으로 ESB를 활용하면 유용하다는 스탄스입니다.실제로 경험하지 않으면 모르는 경우가 많이 때문입니다.물론 장래적으로 아키텍쳐 전체를 응시할 수 있는 것이 필요하겠죠.

다카노 : 이전의 ESB는 단순히 시스템을 연결하는 중개의 역할에 지나지 않았습니다. 하지만 현재의 ESB는 충실한 기능을 갖추고 있는 것이 많고 결과적으로 적용범위가 확대되고 있습니다. 결국 시스템연계의 수단으로 정책한 것인지, 정착 해가고 있는 단계라고 말할 수 있겠습니다.

현재 다카노씨의 말에 관련해서 몇년인가 전에 [ESB와 EAI는 무엇이 다른가]라는 논의가 있었는데요.

나카무라 : EAI벤더와 ESB벤더에 소속되어 있던 적이 있는 제가 대답하죠. 결론을 말하면 기본적인 목적은 같습니다.[이것이 ESB, 이것이 EAI]라는 논의는 의미가 없습니다. 실제로 EAI에서 발전한 ESB도 많으니깐요. 단지 데이터를 동기하기 위해 사용하고 있는가, 기능을 공유하기 위해 사용하고 있는가. 사용법에 대해서는 검토할 여지가 있는 것이죠.

미요시 : SAP의 경우, ESB도 EAI도 [SAP NetWeaver PI]의 하나의 제품입니다. ESB이기도 EAI이기도, 양쪽 다 기능의 차이가 없다라고 할까, 그것을 운운할 필요가 없어진 것이 현실정 입니다.

나카무라 : ESB 그 자체를 이야기 하면 본격적으로 이용되도록 한 결과 ESB는 대용량 데이터를 고속으로 처리할 필요가 생겼습니다. 어떤 서비스에서 다른 서비스로 고속 트랜잭션을 전달할 필요가 있는 것이지요.거기에서 오라클은 in-memory기술을 사용하여 고속화 된 응답을 받도록 하고 있습니다.

와타나베 : 확실히 ESB에 대한 성능요건은 엄격해지고 있습니다.여기서 IBM의 경우는 ESB부하를 덜기위해 [WebSphere DataPower SOA 어플라이언스]라는 전용장치를 제공하고 있습니다.ESB에 흘러들어간 데이터를 사전에 분석하고 필요한 데이터만을 ESB에 흐르게 하는 것이 가능합니다.일본에서는 아직 여기까지 성능을 요구한 경우는 적지만 미국에서는 대용량 데이터를 처리하는 통신업계나 금융업계를 중심으로 도입이 진행되고 있습니다.

그렇군요. 외국계 대기업 IT벤더에서는 EAI와 ESB의 차이점을 현재로썬 논의하지 않는군요.ESB의 성능을 높이는 것이 최근의 쟁점이라는 말씀이시군요.그럼 보다 개선된 ESB를 도입하면 SOA의 이점으로 불려지는 [변화에 대한 유연성]을 확보할수 있는 건가요. 바꿔 말하면 ESB=SOA라는 것이 성립하는 것인가 라는 의미인데요.

나카무라 : 답은 예스입니다. 유연성의 확보에 우선 ESB가 중요합니다. ESB로 서비스마다 데이터포멧이나 통신 프로토콜의 차이를 변환해서 정류화(전류의 교류를 직류로 바꿈)가 된다면 각 서비스의 독립성을 담보할수 있을테니깐요.

와타나베 : 신규 시스템 개발에서 경시하기 쉬운 것이 기존 시스템을 포함한 시스템 연계의 방법입니다. 힘과 기술로 연계시키는 것은 가능하지만 장래의 보수나 시스템 변경을 생각하면 ESB를 사용해야만 하겠죠. 장래를 생각하지 않다고 하더라도 시스템 연계가 용이하게 되는 장점이 큽니다.ESB를 사용하는 고객은 그것을 이해하고 있습니다.그것 또한 ESB도입에 의한 변화대응력을 나타내고 있는 것이라고 생각됩니다.

지금이야말로 시스템 개발을 할때의 포인트로써 타시스템과의 연계를 하기위해 표준적인 인터페이스를 준비하는 것이 중요합니다.여기에서 ESB를 전제로 시스템을 설계합니다.그렇게 이해해도 괜찮겠습니까?

와타나베 : 그런 생각 자체가 아키텍쳐를 어떤식으로 디자인할까라는 것과 일맥상통 합니다.

미요시, 나카무라, 타카노 : 같은 생각입니다.

ESB 혹은 SOA에 대한 설명은 거의 들을 수 없었던 것 같은데요...

나카무라 : 우리들은 근 2년, 고객이 지향하는 목적을 위해 필요한 아키텍쳐의 의의가 일치하도록 SOA에 대한 평가서비스를 제공해오고 있습니다.그 중에서의 설명은 할 작정이었지만 말씀하신대로 설명이 부족했을지도 모릅니다.

잠시 각도를 바꾸어서 최근 SOA에 대한 사용자의 이해나 요구등은 어떻습니까?

나카무라 : 업계마다 다르지요. 예를 들어 통신이나 금융쪽은 SOA가 등장하기 전부터 [서비스 플랫폼]이라는 생각을 가지고 있었고, 어플리케이션을 서비스로써 개발하는 인상이 있습니다.물론 각 기업마다 다른것은 사실이지만 대부분으로 말해서 어플리케이션의 기능을 서비스로 제공하는 생각에 뿌리를 두고 있습니다.그 이유로 ESB가 진입하기 쉽다. 반면 제조나 유통, 도매업은 업종별로 어플리케이션의 작성법이 다릅니다.

다카노 : 저는 이전에 통신업과 제조업이라는 상반된 기업에서 그 차이점을 느꼈습니다.통신업은 업무 프로세스를 어떻게 자동화할까에 주력하고 있습니다.당연히 시스템을 연계하는 구조가 크게 요구되어집니다. 반면 제조업은 배치 처리를 우선합니다.사이로화 된 업무 시스템에서 특수한 문제가 발생하지 않기 때문에 시스템간의 연계나 서비스 플랫폼이라는 의식은 희박한 것이죠.

앞으로는 어떨까요?

나카무라 : 많은 기업들의 IT부문은 리만쇼크 이후, IT투자를 맞이해 구상책정에 시간을 할애하고 있습니다.
그것이 좋은 방향으로 작용하고 시스템을 통합하는 아키텍쳐를 디자인하는 케이스가 늘고 있습니다.내년 이후엔 투자가 진행되고 새로운 구상을 기반으로 플랫폼을 재점검하는 움직임이 활발해질 것으로 보고 있습니다.

와타나베 : 이 같은 경제상황에서는 전면적인 시스템의 재점검은 어렵습니다. 그렇기때문에 기업내의 IT아키텍쳐를 어떻게 관리할까라는 것이 중요한 테마가 되는 것이죠.거기에는 예를들어 외부 사업인이 제공하는 SaaS가 새롭게 대두될지도 모릅니다.그것을 포함한 아키텍쳐를 정리하고 어떻게 유지/운용해 가야만 할까를 검토하는 움직임이 나올 것입니다.

시스템을 조망하는 전입자를 확보하는 것이 필수불가결

세계적으로 보면 그러한 움직임은 어떤 평가를 받게되는 걸까요.일본기업의 시스템 아키텍쳐는 뒤쳐지고있는 걸까요?

미요시 : 시간적인 차이가 아니라 어플리케이션의 작성법등이 원래 다른것 아닌가요.방금전에 지적한 것 처럼 업계에 따라서는 어플리케이션을 모듈화하고 있지만 반드시 그렇지 않은 업계도 있습니다. 그러한 근본적인 차이점이 배경이 된다고 생각합니다.

와타나베 : 다소 도전적인 말을 빌리자면 일본기업은 조직체계에 문제가 있습니다.정보 시스템부문에 IT아키텍트가 있는지 없는지가 중요하다고 생각합니다.IBM도 그렇지만 일본에서는 IT벤더가 유저기업의 아키텍트이기도 한 경우가 많습니다.여기에 문제가 있는것이죠.

유저기업중에 시스템을 조망하고 아키텍쳐를 디자인하는 전입자가 없으면 안되는 건가요?

와타나베 : 이벤트나 세미나에서 각 기업의 도입사례를 소개하는 것 같은 선진적인 기업에서는 CIO가 아키텍트의 역할을 담당하고 있는 경우가 많습니다.

나카무라 : CIO나 아키텍트라고 해도 재무적인 권한을 가진 사람이 후원자로 있지 않으면 지향해야만 하는 아키텍쳐에의 추진은 어렵겠죠.아키텍쳐의 개혁을 진행하는 일본기업은 이러한 인재가 [필요요건]이 되는거죠.

다카노 : 예를들면 해외 SOA관련 이벤트에서는 유저기업의 CIO나 매니저 레벨의 사람이 사례를 소개하기 위해 등단합니다.그러한 분들은 제품의 기능에 대해서도 실제적으로 자세히 잘 알고 있습니다.버젼의 차이에 따른 기능의 차별까지 파악하고 아키텍쳐를 생각하고 있는 것이죠.일본기업의 사람과 이야기 하고 [왜 그런 예전 버젼의 제품을 사용하고 있습니까?]라고 놀라는 일이 많은 것은 큰 차이점 이죠.

지향하고 하는 목표를 명확하게 하고
수단의 하나로 SOA활용을

마지막으로 유저기업이 훗날, SOA를 이용한 시스템 고도화에 발을 들여놓는데 있어서 어떤 점을 주의하는 것이 좋을까요?

타카노 : SOA라는 단어나 기술에 갈피를 못잡지 않도록 하는 것입니다.SOA 혹은 BPM도 어차피 IT방법론이니까요.목적은 어디까지나 기업가치나 재무적인 효과를 만드는 것입니다.그렇다고 한다면 그것을 실현하는 방법으로 SOA나 BPM을 붙잡고 착수해야만 하는 것입니다.

미요시 : 저도 동감입니다.SOA는 어디까지나 수단일 뿐 목적은 아닙니다.업무최적화나 변화대응력의 강화등을 어떻게 달성할까를 검토합니다.그 결과 그것을 지원하는 방법으로써 SOA를 활용하는 것이 자연스럽지 않겠습니까.

나카무라 : 수년전부터 SOA에 착수한 기업으로부터 서서히 효과가 드러나고 있다는 사례가 나오고 있습니다.7월에는 옴론의 도입사례를 발표했습니다.이러한 사례로부터 필요한 정보를 수집하고 SOA에 착수하게 되었으면 좋겠네요.

와타나베 : 오늘의 토론에서 SOA의 A는 아키텍쳐이고 이것을 유저기업에 대해서 욕구를 불러 일으키게 하고, 이해의중요성을 재확인 했다라고 생각합니다.지금부터 수년간 SaaS나 클라우드 같은 외부 서비스를 기업 시스템에 착수하는 움직임이 진행될 것입니다.그때에 부분최적, 또는 그 시기를 잘 극복하고 착수할 것인가, 또는 전체 아키텍쳐를 조망하고 활용하는 것이 가능할까.우리들은 후자가 되도록 지원할 필요가 있습니다.동시에 유저기업에서는 적임의 아키텍트를 둘 필요성을 인식해주셨으면 하는 생각입니다.

그렇군요.오늘 말씀나눠주신 여러분 정말 감사합니다.


<第一編>
お母さん:何十年ぶりかしら。二人きりの旅行。

     こんにちは

学生たち:こんにちは

お父さん犬:こんにちは

学生たち:こんにちは

お母さん:高校生? 寒いわね。

学生たち:寒いですね。

お父さん犬:絢にもこんな時代があったなあ

あや:え? 

男子高校生:どうしました?

あや:あ、別に。
   ホワイト学割なら学生は基本料3年間無料です。

お母さん:それじゃ

学生たち:さよなら

お母さん:今子供のこと考えたんでしょう。

お父さん犬:何で分かった

お母さん:分かるわよ。あなたの考えてることくらい
今年、IT業界で最も話題になったキーワードは、クラウドだろう。IT系の雑誌やWEBサイトで、この言葉を見ない日はないほどだ。さかのぼって2004年ごろ、同じようにもてはやされた言葉があった。SOA(サービス志向アーキテクチャ)である。

当時、多くの企業においてはWEBシステムやC/Sシステム、さらにはメインフレーム時代のレガシーが混在。システム変更の煩雑さや運用コストの増大が大きな問題になっていた。

そこへ、SOAが登場した。その基本的な考え方はこうだ。システムをプレゼンテーション層、プロセス層、サービス連携層、サービス層といったレイヤー構造に分割。ソフトウェア部品や機能を、ビジネスプロセスと1対1対応する”サービス”の単位で切り出し、それらを組み合わせてシステムを構築する。SOAに基づくシステムにおいては、業務遂行に必要なサービスを1つの画面から呼び出して利用でき、ビジネスプロセスに変更があれば、即座にサービスを組み替え可能。さらに、サービス間は互いに”疎”な関係であるため、あるサービスに追加や変更を加えたとしても他に影響しないー。

SOAはサイロ化したシステムによる弊害を解消する切り札として注目を浴びた。ところがその普及は遅々として進まなかった。なぜか、上記のようなアーキテクチャをすべて実装するには、ビジネスプロセスの分析・可視化が前提になる。それには全社を挙げて取り込む必要があり、時間もコストもかかることが壁となった。「理念はわかるが、どこから手をつけていいか分からない」というのが、多くのユーザー企業の本音だった。

SOAとBPMを切り分け
まずはシステム間連携から

しかし、ここへきてSOAを用いたシステム刷新事例が増えている。東京証券取引所は6月、情報系システムの一部をSOAをベースに全面構築した。オムロンも、新たなIT基盤にSOAを採用。経営管理や営業支援、SCMといったシステムをこの基盤上で稼動開始した。

こうした動きの背景には、SOAに対する考え方が”こなれてきた”ことが挙げられる。ユーザー企業に、「SOAの理想像に振り回されず、まずはシステム間連携から実現しよう」という良い意味での割り切りが生まれたのだ。まずは基盤となるESBを導入して足下を固める。そのうえで、各システムの更改時期や優先順位に従って順次、既存システムをサービス化。ビジネスプロセスの可視化や分析といった”上流”な別立てで考えよう、というわけだ。アイ・ティ・アールの生態清司氏も「ビジネスプロセスを最適化するBPMは、企業の競争力向上に不可欠だ。だが、それは必ずしもSOAの枠組で実施する必要はない」と指摘する。

次から、東証の取り組みを例に、SOAへの今日的アプローチで見ていくことにしよう。


이상적인 것을 추구하지 말고 시스템간 연계에 현실화를...

올해, IT업계에서 가장 화제가 된 키워드는 클라우드 일 것이다.IT관련 잡지나 Web 사이트에서 이 단어를 보지 않은 날이 없을 정도다.2004년쯤으로 거슬러 올라가, 지금과 비슷하게 인기가 있던 단어가 있었다. SOA(서비스 지향 아키텍쳐)이다.

당시 많은 기업에겐 Web 시스템이나 C/S시스템, 더욱이 메인 프레임 시대의 레가시(시대에 뒤떨어진 낡은 컴퓨터시스템)가 혼재했다.시스템 변경의 번잡함이나 운용 비용의 증대가 큰 문제가 되었다.

그곳에서 SOA가 등장했다.기본적인 생각은 이러하다.시스템을 프리젠테이션층, 프로세스층, 서비스 연계층, 서비스 층으로 되어있는 레이어 구조를 분리한다.소프트웨어 부품이나 기능을 비즈니스 프로세스와 1대1 대응시켜 "서비스" 단위로 나누고, 그것의 조합으로 시스템을 구축한다.SOA을 기반으로 하는 시스템은 업무수행에 필요한 서비스를 1개의 화면에서 호출하는 것으로 이용이 가능하고, 비지니스 프로세스의 변경이 발생하면 즉시 서비스를 교체하는 것 또한 가능하다. 더욱이 서비스 상호간에 "배타적" 이기 때문에 어떠한 서비스에 추가나 변경을 해도 타서비스에는 영향을 주지 않는다.



SOA는 사이로화(각 부문이나 업무별로 최적의 시스템을 구축하기 위해 각 어플리케이션 마다 서버가 필요하게 되어 관리자의 부담이 증가하는 것) 시스템에 대한 폐해를 해소하기 위한 비장의 카드로 주목을 받았다.그렇지만 SOA의 보급은 더디게 진행되어 진전되지 못했다.왜 일까.위 그림과 같은 아키텍쳐를 전체적으로 구현하는 데에는 비지니스 프로세스의 분석.가시화가 전제가 된다.그것은 모든 회사를 혼잡스럽게 하고 시간과 비용도 적지 않게 들어 실현하는 데 장애물이 되었다.
[이상적인 생각은 이해하지만 어디서부터 다가서야할지 모른다] 란 것이, 많은 유저 기업들의 속마음이다.

SOA와 BPM의 분리
우선 시스템들간의 연계부터

하지만 이제와서 SOA를 이용한 시스템 쇄신사례가 증가하고 있다.동경증권거래소는 6월, 정보시스템의 일부를 SOA를 기반으로 전면 재구축했다.옴론도 새로운 IT기반의 SOA를 채택했다.경영관리나 영업지원, SCM등의 시스템을 SOA를 기반으로 하여 가동하기 시작했다.

이러한 움직임의 배경에는 SOA에 대한 생각이 "녹아 들었다" 란 것을 들수 있다.유저 기업에게 [SOA의 이상향을 남용하지 않고 우선은 시스템들 간의 연계부터 실현하자] 라는 좋은 의미로 명쾌히 결론을 냈다.우선은 기반이 되는 EBS를 도입해서 부족한 부분을 다진다. 거기에 각 시스템의 개정 시기나 우선순위에 따른 순차, 기존 시스템을 서비스 한다.비지니스 프로세스의 가시화나 분석이 되는 "상류"는 다른 시점으로 생각하자 라는 것이다.ITR의 이쿠마 키요시 씨도 [비지니스 프로세스를 최적화하는 BPM은 기업 경쟁력의 필수 불가결이다. 하지만 그것은 SOA 틀의 구조에서 반드시 실시될 필요는 없다]라고 지적했다.

다음호에서는 동경증권거래소를 예로 들어 SOA로의 목적 접근을 살펴보자.

IT Leaders 에서 발췌
http://it.impressbm.co.jp/e/2010/11/30/3095#
クラウド時代のシステム連携

熾烈さを増やす大競争時代。常に新たな一手を打っていなければならない経営環境において、情報システムには一層の戦力性が求められている。使い込んできたレガシーシステム、サイロ化しているオープンシステム、実用期にさしかかったクラウドサービス。。。これらをうまく連携させることが現実解の一つだが、付け焼き刃の対処に終わらず、中長期的に実用性のある方法を模索しなければならない。そこで再び注目したいのがSOA(サービス志向アーキテクチャ)だ。その今目的な意義と最新動向に迫る。

다시 한번 SOA에 도전한다!

클라우드 시대의 시스템 연계

치열함이 가속화 되어가는 대경쟁시대.언제나 새로운 수를 내지 않으면 안되는 경영환경에 있어서, 정보 시스템에는 한층 더 전력성이 요구되어 진다.이미 친숙하게 사용하고 있는 레가시 시스템, 사이로화 되어지고 있는 오픈 시스템, 실용화 단계의 막바지에 다다른 클라우드 서비스... 이것들을 효율적으로 연계시키는 것이 현실화가 되는 한가지지만, 보여지기 위한 처리에서만 끝나는 것이 아니라, 중장기적으로 실용적으로 사용할 수 있는 방법을 모색해야만 한다.여기서 다시 주목할 것은 SOA(서비스 지향 아키텍쳐)이다. 그것의 현시점에 대한 목적의 의의와 최신경향에 대한 시각이 간구된다.


IT Leaders 에서 발췌

http://it.impressbm.co.jp/e/2010/11/30/3094

+ Recent posts