架构即分工
本帖最后由 rosemanor 于 2020-3-7 20:42 编辑在工程领域，最让人迷惑莫过于两个词“架构”和“服务”。这几年火了的“中台”和“微服务”更是让这两个词变得更加让人迷惑。
先从“架构”这个词开始。
我猜这个词大概来源于建筑业。从茅草屋到摩天大楼的最大变化大概就是单靠一个人完成不了。我对建筑行业不懂。脑补下，应该先从整体土木结构开始，然后到每一层的功能分区，再到具体点的装修材料和水电设计等等。摩天大楼的建设光靠一个外观图肯定是不行的。如果没有一个统一的架构规范，这么多工种配合的话，极有可能建好了楼体结构，可能水电都没法接入。
跳过对建筑的猜测，来到互联网行业来看看“架构”。先说“产品架构”。《用户体验要素》是我特别喜欢的一本书。这本书从下往下把一个产品架构定义成了五层。从上往下分别是战略层、范围层、结构层、框架层和表现层。
单看这五层，我们就能看到有不同的岗位分工：战略层由高管或PMM产品市场经理负责、范围层由产品负责人负责、结构层由产品经理负责、框架层由交互设计师负责、表现层由UI设计师负责。在一些小团队里面，产品经理身兼多职，一人包揽全部。
题外话。我通常用一个问题就可以鉴别出产品经理：“请设计一个登陆注册的功能”。一般的是画一个原型，好一点的会先去设计下需求，再好一点的会先讨论市场，比如这个产品需要不需要社交引流。
我们再换个视角来看看技术一点的“网络架构”。
OSI 7层协议比较理想，现实中并未严格按照这7层走。但我们也可以看到不同层的分工。比如物理层由一些光纤和无线通信厂商来负责、比如网络层由IANA或者运营商来负责，再比如应用层由App研发公司来负责。
再换个视角来看看企业信息化里面的“架构”。企业信息化中常用的“架构”有一个更正式点的名字叫“企业架构”。比如Zachman、TOGAF。
TOGAF从上往下可以分成业务架构、数据架构和应用架构、技术架构。这也代表了一种分工。通常业务架构由产品经理或者BA(业务分析师)负责、应用架构和数据架构通常由SA解决方案架构师负责、技术架构通常由IA基础设施架构师负责。
BA或产品经理对业务进行分析后得到业务对象和业务事件，并将其作为输入给到SA。SA将写好的代码交给IA。
企业信息化的业务架构是来描述企业内部的流程，2C的产品不适合。这时可以把企业内部流程换成CJM客户旅程地图。
如果你在设计架构，我建议按照以下的步骤来：
[*]流程(通信流程、产品流程、研发流程、信息化流程、客户旅程等等)是什么？
[*]流程上有哪些岗位或角色？
[*]这些岗位和角色的输入输出是什么？能不能结构化？
[*]这些输入输出有没有数量和质量上的要求？
当完成了以上的分析之后，架构就能很清晰了。
谈完架构后，我们谈谈“服务”。工程团队一提到服务这词，大概有这么几个语境：1，接口；2，业务逻辑；3，RPC应用。
在SOA的架构定义中，Service只代表一种业务服务。它和“服务行业”的“服务”这个词类似。相对的一个词叫“产品”。换句话说，“服务”做好了之后是内部员工用的系统。它的复杂度可比“接口”或者“业务逻辑”或者“RPC应用”大多了。
下图是SOA中Service的官方定义。
SOA一般是在企业发展到一定程度后的组织集中化。例如财务共享中心，人力资源共享中心等等。组织集中化的历史大致可以追溯到杜邦公司发明的“复式记账法”。它用一种记账标准实现了旗下企业和投资公司的财务标准化集中管理。
“服务‘也是一种分工。不过它是在组织发展到极其庞大的时候才有必要。
如果你的研发规模不够大，至少千人以上。你是不需要技术中台的。如果你的业务规模只有单一业务，没有多元化业务，你也是不需要业务中台的。
要理解“服务”这个词要从业务流程的组织分工开始。“微服务”也一样。有一定研发人员规模后，要从研发流程上开始分工。一部分人开始提供“微服务”，一部分人专注在“业务流程”开发上。
总结下，架构和服务都是一种组织分工。架构设计就是一种“资源”的安排。作者：Mac 来源：斜杠的沉思
页:
[1]