【オープンソースソフトウェアガバナンス】 MITRE : オープンソースソフトウェア

意味：

オープン ソース ソフトウェア (OSS) は、付属の OSS ライセンスに従うことに同意するだけで完全な所有権が取得される商用ソフトウェアであり、第三者による即時の検証は必要ありません。OSS ライセンスに同意すると、個人、企業、または政府機関は、人間が読めるソース コードの OSS アプリケーションを必要なだけ頻繁かつ広範囲にコピー、配布、実行することができ、配布要件に応じてライセンスを取得することができます。拡張する または、OSS アプリケーションを拡張します。OSS による支払いは間接的であり、ほとんどの場合、アプリケーションの修正や拡張機能の形でアプリケーションを保守するコミュニティと価値を共有することに同意することが含まれます。

キーワード:

FOSS、無料およびオープンソース ソフトウェア、オープンソース ソフトウェア、OSS

MITRE SEの役割と期待:

MITRE システム エンジニア (SE) は、大規模なシステムおよびシステムのシステムの構築にオープン ソース ソフトウェア (OSS) および関連するサポート プロセスを適用することの潜在的な利点、リスク、制限を理解する必要があります。新しい開発ではなく、該当する商用ソフトウェアの選択と使用を要求する連邦規制に確実に準拠するには、OSS 機能がシステム統合、エンドユーザー サポート、および構成可能性にどのように、どこに適用されるかを理解する必要があります。彼らは、取得コスト、長期サポート、拡張性、適応性、セキュリティ、要件の変化に直面したときの回復力の点で、OSS が他の形式の商用ソフトウェアとどのように比較されるかを理解する必要があります。SE は、エンジニアリング レベルおよびプロセス レベルでの OSS のセキュリティ特性と、これらの特性が他の種類の商用および政府ソフトウェアとどのように比較されるかを特に理解している必要があります。主要な OSS パッケージの認証ステータスと、OSS の分散所有権モデルで認証がどのように機能するかを理解する必要があります。彼らは、OSS サポート コミュニティと効果的かつ生産的に対話する方法を理解する必要があります。OSS サポート コミュニティでは、ソフトウェアの修正やアプリケーションの機能拡張に対して料金ではなく対価が支払われる物々交換ベースの経済が採用されています。

バックグラウンド

システム エンジニアリングのソフトウェア エンジニアリング分野およびエンジニアリング情報集約型企業において、オープン ソース ソフトウェアほど強い反応を引き出す可能性が高いトピックはほとんどありません。この反応は主に、関連する OSS ライセンスに従うことに同意した人が他のユーザーと同じ所有権を受け取る、コミュニティベースの OSS 所有権モデルに由来しています。このエンジニアリング変更権限の分散化は、ソフトウェア エンジニアリングの最も古く、最も深く根付いた前提の 1 つ、つまり、高品質で信頼性の高い信頼できるソフトウェアは、適切に管理された権限中心の最上位ソフトウェアを使用して開発された場合にのみ作成できるという前提に違反します。それは可能です - 下向きの開発プロセス。OSS は、集中化された開発権限の必要性を放棄するだけでなく、開発プロセスの制御をプログラマーの緩やかなコラボレーションに与えることで、この概念を覆します。ソフトウェアエンジニアリングでは、コーダーは要件を理解する可能性が最も低く、システムの完全性、品質、保守性、安全性を確保するために設計されたルールに違反する可能性が最も高い行為者とみなされていることが多いため、コーダーのプロセスに変更管理が与えられるのは当然のことです。不信の目で見られることが多い。

しかし、この見方は変わりつつあります。1 つ目の理由は、計画市場経済がイノベーションやリソースの効率的な利用を促進する点で自由市場経済と競合できないのと同様に、大規模なソフトウェア開発の取り組みを緊密に集中管理することは、局所的なイノベーションや適応を促進するほど効果的ではないという認識が高まっていることです。OSS は、このローカル イノベーションを促進し、ローカル イノベーションの人間が判読できる結果を、任意のレベルでの検査や分析にすぐに利用できるようにします。

