The Architect (dedicated non-programming technical decision maker and problem solver for business):
架构师(专用非编程技术决策者,业务问题解决者)
- Has outdated programming knowledge and experience, loss of touch with modern development approaches and practices. 过时的编程知识和经验,对现代的软件开发方式和实践缺乏关注。
- Don’t program and don’t know much about evolving system internals, but makes key technical decisions. Often has completely irrelevant and unreal picture what is happening with the system. 不进行软件开发,对系统内部知之甚少,但却要做出关键的技术决策。对系统经常有完全无关和虚幻的映像(不太会翻译这句)。
- Tends to complex, premature and generic solutions when the system is still in infancy and nothing is clear. Applies latest modern buzzword technologies as SOA, MDA, SaaS, Software Factories, etc. which look so beautiful in technical magazines, conferences and CV, but cause unnecessary headache for developers. 当系统仍处于起始阶段,都还不明晰的时候,常会做出复杂的,不成熟仅仅通用的决策。使用在技术杂志、技术大会和CV上看起来如此美妙的现代最新的口号,诸如SOA,MDA,SaaS,Software Factories等等,只是给开发人员带来不必要的头痛。
- Plays role of the middleman introducing complexity in coordination and project responsibilities. Represents software team in interactions with business customers reducing communication value for the rest of the team and impacting idea flow. 以中间人的角色,引入复杂的协调和项目的责任。代表开发组与客户进行交流,屏蔽了其他成员的发言权和开发思想上的交流。(翻译时候意思懂了,但就是表达不出来)
- Reduces quality of decisions, which become limited to one perspective; decision making starts lacking diversity, independence and decentralization, which are essential attributes of collective intelligence. 决定仅仅局限在某个角度 ,降低了决策的质量;最初的决定缺乏多样性,独立性和向下兼容,这些都是集体决策的本质。
- Creates tension with developers who experience mismatch between grand design and reality. Often continues pushing design decisions until the system becomes overly complex, difficult to change and becomes completely unusable. 在缺乏大型设计和实现经验的开发者之间制造紧张氛围。不断的做出决定,系统变得过度复杂,难于改变,和应用。
- Secures job and justifies high salary - becomes authoritative center for solving business problems without much input from the team. 有稳定的工作和高薪,成为解决业务问题的权威,但却从未融入到团队当中。
- Causes loss of sense of ownership, motivation and accountability in developers by detaching them from the key architecture decisions. 把开发人员排除在关键架构决策之外,让他们缺乏主动性和责任感。
- Concentrates project knowledge and the big picture in one head, limiting (and sometimes preventing) complete understanding for others. 只精通工程知识和大局一面,对其他方面几乎一无所知。
- Contributes to creation of specialized IT verticals that hurt relations with the business. 擅长在纵向专门的IT方面建立联系,但同时却切断了业务上的关联。
分享到:
相关推荐
【软件架构师入门教程,成功架构你的软件】 作为软件开发领域的关键角色,软件架构师承担着设计和指导软件系统整体结构的重要职责。本教程旨在帮助初级软件工程师掌握软件架构的基础知识,逐步提升到架构师的水平。...
软件架构师是一个至关重要的角色,他们负责塑造软件系统的结构,以满足业务需求并确保系统的高效运行。以下是从标题和描述中提取的一些关键知识点: 1. 客户需求优先:架构师首要任务是理解和分析客户需求,而不是...
对于准备参加软考(即全国计算机技术与软件专业技术资格(水平)考试)中的架构师级别考试的考生来说,这份资源是提升复习效果、理解和掌握考试重点的关键。 在架构师的考试中,主要考察的是候选人在软件系统设计、...
成为一位成功的IT架构师不仅需要深厚的技术功底,还需要良好的沟通能力和项目管理技巧。IBM认为,架构师的成长路径通常包括以下阶段: 1. **初级开发者**:从编码开始,逐渐理解软件开发的各个环节。 2. **技术...
《软件架构师应该知道的97件事》是针对软件架构设计这一重要领域的知识总结,它涵盖了软件开发过程中架构师必须掌握的关键概念、原则和实践。作为软件架构师,理解并运用这些知识点对于创建高效、可扩展且易于维护的...
【系统架构设计师】论文主要探讨了微服务架构在构建一站式互联网大数据征信平台...通过深入理解和实践微服务架构,架构师可以更好地应对现代企业面临的快速变化和高并发挑战,为业务发展提供更加稳定和灵活的技术支持。
在这个过程中,软件架构师扮演着核心角色,他们负责定义、记录、维护和改进软件架构,以确保其正确执行。 软件架构活动包括一系列复杂的步骤,如定义、范围界定等,这遵循了IEEE 1471标准。该标准提供了一个模型...
他的著作《一线架构师实践指南》和《软件架构设计》在业内广受好评,为许多IT从业者提供了宝贵的指导。 ADMEMS方法是温昱对软件架构设计的独特贡献,它代表了六大核心要素,旨在帮助架构师和开发团队系统地进行架构...
这本书旨在为软件架构师提供深入的理解和实用的指导,涵盖了一系列重要的知识点,以下是对其中几个核心概念的详细解析。 ### 不要把简历放在需求之前 **知识点:** - **理解需求的重要性**:Nitin Borwankar在书...
在实际工作中,系统架构师不仅需要精通各种技术,还需要具备良好的沟通技巧和业务理解能力。通过系统的培训和实践,可以不断提升这些方面的能力,从而成为一个出色的系统架构师。在学习过程中,不断反思、实践和调整...
软件架构师通过选择和组合不同的架构模式来设计这样的结构,以满足项目的需求和约束。 常见的软件架构模式包括: 1. 层次型架构:这种模式将系统分解为多个层次,每个层次负责特定的功能。例如,用户界面层、业务...
分布式计算机软件架构在当前及未来的发展中扮演着至关重要的角色。...随着技术的不断进步和应用需求的不断提升,我们有理由相信分布式计算机软件架构将在未来展现出更加多样化和智能化的发展趋势。
案例分析考察的是系统架构师如何在实际场景中应用理论知识,如分布式系统设计、数据存储策略、性能优化等。解析中将详细解读每个案例的背景、问题所在、解决方案以及选择该方案的理由,帮助考生理解和掌握在实际工作...
此外,软件设计师还需要具备良好的文档编写能力,因为清晰、准确的文档是软件开发不可或缺的一部分。真题中的案例分析和设计题,往往要求考生具备撰写系统设计文档和用户手册的能力,这在答案解析中也会有详细的指导...
1. **架构评估与选择**:根据业务场景,评估不同的架构模型,如微服务架构、事件驱动架构等,并解释选择理由。 2. **技术选型**:分析各种技术和工具的优缺点,为特定项目选择合适的技术栈。 3. **架构优化**:...
"软件系统架构风格" 软件系统架构风格是描述特定软件系统组织方式的惯用模式。组织方式描述了系统的组成构件和这些构件的组织方式,惯用模式则反映众多系统共有的结构和语义。在实际的软件项目开发中,采用恰当的...
Java培训课程中的软件架构评估是一项关键的工程活动,它确保设计的系统能够满足各种需求,同时考虑到性能、可用性、安全性和其他重要因素。以下是对该主题的详细解释: 1. **评审流程**: 评审流程是软件架构评估...
例如,2017年的试题可能更加注重软件设计模式、软件架构设计以及敏捷开发等现代软件开发方法。通过解答这些题目,考生可以检验自己在软件需求分析、设计原则、算法设计与分析、数据库设计、网络协议等方面的知识掌握...
1. **需求分析与设计**:题目可能给出一个具体的应用场景,要求考生分析需求,并设计出相应的软件架构。解题时,考生应首先明确需求,然后根据需求设计模块划分、数据流图、实体关系图等,最后给出设计理由。 2. **...