《97 Things Every Software Architect Should Know》读书笔记_97things every software architect should now

（从网上搜集的，并且整理为DOC文档，希望大家可以从这篇文章中学到更多的东西，

我准备将该文档翻译成中文，大家可以不定期的访问我的博客http://blog.csdn.net/jianglike18）

1、Don't put your resume（n. 履历） ahead of therequirements

As engineers we sometimes recommend（v.推荐） technologies, methodologies（方法论） and approaches for solving problemsbecause we want to have these on our resume and not because they are the bestsolution for the problem. Such decisions very rarely result in（v.导致）happy outcomes（n.结果）.

The best thing for your career（n.职业） is a longstring of（一长串的） happy customers eager（adj.热心于） to recommend you because you didthe right thing by(对, 例如He did well by me.

他待我好) them and for the project.This goodwill (n.友好关系) will serve（帮助）you orders of magnitude（若干数量级） better than the latest shiny（闪耀的） object in the latestshiny language or the latest shiny paradigm. While (adj.虽然) it is important, evencritical, to stay abreast（并肩地） of the latest trends (n.趋势) and technologies thisshould never happen at the cost of (adv.以...为代价) the customer. It’simportant to remember that you have a fiduciary(adj.基于信用的) duty. As an architectyou have been entrusted with(v.委托) the well-being（n.安宁）of your organization and itsexpected that you will avoid all conflicts of interest（n.利害） and give the organization your undivided（adj.专一的） loyalty（n.忠诚）. If the project isn't cutting edge(n.刀刃) or challenging enoughfor your current career needs then find one that is.

If you can't do that and you are forced to be in such a project, then you andeveryone else will be happier using the right technology for the customerrather than for your resume. It is often difficult to resist（vt.抵抗） utilizing a solution that is newand cool, even when it is inappropriate for the current situation. 

With the right solution, the project will have a happier team, a happiercustomer and overall far less stress. This will often give you time to go deeper into（v.探究） the existing oldertechnology or to learn the new stuff(n.东西) on your own time. Or togo take that painting class（油画课） you always wanted to do.Your family will love you for it, too - they'll notice the difference when you get home（v.回到家里）.

Overall（全面的） always put the customer's long-term（adj.长期的） needs ahead of your own short-term(adj.短期的) needs and you won't go wrong（v.走错路, 误入歧途, (机器等)发生故障）.

 注：架构师不能置客户的利益于不顾而去沉迷于那些酷酷的技术。

By Nitin Borwankar

This work is licensed under a Creative CommonsAttribution 3

2、Simplify(v.简化) essential(adj.根本的) complexity; Diminish(v.减少)accidental(adj.附属的) complexity

Essential complexity represents the difficulty inherent(adj.固有的) in any problem. For example, coordinating anation’s air traffic is an inherently complex problem. Every plane’s exactposition (including altitude), speed, direction and destination must be trackedin real time to prevent mid(mid smoke and flame.在烟火之中) air and runway(n.飞机跑道) collisions. The flight(n.航班) schedules(n.时间表) of aircraft(n.飞机) must be managed to avoid airport congestion(n.拥塞) in a continuously changing environment – a sever change in weather throws the entire schedule outof whack(n.紊乱).

Conversely(n.相反地), accidental complexity grows from(由……发展起来) the things we feel we must build to mitigate(v.减轻)essential complexity. The antiquated(adj.陈旧的) air traffic control system used today is anexample of accidental complexity. It was designed to address the essentialcomplexity of controlling the traffic of thousands of airplanes, but thesolution itself introduces its own complexity. In fact, the air traffic controlsystem used today is so complex that updating it has proven to be difficult ifnot impossible. In much of the world air traffic is guided by technology thatis more than 30 years old.

Many frameworks and vendor(n.卖方) "solutions" are the symptoms ofthe accidental complexity disease. Frameworks that solve specific problems areuseful. Over-engineered frameworks add more complexity than they relieve.

Developers are drawn to(v.使…接近)complexity like moths(n.蛾) to flame(n.火焰), frequently with the same result. Puzzle solving is fun, and developers are problem solvers. Who doesn't like the rush of solving some incredibly(adv.不能相信地) complex problem? In large-scale software, though(adv.可是) removingaccidental complexity while retaining(v.保留) the solution to the essential complexity ischallenging.

How do you do this? Prefer frameworks derived from working code rather thanones cast down from ivory(n.象牙) towers. Look at the percentage of code youhave in a solution that directly addresses the business problem vs. code that merely (adv.仅仅)services the boundary between the application and the users. Cast a wary(adj.机警的)eye on vendor driven solutions. They may not be inherently bad, but vendorsoften push accidental complexity. Make sure that the solution fits the problem.

It’s the duty of the architect to solve the problems inherent in essentialcomplexity without introducing accidental complexity.

By Neal Ford

This work islicensed under a Creative Commons Attribution 3

(wc 342)

3、Chances(n.机会) are your biggest problem isn't technical

Right now someone's running afailing project to build a payroll(n.工资单) system. Probably more than one someone.

Why? Was it because they chose Rubyover Java, or Python over Smalltalk? Or because they decided to use Postgresrather than Oracle? Or did they choose Windows when they should have chosenLinux? We've all seen the technology take the fall for failed projects. Butwhat are the chances that the problem was really so difficult to solve that Javawasn't up the task?

Most projects are built by people,and those people are the foundation(n.基础) for success and failure. So, it pays(v.值得) to think about(v.考虑) what it takes to(v.求助于) help make those peoplesuccessful.

Equally, there's a good chance thatthere's someone who you think is "just not doing it right" and is undermining(v.破坏) the project. In thesecases, the technology you need to solve your problem is very old and wellestablished indeed, in fact it's possibly the most importanttechnical innovation in the history of humanity. What you need is aconversation.

Mere(adj.仅仅的) familiarity(n.精通) with the conversation as(conj.像)a technology isn't enough.  Learning to treat(v.对待) people with respect(n.尊敬), and learning give them thebenefit of the doubt(在没有相反的证据以前暂时相信他的话), is one of the coreskills that turn a smartarchitectinto one an effectivearchitect.

There's lots more to it than this,but a couple small tips can significantly increase yourconversational effectiveness:

1) Approach these events asconversations -- not asconfrontations.

If you assume the best about peopleand treat this as a way to ask questions you definitely learn more, and you areless likely to put people on the defensive. 

2) Approach these conversations onlyafter you've got your attitude right.

If you're angry, frustrated,annoyed, or otherwise flustered its very likely that the other person will interpret(v.认为是...的意思) you non-verbals asindicating that you're on the attack. 

3) Use these as opportunities to setmutually agreed upon goals.

Instead of telling a developer thatthey need to be quiet in meetings because they never let anybody speak, ask ifthey can help you increase other people's participation. Explain that somepeople are more introverted(adj.内向的) and need longer silences before they jump into aconversation, and ask if they will help you out by waiting 5 seconds beforejumping in. 

If you start with a shared purpose,treat people "problems" as an opportunity to learn, and manage yourown emotions(n.情绪), you'll not only becomemore effective, you'll also discover that you learn something every time. 

 By MarkRamm

This work is licensed under a Creative Commons Attribution3

4、Communication is King; Clarity(n.清楚) and Leadership(n.领导能力) its humble(恭顺的) servants(n.仆人)

All too often(n.时常)software architects sitin their ivory towers, dictating(v.规定) specifications, technology decisions, and technologydirection to the developers below. More often than not(n.时常) this leads to(v.导致) dissension in the ranks,quickly followed by a revolt by the masses, finally resulting in a softwareproduct that doesn't even come close to resembling the original requirements.Every software architect should know how to communicate the goals andobjectives of a software project. The key to effective communication is clarityand leadership.

Clarity describes how you communicate. No one on your team is going to read a100 page architecture decisions document. Being clear and concise(adj.简明的) in the way youcommunicate your ideas is vital(adj.至关重要的) to the success of any software project. Keep thingsas simple as possible at the start of a project, and by all means(adv.尽一切办法) do not start writinglengthy Word documents. Use tools like Visio to create simple diagrams to convey(v.传达) your thoughts. Keep themsimple, for(conj.因为) they will almostcertainly be changing frequently. Another effective means of communication isinformal whiteboard meetings. Nothing gets your ideas across better thanbringing in a group of developers (or other architects) into a room andwhiteboarding your ideas. Also, be sure to always have a digital camera withyou at all times. Nothing is more frustrating than being pushed out of ameeting room with all of your ideas stuck on a white board. Snap a picture,download it, and share it via a wiki to the rest of the team. So throw away thelengthy Word documents and focus more on getting your ideas across, andafterwards worry about recording the details of your architectural decisions.

One thing most software architects fail to realize is that a software architectis also a leader. As a leader, you must gain the respect of your co-workers(n.同事) to work effectively in ahealthy and effective environment. Keeping developers in the dark about the bigpicture or why decisions were made is a clear recipe(n.处方) for disaster. Having thedeveloper on your side creates a collaborative environment whereby(adv.凭什么) decisions you make as anarchitect are validated. In turn, you get buy-in from developers by keepingthem involved in the architecture process. Work with developers, not againstthem.  Keep in mind that all team members (e.g. QA team, BusinessAnalysis, and Project Managers as well as developers) require clear communicationand leadership. Employing(v.使用) clarity and effectiveleadership will improve communication and create a strong and healthy workenvironment.

If “Communication is King” thenclarity and leadership are its humble servants.

By Mark Richards

This work is licensed under a Creative CommonsAttribution 3

 (wc 434)

5、Architecting is about balancing

Balance(v.平衡) stakeholders'(n.股东) interests(n.利益) with technical requirements.

When we think of architectingsoftware, we tend to(v.趋向) think first of(v.考虑) classical(adj.传统的) technical activities(n.行为), like modularizingsystems, defining interfaces, allocating responsibility, applying patterns, andoptimizing performance.  Architects also need to consider security,usability, supportability, release management, and deployment options, amongothers things.  But these technical and procedural(adj.程序上的) issues must be balancedwith the needs of stakeholders and their interests. Taking(v.采取) a “stakeholders andinterests” approach(n.步骤) in requirements analysisis an excellent way to ensure completeness(n.完备性) of requirements specifications for the software beingdeveloped.

Analyzing the stakeholders, and their interests, in the process by which anorganization develops software, and in the organization itself, reveals(v.揭示) the ultimate(adj.最终的) set of priorities bearing on(v.有关) a software architect.Software architecting is about balancing this set of priorities, over the shortand long term, in a way that is appropriate to the context at hand.

Consider, for example, the engineering department of a software-as-a-servicebusiness. The business likely has certain priorities(n.优先考虑的事), such as meeting contractual(adj.契约的) obligations(n.义务), generating revenue,ensuring customer referenceability, containing costs, and creating valuabletechnology assets(n.资产). These businesspriorities may translate to departmental(adj.部分的) priorities like ensuring the functionality andcorrectness, and “quality attributes” (i.e. “-ilities”) of the software beingdeveloped, as well as ensuring the productivity of the development team,ensuring the sustainability and auditability of development operations, and theadaptability(n.适应性) and longevity(n.寿命) of the softwareproducts.
It is the architect’s job to not only create functional, quality(n.优质) software for users, butalso to do so while balancing the other departmental priorities, with the costcontainment interests of the business’s CEO, with the ease-of-administrationinterests of the operations staff, with the ease-of-learning andease-of-maintenance interests of future programming staff, and with bestpractices of the software architect’s profession.
The architect may choose to consciously(adv.有意识地) tilt(v.(使)倾斜) the balance in favor of(adv.赞同) one priority in theshort term, but had better(adv.最好) maintain a proper balance over the long term in order totruly do the job well. And the balance that is struck needs to be appropriateto the context at hand, considering factors such as the expected lifespan(n.寿命) of the software, the criticality(n.临界点) of the software to thebusiness, and the technological and financial culture of the organization.

Insummary(综上), software architectingis about more than just the classical technical activities; It is aboutbalancing technical requirements with the business requirements of stakeholdersin the project.

By Randy Stafford

This work is licensed under a Creative CommonsAttribution 3

(wc 391)

6、Seek the value in requested capabilities

Often customers and end-users state(v.宣称) what they think is a viable(adj.可行的) solution to a problem asa requirement. The classical story on this was told by Harry Hillaker, the leaddesigner of the F-16 Falcon(n.猎鹰). His team was requestedto design a Mach 2 - 2.5 aircraft, which was then, and probably still is, a non-trivial(adj.重要的) task – especially whenthe objective is to create "cheap" lightweight aircraft. Rememberthat the force required to overcome drag(n.阻力) quadruples(n.四倍) when doubling(v.使加倍) the speed, and what impact that have on aircraft weight.

When the design team asked the air force why they needed Mach 2 - 2.5, theanswer was to be able to escape from combat(n.格斗). With the real need on the table the design team was ableto address the root problem and provide a working solution. Their solution wasan agile aircraft with a high thrust-to-weight ratio, providing accelerationand maneuverability(n.机动性), not maximum speed.

This lesson should be brought into software development as well. By asking forthe value to be provided by a requested feature or requirement architects areable address the real problem, and hopefully provide a better and cheapersolution compared to addressing the solution suggested by the client. The focuson value also simplifies prioritization. The most valuable requirements becomethe driving(adj.强烈的) requirements.

So, how to proceed then? In many ways the required approach is found in theagile manifesto(n.宣言): "Collaboration(n.协作) over(v.优先于) contract".Practically speaking this implies arranging workshops(n.讨论会) and meetings where thearchitects focus are on customer needs, helping the customers to answer the"why" question. Be aware that answering the "why" questioncan be difficult because we very often talk about tacit(adj.隐含的) knowledge. Discussionson how to provide a technical solution should be avoided in these workshops,because they move the discussions away from the customer’s domain and into thedomain of software development.

By Einar Landre

This work is licensed under a Creative CommonsAttribution 3

(wc 309)

7、Stand Up!

As architects, many of us have grownfrom highly technical positions where our success was derived mainly from ourability to talk to machines. However, in the role of architect much of ourcommunication is now done with our fellow human beings. Whether it's talking todevelopers about the benefits of employing a specific pattern, or explaining tomanagement the cost-benefit(adj.成本效益的) tradeoffs(n.n.权衡) of buying middleware, communication is core to oursuccess.


Although it's difficult to measure an architect's impact on a project, ifdevelopers consistently ignore their guidance(n.指导) and management doesn't buy-in(v.买账) to theirrecommendations, the "rightness(n.正确性)" of their guidance will do little toadvance their career. Experienced architects understand that they need to"sell" their ideas and need to communicate effectively in order to dothat.

Many books have been written on the topic of inter-personal(adj.人与人之间的) communication, but Iwanted to call out one simple, practical, easy-to-employ tip that willdrastically increase the effectiveness of your communication, and,consequently, your success as an architect.  If you’re in any situationwhere you’re talking to more than one person about your guidance, standup.  Whether it’s a formal design review or an informal discussion oversome diagrams, it doesn’t matter. Stand up, especially if everyone else issitting down.

Standing up automatically communicates authority(n.威信) and self-confidence. Youcommand the room. People will interrupt you less. All that is going to make abig difference to whether or not(n.无论是否) your recommendations will be adopted.

You’ll also notice that once you stand, you’ll start making more use of yourhands and other body language. When speaking to groups of 10 or more people,standing up will also help you can make eye contact with everybody. Eyecontact, body language, and other visual elements account for(v.占) a large portion ofcommunication. Standing up also tends to change your tone of voice, volume, pitch(n.音调), and speed: projecting(v.使突出) your voice to largerrooms; slowing down(v.(使)慢下来) to make more importantpoints. These vocal elements contribute substantially(adv.充分地) to the effectiveness ofcommunication.

The easiest way to more than double your effectiveness when communicating ideasis quite simply to stand up.

By Udi Dahan

This work is licensed under a Creative CommonsAttribution 3

(wc 352)

8、Skyscrapers(n.摩天楼) aren't scalable

We often hear software engineering compared to(比喻为) building skyscrapers, dams(n.水坝), or roads. It's true insome important aspects(n.方面).

The hardest part of civilengineering(土木工程学) isn't designing abuilding that will stand up once(conj.一旦) it is finished, but figuring out the construction process.The construction process has to go from a bare(adj.空的) site to a finishedbuilding. In the interim(在这期间), every worker must beable to apply his trade, and the unfinished structure has to stand up the wholetime. We can take a lesson from that when it comes to deploying largeintegrated systems. ("Integrated" includes virtually every enterpriseand web application!) Traditional "big bang" deployments are like stacking up(v.加起来) a pile of beams andgirders, throwing them into the air, and expecting them to stick together inthe shape of a building.

Instead, we should plan to deployone component at a time. Whether this is a replacement or a greenfield project, this has two largebenefits.

First, when we deploy software, weare exposing ourselves to the accumulated technical risk embodied in the code.By deploying one component at a time, we spread technical risk out over alonger period of time. Every component has its own chance to fail inproduction, letting us harden each one independently.

The second large benefit is that itforces us to create well-defined interfaces between components. Deploying asingle component of a new system often means reverse-integrating it with theold system. Therefore, by the time deployment is complete, each component hasworked with two different systems: the original and the replacement. Nothing isreusable until it has been reused, so piecewise deployment automatically meansgreater reusability. In practice, it also leads to better coherence and loosercoupling.

Conversely, there are some importantways that civil engineering analogies mislead us. In particular, theconcreteness of the real world pushes us toward a waterfall process. After all,nobody starts building a skyscraper without knowing where it's going or howtall it should be. Adding additional floors to an existing building is costly,disruptive and risky, so we strive to avoid it. Once designed, the skyscraperisn't supposed to change its location or height. Skyscrapers aren't scalable.

We cannot easily add lanes to roads,but we've learned how to easily add features to software. This isn't a defectof our software processes, but a virtue of the medium in which we work. It's OKto release an application that only does a few things, as long as users valuethose things enough to pay for them. In fact, the earlier you release yourapplication, the greater the net present value of the whole thing will be.

"Early release" may appearto compete with "incremental deployment", but they can actually worktogether quite well. Early release of individual components means that each onecan iterate independently. In fact, it will force you to work out thorny issueslike continuous availability during deployments and protocol versioning.

It's rare to find a technique thatsimultaneously provides higher commercial value and better architecturalqualities, but early deployment of individual components offers both.

By Michael Nygard

This work is licensed under a Creative CommonsAttribution 3

9、You're negotiating more often than you think.

We've all been hit withbudgetecture. That's when sound technology choices go out the window in favorof cost-cutting. The conversation goes something like this.

"Do we really need X?"asks the project sponsor (n.发起人).

For "X", you cansubstitute nearly anything that's vitally(n.极其) necessary to make the system run: software licenses,redundant servers, offsite backups, or power supplies. It's always asked with a sort of(一种) paternalistic(adj.家长式统治的) tone, as though(好像) the grown-up(n.成年人) has caught us blowing(乱花钱) all our pocket money on comic（adj.喜剧的） books and bubble gum（n.泡泡糖）, whilst(n.同时) the serious adults aretrying to get on with(继续做) buying more buckets tocarry their profits around in.

The correct way to answer this is"Yes. We do." That's almost never the response.

After all, we're trained asengineers, and engineering（n.工程） is all about making trade-offs（n.平衡）. We know good and well that youdon't really need extravagances(n.浪费) like power supplies, so long as there's a sufficientsupply of hamster wheels and cheap interns in the data center. So instead ofsaying, "Yes. We do," we say something like, "Well, you could dowithout a second server, provided you're willing to accept downtime for routinemaintenance and whenever a parity bit flips, causing a crash, but if we geterror-checking parity memory then we get around that, so we just have to worryabout the operating system crashing, which it does about every three-point-ninedays, so we'll have to do nightly restart. The interns can do that wheneverthey get a break from the power-generating hamster wheels."

All of which might be completelytrue, but is utterly the wrong thing to say. The sponsor stopped listeningright after the word "well."

The problem is that you see yourpart as an engineering role, while your sponsor clearly understands he'sengaged in a negotiation. We're looking for a collaborativesolution-finding exercise; they're looking for a win-lose tactical maneuver.And in a negotiation, the last thing you want to do is make concessions(n.让步) on the first demand. Infact, the right response to the "do we really need" question issomething like this:

"Without a second server, thewhole system will come crashing down at least three times daily, particularlywhen it's under heaviest load or when you are doing a demo for the Board ofDirectors. In fact, we really need four servers so we can take one HA pair downindependently at any time while still maintaining 100% of our capacity, even incase one of the remaining pair crashes unexpectedly."

Of course, we both know you don'treally need the third and fourth servers. This is a counter-negotiating gambitto get the sponsor to change the subject to something else. You're upping the ante（n.赌注） and showing that you're alreadyrunning at the bare, dangerous, nearly-irresponsible minimum tolerableconfiguration. And besides, if you do actually get the extra servers, you cancertainly use one to make your QA environment match production, and the otherwill make a great build box.

By Michael Nygard

This work is licensed under a Creative CommonsAttribution 3

10、Quantify

"Fast" is not arequirement. Neither is "responsive". Nor "extensible". Theworst reason why not is that you have no objective way to tell if they're met.But still users want them. The architect's role is largely to help the systemhave these qualities. And to balance the inevitable conflicts andinconsistencies between them. Without objective criteria architects are at themercy of capricious users ("no, I won't accept it, still not fastenough") and of obsessive programmers ("no, I won't release it, stillnot fast enough").

As with all requirements we seek towrite down these desires. Too often then the vague adjectives come out:"flexible", "maintainable" and the rest. It turns out thatin every case (yes even "usable", with effort) these phenomena can bequantified and thresholds set. If this is not done then there is no basis foracceptance of the system by its users, valuable guidance is stolen from itsbuilders as they work, and the vision is blurred for those architecting it.

Some simple questions to ask: Howmany? In what period? How often? How soon? Increasing or decreasing? At whatrate? If these questions cannot be answered then the need is not understood.The answers should be in the business case for the system and if they are not, thensome hard thinking needs to be done. If you work as an architect and thebusiness hasn't (or won't) tell you these numbers ask yourself why not. Then goget them. The next time someone tells you that a system needs to be"scalable" ask them where new users are going to come from and why.Ask how many and by when? Reject "Lots" and "soon" asanswers.

Uncertain quantitative criteria mustbe given as a range: the least , the nominal, and the most. If this rangecannot be given, then the required behavior is not understood. As anarchitecture unfolds it can be checked against these criteria to see if it is(still) in tolerance. As the performance against some criteria drifts overtime, valuable feedback is obtained. Finding these ranges and checking againstthem is a time-consuming and expensive business. If no one cares enough aboutthe system being "performant" (neither a requirement nor a word) topay for performance trials, then more than likely performance doesn't matter.You are then free to focus your architectural efforts on aspects of the systemthat are worth paying for.

"Must respond to user input inno more than 1500 milliseconds. Under normal load (defined as...) the averageresponse time must be between 750 and 1250 milliseconds. Response times lessthan 500 milliseconds can't be distinguished by the user, so we won't pay to gobelow that." Now that's a requirement.

By Keith Braithwaite

This work is licensed under a Creative CommonsAttribution 3 

11、One line of working code is worth（相当...价值） 500 of specification（说明书）（一行可以工作的代码相当于500页规格说明书的价值）

Design is a beautiful thing. A systematic（系统的）, detailed presentation（陈述） and review of a problem space andsolution reveals（揭示） errors and opportunitiesfor improvement, sometimes in a startlingly（令人吃惊地） dramatic（生动的） way. The specificationsare important because they provide the pattern for building. Taking the time tothink through the architecture is important, both on a macro level with an eyefor interactions between components and on a micro level with an eye forbehavior within a component. 

Unfortunately it's far too easy toget wrapped up in（酷爱） the process of design, enthralled（迷惑） by architecture in abstract. Thefact is that specifications alone have no value. The ultimate goal of asoftware project is a production system. A software architect must always keep an eyeon（密切注视） this goal, and remember that designis merely a means to an end, not an end in itself. An architect for a skyscraper（摩天楼） who ignored the laws of physics tomake the building more beautiful would soon regret（为...感到遗憾） it. Losing sight of（忽略） the goal of working code spells（意味着） serious trouble for any project.

Value the team members who work on（继续工作） implementing your vision（想象力）. Listen to them. When they haveproblems with the design, there's a good chance（有很大的可能性） they're right and the design is wrong, or at least unclear. It's your job, in these cases, to modify the design to meet real-worldconstraints by working with（与...合作） your team members to determine whatworks and what does not. No design is perfect from the start; all designs needto be modified as they are implemented.

If you're also adeveloper on the project, value（重视） the time you spend writing code, and don't believe anyonewho tells you it's a distraction（分心的事物） from your work asarchitect. Your vision of both macro and micro levels will be greatly enhancedby the time you spend in the belly（腹中） of the beast（兽） bringing it to life.

 注：设计规格是重要的，但规格不是我们的最终目的。多听同事的，重视写代码，有助于你的设计。所有的设计在实现时都需要被修正。

By Allison Randal

Licensed under Creative CommonsAttribution 3

(wc 313)

12、There is no one-size-fits-all（万全之策） solution

Architects must continuously develop and exercise “contextual sense” – because there is noone-size-fits-all solution to problems which may be widely(相差大地) diverse（变化多的）.

