跳转到主要内容
为什么没有人理解企业架构&为什么技术抽象总是失败

为什么没有人理解企业架构&为什么技术抽象总是失败

2022年1月20日 11次UAT-栏目管理员

 抽象而复杂的技术解决方案失败了。企业架构就是这些。我们可以继续使这一切复杂化,或者只是承认我们正在通过开发动态业务技术战略来寻求业务技术一致性。归根结底,EA既是转换器,也是桥梁:战略转换器和技术桥梁。中间立场是商业技术战略。(文章来源:Forbes)

 

EA是什么?

 

“企业架构(EA)是一门学科,通过识别和分析朝着理想业务愿景和结果方向的变化的执行,积极主动和全面地领导企业应对破坏性力量。EA通过向业务和IT领导者提供调整政策和项目的签名就绪建议,以实现利用相关业务中断的有针对性的业务结果,从而提供价值。”

 

也许像你一样,我不知道这些是什么意思。这种语言抽象而令人困惑。谁那样说话?“企业架构(EA)是一门学科,通过识别和分析朝着理想业务愿景和结果方向的变化的执行,积极主动和全面领导企业应对破坏性力量。”真的吗?

 

好的,也许其他人——比如TechTarget——可以讲清EA:

“企业架构(EA)是定义组织结构和运营的概念蓝图。企业架构的目的是确定一个组织如何有效地实现其当前和未来的目标。企业架构涉及分析、规划、设计和最终实现企业分析的实践。”

 

好多了一点,但仍然太模糊了。

 

如果我有这项权利,EA(至少每个人都同意首字母缩略词)来自业务战略,专注于“当前和未来(业务)目标”或“期望的业务愿景和结果”。虽然我不知道为什么定义不直接与战略有关,但我可以接受围绕业务绩效对EA的解释。我想足够清楚了,但为什么有这么多EA项目失败?(WhiteCloudSoftware表明,66%的EA计划失败了。)

 

EA不应该是什么

 

EA不应该是一个带有奇怪、深奥术语的抽象概念。我们一直在这样做:SCRUM、ITIL、Cookie、垃圾邮件、恶意软件、Nettiquette、微博、SEO、API、缓存、虚拟、防火墙、路由器、蓝牙、API、SaaS(PaaS和IaaS)、NLP和瀑布。EA不应该是另一个需要翻译的抽象概念。EA也不应该是远程操作——也不应该外包给对公司知之甚少的供应商。它不应该是神秘的或离散的,绝对不应该与构成整体业务战略的当前和预测的业务模式和流程脱节。

 

那么EA应该是什么?

 

第一步是揭开神秘面纱。所有抽象术语——甚至“架构”一词——都应该修改或替换为每个人——特别是非技术高管——都能理解的单词和短语。企业规划或企业业务技术战略可能更好,甚至只是业务技术战略(BTS)。为什么?因为“企业架构”只不过是一种对齐练习,在企业想要做的事情和技术人员现在和几年后如何实现它。这是持续的,因为业务需求不断变化。归根结底,EA既是转换器,也是桥梁:战略转换器和技术桥梁。中间立场是商业技术战略。

 

如何进行企业架构(或BTS)

 

EA——或者我应该说“商业技术战略”——不是战略的表亲,而是后代。只有当EA来自连贯的业务战略时,EA才有意义。对于技术公司,即销售基于技术的产品和服务的公司——EA的作用更容易定义。谁不想帮助技术(又名“工程”)——那些构建产品和服务的人——使用正确的基础设施上的正确数据构建正确的应用程序?

 

EA的官方步骤包括开发四个“架构”:

“业务架构——定义业务战略和组织、关键业务流程以及治理和标准。

 

应用程序系统架构——为部署单个系统提供了蓝图,包括应用程序系统之间的交互及其与基本业务流程的关系。

 

数据架构——记录逻辑和物理数据资产的结构以及任何相关的数据管理资源。

 

