正文
苏宁在这几年转型过程中，技术发挥了什么样的作用？我对于技术和业务的理解是，所有的技术都是为业务服务的。苏宁在硅谷有一个研究院，刚刚过去的十月份，我去硅谷参观了Facebook、LinkedIn等企业，大概有十几天和他们深入交流，探讨了这方面的问题。我们把企业模型简化，从上到下是业务、产品、技术。下层所有的工作都是为业务做支撑。我们根据技术在里面发挥的作用来看这是一家什么样的企业。
如果一个开发人员做的东西就决定你的业务，这代表是什么？技术的使用意味着更高效、更快，更能反馈市场的变化。这种企业在市场上是极具竞争力的。所谓的工程师文化，即工程师能决定业务。像谷歌、Facebook，特别符合这种文化。第二种是产品决定业务，不是业务人员决定公司应该怎么做。像LinkedIn、中国很多的互联网公司大多都在这个位置。第三种就是业务决定。业务提要求，下面开发人员做开发。
苏宁是在逐步演变的。公司业务到底是由业务人员决定，还是产品经理决定，还是开发工程师决定？大家肯定觉得由最底层决定最好。事实上不是的。如果开发工程师根本就不思考业务，你让他决定公司的业务，那将是一场灾难。这是一个辩证的关系。我作为技术的管理者，经常会思考如何去拿捏这个度。你是希望眼睛往下面看，这是目标，并不代表公司会立刻变成这样。
我们从技术、方法论的角度来看，苏宁在思考什么。现在技术界有一句话，“架构不是设计出来的，架构是演变出来的”，我觉得太极端了。古人讲中庸之道是最好的。架构是否设计和演变，跟架构师很有关系。设计任何的架构，都会有上下文，有限制，这代表着中庸的态度，一定要适合当时场景，平衡权益。而苏宁在这个过程中，引入了企业架构，开始做规划。
这是苏宁转型过程中比较困难的一个环节。什么叫企业架构，可能很多人听到过，实际可能跟工作没有太多的关系。但是企业架构的思维方式是跟你有关的。比如，一个城市可以野蛮式生长，不用规划。中国很多城市建设就是挖了填，再挖再填，跟我们的系统建设很像。另外一种情况是，一个城市使劲做规划，根本不落地。
我毕业之后一直在北京，北京建设规划了一个又一个环，现在到七环。环状设计的确给今天北京交通带来很大的问题，但并不代表不应该做规划。很多人也知道，环的设计也给北京交通带来很大益处。那么，我的观点是，架构是边规划边演进的，然后还有做治理。这个时候就应该要考虑如何分配，谁去做规划，谁去做演进，谁去做治理。
某些企业里的治理者可能有官僚主义，这是我规划的，你就得照着我的规划做。这个时候大家会说，这种方法太差劲了，不用规划，直接做。结果各自演进，变成一种混沌状态。真正良好的过程是，要去做规划，并且要去演进。负责人，尤其是做规划、做治理的人，要有倾听机制，有服务的心态，要思考如何服务各研发团队。如果开发人员能够去思考他做的技术功能是如何支撑企业战略，如果公司每个人都思考这个问题，那么这个公司绝对很了不起。具有工程师文化的公司，对人员、工程师要求很高，从战略，到业务、应用、技术，最后到实施都管控起来，这是企业架构方法论需要处理的一个问题。
规划是做正确的事，治理是把事做正确。企业架构很关键的一点是，有一个很好的反馈机制。企业架构是回答企业的问题，产品经理应该思考这个问题，开发人员更应该思考这个问题。如果企业里每个人都在思考这个问题，并关联上自己做的事情，那这个企业会非常有活力。
苏宁企业架构怎么做的，看一下理想情况下的过程。目前的业务、技术在什么水平，我想把它演进成哪个程度、哪个水平，分析差距，找到要做的项目，然后去实施、评估，不断重复这个过程。到今天，苏宁都没有完全做到这一点，但是要不断去做，让大家做的事情匹配公司的战略。
我们看一下具体做的过程。
2011年的时候，我们意识到业务和信息战略对齐的重要性，但是大多数时候还是靠各自业务线去驱动。从2012年开始，成立了一个专门做企业架构的团队，这个团队更多做的是应用架构层面的事情。那个时候团队管控的范围还比较表面，公司内部对其重要性的认识也不是很深。那么，这个组织架构，除了有自己的规划之外，还发挥什么作用呢？当各个研发中心出现工作冲突的时候，这个决策性的组织就出现了。在苏宁常说的一句话：“找架构师来切一下，这个应该在哪里做。”出现问题，首先应该是在组织里找原因，而不是找一个人的原因。