The incisive（深刻的） phrase “contextual sense”was coined（铸造）, and its meaning insightfully（深刻见解地） described, by Eberhardt Rechtin in his 1991 book Systems Architecting:Creating & Building Complex Systems:

[The central ideas of the ‘heuristic（启发式的） approach’ to architecting complex systems] come from asking skilledarchitects what they do when confronted with（面对） highly complex problems. The skilled architect and designer would mostlikely answer, ‘Just use common sense(常识).’ … A better expression than ‘common sense’is contextual sense – a knowledge（知识） of what is reasonable within a given context. Practicing（积极活动的） architects through education, experience, and examples accumulate a considerable（相当可观的） body（大量） of contextual sense by（通过） the time they’re entrusted（委托） with solving a system-level problem – typically 10 years.” [RechtinSysArch] (emphasis in the original)

A big problem in thesoftware industry, in my opinion, is that people are often responsible forsolving problems requiring more contextual sense than they’ve accumulated.Perhaps this is because the software industry isbarely（仅仅） two generations old andgrowing explosively（爆发地）; perhaps it will be a sign of maturity in the software industry when thisproblem no longer exists.

I encounter examplesof this problem frequently in my consulting（顾问） engagements（雇佣）.  Typical examplesinclude failures to apply Domain-Driven Design [Evans DDD] when appropriate, straying（偏离） from a pragmatic（注重实效的） outlook（观点） and over-designing a software solution for the essential need at hand,and making irrelevant or unreasonable suggestions during performanceoptimization crises（紧要关头）.

The most importantknowledge of software patterns is the knowledge of when to apply them and whennot to apply them, and the same is true of different root cause hypotheses（假定） and associated correctiveactions during problem analysis. In both activities – system architecting andproblem analysis – it is axiomatic(不言自明的) that there is no one-size-fits-all solution;architects must develop and exercise contextual sense in formulating（构想） and troubleshooting theirarchitectures.

 注：最重要的是要体会contextual sense这个词，我的理解它是一种具体问题具体分析的能力或者那种感觉。

By Randy Stafford

This work islicensed under a Creative Commons Attribution 3

(wc 265)

13、It’s never too early to think about performance

Business users specify their needsprimarily through functional requirements.  The non-functional aspects ofthe systems, like performance, resiliency（弹性）, up-time（正常运行时间）, support needs, and the like（等等）, are the purview（范围） of the architect. However, oftenthe preliminary testing of non-functional requirements is left until very latein the development cycle, and is sometimes delegated completely to theoperations team. This is a mistake that is made far too often.

The reasons are varied（各式各样的）.  There is presumably（大概） no sense in making something fastand resilient if it doesn't actually perform the required function. Theenvironments and tests themselves are complex.  Perhaps the early versionsof the production system will not be as heavily utilized. 

However, if you aren't looking at performance until late in the project cycle,you have lost an incredible（难以置信的） amount of information asto when performance changed. If performance is going to be an importantarchitectural and design criterion, then performance testing should begin assoon as possible. If you are using an Agile methodology based on two weekiterations, I'd say performance testing should be included in the process no later than（不迟于） the third iteration.

Why is this so important? The biggest reason is that at the very least（丝毫） you know the kinds of changes thatmade performance fall off a cliff（悬崖）. Instead of having to think about the entire architecturewhen you encounter performance problems, you can focus on the most recentchanges. Doing performance testing early and often provides you with a narrowrange of changes on which to focus. In early testing, you may not even try todiagnose performance, but you do have a baseline of performance figures to workfrom.  This trend data provides vital information in diagnosing the sourceof performance issues and resolving them.

This approach also allows for the architectural and design choices to bevalidated against the actual performance requirements.  Particularly forsystems with stringent（迫切的） requirements, earlyvalidation is crucial to delivering the system in a timely fashion.

Technical testing is also notoriously（出了名地） difficult to get going（实行）. Setting up appropriate environments, generating theproper data sets, and defining the necessary test cases all take a lot of time.By addressing performance testing early you can establish your test environmentincrementally avoiding much more expensive efforts once after you discoverperformance issues.

By Rebecca Parsons

This work is licensed under a Creative CommonsAttribution 3

(wc 389)

14、Application architecture determines application performance

Application architecture determinesapplication performance. That might seem rather（相当） obvious, but real-word experienceshows that its not. For example, software architects frequently believe thatsimply switching from one brand of software infrastructure to another will besufficient to solve an application’s performance challenges. Such beliefs maybe based on a vendor’s benchmark（基准） trumpeting（吹嘘）, say, 25% better performance than the closestcompetition’s. But, taken in context, if the vendor’s product performs anoperation in three milliseconds while the competition’s product takes fourmilliseconds, the 25% or one-millisecond advantage matters little in the midstof（在…之中） a highly inefficient architectureat the root of an application’s performance characteristics.

In addition to IT managers andvendor benchmarking teams, other groups of people – vendor support departments,and authors of application performance management literature – recommend simply“tuning” the software infrastructure, by fiddling（微不足道地） with memory allocations, connectionpool sizes, thread pool sizes, and the like.  But if the deployment of anapplication is insufficiently architected for the expected load, or if theapplication’s functional architecture is too inefficient in its utilization ofcomputing resources, then no amount of “tuning” will bring about the desiredperformance and scalability characteristics. Instead a re-architecting of internallogic, or deployment strategy, or both, will be required.

In the end, all vendor products andapplication architectures are constrained by the same fundamental principles ofdistributed computing and underlying physics: applications, and the productsthey use, run as processes on computers of limited capacity, communicating witheach other via protocol stacks and links of non-zero latency. Therefore peopleneed to appreciate that application architecture is the primary determinant ofapplication performance and scalability. Those quality attributes cannot be miraculously（奇迹地） improved with some silver-bulletswitch of software brands, or infrastructure “tuning”. Instead, improvements inthose areas require the hard work of carefully-considered (re-) architecting.

By Randy Stafford

This work is licensed under a Creative CommonsAttribution 3

(wc 300)

15、Commit-and-run is a crime. Respect your Colleagues

It's late in the afternoon. The teamis churning out（艰苦地做出） the last pieces of thenew feature set for the iteration, and you can almost feel the rhythm（节奏） in the room. John is in a bit of ahurry though. He's late for a date, but he manages to（设法） finish up his code, compile,check-in and off he goes. A few minutes later, the red light turns on. Thebuild is broken. John didn't have time to run the automated tests, so he made acommit-and-run and thereby left everybody else hanging. The situation is nowchanged and the rhythm is lost. Everybody now knows that if they do an updateagainst the version control system, they will get the broken code onto theirlocal machine as well, and since the team has a lot to integrate this afternoonto prepare for the upcoming demo, this is quite a disruption. John effectivelyput the team flow to a halt because now no integration can be done before someonetakes the time to revert his changes.

This scenario is way（非常） too common. Commit-and-run is acrime because it kills flow. It's one of the most common ways for a developerto try to save time for himself, that ends up wasting other peoples time and itis downright（完全） disrespectful（无礼的）. Still, it happens everywhere. Why?Usually because it takes too long time to build the system properly or to runthe tests.

This is where you, the architect, come intoplay（开始活动）. If you've put a lot ofeffort into creating a flexible architecture where people can perform, taughtthe developers agile practices like test-driven development and set up acontinuous integration server, then you also want to nurture a culture whereit's not alright to waste anybody else's time and flow in any way. To be ableto get that, you need to make sure the system among other things has a soundarchitecture for automated testing, since it will change the behavior of thedevelopers. If tests run fast, they will run them more often, which itself is agood thing, but it also means that they won't leave their colleagues withbroken code. If the tests are dependent on external systems or if they need tohit the database, reengineer them so they can be run locally with mocks orstubs, or at the very least with an in-memory database, and let the buildserver run them in the slow way. People should not have to wait for computers,because if they have to, they will take shortcuts which often causes problemsfor others instead.

Invest time in making the systemfast to work with. It increases flow, lessens the reasons for working in silosand in the end makes it possible to develop faster. Mock things, createsimulators, lessen dependencies, divide the system in smaller modules or dowhatever you have to. Just make sure there's no reason to even think aboutdoing a commit-and-run.

By Niclas Nilsson

This work is licensed under a Creative CommonsAttribution 3

16、There Can be More than One

It seems to be a never–ending sourceof surprise and distress（不幸） to system builders thatone data model, one message format, one message transport—in fact, exactly oneof any major architectural component, policy or stance（姿态）—won'tserve all parts of the business equally well. Of course: an enterprise ("enterprise" is red flag #1) big enough to worry about how manydifferent "Account" tables will impact system building next decade ismost likely too big and diverse for one "Account" table to do the jobanyway.

In technical domains we can forceuniqueness. Very convenient for us. In business domains the inconsistent,multi–faceted, fuzzy, messy world intrudes（闯入）. Worse yet, business doesn't even deal with "theworld", it deals with people's opinions about aspects of situations inparts of the world. One response is to deem（相信） the domain to be technical andapply a unique solution by fiat（批准）. But reality is that which does not go away when one stopsbelieving in it, and the messiness always returns as the business evolves. Thusare born enterprise data teams, and so forth（等等）, who spend all their (very expensive) time trying to tame（制服） existential dread（恐惧） through DTD wrangling. Payingcustomers tend to find the level of responsiveness that comes form thissomewhat unsatisfactory.

Why not face up to the reality of amessy world and allow multiple, inconsistent, overlapping representations,services, solutions? As technologists we recoil（畏缩） in horror form this. We imagineterrifying scenarios: inconsistent updates, maintenance overhead,spaghetti–plates of dependencies to manage. But let's take a hint from theworld of data warehousing（仓库贮存）. The schemata data martsare often (relationally) denormalized, mix imported and calculated valuesarbitrarily, and present a very different view of the data than the underlyingdatabases. And the sky does not fall because of the non–functional propertiesof a mart（市场）. The ETL process sits atthe boundary of two very different worlds, typically transaction versusanalytical processing. These have very different rates of update and query,very different throughput, different rates of change of design, perhaps verydifferent volumes. This is the key: sufficiently different non–functionalproperties of a sub–system create a boundary across which managing inconsistentrepresentations is tractable（易驾驭的）.

Don't go duplicatingrepresentations, or having multiple transports just for the fun of it, but doalways consider the possibility that decomposition of your system bynon–functional parameters may reveal opportunities to allow diverse solutions toyour customers' advantage. 

By Keith Braithwaite

This work is licensed under a Creative CommonsAttribution 3

17、Business Drives

In the context of businessenterprise application development, an Architect must act as a bridge betweenthe business and technology communities of an organization, representing andprotecting the interests of each party to the other, often mediating betweenthe two, but allowing the business to drive. The business organization'sobjectives and operating realities should be the light in which an Architectleads technology-oriented decision making.

Businesses routinely plan for andarticulate a specific, desired Return on Investment (ROI) before undertaking asoftware development initiative. The Architect must understand the desired ROI,and by implication, the limits of the value of the software initiative to thebusiness, so as to avoid making technology decisions that could cause theopportunity to be out-spent. ROI should serve as a major piece of objectivecontext in the give-and-take conversations with the business about the value ofa feature versus the cost of delivering that feature, and with the developmentteam about technical design and implementation. For example, the Architect mustbe careful to represent the interests of the business to the development teamby not agreeing to choose technology that has unacceptably costly licensing andsupport cost implications when the software is deployed into testing orproduction.

Part of the challenge of letting thebusiness “drive” is providing enough quality information about the ongoingsoftware development effort back into the business to support good businessdecision making. That’s where transparency becomes crucial. The Architect, inconjunction with development management, must create and nurture the means forregular, ongoing information feedback loops. This can be accomplished by avariety of lean software development techniques, such as big visible charts,continuous integration, and frequent releases of working software to thebusiness starting early in the project.

Software development isfundamentally a design activity, in that it involves an ongoing process ofdecision making until the developed system goes into production. It isappropriate for software developers to make many decisions, but usually not tomake business decisions. However, to the extent that the business communityfails to fulfill its responsibility to provide direction, answer questions andmake business decisions for the software development team, it is actuallydelegating the making of business decisions to software developers. TheArchitect must provide the macro-context for this ongoing series ofmicro-decisions made by developers, by communicating and protecting thesoftware architecture and business objectives, and seek to ensure developers donot make business decisions. Technical decision making un-tethered to thecommitments, expectations and realities of the business, as articulated by thebusiness community on an ongoing basis, amounts to costly speculation and oftenresults in an unjustifiable expenditure of scarce resource.

The long-term interests of thesoftware development team are best served when business drives.

By Dave Muirhead

This work is licensed under a Creative CommonsAttribution 3

18、Simplicity before generality, use before reuse

A common problem in componentframeworks, class libraries, foundation services, and other infrastructure codeis that many are designed to be general purpose without reference to concreteapplications. This leads to a dizzying array of options and possibilities thatare often unused, misused, or just not useful. Most developers work on specificsystems: the quest for unbounded generality rarely serves them well (if atall). The best route to generality is through understanding known, specificexamples and focusing on their essence to find an essential common solution.Simplicity through experience rather than generality through guesswork.

Favoring simplicity beforegenerality acts as a tiebreaker between otherwise equally viable designalternatives. When there are two possible solutions, favor the one that issimpler and based on concrete need rather than the more intricate one that boastsof generality. Of course, it is entirely possible (and more than a littlelikely) that the simpler solution will turn out to be the more general one inpractice. And if that doesn't turn out to be the case, it will be easier tochange the simpler solution to what you now know you need than to change the'general' one that turns out not to be quite general enough in the right way.

Although well meant, many thingsthat are designed just to be general purpose often end up satisfying nopurpose. Software components should, first and foremost, be designed for useand to fulfill that use well. Effective generality comes from understanding,and understanding leads to simplification. Generalization can allow us toreduce a problem to something more essential, resulting in an approach thatembodies regularity across known examples, a regularity that is crisp, concise,and well grounded. However, too often generalization becomes a work item initself, pulling in the opposite direction, adding to the complexity rather thanreducing it. The pursuit of speculative generality often leads to solutionsthat are not anchored in the reality of actual development. They are based onassumptions that later turn out to be wrong, offer choices that later turn outnot to be useful, and accumulate baggage that becomes difficult or impossibleto remove, thereby adding to the accidental complexity developers and futurearchitects must face.

Although many architects valuegenerality, it should not be unconditional. People do not on the whole pay for(or need) generality: They tend to have a specific situation, and it is asolution to that specific situation that has value. We can find generality andflexibility in trying to deliver specific solutions, but if we weigh anchor andforget the specifics too soon, we end up adrift in a sea of nebulouspossibilities, a world of tricky configuration options, overburdened (not justoverloaded) parameter lists, long-winded interfaces, and not-quite rightabstractions. In pursuit of arbitrary flexibility you can often lose valuableproperties, accidental or intended, of alternative, simpler designs.

By Kevlin Henney

(Edited RMH 2008-05-28,re-edited KH 2008-06-11 & 2008-07-02)

This work is licensed under a Creative CommonsAttribution 3

19、Architects must be hands on

A good architect shouldlead by example, he (or she) should be able to fulfill any of the positionswithin his team from wiring the network, and configuring the build process towriting the unit tests and running benchmarks. Without a good understanding ofthe full range of technology an architect is little more than a projectmanager. It is perfectly acceptable for team members to have more in-depthknowledge in their specific areas but it's difficult to imagine how teammembers can have confidence in their architect if the architect doesn'tunderstand the technology. As has been said elsewhere the architect is theinterface between the business and the technology team, the architect mustunderstand every aspect of the technology to be able to represent the team tothe business without having to constantly refer others. Similarly the architectmust understand the business in order to drive the team toward their goal ofserving the business.

An architect is like an airline pilot, he might not look busy all of the timebut he uses decades of experience to constantly monitor the situation, takingimmediate action if he sees or hears something out of the ordinary. The projectmanager (co-pilot) performs the day-to-day management tasks leaving thearchitect free from the hassles of mundane tasks and people management.Ultimately the architect should have responsibility for the delivery andquality of the projects to the business, this is difficult to achieve withoutauthority and this is critical the success of any project.

People learn best by watching others; it's how we learn as children. A goodarchitect should be able to spot a problem, call the team together and withoutpicking out a victim explain what the problem is or might be and provide anelegant work-around or solution. It is perfectly respectable for an architectto ask for help from the team. The team should feel part of the solution butthe architect should chair from discussion and identify the right solution(s).

Architects should be bought into the team at the earliest part of the project;they should not sit in an ivory tower dictating the way forward but should beon the ground working with the team. Questions about direction or choices oftechnology should not be spun off into separate investigations or new projectsbut be made pragmatically through hands-on investigation or using advice fromarchitect peers, all good architects are well connected.

A good architect should be an expert in at least one tool of their trade, e.g.an IDE, remember they are hands-on. It stands to reason that a softwarearchitect should know the IDE, a database architect should know the ER tool andan information architect an XML modelling tool but a technical or enterprisearchitect should be at least effective with all levels of tooling from beingable to monitor network traffic with Wireshark to modelling a complex financialmessage in XMLSpy - no level is too low or too high.

An architect usually comes with a good resume and impressive past, he canusually impress the business and technologists but unless he can demonstratehis ability to be hands-on it's difficult gain the respect of the team,difficult for the team to learn and almost impossible to deliver what they wereoriginally employed to do.

By http://commons.oreilly.com/wiki/index.php/User:JtdaviesJohn Davies

This work is licensed under a Creative CommonsAttribution 3

20、Continuously Integrate

The build as a "big bang"event in project development is dead. The architect, whether an application orenterprise architect, should promote and encourage the use of continuousintegration methods and tools for every project.

The term Continuous Integration (CI)was first coined by MartinFowler in a design pattern. CI refers to a set practices and tools thatensure automatic builds and testing of an application at frequent intervals,usually on an integration server specifically configured for these tasks. Theconvergence of unit testing practices and tools in conjunction with automatedbuild tools makes CI a must for any software project today.

Continuous Integration targets auniversal characteristic of the software development process – the integrationpoint between source code and running application. At this integration pointthe many pieces of the development effort come together and are tested. Youhave probably heard the phrase “build early and often”, which was a riskreduction technique to ensure there were no surprises at this point indevelopment. “Build early and often” has now been replaced by CI which includesthe build but also adds features that improve communication and coordinationwithin the development team.

The most prominent part of a CIimplementation is the build which is usually automated. You have the ability todo a manual build but they can also be kicked off nightly or can be triggeredby source code changes. Once the build is started the latest version of thesource code is pulled from the repository and the CI tools attempts to buildthe project then test it. Lastly, notification is sent out detailing theresults of the build process. These notifications can be sent in various formsincluding email or instant messages.

Continuous Integration will providea more stable and directed development effort. As an architect you will love itbut more importantly your organization and your development teams will be moreeffective and efficient.

By Dave Bartlett

This work is licensed under a Creative CommonsAttribution 3

21、Avoid Scheduling Failures

Failed projects can happen for a multitude of reasons. One of the mostcommon sources of failure is altering the project schedule in midstream(在中途)without proper planning. This kind of failure is avoidable, but it can requiremajor effort on the part of multiple people. Adjusting the time line orincreasing resources on a project are not normally（一般地）of concern（重要的）（不是一般地重要，也就是非常重要）.Problems start when you are asked to do more in the same time line or when theschedule is shortened without reducing the workload（工作量）.

The idea that schedules can be shortened in order to reduce cost or speed updelivery is a very common misconception(误解). You’ll commonly see attempts to requireovertime or sacrifice（牺牲） “less important scheduled tasks” (like unit-testing) as a way to reducedelivery dates or increase functionality while keeping the delivery dates as is（照原来的样子）. Avoidthis scenario at all costs. Remind those requesting the changes of thefollowing facts:

1.  A rushed（匆忙的） design schedule leads to poor design, bad documentation and probableQuality Assurance or User Acceptance problems.

2.  A rushed coding or delivery schedule has a direct relationship to thenumber of bugs delivered to the users.

3.  A rushed test schedule leads to poorly tested code and has a directrelationship to the number of testing issues encountered.

4.  All of the above lead to Production issues which are much more expensiveto fix.

The end result is an increase in cost as opposed to a reduction in cost（最后的结果是本来想降低成本却导致成本的增加）. This is normally why the failures happen.

As an Architect you will one day（总有一天） find yourself in the position of having to act quickly to increase the likelihood（可能性） of success.  Speak up（大声地说） early. First try tomaintain quality by negotiating the originally planned timeline. If a shortenedschedule is necessary then try to move non-critical functionality to futurerelease(s). Obviously this will take good preparation, negotiating skills and aknack（诀窍）for influencing people. Prepare by sharpening your skills in those areas today.You will be glad you did.

注：架构师面对中途改变计划时，一定要通过调整基线或者削减非关键功能去保证质量，这需要高超的协调技巧。

By NormanCarnovale

This work islicensed under a Creative Commons Attribution 3

22、Architectural Tradeoffs

Every software architect should knowand understand that you can't have it all. It is virtually（事实上） impossible to design anarchitecture that has high performance, high availability, a high level ofsecurity, and a high degree of abstraction all at the same time. There is atrue story which software architects should know, understand, and be able tocommunicate to clients and colleagues. It is the story of a ship called the Vasa（瓦萨号）.

In the 1620's Sweden（瑞典） and Poland（波兰） were at war. Wanting a quick end tothis costly war, the King of Sweden commissioned（授权） the building of a ship called the Vasa.Now, this was no（不是） ordinary（普通的） ship. The requirements for thisship were unlike any other ship of that time; it was to be over 200 feet long,carry 64 guns on two gun decks（甲板）, and have the ability to transport 300 troops（军队） safely across the waters intoPoland. Time was of the essence（极重要的）, and money was tight(sound familiar?). The ship architect had never designed such a ship before.Smaller, single gun deck ships were his area of expertise. Nevertheless（不过）, the ship's architect extrapolated（推断） on（基于）his prior experience and set out（开始） designing and building the Vasa. The ship waseventually built to specifications, and when the eventful（重要的） day came for the launch, the shipproudly sailed into the harbor（海港）, fired its gun salute（鸣礼炮）, and promptly（迅速地） sank to the bottom of the ocean.

The problem with the Vasa wasobvious; anyone who has ever seen the deck of a large fighting ship from the1600's and 1700's knows that the decks on those ships were crowded and unsafe,particularly in battle. Building a ship that was both a fighting ship and atransport ship was a costly mistake. The ship's architect, in an attempt tofulfill all of the kings wishes, created an unbalanced and unstable ship.

Software architects can learn a lotfrom this story and apply this unfortunate event to the design of softwarearchitecture. Trying to fulfill each and every requirement (as with the Vasa)creates an unstable architecture that essentially accomplishes nothing well. A goodexample of a tradeoff is the requirement to make a Service-OrientedArchitecture (SOA) perform as well as a point-to-point solution. Doing sousually requires you to bypass the various levels of abstraction created by anSOA approach, thereby（从而） creating an architecturethat looks something like what you would typically order at your local Italianrestaurant. There are several tools available to architects to determine whatthe tradeoffs should be when designing an architecture. Two popular methods arethe Architecture Tradeoff Analysis Method (ATAM) and the Cost BenefitAnalysis Method (CBAM). You can learn more about ATAM and CBAM by visitingthe Software Engineering Institute (SEI) websites at http://www.sei.cmu.edu/architecture/ata_method.htmland http://www.sei.cmu.edu/architecture/cbam.htmlrespectively.

 注：架构师在设计时要学会取舍，如果你什么都想实现结果是什么都实现不了。可以用ATAM和CBAM去决定怎么做权衡。

By Mark Richards

(Edited RMH 5/28/2008)

This work is licensed under a Creative CommonsAttribution 3

23、Database as a Fortress（堡垒）

The database is where all of thedata, both input by your employees and data collected from your customers,resides. User interfaces, business and application logic, and even employeeswill come and go, but your data lasts forever. Consequently, enough cannot besaid about the importance of building a solid data model from Day One.

The exuberance(生气勃勃) over agile techniqueshave left(留下了) many thinking that it’sfine, or even preferable, to design applications as you go. Gone are thedays of writing complex, comprehensive technical designs up front（一开始就写复杂设计的日子已经不再了）! The new school（学派） says deploy early and often. A lineof code in production is better than ten in your head. It seems almost too goodto be true, and where your data is concerned, it is.

While business rules and userinterfaces do evolve rapidly, the structures and relationships within the datayou collect often do not. Therefore, it is critical to have your data modeldefined right from the start, both structurally and analytically. Migratingdata from one schema to another in situ is difficult at best, time consumingalways, and error prone often. While you can suffer（忍受） bugs temporarily at the applicationlayer, bugs in the database can be disastrous（灾难性的）. Finding and fixing a data layer design problem does notrestore your data once it has been corrupted.

A solid data model is one thatguarantees security of today’s data, but also extensible for tomorrow’s.Guaranteeing security means being impervious to bugs that will – despite yourbest efforts – be pervasive（普遍深入的） in an ever-changing（经常改变的） application layer（不管你怎么努力，缺陷总是普遍深入经常发生变化的应用层，保证安全意味着不受这些缺陷的影响）. It means enforcingreferential integrity. It means building in domain constraints wherever theyare known. It means choosing appropriate keys that help you ensure your data’sreferential integrity and constraint satisfaction. Being extensible fortomorrow means properly normalizing your data so that you can easily addarchitectural layers upon your data model later. It means not taking shortcuts.

