私の知る限り、Solutions ArchitectはApplications Architectの別の「マーケティング」用語です。それは正しいですか、それとも実際にはどういうわけか役割が異なりますか? もしそうなら、どのように?
はい、StackOverflow と Google の両方でこれを検索しました。
私の知る限り、Solutions ArchitectはApplications Architectの別の「マーケティング」用語です。それは正しいですか、それとも実際にはどういうわけか役割が異なりますか? もしそうなら、どのように?
はい、StackOverflow と Google の両方でこれを検索しました。
2018年1月5日更新-過去9年間で、私の考え方はこのトピックに関してかなり進化しました。私は大多数よりも業界の最先端に少し近いところに住む傾向があります(確かに、多くの本当に賢い人々ほど限界を押し広げているわけではありませんが)。私は、アプリケーションからソリューション、エンタープライズ、大小さまざまな企業で、さまざまなレベルのアーキテクトを務めてきました。私たちのテクノロジー業界の未来は、ほとんど建築家のいないものであるという結論に達しました。。これがおかしなことに聞こえる場合は、数年待ってください。そうすれば、おそらくあなたの会社が追いつくでしょう。さもないと、それを理解した競合他社があなたに追いつく(そして追い抜く)でしょう。基本的な問題は、「アーキテクチャ」が、アプリケーション/ソリューション/ポートフォリオに関して行われたすべての決定の合計にすぎないということです。つまり、「建築家」というタイトルは、実際には「決定者」を意味します。それは多くのことを言います、それがそうではないことによってもいう。「ビルダー」とは言いません。人々に「構築する」ことを暗黙のうちに伝えるキャリアパス/階層を作成することは「決定すること」よりも低く、「決定者」は「構築すること」に対して(タイトルの違いによって)直接責任を負いません。建築家の称号にまだ固執している人々は、これに摩擦し、「しかし、私は実践的です!」と抗議します。素晴らしいです。あなたが単なるビルダーである場合は、意味のないタイトルを放棄し、他のビルダーとの差別化をやめてください。「すべてのビルダーは決定者であり、すべての決定者はビルダーである」ことを強調する企業は、競合他社よりも速く動きます。私たちは皆のために「エンジニア」というタイトルを使用し、「エンジニア」は決定と構築を意味します。
元の答え:
非常に大規模な組織で働いたことがない(または働いたことはあるが、機能不全の組織だった)人々にとって、「建築家」は彼らの口に悪い味を残したかもしれません。しかし、それは正当な役割であるだけでなく、賢明な企業にとって非常に戦略的な役割でもあります。
アプリケーションが非常に広大で複雑になり、全体的な技術ビジョンと計画を処理し、ビジネスニーズを技術戦略に変換することがフルタイムの仕事になる場合、それはアプリケーションアーキテクトです。アプリケーションアーキテクトは、多くの場合、開発者を指導および/またはリードし、責任のあるアプリケーションのコードをよく知っています。
組織に非常に多くのアプリケーションとインフラストラクチャの相互依存関係があるため、それらのコードに関与することなく、それらの整合性と戦略を確保することがフルタイムの仕事である場合、それはソリューションアーキテクトです。ソリューションアーキテクトは、アプリケーションアーキテクトに似ている場合もありますが、ビジネスの論理ソリューションを構成する特に大規模なアプリケーションのスイートを超えています。
組織が非常に大きくなり、ソリューションアーキテクトの高レベルの計画を調整し、ビジネステクノロジ戦略の条件を組み立てるのがフルタイムの仕事になる場合、その役割はエンタープライズアーキテクトです。エンタープライズアーキテクトは通常、経営幹部レベルで働き、経営幹部とそのサポート機能、およびビジネス全体にアドバイスを提供します。
インフラストラクチャアーキテクト、情報アーキテクト、その他数名もいますが、総数では、これらは「ビッグ3」よりも少ない割合を占めています。
注:他の多くの回答では、これらのタイトルには「標準がない」とされています。それは真実ではありません。Fortune 1000企業のIT部門に行くと、これらのタイトルが一貫して使用されていることがわかります。
「アーキテクト」に関する最も一般的な2つの誤解は次のとおりです。
これらの誤解は、多くの建築家がかなり悪い仕事をしていることや、組織が建築家の目的を理解するのにひどい仕事をしていることに起因しています。トッププログラマーをアーキテクトの役割に昇進させることは一般的ですが、それは正しくありません。それらはいくつかの重複しているが同一ではないスキルセットを持っています。最高のプログラマーは、常にではありませんが、多くの場合、理想的なアーキテクトです。優れたアーキテクトは、IT業界の多くの技術的側面をよく理解しています。開発者が必要とするよりもビジネスニーズと戦略をよりよく理解する。優れたコミュニケーションスキル多くの場合、プロジェクト管理とビジネス分析のスキルがあります。アーキテクトは、コードで手を汚さず、技術的に鋭敏に保つことが不可欠です。良いものはそうです。
基本的に、IT 認定資格の世界では、「本物の」専門組織に足を踏み入れない限り、好きなように名乗ることができます。たとえば、名刺に「マイクロソフト認定ソリューション エンジニア」であっても、「プロフェッショナル エンジニア」(または P. Eng) というマジック フレーズを書いた場合、その鉄の指輪を持っていない限り、法的な問題に直面します。「本物の」アーキテクトに似たような称号があることは知っていますが、覚えていませんが、「Cisco Certified Network Architect」などになることができると言及しない限り.
アーキテクトの役職には業界標準の定義はありません。アプリケーション/システム/ソフトウェア/ソリューションアーキテクトはすべて、一般に、強力な設計とリーダーシップのスキルを持つ上級開発者を指します。設計、戦略、開発(多くの場合、コアサービスまたはフレームワーク)、および管理のバランスは、組織とプロジェクトによって異なります。
私にとって本当に異なる意味を持つ唯一の「アーキテクト」の役職は「エンタープライズアーキテクト」であり、これは私がIT戦略の立場にあると考えています。
アーキテクトのタイプには有効な違いがあります。
エンタープライズ アーキテクトは、エンタープライズ戦略と密接に連携するエンタープライズ向けのソリューションを検討します。たとえば銀行では、彼らは完全な IT ランドスケープを見ます。
ソリューション アーキテクトは、銀行の新しいクレジット カード取得システムなど、特定のソリューションに焦点を当てます。
ドメイン アーキテクトは、アプリケーション アーキテクトやネットワーク アーキテクトなど、特定の分野に焦点を当てています。
テクニカル アーキテクトは、一般に、ビジネス面よりもテクノロジー面に重点を置いたソリューション アーキテクトの役割を果たします。
いいえ、アーキテクトはプログラマーとは別の仕事をしています。アーキテクトは、非機能 ("ility") 要件に関心があります。信頼性、保守性、セキュリティなど。(同意しない場合は、この思考実験を検討してください。複雑な Web サイトを処理する C で記述された CGI プログラムと、Ruby on Rails 実装を比較してください。どちらも同じ機能上の動作をしています。RoRアーキテクチャを選択すると、どのような利点があります。)
一般に、「ソリューション アーキテクト」はシステム全体 (ハードウェア、ソフトウェア、およびすべて) に関するものであり、「アプリケーション アーキテクト」は固定プラットフォーム内で作業しますが、用語はそれほど厳密ではなく、十分に標準化されていません。
「アーキテクト」とは、高レベルで連携して機能するアプリケーションの複数のレイヤーを設計できる人に与えられる称号です。特定のタイプのテクノロジー(つまり、「ソリューション」、「アプリケーション」、「ビジネス」など)なしで一般的なタイプの「アーキテクト」に入るものはすべて、マーケティングの話です。
実際にはかなりの違いがあります。ソリューションアーキテクトは要件を全体的に見て、たとえば、要件は、ピザの注文を受けるコールセンターのスタッフの数を減らすことであり、ソリューションアーキテクトは、来る必要のあるすべてのコンポーネントを調べます。これを満たすために、使用する音声認識ソフトウェア、必要なハードウェア、それをホストするのに最適なOS、IVRソフトウェアとプロビジョニングシステムの統合などを一緒に実現します。
一方、このシナリオのアプリケーションアーキテクチャは、ソフトウェアがどのように相互作用するか、どの言語が最適か、既存のAPIを最適に使用する方法、存在しない場合はAPIを作成する方法などの詳細を扱います。
どちらにも場所があり、要件を満たすために両方のタスクを実行する必要があります。大規模な組織では、専任の担当者がそれを実行します。小規模な開発ショップでは、多くの場合、開発者はすべてのアーキテクチャタスクをその一部として引き受ける必要があります。全体的な開発、他に誰もいないので、それは単なるマーケティング用語であると言うのは過度に冷笑的であり、それは実際の役割であり(開発者がその場でそれを拾う場合でも)、プロジェクトのキックオフで特に価値があります。
私には同じように聞こえます!私はオリに完全に同意しませんが。必要に応じて、選択した数人にソフトウェアアーキテクトの称号を与えますが、経験上、ソフトウェアアーキテクトの称号に実際に値する人は、通常、称号に含まれていません。
私の経験では、Computer Associates でコンサルティングを行っていたときのマーケティングの叫びは、「製品ではなく、ソリューションを販売する」というものでした。したがって、プロジェクトを取得し、アーキテクトの帽子をかぶる必要がある場合、私はソリューション アーキテクトになります。主に CA 製品であり、場合によってはサード パーティまたは手でいくつかのコンポーネントを使用するソリューションを設計するためです。コード化された要素。
今、私は開発者としてより集中しており、アプリケーション自体のアーキテクトであるため、アプリケーション アーキテクトです。
私はそう見ていますが、すでに議論したように、命名基準にはほとんど意味がありません。
肩書きが多すぎて名刺にタイトルが収まらない場合は、誰かがワードスミスで気の利いたタイトルを付けてくれます。
例: プログラミング/IT/プロジェクト管理/戦略/ビジネス アナリスト
建築家の称号を受け取るその他の方法:
スペル?
真剣に - 彼らは両方とも BS の役職の毛羽立っています。「プログラマー」はあなたにとって十分ではありませんか?「建築士」になろう!
本当に.世界は何に来ている?!
編集: 私は明らかにいくつかの「建築家」の感情を傷つけました!
編集 2: この言い回しは、一部の人々が問題のドメイン全体 (ハードウェア、ソフトウェア、展開、保守など) に対処することを意味すると解釈できるという意見には同意しますが、ほとんどの人はクライアントを満足させたい (そしてより多くのお金を稼ぎたい) と考えています。肩書きに関係なく、必要に応じて完全なサービスを提供します。
実生活では、それは単なるマーケティングのたわごとです。