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