もう一つの理由は実用的なものです。OSS の使用は民間システムと政府システムの両方で一般的であり、長年にわたって使用されています [1]。インターネットを最初に可能にした通信ソフトウェア (TCP/IP) は、有用なデータを提供した初期のサーバー システムの多くと同様、OSS でした。Microsoft は、自社の製品ラインを構築および拡張するためにオープン ソース ソフトウェアを広範囲に利用している多くの営利企業の 1 つです。Internet Explorer は、主に OSS に基づいている Microsoft ユーティリティのよく知られた例です。Mac から iPod、iPhone まで、基本的にすべての最新の Apple 製品は、カスタム ソフトウェアの薄い層を備えた OSS 上に構築されています。Google も社内および商用製品で OSS を多用する業界リーダーです。Apple と Google は、OSS を効果的に使用することで、コストのかかる設計者がレガシー コードの保守ではなく、まったく新しい機能の開発に集中できるようになり、より多くのより迅速なイノベーションを可能にする好例でもあります。最後に、現在一般市場で販売されているほぼすべてのネットワーク機器とカスタム ハードウェア ボックスは、そのほとんどまたは全体が OSS を使用して構築されています。OSS は、低コスト、容易な拡張性、新しい環境に適応する柔軟性、利用可能な幅広い機能、および現場で実証された信頼性により、機器ベンダーに人気があります。

政府の特典と利用

2009 年 10 月 16 日、米国国防総省 (DoD) は、オープン ソース ソフトウェア (OSS) の使用に関する最新のポリシーを公開しました [2、3]。このポリシーは、商用ソフトウェアの一形態としての OSS の法的地位を強調し、説明しています。これは、OSS が米国法 (10 USC 2377)、商用アイテムを優先的に購入する権利に準拠していることを意味します。コストを削減し、国防総省システムの品質を向上させるための商用オプションを検討する際に、OSS オプションの評価を含めないと、誤ってこの法律に違反する可能性があります。White House Developer Site [4] は、ソフトウェア開発者を GitHub 上の White House Project (分散オープンソース開発) [5] および Drupal (オープンソース ブログ) サイト [6、7] に誘導します。

ベストプラクティスと学んだ教訓

• フリー アンド オープン ソース ソフトウェア (FOSS) に関する米国国防総省の Web ページを読んで理解してください [8]。米国国防総省は数年をかけて、国防総省システムにおける OSS の役割を分析および説明する 3 つの文書を作成しました。このサイトでは、オープンソースに関する国防総省のポリシー、オープンソースの連邦的役割と法的地位に関するよくある質問、および 2003 年に遡るオープンソースの広範な人気と国防総省にとっての重要性に関する OSS 調査について取り上げています。このウェブページは一般的に書かれており、他の連邦省庁や連邦機関にもほとんど変更なく適用されます。特に、国防総省と協力している MITRE システムのソフトウェア エンジニアは、2009 年 10 月 16 日にサイトに掲載された国防総省の方針声明を必ず確認する必要があります。

• OSS をサポートするコミュニティが大規模であればあるほど、長期サポート コストの削減も大きくなります。この経験則は、大規模システムを構築するときに OSS がコストと容量の大きな利点をもたらす方法の核心です。コード自体を変更する機能とは何の関係もなく、実際、OSS ソース コードの変更に関心のある未熟なプロジェクトによって深刻な問題が発生する可能性があることに注意してください。OSS はフェデレーションとしての作業をサポートしているため、フェデレーションができるだけ大規模な場合、個々のメンバーにとってコスト効率が最も高くなります。OSS サポート コミュニティが特定の OSS 機能に関する世界クラスの専門家を含めるのに十分な規模である場合、これらのメンバーは広範なサポートに必要な時間の数分の 1 で困難な問題を解決できることが多いため、これらのコスト上のメリットはさらに大きくなります。

