シェアードサービスセンター構築の原則-「エンタープライズITアーキテクチャー変革の道-アリババ中台戦略思想とアーキテクチャー実践」

I.はじめに

今日、私は「エンタープライズ IT アーキテクチャー変革の方法 - アリババ中台の戦略的思考とアーキテクチャーの実践」 - 共有サービスシステムの構築の第 4 章を再読しました。この本で説明されている共有サービスセンターには、実際には 2 つのレベルがあります。

1 つ目は、基礎となる PaaS 機能です。分散、可用性、高可用性、およびリアルタイム監視の観点から、企業内のシステムグループ全体のアーキテクチャの要件を解決するために使用されます。
第二に、一般的なビジネス機能です。私の理解では、実際に SaaS を構築しています。その目的は、企業のコア機能をシンクして共有し、企業のイノベーションの速度を加速することです。

ここで、2 番目についてもお話ししたいと思います。それは、一般的なビジネス能力の構築についての理解です。

2. シェアードサービスセンターの建設経緯

タオバオには当初、ユーザーセンター、商品センター、取引センター、ストアセンターの 4 つの共有サービスセンターしかありませんでしたが、各センターの選択と配置は、私たちにインスピレーションを与えてくれます。

ユーザーセンター : ユーザーセンターを選ぶ理由主な考慮事項は、1) ビジネスの複雑さが商品/トレーディングセンターよりも低く、変革のリスクが比較的低いこと、2) ユーザー関連の情報が最も頻繁に呼び出されること、およびサービス後のコスト削減が少ないことです。テストが容易になる (ビジネスロジックが関与しないため、新しいビジネス機能が関与しないため)。

商品センター : 淘宝網はプラットフォームベースの e コマース企業であり、商品管理は淘宝網のコア機能の 1 つであるため、最も共有する必要があります。

取引センター : 当初、取引センターには、ショッピングカート、取引プロセス、注文管理、決済、マーケティングなどの機能が含まれていましたが、ビジネスの継続的な発展に伴い、在庫とマーケティングは在庫センターとマーケティングセンターに分離されました。このようなプロセスは、サービスセンターのダイナミックな進化を反映しています。

ストアセンター : ストアは当初、売り手のストア管理およびその他のビジネス機能を担当していましたが、その後、ストアシステムの改善とビジネス範囲の拡大により、タオバオで最もダイナミックなサードパーティのストア装飾市場に発展しました。これは、プラットフォームのベストプラクティスです。

上記から、いくつかのことを漠然と要約できます。

1. これらのセンターは活力に満ちた個人であり、エンタープライズビジネスの発展に伴い、独自の機能モジュールが成長し、独立して新しいサービスセンターになり、センター自体が新しい機能を導出する可能性があります。

2. 中間段階でビジネスを行う前に、企業はまずコア機能が何であるかを整理する必要があります。

3. 中台化を構築する過程で、複雑さが比較的低く効果が明らかなコア機能を使用して、機能を分離し、それらを共有サービスセンターに統合するよう試みます。

4. センターがチャネルに提供する機能は、形式に限定されるべきではなく、API や WEB インターフェイスの形で提供できると理解しています.もちろん、データ機能やいくつかの一般的なツールを提供することもできます.ゆっくりと、これらのセンターをプラットフォームに提供できるようになります。

3. サービスセンター分割の原則

シェアードサービスセンターの分割は、技術的な側面だけでなく、ビジネスオペレーションの側面も考慮する必要があります。これを行う最初の意図が何であるかを忘れないでください。すべては、ビジネスに迅速に対応し、ビジネスの革新を促進するためです。私は下手な言葉で理解できる本の 4 つの原則を説明しようとしています。

1. 高凝集・低結合の原理