The database is the final gatekeeperof your precious data. The application layer which is, by design ephemeral（短暂的）, cannot be its own watchdog. Forthe database to keep proper guard, the data model must be designed to rejectdata that does not belong, and to prevent relationships that do not make sense.Keys, foreign key relationships, and domain constraints, when described in a schema are succinct（简洁的）, easy to understand and verify, andare ultimately self-documenting. Domain rules encoded the data model are alsophysical and persistent; a change to application logic does not wash them away.

To get the most out of a relationaldatabase – to make it a true part of the application as opposed to simply astorehouse for application data – you need to have a solid understanding ofwhat you are building from the start. As your product evolves, so too will thedata layer, but at each phase of its evolution, it should always maintain itsstatus as Fortress. If you trust it and bestow(给与) upon it the heavyresponsibility of trapping bugs from other layers of your application, you willnever be disappointed.

注：一开始就要把数据库设计好，易扩展，让它不受业务层的影响，把它作为最后的堡垒。

(RMH Edited 7/13/2008)

By Dan Chak

(Edited RMH 5/28/2008)

This work is licensed under aCreative Commons Attribution 3

24、Use uncertainty as a driver

Confronted with two options, mostpeople think that the most important thing to do is to make a choice betweenthem. In design (software or otherwise), it is not. The presence of two optionsis an indicator that you need to consider uncertainty（不确定性） in the design. Use the uncertaintyas a driver to determine where you can defer commitment to details and whereyou can partition（分类） and abstract to reducethe significance of design decisions. If you hardwire the first thing thatcomes to mind you're more likely to be stuck with（被...缠住无法摆脱） it, so that incidental（非主要的）decisions become significant and thesoftness of the software is reduced.

One of the simplest and mostconstructive definitions of architecture comes from GradyBooch: "All architecture is design but not all design is architecture.Architecture represents the significant design decisions that shape（塑造） a system, where significant ismeasured by cost of change." What follows from this is that aneffective architecture is one that generally reduces the significance of designdecisions(紧跟着上面的是，一个有效的架构是一个可以降低设计决定重要性的架构). An ineffectivearchitecture will amplify（扩大） significance.

When a design decision canreasonably go one of two ways, an architect needs to take a step back. Insteadof trying to decide between options A and B, the question becomes "How doI design so that the choice between A and B is less significant?" The mostinteresting thing is not actually the choice between A and B, but the fact thatthere is a choice between A and B (and that the appropriate choice is notnecessarily obvious or stable).

An architect may need to go incircles before becoming dizzy（晕眩的） and recognizing（认可） the dichotomy（二分法）. Standing at whiteboard (energetically（积极地）) debating options with a colleague?Ummingand ahhing（唧唧歪歪） in front of some code,deadlocked over whether to try one implementation or another? When a newrequirement or a clarification of a requirement has cast doubt on（对...产生怀疑） the wisdom of a currentimplementation, that's uncertainty. Respond by figuring out（计算出）what separation or encapsulationwould isolate that decision from the code that ultimately depends on it.Without this sensibility（敏感性） the alternative responseis often rambling(蔓延) code that, like anervous interviewee, babbles(喋喋不休) away trying tocompensate for uncertainty with a multitude of speculative(投机的) and general options. Or,where a response is made with arbitrary but unjustified(未被证明其正确的) confidence, a wrong turnis taken at speed（飞快地） and without looking back（倒退）.

There is often pressure to make adecision for decision's sake(缘故). This is where options thinking can help. Where there isuncertainty over different paths a system's development might take, make thedecision not to make a decision. Defer the actual decision until a decision canbe made more responsibly(可靠地), based on actualknowledge, but not so late that it is not possible to take advantage of theknowledge.

Architecture and process are interwoven（交织）, which is a key reason thatarchitects should favor development lifecycles and architectural approachesthat are empirical（完全根据经验的） and elicit（得出）feedback, using uncertainty constructivelyto divide up both the system and the schedule.

注：当面对选择的时候，最有效的架构就是后退一步，通过分割或封装让选择变得不重要。

By Kevlin Henney

(Edited RMH 2008-05-28,re-edited KH 2008-07-02, edited-again 2008-07-12)

This work is licensed under a Creative CommonsAttribution 3

25、Scope is the enemy of success

Scope refers to a project's size. How much time, effort, and resources?What functionality at what level of quality? How difficult to deliver? How muchrisk? What constraints exist? The answers define a project's scope. Softwarearchitects love the challenge of big, complicated projects. The potential rewardscan even tempt people to artificially expand a project’s scope to increase itsapparent importance. Expanding scope is the enemy of success because theprobability of failure grows faster than expected. Doubling a project’s scopeoften increases its probability of failure by an order of magnitude.

Why does it workthis way? Consider some examples:

·   Intuition tells us todouble our time or resources to do twice as much work. History[1] says impactsare not as linear as intuition suggests. For example, a four person team willexpend more than twice the communication effort as a team of two.

·   Estimation is far from anexact science. Who hasn’t seen features that were much harder to implement thanexpected?

Of course, someprojects aren’t worth doing without some built-in size and complexity. While atext editor without the ability to enter text might be easy to build, itwouldn’t be a text editor. So, what strategies can help to reduce or managescope in real-world projects?

·   Understand the real needs– The capabilities a project must deliver are a set of requirements.Requirements define functionality or qualities of functionality. Question anyrequirements not explained in terms of measurable value to the customer. If ithas no effect on the company’s bottom line, why is it a requirement?

·   Divide and conquer – Lookfor opportunities to divide up the work into smaller independent chunks. It iseasier to manage several small independent projects than one large project withinterdependent(相互依赖的) parts.

·   Prioritize – The world ofbusiness changes rapidly. Large projects’ requirements change many times beforethey’re completed. Important requirements usually remain important as thebusiness changes while others change or even evaporate（消失）. Prioritization lets you deliver the most important requirements first.

·   Deliver results as soon aspossible – Few people know what they want before they have it. A famous cartoonshows the evolution of a project to build a child’s swing based on what thecustomer said and what various roles in the project understood. The complicatedresult only faintly resembles a swing. The last panel, titled “What would haveworked”, shows a simple swing using an old tire. When the customer hassomething to try, the solution may be simpler than expected. Building the mostimportant things first gets you the most important feedback early, when youneed it most.

Agile advocates（提倡）[2] exhort（忠告） us to build "Thesimplest thing that could possibly work". Complex architectures fail farmore often than simpler architectures. Reducing project scope often results ina simpler architecture. Scope reduction is one of the most effective strategiesan architect can apply to improve the odds（几率） of success.

注：架构师要把握真实需求，尽量控制项目的范围。

By Dave Quick

[1] See "TheMythical Man-Month" by Fred Brooks

[2] See"eXtreme Programming eXplained" by Kent Beck

This work islicensed under a Creative Commons Attribution 3

26、Reuse is about people and education, not just architecture

You might adopt the approach that aframework that is well designed, or an architecture that is carefullyconsidered, and cleverly implemented will lend itself to re-use within yourorganization. The truth is that even the most beautiful, elegant and re-usablearchitecture, framework or system will only be re-used by people who:

a) know it is there

b) know how to use it

c) are convinced that it is betterthan doing it themselves

a) Know its there

Within your organization, developersor designers need to know a design, framework, library, or fragments of codeexists and where they can find all the critical information about theseelements (e.g. documentation, versions, and compatibility) in order to reusethem. It is a simple, logical truth that people won't look for things that theydon't believe to exist. You are more likely to succeed with reusable elementsif the information about them is “pushed”.

There are any number of methods forpushing information about reusable elements in an organization. These rangefrom wiki pages with an RSS feed providing update information, useful in verylarge teams, to e-mail announcing version updates in the source repository. Ina tiny team, the designer or lead developer can inform his colleagues inpersonal conversations or shouting it across the office. Ultimately, whateveryour process for communicating about reusable elements... make sure you haveone, don’t leave it up to chance.

b) Know how to use it

Understanding how to reuse anelement depends on skills and training. Of course there are those people who(to use Donald Knuth’s terminology) "resonate（共鸣）" with coding and design. Wehave all worked with them, the gifted（有天才的） developers and architects whose speed and depth ofunderstanding is impressive, even scary. But these people are rare. The rest ofyour team might be made up of good, solid, intelligent developers anddesigners. They need to be taught.

Developers and designers might notknow of the particular design pattern used in a design, or fully understand theinheritance model that the framework designer intended them to use. They needto be given easy access to that information in the form of up-to-datedocumentation, or even better, training. A little training goes a long way toensuring that everyone is on the same page when it comes to reuse.

c) Are convinced that its betterthan doing it themselves

People, and particularly developers,tend to prefer to solve problems themselves rather than ask for help. Askinghow something works is a sign of weakness, or even an indication of ignorance.This has a lot to do with the maturity and personality type of your individualteam-members, “Better than doing it themselves” means different things todifferent people. The “young guns” on your team will always want to writethings themselves because it appeases their ego（自负）, whereas your more experiencedpeople are more likely to accept that someone else has given thought to theproblem domain and has something to offer in terms of a solution.

If your team doesn’t know where tofind reusable artifacts or how to reuse them they will default to the natural,human position: they will build it themselves. And you will pay for it.

注：架构师要别人知道有可重用的东西，怎样重用，让别人确信重用比自己重新实现的更好。

(RMH Edited 7/13/2008)

By Jeremy Meyer(Edited RMH 5/28/2008)

This work is licensed under a Creative CommonsAttribution 3

27、There is no 'I' in architecture

I know, there really is an ‘i’ inarchitecture. But it’s not a capital ‘I’, calling attention to（唤起注意） itself, dominating discussion. Thelower-case character fits neatly within the word. It’s there only because itfulfills requirements for proper spelling and pronunciation.

How does that relate to us assoftware architects? Our egos(自负) can be our own worst enemy. Who hasn’t experiencedarchitects who:

• Think they understand the requirements better than the customers.
• View developers as resources hired to implement their ideas.
• Get defensive when their ideas are challenged or ignore the ideas of others.

I suspect any experienced architecthas fallen into at least one of these traps at some point. I’ve fallen into allof them and learned painful lessons from my mistakes.

Why does this happen?

• We’ve had success – Success and experience build self-confidence and allow us to become architects. Success leads to bigger projects. There is a fine line between self-confidence and arrogance（自大）. At some point the project is bigger than our personal ability. Arrogance sneaks in（渐显） when we cross that line but don’t know it yet.
• People respect us – Tough design questions provide a critical safety net. Our own defensiveness, arrogance, or emphasis on our experience can result in missed design questions.
• We’re human – Architects pour（灌注） themselves into each design. Criticism（批判） of your creation feels like criticism of you. Defensiveness is easy. Learning to stop it is hard. Pride in our accomplishments is easy. Recognizing our limitations without conscious effort is hard.

How do we avoid it?

• Requirements don’t lie - With correct, complete requirements, any architecture that meets them is a good one. Work closely with the customer to make sure you both understand the business value each requirement provides. You don’t drive the architecture, the requirements do. You do your best to serve their needs.
• Focus on the team –These are not just resources; they are your design collaborators and your safety net. People who feel unappreciated usually make a poor safety net. It’s the teams’ architecture, not yours alone. You provide guidance but everyone does the heavy lifting together. You need their help as much or more than they need yours.
• Check your work – The model is not the architecture. It is only your understanding of how the architecture should work. Work with your team to identify tests that demonstrate how the project’s architecture supports each requirement.
• Watch yourself – Most of us fight our natural tendencies（倾向） to defend our work, focus on our selfish interests, and see ourselves as the smartest person in the room. Pressure pushes these tendencies to the surface. Consider your interactions for a few minutes every day. Did you give everyone’s ideas the respect and acknowledgement they deserved? Did you react negatively to well meaning input? Do you really understand why someone disagreed with your approach?

Removing the ‘I’ from architecturedoesn’t guarantee success. It just removes a common source of failure that’sentirely your fault.

By Dave Quick

Thiswork is licensed under a Creative CommonsAttribution 3

28、Get the 1000ft（英尺） view

As an architect we want to know howgood the software is that we are developing. Its quality has an obviousexternal aspect, the software should be of value to its users, but there isalso a more elusive（难捉摸的） internal aspect toquality, to do with the clarity of the design, the ease with which we canunderstand, maintain, and extend the software. When pressed for a definition,this is where we usually end up saying "I know it when I see it." Buthow can we see quality?

In an architecture diagram littleboxes represent entire systems and lines between them can mean anything: adependency, the flow of data, or a shared resource such as a bus. Thesediagrams are a 30.000ftview, like a landscape seen from a plane. Typically the only other viewavailable is the source code, which is comparable to a ground level view. Bothviews fail to convey much information about the quality of the software, one istoo high level and the other provides so much information that we cannot seestructure. Clearly, what is missing is a view in between, a 1000ft view.

This 1000ft view would provide information at the rightlevel. It aggregates large amounts of data and multiple metrics, such as methodcount, class fan out, or cyclomatic complexity. The actual view very muchdepends on a specific aspect of quality. It can be a visual representation of adependency graph, a bar chart that shows metrics at a class level, or asophisticated polymetric view that correlates multiple input values.

Manually creating such views andkeeping them in sync with the software is a hopeless endeavor. We need toolsthat create these views from the only true source, the source code. For someviews, a design structure matrix for example, commercial tools exists but it isalso surprisingly easy to create specialized views by combining small toolsthat extract data and metrics with generic visualization packages. A simpleexample would be to load the output from checkstyle, which is essentially a setof metrics on the class and method level, into a spreadsheet to render charts.The same metrics could also be shown as a tree-map using the InfoViz toolkit. Agreat tool to render complex dependency graphs is GraphViz.

Once a suitable view is availablesoftware quality becomes a little less subjective. It is possible to comparethe software under development with a handful of similar systems. Comparingdifferent revisions of the same system will give an indication of trends whilecomparing views of different subsystems can highlight outliers. Even with justa single diagram we can rely on our ability to spot patterns and perceiveaesthetics. A well-balanced tree probably represents a successful classhierarchy, a harmonious（协调的） set of boxes might showcode that is organized into appropriately sized classes. Most of the time avery simple relationship holds: If it looks good it probably is good.

(RMH Edited 7/11/2008)

By Erik Doernenburg

This work is licensed under a Creative CommonsAttribution 3

29、Try before choosing

Creating an application requiresmany decisions to be made. Some might involve choosing a framework or librarywhile others revolve around the use of specific design patterns. In either casethe responsibility for the decision generally lies with（在于） the architect on the team. A stereotypical（典型的） architect might gather all theinformation that can be gathered, then mull（深思） over it for a while, and finally decree（颁布） the solution from the ivory towerfor it to be implemented by the developers. Not surprisingly there is a betterway.

In their work on lean developmentMary and Tom Poppendieck describe a technique for making decisions. They arguethat we should delay commitment until the last responsible moment, that is themoment at which, if the team does not make a decision, it is made for them;when inaction results in an outcome that is not (easily) reversible（可逆的）. This is prudent（谨慎的） because the later a decision ismade the more information is available on which to base the decision. However,in many cases more information is not the same as enough information, and wealso know that the best decisions are made in hindsight（事后）. What does this mean for the goodarchitect?

The architect should constantly be on the lookout（警惕） for decisions that will have to bemade soon. Provided the team has more than a handful of developers andpractices collective（集体的） code ownership thearchitect can, when such a decision point approaches, ask several developers tocomeup with（提出） a solution to theproblem and go with（伴随） it for a while. As thelast responsible moment arrives the team gets together and assesses the benefitsand drawbacks of the different solutions. Usually, now with the benefit ofhindsight, the best solution to the problem is apparent to everybody. Thearchitect does not have to make the decision, he or she merely orchestrates（组织） the decision making process.

This approach works for smalldecisions as well as for large ones. It can allow a team to figure out（解决） whether or not to use the Hibernatetemplates provided by the Spring framework but it can equally answer thequestion of which JavaScript framework to use. The duration for which thedifferent approaches evolve is obviously very dependent on the complexity ofthe decision.

Trying two or even more approachesto the same problem requires more effort than making a decision upfront andthen just implementing one. However, chances are that an upfront decision leadsto a solution that is later recognized to be sub-optimal（次优的）, leaving the architect with adilemma: either the team rolls back the current implementation or they livewith the consequences, both of which result in wasted effort. Even worse, it isentirely possible that nobody on the team recognizes that the approach chosenis not the best one, because none of the alternatives were explored. In thiscase effort is wasted without any chance of addressing the waste. After all,trying multiple approaches might be the least expensive option.

注：架构师应该是组织开发者各自提出自己对问题的解决办法，然后大家评估最好的一个。

(RMH Edited 7/10/2008)

By Erik Doernenburg

This work is licensed under a Creative CommonsAttribution 3

30、Understand The Business Domain

Effective software architectsunderstand not only technology but also the business domain of a problem space.Without business domain knowledge, it is difficult to understand the businessproblem, goals, and requirements, and therefore difficult to design aneffective architecture to meet the requirements of the business.

It is the role of the softwarearchitect to understand the business problem, business goals, and businessrequirements and translate those requirements into a technical architecturesolution capable of meeting those requirements. Knowing the business domainhelps an architect decide which patterns to apply, how to plan for future extensibility,and how to prepare for ongoing industry trends. For example, some businessdomains (e.g., Insurance) lend themselves well to a Service-orientedarchitecture approach where as other business domains (e.g. Financial Markets)lend themselves more towards a workflow-based architecture approach. Knowingthe domain helps you decide which architecture pattern may work best to satisfythe specific needs of the organization.

Knowing the industry trends of aspecific domain can also help a software architect in designing an effectivearchitecture. For example, in the insurance domain, there is an increasingtrend towards "on-demand" auto insurance, where you only pay for autoinsurance when you actually drive your car. This type of insurance is great ifyou park your car at the airport on Monday morning, fly off to your workdestination, and return Friday to drive back home. Understanding such industrytrends enable you as a software architect to plan for these trends in thearchitecture, even if the company you are working with hasn't planned for themyet as part of their business model.

Understanding the specific goals ofthe business also helps you design an effective architecture. For example, dothe goals of the particular business you are working for include non-organicgrowth through heavy mergers and acquisitions? The answer to this question mayinfluence the type of architecture you design. If the answer is yes, thearchitecture might include many layers of abstraction to facilitate the mergingof business components. If the goals of the business include increased marketshare through a heavy online presence, then high availability is most likelygoing to be a very important attribute. As a software architect, alwaysunderstand the goals of the company you are working with, and validate that thearchitecture can support these goals.

The most successful architects Iknow are those who have broad hands-on（容易地） technical knowledge coupled with a strong knowledge of aparticular domain. These software architects are able to communicate withC-level executives and business users using the domain language that thesefolks know and understand. This in turn creates a strong level of confidencethat the software architect knows what he or she is doing. Knowing the businessdomain allows a software architect to better understand the problems, issues,goals, data, and processes, which are all key factors when designing aneffective enterprise architecture.

注：架构师不单需要掌握技术，还必须理解业务，否则很难设计出满足需求的架构。

By Mark Richards

This work is licensed under a Creative CommonsAttribution 3

31、Programming is an act of design

Kristen Nygaard, father ofobject-oriented programming and the Simula programming language, used to say:Programming is learning. Accepting the fact that programming or more preciselysoftware development is a processes of discovery and learning and not a processof engineering and construction are fundamental to bring software practicesforward. Applying the concepts of traditional engineering and construction onsoftware development does not work. The problems have been documented andcommented upon by leading software thinkers for more than 30 years. As anexample, In 1987 Fredric Brooks JR stated in the "Report of the DefenseScience Board Task Force on Military Software" that the document driven,specify-then-build approach lies at the heart of so many software problems.

So where should the softwareindustry go and look for improving their practices? What about the industriesinvolved in production of sophisticated mass-market products such as cars,pharmaceutical drugs or semiconductors?

Lets take a look at the carindustry. When planning a new model, the first thing is to choose a concept or archetype（原型）. It’s primarily an architecturalpositioning mechanism. BMW X6 is an example of a new concept that combines theproperties of a SUV and a Coupe into what BMW calls a Sports Activity Coupe.The thing is that before you can purchase a new X6, BMW has invested thousandsof hours and millions of dollars in both its vehicle and manufacturing design.When BMW receives your order, one of their assembly lines will kick in andproduce your customized version of the X6.

So what is the lesson learned fromthis carmaker scenario? The important lesson is that the making of a new carinvolves two processes: The first process is the creative design process,including establishing the required assembly lines. The second process is themanufacturing of cars in line with customer specification. In many ways theseare the processes we find in the software industry as well. The challenge iswhat we put into the terms.

In the article “What is softwaredesign?” Jack Reeves suggested that the only artifact of software engineeringthat satisfied the criteria for a design document, as such document isunderstood and used in classical engineering, is the source code. Themanufacturing of the software is automated and taken care of by the compiler,build and test scripts.

By accepting that carving out sourcecode is an act of design, not an act of construction we are in a position toadopt useful management practices that are proven to work. Those are thepractices used to manage creative and unpredictable work such as developing anew car, a new medical drug or a new computer game. We talk about the practicesof agile product management and lean production such as SCRUM. These practicesfocus on maximizing return-on-investment in terms of customer value.

For the software industry to capitalize on（利用） these practices we must remember:Programming is an act of design, not an act of construction.

 (RMH Edited 7/13/2008)

By Einar Landre

This work is licensed under a Creative CommonsAttribution 3

32、Time changes everything

One of the things I've been most entertained by as the years have gone by,is observing what things have lasted and what haven't. So many patterns,frameworks, paradigm changes, and algorithms, all argued for with passion bysmart people, thinking of the long term, balancing all the known issues, havenot warranted more than a yawn over the long haul. Why? What is history tryingto tell us?

Picka worthy challenge

This one is trickyfor a software architect. Challenges or problems are given to us, so we don'thave the luxury of choosing, right? It's not that simple. First of all we oftenmake the mistake of believing that we can't influence what we are asked to do.Usually we can, but it gets us out of our comfort zone in the technology space.There are dragons there when we don't choose to do the right things. Timepasses, we have worked diligently and hard solving the requested challenge, andin the end it doesn't matter: we didn't do what was really needed and our workis wasted. Over time, a good solution to the right challenge will probablyoutlast all others.

Simplerules

We say it toourselves: keep it simple stupid. We say it but we don't do it. We don't do itbecause we don't have to. We are smart and we can handle some complexity andeasily justify it because it adds agility to our design, because it is moreelegant to our aesthetic sensibilities, because we believe we can anticipatethe future. Then time passes, you walk away from the project for a year ormore. When you come back look at it, you almost always wonder why you did whatyou did. If you had to do it all over again, you would probably do itdifferently. Time does this to us. It makes us look silly. It is good torealize this early and get over yourself, and really try to learn what simplemeans in the lens that only time can grind.

Behappy with that old stuff

Architects love tosearch for the “one true way”, the methodology, or school of thought thatprovides the predictability we crave and the clear answers that always seemjust out of reach. The problem is that whatever guiding light you have in oneyear will probably not match the guiding light you have in a couple of years,much less a decade later. As you look back, you will always be looking atdesigns that don't match your current expectations. Learn to embrace that oldstuff, and resist the temptation to think you should go back and “fix” it. Wasthe solution an appropriate one for the problem? Did it solve the needs of theproblem? Keep these as your measure, you will be a lot happier. 

By Philip Nelson

This work is licensed under a Creative Commons Attribution 3

33、Give developers autonomy

Most architects begin their careeras developers. An architect has new responsibilities and greater authority indetermining how a system is built. You may find it difficult to let go of（释放） what you did as a developer in yournew role as an architect. Worse, you may feel it's important for you toexercise a lot of control over how developers do their work to implement thedesign. It will be very important to your success and your team's success togive all of your teammates enough autonomy to exercise their own creativity andabilities.

As a developer you rarely get the time to sit back and really look at how thewhole system fits together. As an architect, this is your main focus. Whiledevelopers are furiously（猛烈地） building classes,methods, tests, user interfaces and databases, you should be making sure thatall those pieces work well together. Listen for points of pain and try toimprove them. Are people are having trouble writing tests? Improve theinterfaces and limit dependencies. Do you understand where you actually needabstraction and where you don't? Work for domain clarity. Do you know whatorder to build things in? Build your project plan. Are developers consistentlymaking common mistakes using an API you designed? Make the design more obvious.Do people really understand the design? Communicate and make it clear. Do youreally understand where you need to scale and where you don't? Work with yourcustomer and learn their business model.

If you're doing a great job of being an architect, you really shouldn't haveenough time to interfere with developers. You do need to watch closely enoughto see that the design is being implemented as intended. You do not need to bestanding over people's shoulders to accomplish that goal. It's reasonable tomake suggestions when you see people struggling, but it's even better if youcreate the environment where they come and ask you for suggestions. If you aregood, you will deftly（灵巧地） walk the fine linebetween guaranteeing a successful architecture and limiting the creative andintellectual life of your developers and teammates.

注：架构师要给开发者足够的自治权。

By Philip Nelson

This work is licensed under a Creative CommonsAttribution 3

34、Value stewardship（工作） over showmanship

