@IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- @IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
アプリケーション・アーキテクト
1
投稿者 | 投稿内容 | ||||||||
---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2007-12-25 01:40
こんばんは。
素人っぽい漠然としたご質問ですみません。 アプリケーション・アーキテクトを目指すには、どのようなキャリアパスを 考えれば良いでしょうか?。 アプリのアーキを考えるとなると、やはりPGとして数年の経験が必要でしょうか・・。 オブジェクト指向の理解や実践、O/R、DIは使いこなせて当然のようなイメージが ありますが・・。 ちなみに個人的な思い込みですが、アプリのアーキテクチャとは「フレームワーク」と 同意義だと思っています。 お手数ですがご意見お願いします。 | ||||||||
|
投稿日時: 2007-12-25 02:00
だいたいそんな感じで合っているとは思います。 ただ、あまり現場では、そういう「アプリケーション・アーキテクト」のような明確な職種は、存在しないと思ったほうが良いかもしれません。名札や名刺に「アプリケーション・アーキテクト」と書くことはそんなにはないでしょう。でも、「名刺に何て書こうかな?」と迷って、「とりあえずアプリケーション・アーキテクトって書いちゃえ」みたいな感じで使うようなことはあるかもしれませんが、それだけです。
どうなんでしょう。あまり用語の定義は知りませんが、「アーキテクチャ」とは、設計という意味合いが強いかな、と思います。 | ||||||||
|
投稿日時: 2007-12-25 09:05
一言で言えば、アーキテクチャは設計思想で、フレームワークはライブラリの集まりです。 フレークワークはモノそのものを指します。 _________________ C# と VB.NET の入門サイト じゃんぬねっと日誌 | ||||||||
|
投稿日時: 2007-12-25 10:04
るぱんです。
まず、はじめに。 質問するときはたいがい漠然としてるものです。 答えが判ってたら聞いてないでしょうし。
他にも、SOPとか、Securityまでの守備範囲になるだろうね。 当然DBやネットワークにかかる負荷も計算しておかないとね。 あとは、もろもろ踏まえた上で3秒ルール適用とか。 やるこたいっぱいありますね。
フレームワークがサポートしてくれてる設計思想の部分がアーキテクトとして、 じゃぁ、サポートしてない範囲はどうしよう? (例えば、ホストマシンとの連携はStrutsはカバーしてないし、エラーログを自動検知で管理者にメールする機能とかつけるとなるとどうしよう?設定ファイル直しただけで再起動無しでサービスを続けるにはどうしよう?) フレームワークの設計思想、そこから導かれる適用範囲、それを考慮した上で、 技術的にこれは問題ないって断言してくれる人・・・と思ってます。 まぁ、チーム内部で一番技術的に細かい人ってな印象です。 それに、誰だか忘れたけど、Net上の紙面でアーキテクトはこれからプロマネに集約される・・・とかって言ってたので、潮目が変わってると思いますよ。 ご参考までに。 _________________ |
1