摘自：http://msdn.microsoft.com/en-us/architecture/cc505969.aspx
Contents
Introduction
A-Z Guide to Being an Architect
Conclusion
Introduction
Being an architect isn't just about baffling people with unusual diagrams that only make sense when the author is in the same room. No longer can an architect wave a hand judgmentally and dismiss an idea as being "inconsistent with the prescribed architecture." These days, an architect has a lot of diverse responsibilities: to the business, the team, the vision, the technology, and even the wider world.
In this article, the authors provide a handy A-Z guide to being an architect. Good luck, and may all your architectures be "n-tier"—which, given that "n" can be any value from 1, and "tier" is just a metaphor for lumps of similar code, seems quite likely... .
A-Z Guide to Being an Architect
A Is for Advocate
"I think you'll find that you really don't want to do it like that."
Architects have to explain and advise on technical issues to business stakeholders. They also have to be able to advise delivery teams on how to build. This advice is the currency of an architect; invested wisely, it will return goodwill and trust. The architect is asked for advice, because it is the architect's job to "see the whole."
See also: Abstraction, Agile, Acrobat, Availability, Analysis, Applications
B Is for Balance
"A little more to the left. Keep going. A bit more. Not that far. Sorry."
All decisions involve trade-offs—for example, adding a security measure may hurt performance. It is the architect's lot to make the right trade-off. Architecture may be a zero-sum game, but knowing what the system is intended to achieve enables the architect to choose the trade-offs that make the system successful. Of course, where there are competing objectives, it falls to the architect to explain the issue and seek resolution through prioritization of the objectives.
See also: Best Practice, Benchmarks, Building Blocks
C Is for Coach
"Work through the pain!"
With so many choices for the implementation of a solution, architects cannot simply dictate to development teams their notion of the "architecture." They are now called upon to coach development teams. Softer skills are needed: asking how and why rather than instructing "do this" and "do that." This is a Good Thing. Development teams who understand the reasons for the architecture are more likely to commit to it and are likely to do a better job of implementing it. Architects can also begin to spot talent within development teams and offer useful career progression opportunities.
See also: Communication, Champion, Context, Collaboration, C#
D Is for Dependencies
"What happens if I unplug this? Oh!"
The relationships among the components that make up anarchitecture are of fundamental importance. Dependencies are inevitable but should be as few and as manageable as possible. Draw a diagram and map the dependencies. Circles, whether direct (A depends on B and vice versa) or indirect (A depends on B which depends on C which depends on A) are a Bad Thing. If many things depend on D, then D needs to be stable because changing it will have a significant effect.
See also: Design, Development, Delivery, Domain, Documentation
E Is for Evangelist
"Let me show you something really cool."
Architects need to be advocates for the choices they have made; others need to believe in the ideas, frameworks, and guiding values of an architecture. Evangelism is about telling stories to different people. A simple segmentation may be a technical versus business audience, but there are really many differing audiences within that. The architecture needs to have a compelling story for each. An evangelist is able to synthesize and simplify complex scenarios for the benefit of common understanding.
See also: Enterprise, Engineer, Enthusiast
F Is for Frameworks
"How do I get there?"
Creating the architecture for a solution may be difficult. Creating the architecture for multiple solutions is harder—especially, given time pressures and the integration between solutions. An architecture framework is a structure that removes some of the wheel reinvention that would otherwise occur. It provides tools, methods, and a common vocabulary for the process of creating an architecture. An architecture framework can be considered to address the how of architecture.
See also: Facts, Functionality, F#, Firewall
G Is for Governance
"It is the opinion of the subcommittee..."
There comes a time, as they say, when you have to put on the suit if you're serious about doing business. Control is an important part of realizing an architectural vision. Regardless of the model of IT—centralized, decentralized, or federated—there will be competing requirements of equal value. A good architecture needs to be able to flex to differing needs, but not so much that the values of the architecture are lost to the immediate, possibly short-term, must-haves of the business. Equally, good governance can give a positive, dashboard-style view on technology for the business. Common understanding is always a Good Thing.
See also: Generative Programming, Generalist
H Is for Human Dynamics
"The system would have been a success if it hadn't been for those pesky users!"
Understanding how people interact with each other and the systems that support them is crucial to delivering successful solutions. The dynamics of each project and team will be different; the stakeholders' relationships and motivations may be unique to a given project. Knowing how to navigate human relationships is a key skill of good architects and good leaders.
See also: Heterogeneous Environments, Heated Debates, High Performance Computing
I Is for Innovation
"The lifeblood of any organization"
Most products can be viewed as a cycle of invention, innovation, commoditization, and redundancy. Invention is costly, slow, and can require luck and big leaps in thinking. By commoditization time, the game is up, and harnessing the work of others is probably the best option. Typically, therefore, it is the innovation space where advantages—efficiency, competitive differentiation, and so forth—can be achieved through perhaps smaller, but no less valuable evolutions and revolutions of existing ideas and solutions. Small teams can push for innovation constantly and take chances to make their name. Larger groups and organizations may not be able to move as quickly, but they need to enable innovation to percolate from individuals and teams and develop mechanisms for making the best of this inspiration and imagination. Architects can be the mouthpiece for the technical teams, and the ears of the business for innovation.
See also: Integrity, Inspiration, Infrastructure
J Is for Judgment
"With great power comes great responsibility."
When the discussion is done and a technical decision must be made, then an architect is going to have to exercise judgment. The team entrusts the architect to make these judgment calls, and the architect's good judgment gives confidence to the team. For better or for worse, a series of good or bad calls may be seen to characterize the architect: conservative or wise, impulsive or prescient, biased or brave. Exercising good judgment is vital, but in practice, even good judgment will sometimes turn out to be wrong. Don't worry about making a mistake; worry more about not doing anything.
See also: Java, Just In Time
K Is for Knowledge
"If only I knew then what I know now."
Knowledge is a key architectural tool. Of course, being aware of the boundaries of your knowledge is a Good Thing. Areas that are known unknowns are ripe for proof-of-concepts and other knowledge-building exercises. Unknown unknowns, on the other hand, are Bad Things: They are the architectural equivalent of gremlins. Knowledge of technology is only one, albeit important, domain that an architect needs to command. An architect also needs to know about the nontechnical factors that will be in play, such as organizational structures, enterprise strategy, business processes, and development methodologies.
See also: Kernel, Keyboard
L Is for Leadership
"I'm behind you all the way."
Leadership is vital for an architect and typically takes two forms: thought leadership and team leadership. As guardian of the architecture and the values behind the architecture, the architect is thought leader: The architect continually reevaluates the vision and re-presents the "newer, shinier" vision, with comment on competing visions and emerging technology. As team leader, an architect may not be required to perform line management duties, but may be called upon to be an icon for the rest of the team, providing confidence, insight, motivation, and inspiration.
See also: Lean, Linux, Latency, Load Balancing
M Is for Modeling
"So, to help us visualize how this might work, I made this model using nothing but twigs and guitar strings."
A model is a representation of something—for example, a business process or computer system. Views of a model provide a way to communicate and understand ideas about the problem and the solution. Different views address different concerns—overloading one view in an attempt to address multiple concerns will either lead to an overcomplicated view or an oversimplified understanding. Having a shared notation for representing these views of a model can simplify conversations about the model—although, if the notation becomes too complex, this benefit is soon lost.
See also: Management, Maintainability, Messaging
N Is for "N-tier"
"A house of cards"
Data Layer, Business Logic Layer, User-Interface Layer. Job done. Well, not quite. N-tier is a vague term at best, and doesn't really say anything more than pointing to the idea that there should be some kind of separation of concerns between various chunks of code. With Service-Oriented Architecture (SOA), and, most recently, the explosion in cloud services—either as back end (cloud storage for example) or front end (such as Facebook)—actually describing the architecture can be harder than building it. We're fans of the "Petri dish" approach: concentric circles usually containing square boxes as if suspended in agar jelly.
See also: Needs, Networks, Nonfunctional Requirements, .NET
O Is for Object Orientation
"Encapsulate this!"
Object Orientation (OO) is a programming paradigm that rose to prominence in the 1990s. It can be thought of as a way to conquer complexity by dividing a big problem or program into bite-size, digestible, and, of course, logically coherent chunks. Object orientation is often referred to as OO and sometimes as OOP (Object-Oriented Programming), which is only a letter away from sounding like a mistake. To ensure acronym coverage, we must also mention OOAD (Object-Oriented Analysis and Design). Object orientation is as much an analysis technique as it is a programming paradigm, although translation is often required from an analysis, or conceptual, model to a design, or logical, model—just as there is between the design model and the implementation, or physical, model. An object—the entity at the core of OO—has both behavior and data, and the functionality of a system is achieved through the interaction of objects. Objects, which are instances of classes, expose their abilities via methods. There are, predictably, some key concepts and terms to be learned in order to grasp OO—the most important being inheritance, polymorphism, encapsulation, and abstraction.
See also: Operations, Object-Relational Mapping, Operating System, OLAP
P Is for Patterns
"I think I see something emerging from the chaos. Is it a zebra?"
Patterns are everywhere it seems. Where there was the Gang of Four and their original Design Patterns, now there are many resources and books dedicated to patterns across many disciplines. Some are stronger than others and probably some judicious pattern-weeding is necessary for a well-maintained architectural garden. Patterns provide both a template for the implementation of a particular concept but also a common language to discuss abstract and complex concepts without the need to resort to a full description, or a diagram—although we'd probably do that, too.
See also: Principles, Platforms, Politics, Performance, Process
Q Is for Quality
"Good enough isn't good enough."
Quality is often understood as a synonym for good. Good is hard to define and measure. Quality should be defined and measurable. What quality is really about is ensuring that the solution meets the requirements and all the applicable standards (as defined by the enterprise, industry, statutory authority, and so forth). By defining and specifying the metrics and standards, a solution can be judged—and, if necessary, improved.
See also: Qualifications, Queries, Quantification, Quantum Computing
R Is for Road Maps
"You take the high road, and I'll take the low road."
Where architecture and real life sometimes come unstuck is in the difference in times between the production of concepts and the subsequent realization of the vision. Many obstacles stand in the way of a beautiful architecture: differing views, changing product strategy, short-term tactical needs. A road map can help to maintain the original vision, providing a view on the now, the soon and the later of the implementation. A road map can provide the business with a view on the plans and targets of the technology teams. A road map can sometimes help you remember just what it was that you were trying to do in the first place.
See also: Requirements, Realization
S Is for Strategy
"What are we trying to achieve?"
Strategy sets out how to achieve your goals. Architectural strategy is derived from the enterprise strategy—it should enable the enterprise to achieve its goals. The word "strategic" should be used with care and caution—many before you have used it to justify costly, long-term investments with ill-defined benefits. A strategy, like a good military plan, should be adaptable—otherwise, it will collapse upon contact with reality. Strategy is often confused with—and sometimes mistakenly thought to be in opposition to—tactics. Tactics are the specific actions that, by achieving objectives, are the implementation of your strategy.
See also: Services, Software, Standards, Security, Scalability
T Is for Thinking
"I think, therefore, I clearly have too much time on my hands."
As a skill, thinking is typically not a problem for developers and architects. Finding the space and time to think is a little harder. In these days of a constant bombardment of information from the blogosphere—good, bad, and ugly—it can sometimes be hard to find the inclination to think for oneself. Such a crucial activity needs to be given focus and an architect should be prepared to make the space and time and defend it. Think about thinking: What works for you? Long train journeys? Music? A hot bubble bath? It might be hard to install a bathroom suite in the office, but you never know.
See also: Technology, Transparency
U Is for Understanding
"I do believe you've got it."
Understanding is complementary to knowledge. Understanding people, systems, and processes makes a significant difference to the outcome of a solution. It is the antithesis of assumption. Some nefarious types will present assumption as understanding; this is undoubtedly a Bad Thing and will not lead to the Promised Land of Good Architecture. Questioning is a key technique for reaching understanding; used well, it can puncture assumption, myth, and other forces that could derail a project.
See also: UML, Unix
V Is for Values
"Explain to me again why we're doing this..."
The values of an architecture are best expressed as principles—the value system that guides decision-making and architectural practice is made up of these values. Principles are, therefore, the foundation that underlies architecture. To be effective there should be no more than a handful of enterprise-level principles and they must have the support of senior leaders. A good principle is clear, consistent, relevant, appropriately focused, adaptable, and stable.
See also: Virtualization, Visualization, Views
W Is for Whiteboard
"It's probably easier if I just draw a picture."
Good whiteboarding skills are a true art: It is easy to become an apprentice, but achieving mastery is always elusive. On the evidence of our own careers, we suspect that many great ideas have never been implemented simply because of a "bad gig" on the whiteboard. In the future, if the original pioneers of computer technology are to be remembered (that's you, by the way) then the most fitting monument would be a huge statue of a whiteboard in pristine white marble, with just a few tell-tale signs of the accidental use of a permanent marker.
See also: Workflow, Wikis, Windows, Web
X Is for XML
"<xs:element name='quote' type='xs:string' />"
XML has become a universal markup language; thus, providing a nonproprietary format for data storage and a means to integrate systems and applications. While it has its detractors and there are rival markup languages (such as JSON and YAML), there is, as yet, nothing that can rival the reach of XML. While some may think of XML as the Esperanto of the Web, it is really nothing more than the basis for a shared language. Think of XML as providing the letters and the punctuation, but not the words or grammar. XML Schema (XSD) provides a means of defining XML documents that can be shared and used to validate documents. And, while there are alternatives, such as RelaxNG, XSD—like XML—has sufficiently broad reach that it is likely to be understood by partners and customers.
See also: XSD, XPath, XQuery, XAML, XOML
Y Is for YAGNI
"Stay on target! Stay on target!"
Great designs are often not grand designs. Using good judgment to decide when to build new features, or reuse prior work, or skip the features is all part of the architectural game. Still, it can be appealing to keep just building new stuff, just in case it's needed in the future, because "you never know." Of course, you do know; not much software lasts for all that long these days, owing to new techniques, channels, and even languages that can be exploited. If you're not sure, more than likely, You Ain't Gonna Need It.
See also: YAML, Yottabyte
Z Is for Zeitgeist
"All the cool people are doing it."
Zeitgeist or "spirit of the age" is an important aspect of thinking and values and leadership. It's magnified with the rate at which "ages" manifest themselves. We're already on Web 2.0 after all. Understanding how to react to the zeitgeist ensures that the right steps are taken to respond to changing circumstance: "Let's reinvent ourselves as Facebook tomorrow." Typically, for an architect, it is not so much the manifestation of new thought—those are just implementations—as the underlying memes and their importance in the technology landscape. Everyone else sees "social networking," where an architect sees "the semantic Web."
See also: Zeal, Zettabyte, Zero Day Exploit
Conclusion
When we set out to compile this A-Z, we wondered how much of a challenge it would be to construct. In fact, we were inundated with possibilities, and spent a lot of time debating the merits of any given entry.
For us, the list has been an affirmation that architecture is as much about softer skills—good judgment, balance, and other wisdom—as it is about understanding the broad technical landscape, or the skills required to design and implement an architecture.
We've had a lot of fun writing our version of this A-Z, but would love to hear of your own alternatives. We wouldn't be architects if we all agreed on the same list!
About the authors
Mark Bloodworth is an Architect Evangelist in the Developer and Platform Evangelism Team at Microsoft. Prior to joining Microsoft, Mark was the Chief Solutions Architect at BBC Worldwide, where he led a team responsible for architecture and systems analysis. This role encompassed technical strategy, architecture, and team management. Mark's background is in software development and design, specializing in Web applications and integration. Most of his career has been focused on using Microsoft technologies, especially .NET, with a little Java thrown in for good measure. Mark keeps a blog at remark.wordpress.com.
Marc Holmes is an Architect Evangelist for the Developer and Platform Evangelism Team at Microsoft in the U.K., where he specializes in architecture, design, and proof-of-concept work with a variety of customers, partners, and ISVs. Prior to Microsoft, Marc most recently led a significant development team as Head of Applications and Web at BBC Worldwide. Marc is the author of Expert .NET Delivery Using NAnt and CruiseControl.NET (Berkeley, CA: APress, 2005) and keeps a blog at http://www.marcmywords.org.