技术架构——描述了支持部署关键任务应用程序所需的硬件、软件和网络基础设施。”

 

让我们翻译所有这些:

“业务架构——定义业务战略和组织、关键业务流程以及治理和标准:

 

公司如何赚钱的描述。赚钱的流程、产品和服务的描述。描述公司今天如何赚钱,以及它预计在未来3-5年如何赚钱。公司赚钱的竞争市场描述。(有工具可以帮助做到这一点。)

 

应用程序系统架构——为部署单个系统提供了蓝图,包括应用程序系统之间的交互及其与基本业务流程的关系:

 

实现赚钱的流程、产品和服务的软件应用程序。使公司在未来3-5年内赚钱的软件应用程序。(也有这方面的工具。)

 

数据架构——记录逻辑和物理数据资产的结构以及所有相关的数据管理资源:

 

公司需要的数据类型来为软件应用程序提供燃料,从而实现赚钱的流程、产品和服务。使公司在未来3-5年内赚钱的数据。(有这方面的工具。)

 

技术架构——描述支持部署关键任务应用程序所需的硬件、软件和网络基础设施:

 

使用公司所需的数据的技术基础设施和技术交付,为软件应用程序提供动力,从而实现和优化赚钱的流程、产品和服务。使公司今天和未来3-5年能够赚钱的基础设施。(有这方面的工具。)

 

一个测试是,这一切对非技术高管来说有多容易理解。我们可以选择“业务架构”、“应用程序系统架构”、“数据架构”和“技术架构”,也可以简单地选择策略、应用程序、数据和交付。(我经常对IT坚持要求每个人都学习自己的语言感到困惑,即使IT服务于业务。)

 

当然,这一切都有“框架”。(总是有框架。)很多很多框架都有奇怪的名称,比如TOGAF、Zachman和FEAF。我从未见过任何成功实施任何框架的人。当然,有些人到处实施了部分,但实际上没有一个部件始终将TOGAF、Zachman或FEAF的使用制度化。

 

治理呢?BTS必须自上而下,而不是自下而上。商业技术策略师应该与执行团队和商业策略师合作,而不是与技术人员合作,至少在最初不应该。他们的第一份工作是转换;他们的第二份工作是桥梁和翻译。如果我们在RACI制定这个图表,BTS有责任,高管有责任。最初,会咨询技术人员。如果这种治理有任何变化,BTS将失败。为什么?因为技术“恶作剧”无处不在。技术人员总是认为他们最了解情况——有时当他们的架构与BTS完全一致时,他们会知道——但通常他们不知道。技术与业务之间的脱节大于业务与技术之间的脱节。

 

值得吗?

如果BTS沦为具体的商业价值,它绝对值得。几十年来,我们一直有一个统一的目标。它还在这里。它将永远在这里。BTS只是公正的,都是关于对齐统一的。多年来,EA方法、工具和框架得到了开发,并强加给几乎不了解它们的公司、战略家和技术人员。现在是时候将EA剥离到其最基本的特性了——业务战略与运营和战略技术保持一致。我们可以继续使这一切复杂化,或者只是承认我们正在通过开发动态业务技术战略来寻求业务技术一致性。EA是个好主意,但它不是一个切实可行的解决方案。BTS将产生更好的结果。

 

关于作者

史蒂夫·安德烈奥

维拉诺瓦大学维拉诺瓦商学院的拉布雷克商业技术教授,他在那里教授战略技术、创新和创业精神。他研究技术管理最佳做法、社交媒体、分析、云计算和技术采用。他是35本关于信息技术、技术趋势和商业技术管理的书籍的作者/合著者/编辑。

 

声明:发表于The Open Group APAC雷达栏目的文章不一定代表官方观点。文内对出版物、产品或服务的评论和分享并不构成对购买的认可或建议。

 

新年兴「书」礼!官方数字化转型发布物礼盒装等您遇见!限量速领!