これは単なるサービス部門ではなく、私たちの通常のシステム設計が守らなければならない基本原則と言えます。サービスセンターの文脈では、サービス間のビジネスの分離が比較的大きいことを意味します.注文を行うときは、注文機能（単純な追加、削除、チェックなど）のみを含めるようにして、含めないでください.ユーザー情報機能; ただし、ある程度のビジネス関連性を持つ一部の機能では、特定の問題の特定の分析が必要です。その具体例を挙げてみると、筆者が担当しているチームの中に、ECモールの構築を担当しているチームがあり、請求、顧客の権利など、すべて順調でした。しかし、事業計画は、顧客の権利と利益にもさらに取り組みたいと考えており、元のECモールでいくつかの権利と利益に関連する要件を作成し続けた後、多くの問題があることがわかりました（リソースの調整、システムの境界、など）、そして最終的に権利と利益のシステムを変更することを決定しましたマイクロサービスフレームワークを使用して独自の開発を行います。

プロセス全体の観点から、最初にエクイティシステムまたはエクイティセンターを設計しない理由を言う人もいるかもしれません。しかし、私は今でも同じことを言います。顧客のニーズが急速に変化し、次の 3 か月で何をすべきかを製品が明確に説明できないこの VUCA 時代では、1) 独自にエクイティシステムを構築する必要があるかどうか、2) を測定できません。 ) ) この段階で移行設計はありますか? 結局、ROI の考慮があります. 2 か月後にビジネスの方向性が調整されると、開発リソースの無駄になりませんか? しかし、事前にできることはありませんか？もちろん違います。過去の経験に基づいて、エンジニアリングレベルで少なくとも次のことを行うことができます。

1. 第 1 フェーズの機能要件の範囲について、基本的に一部の既存の業務データテーブルを使用する必要がなく、従来の追加、削除、確認、変更に加えて、経験に基づいて機能範囲を評価する場合、いくつかのアグリゲーションレイヤー機能があります。一般的には、新しいスタンドアロンサービスを作成することを検討してください (jar 形式で)。

2. それ以外の場合は、既存のビジネス機能間の相関度が最も高いマイクロサービスで開発しますが、後の段階で独立して開発する必要がある場合に、迅速かつ直接的にまとめて抽出できるように、パッケージの次元で独立するようにしてください。ツールクラスを使用してマイクロサービスになります。

3. データベースレベルでは、新しいビジネス機能をサポートするために同じライブラリ内の別のテーブルを使用することが一般的に好まれますが、別のライブラリまたは別のスキーマを使用しないのはなぜですか? 複数のデータソースの管理を主に考慮すると、プロジェクトのデータベース管理モジュールはより複雑になります。はもっと複雑です。できるだけシンプルにアインシュタインは「シンプルであることは科学が追求する偉大な目標である」と言いませんでしたか?

上記の例の全体のプロセスから、詳しく見てみると、実際には「高凝集低結合」という基本原則に従っています。

まず、初期エクイティシステムの機能が非常に単純な場合は、比較的モールシステムに近いため、高い結束性を満たしますが、コードエンジニアリングレベルでは、パッケージの次元で独立して一定の機能を確保するようにしてください。スケーラビリティの程度が高いため、次の高い結束にも対応します。

そして、権益制度の機能がますます大きくなるにつれ、もはやモールの本事業の下に置くことができなくなるのは明らかですが、事業計画が特に明確ではないため、機能を剥奪し、マイクロサービスの独立した開発になりますが、データ層はまだ最初に予約されています. モールシステムの下で;

したがって、システムのアーキテクチャー（サービス部門）の先進性を確保したい場合や、エントロピーが増大したときにシステムや組織が崩壊しないようにアーキテクチャーをどのようにガードできるかを考える場合、「進化能力」を追加することが鍵となります。 "システムに。「進化能力」の基本原則の一つに「高凝集・低結合」があります。

2.プログレッシブ・コンストラクションの原則