When an architect enters a project,there is an understandable desire to prove one's worth. Being assigned the roleof software architect typically indicates implicit trust on the part of thecompany in architect's technical leadership, and it only follows that thearchitect would desire to make good on that expectation as soon as possible.Unfortunately, there are those who labor under the misapprehension that provingone's worth consists of showmanship; bedazzling（使困惑）ifnot（否则） baffling（困惑） the team with one's technical brilliance（光辉）.  

Showmanship（演出技巧）, the act of appealing to（有吸引力） your audience, is important inmarketing, but it's counter productive to leading a software developmentproject.  Architects must win the respect of their team by providing solidleadership and by truly understanding the technical and business domain inwhich they are expected to operate.  

Stewardship（工作）, taking responsibility and care ofanother’s property, is the appropriate role of an architect.  An architectmust act in the best interests of their customer and not pander to（迎合） the needs of their own ego.

Software architecture is about serving the needs of one's customers, typicallythrough direction from those with domain expertise that surpasses one's own.Pursuing successful software development will lead one to create solutions ofcompromise, balancing the cost and complexity of implementation against thetime and effort available to a project. That time and effort are the resourcesof the company, which the software architect must steward（管理） without self-serving（自私的） undercurrents（潜流）. Unduly（过度地） complex systems that sport the latest hot framework ortechnology buzzword（时髦词语） seldom do so withoutsome sacrifice at the company's expense. Much like an investment broker, thearchitect is being allowed to play with their client's money, based on thepremise that their activity will yield an acceptable return on investment.

Value stewardship over showmanship; never forget that you are playing withother peoples' money.

By Barry Hawkins

This work is licensed under a Creative CommonsAttribution 3

35、

36、The title of software architect has only lower-case 'a's; deal withit

A disappointing trend has been inbloom for some time now within software development; the attempt toprofessionalize the practice of software architecture as one on par with theclassical school of Architecture. Thisseems to stem from some need for further legitimization of one's accomplishmentbeyond acknowledgment among one's peers and employer. By comparison,Architecture itself was not professionalized until the late 19th century, atleast a few millennia after the practice had been around. It would be no greatstretch to say that some software architects seem a bit eager by comparison.

Software architecture is a craft,and it certainly takes practice and discipline to achieve success in the field.That said, software development is still a relatively nascent endeavor. Wedon't even know enough about this practice to adequately professionalize it.Despite its youth, software development's product has become a highly valued tool,and as such, the accomplished individuals (as well as those who wish to be seenas accomplished) have enjoyed levels of compensation on par with the leadingprofessional fields, including medicine, accounting, and law.

Practitioners of software developmentenjoy considerable compensation for work that is highly creative andexploratory. The fruits of our labors have been used to accomplish manysignificant milestones, some that benefit all of mankind. The barriers to entryare largely one's own merit and opportunity; the fully-professionalized fieldsundergo programs of study and internship that dwarf our own. Dwell on that fora moment and ponder how much cause we have to be content, and just how brash itis to insist that software architect be considered a title that sits as peer toLawyer, Doctor, and Architect.

The title of software architect hasonly lower-case 'a's; deal with it.

By Barry Hawkins

This work is licensed under a Creative CommonsAttribution 3

37、Software architecture has ethical（道德的） consequences（结果）

The ethical dimension in software isobvious when we are talking about civil rights, identity theft, or malicious(怀恶意的) software. But they arisein less exotic(外来的) circumstances. Ifprograms are successful, they affect the lives of thousands or millions ofpeople. That impact can be positive or negative. The program can make theirlives better or worse--even if just in minute(极小的) proportions（比例）.

Every time I make a decision abouthow a program behaves, I am really deciding what my users can and cannot do, inways more inflexible than law. There is no appeals court for required fields ormandatory workflow.

Another way to think about it is interms of multipliers. Think back to the last major Internet worm, or when a biggeek movie came out. No doubt, you heard or read a story about how muchproductivity this thing would cost the country. You can always find someanalyst with an estimate of outrageous（可恶的） damages, blamed on anything that takes people away fromtheir desks. The real moral of this story isn't about innumeracy（科学盲） in the press, or self-aggrandizingaccountants. It's about multipliers, and the effect they can have.

Suppose you have a decision to makeabout a particular feature. You can do it the easy way in about a day, or thehard way in about a week. Which way should you do it? Suppose that the easy waymakes four new fields required, whereas doing it the hard way makes the programsmart enough to handle incomplete data. Which way should you do it?

Required fields seem innocuous（无伤大雅的）, but they are always an impositionof your will on users. They force users to gather more information beforestarting their jobs. This often means they have to keep their data on Post-Itnotes until they've got everything together at the same time, resulting in lostdata, delays, and general frustration.

As an analogy, suppose I'm putting asign up on my building. Is it OK to mount the sign just six feet up on thewall, forcing pedestrians（步行者） to duck or go around it?It's easier for me to hang the sign if I don't need a ladder and scaffold（脚手架）, and the sign wouldn't even blockthe sidewalk（人行道）. I get to save an hourinstalling the sign, at the expense of taking two seconds away from everypedestrian passing my store. Over the long run, all of those two seconddiversions are going to add up to many, many times more than the hour that Isaved.

It's not ethical to worsen the livesof others, even a small bit, just to make things easy for yourself. Successfulsoftware affects millions of people. Every decision you make imposes your willon your users. Always be mindful of the impact your decisions have on thosepeople. You should be willing to（乐于） bear large burdens to ease theirs.

By Michael Nygard

This work is licensed under a Creative CommonsAttribution 3

38、Everything will ultimately failv

Hardware is fallible, so we addredundancy. This allows us to survive individual hardware failures, butincreases the likelihood of having at least one failure present at any giventime.

Software is fallible. Ourapplications are made of software, so they're vulnerable to failures. We addmonitoring to tell us when the applications fail, but that monitoring is madeof more software, so it too is fallible.

Humans make mistakes; we arefallible also. So, we automate actions, diagnostics, and processes. Automationremoves the chance for an error of comission, but increases the chance of anerror of omission. No automated system can respond to the same range ofsituations that a human can.

Therefore, we add monitoring to theautomation. More software, more opportunities for failures.

Networks are built out of hardware,software, and very long wires. Therefore, networks are fallible. Even when theywork, they are unpredictable because the state space of a large network is, forall practical purposes, infinite. Individual components may actdeterministically, but still produce essentially chaotic behavior.

Every safety mechanism we employ tomitigate one kind of failure adds new failure modes. We add clustering softwareto move applications from a failed server to a healthy one, but now we risk"split-brain syndrome" if the cluster's network acts up.

It's worth remembering that the Three Mile Island accident was largely caused by apressure relief value---a safety mechanism meant to prevent certain types ofoverpressure failures.

So, faced with the certainty offailure in our systems, what can we do about it?

Accept that, no matter what, yoursystem will have a variety of failure modes. Deny that inevitability, and youlose your power to control and contain them. Once you accept that failures willhappen, you have the ability to design your system's reaction to specificfailures. Just as auto engineers create crumple zones---areas designed toprotect passengers by failing first---you can create safe failure modes thatcontain the damage and protect the rest of the system.

If you do not design your failuremodes, then you will get whatever unpredictable---and usually dangerous---oneshappen to emerge.

By Michael Nygard

This work is licensed under a Creative CommonsAttribution 3

39、Context is King

I feel there is a certain irony intrying to impart something about architectural ideals, when the very premise Iwish to begin with is that effectively there are no ideals. If this isindeed the case, then surely there is nothing to write, I am a contradictionand by doing this I run the risk of the universe imploding or something likethat.

But alas, ceci n'est pas unepipe.

One of the most valuable lessonsthat I have learned as a software architect is that context is king, and simplicityits humble servant. What this means in practical terms is that context is theonly force that trumps simplicity when making architectural decisions.

When I say context, I refer not onlyto high-level, immediate forces such as key business drivers, but also toelements in the periphery, such as emerging technologies and thought leadershipon diverse topics. Indeed, good architects keep track of several fast-movingtargets.

What constitutes good architecture?It is the product of decisions made within a context usually tainted withmultiple competing priorities. Those competing priorities mean that sometimesthe most important decisions are not about what you put in, but rather what youomit. The currency of good architecture is simply astute decision-making (whilethe products are all only about communicating your intent).

Historically, there have been somefascinating examples of the influence that context can have on architecture. Afavorite example involves the database selected to support an ambitious newsoftware system for a modern battlefield tank [1]. (Deciding what database touse is not usually architecturally significant; this example merely serves toillustrate a point).

When it came time to choose thedatabase, the team assessed many. They found that while the tank was movingquickly over undulating terrain while tracking a target, the majority of thedatabases were capable of supporting this maximal throughput required of thenavigation and targeting systems. But they were taken by surprise when theydiscovered that firing the main gun on the tank caused such a strongelectromagnetic pulse that it totally crashed the on-board systems and ofcourse the database along with it! On a modern battlefield, a tank without itssoftware running is quite literally in the dark. In this context, recoverytime was the overwhelming factor in the choice of database, and no databasedid that better at the time than InterBase [2], and that is why it was chosenfor the M1 Abrams tank.

So, while newsgroups rage with theflames of technology debates of X vs Y, it is idle amusement. The reason thesedebates rage is often not because of huge disparities in their technicalmerits, but rather because there are more subtle differences between them, andwhat features individuals value more than others when there is no guiding contextto act as a trump card.

Your team should be free of ideals,reflect on context in the first instance, and reach for the simplest solutionsfrom there.

By Edward Garson

This work is licensed under a Creative CommonsAttribution 3

Footnotes

[1] - A tank, despite its extremelydubious purpose, is still an engineering marvel.

[2] - Interestingly, InterBase hadan architecture that caused disk-writes to leave the database in analways-consistent state. This is one reason that contributes to its ability torecover from hard failures so quickly.

40、It's all about performance

Imagine a personal vehicle that isroomy, comfortable, fuel efficient, inexpensive to produce, and 98% recyclable.You want one? Sure. Everyone does. Just one problem: Its top speed is 6miles/hour (10 km/hour).Still want one? This small example demonstrates that performance is just asimportant as any other criterion.

The reason many designers putperformance at the bottom of their lists might be that computers are so muchfaster at computation than their human counterparts, that they assume that thespeed of the system will be acceptable. And if today's systems aren't fastenough, Moore'sLaw will take care of everything. But hardware speed is only part of thesystem.

Performance is sometimes thought ofas a simple measurement of the time it takes for a system to respond to userinput. But system designers must consider many aspects of performance,including performance of the analysts and programmers who implement the design;performance of the human interactions of the system; and performance of thenon-interactive components.

Performance of the people buildingthe system is often called productivity, and it is important because itdirectly affects the cost and schedule of the project. A team that delivers aproject late and over budget has a lot of 'splainin' to do. Using tools andpre-built components can dramatically affect how quickly the system can bebuilt and start returning value.

Performance of the humaninteractions is critical to acceptance of the system. Many factors of systemdesign contribute to this aspect of performance, response time being perhapsthe most obvious. But response time is not the only factor. Just as importantare intuitiveness of the interface and number of gestures required to achieve agoal, both of which directly affect performance.

More than response time per se, agood system specification will measure task time, defined as the time requiredto complete a domain-specific task, including all human interactions with thesystem. In addition to system response time, this measurement includes operatorthink time and operator data entry time, which are not under the control of thesystem. But including these times gives motivation to the proper design of thehuman interface. Proper attention to the way information is presented and thenumber of gestures required to complete the task will result in better humanoperational performance.

Performance of the non-interactivecomponents is equally important to the success of the system. For example, a "nightly"batch run that takes more than 24 hours to complete will result in an unusablesystem. Performance of the disaster recovery component is also a criticalconsideration. In case of total destruction of one part of the system, howquickly can operational status be restored, in order to allow normal businessto resume?

When considering the implementationand operation of a successful system, architects and designers should alwayspay careful attention to performance.

(RMH Edited 7/2/2008)

By Craig L Russell

This work is licensed under a Creative CommonsAttribution 3

41、Engineer in the white spaces

A system consists of interdependentprograms. We call the arrangement of these programs and their relationships"architecture". When we diagram these systems, we often representindividual programs or servers as simplistic little rectangles, connected byarrows.

One little arrow might mean,"Synchronous request/reply using SOAP-XML over HTTP." That's quite alot of information for one glyph to carry. There's not usually enough room towrite all that, so we label the arrow with either "XML overHTTP"---from an internal perspective---or "SKU Lookup"---for theexternal perspective.

That arrow bridging programs lookslike a direct contact, but it isn't. The white space between the boxes isfilled with hardware and software components. This substrate may contain:

   * Network interface cards
   * Network switches
   * Firewalls
   * IDS and IPS
   * Message queues or brokers
   * XML transformation engines
   * FTP servers
   * "Landing zone" tables
   * Metro-area SoNET rings
   * MPLS gateways
   * Trunk lines
   * Oceans
   * Cable-finding fishing trawlers

There will always be four or fivecomputers between program A and B, running their software for packet switching,traffic analysis, routing, threat analysis, and so on. As the architectbridging between those programs, you must consider this substrate.

I saw one arrow labeled"Fulfillment". One server was inside my client's company, the otherserver was in a different one. That arrow, critical to customer satisfaction,unpacked to a chain of events that resembled a game of "Mousetrap"more than a single interface. Messages went to message brokers that dumped tofiles, which were picked up by a periodic FTP job, and so on. That one"interface" had more than twenty steps.

It's essential to understand thatstatic and dynamic loads that arrow must carry. Instead of just "SOAP-XMLover HTTP", that one little arrow should also say, "Expect one queryper HTTP request and send back one response per HTTP reply. Expect up to 100requests per second, and deliver responses in less than 250 milliseconds99.999% of the time."

There's more we need to know aboutthat arrow.

   * What if the caller hits it too often? Should the receiver drop requests on the floor, refuse politely, or make the best effort possible?
   * What should the caller do when replies take more than 250 milliseconds? Should it retry the call? Should it wait until later, or assume the receiver has failed and move on without that function?
   * What happens when the caller sends a request with version 1.0 of the protocol and gets back a reply in version 1.1? What if it gets back some HTML instead of XML?  Or an MP3 file instead of XML?
   * What happens when one end of the interface disappears for a while?

Answering these questions is theessence of engineering the white spaces.

By Michael Nygard

This work is licensed under a Creative CommonsAttribution 3

42、Talk the Talk

As with any profession, jargon isused so that individuals within that profession can effectively communicatewith one another. Lawyers talk to one another about habeas corpus（人生保护权）, voir dire, and venire; Carpenterstalk to one another about butt joints（接头）, lap joints, and flux; Software Architects talk to oneanother about ROA, Two Step View, and Layer Supertype. Wait, what was that?

It is imperative（必要的） that software architects,regardless of the platform they are working in, have an effective means ofcommunication between one another. One of those means of communication isthrough architecture and design patterns. To be an effective software architectyou must understand the basic architecture and design patterns, recognize whenthose patterns are being used, know when to apply the patterns, and be able tocommunicate to other architects and developers using them.

Architecture and design patterns canbe classified into four basic categories: Enterprise Architecture Patterns,Application Architecture Patterns, Integration Patterns, and Design Patterns.These categories are generally based on the level of scope within the overallarchitecture. Enterprisearchitecture patterns deal with the high-level architecture, whereas designpatterns deal with how individual components within the architecture arestructured and behave.

Enterprise Architecture Patternsdefine the framework for the high-level architecture. Some of the more commonarchitecture patterns include Event Driven Architecture (EDA), Service OrientedArchitecture (SOA), Resource Oriented Architecture (ROA), and Pipeline(管道) Architecture.

Application Architecture Patternsspecify how applications or subsystems within the scope of a larger enterprisearchitecture should be designed. Some common pattern catalogs in this categoryinclude the well-known J2EE design patterns (e.g., Session Façade and TransferObject) and the application architecture patterns described in Martin Fowler’sbook “Patterns of Enterprise Application Architecture”.

Integration Patterns are importantfor designing and communicating concepts surrounding the sharing of informationand functionality between components, applications, and subsystems. Someexamples of Integration Patterns include file sharing, remote procedure calls,and numerous messaging patterns. You can find these patterns at http://www.enterpriseintegrationpatterns.com/eaipatterns.html.

Knowing the basic design patterns asdescribed by the Gang of Four book “Design Patterns: Elements of ReusableObject-Oriented Software” is a must for any software architect. Although thesepatterns may appear to be too low-level for a software architect, they are partof a standard vocabulary that makes for effective communication betweenarchitects and developers. 

It is also important to be aware ofand understand the various anti-patterns as well. Anti-patterns, a term coinedby Andrew Koenig, are repeatable processes that produce ineffective results.Some of the more well-known anti-patterns include Analysis Paralysis, Design ByCommittee, Mushroom Management, and Death March. Knowing these patterns willhelp you avoid the many pitfalls you will most likely experience. You can finda list of the common anti-patterns at http://en.wikipedia.org/wiki/Anti-patterns.

Software architects need the abilityto effectively communicate with one another in a clear, concise, and effectiveway. The patterns are there; it is up to us as software architects to learn andunderstand these patterns so we can “walk the walk and talk the talk”.

By Mark Richards

This work is licensed under a Creative CommonsAttribution 3

43、Heterogeneity Wins

Thenatural evolution of computer technology has brought about important changes with respect to（关于） the tools that architects can use to build software systems. Thesechanges have brought about a resurgence（苏醒） of interest in polyglot（数种语言的） programming, which refers to the use ofmore than one core language in the provision（预备） of a software system.

Polyglot programming is not a new concept: one prominent（显著的） example from the past is front-end Visual Basic clients supportedby COM objects authored in C++ on the back-end. Fundamentally speaking, thisarchitecture leveraged what those languages were good at in their heyday.

So what changes took place to fuel this renewed interest in polyglotprogramming?

The change is that technical standards together with ever-increasing bandwidthand computing resources conspired(凑合起来) tomake text-based protocols viable: gone are the days of arcane（神秘的） binary protocols as a pre-requisite to efficient distributedsystems. Text-based remote interoperability largely began with XML/SOAP-basedweb services and continues to evolve with RESTful architectural styles andother supporting (but no less important) protocols such as Atom and XMPP.

This new breed of technologies creates far broader opportunities forheterogeneous development than ever before, simply because the payloadis formattedtext, which is universally generated and consumed. Heterogeneous developmentaffords using the right tool for the job, and text-based interop has blown thedoors off what was previously possible.

Architects can now combine specific, powerful tools that move the yardstick（衡量标准） from previously being able to employ the right language to nowbeing able to employ the right paradigm. Programming languages supportdifferent paradigms, in that some are object-oriented, while others arefunctional or excel at concurrent programming. Some of these paradigms are aperfect match for particular problems or domains, while others are a poor fit.Today, however, it is possible to 'mash-up' some rather unconventional andseemingly dissonant tools into elegant solutions rather more easily than in thepast.

The effects of this change has begun, and manifests itself as a combinatorialincrease in the architectural topology of modern software systems. This is notjust a reflection of their inherent diversity（多样性）, but a testament（遗嘱） to new possibilities.

While choice is not always a good thing, it is 'less worse' than thealternative in the context of modern software architecture. As an industry, weare faced with very serious problems[1] and we need all the interoperability wecan get, particularly as the incumbent（职责所在的） platforms are not well equipped（装备） to resolve them[2].

Yourjob as architect has become even more challenging, because technology silos（粮仓） are crumbling in the face of new possibilities: embrace this, thinkoutside the stack, and leverage the new diversity: heterogeneity wins.

[1]- The impending multicore era may well prove to be the most significant problemyet faced by the software development community.
[2] - The Free Lunch is Over - Herb Sutter, http://www.gotw.ca/publications/concurrency-ddj.htm

By Edward Garson

Thiswork is licensed under a Creative CommonsAttribution 3

44、Dwarves, Elves, Wizards, and Kings

InCryptonomicon, Randy Waterhouse explains his classification system for the differenttypes of people he meets. Dwarves are hard workers, steadily producingbeautiful artifacts in the dark loneliness of their caves. They exert（努力） tremendous forces moving mountains and shaping earth, and arerenowned for their craftsmanship. Elves are elegant, cultured, and spend theirdays creating new and beautiful magical things. They are so gifted they don'teven realize that other races view these things as otherworldly almost. Thewizards are immensely powerful beings almost completely unlike all others, butunlike the Elves, they do know about magic, and its power and nature, and wield（挥） it with supreme（至高的） effect. But there is a fourthtype of character that Waterhouse alludes（间接提到） to but does not mentionspecifically. The Kings are the visionaries who know what must be done with allof these different characters.

AnArchitect is a King of sorts. The Architect must be familiar with all of thesecharacters, and ensure that the architecture has roles for all of thesecharacters. An architecture designed only for one will only attract（吸引） that one character to the project, and even with the best dwarves,or elves, or wizards, the team will be severely limited in its reach if it canonly approach problems in one way.

Agood king will lead all types through a quest, and help them work together tocomplete it. Without the quest, there is no vision for the team, and itultimately becomes a partisan mess. Without all characters, the team can onlysolve one class of problem, and is stopped at the first barrier impassable tothat solution.

Thearchitect creates the quest with all the characters in mind. The architecturethen becomes a guide for finding tasks for the different characters to performwhile learning about each other. When a project encounters difficulty, the teamwill already know how to approach solving it because the architecture gave themthe opportunities to grow into a team.

By:EvanCofsky

Thiswork is licensed under a Creative CommonsAttribution 3

45、Learn from Architects of Buildings

Architecture is a social act and thematerial theater of human activity.”—Spiro Kostof

How many software architects seetheir role as exclusively, or primarily technical? Is it not rather that theyare the conciliators（抚慰者）, go–betweens andarbiters of the warring factions among the stake-holders? How many approachtheir work in a purely intellectual spirit, without giving proper weight to thehuman factors of their job?

“A great architect is not made byway of a brain nearly so much as he is made by way of a cultivated, enrichedheart.”—FrankLloyd Wright

What more strongly marks out thearchitects in your organization: raw intellectual horsepower and vast capacityto recall technical minutia, or taste, refinement and generosity of spirit?Under which tendency would you prefer to work?

“A doctor can bury（隐藏） his mistakes but an architect canonly advise his client to plant vines.”—ibid

Is the "maintenance" of"legacy" systems anything more than pruning those vines? Would you,as an architect, have the intestinal fortitude to scrap a piece of work that hadfailed? Or would you cover it up? Wright also said that the architect's bestfriend was the sledgehammer（大钟）. What have you demolished（粉碎） recently?

“Architects believe that not only dothey sit at the right hand of God, but that if God ever gets up, they take thechair”—KarenMoyer

For "God" read"customer".

“In architecture as in all otheroperative arts, the end must direct the operation. The end is to build well.Well building has three conditions: Commodity, Firmness and Delight.”—Henry Watton

When was the last time you saw apiece of software who's architecture gave you any delight? Do you aim togive delight with your work?

"No person who is not a great sculptor（雕刻家） or painter can be an architect. Ifhe is not a sculptor or painter, he can only be a builder"—John Ruskin

Does artistry play its proper partin your architecture? Is the assemblage of components to make systems informedby a painterly concern for shape and texture, with a sculptural（雕刻般的） sense of balance and impliedmotion, of the importance of negative space?

And finally, no gloss is required onthis comment, a sure remedy for the software architect's most damaging syndrome（综合病症）.

"It seems a fantastic（荒谬的） paradox, but it is nevertheless amost important truth, that no architecture can be truly noble which is notimperfect."—ibid

By Keith Braithwaite

This work is licensed under a Creative CommonsAttribution 3

46、Fight repetition

Are your developers performing recurring（重复的） tasks that needs little thinking?Can you find recurring patterns in the code? Can you spot code that's beenwritten copy-paste-modify style? If that's the case, your team is moving slowerthan they should and oddly enough - you may be the cause.

Before explaining why, let's agreeon a couple of truths about software development: 

1) Duplication is evil. 

2) Repetitive work slows downdevelopment. 

As an architect, you set the tone.You've got the best overall grasp of the system and you probably wrote atrend-setting, end-to-end, vertical slice of the system that serves as anexample for the team - an example that has been copied many times by now.Whenever a developer copies anything - be it a few lines of code, an XML-file,or a class - that's a clear indication that something could be made simpler oreven completely abstracted away. Most often, it's not the domain logic that iscopied; it's the infrastructure code that just has to be there to make it work.For that reason, it's crucial that you can envision the effects your exampleshave. Any code and configuration in your examples will be the base for tens,hundreds, or maybe thousands other slices of the system, which means you haveto make sure that your code is clean, intention revealing, and contains nothingexcept what can't be abstracted away - the domain problem itself. As anarchitect, you need to be highly sensitive to any kind of repetitive patterns,since anything you write will (ironically) be repeated.

But that doesn't happen in yoursystem, right? Take a look at that configuration file. What needs to bedifferent if applied on another slice of the system and what will stay thesame? Look at a typical business layer method. Is there a pattern that shows upin other methods as well, containing things like transaction handling, logging,authentication or auditing? How about the data access layer? Any code in therethat will be the same except for names of entities and fields? Look broader.Can you find two or three lines of code that frequently seems to go togetherand even though they operate on different objects, it feels like the samething? These are all examples of repetition. Repetition in code is somethingthat developers eventually learn to filter out and ignore when reading thecode, once they figured out where the interesting variabilities are found, buteven if the developers get used to it - it slows them down. Code like that isclearly written for computers execute, not for developers to read. 

