Take Responsibility for Your Decisions

?

Take Responsibility for Your Decisions

Yi Zhou

SoFTWARE ARCHiTECTS HAvE To TAKE RESponSiBiliTy for their deci- sions, as they have much more influential power in software projects than most people in organizations. Studies of software projects show that more than two-thirds of them either are outright failures or deliver unsuccessfully (deadline slip, budget overruns, or low customer satisfaction). Many of the root causes point to improper decisions software architects made, or failures of follow-through on the right architectural decisions.

How can you become a responsible software architect who makes effective architectural decisions?

First, you have to be fully cognizant of your decision process, whether it is agile or ceremonial. You should not claim that an architectural decision has been made until the following two conditions are met:

? A decision has been put in writing because architectural decisions are rarely trivial. They must be substantiated and traceable.

? A decision has been communicated to the people who execute it and the people who will be affected directly or indirectly. Communication is all about creating shared understanding.

Second, review your architectural decisions periodically. Examine the results of your decisions against expectations. Identify architectural decisions that remain valid and those that do not.

?

??Third, enforce your architectural decisions. Many software projects get software architects involved only in the design phase, then they move on to other proj- ects or the consultation contract ends. How can they ensure that their deliber- ate architectural decisions have been implemented correctly? Their decisions will be at best good intentions unless they follow through with them.

Finally, delegate some decision making to others who are experts in a problem domain. Many architects wrongly assume they have to make every architec- tural decision. Therefore, they position themselves as know-it-all experts. In reality, there’s no such thing as a universal technical genius. Architects have areas in which they are quite proficient, areas in which they are knowledge- able, and areas in which they are simply incompetent. Adept architects del- egate decisions about domain problems in which they are not proficient.

Yi Zhou is currently the chief software architect in a well-known biotech company, and specializes in designing the software platform for medical devices and person- alizing disease management. He has nearly 20 years’ experience in all aspects of the software development life cycle, and excels in business-technology alignment and strategic planning, process improvement, architecture and framework design, team building and management, and consulting.

时间: 2024-10-21 08:07:13

Take Responsibility for Your Decisions的相关文章

设计模式之Chain of Responsibility(职责链)(转)

Chain of Responsibility定义 Chain of Responsibility(CoR) 是用一系列类(classes)试图处理一个请求request,这些类之间是一个松散的耦合,唯一共同点是在他们之间传递request. 也就是说,来了一个请求,A类先处理,如果没有处理,就传递到B类处理,如果没有处理,就传递到C类处理,就这样象一个链条(chain)一样传递下去. 如何使用? 虽然这一段是如何使用CoR,但是也是演示什么是CoR. 有一个Handler接口: public

Oracle EBS 提示XX对当前用户不可用--XX is not a valid responsibility for the current user

Oracle EBS 提示XX对当前用户为不可用职责--XX is not a valid responsibility for the current user 最近在EBS中添加新职责进行切换没问题,但是要进入相关职责的Form或Web页面则会碰到如图的难题.解决方法是这样的. 1. 进入Functional Administrator职责. 2. 选择Core Services->Caching Framework->Global Configuration. 3. 分别Clear Al

Chain of Responsibility模式

消息传递是面向对象开发中经常用到的机制,例如异常的传递,如果当前函数/类无法处理异常,可以将其抛到上一层.消息传递类似,如果一个类收到消息,如果当前类无法处理,可以将消息按照预先定义好的路径传递下去,直到有类可以处理这个消息.这就是Chain of Responsibility模式. Handle类中持有自己的指针/引用,指向某一个派生类.如果当前类无法处理消息,则调用派生类来处理. 实现: Handle.h #ifndef _HANDLE_H_ #define _HANDLE_H_ class

(20):(行为型模式) Chain Of Responsibility 职责链模式

(20):(行为型模式) Chain Of Responsibility 职责链模式,布布扣,bubuko.com

C#设计模式系列:单一职责原则(Single Responsibility Principle)

1.单一职责原则的核心思想 一个类应该有且只有一个变化的原因. 2.为什么要引入单一职责原则 单一职责原则将不同的职责分离到单独的类,每一个职责都是一个变化的中心.当需求变化时,这个变化将通过更改职责相关的类来体现.如果一个类拥有多于一个的职责,则这些职责就耦合到在了一起,那么就会有多于一个原因来导致这个类的变化.对于某一职责的更改可能会损害类满足其他耦合职责的能力.这样职责的耦合会导致设计的脆弱,以至于当职责发生更改时产生无法预期的破坏. 3.单一职责原则的优点 1>.可以降低类的复杂度,一个

atitit.设计模式(1)--—职责链模式(chain of responsibility)最佳实践O7 日期转换

atitit.设计模式(1)---职责链模式(chain of responsibility)最佳实践O7 日期转换 1. 需求:::日期转换 1 2. 可以选择的模式: 表格模式,责任链模式 1 3. 调用代码 2 4. 责任链链的特性: 2 5. 模式结构 4 6. 职责链模式包含如下角色:Handler,ConcreteHandler: 具体处理者,HandlerChainUtil ,Client 4 7. 设置哈一个handler,,两个法:排序法,指定法 5 1. 指定法 5 2. 排

职责链(Chain of Responsibility)模式

职责链(Chain of Responsibility)模式:使多个对象都有机会处理请求,从而避免请求发送者呵接受者之间的耦合关系. 将这个对象连成一条链子,并沿着这条链传递该请求,知道有一个对象处理它. /* * 抽象处理者(Handler)角色:定义出一个处理请求的接口.如果需要,接口可以定义出一个方法,以设定和返回对下家的引用. 这个角色通常由一个抽象类或接口实现. * 具体处理者(ConcreteHandler)角色:具体处理者接到请求后,可以选择将请求处理掉,或者将请求传给下家. 由于

设计模式19:Chain Of Responsibility 职责链模式(行为型模式)

Chain Of Responsibility 职责链模式(行为型模式) 请求的发送者与接受者 某些对象请求的接受者可能有多种多样,变化无常…… 动机(Motivation) 在软件构建过程中,一个请求可能被多个对象处理,但是每个请求在运行时只能有一个接受者,如果显示指定,将必不可少地带来请求发送者与接受者的紧耦合. 如何使请求的发送者不需要指定具体的接受者?让请求的接受者自己在运行时决定来处理请求,从而使两者解耦. 意图(Intent) 使多个对象都有机会处理请求,从而避免请求的发送者和接受者

职责链模式(Chain of Responsibility)

详解 定义 为了避免请求发送者与接收者耦合在一起,让多个对象都有可能接收请求,将这些对象连接成一条链,并且沿着这条链传递请求,直到有对象处理它为止,职责链模式又称为责任链模式,它是一种对象行为型模式.(如果你接触过异常处理,那么套用异常处理机制可以更好地理解). 职责链可以是一条直线,也可以是一个环,还可以是一个树形结构,不过最常见的职责链是直线型,即沿着一条单向的链来传递请求.链上的每一个对象都是请求处理者,职责链模式可以将请求的处理者组织成一条链,并使请求沿着链传递,由链上的处理者对请求进行