• OSS ライセンスの急増を避けます。OSS ライセンスはすでに多すぎます。組織にとって、独自の OSS ライセンスを作成することがどれほど魅力的であっても、各ライセンスは、それに対処しなければならない開発者、弁護士、プロジェクト マネージャーをさらに混乱させるだけであり、また、そのような新しいライセンスをサポートできる開発者を細分化する傾向があります。プール。通常は、次の 4 つの主要なライセンス タイプで十分です。

  • GNU1 General Public License (GPL): この一般的なライセンスでは、GPL ソース コードを使用して作成された新しいソース コード自体が GPL に基づいてライセンスを取得する必要があります。つまり、最初のソース コードを作成した OSS コミュニティに還元する必要があります。この機能により GPL は物議をかもしますが、恣意的に変更する利益の動機が排除されるため、システムやネットワークの深いインフラストラクチャを安定させるのにも非常に優れています。Linux カーネルの一部は GPL ライセンスに基づいて作成されており、これは GPL のもう 1 つの機能、つまり GPL のソフトウェアを使用せずに GPL コンポーネントへの標準インターフェイスを使用できることを示しています。

  • GNU Lesser General Public License (LGPL): これは、GPL コンポーネントを非 GPL コードに「ライブラリ コンポーネント」として埋め込むことを許可する GPL の変種です。GPL モデルは好きだが、企業によるソフトウェアのコンポーネントの使用や購入を妨げたくない小規模企業の間で人気があります。

  • Berkeley Software Distribution (BSD)/Apache: これらの寛容なライセンスにより、企業はソース コードのコピーを「キャッチ」し、それらのコピーとそれに加えられた変更を独自のものとして扱うことができます。Apple は、BSD ライセンスのこの機能を利用して、現在の Mac パーソナル コンピュータ、iPod、iPhone の製品ラインを作成しました。大量のソース コードを維持するだけでもコストがかかるため、ほとんどの BSD/Apache ライセンス提供者はコミュニティ モードで OSS 製品をサポートし続けています。システム エンジニアにとって、BSD および Apache ライセンスは、大規模なシステム作業に携わる中小企業が、BSD または Apache ライセンスで利用可能な OSS 機能を適応させるための強力なコスト インセンティブを確実に得るためのツールと見なされるべきです。たとえば、インターネット通信ソフトウェア (TCP/IP) の初期リリースに BSD のようなライセンス モデルを選択したことで、独自のネットワークを持つ数十の中小企業や大企業にコードが受け入れられ、最初に実用的なインターネットを立ち上げることができました。

  • 無ライセンス (政府コード): これは、政府職員が開発したコードに対して法的に要求されるステータスです。誰でも使用できるようにすることで BSD または Apache ライセンスに近似しますが、個人または企業が政府の出所を認めずに作品全体を「現状のまま」著作権で保護することを選択した場合、かなりの混乱を引き起こすでしょう。

• 関係する弁護士が OSS ライセンスを理解しているとは考えないでください。ソフトウェア、特にソフトウェアがどのようにして読み取り可能なソース コードから実行可能なマシン コードに変換されるかについてほとんど知識のない弁護士は、GPL ライセンスと LGPL ライセンスを理解することはおろか、読むことさえ困難になるでしょう。BSD および Apache ライセンスはソフトウェア構造の詳細を回避しており、弁護士にとって理解しやすいです。通常、弁護士が BSD と Apache を好む理由はただ 1 つあります。この残念な状況は徐々に改善されつつありますが、GPL と LGPL の場合、これらのライセンスの意味と影響については、依然としてプログラマーの方が、その影響を評価する任務を負っている弁護士よりもよく知っていることがよくあります。社会的企業は、このような断絶の可能性を認識し、可能であれば、弁護士に国防総省 FOSS Web サイトのよくある質問 (FAQ) などの関連文書を参照してもらう必要があります[3]。

• OSS を使用して共有インフラストラクチャを安定化します。ここでのインフラストラクチャとは、ネットワークやデータ共有などの基本的な機能を確立する大規模なシステム、またはシステムのソフトウェア コンポーネントを指します。すべてのシステム インフラストラクチャ プロジェクトの中で最も成功したインターネット プロジェクトの歴史が示すように、OSS を使用して基本的な機能の共有を促進することは、より複雑で、多くの場合予期せぬ新機能の出現を促進するための強力なツールとなり得ます。インフラストラクチャー。OSS は、企業が機能を恣意的に変更したり、顧客を独自の機能セットに固定したりする利益インセンティブを排除することで、大規模システムの安定化にも役立ちます。最後に、インフラストラクチャは最も革新性の低いコードであることが多いため、OSS を使用すると知的リソースが解放され、より革新的な新しい設計作業に使用できるようになります。

