Review Weixin/WeChat Business Architecture as a Case Study

Business Architecture (BA) sounds a lot of ambiguity to most people, as there was no universally-accepted definition for it. TOGAF considers it as one of the four pillars in “… includes information on business strategy, governance, organization and how to adapt any existing processes within the organization”. Other schools refer it as “logical view” or “scenarios /use case view” as in "4+1 architecture view model".

Despite of the differences, BA shall present the view that is the closest to business activities or what an end consumer may sense as a user.

(WHAT) — Here I followed the definition by Li Yunhua, where a business architecture describes the functionalities of what a system exposes to users.

(WHY) — We need it for product team for strategic product planning, reporting to higher executives, and onboarding for quick high level views.

(WHERE) — The boundary for BA is at the business functions level, emphasizing the core business units, and it won’t go to details beyond what users may know about.

Use Wechat as an example, I searched through the corporate’s overview for investors, and came across this core business units under the largest communication and social service in China for over 1.25 billion MAU.

【image BU】

The business functions scatters around communication, socialising, sharing, video streaming, mobile payment, games and services to enterprises, and interactions between consumers and enterprises.

The business architecture can be draw as below:

【image 架构】

This is based on people, content, services and enterprises. Note people and content share same colour coding, because they were originally targeted at B2C model.

Architecture Design on Student Management System Use Case

TLDR; It is my personal mind exercise for software architecture.

Step 0: Business Requirements Clarification (Non-Functional)

Operation ready, in terms of

• Allow public access through internet

• Support up to 1000 students

Optional for this case study: functional requirements include information management for profile, courses, grades, awards, etc; exams management, and basic authorization and authentication.

Resource: 3 enthusiastic volunteers

all good at Java, and 1 proficient with Php

zero funding from university

Step 1: Access Sources of Complexities

Considerations:

1. High performance — not really. Only 1000 students, a single monolithic instance will do.

2. High availability — service downtime is not a big deal, as students may try in another time; data loss can be tolerated to certain extend, so backup is still needed.

3. High extensibility — probably yes, as the requirements go wild once the system is online.

4. Security — basic is fine.

5. Cost — Low budget but a few dollars are still manageable for trials and demos to university.

6. Time — 3 months, as they are volunteers.

In a conclusion, the complexities lie in extensibility, cost and time.

Step 2: Identify Architecture Candidates

[image]

Common design includes a client/service structure, with

1. service running on Cloud — Quick and easy of public IP subscription, low infrastructure investment. (Time, Cost)

2. web pages to support PC and mobile users. (Extensibility)

3. DNS for domain resolution by binding exposed public IP of VM from Cloud provider. (Time, Cost)

4. 1x MySql Cloud instance, which runs daily scheduled backup managed by Cloud provider. (Time, Cost)

5. Core business logics runs in Cloud VM, with one monolithic structure covering 4 functional requirements. （Time, Cost）

6. J2EE is chosen as core language. (Skillset)

Option 1:

3 volunteers implement in Java, with assignment splitted according to J2EE layered architectures (presentation, business, persistence, database).

Option 2:

• 1 x volunteer implement in Php, with assignment of web sites (presentation layer), since Php is good for dynamic web sites with readily available plugins and templates.

• 2 x volunteers implement in Java, with assignments of business, persistence and database, with one REST API for internal communication with presentation layer.

Step 3: Select Optimal Design

A Time and Cost Trade-off

Time:

Option 1 Duration = Duration_Persistent_Java + Duration_[Business + Persistence + Database]

Option 2 Duration = Duration_Persistent_Php + REST_Overhead + Duration_[Business + Persistence + Database]

Assumption: Php guy is much more effective in terms of programming in Php than Java. Then Duration_Persistent_Java > Duration_Persistent_Php + REST_Overhead. Therefore Option 1 Duration > Option 2 Duration.

Cost:

Option 2 Cost — Option 1 Cost = 1 Php VM.

Assuming time is not that critical comparing with cost, Option 1 is the best choice, because volunteers are likely to give more time buffer, but money is from their pocket!

Step 4: Implement in Iterations …

Check with university and get them paid if it goes well.