写在开头
某友：”听说你现在是企业架构师，听着就很高大上，现在是不是不做技术了，是不是工作偏务虚？“
我：”嗯，涉及的内容比较务虚，但....也不是吧“
每次回答类似的问题我都有点词穷，企业架构师在被冠以“务虚”的标签下，好像难以自证。
“虚”声一片
或许你见过这样的场景：在某项规划或方案设计的汇报会上，汇报人言辞华丽、滔滔不绝，然而当会议落幕，人们私下交流时，却常常达成一种奇怪的共识——似乎听了许多，实则空洞无物，不知所云。
这让我想起了B站上一位知名搞笑UP主“肖科长”的视频。视频中，“肖科长”手持茶缸，以深沉而严肃的口吻模仿开会发言，其中“抓关键问题，就是要抓住问题的关键”，是一个被大家熟知的金句，最近的一部电影《年会不能停》也引用了一番。从打工人角度看，这些画面实际是对日常职场文化中这种不实际、不作为、表面化交流方式的一种抗议。
此时此刻，你脑海中可能已经浮现若干这样的场景，在心里给他们贴上了类似“务虚”的标签。而在我们看来，在感官判断的背后，可能并非如此简单，有时甚至会造成无意的伤害。本文想提供一个新的视角，剥离评价群体与被评价群体的语境，更客观地谈谈到底什么是“务虚”？什么是“务实”？这其中是否存在误解呢？
从问题本身看虚与实
当我们提“务虚”和“务实”时，其实是在谈我们对于一个人解决问题过程中的主观感受。所以，不妨先回到产生分歧的原点——“问题”上。
宏观问题与微观问题
人在职场生活中，是通过不断遇到问题、解决问题、交换价值、获得回报而安身的，问题本身各不相同。当我们尝试，将这些问题汇集在一个巨大的“问题空间”里，并用一个外部视角来观察它，你会发现问题类型极其丰富和复杂，它涵盖了从国家治理方针到如何买到一杯美式咖啡的方方面面。
当我们对这个庞大的“问题空间”尝试做个分类，如何分呢？有两个维度，以专业领域差异（“横向”）而形成的问题分类，以及另一个以“纵向”问题分层，从宏观的抽象问题延伸至微观的具体问题，交叉后形成问题的二维矩阵。
当撇开那些洞悉天文地理、无所不能的全能者不谈，其实，大多数人一生中能够深入接触的横向的领域种类，以及纵向的层次都是相对有限的。因此，在二维矩阵的不同小块间，互相“看见”是非常难的，如果我们对于专业领域的差异能够理解为“隔行如隔山”，那么在问题的“纵向”层面，这种隔阂也是同样存在的，也可以说是 “隔层如隔山”。
再看企业架构框架
在我作为应用程序开发工程师的职业经历中，机缘巧合下接触了企业架构的方法，从而对整体性地看待企业在做什么，整体的价值是什么，有了更广阔的认知。
John Zachman提出的企业架构框架（“Zachman Framework”）是企业架构的源头，他的灵感起源于对建筑、飞机等复杂业务的观察，核心理念是同一个事物可以用不同的方式、基于不同的目的、从不同维度进行描述。企业这个复杂体，当然也可以这样去描述。
下面这张图是Zachman先生的一个建筑架构师朋友画的设计图，其中不同颜色和形式的线条代表了房子需要有的功能，下一步会指导施工人员进行施工。正如房屋架构图一样，企业建设也需要企业架构图。
在他提出的企业架构框架中，同样提供了一个结构化的方法来审视和定义企业，这种独特的方法帮助了组织能够更为有效地规划和执行业务及IT策略。
他提出以下5个层次的企业框架：规划者、业务属主、系统设计者、技术设计者、开发人员。这种多层次的视角揭示了务实与务虚的感知差异，让我们拿这个图再次对比第一张图，你会发现观点其实是完全相同的，越往上的规划者工作在抽象层次，越容易被觉得“虚”，而越往下的开发人员越工作在具体层中，同样印证了上文中对于问题空间的分层思想。
对“务虚”的判定是存在误解的
让我们做个思维训练，将脑海中“务虚”的概念做个分解，你会发现，其实大部分情况下所被评价为”务虚“的，往往是宏观的问题。因此，“务虚”的问题和“宏观”的问题，我们可以给它粗糙地画个等号，类似的“务实”的问题和“微观”的问题我们也可以同样等价起来。
我们认为，这样基于问题分层的映射是对务虚问题的更为客观的定义，但实际中这种客观定义是被有意或无意忽视的。我们发现“务虚的问题”更为轻易和直接地被认为是“务虚的态度”，给予不好的评价，是诱发误解产生的重要原因。
相比跨领域，跨层次间的误解会更容易产生。因为高低视角的层次间往往又存在着比跨专业领域更为紧密的上下游关系，当互相的产物或服务能力彼此不认可时，或者层与层之间没有相互影响甚至完全黑盒时，各自的价值便很难得到另一方的认同，就可能会诱发误解的产生。
我们所倡导的“务实”
我们反对的是“务虚的态度”
在每个层次中都存在着以“务实”态度工作的人，无论他们各自所处的问题层次，是高度抽象的层次，还是极为具象的层次。也就是说，即使做务虚的工作也可以是以务实的态度，这样的工作者不应该被误解。
我是一名企业架构师，每当我回忆起职业的第一年，心里仍有些苦涩，在承接战略落地做信息化规划的过程中，企业架构团队做了大量的业务调研和技术实现上的权衡，但很多战略性的落地关键讨论却很难让实施团队真的加入到讨论中，苦恼之际做实施的朋友跟我说，”其实大家背地里都觉得你们不落地，实施中有很多难题，这些在规划中没给答案“。
当时的我既委屈又不甘，但现在看来，一切都可以解释了：信息化规划团队与实施团队间缺少了一个对彼此定位以及服务支撑关系的“共识”过程，都在努力守住自己熟悉的边界，如果当时各自互相迈近一步，或许很多矛盾就能化解，都能“轻松”一些了。
那“务实的态度”是什么呢
“务实的态度”是一种面对问题解决问题的态度，目标只有一个，就是“解决问题”。所以，这种态度的核心在于价值驱动理念和实用主义精神，其核心目标不是讲清楚道理或是讲明白逻辑，而是始终关注如何切切实实解决实际的问题和挑战，并最终落于行动，产生实质的效果。
以这样的态度工作会尊重问题的复杂度和包容解决方案的局限性，会从问题出发，以终为始，不断纠偏与调整解决方案，甚至会承认解决方案的局限，否认过去，及时纠偏。
“务实的态度”并不局限问题的层次，宏观到企业战略设计，微观到一个系统功能的设计与实现，只要其对于企业存在价值，都需要以“务实的态度”进行分析和落地。
在解决“务实的问题”时，也就是在面对一个微观且非常具体的问题，例如一段代码的设计，如果不以实际情况与价值出发，空谈设计模式和种种行业最佳实践，毫无依据的陷入对于未来种种变化的夸夸其谈，在我看来也不能称之为在以“务实的态度”工作，是没有价值的。 反之，在解决“务虚的问题”时，即便是面对高层次的战略规划问题，如果我们能始终关注如何能找到实际可行的解决方案，细化到行动方阵，主动推动落地实施，从理论走向实践，用实践解决问题，达成具体的成果，那在我看来，也是在以“务实的态度”工作，是有价值的。
所以，当我们谈论“务实与务虚”时，一定要区分是在谈论“问题”还是“态度”。我们反对的是“务虚的态度”，而提倡的是以“务实的态度”解决问题，无论是在解决宏观的“务虚问题”，还是微观的“务实问题”，都是有价值的。
以务实的态度践行企业架构
作为一名企业架构咨询师，正如开头所说，我常常面临外界对我们工作的误解和批判，特别是关于“不落地”的指责。对于企业架构这个领域，我想通过一个最近的项目经历，为我们这个领域的务实工作者正名。
一次务实的企业架构践行
我们的客户是一家集团型的大型企业，业务、组织、IT上的现状非常复杂交错，干系方众多且诉求多样。我们作为外部的IT规划咨询团队，在意识到客户环境下实施变革的难度后，如果为了避免项目风险，从逻辑上是可以通过最佳实践为背书，通过一些表面上共识的方式，更为直接的方式直接产出一份看似合理的规划报告，快速完成项目任务。
但我们不是，我们团队怀有对务实态度的坚守，本着对客户负责和解决问题为出发点，我们选择了看起来相对更为繁杂的方式，于是在这个项目中，我们和客户的企业管理中心紧密协同，做了两件非常务实的事：
一是，即使是一个宏观的规划，也有清清楚楚的实际成果。
在客户的领导对于不破不立的坚持下，我们借助企业架构的理论深度融入到实际工作中，在过程中持续瞄准，将更多或许是高阶的问题，比如业务边界、组织边界、IT边界，以适合且真实数据支撑的方式暴露出来，而不是将问题隐藏住，被客户评价为“帮助我们看清了业务原本的样子，工作非常细致扎实”，即使是一个宏观的规划，也有清清楚楚的实际成果，有依据有逻辑有观点。对此，我们团队自己也有极大的成就感。
二是，让架构的产生、使用都流动起来！
企业架构是对企业的方方面面进行建模，企业越复杂，其天然存在的管理要素种类越多，要素之间的潜在关联关系越复杂，建模的结果也越复杂。进而可以想象，如果这些建模的成果只以文本方式留在产出物材料和大量的表格中，面对高额的维护和使用成本，势必会成为企业库房里的“呆料”，随着时间流逝价值递减。
于是我们觉得 “把企业架构的工作搬到线上吧！让架构的产生、使用都流动起来！”，这个想法与客户企业管理中心的场景不谋而合，客户也面临海量制度的无法有效管理使用，我们以同样的务实态度和实用主义精神，与客户达成了更长远的合作。
可见，“务实的态度”是一种职业上的个人选择。它与工作的问题层次无关，与领域也无关。当选择以这样的态度工作，无论是在宏观的规划还是微观的执行层面，都遵循对实效性与可行性的坚守、坚持，和对实际结果的关注。
此时，再次回答“务虚”的评价
某友：”听说你现在是企业架构师，听着就很高大上，现在是不是不做技术了，是不是工作偏务虚？“
我：“如果你说的务虚指处理的问题类型，那的确是，我们会更关注产出符合企业诉求的IT规划，更为抽象和宏观；但如果你说的是务虚的态度，脱离实际不落地，那就委屈我了，我们在做事的时候，坚持务实、解决实际问题，这是我们的第一原则”