• OSS を使用して、高価なリソースをイノベーションに集中させます。大規模システムから「解決された」問題を分解して OSS に移動した最終結果は、図 1 のピラミッド状の構造に示されています。この図の主な概念は、安定していて変化が比較的遅く、十分にサポートされている機能を OSS コミュニティから除外することで、組織は切望されているデザイナーやコーダーをサポートの役割から引き抜くことができるということです。彼らは、組織の最も重要なニーズに焦点を当てた、より革新的な役割にメンバーを移行することができ、多くの場合、OSS のプロトタイピングおよび探索機能を活用できます (次の 2 つのエントリを参照)。

図 1. I-4 アーキテクチャ ピラミッド

• OSS 連絡先ポジションの使用が推奨されます。OSS リエゾンは、関連する OSS アプリケーション スイートの追跡、参加、使用を任務とする熟練したプログラマーです。経験豊富な OSS 担当者は、組織のニーズがサポート コミュニティによって理解およびサポートされていることを確認するとともに、OSS 機能の組み合わせが特定のシステム レベルの要件を満たしているか、どのようにサポートしているかについて、迅速に利用できる内部アドバイスを提供できます。OSS 連絡職は、標準的なソフトウェア エンジニアリングの職務内容という点では標準的ではありませんが、広範な要件が長期的なソフトウェア開発プロジェクトに不適切に変換されないようにするための最も効果的な方法の 1 つを提供します。 OSS ですでに利用可能な機能を通じてコピーされます。

• 探索的なプロトタイピングにおける OSS の利点について学びます。OSS が強力な探索用プロトタイピング ツールであるのと同じ理由で、OSS は大規模で複雑なシステム エンジニアリングの問題に典型的な統合問題に対する強力なアプローチも提供します。OSS には、さまざまな、そして多くの場合予期しないタイプのデータと通信プロトコル間の変換を支援するために特別に設計されたパッケージと言語が含まれています。大規模で複雑なシステムの場合、このような翻訳対応 OSS ツールの最も重要な利点の 1 つは、これらのツールを使用して、そのようなシステムの古くて廃止されたコンポーネントの予期される入力と相互作用をシミュレートできることです。このようなレガシー コンポーネントの変更には費用がかかり、リスクが伴うことが多いため、システムの残りの部分で現在のプロトコルと標準を維持しながら、レガシー システムへのこのような「ソフト」インターフェイスを構築できることは、アイテムに対する全体的なリスク値のレベルを最小限に抑えるのに非常に役立ちます。

• システムおよびシステム統合に対する OSS の利点について学びます。OSS が強力な探索用プロトタイピング ツールであるのと同じ理由で、OSS は大規模で複雑なシステム エンジニアリングの問題に典型的な統合問題に対する強力なアプローチも提供します。OSS には、さまざまな、そして多くの場合予期しないタイプのデータと通信プロトコル間の変換を支援するために特別に設計されたパッケージと言語が含まれています。大規模で複雑なシステムの場合、このような翻訳対応 OSS ツールの最も重要な利点の 1 つは、これらのツールを使用して、そのようなシステムの古くて廃止されたコンポーネントの予期される入力と相互作用をシミュレートできることです。このようなレガシー コンポーネントの変更には費用がかかり、リスクが伴うことが多いため、システムの残りの部分で現在のプロトコルと標準を維持しながら、レガシー システムへのこのような「ソフト」インターフェイスを構築できることは、プロジェクトの全体的なリスク レベルを最小限に抑える上で非常に価値があります。

