| « 2005年8月23日 | 2005年8月24日の投稿 |
2005年8月25日 » |
前回、アーキテクチャの反対語はインプリメンテーション（実装）と昔、習ったなんて話を書きました。実際、アーキテクチャという言葉の元祖でもある、S/360 Principles of OperationというIBMのメインフレームのアーキテクチャのマニュアルを見ても内部実装の話は全然書いてなくて、アーキテクチャを実現するのは、ハードワイアド・ロジックでも、マイクロコード（ファームウェア）でも、ソフトウェア・エミュレーションでも何でもよいという趣旨のことが書いてあります。
しかし、最近ですと、たとえばPentiumのNetburstアーキテクチャと言ったりしますが、これは完全に内部設計の話ですよね。ということで、アーキテクチャは実装とは独立した外部設計と言う定義がここですでに崩れてきてます（本来、こういうプロセッサ内部の設計の話はマイクロアーキテクチャと呼ぶべきと思いますけど、いつの間にか単にアーキテクチャとよばれるようになってるのだと思います）。
それから、アーキテクチャのことを「設計思想」と訳すことがありますね。一般紙なんかだと「アーキテクチャ（設計思想）」なんて括弧書きで説明してあったりします。で、確かに、設計思想と言う意味で「アーキテクチャ」と言う言葉を使うときはあります（SOAにおけるアーキテクチャという言葉はこれに近いかも、ソフトウェアをサービスと言う部品にわけて構築しましょうという思想ですから）。
ところが、EAにおけるアーキテクチャは設計思想なんてもんじゃないですね。ザックマン・アーキテクチャやそれから由来するアーキテクチャのフレームワーク（FEAFとかTOGAF）では外部設計を厳密に記述することが求められてます。要するに、アプリケーション開発では必ず行うワークフロー図とかER図のようなものを全社的に書くことが求められてるわけです（最初見た時は「え、ここまで書かなきゃならんの!」とびっくりしてしまいました）。
ということで、アーキテクチャという言葉は、外部設計だったり、内部の実装だったり、設計思想だったり、厳密な設計そのものだったりと、ほとんど意味がなくなってる言葉ではないかと思ったりします。「サービス」という言葉以上に、「アーキテクチャ」という言葉こそ、議論の前に「ここでは『アーキテクチャ』を～という意味で使います」とローカル宣言しておかないとさっぱり意味が通じない危険性もあるかと思います。
| « 2005年8月23日 | 2005年8月24日の投稿 |
2005年8月25日 » |
| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | ||||
| 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 |
| 25 | 26 | 27 | 28 | 29 | 30 |
オルタナティブ・ブログは、専門スタッフにより、企画・構成されています。入力頂いた内容は、アイティメディアの他、オルタナティブ・ブログ、及び本記事執筆会社に提供されます。
顧客に“ワォ！”という体験を提供――ザッポスに学ぶ企業文化の確立
ちょっとした対話が成長を助ける――上司と部下が話すとき互いに学び合う
悩んだときの、自己啓発書の触れ方
考えるべきは得意なものは何かではなく、お客さまが高く評価するものは何か
なんて素敵にフェイスブック
部下を叱る2つのポイント
第6回 幸せの創造こそ、ビジネスの使命