Your responsibility is to remove it.To do that, you may need to harvest frameworks, create better abstractions,perhaps ask the toolsmith to setup an aspect framework or write a few smallcode generators, but the repetition won't go away unless someone does somethingabout it. 

That someone is you.

(Niclas Nilsson Edited 29/9/2008)

(RMH Edited 7/9/2008)

By Niclas Nilsson

This work is licensed under a Creative CommonsAttribution 3

47、Welcome to the Real World

Engineerslike precision, especially software engineers who live in the realm of ones andzeros. They are used to working with binary decisions, one or zero, true orfalse, yes or no. Everything is clear and consistent, guaranteed by foreign keyconstraints, atomic transactions, and check sums.

Unfortunately, the real world is not quite that binary. Customers place orders,just to cancel them a moment later. Checks bounce, letters are lost, paymentsdelayed, and promises broken. Data entry errors are bound to happen every sooften. Users prefer "shallow" user interfaces, which give them accessto many functions at once without being boxed into a lengthy, one-dimensional "process",which is easier to program and seems more "logical" to manydevelopers. Instead of the call stack controlling the program flow, the user isin charge.

Worse yet, widely distributed systems introduce a whole new set ofinconsistencies into the game. Services may not be reachable, change withoutprior notice, or do not provide transactional guarantees. When you runapplications on thousands of machine, failure is no longer a question of"if", but of "when". These systems are loosely coupled,asynchronous, concurrent, and do not adhere to traditional transactionsemantics. You should have taken the blue pill!

As computer scientists' brave new world is crumbling（粉碎）, what are we to do? As so often,awareness is a first important step towards a solution. Say good bye to thegood old predictive call-stack architecture, where you get to define whathappens when and in what order. Instead, be ready to respond to events at anytime in any order, regaining your context as needed. Make asynchronous requestsconcurrently instead of calling methods one by one. Avoid complete chaos bymodeling your application using event-driven process chains or state models. Reconcile（使和解） errors through compensation, retry,or tentative operations.

Sounds scary（引起惊慌的） and more than you bargained for?Luckily, the real world had to deal with the same issues for a long time:delayed letters, broken promises, messages crossing in transit, payments postedto the wrong account -- the examples are countless. Accordingly, people had toresend letters, write off bad orders, or tell you to ignore the paymentreminder in case you already sent a payment. So don't just blame the real worldfor your headaches, but also use it as a place to look for solutions. Afterall, Starbucks does not two-phase commit either [1]. Welcome to the real world.

[1] http://www.eaipatterns.com/ramblings/18_starbucks.html

48、Don't Control, but Observe

Today's systems are distributed andloosely coupled. Building loosely coupled systems is a bit of a drag, so why dowe bother? Because we want our systems to be flexible, so they do not breakapart at the slightest change. This is a critical property in today'senvironments where we may only control a small portion of our application, theremainder living in distributed services or third party packages, controlled byother departments or external vendors.

So it looks like the effort to build a system that is flexible and can evolveover time is a good idea. But that also means our system will change over time.As in "today's system is not what it was yesterday." Unfortunately,this makes documenting the system challenging. It's commonly known thatdocumentation is out of date the moment it is printed, but in a system thatchanges all the time, things can only be worse. Moreover, building a systemthat is flexible generally means the architecture is more complex and it's moredifficult to get the proverbial "big picture." For example, if allsystem components communicate with each other over logical, configurablechannels, one better have a look at the channel configuration to have any ideawhat is going on. Sending messages into the logical la-la-land is unlikely totrigger a compiler error, but it is sure to disappoint the user whose actionwas encapsulated in that message.

Being a control freak architect is so yesteryear, leading to tightly coupledand brittle solutions. But letting the software run wild is sure to spawnchaos. You have to supplement the lack of control with other mechanisms toavoid doing an instrument flight without the instruments. But what kind ofinstruments do we have? Plenty, actually. Today's programming languages supportreflection, and almost all run-time platforms provide run-time metrics. As yoursystem becomes more configurable, the current system configuration is anothergreat source of information. Because so much raw data is difficult tounderstand, extract a model from it. For example, once you figure out whichcomponents send messages to which logical channels, and which components listento these channels, you can create a graph model of the actual communicationbetween components. You can do this every few minutes or hours, providing anaccurate and up-to-date image of the system as it evolves. Think of it as"Reverse MDA[1]". Instead of a model driving the architecture, youbuild a flexible architecture, and extract the model from the actual systemstate.

In many cases, it's easy to visualize this model, creating the literal bigpicture. However, resist the temptation to plot the 3 by 5 meter billboard ofboxes and lines, which contains every class in your system. That picture maypass as contemporary art, but it's not a useful software model. Instead, use a 1000 ft view as described by ErikDoernenburg, a level of abstraction that actually tells you something. On topof that, you can make sure your model passes basic validation rules, such asthe absence of circular dependencies in a dependency graph, or no messagesbeing sent to a logical channel no one listens to.

Letting go of control is a scary thing, even when it comes to systemarchitecture. But supplemented by observation, model extraction, andvalidation, it is probably the way only to architect for the 21st century.

[1]  MDA = Model Driven Architecture

49、Janus（两面神） the Architect

In the Roman world, Janus was the God ofbeginnings and endings; doors and passageways.  Janus is usually depictedwith two heads facing in different directions, a symbol you may have seen oncoins or from the movies.  Janus represents transitions and changes inlife from past to future, young to old, marriage, births and coming of age.

Forany architect software or structural, Janus ability to see forward and backwardor past to future is a highly regarded skill.  An architect strives tomerge realities with vision; past success with future direction; business andmanagement expectations with development constraints.  Creating thesebridges is a major part of being an architect.  Often an architect mayfeel they are trying to span chasms（裂口） whilebringing a project to completion because of different forces acting on aproject.  For example, ease of access vs. security or satisfying presentbusiness processes while designing for management’s future vision.  A goodarchitect must have those two heads capable of carrying two different ideas orthoughts, different goals or visions to create a product that will satisfy thevarious project stakeholders.

Youshould notice that Janus has two heads not simply two faces.  This allowsJanus to have the extra ears and eyes needed for awareness.  An excellentIT architect will be a superior listener and evaluator.   Understanding the reason for a capital expenditure is crucial todetermining the goals and vision a management team has for the future of theirorganization.  Being able to evaluate the technical skills of your staffwith the design and technology to be used within the project will aid increating the proper training and programming pairs to ensure a successfulproject.  Knowing what open source solutions to use in combination withcommon off-the-shelf software can greatly streamline a project’s timelines andbudgets. An excellent architect will be aware of many of these disparate piecesof the development process and use them to be successful in the projectlifecycle.

Thereare managers who demand and expect God like qualities from their architects butthat is not the purpose of this comparison.  A good architect is open tonew ideas, tools and designs that progress the project, team or profession; shedoesn’t want to spend most of her time in management meetings or doing all thecoding; he should concede to good ideas and cultivate an atmosphere for ideasto grow.  It is an open mind that will succeed as an architect; a mindthat can balance the many conflicting forces at work on projects.  Allarchitects strive to complete their projects and ensure the success of theirdevelopment teams.  The best architects create systems that stand the testof time because these systems are able to be maintained and expanded into thefuture as the organization grows and technology changes.  These architectshave listened, evaluated and refactored their processes, designs and methods toensure the success of their work and projects; they have endeavored to ensuretheir products will withstand the transitions and changes that are sure tocome.

Thisis the mindset we should strivefor（争取） as architects.  It is simple yet difficult toperform. Like Janus, a software architect needs to be a keeper of doors andpassageways, spanning the old and the new, incorporating creativity withsound engineering to fulfill todays requirements while planning to meettomorrow's expectations.

By Dave Bartlett

This work islicensed under a Creative Commons Attribution 3

50、Architects focus is on the boundaries and interfaces

Since Lord Nelson destroyed theFrench and Spanish fleet（舰队） at Trafalgar in 1805,"divide an conquer" has been the mantra for dealing with complex anddifficult problems. A more familiar term with the same intent is separationof concern.  From separation of concern we get encapsulation,and from encapsulation we get boundaries and interfaces.

From an architect's point of view,the hard part is to find the natural places to locate boundaries and define theappropriate interfaces needed to build a working system. This is especiallydifficult in large enterprise systems, often characterized by few naturalboundaries and inter-tangled domains. In this situation old wisdom such as: Minimizecoupling, maximize cohesion, and Do not slice through regions where highrates of information exchange are required provide some guidance, but theysay nothing about how to communicate the problems and potential solutions tostakeholders in a easy way.

Here the concept of bounded-contextsand context mapping, as described by Eric Evans in his book Domain-DrivenDesign,comes to the rescue. A bounded context is an area where amodel or concept is uniquely defined, and we represent it as a cloud or bubblewith a descriptive name that define its role and responsibility in the domainat hand. As an example, a shipping system might include contexts such as: CargoOperation, Cargo Scheduling and Harbor Movement. In other domains other nameswill be appropriate.

With the bounded contextsidentified and drawn up on the white-board, it's time to start to draw therelationships between the contexts. These relationships might addressorganizational, functional or technical dependencies. The result from thisexercise is a context map, a collection of bounded-contexts and the interfacesbetween them.

Such a context map providesarchitects with a powerful tool that allows them to focus on what belongstogether and what should be kept apart, enabling them to divide and conquerwisely in a communicative way. The technique can easily be used to document andanalyze the as-is（照现在的样子） situation, and fromthere guide re-design toward a better system characterized by low coupling,high cohesion and well defined interfaces.

By Einar Landre

This work is licensed under a Creative CommonsAttribution 3

51、Challenge assumptions - especially your own

Wethern's Law of Suspended Judgement states (in a rather tongue-in-cheekfashion) that "Assumption is the mother of all screw-ups." A morepopular take on this would be, "Don't assume - it makes an 'ass' of 'u'and 'me'." But when you are dealing with assumptions that could costthousands, if not millions of dollars, it's not always a laughing matter.

Best practices insoftware architecture state that you should document the rationale behind eachdecision that is made, especially when that decision involves a trade-off(performance versus maintainability, cost versus time-to-market, and so on). Inmore formal approaches, it is common to record along with each decision thecontext of that decision, including the "factors" that contributed tothe final judgement. Factors may be functional or non-functional requirements,but they also may just be "facts" (or factoids...) that thedecision-makers found important (technology constraints, available skill sets,the political environment, etc.).

This practice isvaluable because by way of listing these factors, it helps highlightassumptions that the architects may have that are affecting important decisionsregarding the software that is being designed. Very often these assumptions arebased on "historical reasons", opinion, developer lore(知识),FUDs, or even "something I heard in the hallway":

·   "Open source is notreliable"

·   "Bitmap indexes aremore trouble than they're worth"

·   "The customer wouldNEVER accept a page that takes 5 seconds to load"

·   "The CIO would rejectanything that isn't sold by a major vendor"

It is important tomake these assumptions visible and explicit for the sake of posterity and forfuture re-evaluation. However, it is even more critical to make sure that anyassumptions that aren't based on relevant empirical evidence (or a confirmationfrom the people involved, for political factors) be validated before a decisionis finalized. What if customers can wait 5 seconds for critical reports if youprovide a counter? In exactly what way is exactly which open source projectunreliable? Have you tested the bitmap indexes on your data, using yourapplication's transactions and queries?

And don't overlook（没注意到） the word"relevant." Something that was true in an older version of yoursoftware may not be true today. The performance of bitmap indexes in oneversion of Oracle may not be the same as in another. An older version of alibrary may have had security holes that have already been fixed. Your oldreliable software vendor may be on their last legs financially. The technologylandscape changes every day, and so do people. Who knows? Maybe your CIO hasbecome a closet fan of Linux.

Facts andassumptions are the pillars（重要的支持者） on which your software will be built. Whatever they are, make sure thefoundations are solid.

by Timothy High

This work islicensed under a Creative Commons Attribution 3

52、Record your rationale

There is much debate（争论） in the software development community about the value of documentation,especially in regards to the design of the software itself. The disagreementsgenerally cluster around the perceived value of doing a "big upfrontdesign", and the difficulties of maintaining design documentationsynchronized with an ever-changing code base.

One type of documentation that ages well, doesn't require much effort andalmost always pays off is a record of the rationale behind decisions that aremade regarding the software architecture. As explained in the axiom"Architectural Tradeoffs", the definition of a software architectureis all about choosing the right tradeoffs between various quality attributes,cost, time, and other factors. It should be made clear to you, your managers,developers, and other software stakeholders why one solution was chosen overanother and what tradeoffs this entailed (did you sacrifice horizontalscalability in the name of reducing hardware and licensing costs? Was securitysuch a concern that it was acceptable to increase the overall response time inexchange for data encryption?).

The exact format of this documentation can vary according to what isappropriate for your project, from quick notes in a text document, wiki orblog, to using a more formal template to record all aspects of eacharchitectural decision. Whatever the form and format, the documentation shouldanswer the basic questions "What was that decision we made?", and"Why did we make that decision?". A secondary question that is oftenasked and should be documented is "What other solutions were considered,and why were they rejected?" (actually, the question usually asked is"Why can't we do it MY way?") The documentation should also besearchable so that you can easily find it whenever it's needed.

This documentation may come in handy in a number of situations:

·   As a means of communicationto developers regarding important architectural principles that should befollowed

·   To get the team "onthe same page", or even head off a mutiny（反抗）, when developers question the logic behind the architecture (or even to humbly（谦恭地） accept criticism if itturns out a decision doesn't hold up under scrutiny（详细审查）)

·   To show to managers andstakeholders exactly why the software is being built the way it is (such as whyan expensive piece of hardware or software is necessary)

·   When handing off theproject to a new architect (how many times have you inherited a piece ofsoftware and wondered exactly why the designers did it THAT way?)

However, the most importantbenefits that come from this practice are:

·   It forces you to beexplicit about your reasoning in order to verify that your foundations aresolid (see the axiom "Challenge assumptions - especially your own")

·   It can be used as astarting point to re-evaluate a decision when the conditions that influencedthe final decision have changed

The effort requiredto create this documentation is equivalent to jotting down a few notes wheneveryou have a meeting or discussion on the subject. Whatever the format youchoose, this is one type of documentation that is worth the investment.

by Timothy High

This work islicensed under a Creative Commons Attribution 3

53、Empower developers

Things are usually easier said thandone, and software architects are notoriously good at coming up with things tosay. To keep your words from becoming a lot of hot air (generally the keyingredient in making vaporware), you need a good team of developers to make ithappen. The role of an architect is usually to impose constraints, but you alsohave the opportunity to be an enabler. To the extent your responsibilitiesallow, you should do everything possible to empower your developers.

Make sure developers have the toolsthey need. Tools shouldn't be imposed on developers, they should be carefullychosen to make sure they are the right tools for the job at hand. Repetitiveand mindless work should be automated wherever possible. Also, it is well worththe investment to make sure developers have top-notch machines to work with,adequate network bandwith and access to software, data and informationnecessary to carry out their work.

Make sure they have the skills theyneed. If training is required, make sure they get it. Invest in books andpromote active discussions about technology. The work life of a developershould be hands-on and practical, but also should be actively academic. If youhave the budget for it, send your team to technical presentations andconferences. If not, get them involved in technical mailing lists and look forfree events in your city. As much as possible, participate in the developerselection process as well. Look for developers that are hungry to learn, thathave that little "spark" that says they really dig technology (alsomake sure they can play ball with the team...). It's hard to get a big bang outof a team of duds.

Let developers make their owndecisions wherever it won't contradict the overall goal of the software design.But put constraints where they count, not only to guarantee quality, but alsoto further empower developers. Create standards for the sake of consistency,but also to reduce the number of troublesome, insignificant decisions thataren't part of the essential problem developers are solving. Create a clearroadmap for where to put their source files, what to call them, when to createnew ones, and so on. This will save them time.

Lastly, protect developers fromnonessential parts of their job. Too much paperwork, and too many office choresadds overhead and reduces their effectiveness. You (usually) aren't a manager,but you can have influence on the processes surrounding software development.Whatever processes are used, make sure it is designed to remove obstacles, notincrease them.

by Timothy High

This work is licensed under a Creative CommonsAttribution 3

54、It is all about the data

As software developers we initiallyunderstand software as a system of commands, functions and algorithms. Thisinstruction-oriented view of software aids us in learning how to buildsoftware, but it is this very same perspective that starts to hamper us when wetry to build bigger systems.

If you stand back a little, a computer is nothing more than a fancy tool tohelp you access and manipulate piles of data. It is the structure of this datathat lies at the heart of understanding how to manage complexity in a hugesystem. Millions of instructions are intrinsically complicated, but underneath（在下面） we can easily get our brains arounda smaller set of basic data structures.

For instance, if you want to understand the UNIX operating system, diggingthrough the source code line-by-line is unlikely to help. If however you read abook outlining the primary internal data-structures for handling things likeprocesses and the filesystem, you’ll have a better chance of understanding howUNIX works underneath. The data is conceptually smaller than the code andconsiderably less complicated.

As code is running in a computer, the underlying state of the data iscontinually changing. In an abstract sense, we can see any algorithm as justbeing just a simple transformation from one version of the data to another. Wecan see all functionality as just a larger set of well-defined transformationspushing the data through different revisions.

This data-oriented perspective -- seeing the system, entirely by the structureof its underlying information -- can reduce even the most complicated systemdown to a tangible collection of details. A reduction in complexity that isnecessary for understanding how to build and run complex systems.

Data sits at the core of most problems. Business domain problems creep into（爬进） the code via the data. Most keyalgorithms, for example, are often well understood, it is the structure andrelationships of the data that frequently change. Operational issues likeupgrades are also considerably more difficult if they effect data. This happensbecause changing code or behavior is not a big issue, it just needs to bereleased, but revising data structures can involve a huge effort intransforming the old version into a newer one.

And of course, many of the base problems in software architecture are reallyabout data. Is the system collecting the right data at the right time, and whoshould be able to see or modify it? If the data exists, what is its quality andhow fast is it growing? If not, what is its structure, and where does it reliablycome from? In this light, once the data is in the system the only otherquestion is whether or not there is already a way to view and/or edit thespecific data, or does that need to be added?

From a design perspective, the critical issue for most systems is to get theright data into the system at the right time. From there, applying differenttransformations to the data is a matter of making it available, executing thefunctionality and then saving the results. Most systems don't have to be particularlycomplex underneath in order for them to work, they just need to build up biggerand bigger piles of data. Functionality is what we see first, but it's datathat forms the core of every system.

by Paul W. Homer

This work is licensed under a Creative CommonsAttribution 3

55、Control the data, not just the code

Source code control andcontinuous integration are excellent tools for managing the application buildand deployment process.  Along with（陪同……一起） source code, schema and data changes are often asignificant part of this process and thus warrant similar controls.  Ifyour build and deployment process includes a list of elaborate steps requiredfor data updates, beware（小心）.  These are thelists that always have you crossing your fingers.  They look somethinglike this:

1) Create a list of scripts that need to be run, in order

2) E-mail scripts to special database person

3) Database person copies the scripts to a location where they’re executed by acron job

4) Check script execution log and pray that all scripts ran successfully sinceyou’re not exactly sure what will happen if you re-run them

6) Run validation scripts and spot-check（抽查） the data

7) Regression test（回归测试） the application and seewhat blows up

8) Write scripts to insert missing data and fix blow-ups

9) Repeat

Ok, so that might be a slight exaggeration（夸张） but it’s not that far off.  Many a（许多） project requires this type of acrobatic（杂技的） workflow for successful databasemigration.  For some reason the data portion of the migration plan seemsto be easily overlooked during architecture planning.  As a result it canbecome a brittle, manual process that gets bolted on as an afterthought（追悔）.

This complex web-work creates many opportunities for process breakdown. To make matters worse, bugs caused by schema (计划)and data changes don’t always get caught by unit tests aspart of the nightly build report.  They like to rear their ugly head in aloud, boisterous（喧闹的） manner immediately aftera build has been migrated. Database problems are usually tedious to reverse byhand and their solutions tend to be more difficult to validate.  The valueof a completely automated build process that is capable of restoring thedatabase to a known state will never be more evident than when you’re using itto fix an extremely visible issue.  If you don’t have the ability to dropthe database and restore it to a state that is compatible with a specific buildof the application you are susceptible（易受影响的） to the same type of problems you’d have if you couldn’tback out a code change quickly.

Database changes shouldn’t create a ripple（波纹） in your build’s time-space continuum.  You need to beable to build the entire application, including the database, as oneunit.  Make data and schema management a seamless part of your automatedbuild and testing process early on and include an undo button; it will paylarge dividends.  At best it will save hours of painful, high-stressproblem solving after a late night blunder. At worst it will give your team theability to confidently charge forward with refactoring of the data accesslayer.

by

Chad LaVigne

This work is licensed under a Creative CommonsAttribution 3

56、Don't Stretch The Architecture Metaphors

Architects like to deal with metaphors. They provide nice concrete handleson subjects that are often abstract, complex and moving targets. Whether it iscommunicating with the rest of the team or talking through the architecturewith the end-user it is so tempting to find something tangible or physical touse as a metaphor for what you are trying to build.

This usually startswell, in that a common language can evolve where people start to feel thatthings are moving in the right direction. The metaphor develops and grows overtime until it takes on a life of it's own. People feel good about the metaphor- we're making progress!

What usually happensis that the metaphor for the architecture now becomes dangerous. Here's how itcan turn on it's Architect creators:

·   The business domaincustomer starts to like your metaphor more that your proposed system, in thatthe happiest possible interpretation is now taken by all concerned and where noreal constraints are uncovered.

Example: We'rebuilding a 'transport system like a ship travelling between a series of docks'.

You think containerships crossing the Pacific. I was actually thinking a rowing boat in a swimmingpool, with possibly one oar.

·   The development teamstarts to think that the metaphor is more important than the actual businessproblem. You start to justify odd decisions because of a fondness for themetaphor.

Example: We saidit's like a filing cabinet  so of course we have to show it to the useralphabetically. I know it's a filing cabinet with six dimensions and ofinfinite length and clock built in to it, but we've done the icon now - so ithas to be a filing cabinet...

·   The delivered systemcontains relics of names from old broken metaphors long gone;archaeological   testimonials to concepts long refactored and dugover.

Example: Why doesthe Billing Factory object create a Port channel for the Rowing boat system?Surely it it should return a Pomegranate view for the Hub Bus? What do you meanyou're new here?

So remember, don'tfall in love with your system metaphor - only use it for exploratorycommunication purposes and don't let it turn on you.

by David Ing

This work islicensed under a Creative Commons Attribution 3

57、Focus on Application Support and Maintenance

The support and maintenance of anapplication should never ever be an after-thought. Since over 80% of anapplication's life-cycle is spent in maintenance, you should pay a lot ofattention to the problems of support and maintenance when you're designing.Fail to heed this and you'll watch with horror as your application stops beingthe architect's dream and becomes a vile beast that dies a horrible death andis forever remembered as a failure.

When most architects design applications they think mainly of developers, whohave IDEs and debuggers in place.  If something goes wrong, highly skilledsoftware engineers debug away and the bug is discovered. It's easy to thinkthis way because most architects have spent most of their lives as developersrather than administrators.  Unfortunately, the developer and the supportguy have different skill sets, just as the development/testing environment andthe production environment has different purposes.

Here are a few of the disadvantages that an administrator faces:

 * An administrator can't resubmit a request message to reproduce theproblem.  When you're in production, you can't re-issue a financialtransaction against the "live" database to see what when wrong
 * Once the application is in production, the pressure to fix bugs comesfrom customers and executives, not from the project manager and the testingteam.   And an angry CEO can be a lot more threatening.
 * Once you're in production, there is no debugger. 
 * Once you're in production, deployment needs to be scheduled andco-ordinated.  You can't take a production application down for a fewminutes to test a bug fix.
 * The logging level is much higher in the development environment than inproduction

A few symptoms of this failure to plan for support are:
 * most problems require a developer's involvement
 * the relationship between the development team and the support team issour; the developers think the support team is a bunch of idiots
 * the support team hates the new application
 * the architect and development teams are spending a lot of time inproduction
 * the application is restarted often as a way to resolve problems
 * the administrators never have time to tune the system properly becausethey're always fighting fires

To ensure that your application succeeds once it's out of the developers'hands, you should:
 * understand that development and support require a different skill set
 * get a support lead as early in on the project as possible
 * make the support lead a core part of the team
 * get a support lead to be involved with the planning for the applicationsupport

Design such that the learning curve for the support personnel is minimal. Traceability, auditing and logging are crucial. When the administrators arehappy, everybody is happy ( espescially your boss )

by Mncedisi Mawabo Kasper

This work is licensed under a Creative CommonsAttribution 3

58、

59、Prefer principles, axioms and analogies to opinion and taste

When creating your architecture you should explicitly use principles,axioms and analogies to guide the creation.  This gives the architecture anumber of benefits that are not present if you simply create by implicitlyleveraging your experience, opinions and tastes.