この原則は、実装レベルからのものです。VUCA時代の今もなお、お客様のニーズや運用のニーズは常に変化しています。全体的なトップレベルの設計が必要です。なぜなら、それはより指針となる性質であり、マクロレベルで明確な円を描くことは疑いの余地がないからです。ただし、特定のサービスセンターを構築する場合、さらに必要なのは戦略と迅速に調整する能力であるため、小さなステップで実行することをお勧めします (特に、再発明する必要のないシステムまたはプロジェクトの場合) , Don'一度にすべてを行う必要はありません。

また、先ほど申し上げたように、システムアーキテクチャは生きており、まず、ビジネスの発展とともに外生的に成長し、同期もテクノロジーの継続的なアップグレードによって内生的に成長します。サービス指向アーキテクチャは、設計原理のバランスだけでなく、技術、コスト、リソース、建設期間、パフォーマンスなどのトレードオフであり、バランスを追求する芸術であると私は常に信じてきました。その時の条件に最も適した解決策を考え出すために、より良い解決策を考え出します。そのような前提に基づいて, 私たちの計画は間違いなく完璧ではありません. 私たちにできることは無限に完璧に近づくことだけです. サブテキストは、各共有サービスセンターは実際にはバージョン1.0の構築後も継続的な反復最適化が必要であるということです.必要。（人間自身が完璧ではないので、私たちがデザインするものも不完全でなければなりませんが、これはここでは議論しない哲学的なカテゴリーです.笑）

3. データの完全性の原則

この基本原則は、上記の最初の原則を反映する必要があります。または、データモデル設計レベルでの「高凝集性と低結合」の具現化として理解することもできます。しかし、ここで強調したいのは、いわゆるデータの整合性は幅広いということです。ここでは、説明のためにドメインモデリングの集約と集約ルートを借りることができます。

アグリゲーションとは集約は、実際には、特定の集約ルート、エンティティ、および集約コンテキスト境界を持つ関連オブジェクトのグループの組み合わせです。その中で、境界は、集約に存在する必要があるエンティティまたはサブエンティティを定義します。

集約ルートとは DDD では、集約ルートは、集約の内部エンティティが他の外部集約と通信するための一意のブリッジとして機能します (集約間参照)。

エンティティとはエンティティはそれぞれの具体的なオブジェクトです。

下の図から、顧客集計全体では、顧客が唯一の集計ルート (データベーステーブルの主キーとして理解できます) であり、他の外部集計はそれを介して顧客集計内の他のすべてのエンティティにアクセスできます (のデータベースの異なるテーブルとして理解できますが、主キーは同じです)。集計全体がデータの整合性の原則を体現しています。

1. 特定の顧客のデータをクリーンアップしたい場合、アグリゲーションはどの顧客データをクリーンアップするかを教えてくれました。

2. 特定の顧客のポートレートを分析したい場合、特定のモデルが出てくる準備ができています。

データの整合性とは、統一されたデータモデルを使用することを意味します. この方法でのみ、統一されたデータモデルと対応するアルゴリズムを使用して、生成された全体的なデータに対して対応する統計分析を実行できるため、対応する結果を最も効率的に取得できます。後で対象を絞った操作戦略は、より価値のある参照を提供します。

4. 事業運営の原則

シェアードサービスセンターを構築する場合、ビジネスオペレーション、つまりビジネスロジックも考慮する必要があるというのが私の理解です。そのようなサービスセンターだけが、ビジネスは、1) このサービスセンターを使用する過程でビジネスデータを継続的に蓄積することができます, 2) 書籍に記載されているように、使用中にさまざまなビジネスニーズにより革新的なアイデアが自然に生まれます.センターでは、大量の商品 SKU と SPU があるため、商品検査技術が生まれました。このことからわかるように、センターは利用者が利用してこそ進化し、進化し続けると同時に、新たな運用上の難しさから新たな技術やサービスが生まれるという好循環が生まれています。

一般的に使用されるキーは常にオンになっているため、共有サービスの構築中もこの原則に最大限従う必要があります。