皆さん、こんにちは。今日はビジネス アーキテクチャについて説明しますが、ビジネス アーキテクチャとは何か、プロダクト マネージャーの観点からそれをどのように実行するかについては話していません。その代わりに、テクニカルアーキテクトの観点から、ビジネスアーキテクチャにどのように着手するか、またはビジネスアーキテクチャがない場合に、ビジネスの変化傾向を判断してシステムアーキテクチャに事前に対応する方法について説明します。
1. 背景
研究開発担当者は技術アーキテクチャを持ち、プロダクトマネージャーはビジネスアーキテクチャを持っています（通常は1名） テクニカルアーキテクトがビジネスアーキテクチャを理解していない場合、次のようなダイアログが表示されます。
Xiao Wang、テクニカル エンジニア: 「プロダクト マネージャーが再び需要を変更しました。昨日、在庫状況に応じて注文を分割する必要があると言われました。オンラインにアクセスしたところ、今日、プロモーションの種類に応じて注文を分割するように言われました。 」
建築家シャオ・サン氏: 「ビジネスは急速に発展しています。その日、彼は製品の量に応じて分割したいと言いましたが、私はそれをブロックしました。」
技術エンジニアのシャオ・ワン氏: 「素晴らしいですね、あなたにはまだ発言する権利があります。」
誰でも似たような問題に遭遇することは多いと思いますが、テクニカルアーキテクトがビジネスアーキテクチャを理解していると、次のような対話シーンになります。
テクニカル エンジニア Xiao Wang: 「プロダクト マネージャーが再び需要を変更しました。昨日、在庫状況に応じて注文を分割する必要があると言われました。オンラインにアクセスしたところ、今日はプロモーションの種類に応じて分割するように言われました。幸いなことに、このルールについては、前回教えていただきましたね。変更可能です。さまざまな注文のロジックを細分化してみましょう。構成を変更して完了できます。アーキテクトにふさわしいのですが、この変更可能な部分をどのようにして知っていますか? 知っていますか?占い？"
建築家シャオサン：「ははは、未来を予測するのは本来建築家の仕事ですよ。」
技術エンジニアのシャオ・ワン: 「早く教えてください。」
次に、テクニカル アーキテクトが将来のビジネス展開を予測できるようにする方法を学びましょう。
2、解決策
テクニカル アーキテクトはビジネス アーキテクチャの知識を理解する必要がありますが、バリュー チェーンやその他の概念など、プロダクト マネージャーほど多くのことを知る必要はありません。彼が知る必要があるのは、ビジネスの発展と変化の傾向を特定し、対応する部分の技術アーキテクチャを構造化して拡張する方法です。今日は簡単な方法、MIT 知識モデルを紹介します。簡単に言うと、 1：マッピング（Mapping） 2：識別（identify） 3：問合せ（ask about）
マッピング (マッピング) : すべての要件は、コンピュータ プログラムがどのシナリオ (イベント) で動作し始めるか、プログラムがどのデータ (エンティティ) を読み取る必要があるか、およびどのような順序 (アクティビティ) で読み取る必要があるかという、次の体系的かつ構造化された言語にマッピングできます。誰 (組織/役割) がルール (タスク) を実行し、実行後にどのようなデータ (エンティティ) が生成されるか。ただし、特定のシナリオでは、順序 (アクティビティ)、ルール (タスク)、および誰 (組織/役割) を変更する方が簡単です。
Identify (特定) & ask ( ** について質問) : したがって、プロダクト マネージャーと要件を伝達する際に最も重要なことは、順序とルールを特定することです** (組織/役割は通常、権限システムの RBAC モデルで構成可能です) 、考慮する必要はありません）。順序とルールを素早く特定するにはどうすればよいでしょうか?
1. シーケンス: 1 つのシーン内の複数のビジネス活動。通常、プロダクト マネージャーのビジネス フローチャートに表示されます。製品導入機能など、「洞察」、「選択」、「投資」などの複数のステップを経る必要があります。 、「法務」などのビジネスプロセスノード。この注文を見つけた後、主に製品に 2 つの質問をすることで、変更可能かどうかを判断できます。「この注文は、顧客、チャネル、カテゴリ、またはチャネルごとに異なりますか?」「この注文は、短期的なオンラインのプレッシャーによるものですか?」妥協案は単純化されただけです。」通常、プロダクト マネージャーはリサーチを行うときにこの情報を入手します。プロダクト マネージャーが確信を持てない場合は、プロダクト マネージャーにこの情報を調査してもらうように依頼できます。システム アーキテクチャを処理するとき、スケーラビリティに対処するさまざまな方法があります。複数のマイクロサービスを作成するか、プロセス エンジン ツールを使用してスケーラビリティを実装できます。 。
2. ルール: 通常 (IF A then B) モードでは、通常、各連続ノードの下にあります。たとえば、製品が「洞察」ビジネス活動を導入する場合、次の単語が見つかった場合: 「製品がメジャー アプライアンスの場合、価格競争要素を考慮する必要がある」「製品の動きが遅いタイプであれば、インサイトに参加する必要はない」など。このような用語を見つけた場合は、基本的にルールであると判断できますが、たとえば ** 「在庫状況に応じて注文を分割します。オンラインになったばかりで、今日はプロモーションの種類に応じて分割するように言いました。「分」、**実際には、ここに明らかな (IF A then B) パターンはありませんが、通常、形容詞を伴う動詞は変更される可能性があります (在庫に応じて分割するなど)スターテス）。しかし、注意深く調べたり考えたりすると、2 つの分割ロジックは条件付きまたは順次でなければならないことがわかります。そうでないと、同じ順序の分割が台無しになります。この時点で、商品に関する質問が 2 つある場合、「1. このルールは、さまざまな顧客/チャネル/カテゴリーまたはチャネル、期間、優先順位などの特定の条件下で有効かどうか」ということになります。「2. このルールには、さまざまな顧客/チャネル/カテゴリ、およびその他の目的またはチャネル用の他のルールが存在する可能性があります。」同様に、プロダクト マネージャーが確信を持てない場合は、プロダクト マネージャーにこの情報を調査してもらうように依頼できます。システム アーキテクチャを処理するときに、さまざまな方法でスケーラビリティを処理できます。最も単純なコードを戦略モデルとして使用することも、次のコードを使用することもできます。スケーラビリティを実現するための設定ファイル、ルール エンジン ツールなど。
3. 事例分析
上記の単純なモデルを通じて、建築家 Xiaosun が顧客の製品マネージャーとやり取りした需要シナリオを復元します。
プロダクト マネージャー Xiao Li: 「今回はビジネスと注文の処理を行います。これが私の PRD です。今日は見てみましょう...」
アーキテクト Xiao Sun: 「PRD は非常に詳細です。PRD を通じて、私たちは注文処理の機能を理解しています。私の言うことが正しいかどうかわかります。注文処理機能は注文データを読み取る必要があります。通常、これらのタスクは人間の介入なしにシステムによって自動的に処理されます。
プロダクト マネージャー Xiao Li: 「はい、大きなロジックは次のとおりです」
アーキテクト Xiao Sun: 「ここでの分割とマーキングの順序は、顧客、チャネル、カテゴリ、またはチャネルごとに異なります。この妥協は、短期的なオンライン圧力による単純化に過ぎないのでしょうか?」
製品マネージャー Xiao Li: これらの手順を通じて、4 つの顧客、3 つの注文チャネル、競合製品を調査しました。現在、新しいノードを検討する可能性はありません。
アーキテクト Xiao Sun: 「わかりました。それではコストを検討します。最初にプロセス ノードを固定として設計します。その後、ここで変化するシナリオが見つかったら、すぐに通知してください。また、あなたが言及したのは、注文は分割プロセスの順序に従っています。在庫ステータスの分割ですが、すべての注文は在庫ステータスに従って分割されますか?」
プロダクトマネージャー Xiao Li: 「ええと、そう思います」
アーキテクト Xiao Sun: 「さまざまな顧客、チャネル、カテゴリ、および他の端末やチャネルの下にさまざまなロジックがあるかどうかを調査することをお勧めします。」 通常、形容詞を含むアクションは変更される可能性があります。
- しばらくして
製品マネージャー Xiao Li: 「はい、顧客 A は、在庫に加えて、送料、ギフトカード、製品の数量分割ロジックもあると言いました。これらは順番に実行されます。」
建築家 Xiao Sun: 「わかりました。拡張性を考慮してこの作品を設計しました。」
4. 概要説明
アーキテクトがビジネスの予測可能性やビジネスの感度を高めるのは実際には非常に簡単です。適切なポジションを見つけて、より多くの質問をするだけで、最前線の研究開発の作業負荷が大幅に軽減されます。この能力は多くの場所でビジネス感性と呼ばれることもあります。したがって、システムのスケーラビリティ設計はビジネス入力と不可分である必要がありますが、いくつかの簡単な質問を通じてビジネスが変化する場所を素早く見つける方法は、今回共有したMITモデルによって解決されます。ビジネスシナリオに応じて、このMIT知識モデルに従ってビジネスの変化点を分析することもできます。
出典: JD Cloud 開発者コミュニティ
著者：JD Retail 李春麗（無断転載はご遠慮ください）