Documenting your architecture will be easier.  You can start by describingthe principles that were followed.  This is much easier than trying tocommunicate your opinions and experience.  The principles will thenprovide a convenient handle for those tasked with understanding andimplementing the architecture.  It will also be invaluable for subsequentor inexperienced architects who need to work with the architecture.

An architecture with clear principles is an architecture that frees itsarchitect from reviewing everything and being everywhere.  It givesarchitects greater leverage and influence.  You will not need to be anomniscient workaholic to ensure that others can consistently:

·   implement and adapt thearchitecture;

·   extend the architectureinto related domains;

·   re-implement thearchitecture using newer technologies;

·   work out the detailed edgecases.

Disagreements about opinion and taste invariably turn into political argumentsin which authority is used to win.  However, disagreements where thefoundation principles are clear provide a way for more reasoned discussion tooccur without issues being personalised.  It also allows the disagreementsto be resolved without reference to the architect at all.

Principles and axioms also give an architecture consistency throughout itsimplementation and across time.  Consistency is often a problem,especially in large systems that span multiple technologies and will exist formany years.  Clear architectural principles allow those unfamiliar with aparticular technology or component to reason about and more readily understandthe unfamiliar technology.

By Michael Harmer

This work islicensed under a Creative Commons Attribution 3

60、Start with a Walking Skeleton

One very useful strategy forimplementing, verifying, and evolving an application architecture is to startwith what Alistair Cockburn calls a Walking Skeleton.  A Walking Skeleton is a minimal, end-to-end implementation of thesystem that links together all the main architectural components. Starting small, with a working system exercising all the communication paths,gives you confidence that you are heading in the right direction.

Once the skeleton is in place, it's time to put it on a workoutprogram. Bulk it up with full body workouts.  This means implementincrementally, adding end-to-end functionality.  The goal is to keep thesystem running, all the while growing the skeleton.

Making changes to an architecture is harder and more expensive the longer ithas been around and the bigger it gets.  We want to find mistakesearly.  This approach gives us a short feedback cycle, from which we canmore quickly adapt and work iteratively as necessary to meet the business'prioritized list of runtime-discernablequality attributes.  Assumptions about the architecture arevalidated earlier.  The architecture is more easily evolved becauseproblems are found at an earlier stage when less has been invested in itsimplementation.

The bigger the system, the more important it is to use this strategy.  Ina small application, one developer can implement a feature from top to bottomrelatively quickly, but this becomes impractical with larger systems.  Itis quite common to have multiple developers on a single team or even onmultiple, possibly distributed teams involved in implementing end-to-end. Consequently, more coordination is necessary.  And naturally, developersimplement at a different pace.  Some developers can accomplish a lot andin little time while others can spend a lot of time implementing very little.More difficult and time consuming efforts should be done earlier in theproject.

Start with a Walking Skeleton, keep it running, and grow it incrementally.

By Clint Shank

This work is licensed under theCreative Commons, Attribution 3 open source license.

61、Share your knowledge and experiences

From all of our experiences,including both success and failure, we learn a great deal（大量）. In a young industry like softwaredevelopment, disseminating（传播） this experience andknowledge is vital in helping sustain progress. What each team learns in itsown tiny little corner of the world is possibly influential across the globe.

Realistically our fundamental knowledge base for software development, that is,the knowledge that is absolute and theoretically correct, is small compared towhat is necessary to successfully develop a project. To compensate,we guess,rely on intuitive judgments or even pick randomly. In that, any majordevelopment project generates empirical evidence into what works and whatfails. We're gradually working through the permutations, which we want to applyback to industry as a whole（总体上）.

At an individual level, we are all trying to grow and come to understand how tobuild larger and larger systems. The course of our careers will take us towardever-increasing challenges, for which we want our past experiences to helpguide us. Being there is one thing, but to get the most from the experience weoften have to rationalize it. The best and easiest way of working through it isto attempt to explain it to another person.

The act of discussing something always helps to show its weaknesses.You don'treally understand something, until you can explain it easily. It's only byputting forth our explanations and discussing them that we solidify the experienceinto knowledge.

Another point is that while we may have had specific experiences, the inferences（推论） we draw from them may not beentirely correct in the overall context. We may not have been as successful aswe thought, or as smart as we wanted. Of course testing your knowledge againstthe real world is scary, particularly when you find out that something dear ismyth, incorrect or was never true; it's hard to be wrong.

Ultimately, we are human beings so not everything in our minds is correct; not everythought we have is reasonable. It's only when we accept our flaws that we open up（开始） the possibility of improving. Theold adage（格言） about learning more fromfailure always holds. If our ideas and beliefs do not stand the test of adebate, then it is better we find out now, than build on it later.

We really want to share our knowledge and experience to help the industryprogress; we also realize it helps ourselves to understand and correct it.Given the state of so much of our software, it is clearly important for us totake every opportunity to share the things we know, what we think we know, andwhat we've seen. If we help those around us to improve, they'll help us toreach our full potential.

by Paul W. Homer

This work is licensed under a Creative CommonsAttribution 3

62、Make sure the simple stuff（东西） is simple

Software architects solve a lot ofvery difficult problems but we also solve some relatively easy ones.  Whatwe don’t want to do is apply a complicated solution to an easy problem. As obvious as that advice sounds it can be hard follow.  People who designsoftware are smart, really smart.  The simple problem-complex solutiontrap can be an easy one to fall into because we like to demonstrate our knowledge. If you find yourself designing a solution so clever that it may become self-aware（自明的）, stop and think.  Does thesolution fit the problem?  If the answer is no, reconsider your designoptions.  Keep the simple stuff simple.  You’ll get plenty of chancesto showcase your talent when the difficult problems arise, and they will.

This doesn’t mean that we shouldn’t implement elegant solutions.  It meansthat if we’re tasked with designing a system that only needs to support sellingone type of SKU based widget it’s probably a bad idea to design for hierarchiesof dynamically configurable products.
 
The cost incurred by a complicated solution may seem small but chances are it’slarger than you’re giving it credit for.  Over-engineering at thearchitectural level causes many of the same issues as it does at thedevelopment level but the negative effects tend to be multiplied.  Poordecisions made at the design level are more difficult to implement, maintainand worst of all reverse.  Before moving forward with an architecturaldecision that exceeds system requirements, ask yourself how difficult it wouldbe to remove after it’s in place.
 
The costs don’t stop with the implementation and maintenance of the solution inquestion. Spending more time than necessary on an easy problem leaves less timefor when the complicated issues show up.  Suddenly your architecturedecisions are creating scope creep and adding unnecessary risk to theproject.  Your time could be spent much more efficiently making sure noone else is doing that. 

There’s often a strong desire to justify solutions with a perceived benefit orimplied requirements.  Remember this: when you try to guess at futurerequirements, 50% of the time you’re wrong and 49% of the time you’re very,very wrong.  Solve today’s problem today.  Get the application outthe door on time and wait for feedback to generate real requirements.  Thesimple design you create will make it much easier to integrate those newrequirements when they arrive.  If you beat the odds and your impliedrequirement becomes a real one on the next release you’ll already have asolution in mind.  The difference is now you’ll be able to allocateappropriate time for it in the estimate because it’s truly required. Before you know it you’ve got the reputation（名声） of a team that makes good estimates and gets work done ontime.

by

Chad LaVigne

This work is licensed under a Creative CommonsAttribution 3

63、If you design it, you should be able to code it.

As an architect, it's tempting（诱惑人的） to create elaborate（精细的） designs and abstractions that elegantly address（处理） the problem at hand. It is even more tempting to sprinkle（洒） new technologies into theproject. At the end of the day, someone has to implement your design, and thearchitectural acrobatics（巧妙手法） that you have the developers perform impact the project.

When designing thearchitecture for your project, you need to have a feel for the amount of effortnecessary to implement each element of your design - if you developed anelement before it will much easer to estimate the effort required.

Don’t use a patternin your design that you haven’t personally implemented before. Don’t rely on aframework that you haven’t coded against before. Don’t use a server that youhaven’t configured before. If your architecture depends on design elements thatyou haven’t personally used, there are a number of negative side effects:

1.  You will not have experienced the learning curve that your developers willhave to face. If you don't know how long it takes to learn a new technology,you won't be able to give a good estimate on time to implement.

2.  You will not know the pitfalls to avoid when using theelements. Inevitably, things will not go as well as the demo that thetrained expert in the technology provided. If you haven't worked with thetechnology before, you will be blindsided（毫无防备的） when this happens.

3.  You will lose the confidence of your developers. When the developers askquestions about the design and you aren't able to give solid answers, they willquickly lose confidence in you and your design.

4.  You will introduce unnecessary risk. Not knowing these things can put abig question mark on key elements of the solution. No one wants to start aproject with big, unnecessary risks hanging around.

So how does one goabout learning new frameworks, patterns, and server platforms? Well that’sanother axiom（公理） in and of itself: Before anything, an architect is a developer.

 By Mike Brown

This work islicensed under a Creative Commons Attribution 3.

64、The ROI（投资回报） variable

Every decision we make for ourprojects, be it technology, process or people related, can be a viewed as aform of investment. Investments come associated with a cost, which may or maynot be monetary, and carry trust that they will eventually pay off. Ouremployers choose to offer us salaries in the hope that this investment willpositively affect the outcome of their venture. We decide to follow a specificdevelopment methodology in the hope that it will make the team more productive.We choose to spend a month redesigning the physical architecture of anapplication in the belief that it will be beneficial in the long run.

One of the ways of measuring the success of investments is by rate of return,also known as return on investment (ROI). For example, "we anticipate thatby spending more time writing tests we will have less bugs in our nextproduction release". The cost of the investment in this case is derivedfrom the time spent writing tests. What we gain is the time saved from fixingbugs in the future, plus the satisfied customers experiencing better behavedsoftware. Let's assume that currently 10 out of 40 working hours in a week arespent fixing bugs. We estimate that by devoting 4 hours a week to testing wewill reduce the amount of time spent on fixing bugs to 2 a week, effectively saving 8 hours toinvest in something else. The anticipated ROI is 200%, equal to the 8 hours wesave from bug fixing divided by the 4 hours we invest in testing.

Not everything need directly translate in monetary gains, but our investmentsshould result in added value. If for our current project, time to market isessential to the stakeholders, maybe a bulletproof（防弹的） architecture which requires alengthy up front design phase will not offer ROI as interesting as a swiftalpha release. By quickly going live, we gain the ability to adapt to audiencereactions that can form the deciding element to the future direction andsuccess of the project, whereas not thoroughly planning can incur the cost ofnot being able to scale the application easily enough when the need arises. TheROI of each option can be determined by examining its costs and projectedprofits and can be used as a base for selection between what is available.

Consider thinking of architectural decisions as investments and take intoaccount(考虑) the associated rate ofreturn, it is a useful approach for finding out how pragmatic or fit forpurpose every option on the table is.

By George Malamidis

Thiswork is licensed under a Creative Commons Attribution 3

65、Your system is legacy（遗产）, design for it.

Even if your system is bleeding edgeand developed in the latest technology, it will be legacy to the next guy. Dealwith it! The nature of software today means things go out of date fast. If youexpect your system to go into production and survive, even for a few months,then you need to accept that maintenance developers will need to fix things up.This means several things:

Clarity - it should be obvious what role components and classes perform.

Testability - is your system easy to verify?

Correctness - do things work as designed or as they should? Eliminate quick andnasty fixes.

Traceability - can Ernie the Emergency bug fixer who has never seen the codebefore jump into production, diagnose a fault and put in a fix? Or does he needan 8 week handover（移交）?

Try to think of a different team opening up the codebase and working out what'shappening. This is fundamental for great architecture. It doesn't have to beover-simplified or documented to the hilt, a good design will document itselfin many ways. Also the way a system behaves in production can also expose thedesign. For example, a sprawling architecture with ugly dependencies will oftenbehave like a caged animal in production. Spare a thought for（替……着想） (usually more junior) developerswho may have to debug defects.

Legacy tends to be a bad word in software circles, but in reality, all softwaresystems should endure（忍耐） the tag. It is not a badthing as it may indicate that your system is durable, meets expectations andhas business value. Any software system that has never been called legacy hasprobably been canned（罐装的） before launch - which isnot the sign of a successful architecture.

by Dave Anderson.

 This work is licensed under a Creative CommonsAttribution 3http://creativecommons.org/licenses/by/3.0/us/

66、If there is only one solution, get a second opinion

You've probably heard this saidbefore. If you're an experienced architect, you know it's true: if you can onlythink of one solution to a problem, you're in trouble.

Software architecture is aboutfinding the best possible solution for a problem given any number ofconstraints. It is rarely possible to satisfy all requirements and constraintswith the first solution that comes to mind. Generally, trade offs must be madeby choosing the solution that best satisfies the requirements according to themost critical priorities.

If you only have one solution to theproblem at hand, it means that you will have no room to negotiate these tradeoffs. It's very possible this one solution will be insatisfactory to the stakeholders（赌金保管者） of your system. It also means thatif priorities are shifted due to a changing business environment, your systemmay have no room to adapt for new requirements.

Rarely, if ever, is this situationcaused by a real lack of options. It is much more likely due to theinexperience of the architect in this particular problem domain. If you knowthis is the case, do yourself a favor and ask someone more experienced to giveyou a hand.

A more insidious（阴险的） manifestation（表现） of this problem is when an architecture is designed fromhabit. An architect can be experienced with a single style of architecture(e.g. a 3-tier, layered client-server system), but not know enough to recognizewhen that style doesn't fit. If you find yourself in the situation where youautomatically KNOW the solution, without having done any comparison to otherapproaches, stop, take a step back, and ask yourself if you can think ofanother way to do it. If you can't, you may be in need of some help.

A friend of mine was once thetechnical person in charge of a small, but growing internet start-up. As theiruser base started growing, so did the load requirements on their system.Performance was going down the tubes, and they were starting to lose some oftheir hard-won user base.

So, the boss asked him, "Whatcan we do to improve the performance?"

My friend had the answer: "Buya bigger machine!"

"What else can we do?"

"Umm... as far as I know,that's it."

My friend was fired on the spot. Ofcourse, the boss was right.

by Timothy High

Thiswork is licensed under a Creative Commons Attribution 3

67、Understand the impact of change

A good architect reduces complexity to a minimum and can design a solutionwhose abstractions provide solid foundations to build upon, but are pragmaticenough to weather(经受住) change.

The great architectunderstands the impact of change - not just in isolated software modules, butalso between people and between systems.

Change can manifest（出现） in a variety of forms:

·   Functional requirementschange

·   Scalability needs evolve

·   System interfaces aremodified

·   People in the team comeand go

·   and the list goes on...

The breadth andcomplexity of change in a software project is impossible to fathom（看穿） up-front（预先）, and it's a fruitless（不结果实的） task trying to accommodate every potential bump（撞击） before it happens.  But the architect can play a crucial role indetermining whether the bumps in the road（挡路） make（被处理） or break a project.

The architect's roleis not necessarily to manage change, but rather to ensure change is manageable.

Take, for example, ahighly distributed solution that spans many applications and relies on avariety of middleware to glue the pieces together.  A change in abusiness process can cause havoc（大破坏） if the set of dependencies are not correctly tracked or accuratelyrepresented in some visual model.  The impact downstream（下游的） is particularly significant if the change affects the data model, breaksexisting interfaces, and the existing long-running, stateful transactions mustsuccessfully complete under the old version of the process.

This example mayappear extreme, but highly integrated solutions are now mainstream. This is evident in the choice of integration standards, frameworks andpatterns available.  Understanding the implications（含意） of change in these outlying systems is critical in ensuring a sustainablelevel of support to your customers.

Fortunately, thereare many tools and techniques to mitigate the impact of change:

·   Make small, incrementalchanges

·   Build repeatable testcases - run them often

·   Make building test caseseasier

·   Track dependencies

·   Act andreact systematically

·   Automate repetitive tasks

Thearchitect must estimate the risk of change on various aspects of theproject's scope, time and budget, and be prepared to spend more time onthose areas whose impact would be the greatest as the result of "a bump inthe road".  Measuring risk is a useful tool forknowing where your valuable time should be spent.

Reducing complexityis important, but reduced complexity it does not equate to simplicity. The pay-off for understanding the type and impact of change on yoursolutions is immeasurable（不可估量的） in the medium- to long-term.

by Doug Crawford

This work islicensed under a Creative Commons Attribution 3.

68、You have to understand Hardware too

For many softwarearchitects, hardware capacity planning is a topic that lies beyond theircomfort zone, yet it remains（依然是） an important part of thearchitect’s job.  There are a number of reasons software architects oftenfail to properly consider hardware but they mostly have to do with a lack ofunderstanding and unclear requirements.  

The primary reason we neglect（疏忽） hardware considerations is that we are focused on softwareand tend to ignore hardware demands. In addition, we are naturally isolatedfrom hardware by high-level languages and software frameworks.

Unclear requirements are also a factor as they may change or may be poorlyunderstood.  As the architecture evolves hardware considerations will alsochange.  In addition, our clients may not understand or be able to predictthe size of their own user base or system usage dynamics.  Finally,hardware is constantly evolving. What we knew about hardware in the past doesnot apply today.  

Without hardware expertise predicting hardware configurations for systems to bedeveloped is highly error prone. To compensate some software architects uselarge safety factors. Such safety factors are generally not based on objectiveassessments or founded in any methodology. In most of the cases, this leads toexcessive infrastructure capacities that will not be utilized even in periodsof peak demand. As a result, clients' money is wasted on more hardware than asystem will ever need.

The best defense against poor hardware planning is to work closely with aninfrastructure architect.  Infrastructure architects, unlike softwarearchitects, are specialists in hardware capacity planning and they should be apart of your team.  However, not every software architect has the luxury（奢侈） of working with an infrastructurearchitect. In such cases there are some things a software architect can do tomitigate errors when planning for hardware.

Drawingon（利用） your own past experience can help.You've implemented systems in the past and so you have some knowledge ofhardware capacity planning – even if it was an after thought at the time. You can also discuss the topic with your client and convince them to set asidefunds for hardware capacity planning.  Budgeting for capacity planning canbe much more cost effective than buying more hardware than you need.  Inthis case, horizontal scalability is the key – adding hardware as needed ratherthan over-buying in the beginning.  To make a horizontal strategy worksoftware architects need to constantly measure capacity and isolate softwarecomponents to execute in performance predictable environments.

Hardware capacity planning is as important as software architecture and itneeds to be given a first order priority whether you have an infrastructure architecton hand or not.  Just like an architect is responsible to establish thelinks between business demands and a software solution, she is responsible to envision（预想） the links between hardware andsoftware.

By Kamal Wickramanayake

This work is licensed under CreativeCommons Attribution 3

69、Shortcuts now are paid back（偿还） with interest later

It’s important toremember when architecting a system that maintenance will, in the long run,consume more resources than initial development of the project.  Shortcuts taken during the initial development phase of a project can result insignificant maintenance costs later.

For example, you may have been informed that unit tests don't deliver directvalue and so you tell your developers to skip the rigorous（严格的） application of them. This makes thedelivered system much more difficult to change in the future, and decreasesconfidence when making those changes. The system will require far more manualtesting for a smaller set of changes, leading to brittleness（脆弱性） and increased maintenance expensesas well as a design that's not as appropriate as a fully-tested design (letalone a test-first design).

A serious architectural mistake that is sometimes made is to adapt an existingsystem for a purpose that it is not fit for, on the basis that using anexisting system somehow（以某种方式） reduces costs. Forexample, you might find yourself utilizing BPEL architectural componentscoupled with database triggers to deliver an asynchronous messaging system.This might be done or insisted upon for reasons of convenience or because thatis the architecture is known to you or the client.  But a messagingarchitecture should have been selected in the first instance after requirementsmade it clear it was a necessary component. Poor decisions made at theinception of a project make it much more expensive to re-architect the systemto meet new requirements.

In addition to avoiding short cuts during the initial development phase, it’salso important to correct poor design decisions as quickly as they arediscovered. Poorly designed features can become the foundation for futurefeatures making corrective action later even more costly.

For example, if you discover that inappropriate libraries were selected forsome underlying functionality they should be replaced as soon as possible.Otherwise the effort to make them fit evolving requirements will result inadditional layers of abstractions, each designed to hide the poor fit of theprevious layer. You are building yourself a ball of tangled twine, tack, andsticky tape and with every layer you add, it is harder to unravel（拆开）. This easily results in a systemthat is resistant to change.

As an architect, when you encounter an architectural problem or design flawinsist that it be rectified now, when it cheapest to fix it. The longer youleave it to drag out, the higher the interest payment is.

by Scot Mcphee

This work is licensed under a Creative CommonsAttribution 3 licence

70、"Perfect" is the Enemy of "Good Enough"

Software designers, and architectsin particular, tend to evaluate solutions by how elegant and optimum they arefor a given problem. Like judges at a beauty contest, we look at a design orimplementation and immediately see minor flaws or warts（瑕疵） that could be eliminated with justa few more changes or re-factoring iterations.  Domain models simply begfor one more pass to see if there are any common attributes or functions thatcan be moved into base classes. Services duplicated in multiple implementationscry out their need to become web services. Queries complain about "buffergets" and non-unique indexes and demand attention.

My advice: Don't give in to the temptation to make your design, or your implementation,perfect! Aim for "good enough" and stop when you've achieved it.

What exactly is "good enough," you might ask? Good enough means thatthe remaining imperfections do not impact system functionality,maintainability, or performance in any meaningful way. The architecture anddesign hangs together. The implementation works and meets the performancerequirements. Code is clear, concise, and well-documented. Could it be better?Sure, but it is good enough, so stop. Declare victory and move on to the nexttask.

The search for perfection in design and implementation leads, in my opinion, toover-designed and obfuscated solutions that are, in the end, harder tomaintain.

A number of the axioms in this book caution designers to avoid unnecessaryabstraction or complexity. Why do we have problems keeping things simple?Because we are seeking the perfect solution! Why else would an architectintroduce complexity in a workable solution except to address a perceivedimperfection in the simpler design.

  
Remember that application development is not a beauty contest（选美）, so stop looking for flaws andwasting time chasing perfection.

71、Avoid "Good Ideas"

Good ideas kill projects. Sometimes it's a quick death, but often it's aslow, lingering（延迟的） death caused by missed milestones and a spiraling（螺旋式上升的） bug count.

You know the kinds of good ideas I'm talking about: Tempting, no-brainer, innocent（天真的）-looking,couldn't-possibly-hurt-to-try sorts of ideas. They usually occur to someone onthe team about halfway through a project when everything seems to be goingfine. Stories and tasks are getting knocked off（击倒） at a good pace, initial testing is going well, and the rollout（首次展示） date looks solid. Life isgood.

Someone has a "good idea," you acquiesce（勉强同意）, and suddenly you are re-fitting a new version of Hibernate into yourproject to take advantage of the latest features, or implementing AJAX in someof your web pages because the developer showed the user how cool it is, or evenre-visiting the database design to utilize XML features of the RDBMS. You tellthe project manager you need a few weeks to implement this "goodidea," but it ends up impacting more code than originally anticipated, andyour schedule starts to slip. Plus, by letting in the first "goodidea," you've allowed the proverbial（谚语的） camel's nose in the tent, and soon the good ideas are coming out of the woodwork（木制品） and it becomes harder tosay no (and the camel is soon sleeping in your bed).

The really insidious thing about "good ideas" is that they are"good." Everyone can recognize and reject "bad" ideas outof hand - It's the good ones that slip through and cause trouble with scope,complexity, and sheer wasted effort incorporating something into theapplication that isn't necessary to meet the business need.

Here are some key phrases to look for:

·   "Wouldn't it be coolif …" Really, any sentence with the word "cool" in it is adanger signal.

·   "Hey, they justreleased version XXX of the YYY framework. We ought to upgrade!"

·   "You know, we reallyshould re-factor XXX as long as we are working on ZZZ …"

·   "That XXX technologyis really powerful! Maybe we could use it on …"

·   "Hey,<yournamehere>, I've been thinking about the design and I have anidea!"

Okay, okay, maybeI'm being a bit too cynical（愤世嫉俗的） with that last one. But keep watching out for（提防） "good ideas" that can kill your project.

72、Great content creates great systems

I have seen my fair share of initiatives focus endlessly on requirements,design, development, security & maintenance but not on the actual point ofthe system – the data. This is especially true in content-based systems inwhich the data is information delivered as unstructured or semi-structuredcontent.  Great content means the difference between a system that ishollow and one that is relevant.

Content is king.Content is the network. Content is theinterface. In an increasinglyinterconnected world, content quality is rapidly becoming the differencebetween success and failure. FaceBook vs. Orkut /Google vs. Cuil / NetFlix vs.BlockbusterOnline.... the list is endless where battles have been won and loston the content battlefield. One could argue that content-related aspects arenot the software architect's problem - but I think the next decade willcertainly disprove that.

Part of the designprocess for a new system should be devoted assessing content inventory.Designing an effective domain/object/data model is not enough.

Analyze allavailable content and assess its value on the following criteria:

- Is there enoughcontent available? If not, how do we attain critical mass?

- Is the contentfresh enough? If not, how do we improve delivery rates?

- Have all possiblecontent channels been explored? RSS feeds, Email, Paper Forms are all channels.