• OSS ライセンスは、他の独自ライセンスと同様に扱ってください。大規模な連邦開発プロジェクトが、Oracle、IBM、Microsoft などの大手独自ソフトウェア会社とのライセンス契約に重大な違反を検討することは非常に異例です。しかし皮肉なことに、OSS とは無条件の「無料」ソフトウェアを指すという一般的な誤解もあり、ソース コードから OSS ライセンスを剥奪するなど、開発者が OSS ライセンスに違反することは驚くほど一般的です。これは開発品質と長期サポートの観点から見て非常に悪いアイデアであるだけでなく、違法かつ非倫理的であり、Free Software Foundation (FSF) などの監視団体による法的措置につながる可能性があります [8]。さらに重要なことは、OSS の本当のコスト削減の可能性が秘められているフェデレーテッド共有および貢献モデルを破壊することです。システム エンジニアは、特定のプロジェクトにおいて、OSS ライセンスが他の商用ライセンスと同じ程度に尊重されるように最善を尽くす必要があります。

• 大規模なシステムを構築する際に、新しいソフトウェアの必要性を最小限に抑えます。歴史的に、ソフトウェア プロジェクトは進捗状況を測定する方法として書かれたコード行を使用してきました。そのため、コードが増えることは良いことであると考える傾向がありました。ただし、コードの新しい行には、何十年にもわたる長期的なコストと信頼性の負担が伴うため、本当の目標はその逆であるべきです。SE は、新しい独自のソフトウェアの必要性を最小限に抑える方法を常に見つけるべきです。コードは通常、次のとおりです。必須ですが、比較的小さく、強力で、作成中のシステムに固有のものである必要があります。通常のファイル アクセスや標準ネットワーク通信などの一般的な機能はこのカテゴリには分類されないため、常に安定した、十分に標準化された OSS または独自のソフトウェアを入手して処理する必要があります。

• 社内開発を加速するための「無料のソースコード」としての OSS の概念には強く反対します。長期的なコード サポートのコストは、どのような種類のソフトウェアに比べても常に小さく見えます。この理由だけでも、OSS を短期的な開発目標を加速するための「無料」ソース コードとみなすことは、短絡的で率直に言って危険な見方です。良い例えは次のとおりです。あなたの組織が Microsoft Windows のすべてのソース コードを無料で入手したが、それ以降はすべてのバグを修正し、すべての機能拡張を自分で行う必要があると規定されている場合、あなたはその申し出を受け入れますか? 大規模な OSS パッケージは少なくとも Windows と同じくらい複雑であるため、このようなソース コードを小規模な社内プロジェクトに無計画に採用すると、非常に大規模で急速に時限爆弾に相当するサポート コストが発生することになります。便利な 3 段階の経験則は、最初に実行可能ファイルを試し、次にコミュニティ サポートを試し、最後に新しいコードを試すことです。

  • 常に最初に OSS の実行可能バージョンを試してください。OSS は代替の OSS よりも構成が容易な傾向があるため、最初のステップは、専門家に相談して、「標準リリース」バイナリ形式で OSS をダウンロードすることで、ニーズを満たす OSS アプリケーションを簡単に構成できるかどうかを確認することです。(セキュリティ上の理由から、ソースをローカルにダウンロードしてコンパイルすることもできます。)

  • 次に、機密性のない変更をサポート コミュニティに送信してみてください。OSS アプリケーションの一部の機能をどうしても変更またはソース コード レベルまで拡張する必要がある場合は、アプリケーションをサポートするコミュニティに直接送信できる方法で、必要な変更を表現するようにしてください。このアプローチは、長期的なソース コード サポートの必要性を軽減するだけでなく、サポート コミュニティとのより強い関係を構築するのにも役立ちます。

  • 最後の手段としてのみ、独自のモジュールを開発してください。コードの変更を公開してはいけないまれなケースでは、スタンドアロン モジュールを開発する方法を探してください。可能であれば、そのようなモジュールに OSS ソース コードを含めないでください。元の OSS が更新されるたびに、新しいモジュールに含まれる OSS ソース コードのすべての行をチェックして更新する必要があります。これにより、モジュールの法的ステータスも不必要に複雑になります。

