Java資格は建築家の役割にとって重要ですか？
Java認定（SCJP、SCWCDなど）が建築家の立場にとってどれだけ重要かを知りたい。ある人がJava開発で良い経験をしていて、アーキテクトレベルでのキャリアを追求したい場合、彼は彼のCVの認定を受ける必要があると思いますか。彼がリード開発者の役割に取り組んだことがない場合はどうなりますか？
建築家のポジションの面接を行う場合。そして、私は5年の経験を持つさまざまなチームでJava Web開発者として働いてきました。決して導きません。そして、私は私の履歴書に認定バッジを持っています。
開発者はどのようにしてチームのアーキテクトになるためのキャリアパスを作ることができますか？
Javaスペースでの認証の皮肉は、それが実際に私が最も有用だと思う最低レベルのものであることです。
私は古いSun Certified Java Programmer（たとえば、あなたが持つことができる最低のもの）を持っています。まともなプログラマーがJavaチュートリアルを数週間実行しても習得できなかったものは何でも教えてくれます。単純なフィルターとして機能します。合格するためには、基本的なコアを知っている必要があります。 Java-この意味で、これはおそらく、まっすぐな直筆のプログラマーを探しているジュニアロールにとって、やや有用なフィルターです。Javaプログラマー。それがあれば、つまり、基本的なJavaを知っているということです。
私はこれよりも高い資格を取得したことはありませんが、正直なところ、経験から、ほとんどの建築家はシニアやチームリーダーになり、彼らが何をするのが得意であるだけで会社に昇進することでそこに着くことがわかりました。 Java私がこれまで働いていたアーキテクトの役割のために誰かを雇うのに携わってきた会社は、本当に想像できません。それは、最終的にアーキテクチャを手に入れた社内の上級開発者とチームリーダーです役割。
とにかく、重要なのは、これらのスキルを発揮する大規模なタスクの所有権を取得することにより、高レベルのシステムアーキテクチャと設計に対する適性を示すことです。おそらく、何らかの方法で、まずはより低いレベルのチームリーダーになる必要があります。証明されたチームをリードし、「アーキテクチャのような」高レベルシステム設計の経験は、このレベルのどの認定よりもはるかに長い道のりです。
注：私自身は建築家ではありません（チームのリーダーでさえありません）が、これはさまざまな企業で10年以上にわたって観察してきたことです。結局アーキテクトになる人々は、大きなタスクの所有権を取り、チームを主導し、物事を成し遂げる方法を知っている人々です。また、Java認定を取得している人すら知りません。
私は人々にインタビューするときはいつでも、私は通常彼らの資格を無視します。私の経験では、認定は実用的な知識にとって良いバロメーターではありません。面接中の私の質問は通常、その人が必要な情報を知っていて、それを実際の問題に適用できるかどうかを知らせてくれます。
私のキャリアの早い段階で私はSCJPについて学び、それを達成しました。認定の目標が、Javaの複雑な詳細を研究および学習する動機であったという理由だけで、それをもう一度やりました。ただし、認定自体は私のキャリアには何の影響もありませんでした。
彼らは米国ではほとんど問題にならない傾向がありますが、ソフトウェアアーキテクトなどのトップの仕事のための真の資格のある応募者や競争の激しいインドが多いインドのような場所では、特定の候補者を除外するために使用できます。
認定は、ほんの少しだけ有益であっても、最終的にはそれだけの価値があると思いますが、確かに、認定は真の才能やスキルよりも重要度が低いです。
SAロールの準備ができているとは思わないが、あなたの質問は私に関係しています。優れたソフトウェアアーキテクトのIMHOは、多数の異なるテクノロジーの中で多様なバックグラウンドを持っている必要があります。彼/彼女はフレームワークまたは言語について少なくとも高いレベルの理解があり、レガシーシステムの設計における長所と短所を批評的に評価する能力。多くの制約がある場合、優れたソフトウェアアーキテクトは、さまざまな潜在的なソリューションやそれぞれの長所と短所を比較検討します。
上級管理者から、なぜ選択するのかと尋ねられたときJava over Ruby何と言いますか？PHP =対C＃？貧血データモデルを定義できますか？Java EEアプローチがSpring Framework AOPアプローチより優れている、またはその逆の利点は何ですか？
これらは、建築家が答えることができる種類の質問であり、これらについて調査を行う必要がある場合は、そのタスクを実行できない場合があります。
SCJPは非常に基本的な証明書です。あなたは確かにこれを取得し、SCJDを実行する必要があります。 （これらのものには新しい名前が付けられていることに注意してください。）SCWCDも基本です。もっと印象的なことをしてください。
http://en.wikipedia.org/wiki/Sun_Certified_Professional
職務に関しては、建築の職種を探す前に、プロジェクトのリーダーシップを発揮する必要があります。
国際ソフトウェアアーキテクチャ認定ボード は、方法論的および概念的なノウハウに重点を置いた、ベンダーおよびテクノロジーに中立なカリキュラム（コースやクラスは販売していません！）を提供します。
Imho、テクノロジー中心の認定を補完できます。
認証は建築家のキャリアパスに適していますか？
はい。私の意見では、認定された主な結果は概要です。あなたは技術を知っています（それはあなたが技術の使い方を知っていることを意味するのではないことに注意してください-それは練習が必要です）。建築家にとっては、彼の専門分野で使用されているテクノロジーの概要を理解することは非常に有用ですが、Java世界の認定資格で十分である必要はありません。いくつかの主要なアプリケーションについても知っておく必要があります。サーバーとフレームワーク。
私は多くのMS認定を通過し、これらの認定の準備のために、これまで使用する必要がなかったAPIの一部に慣れました（そして、それらについてまったく知らなかった場合もあります）。後で、APIのこれらの部分をいくつかの問題のすぐに使えるソリューションとして提案することができました。それが私が認証を取得し続ける理由です。認定自体は、関連事項を知っていることを証明するまで、面接では何も意味しません。
認定資格は建築家としての就職に役立ちますか？
いいえ。認証自体は何も意味しません。 「建築家」になるには、他のスキルが必要です。プログラミング自体はアーキテクトになるのに十分ではありません-決定を下し、責任を負い、コンポーネントまたはアプリケーション全体を設計し、他の人のために作業を準備する（場合によってはリードする）必要があります。コミュニケーション能力が必要です。
少なくともそれが建築家に期待していたことです。しかし、何を/誰が建築家ですか？私にとっては、これは流行語に過ぎません。私が今まで会ったことのある建築家の半数以上が、昇進するための適切な場所でちょうど良い時間（または十分長い時間）にいた。建築家であることは、あなたが他の人よりも優れている、または優れているという意味ではありません。自分を建築家と呼んでいる人に出会ったとき、私はいつも非常に疑わしいです。
結論-NFRのコンテキストでコーディングを理解し、それらがどのようにビジネスの問題を解決し、戦略的な利点を生み出すかを理解する必要があります。うまくプログラムできることについては何も言わなかったことに注意してください（通常は予想されますが、これには他のほとんどのコメントが含まれますが、これらはさらに拡張されます。Springを選択すると、変更可能性を犠牲にしながら、軽量で高速なアプリケーションが得られますか？では、この属性の決定がビジネスに与える影響は何ですか？それは、新しく形成されたDevOpsチームに構成管理と保守性の課題をもたらしますか？非公開SaaS=デリバリーモデルは理にかなっていますか？ある投稿者が言ったように、企業のビジネスモデル、戦略、部門/ビジネスユニットのコンテキストに基づいてフィードバックを分析し、技術的な決定に調整を加えながら、意思決定、それらの決定を擁護し、それらの決定をサポートできない最善の方法で他者を啓発することについて非常に重要ですそのモデルと戦略。
したがって、証明書が必要だと思われる場合は、おそらく正しいでしょう。しかし、言語固有のSCJPレベルを超えて必要になるものはあまり明確ではありません。 ITIL、PMI-ACP、CSSLP、TOGAF9、ArchiMate 2、SEI Software Architecture Professional CertificateおよびATAM Evaluator Certificate、そして堀を重要な点として探求するのはよいでしょう-IASA Foundation Associate。これらは、SCWCDよりもアーキテクトになるための準備をはるかに進めます。そうは言っても、SCEA（現在はOCM Java Architect））を入手することは、Javaの世界で特別に準備して、ボードを処理するための実りある練習になる可能性があります。レビューですが、それ以外は、私が言及したものに焦点を当てます。
技術的な能力と忍耐力があることを示しているため、おそらく役立つでしょう。
しかし、実際にはそうすべきではありません。アーキテクチャはプログラミングではありません。
ここでは「ソリューションアーキテクト」の役割について話していると思います。ソリューションアーキテクトの役割は非常に複雑で、多くのことを伴います。
- 組織のエンタープライズアーキテクチャの理解と準拠
- 同技術アーキテクチャ
- 同上セキュリティアーキテクチャ
- プロジェクトスポンサーの目的と目標を理解する。要件がこれらの目標に関連していることを確認する
- テクニカルアーキテクトが推奨するものの中から、プラットフォーム、開発言語、フレームワーク、ライブラリなどを選択する。
- おそらく（そしてこれを行うには本当に正当な理由が必要です！）テクニカルアーキテクトに、推奨されたセット以外のプラットフォーム、言語、またはフレームワークを受け入れるように説得するでしょう。
- 他のアプリケーションへのインターフェースのネゴシエーション。
- セキュリティアーキテクトに必要なドキュメントを提供します。
- 非機能要件、予想される負荷などに基づいてハードウェア要件を定義する.
- 必要なハードウェア、ネットワーク接続、ソフトウェアなどをインフラストラクチャチームに要求する
- インフラストラクチャチームが必要とするドキュメントの提供
- 運用チームが必要とするアーキテクチャドキュメントの提供
役割のごく一部はプログラミング環境と開発環境を扱いますが、実際には、ほとんどの時間はボイラープレートのドキュメントの記入、または唯一の貢献が馬鹿げた提案を拒否し、いくつかの残余があることを確認するための無限の会議への出席に費やされます結果として生じる合意の健全性。
少なくとも企業の世界では、資格を持っている人は常に持っていない人よりもエッジを持っています。必ずしも知識/スキルに関してではなく、企業が主導権を示しているようにエッジがあります。