收录了 企业架构图 频道下的 50 篇内容
数字化转型最重要的能力是什么?政策解读能力。
随着敏捷和精益实践的流行,企业架构师的角色也在悄然地发生变化,最近ThoughtWorks的技术专家Kevin Hickey在MartinFowler的博客上发表了一篇文章,介绍了自己对新时代企业架构师的理解,本文便是由该文翻译整理而来。
架构图对于系统的设计和文档化来说都是很重要的。它们必须是自描述的,并且与代码保持一致性。为了保证利益相关者能够看懂架构图,需要遵循一些原则。
本次分享,就会从当前数字化与平台的趋势和挑战出发,引出并介绍企业架构概念、发展历史以及经典企业架构的困境。
关注企业架构,你会逐渐获得不一样的设计视角,会越来越知道自己写的软件有什么样的价值。
“我们特别强调数字化转型下的企业架构升级,要做到整体与细节的统一性,做到从高阶到细节的一致性,同时去满足细节需求,最终能汇总成一个完整的整体架构。 ”
深入浅出地讲企业架构。
适当数量的软件架构图可以极大地改善开发团队和外部利益相关者之间的沟通。我们需要对目标受众有很好的了解,以及对内容的深思熟虑。不要因为有很多不好架构图就认为架构图是不必要的或者没有用的。
很多企业架构师仍然在偷偷编写自己的“解决方案架构定义手册”,甚至想办法掩藏自己的真实意图。但现在,我们发现了一种新的趋势,越来越多的商业与企业架构团队开始携手合作,并共同参与到组织的业务优先级战略规划、项目组合管理、路线图优化、产品管理、以客户为中心型计划、敏捷项目调节以及制定面向业务的新型现代KPI等工作当中。
John Zachman是Zachman框架的发起人,他最近撰写了一篇文章,回答了与云计算对企业架构产生的影响相关的问题;他特别强调,具有颠覆性并且开始流行的云架构正逐渐成为降低成本的有效技术。
Scott Ambler给希望对其企业架构过程进行剪裁的企业架构师们提出了一些忠告,告诉他们怎样支持敏捷软件开发团队。他主张开发团队希望企业架构师手把手参与到项目当中,给出指导、参考架构和总体概要图;他们不希望长篇累牍的文档、耳提面命的管理和审查。
本文是架构设计实践五部曲系列文章的第一篇,架构与架构图。本文将对架构作深入的阐释,并教你什么时候画架构图、怎么画架构图。
本文是架构设计实践五部曲系列文章的第五篇,技术架构的战略和战术原则。本篇讲述如何保证在做技术架构时,实现一个稳定、出色的系统。
业务架构设计需要考虑哪些因素?业务架构设计的难点和挑战是什么?
经过去年的起起落落,圈内至少对中台达成了一个共识——它仍是一种企业级的软件工程方法。
多数架构师都是停留在“技术架构,或软件架构的层面。少有人能做到“开放性思维”,从商业问题的本身出发, 带领团队让“理真的越辩越明”。
业务架构的概念是上个世纪的,但最近几年在企业级实践里发现了业务架构的一些作用,所以今天我们又重新看待它的价值。
业务架构从诞生之初就很清楚地定义了自己的使命:面向复杂系统构建。未来,业务不再仅仅是业务,技术也不再仅仅是技术,谁先实现思维方式的改进,谁就能赢得转型的先手,而业务架构能力可以在这方面发挥关键作用。
本文定义了业务架构的主题和规则。与其他方式不同,只有业务职能和业务信息才能成为架构中的实体,共同形成业务架构的主题。另一方面,业务架构的规则是对业务架构主要及次要任务的描述。
中台说到底也是一种业务架构设计结果,回顾软件设计的发展历程,中台也不是石头中蹦出来的齐天大圣,它并非一种超越了企业架构这个概念的存在,因此,想要深入理解中台设计方式,多去学习下业务架构、软件架构的发展历程还是有帮助的。