- Are thereeffective input streams built to facilitate the continual delivery of thiscontent into the system? It's one thing to identify valuable content, butanother thing altogether to harvest it regularly.

Make no mistake, thesuccess of a system depends on its content. Spend a healthy part of the designprocess to assess the value of your content. If your findings are less thansatisfactory then that's a red flag and the stakeholders must be advised about.I have seen many systems that fulfill all contractual obligations, meet everyrequirement and still fail because this fairly obvious aspect was ignored.Great content creates great systems.

By Zubin R. Wadia

This work islicensed under a Creative Commons Attribution 3

73、The Business Vs. The Angry Architect

There comes a time in our career asan architect when we realize many of the issues we encounter are recurring.Though the project and industry may change, many of the problems are similar.At this point we can draw on our experience to provide many solutions quickly,leaving more time to enjoy the challenging issues. We’re confident in oursolutions and we deliver as advertised. We have reached homeostasis. This isthe perfect time to make a colossal mistake - like deciding you know so muchthat it’s time for you to start talking more than you listen. This poordecision usually comes with a side of cynicism, impatience and general angertowards inferior minds who dare contradict your superior understanding of allthings technical and otherwise.

In it’s worst form this overconfidence bleeds into the business realm. This isan excellent way to land your career on a list somewhere next to the BlackRhino. The business is our reason for existence. That statement probably hurtsa little but we must not lose sight of that fact. We live to serve them, notvice-versa. Listening to and understanding the business that employs us tosolve problems is the most critical skill we possess. Ever caught yourselfimpatiently waiting for a business analyst to finish talking so you could makeyour point? Chances are you didn’t get theirs. Show the business domain expertsthe respect you expect to receive, this is the last group of people you wantviewing you as unapproachable. If they start avoiding you, you’re being acatalyst for communication breakdown and sabotaging your own project. Remember;when you’re talking you can only hear something you already know. Don’t everstart thinking you’re so smart that no one else has something valuable to say.

When we are listening we’ll often disagree with what we hear about how thebusiness operates. That’s fine. We can make suggestions for improvement andshould definitely do so. However, if at the end of the day you disagree with howthe business is run and it's not going to change, that’s just too bad. Don’tallow yourself to become a disgruntled genius that spends all of your timetrying to impress others by making witty, condescending statements about howpoorly the company is run. They won’t be impressed. They’ve met that guy beforeand they don’t really like him. One of the key ingredients to the recipe for agreat architect is passion for your work but you don’t want too much passion ofthe angry variety. Learn to accept disagreements and move on. If thedifferences are too great and you find yourself continually at odds with thebusiness, find a company that’s easier for you to get behind and designsolutions for them. Regardless of how, find a way to establish a good relationshipwith the business and don't let your ego damage it. It will make you happierand more productive.

by

Chad LaVigne

This work is licensed under a Creative CommonsAttribution 3

74、Stretch key dimensions to see what breaks

An application's design is outlined initially based on the specifiedbusiness requirements, selected or existing technologies, performance envelope,expected data volumes and the financial resources available to build, deployand operate it. The solution, whatever it is, will meet or exceed what is askedof it in the contemporary environment and is expected to run successfully (orit is not yet a solution).

Now take this solution and stretch the key dimensions to see what breaks.

This examination looks for limits in the design that will occur when, forexample, the system becomes wildly popular and more customers use it, theproducts being processed increase their transaction counts per day, or sixmonths of data must now be retained rather than the initially specified week.Dimensions are stretched individually and then in combination to tease out theunseen limits that might lie hidden in the initial design.

Stretching key dimensions allows an architect to validate a solution by:

·   Understanding whether theplanned infrastructure accommodates these increases, and where the limits are.If the infrastructure will break it identifies where it will break which can behighlighted to the application's owner, or the planned infrastructure can bepurchased with specific upgrade paths in mind.

·   Confirming there aresufficient hours in the day to perform the processing at the expectedthroughput, with head room to accommodate 'busy days' or 'catch up' after anoutage. A solution that cannot process a day's processing in a day and relieson the weekend when things are quieter has no long-term future.

·   Validating the data accesschoices that were made are still valid as the system scales. What might workfor when a week's data is held, may be unusable with six month's data loaded.

·   Confirming how theapplication's increased workload will be scaled across additional hardware (ifrequired), and the transition path as the load increases. Working through thetransition before the application is deployed can influence the data stored andits structure.

·   Confirming the applicationcan still be recovered if the data volumes are increased and/or the data is nowsplit amongst an increased infrastructure.

Based on this examination, elements of the design may be recognised as problemsrequiring redesign. The redesign will be cheaper whilst the design is stillvirtual, technical choices are not locked-in and the business data has yet tobe stored in the repositories.

by Stephen Jones

This work islicensed under a Creative Commons Attribution 3

75、Before anything, an architect is a developer

Have you heard of a judge who wasn'ta lawyer; or a chief of surgery who wasn't a surgeon? Even after they get towhat some would call the pinnacles of their career, the people holding theseoccupations are still expected to continue learning the new developments withintheir respective fields. As software architects, we should be held to the samestandards.

No matter how well designed asolution is, one of the most important factors for determining the success ofan implementation is getting the developers to sign on to the game plan. The quickest way to get the developers to sign on is to gain theirrespect and trust. We all know the quickest way to gain a developers trust: yourcode is your currency. If you can show your developers that you’re not justsome pie in the sky day dreamer who can’t code his way out of a paper bag,you’ll hear less grumbling about the hoops you’re “making” them jump through toget data to show on the page when “I can get it done in less time by justbinding a dataset to a grid.”

Even though I’m not required to aspart of my job, I will frequently pick up some of the more intricate tasks.This serves two purposes: first it’s fun and helps me to keep my developmentskills sharp; second, it helps me demonstrate to my developers that I’m notjust blowing smoke where the sun doesn’t shine.

As an architect, your primary goalshould be to create a solution that is feasible, maintainable, and of courseaddresses the issue at hand. Part of knowing what is feasible in a solution ishaving knowledge of the effort involved in developing the elements of thesolution. Therefore,  I propose that if you design it, you should beable to code it.

76、A rose by any other name will end up as a cabbage

I overheard some people decidingthat they need more layers in their architecture. They were right, as ithappens; but going about it a little backwards. They were attempting to createa framework that would contain the business logic. Rather than solving somespecific problems they started with the idea that they want a framework thatwraps the database up and produces objects. And it should use object-relationalmapping. And messages. And web services. And it should do all sorts of coolstuff.

Unfortunately, since they didn't exactly know what cool stuff it would do, theydidn’t know what to call it. So they held a little competition to suggest aname. And that is the point at which you must recognise that you have aproblem: if you don’t know what a thing should be called, you cannot knowwhat it is. If you don’t know what it is, you cannot sit down and write thecode.

In this particular case, a quick browse throught the source control historyrevealed the depth of the problem. Of course, there were lots of emptyinterface "implementations"! And the really funny thing is that theyhad already changed the names three times with no actual code. When theystarted they called it ClientAPI -- the “client” refers to the customers of thebusiness, not client as in “client-server”-- and the final version was calledClientBusinessObjects. Great name: vague, broad and misleading.

Of course, in the end, a name isjust a pointer. Once everyone involved knows that the name is just a name andnot a design metaphor then you can all move on. However, if you can't agree ona name that is specific enough for you to know when it is wrong, then you mighthave some difficulty even getting started. Design is all about trying to fulfilintentions -- e.g., fast, cheap, flexible -- and names convey intentions.

If you can’t name it, you can’t write it. If you change the name 3 times, thenyou should stop until you know what you are trying to build.

By SamGardiner

This work is licensed under a Creative CommonsAttribution 3

77、Stable problems get high quality solutions

Real-world programming is not aboutsolving the problem that someone gives to you. In the computer scienceclassroom you must solve the binary-sort problem it’s given to you. In the realworld, the best architects don’t solve hard problems they work around them. Theskill is in drawing boundaries around diffuse and diverse software problems sothat they are stable and self-contained.

An architect should be able to look at a whole mess of concepts and data andprocess and separate them into smaller pieces or “chunks”. The important thingabout those problem chunks is that they are stable allowing them to be solvedby a system chunk that is finite and stable in scope. The problem chunks shouldbe:

    * Internally cohesive: the chunk is conceptually unified, soall of the tasks, data, and features are related
    * Well separated from other chunks: the chunks areconceptually normalized; there is little or no overlap between them


The person who is excessively good at doing this may not even know that theyare doing it, just as a person with a good sense of direction knows where theyare. It just seems to make sense to them to break up the tasks, data, andfeatures in a way that provides a nice edge or interface to the system. I’m nottalking about the actual interfaces of an object-oriented language, but systemboundaries.

For instance, a relational database management system has a very nice system boundary.It manages literally any type of data that can be serialized into a stream ofbytes and it can organize, search and retrieve that data. Simple.

What is interesting is that if the problem is stable then when it is solved, itis solved permanently. In five/fifty years time you might want to slap aweb/telepathic interface over it, but your core system won’t need to change. Thesystem is durable because the problem is durable.

Of course, the code needs to be pretty neat, but if the problem is neat thecode can be neat as there are no special cases. And neat code is good becauseit is easy to test and easy to review, and that means that the implementationquality can be very high. As you don’t have messy code you can concentrate onthings that are outside the domain of user-visible features like using reliablemessaging, distributed transactions, or driving up performance by usingmultithreading or even low level languages like assembly code; because theproblem isn’t changing you can concentrate on driving up the quality to thepoint where quality is a feature.

A stable problem allows you to create a system with a stable design; stabledesign allows you to concentrate on making an application that has very highquality.

By Sam Gardiner

This work is licensed under a Creative CommonsAttribution 3

78、It Takes Diligence

An architect’s job isoften portrayed as an activity focused on ingenuity and problem solving. Ingenuity is a key trait of successful architects.  However an equallyimportant characterization of the activities of a successful architect is‘diligence’.  Diligence can manifest itself in many ways, but ultimately itis an exercise in perseverance and paying the right amount attention to eachtask and each architectural goal of the system. 

Diligence goes handin hand with the mundane.  Successful architecture practices are in manyways mundane.  Effective architects often follow mundane daily and weeklychecklists to remind them of that which they already know academically, butfail to practice by habit.  Without such mundane checklists and remindersarchitects can quickly fall into software time, in which no measurable progressis achieved because a lack of diligence allowed the architecture to meander andviolate known academic principles.  It is important to realize in theseretrospectives of failed projects that in most cases it isn’t incompetence thatdrove failure, but rather the lack of diligence and a sense of urgency.

Diligence alsorequires an architect to succeed at the deceptively simple task of making andkeeping commitments.  These commitments are often disparate and canencompass a wide range of constraints and expectations.  Examples include:

·    Embracing the budget and time constraints ofthe customer

·   Performing all the work that makes thearchitect effective, not just the work the architect enjoys. 

·   Commitment to the process/methodology

·   Accepting responsibility

Atul Gawande, in histerrific book ‘Better:  A Surgeon’s Notes on Performance’ ¹, speaksof diligence in the medical community:

“True success in medicine is not easy.It requires will, attention to detail, and creativity. But the lesson I tookfrom Indiawas that it is possible anywhere and by anyone. I can imagine few places withmore difficult conditions. Yet astonishing success could be found ... what Isaw was:  Better is possible.  It does not take genius. It takesdiligence. It takes moral clarity. It takes ingenuity. And above all, it takesa willingness to try.”

¹ Gawande, Atul. Better: A Surgeon's Notes on Performance.Metropolitan Books, 2007.

By Brian Hart

This work islicensed under a Creative Commons Attribution 3

79、Take responsibility for your decisions

