https://mp.weixin.qq.com/s/ADTO5sAli0WvMViqgVOnaA
以下の二つのグラフは、誰もが印象を持ってできるように：蘇寧のビジネスは非常に複雑です。2012年に、最初の接触蘇寧は、私はまだIBMのために働いている場合は、単に蘇寧電器がそれを販売しているにしたくないですか？おそらく今日に至るまで、多くの人々はまだ、この誤解を持っています。もちろん、実際の状況ではない、これは非常に大きな誤解です。このような江蘇省のサッカー今日のインテル・ミラノなどの蘇寧のスポーツセクション、など。蘇寧は、家電製品を販売するだけでなく、他の商品を販売するだけでなく、小売業全体のカテゴリです。唯一の企業は蘇寧電器、蘇寧はそう、ホテル、不動産などを含め、自宅に記載されていない記載されています。だから、多くの企業がITを本社にサポートする必要があります。
そして、それぞれの端を見てみましょう。今日では、デジタル化、ロケーションベースのサービスの話を、各端部がサポートされる必要があります。だから、多くのバックエンド事業は、我々はITサポートに行く、結合する必要があります。これはコンテキストです。技術を行い、建築家はイエスシーンに対処を検討するために何を、コンテキストを持っています。そう多くのフォーマットにのみ適切にうまく複雑なビジネスを扱う、前にあります。しかし、今日はデジタルに来るようになった、モバイル端末、PC、自宅のインターネットの多種多様あり、トラフィックが制御不能です。非常に複雑なビジネスロジックと質量の取引に対処するために、そして、どのようにこれらの操作やトランザクションをサポートします。
二つの質問に答えるために、技術的な人々を行います。あなたがビジネスに貢献しない限り、最初は、直接的な技術価値を持っていない、価値の問題で、同社のビジネスの急速な発展を支援するためにどのように、それはビジネスや技術です。第二に、それ以外の不安定性の結果は、落ちた、あまりにも速く実行されません。私たちは非常に心配している：システムがダウンしていませんか？サービスは利用できませんではないでしょうか？だから、安定かつ高速の両方を行う方法を、バランスをとります。ITの蘇寧は、戦略的なスローガンがある「安定性、セキュリティ、究極の高速を。」任意のアプリケーション、サービスが安定し、安全なだけでなく、高速の両方でなければなりません。これは、私たちは常にこの理想のために努力する、理想的です。
私の視点に立ち、それを考えることができるバランスをとる方法です。私たちはあなたのアーキテクチャにより、安定性、セキュリティ、究極の高速ある程度のをサポートすることができるように、その場合には、建築家は、コンテキストを持って、行うどんなデザインが理想的ではない、文脈と限界がある覚えています。技術的な言語の観点から、それは、機能と非機能的です。生産性へのIT技術の核心は、システムのためのこれらの非機能要件は、機能要件になると。などの監視、可用性、信頼性、それは機能要件です。あなただけの細線上のサービス限り、それを言うことはできません。あなたはそれを監視することができますか？生産はそれを見ることができますか？利用可能な性能保証？ビジネスの障害の影響を検討する時間がありませんか？どのようにその信頼性はどうですか？他の人へのサービス、極端な状況での契約条項は変更できますか？これは、蘇寧は、すべてのITチームは考慮されて処理されようとしている問題です。
エンタープライズアーキテクチャの進化
あなたと蘇寧を行う方法である。この課題を共有するために、ビューのビジネスおよび技術的な観点から、次の。I共有するよりはやっての過程で特に困難であり、問題は今日でもあるが克服するために苦労しています。
私は彼が国有企業、民間企業、独占企業、準独占企業は、完全な市場競争志向の企業を含む様々な企業のためのコンサルティング行っている、IBMで仕事をしていました。すべてのビジネスは、技術の別のビューで、技術の役割は同じではありません。私たちはそれを行う方法を、具体的蘇寧を見てみましょう。
過去数年間における遷移過程での蘇寧は、技術がどのような役割を果たしてきましたか？技術とビジネスの理解のために、私は技術のすべてが、ビジネス・サービスのためのものであるということです。シリコンバレーの蘇寧研究所、この過去の月がある、私は、十日とそれらの深い交流については、Facebook、LinkedInに他の企業を訪問し、シリコンバレーに行ってきました。この地域での問題を議論しました。私たちは、上から下へのビジネスモデルは、ビジネス、製品および技術である簡素化します。ビジネス支援のために行われたすべての作品の根底に。私たちがプレーする技術の役割によると、ビジネスのどのようなこの種のを見ています。
開発者があなたのビジネスに何かをすることを決定した場合どのようなそれはそれを意味するのでしょうか？技術の使用は、市場の変化に、より効率的でより速く、より良いフィードバックを意味します。市場ではこのような企業は非常に競争力があります。エンジニアがビジネスを決定することができ、エンジニアのいわゆる文化。この文化に沿って、特にグーグル、フェイスブック、など。第二の製品は、それを行う方法を決定するためにビジネスの意思決定ではなく、ビジネスの人々です。LinkedInのと同じように、多くの中国のインターネット企業は、この位置に主にあります。第三は、ビジネス上の意思決定です。開発を行うために開発者が、次のビジネス要求、。
苏宁是在逐步演变的。公司业务到底是由业务人员决定，还是产品经理决定，还是开发工程师决定？大家肯定觉得由最底层决定最好。事实上不是的。如果开发工程师根本就不思考业务，你让他决定公司的业务，那将是一场灾难。这是一个辩证的关系。我作为技术的管理者，经常会思考如何去拿捏这个度。你是希望眼睛往下面看，这是目标，并不代表公司会立刻变成这样。
我们从技术、方法论的角度来看，苏宁在思考什么。现在技术界有一句话，“架构不是设计出来的，架构是演变出来的”，我觉得太极端了。古人讲中庸之道是最好的。架构是否设计和演变，跟架构师很有关系。设计任何的架构，都会有上下文，有限制，这代表着中庸的态度，一定要适合当时场景，平衡权益。而苏宁在这个过程中，引入了企业架构，开始做规划。
这是苏宁转型过程中比较困难的一个环节。什么叫企业架构，可能很多人听到过，实际可能跟工作没有太多的关系。但是企业架构的思维方式是跟你有关的。比如，一个城市可以野蛮式生长，不用规划。中国很多城市建设就是挖了填，再挖再填，跟我们的系统建设很像。另外一种情况是，一个城市使劲做规划，根本不落地。
我毕业之后一直在北京，北京建设规划了一个又一个环，现在到七环。环状设计的确给今天北京交通带来很大的问题，但并不代表不应该做规划。很多人也知道，环的设计也给北京交通带来很大益处。那么，我的观点是，架构是边规划边演进的，然后还有做治理。这个时候就应该要考虑如何分配，谁去做规划，谁去做演进，谁去做治理。
某些企业里的治理者可能有官僚主义，这是我规划的，你就得照着我的规划做。这个时候大家会说，这种方法太差劲了，不用规划，直接做。结果各自演进，变成一种混沌状态。真正良好的过程是，要去做规划，并且要去演进。负责人，尤其是做规划、做治理的人，要有倾听机制，有服务的心态，要思考如何服务各研发团队。如果开发人员能够去思考他做的技术功能是如何支撑企业战略，如果公司每个人都思考这个问题，那么这个公司绝对很了不起。具有工程师文化的公司，对人员、工程师要求很高，从战略，到业务、应用、技术，最后到实施都管控起来，这是企业架构方法论需要处理的一个问题。
规划是做正确的事，治理是把事做正确。企业架构很关键的一点是，有一个很好的反馈机制。企业架构是回答企业的问题，产品经理应该思考这个问题，开发人员更应该思考这个问题。如果企业里每个人都在思考这个问题，并关联上自己做的事情，那这个企业会非常有活力。
苏宁企业架构怎么做的，看一下理想情况下的过程。目前的业务、技术在什么水平，我想把它演进成哪个程度、哪个水平，分析差距，找到要做的项目，然后去实施、评估，不断重复这个过程。到今天，苏宁都没有完全做到这一点，但是要不断去做，让大家做的事情匹配公司的战略。
我们看一下具体做的过程。
2011年的时候，我们意识到业务和信息战略对齐的重要性，但是大多数时候还是靠各自业务线去驱动。从2012年开始，成立了一个专门做企业架构的团队，这个团队更多做的是应用架构层面的事情。那个时候团队管控的范围还比较表面，公司内部对其重要性的认识也不是很深。那么，这个组织架构，除了有自己的规划之外，还发挥什么作用呢？当各个研发中心出现工作冲突的时候，这个决策性的组织就出现了。在苏宁常说的一句话：“找架构师来切一下，这个应该在哪里做。”出现问题，首先应该是在组织里找原因，而不是找一个人的原因。
后来，苏宁开始设计整个应用架构，包括数据资产的规划和设计。我举一个简单的例子。一组数据有很多的系统，如果大家对它理解不一致，就会带来很多问题，而这个问题是公司层面要去做治理的。直到今天，整个企业架构的治理流程和制度是比较完善的，先做规划，然后发布，最后反馈，如果在此过程当中有意见，可以不断修订。苏宁所有研发中心包括四千多人，而这个应用架构的组织不到十人，数据架构只有三四个人，但是这个组织会管控很多核心的内容和设计，同时与各个研发中心之间有匹配和对应。
从治理的结果来看苏宁的主体架构。可能很多人不了解，苏宁今天已经不是一个SAP。苏宁大概有1400多个系统，其中两个系统和历史遗留有关。一个是WCS，在2011年左右，WCS是其前台的网站，是一个套装软件。一个是SAP，和供应链管理有关。但是，到今天已经完全不一样了。
第一代架构:POS+ERP支撑线下规模扩张
上图是第一代架构、苏宁的门店，后台是ERP，前台是POS。这个架构在当年的价值就在于，很大程度上利用它，苏宁业务超过了国美。使用这套体系能够快速开店。当时国美在收购店面的时候，苏宁是快速开店，其中一个很重要的原因是信息化的支撑。从那个时候开始，苏宁对IT的作用有了认识，吃到了甜头，几分钟快速配置系统，就能做好开店的准备工作。
第二代架构:WCS+POS双线作战，抢滩线上
后来电子商务兴起，苏宁引进了IBM WCS电子商务套件，（上图第二代架构）这个系统支撑了苏宁好几年的发展。它非常灵活，但有一个最大的问题是，当业务量增大、业务复杂的时候，它的速度很慢，而且扩展性差。在2012年的时候，当时数据库用的是顶配的780小型机，不能支撑整体业务。2012年10月，我把这个套装软件做了拆分，可以横向扩展。可以认为是应用的一个拆分，但是应用和数据库被绑定，它的内部逻辑无法更改。把它扩展成物理部署，当时变成十倍，给苏宁留了很长的时间能够做后面系统的整个拆分和迁移，过渡阶段不让它受影响。这时候，我觉得系统的不稳定和扩展性，对苏宁的业务是有影响的。在快速支撑和发展业务的时候，如何快速横向扩展，这是很重要的一个考量点。
第三代架构:前中后架构重塑，O2O融合
从2012年开始，苏宁一直在做的事情有两方面的原因。第一考虑的是扩展性、性能的问题。把前台网站的逻辑和后台ERP的逻辑拆到中台。苏宁有一个很简单的架构，就是前台、中台、后台，前台关注消费者，后台关注内部运营管理，中台的系统是重用的逻辑。涉及到的各端，包括PC、移动端、门店、家庭的互联网，所有逻辑调用的都是在中台系统。
第二考虑的是，如果对于今天很多新的互联网企业业务来说，可能会容易一些。但苏宁不一样，很多旧有的业务逻辑，而且体量很大、交易量很大，既要维持业务的增长，还要能调整架构调整，支持未来的增长，这本身是一个很困难的演变过程。技术永远是为业务服务的，或者说技术能够直接变成业务，这是技术团队最值得自豪的一点。
场景举例，多渠道库存共享：
第四代架构:开放零售生态圈(未来)
到今天，苏宁有1400多个系统，服务有好几万。从2011年左右就有一个ESB，做集成，同时在那个时候，苏宁对所有的服务进行了管理。后来把它变成一个分布式的服务调用框架——RSF。一方面是服务的治理，一方面是服务的交付。
今天我关注的是，每天都会产生海量的数据，怎么样让数据发挥价值，如何让这些数据决定公司的运营。苏宁的信息技术要上一个台阶，那么苏宁的业务运营有可能是信息决定的。比如，承诺送货准时到达这个业务，如果利用技术、数据对它进行全流程、每一环节的监控，就可以做到每一单的管理。这个时候你会发现，有很多业务可能因为考虑其他的利益，去牺牲了用户的一些体验。如何让这一点变得透明化，让数据去做决定就很关键。
今天中国的电商还处在刚刚起步阶段，大部分的情况是，不知道用户的感受，如何更懂用户、更感知用户，都要靠后台海量的数据。我认为，这部分是在业务应用的层级，跟技术关系不大，更多是一种思维模式，要站在用户的角度思考。
技术路线
下面分享一下苏宁在演变过程中的技术路线。
电商转型初级阶段
苏宁进入电商之后，线下门店1600-1700家，有18万的用户，用的是SAP管理软件。很多企业，在今天还处在这种水平。在电商转型初级阶段，如何很快实现互联网的转型，开始引入了IBM这个伙伴，最终是要实现自我掌控。一个传统企业做转型，我觉得一定要有决心。
IBM在苏宁的顾问最多的时候有四百个，这为苏宁赢得了时间。在那个时候引入IBM WCS，以EAI方式快速接入，集成苏宁已有的信息化体系，然后基于物理机的平台，开始运转。
电商转型自建SOA体系阶段
随着业务的快速发展，当时已经很先进的软件、平台、技术，配上最强的机器，都撑不住了，怎么办？开始拆分。在这个时候，很多是关于扩展性、吞吐量问题的处理。另外一个问题就是物理机的运维部署难以支持。后来就是把它拆分，建设了RSF、ESB框架、监控系统，引入和评估开源软件。到今天为止，苏宁新建的系统都是基于开源软件，而且都是自己掌控的。
另外，历史遗留的很有用的套装软件，也要计划迁移的。当你把系统拆分成很多服务，如果你对它不了解，那将是一个灾难。另外就是对服务的管理。ESB直到今天还在使用，因为ESB有异构的系统，比如要做中间层转换，这是ESB的作用。还有一个和这个有关的就是测试服务，服务发布时需要持续测试和集成。
电商转型高速成长阶段
在高速成长的时候，苏宁就是在不停做拆分：
第一，要管控、规划，特别有一个团队在负责这些事情。监控体系部分，包括像基础设施的监控、Web的监控、连接的监控、服务端的监控、调用链的监控都要和管控和规划相匹配。第二，对可靠性提出了很高的要求，还对基础架构、基础组件的可用性、扩展性提出了很高的要求。
后来引入了OpenStack，苏宁现在所有的资源管理都在OpenStack上。苏宁经历过VMware、CloudStack、OpenStack阶段，管理一万多个物理机，像持续交付、持续发布目前都运行在OpenStack上。
这是电商转型高速成长阶段的技术架构现状：
电商转型新阶段：未来
我们也在关注Docker。关于是否引用新技术，苏宁都是提前去研究，新技术是否能够更好支持业务。如果现在的技术支持得很好，我们不会轻易更换它。衡量点都在于对业务的支持和匹配。这里面最关键的是服务部分，大量系统的拆分，其实是一个治理的过程。系统再细，最后就是一个服务。关于系统的管控、服务的管控方面，RSF有一个服务管理的平台，定期出报告，负责人会收到报告，对服务进行管理和治理。
技术管理与组织治理
管理组织有两个部门：一个是技术管理，包括CTO办公室和PMO办公室，关注标准和架构的规划，管理架构、安全、应用开发等；另一个是项目管理，包括几个人做一个项目，项目之间的承诺、契约是什么，有没有按时推进，按时交付等。管控还要有系统和工具支撑。
这里隐含了一个规则：没有数据支撑的不做管控。当系统出数据的时候，开始管控。
这里也在平衡规划管理和服务的关系，怎么把管理组织做成一个服务型组织，支持业务的发展。系统和工具是技术平台的部分。另外，所有和业务、应用没有关系的部分是技术平台，它需要支持各研发中心的发展，是不是能让别人做的更快、更稳定、更安全，是不是让别人不要去关注底层的技术细节。上面的两个组织是很小的，但发挥的作用非常大。其余大部分的组织是属于业务应用研发。
管理很重要的一点是，要看公司人的情况，技术的成熟度、能力成熟度。管理需要拿捏是业务人员驱动，还是产品人员驱动，还是开发工程师驱动。如果一个团队能力很强，为什么不能让产品驱动，不能让开发人员驱动，去决定业务怎么做呢？
我的心得分享
第一， 规划和敏捷要并重 。敏捷和规划不是冲突的，应该要完美契合在一起。尤其做技术管理的，一定要时刻拿捏度，管控规划要做多大，敏捷多少要放开。
第二， 人的观念转变最重要 。业务产品技术的划分，最关键的还是要找到正确的人，一个好用的人抵过不好用的人10倍。
第三， 要激发团队的主观能动性 。规划往往会抑制团队的主动能动性，但敏捷容易制造混乱。很多人离职不是因为薪资，可能是因为成长的空间不够大，做的工作看不到价值。怎么让一个人可以拥有十年的工作经验，而不是只有一年的工作经验使用了十年，这是管理者或者技术管理者不停要思考的问题，管理者需要和团队一起成长。
最后， 业务发展最重要 ，信息必须把要很好支持业务。