• あまりにも気軽に政府コードを OSS として公開することは避けてください。機密性の低い政府既製 (GOTS) 製品を担当する政府プロジェクトは、OSS のコミュニティ サポート機能が非常に魅力的であると感じることが多く、安価で脆弱性を悪用するために、単に OSS ライセンスの下で GOTS 製品をリリースできないか疑問に思っています。利点 一部の OSS プロジェクトの修正と改善に対する長期サポート。この質問に対する答えは簡単です。「いいえ」です。OSS サポートの貴重な属性は、すでに製品に関心を持っているコミュニティから得られ、OSS の貴重なモジュール性と柔軟性は、長年にわたって開発してきた人々のコミュニティから得られます。ライセンスを変更して GOTS 製品の OSS を作成し、それを Web サイトに掲載するだけでは、そのすべての欠陥が興味のあるハッカーに公開されてしまいますが、必ずしもサポーターの興味を引くとは限りません。サポーターはいずれにせよ、ほぼ確実に見慣れないソースに興味を持ちます。コードが混乱しています。GOTS アプリケーションを置き換えるより良い方法は、GOTS 機能を近似するために使用できる既存の OSS ツールの構成を探すことです。次に、元の GOTS ツールのフル機能エミュレーションまたは拡張機能として、その構成を中心とした新しいコミュニティの構築を開始してみてください。

• すべての商用ソフトウェアのセキュリティについて現実的な理解を促します。ソフトウェアがバイナリ コードとして販売または配布される場合、現代世界におけるそのセキュリティ ステータスは、人間が読めるソース コードとして配布されるソフトウェアと何ら変わりません。その理由は、最新のハッキング ツールは、バイナリ形式のソフトウェアを直接ターゲットにして破壊しようとするため、バイナリ形式はある意味、人間が読める形式よりも優れており、分析に非常に時間がかかるためです。したがって、「ソースコードが利用できる」からといって OSS を安全にできないという一般的に言われる懸念はナンセンスです。

  • その代わりに、ソース コードを世界から隔離した状態に保つ多くの独自プロセスは、複数のレベルで問題を抱えており、そのようなシステムのセキュリティを重大に損なう可能性のある変更を人々に挿入する機会を与えています。結論は次のとおりです。セキュリティは、各ケースの実際的な詳細に基づいて最もよく評価されるプロセスであり、独自の方法を使用して開発されたか、OSS コミュニティの方法を使用して開発されたかによって、調査する必要がある内容が変わります。独自の方法にはより多くの収益をもたらすという利点がありますが、コミュニティの方法はより多くのユーザーの目に留まりやすくなります。OSS がグローバルに活動している場合、OSS は侵入の試みを発見する可能性がより高い専門家を引き寄せることもできます。

  • OSS は「何千もの目」が見ているから常に安全であるという反論も、単純な理由から誤りです。ソース コードが Web サイトで公開されているからといって、誰もがそれを見ているわけではありません。プロプライエタリなソフトウェアは、何らかの方法で「認定」されているため、より安全であると宣伝される場合もあります。残念ながら、科学的に評価された実地調査では、未認定のソフトウェアよりも安全または信頼性の高いソフトウェアを作成するためのソフトウェア認定プロセスが示されていないため、これらの認定が企業が何でもできることを意味しているかどうかは不明です。そのような認証にかかる高額な費用を負担する必要があります。認定の適用には一貫性がなく、フェデレーション デスクトップでは、一度も認定されていないシステムやアプリケーション、または認定されてから時間が経ち認定が適用されなくなったシステムやアプリケーションが実行されることがよくあります。OSS は、「誰でもコードに変更を挿入できる」ため、安全ではないと考えられることがあります。誰もが OSS ソース コードのコピーに好きな変更を加えることができるのは事実ですが、現実には、Linux などの大規模でアクティブな OSS プロジェクトでは、コードをメイン ビルドにのみ許可する、厳重に保護され、高度に自動化されたコード制御プロセスが行われています。このプロセスは、世界トップクラスのオペレーティング システム カーネルの専門家によって厳密に検査されており、そのレベルの検証は、ほとんどの独自コードの管理およびレビュー プロセスを矮小化するものです。