Software architects have to takeresponsibility for their decisions as they have much more influential power insoftware projects than most people in organizations. Studies of softwareprojects show over two-thirds of them either are outright failures or deliverunsuccessfully (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 effectivearchitectural decisions?

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

    * A decision has been put in writing because architecturaldecisions are rarely trivial. They must be substantiated and traceable.
    * A decision has been communicated to the people who executeit, and the people who will be affected directly or indirectly. Communication is all about creating shared understanding.

Second, review your architectural decisions periodically. Examining the resultsof your decisions against expectations. Identify architectural decisions thatremain valid and those that do not.

Third, enforce your architectural decisions. Many software projects getsoftware architects involved only in the design phase, then they move to otherprojects or the consultation contract ends. How can they ensure that theirdeliberate architectural decisions have been implemented correctly? Theirdecisions will be at best good intentions unless they follow-through with them.

Finally, delegate some decision making to others who are experts in a problemdomain. Many architects wrongly assume they have to make every architecturaldecision. Therefore, they position themselves as a know-it-all expert. Inreality, there’s no such thing as a universal technical genius. Architects haveareas in which they are quite proficient, areas in which they areknowledgeable, and areas in which they are simply incompetent. Adept architectsdelegate decisions about domain problems in which they are not proficient.

by Yi Zhou

This work is licensed under aCreative Commons Attribution 3

80、Don’t Be a Problem Solver

With some exceptions,architects used to be developers. Developers get rewarded for solvingprogramming problems, which are more local in scope than architecturalproblems. Many programming problems are small, tricky, algorithmicproblems. Such problems are frequently presented in programminginterviews, books, and university courses as if the problems exist ina vacuum. The trickiness is alluring and seductive. Over time, we beginto accept such problems out of hand. We do not ask if thisproblem is meaningful, or interesting, or useful, or ethical. We are notrewarded for considering the relation of this problem to a larger landscape. Weare trained to focus only on our solution, which is aggravated by the fact thatsolving hard problems is hard. We leap into action in programming interviews,which often begin by presenting us with some number of jelly beans we aremeant to sort according to an arbitrary set of constraints. We learn not toquestion the constraints; they are a pedagogical tool, intended to lead us todiscover what the teacher or interviewer or mentor already knows.

Architects anddevelopers learn to enter problem-solving mode immediately. But sometimesthe best solution is no solution. Many software problems need not be solved atall. They only appear as problems because we look only at the symptoms.

Consider managedmemory. Developers on managed platforms have not solved memory problems, norcould many of them do so if required; part of their solution means that theymostly just don’t have that problem.

Consider complexbuilds that require lots of interconnected scripts requiring the enforcement ofmany standards and conventions. You could solve that problem, and it would feelgreat to get it all to work, putting your best scripting skills and bestpractices to work. Our colleagues will be impressed. No one is impressed by us notsolving a problem. But if we can step back, and figure out that we aren’tsolving a build problem but rather an automation and portability problem, thismight lead you to a tool that abstracts it away.

Because architectstend to immediately enter problem-solving mode, we forget, or rather have neverlearned how, to interrogate the problem itself. We must learn, like a telephotolens, to zoom in and zoom out, in order to ensure the question is really framedproperly, and that we’re not merely accepting what we’re given. We must not be passivereceptacles for requirements, cheerfully ready at our post, handing out oursmartest solutions in the manner of a Pez dispenser.

Instead ofimmediately working to solve the problem as presented, see if youcan change the problem. Ask yourself, what would the architecturelook like if I just didn't have this problem? This can lead ultimately to moreelegant and sustainable solutions. The business problem still does need tobe solved, but not, perhaps, as immediately suggested. 

We have to break ouraddiction to “problems”. We love to get them, seeing ourselves on a Europeanbridge, as if we are secret agents who’ve just been handed a self-destructingbrown envelope containing our mission. Before considering your answer to aproblem, think what the world would look like if you just didn’t have thisproblem.

By Eben Hewitt

This work is licensed under a Creative Commons Attribution3

81、

82、Your Customer is Not Your Customer

As you work in requirements meetings to design software, pretend that yourcustomer is not your customer. It turns out that this is a very easy thing todo, because it is true.

Your customer is not your customer. Your customer’s customer is your customer.If your customer's customer wins, your customer wins. Which means you win.

If you're writing an ecommerce application, take care of the things that youknow people who will shop at that site will need. They'll need transportsecurity. They'll need encryption of stored data. Your customer may not mentionthese requirements. If you know that your customer is leaving out things yourcustomer's customer will need, address them, and communicate why.

If your customer willingly and knowingly doesn't care about certain importantthings that your customer's customer cares about—as happens from time totime—consider stepping away from the project. Just because Sally Customerdoesn't want to pay for SSL every year and wants to store credit cards in plaintext because it costs less to build, it's not okay to just agree. You'rekilling your customer's customer when you agree to work you know is a bad idea.

Requirements gathering meetings are not implementation meetings. Forbid thecustomer’s use of implementation-specific terms unless it's an absolute, orwell-understood problem. Allow your customer to express only the Platonicideal, his concept and goals, rather than dictating a solution or even usingtechnical terms.

So how do you maintain such discipline in these meetings, which can bedeceptively difficult? Remember to care for your customer’s customer. Rememberthat while your customer is writing your check, you must be clear that you needto honor best practices, so that you can make what the customer really needs,not just what they say they need. Of course, this takes lots of discussion, andclarity as to exactly what you’re doing and why.

Perhaps, as with so many things in life, this is best clarified by a poem. In1649, Richard Lovelace wrote "To Lucasta, on Going to the Wars". Itends with the line: “I could not love thee, dear, so much, / Loved I not honormore.”

 

We cannot love our customers so much, love we not their customers more.

ByEben Hewitt

This work is licensed under a Creative Commons Attribution 3

83、It will never look like that

It will never look like that. It is all too easy to fall into the trap of investing large amounts of time ina design and being confident that the implementation will come out thesame.  A detailed design can easily fool you into believing you have everyangle covered.  The greater the detail and the more in-depth the researchthe greater your confidence in it.  But it is an illusion: it will neverlook like that.

The truth is no matter how in-depth, how well researched and how well thoughtout your design it will never come out looking the same as in your head. Something will happen, an external factor may effect the design: incorrectinformation, a limitation, an odd behaviour in someone else's code. Or you mayhave got something wrong: an oversight, an incorrect presumption, a subtleconcept missed. Or something will change; the requirements, the technology, orsomeone may just find a better way(TM).

Those minor alterations in the design soon stack up and lots of minoralterations soon require that one big one has to be made. Before long youroriginal concept is on the floor in pieces and its back to the drawingboard.  You decide what you needed was more design, more detail, so backyou go and the next architectural vision is clearer, more radical, more perfectthan the last.  But before long the same thing happens, those changesstart to appear and shift your design and developers keep shoving in more and morestuff trying their best to work around the broken design but just breaking itmore and you end up screaming "of course it's got bugs; it was neverdesigned to do that!".

Design is a discovery process, as we implement we discover new information,often impossible to know up front.  By accepting that design is an ongoingand empirical process in a forever changing world, we learn that the designprocess must be flexible and ongoing too.  Clinging onto your originaldesigns and trying to force them through is only going to end up with oneresult so you need to learn to understand that it will never look like that.

By Peter Gillard-Moss

This work is licensed under a Creative CommonsAttribution 3

84、Choose Frameworks that play well with others

When choosing software frameworks asa basis of your system,
you must consider not only the individual quality and features of eachframework,
but also how well the set of frameworks that make up your system will
work together, and how easy it will be to adapt them to new software you may
need to add as your system evolves.  This means you must choose frameworksthat do not overlap and that are humble and simple and specialized.

It will be best if each framework or 3rd party library addresses
a separate logical domain or concern, and does not tread into
the domain or concern of another framework you need to use.

Make sure you understand how the logical
domains and concerns addressed by your candidate frameworks overlap. Draw aVenn diagram if you need to. Two data models that overlap substantially indomain, or two
implementations that address very similar concerns but in slightly
different ways, will cause unnecessary complexity: the slight differences
in conceptualization or representation must be mapped or patched with kludgyglue code.
Chances are you'll end up not only with complex glue, but also with the
lowest-common-denominator of the functionality or representative power of
the two frameworks.

To minimize the chance that any given framework
will overlap with another framework, choose frameworks that have a
high utility to baggage ratio, in the context of your system requirements.
Utility is the functionality or data representation that your project needs
from the framework. Baggage is the framework's sweeping, all-encompassing,
I'm-in-charge view of the world. Does it insist on mixing data representationand
control? Does its data model or set of packages and classes extend well beyond
what your system needs? Do you have to become a fundamentalist in theframework's
religion, and limit your choices of other frameworks to those of the correct
denomination? Does its excess complexity limit the kinds of things you can mix
with it? If a framework comes with lots of baggage, then that it had also
better be providing 75% of the functionality value in your project.

Your system should be comprised of mutually exclusive frameworks, each
of which may be a master of its domain, but which is also simple, humble,
and flexible.

by Eric Hawthorne

This work is licensed under a Creative CommonsAttribution 3

85、Make a strong business case

As a software architect, have you had a hardtime getting your architecture project well funded? The benefits of softwarearchitecture are obvious for architects, but are mythical for manystakeholders. Mass psychology tells us that “seeing is believing” is thestrongest belief for most people.  At the early phase of the projects,however, there is little to demonstrate to convince stakeholders of the valueof sound software architecture. It’s even more challenging in the non-software industrieswhere most stakeholders have little software-engineering knowledge.

Mass psychology also shows that most people believe in “perception isreality.” Therefore, if you can control how people perceive the architecturalapproach you propose, it’s virtually guaranteed that you control how they willreact to your proposal. How can you mange stakeholders’ perceptions? Make astrong business case for your architecture. People who have the budgetauthority to sponsor your ideas are almost always business-driven.

I have employed the following five steps to generate solid business casesto successfully sell my architectural approach many times in my career:

·   Establish the valueproposition. The value proposition is yourexecutive summary of why your organization’s business warrants a particularsoftware architecture.  The key for this is to compare your architecturalapproach with existing solutions or other alternatives. The focus should be puton its capability to increase the productivity and efficiency of the business,rather than how brilliant the technologies are.

·   Build metrics to quantify. The values you promise to deliver need to be quantified to a reasonableextent. The more you measure, the more you can bolster your case that soundarchitecture will lead to a substantial return. The earlier you establishmetrics, the better you manage people’s perceptions that help you sellresponsible architecture.

·   Link back to traditionalbusiness measures. It would be ideal if youcan translate your technical analysis into dollar figures. After all, the onlyconstant parameter in the traditional business measures is money. Find businessanalysts as your partners if you are not comfortable with financial work.

·   Know where to stop. Before you know where to stop, you need to prepare a roadmap thatcaptures a vision with each milestone on it tied directly to business values.Let the stakeholders decide where to stop. If the business value for eachmomentum is significant, you’re most likely to get continued funding.

·   Find the right timing. Even if you follow the above four steps to generate a solid business case,you may still not be able to sell your ideas if you pick the bad timing. Iremember one of my proposals did not get approved for a long time untilanother project turned out to be a total failure because of poorarchitectural design. Be smart on timing.

by Yi Zhou

This work islicensed under a Creative Commons Attribution 3

86、Pattern Pathology

Design patterns are oneof the most valuable tools available to the software architect.  Usingpatterns allows us to create common solutions that are easier to communicateand understand.  They are concepts that are directly associated with gooddesign.  This fact can make it very enticing to demonstrate ourarchitectural prowess by throwing a lot of patterns at a project.  If youfind yourself trying to shoehorn your favorite patterns into a problem spacewhere they don’t apply, you may be a victim of pattern pathology.

Many projects suffer from this condition.  These are the projects whereyou envision the original architect looking up from the last page in hispatterns book, rubbing his hands together and saying “Now, which one will I usefirst!?”.  This mentality is somewhat akin to that of a developer whobegins writing a class with the thought “hmmm, what class should Iextend?”.  Design patterns are excellent tools for mitigating necessarycomplexity but like all tools, they can be misused.  Design patternsbecome a problem when we make them the proverbial hammer with which we muststrike every nail.  Be careful that your appreciation for patterns doesn’tbecome an infatuation that has you introducing solutions that are morecomplicated than they need to be.

Stamping patterns all over a project unnecessarily is over-engineering. Design patterns are not magic and using them doesn’t automatically qualify asolution as good design.  They are reusable solutions to recurringproblems.  They have been discovered and documented by others to help usrecognize when we’re looking at a wheel that’s already been invented. It’s our job to identify problems solved by these solutions when they arise andapply design patterns appropriately.  Don’t let your desire to exhibitdesign pattern knowledge cloud your pragmatic vision.  Keep your sightsfocused on designing systems that provide effective business solutions and usepatterns to solve the problems they address.

by

Chad LaVigne

This work is licensed under a Creative CommonsAttribution 3

87、Learn a new language

To be successful as an architect, you must be able to make yourselfunderstood by people who don’t speak your native tongue. No. I’m not suggestingyou learn Esperanto or even Klingon, but you should at least speak basicBusiness, and Testing. And, if you aren’t fluent in Programmer, you should makethat a top priority.

If you don’t see the value in learning other languages, consider the followingscenario. The business people want a change made to an existing system, so theycall a meeting with the architect and programmers to discuss it. Unfortunately,none of the technical team speaks Business and none of the business peoplespeak Programmer. The meeting will likely go something like this:

·   A business person talksfor a minute about the need for a relatively simple enhancement to an existingproduct, and explains how making the change will enable the sales team toincrease both market and mind share.

·   While the business personis still speaking, the architect starts sketching some kind of occult symbolson a notepad and enters into quiet argument with the one of the programmers intheir strange multi-syllabic tongue.

·   Eventually the businessperson finishes and looks expectantly at the architect.

·   After the whisperedargument completes, the architect walks to the whiteboard and begins drawingseveral complex diagrams that are supposed to represent multiple views of theexisting system while explaining (in complex technical terms) why the requestedenhancement is virtually impossible without major changes and may actuallyrequire a complete redesign/rewrite of the entire system.

·   The business people (whounderstood little of the diagram and less of the explanation) are openlystunned and find it hard to believe that something so simple would require suchmassive changes. They begin to wonder if the architect is serious or justmaking things up to avoid making the change.

·   Meanwhile, the architectand programmers are just as surprised that the business people don’t see howthe “minor” change will require major modifications to the core systemfunctionality.

And therein lies theproblem. Neither group understands how the other thinks, or what half of thewords they use means. This leads to mistrust and miscommunication. It’s a basicpsychological principle that people are more comfortable with those who aresimilar to them as opposed to those who are different from them.

Imagine how the above scenario might change if the architect were able toexplain the issues to the business folk in terms they understand and relay thebusiness issues to the programmers in terms they understand. Instead of surpriseand mistrust, the result would be agreement and approval.

I’m not saying that learning multiple languages will cure all your problems,but it will help prevent the miscommunications and misunderstandings that leadto problems.

For those of you who decide this makes sense, I wish you success on yourjourney. Or, as the Klingons say, Qapla!

by Burk Hufnagel

This work islicensed under a Creative Commons Attribution 3

88、Don't Be Clever

General intelligence, resourcefulness(足智多谋), thoughtfulness（慎重）, a breadth（宽度） and depth of knowledge, and an affinity forprecision are laudable(值得称赞的) qualities in anyone, particularly prized in architects.

 Cleverness, however, carries（意味） a certain additional connotation（内涵）. It implies anability to quickly conceive of（构思出） asolution that may get you out of（避免） a jam（困境）, but that ultimately rests on（停留在） a gimmick（花招）, a shell game, or a switcharoo. We remember clever debaters（辩论者） from high school--always able to playsemantics or work the logical fallacies（谬论） towin the point.

Clever software is expensive, hard to maintain, and brittle（脆弱的）. Don't be clever. Be as dumb（笨的） as you possibly can and still create theappropriate design. The appropriate design will never be clever. If clevernessappears absolutely required, the problem is incorrectly framed; reset theproblem. Reframe it until you can be dumb again. Work in rough chalk sketches（草图）; stay general（保持常规）.Let go of（放开）theflavor of the day（短暂的时髦）.It takes（接受） a smartarchitect to be dumb.

It is our cleverness that allows us to trick software into working. Don'tbe the attorney who gets your software off on a technicality（学术性）. We are not Rube Goldberg. We are notMacGyver, ever-ready（随时准备） topull some complicated design out of our hats having been allowed only a paperclip, a firecracker（鞭炮）, anda piece of chewing gum. Empty your head and approach（动手处理） the problem without your extensive knowledgeof closures（关闭） and generics and howto manipulate object graduation in the heap. Sometimes of course, such stuff isexactly what we need. Butless often than we might think（但是常常比我们可能想象的更少）.

More developers can implement and maintain dumb solutions. In dumbsolutions, each component can only do one thing. They will take less time tocreate, and less time to change later. They inherit optimizations from thebuilding blocks you're using. They emerge from the page as a living process,and you can feel their elegance（优雅） andsimplicity. Clever designs will stay stubbornly（顽固地） rooted（生了根般地）;their details are too embroiled（使纠缠不清） inthe overall picture. They crumble（崩溃） ifyou touch them.

 注：主要是告诉架构师不要追求时髦，而要尽量让解决方案简单。

By Eben Hewitt

This work is licensed under a Creative Commons Attribution 3

89、Build Systems to be Zuhanden

We build tools. The systems that wemake have no other reason to exist (nor we to get paid) than to helpsomeone, usually someone else, do something.

Martin Heidegger, an influential German philosopher ofthe 20th Century, explored the ways that people experience tools (and moregenerally "equipment") in their lives. People use tools towork towards a goal and the tool is merely a means to an end.

During successful use a toolis zuhanden ("ready-to-hand", having the property of"handiness"). The tool is experienced directly, it is usedwithout consideration, without theorisation. We grasp the tool and use it tomove towards our goal. In use, it vanishes! The tool becomes an extension ofthe user's body and is not experienced in its own right. One sign of a toolbeing zuhanden is that it becomes invisible, unfelt, insignificant.

Consider what it feels like tohammer a nail or to write with a pen. Think about that immediacy. Think aboutthe way the tool seems to be a seamless extension of your body.

Alternatively, and usuallywhen something has gone wrong with it, the user may experience a toolas vorhanden ("present-at-hand"). The tool is isolated fromthe goal, it lies before us demanding attention. It becomes a topic ofinvestigation in its own right. The user is no longer able to proceed towardstheir goal but must deal first with the tool, without itdoing anything to move them towards their goal. As technologistswe tend to experience the systems we build for users as vorhanden while webuild them, and again when we receive defect reports. For us, the tool is quiteproperly an object of enquiry, of theorising, of investigation. It is a thingto be studied.

However, it is crucial to theirsuccess that the users experience the tools we build for them as zuhanden. Areyour systems architected to be invisible in use? Does the user interfacefall naturally to hand? Or do your systems keep demanding attention,distracting users from their goal?

By Keith Braithwaite

This work is licensed under a Creative CommonsAttribution 3 

Note: Heidegger's writing can beextremely challenging. A lot of it is based on arguments of a kind that caninfuriate thinkers in the more mathematical Anglo-Saxon tradition ofphilosophy. 

Perhaps the best approach is thougha series of graded exposures. Inwood's "Heidegger a very shortintroduction" is a good way in. Harman's "Heidegger Explained"is a little more meaty. Harman's "Tool-Being" focusses on thevorhanden/zuhanden distinction in great depth, and takes itin interesting directions.

After that the genuine article isHeidegger's own "Being and Time", Part 1, Section III, Para 15: The Being of the Entities Encountered in theEnvironment.

90、Find and retain passionate(充满热情的) problem solvers

Putting together a teamof outstanding developers is one of the most important things you can do toensure the success of a software project.  While the concept of keepingthat team together does not seem to get as much lip service（空口的应酬话）, it is equally important. Therefore, you need carefully select your development team and diligently（坚持不懈地） protect it once assembled.

Most people probably agree that finding top-notch（拔尖的） developers requires thorough（彻底的） technical interviewing.  Butwhat does thorough mean exactly?  It doesn’t mean requiring candidates（候选人） to answer difficult questions aboutobscure（晦涩的） technical details.  Screening（筛选） for specific technical knowledge isdefinitely（明确地） part of the process but turning aninterview into a certification test will not guarantee success.  You aresearching for developers with problem solving skills and passion.  Thetools you use are sure to change; you need people who are good at attackingproblems regardless of the technologies involved.  Proving（证明） someone has the ability to recite（叙述） every method in an API tells youvery little about their aptitude（聪明） or passion for solving problems.

However, asking someone to explain their approach to diagnosing a performanceproblem gives you great insight into their methods for problem solving. If you want to learn about developer’s ability to apply lessons（教训） learned, ask what they would changegiven the chance to start their most recent project anew（重新）. Good developers are passionateabout their work.  Asking them about past experience will bring out thatpassion and tell you what correct answers to technical trivia（琐事） questions cannot.

If you have been diligent in staffing a strong team, you want to do whatever iswithin your power to keep the team together.  Retention（保持力） factors such as compensation（补偿） may be out of your hands but makesure you’re taking care of the little things that help to foster（培养） a healthy work environment. Good developers are often strongly motivated（激发） by recognition（承认）.  Use this fact to youradvantage and acknowledge stellar（主要的） performances.  Finding great developers isdifficult.  Letting people know they are valued is not（让人知道他们是有价值的却不难）.  Don’t miss simplechances to build morale（士气） and boost productivity.

Be careful with negative re-enforcement（援助）.  Too much of it may stifle（抑制） a developer’s creativity and reduceproductivity.  Worse yet, it’s likely to create dissension（纠纷） among the team.  Gooddevelopers are smart; they know they’re not wrong all of the time.  Ifyou’re picking apart（把撕碎） the minutia(细目) of their work, you’lllose their respect.  Keep criticism constructive and don’t require thatevery solution look like it came from you.

Theimportance of staffing your development team correctly can’t be overstated（夸大）.  These are thepeople who do the heavy lifting.  When it comes to estimates, they’re alltreated as equal producers. Make sure it’s tough to crack the starting lineup（阵容） and once you’ve got a winning teamgo the extra mile to keep it together.

注：主要讲怎样面试开发者，以及如何对待开发者。

by

Chad LaVigne

This work is licensed under a Creative CommonsAttribution 3

91、Software doesn’t really exist

Software engineering isoften compared to（比喻为） well-establisheddisciplines such as civil engineering.  There’s a problem with these analogies（类比）; unlike the very tangible（切实的） products created by thesetraditional practices, software doesn’t really exist.  Not in thetraditional sense anyway. Those of us in the world of ones and zeroes aren'tconstrained by the same physical rules that bind classic engineeringparadigms.  While applying engineering principles to the software designphase works well, assuming you can implement the design in the same manner usedby more traditional engineering approaches is unrealistic.

Both business and software are living, moving entities. Business requirementschange rapidly due to things like newly acquired business partners andmarketing strategies. This makes it very difficult to approach a softwareproject in the same manner as a traditional engineering pursuit（经营） such as bridge construction. It is highly unlikely that you'll be asked to move the location of a bridgehalfway through a construction project. However, it is very likely that theacquisition of a business partner will require you to add support fororganization-based content management to an application.  This comparisonshould put things into perspective.  We often say that softwarearchitecture decisions are difficult to change but not nearly（远非） so much as things that areliterally and figuratively（比喻地）set in stone.

Knowing the products we build are pliable（易受影响的） and that the requirements surrounding them are likely tochange puts us in a different position than someone building an immovableobject.  Engineering endeavors（竭力） of the physical flavor are much easier to implement in a"plan the work, work the plan" nature.  With software thingsneed to be tackled in more of a "plan the work, massage the plan"fashion.

These differences aren’t always bad news, at times（有时） they can be advantageous.  Forexample, you're not necessarily constrained to building the components of asoftware system in a specific order so you can tackle high-risk issuesfirst.  This is in direct contrast to something like bridge constructionwhere there are many physical limitations surrounding the order in which tasksare accomplished.

However, the flexibility of software engineering does present some issues, manyof which are self-imposed（自己强加的）.  As architects weare very aware of the "soft" nature of our craft and we like to solveproblems.  Worse yet, the business owners are vaguely（含糊地） aware of these facts.  Thismakes it easy for them to push big changes.  Don’t be too eager toaccommodate large architectural changes just because it appeals to（要求） your solution-providingnature.  Decisions like that can break an otherwise healthy project.

Remember that a requirements document is not a blueprint and software doesn’treally exist.  The virtual objects that we create are easier to changethan their physical world counterparts（配对物）, which is a good thing because many times they’re requiredto.  It’s ok to plan as though（好象） we’re building an immovable object; we just can't besurprised or unprepared when we’re asked to move said（上述的） object.

注：说明了变化是不可避免的，我们可以像创建一个静止对象一样去计划，但是当我们被要求移动对象的时候，不能感到吃惊和没有准备。

by

Chad LaVigne

This work is licensed under a Creative CommonsAttribution 3

92、Pay down（当场支付） your technical debt（债务）

On any project that is in production(i.e. it has customers that are using it), there will come a time when a changemust be made; either a bug needs fixing, or a new feature must be added. Atthat point there are two possible choices; you can take the time needed to"do it right", or you can take one or more "shortcuts" andtry to get the change out the door sooner.

Generally, the business people (sales/marketing and customers) will want thechange made as quickly as possible while the developers and testers will bemore interested in taking the time to properly design, implement, and test thechange before delivering it to the customers.

As the project's architect you'll have to decide which makes more sense andthen convince the decision makers to take your advice; and as with mostarchitectural issues there is a trade-off（平衡） involved. If you believe the system is reasonably stablethen it may make sense to go the "quick and dirty" route and get thechange into production quickly. That's fine, but you need to know that in doingso your project is incurring some "technical debt" which mustbe repaid later.  Repayment, in this case, means going back and making thechange in the way you would have if you'd had the time and resources to do itright the first time.

So why the concern over making changes properly now versus later? It's becausethere's a hidden cost to making these quick and dirty fixes. For financialdebts the hidden cost is called "interest" and most anyone with acredit card knows how expensive just paying the interest on a debt can be. Fortechnical debt, interest takes the form of instability in the system, andincreased maintenance costs due to the hacked in changes, the lack of properdesign, documentation, and/or tests. And, like financial interest, regularpayments must be made until the original debt is repaid.

Now that you understand a bit more about the true cost of technical debt, youmight decide the price is too high and you can't afford the cost. But when it'sa choice between having the developers get the fix out as quickly as possibleortaking（接受） a severe financial hit（打击）, it generally makes sense to getthe fix out quickly. So take the hit and get the change into production ASAP（尽快）, but don't stop there.
 
Once the fix is in production, have thedevelopers go back and fix it properly so that it can be included in the nextscheduled release.This is the equivalent of charging somethingon your credit card and then paying off the balance at the end of the month soyou don't get charged interest. This way you can provide the fast changes thebusiness needs, while keeping your project out of debtor's prison.

注：有时必须将变更尽可能快地商用，可能造成设计，文档，测试都很缺乏，一旦商用后，我们回来后要立刻把这些都补上去，争取在下一个发布版本中把债还了。

by Burk Hufnagel

This work is licensed under a Creative CommonsAttribution 3

93、You can't future-proof(不会过时的技术) solutions

Today's solution is tomorrow’s problem.

No one can predict the future. Ifyou accept this as a universal truth, then the question becomes how far(到什么程度) ahead is the future? Onedecade? Two years? Twenty minutes? If you can’t predict the future then youcan’t predict anything beyond right now. This very moment and the ones thatpreceded it are all you are know until the next moment occurs. This is thereason we have car accidents – if you knew you were going to have an accidenton Thursday you would probably stay home.

Yet we see(注意到) software architects tryto design systems that will be, for lack of（因缺乏） a better term, "future proof" all the time. It’s simplynot possible to future proof an architecture（不可能有永不过时的架构）. No matter what architectural decision you make now, thatchoice will become obsolete（过时的） eventually（最后）. The cool programming language youused will eventually become the COBOL of tomorrow. Today’s distributedframework will become tomorrows DCOM. In short, today’s solution will always betomorrow’s problem.

If you accept this fact that thechoices you make today will most certainly be wrong in the future, then it relieves youof（使你消除） the burden（负担） of trying to future proof yourarchitectures. If any choice you make today will be a bad choice in the futurethen don’t worry about what the future will hold, choose the best solution thatmeets your needs today.

One of the problems architects havetoday is analysis paralysis（瘫痪） and a big contributionto that problem is trying to guess the best technology for the future. Choosinga good technology for right now is hard enough, choosing one that will berelevant in the future is futile(徒劳的). Look at what your business needs now. Look at what thetechnology market offers now. Choose the best solution that meets your needsnow because anything else will not only be wrong choice tomorrow, but the wrongchoice today.

注：为当前选择一个好的技术都非常困难，更不要说选择一个适合将来的。难道说架构师就不需要预见性吗？

By Richard Monson-Haefel

This work is licensed under a Creative CommonsAttribution 3

94、The User Acceptance Problem

People aren’t always happy about new systems or major upgrades. This can pose（形成） a threat（威胁） to the successfulcompletion of a project.

It’s not uncommon（罕有的） for people to disagree with the decision to implement a new system -especially at the beginning.  This should be expected（料到） and the reasons noted. However, initial reactionsto a new system is less of a concern than a sustained negative reaction.

Your goal as an Architect is to be aware of and measure the threat ofacceptance problems and work towards mitigating（减轻） those threats. To do this you have to becognizant of（认识到） them and consider thereasons for them.  Some of the more common reasons are:

·   1.     People may have concerns about the need for a new system (and subsequentretirement of an old system). This can also include fear（害怕） of loosing（不稳定的） functionality or loosing influence or power when roles change.

·   2.     People fear new (unproven) technology.

·   3.     People have cost/budget concerns

·   4.     People simply do not like change.

Each of these reasons requires different possible solutions. Some of which youcan address and others you can't. You have to recognize the difference and dealquickly with those that you can. Start early, having discussions with your endusers about the new system and its real andperceived（感到） benefits anddisadvantages.  The most effective long term solution is to use the designof the system itself to address（陈述） the concerns（利害关系）. Other effective solutions include training, scheduled systemdemonstrations (early in the project lifecycle) and sharing knowledge of whatusers will get with a new system.

A “Project Champion” can help avoid user acceptance problems. Ideally thisshould be a person that represents the user group or stakeholders. Theysometimes have to be convinced themselves. If there is none then push for onefrom the very beginning. Once you've recruited a Project Champion, give themyour assistance in every way you can.

注：在实际上中确实有这个问题，我就不喜欢新技术，怎么才能让我接受新技术？这个条款就讲这个的。拿我来说的话，首先应该给我说明新技术的好处，然后得给我讲明使用新技术是多么的简单，建立信心。满足这两条之后，我估计就愿意用了。

Norman Carnovale

This work islicensed under a Creative Commons Attribution 3

95、The Importance of Consommé

A consommé(肉煮的清汤) is an extremely clarified broth (n.肉汤), usually made with beef or veal(小牛肉), served as(可作...用) a delicate(精致的) soup. A well-made consommé is perfectlyclear. It is considered challenging and time-consuming to make, because thereis only one way to remove the fat and other solids that cloud(玷污)the broth, and gain the absolute clarity the dish requires: repeated, simple, fine-grained(有细密纹理的) straining. This straining again and again, this hyper（超）-conscious （特别注意的）refining of the mixture, createsan intensely rich flavor. It’s as if to taste a consommé is to taste the very essence（本质）of a thing（品汤就好像品尝事物的本质一样）. That is, in fact, the point（要点） of the dish(菜肴).

In culinary(厨房的) schools in America, a simple test is administered（给予） tostudent chefs(厨师) making consommé: the teacher drops a dime(一角硬币)into your amber broth; if you can read the date on the dime resting at thebottom of the bowl(碗), you pass. If you can't, you fail.

Software architecture requires a continual refinement(提炼) of thought, a repeated straining of ideasuntil we have determined（确定） the essence of each requirement in the system. We ask, like Hamlet（哈姆雷特）holding Yorick’s skull（头骨）, what is this thing? Whatare its properties? Its relations? We clarify our concepts, to make therelations within the architecture verifiably true, internally consistent.

Many missed(未觉察) requirements and bugs in software can be traced(回溯) toambiguous(不明确的), general(概括的)language. Ask customers, developers, analysts and users the same questionsrepeatedly, until they are drowsy(昏昏欲睡的) with boredom(厌倦). Now disguise(伪装) your question to pose it in a different way,like an attorney(律师) looking for a snag in the alibi(犯罪现场),to tease（通过持续的哄骗而得到） out anything new, any differences or contradictions（矛盾）. Strain and strain again.

Focus on what can be removed from the concepts presented in the architecture,the nouns that compose them, to determine their essence. Bring surgical（外科手术的） precision（精确度） to the language you find in your requirements, rejecting ambiguity, generality（概括性）, unwarranted assumptions,or extraneous（无关系的） verbiage（空话）. This serves to make yourconcepts richer, more robust. Reduce and reduce again.

Test statements by asking “Would you make the same statement（陈述） if I appended ‘always and forever and in every circumstance’ to it?"People resist committing to absolutes like this, and must refine their words.Force representations of concepts through a linguistic sieve(滤网) to clarify them. Do this again, until youare left with only the exhaustive list of simple and verifiably true statementsthat describe the essential nature the system.

You'll know when the architecture is finished: when you can look through it andread the date on a dime.

注：简单一点说就是去伪存真，实际操作起来较难。 

By Eben Hewitt

(edited by RMH 9/26/2008)

Thiswork is licensed under a Creative CommonsAttribution 3

96、For the end-user, the interface is the system（对终端用户来说，界面就是系统）

There are too many good products hidden behind bad user-interfaces. Theend-user will access the system through its user interface. If the quality ofthe user's experience while（当） interactingwith your product suffers, then his impression（印象） of your product will suffer（受损害）, no matter howtechnologically advanced and path-breaking（开创性的） your product might be（当用户和你产品交互时的体验质量受到损害，那么用户对你产品的印象将会受到损害，无论你产品的技术是多么的先进和开创性）.

The user interface is an important component of architecture and an often-neglected（常常被忽视）one. The Architect should enlist（征募） the services of specialists such as user experience designer andusability experts. The user interaction experts along with the architect candrive the interface design as well as its coupling with the internal mechanisms（用户交互专家和架构师一起工作能够推动界面设计及界面和内部机制的耦合性）. Involving user-interface experts at an early stage and throughout theproduct development phases ensures（让用户界面专家在一开始和整个产品开发阶段都参与能确保） that the final product is polished（优美的） and the integration of the user interface with the product is seamless.The Architect should also look at（考虑） doing user-interaction testing while the product is still in beta withactual end-users and incorporate their feedback into the final product.

Often the usage of a product changes over time as technology changes andfeatures are added. The Architect should ensure that user-interface changeswith the architecture reflecting the expectations（期望） of the users.

User-interactions should be one of the goals of the complete productarchitecture.  In fact user-interaction should be an integral（构成整体所需要的） part of the decision-making（决策）process for architecture trade-offs and internal product documentation as muchas robustness and performance. Changes in user-interaction design should becaptured over time, just like code. This is especially true in products wherethe user-interface is written in a different programming language than the restof the product.

It is the architect's responsibility to make the most common interactions notonly easy but also rewarding（有价值的） for the end-user. Better user-interfaces lead to happier customers, whichhelps improve customer productivity. If your product helps people become moreproductive then it will contribute to the business bottom-line（结果）.

注：道理简单，大家都知道。但是具体做起来难，比如我们项目组能招聘界面方面的专家吗，不能，所以我们的界面只能是业余的。

By Vinayak Hegde

(edited by RMH on 9/26/2008)

This work islicensed under Creative Commons Attribution License 3

97、Great software is not built, it is grown(好的软件不是一次性构建的，而是采用渐增的方式成长起来的)

As an architect you are tasked with（被分配…任务） providing the initialstructure and arrangement of software systems that will grow and change over time（随着时间）, will have be to reworked（修改）, will have to talk toother systems, and almost always in ways you and your stakeholders（股东） did not foresee（不能预见）. Even though we are called architects, and we borrow many metaphors（比喻说法） from building andengineering, great software is not built, it is grown.

The single biggest predictor（预报因子） of software failure is size; on reflection there's almost no benefit tobe had from starting with a large system design（一上来就设计大系统的做法基本上没有任何优点）. Yet at some point we will all be tempted to do exactly that（但是有时我们恰恰被诱惑那样做）. As well as being prone to（倾于） incidental complexity and inertia（惯性）, designing large systems upfront（adv.在最前面） means larger projects,which are more likely to fail, more likely to be un-testable, more likely to befragile(脆弱的), more likely to have unneeded（不需要的） and unused parts, more likely to be expensive, andmore likely to have a negative political dimension.

Therefore resist（要忍住） trying to design a large complete system to "meet or exceed"the known requirements and desired properties（特性）, no matter how tempting that might be（无论多么诱人）. Have a grand vision, but not a granddesign. Let you and your system learn to adapt as（当） the situation andrequirements inevitably（不可避免） change（当情况和需求不可避免地改变时，让你和你系统学会去适应）.

How to do this? The best way to ensure a software system can evolve（进化） and adapt is to evolveand adapt it from the very outset（初期）. Inducing（促使） a system to evolve means starting with a small running system, a workingsubset of the intended（预期的） architecture - the simplest thing that could possibly work. This nascent（初生的） system will have manydesirable properties and can teach us much about the architecture that a largesystem, or worse, a collection of architectural documents never can. You aremore likely to have been involved in its implementation. Its lack of surfacearea will be easier to test and therefore less prone to coupling. It willrequire a smaller team, which will reduce the cost of coordinating the project.Its properties will be easier to observe. It will be easier to deploy. It willteach you and your team at the earliest possible moment what does and does notwork. It will tell you where the system will not evolve easily, where it islikely to crystallize（哪儿需要明确）, where it is fragile. Where it might break. Perhaps most important, itwill be comprehensible and tangible（可感知的） to its stakeholders from the beginning, allowing them to grow into theoverall design as well.

Design the smallest system you can, help deliver it, and let it evolve towardsthe grand vision. Although this might feel like giving up control, or evenshirking your responsibilities, ultimately your stakeholders will thank you forit. Do not confuse（混淆） an evolutionary approach with throwing requirements out, the dreaded（讨厌的） phasing, or building one to throw away.

注：既不是一个大的设计，又要能进化和适应；既不是砍掉需求，也不是验证一个东西后就丢掉。这也太难把握了！看了几遍how to do this也没明白具体怎么做，呵呵！

 by  Billde hÓra

 (edited by RMHSept. 26, 2008)

Thiswork is licensed under a Creative Commons Attribution3

Website:http://97-things.near-time.net/wiki/97-things-every-software-architect-should-know-the-book