收录了 部门架构 频道下的 49 篇内容
本文来自《2019年有赞技术大礼包》系列。
作为架构师和设计者,我们常把手头的事情作为工作焦点,很少反思过去如何。我们应该温故而知新。Andres Kutt这篇文章从他作为Skype架构组领导的经历中总结了6个经验,其中有技术方面的,另外一些是架构师较为软性一点的观点。
来自跨国银行的一线微服务改造经验
1、架构源于对实践的总结,架构是一个建模的过程。2、架构工作的核心是设计,架构需要作出一系列非技术选择。3、代码是架构设计的落地实现。
数人科技的Omega Cloud云操作系统是可以部署在任意公有云,私有云,物理机上的云操作系统。为了服务中小互联网企业,数人科技需要建立一套PaaS服务。初期很难预估整个业务的发展趋势,若一次性购买大量IT基础设施,则数人科技面临着成本高风险大的难题;若购买量不足,则可能造成底层资源无法满足业务快速增长。
英国就业及退休金事务部总监、CDO兼CIO Mayank Prakash在DevOps Enterprise Summit London活动中向与会者介绍了英国最大政府部门如何“从供应商外包的传统架构和服务交付模式,转型为以数字化为核心DNA的全新模式”,InfoQ随后采访了Prakash先生。
据纽约时报报道,过去五个月里,波音董事会的一个小型委员会一直在采访公司员工,安全专家和其他工业组织的高管,试图了解这家航空巨头如何设计和制造更安全的飞机。该委员会本周将向波音全体董事会提交调查结果,并呼吁对公司的组织架构方式进行一些有意义的改变。这些建议将包括改变波音组织结构的各个方面,呼吁建立以安全为重点的新部门,鼓励公司考虑改变未来飞机的驾驶舱,以适应新一代飞行员。
多数架构师都是停留在“技术架构,或软件架构的层面。少有人能做到“开放性思维”,从商业问题的本身出发, 带领团队让“理真的越辩越明”。
企业级转型,或者搞中台,都不是“一锤子买卖”。
架构师的职责是什么?对一个公司的核心价值是什么?核心能力又是什么?如何培养这些核心能力?
本文转载自技术琐话公众号
业务架构从诞生之初就很清楚地定义了自己的使命:面向复杂系统构建。未来,业务不再仅仅是业务,技术也不再仅仅是技术,谁先实现思维方式的改进,谁就能赢得转型的先手,而业务架构能力可以在这方面发挥关键作用。
Gartner在一份最近的报告中透露,只有9%的企业架构活动是在组织内业务方面的合作下完成的。虽然合作项目的比例有望在2016年提高到30%,但是有人认为企业架构小组参与度这样低还是让人警觉,也使他们处于被业务团组抛开而独自做出技术决策的风险之中。
业务架构设计需要考虑哪些因素?业务架构设计的难点和挑战是什么?
办公环境和员工地理位置分布化的同时,网络又在虚拟地联系着越来越大规模的企业,这都给企业管理者提出了很多新的问题,集中化与去集中化之间该怎么选择呢?架构师又该做些什么呢?S. E Slack在IBM developerWorks的撰文似乎对我们很有启示。
“我们特别强调数字化转型下的企业架构升级,要做到整体与细节的统一性,做到从高阶到细节的一致性,同时去满足细节需求,最终能汇总成一个完整的整体架构。 ”
ADMIT详细表述了任何 IT架构工作中都应考虑的决策点。虽然ADMIT格式与其他企业架构框架类似,但ADMIT更关注影响最终结果的特性和驱动力,这使得它可以与其他形式化的企业架构设计和评价方法学结合使用。
满意在每个人心里的定义都不一样,一个系统在每个部门的期望也不一致。参与项目的干系人都有各自的立场也有各自的目标和标准。如何开发系统才能满足以上的所有期望?
收获大型银行架构转型的一手经验