• ソフトウェア認定: 認定を探し、取得をサポートしますが、決して依存しないでください。上で述べたように、ソフトウェア認定がソフトウェアの現場レベルの信頼性または安全性に影響を与えるという科学的証拠はありません。それでも、多くの状況で必要になります。OSS の場合、IBM などの企業が認定の提供を支援します。したがって、SE は念のため関連する OSS の認定を探し、独自の同等の認定とどのように比較するかを確認する必要があります。関心のあるプロジェクトは、通常、特定の OSS コンポーネントの使用のビジネス面を扱う小規模な専有企業などを通じて、OSS グループが認証を取得するのにも役立ちます。最後に、商用ソフトウェア コンポーネントが OSS で認定されているかどうかに関係なく、ネットワーク化されたソフトウェア システム全体のセキュリティが証明されていると想定すべきではなく、複数のセキュリティ層が絶対に必要です。

この記事: https://architect.pub/mitre-open-source-software
ディスカッション: Knowledge Planet [チーフ アーキテクト サークル] または WeChat トランペット [ca_cto] を追加するか、QQ グループを追加します [792862318]
一般公開なし	【jiagoushipro】 【スーパーアーキテクト】 アーキテクチャの方法論、アーキテクチャの実践、技術原則、技術トレンドについての鮮やかなグラフィックと詳細な説明。 お待ちしておりますので、ぜひスキャンしてご注目ください。
WeChatのトランペット	[ca_cea] エンタープライズ アーキテクチャ、クラウド コンピューティング、ビッグ データ、データ サイエンス、モノのインターネット、人工知能、セキュリティ、フルスタック開発、DevOps、デジタル化について議論する 50,000 人のコミュニティ。
QQグループ	[285069459] エンタープライズ アーキテクチャ、ビジネス アーキテクチャ、アプリケーション アーキテクチャ、データ アーキテクチャ、技術アーキテクチャ、統合アーキテクチャ、セキュリティ アーキテクチャの詳細な交換。そして、ビッグデータ、クラウドコンピューティング、モノのインターネット、人工知能などのさまざまな新興テクノロジー。 QQ グループに参加して、貴重なレポートや乾物を共有してください。
ビデオ番号	【スーパーアーキテクト】 建築に関する基本的な概念、モデル、手法、経験が1分ですぐに理解できます。 1日1分、仕組みはおなじみです。
知識の惑星	[チーフアーキテクトサークル] 著名人に質問したり、連絡を取ったり、プライベートな情報を共有したりしてください。
ヒマラヤ	[スーパーアーキテクト] 最新のブラックテクノロジー情報と建築体験を道路や車の中で学びましょう。	[知的な瞬間、ミスター・アーキテクチャーがブラックテクノロジーについて語ります]
知識の惑星	より多くの友人、職場、技術的なチャットに会いましょう。	ナレッジプラネット【職場とテクノロジー】
リンクトイン	ハリー	https://www.linkedin.com/in/architect-harry/
LinkedInグループ	LinkedIn アーキテクチャ グループ	https://www.linkedin.com/groups/14209750/
微博	【スーパーアーキテクト】	賢い瞬間‍
ビリビリ	【スーパーアーキテクト】
チクタク	【cea_cio】スーパーアーキテクト
早い労働者	【cea_cio_cto】スーパーアーキテクト
小さな赤い本	[cea_csa_cto] スーパーアーキテクト
Webサイト	CIO（最高情報責任者）	https://cio.ceo
Webサイト	CIO、CTO、CDO	https://cioctocdo.com
Webサイト	アーキテクトの実践的な共有	https://architect.pub
Webサイト	プログラマーのクラウド開発共有	https://pgmr.cloud
Webサイト	チーフアーキテクトコミュニティ	https://jiagoushi.pro
Webサイト	アプリケーション開発と開発プラットフォーム	https://apaas.dev
Webサイト	開発情報ネットワーク	https://xinxi.dev
Webサイト	スーパーアーキテクト	https://jiagou.dev
Webサイト	企業向け技術トレーニング	https://peixun.dev
Webサイト	プログラマーの本	https://pgmr.pub
Webサイト	開発者チャット	https://ブログ.開発者.チャット
Webサイト	CPOコレクション	https://cpo.work
Webサイト	最高セキュリティ責任者	https://cso.pub ‍
Webサイト	CIOクール	https://cio.cool
Webサイト	CDO情報	https://cdo.fyi
Webサイト	CXO情報	https://cxo.pub

ご清聴、転送、いいね、ご視聴ありがとうございます。