by Mark Bloodworth and Marc Holmes
Contents
Introduction
Being an architect isn't just about baffling peoplewith 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 asbeing "inconsistent with the prescribed architecture." These days, an architecthas 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 ahandy A-Z guide to being an architect. Good luck, and may all yourarchitectures 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 todo it like that."
Architects have to explain and advise on technical issues tobusiness stakeholders. They also have to be able to advise delivery teams onhow to build. This advice is the currency of an architect; invested wisely, itwill return goodwill and trust. The architect is asked for advice, because it isthe 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. Notthat far. Sorry."
All decisions involve trade-offs—for example, adding asecurity measure may hurt performance. It is the architect's lot to make theright trade-off. Architecture may be a zero-sum game, but knowing what thesystem is intended to achieve enables the architect to choose the trade-offsthat make the system successful. Of course, where there are competingobjectives, it falls to the architect to explain the issue and seek resolutionthrough 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. Softerskills are needed: asking how and why rather than instructing "do this" and "dothat." This is a Good Thing. Development teams who understand the reasons forthe architecture are more likely to commit to it and are likely to do a betterjob of implementing it. Architects can also begin to spot talent withindevelopment 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 upanarchitecture are of fundamental importance. Dependencies are inevitable butshould be as few and as manageable as possible. Draw a diagram and map thedependencies. Circles, whether direct (A depends on B and vice versa) orindirect (A depends on B which depends on C which depends on A) are a BadThing. If many things depend on D, then D needs to be stable because changingit 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 havemade; others need to believe in the ideas, frameworks, and guiding values of anarchitecture. Evangelism is about telling stories to different people. A simplesegmentation may be a technical versus business audience, but there are reallymany differing audiences within that. The architecture needs to have acompelling story for each. An evangelist is able to synthesize and simplifycomplex 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 architectureframework is a structure that removes some of the wheel reinvention that wouldotherwise occur. It provides tools, methods, and a common vocabulary for theprocess of creating an architecture. An architecture framework can beconsidered 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 thesuit if you're serious about doing business. Control is an important part ofrealizing an architectural vision. Regardless of the model of IT—centralized,decentralized, or federated—there will be competing requirements of equalvalue. 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 cangive a positive, dashboard-style view on technology for the business. Commonunderstanding 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 beenfor those pesky users!"
Understanding how people interact with each other and thesystems that support them is crucial to delivering successful solutions. Thedynamics of each project and team will be different; the stakeholders'relationships and motivations may be unique to a given project. Knowing how tonavigate human relationships is a key skill of good architects and goodleaders.
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 canrequire luck and big leaps in thinking. By commoditization time, the game isup, 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 perhapssmaller, but no less valuable evolutions and revolutions of existing ideas andsolutions. Small teams can push for innovation constantly and take chances tomake their name. Larger groups and organizations may not be able to move asquickly, but they need to enable innovation to percolate from individuals andteams and develop mechanisms for making the best of this inspiration andimagination. Architects can be the mouthpiece for the technical teams, and theears 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 bemade, then an architect is going to have to exercise judgment. The teamentrusts the architect to make these judgment calls, and the architect's goodjudgment gives confidence to the team. For better or for worse, a seriesof good or bad calls may be seen to characterize the architect: conservative orwise, impulsive or prescient, biased or brave. Exercising good judgment isvital, 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, beingaware of the boundaries of your knowledge is a Good Thing. Areas that are knownunknowns are ripe for proof-of-concepts and other knowledge-building exercises.Unknown unknowns, on the other hand, are Bad Things: They are the architecturalequivalent of gremlins. Knowledge of technology is only one, albeit important,domain that an architect needs to command. An architect also needs to knowabout the nontechnical factors that will be in play, such as organizationalstructures, enterprise strategy, business processes, and developmentmethodologies.
See also: Kernel, Keyboard
L Is for Leadership
"I'm behind you all the way."
Leadership is vital for an architect and typically takes twoforms: thought leadership and team leadership. As guardian of the architectureand the values behind the architecture, the architect is thought leader: Thearchitect continually reevaluates the vision and re-presents the "newer,shinier" vision, with comment on competing visions and emerging technology. Asteam leader, an architect may not be required to perform line managementduties, 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 madethis model using nothing but twigs and guitar strings."
A model is a representation of something—for example, abusiness process or computer system. Views of a model provide a way tocommunicate and understand ideas about the problem and the solution. Differentviews address different concerns—overloading one view in an attempt to addressmultiple concerns will either lead to an overcomplicated view or anoversimplified understanding. Having a shared notation for representingthese views of a model can simplify conversations about the model—although, ifthe 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. Jobdone. Well, not quite. N-tier is a vague term at best, and doesn't really sayanything more than pointing to the idea that there should be some kind ofseparation of concerns between various chunks of code. With Service-OrientedArchitecture (SOA), and, most recently, the explosion in cloud services—eitheras back end (cloud storage for example) or front end (such as Facebook)—actually describing the architecture can be harder than building it. We're fansof the "Petri dish" approach: concentric circles usually containing squareboxes 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 roseto prominence in the 1990s. It can be thought of as a way to conquer complexityby dividing a big problem or program into bite-size, digestible, and, of course,logically coherent chunks. Object orientation is often referred to as OO andsometimes as OOP (Object-Oriented Programming), which is only a letter awayfrom sounding like a mistake. To ensure acronym coverage, we must also mentionOOAD (Object-Oriented Analysis and Design). Object orientation is as much ananalysis technique as it is a programming paradigm, although translation isoften required from an analysis, or conceptual, model to a design, or logical,model—just as there is between the design model and the implementation, orphysical, model. An object—the entity at the core of OO—has both behaviorand data, and the functionality of a system is achieved through the interactionof objects. Objects, which are instances of classes, expose their abilities viamethods. There are, predictably, some key concepts and terms to be learned inorder 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 azebra?"
Patterns are everywhere it seems. Where there was the Gangof Four and their original Design Patterns, now there are many resources andbooks dedicated to patterns across many disciplines. Some are stronger thanothers and probably some judicious pattern-weeding is necessary for awell-maintained architectural garden. Patterns provide both a template for theimplementation of a particular concept but also a common language to discussabstract 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 ishard to define and measure. Quality should be defined andmeasurable. What quality is really about is ensuring that the solution meetsthe requirements and all the applicable standards (as defined by theenterprise, industry, statutory authority, and so forth). By definingand specifying the metrics and standards, a solution can be judged—and, ifnecessary, 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 isin the difference in times between the production of concepts and thesubsequent realization of the vision. Many obstacles stand in the way of abeautiful architecture: differing views, changing product strategy, short-termtactical needs. A road map can help to maintain the original vision, providing aview on the now, the soon and the later of the implementation. A road map canprovide the business with a view on the plans and targets of the technologyteams. A road map can sometimes help you remember just what it was that you weretrying 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. Architecturalstrategy is derived from the enterprise strategy—it should enable theenterprise to achieve its goals. The word "strategic" should be used with careand caution—many before you have used it to justify costly, long-terminvestments with ill-defined benefits. A strategy, like a goodmilitary plan, should be adaptable—otherwise, it will collapse upon contact withreality. Strategy is often confused with—and sometimes mistakenly thought to bein opposition to—tactics. Tactics are the specific actions that, byachieving 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 myhands."
As a skill, thinking is typically not a problem fordevelopers and architects. Finding the space and time to think is a littleharder. In these days of a constant bombardment of information from theblogosphere—good, bad, and ugly—it can sometimes be hard to find theinclination to think for oneself. Such a crucial activity needs to be givenfocus and an architect should be prepared to make the space and time and defendit. Think about thinking: What works for you? Long train journeys? Music? A hotbubble 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. Understandingpeople, systems, and processes makes a significant difference to theoutcome of a solution. It is the antithesis of assumption. Some nefarious typeswill present assumption as understanding; this is undoubtedly a Bad Thing andwill not lead to the Promised Land of Good Architecture. Questioning is a keytechnique 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 asprinciples—the value system that guides decision-making and architecturalpractice is made up of these values. Principles are, therefore, the foundationthat underlies architecture. To be effective there should be no more than ahandful of enterprise-level principles and they must have the support of seniorleaders. A good principle is clear, consistent, relevant, appropriatelyfocused, 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 tobecome an apprentice, but achieving mastery is always elusive. On the evidenceof our own careers, we suspect that many great ideas have never been implementedsimply because of a "bad gig" on the whiteboard. In the future, if the originalpioneers 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 inpristine white marble, with just a few tell-tale signs of the accidental use ofa 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 anonproprietary format for data storage and a means to integrate systems andapplications. 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 ofXML. While some may think of XML as the Esperanto of the Web, it is reallynothing more than the basis for a shared language. Think of XML as providingthe 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 usedto validate documents. And, while there are alternatives, such as RelaxNG, XSD—like XML—has sufficiently broad reach that it is likely to beunderstood 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 goodjudgment to decide when to build new features, or reuse prior work, or skip thefeatures is all part of the architectural game. Still, it can be appealing tokeep 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 thatlong these days, owing to new techniques, channels, and even languages that canbe exploited. If you're not sure, more than likely, You Ain't Gonna NeedIt.
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 ofthinking and values and leadership. It's magnified with the rate atwhich "ages" manifest themselves. We're already on Web 2.0 after all.Understanding how to react to the zeitgeist ensures that the right steps aretaken to respond to changing circumstance: "Let's reinvent ourselves asFacebook tomorrow." Typically, for an architect, it is not so much themanifestation of new thought—those are just implementations—as the underlyingmemes 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 ofa challenge it would be to construct. In fact, we were inundated withpossibilities, and spent a lot of time debating the merits of any given entry.
For us, the list has been an affirmation thatarchitecture is as much about softer skills—good judgment, balance, and otherwisdom—as it is about understanding the broad technical landscape, or theskills required to design and implement an architecture.
We've had a lot of fun writing our version of this A-Z, butwould love to hear of your own alternatives. We wouldn't be architects if weall agreed on the same list!
About the authors
Mark Bloodworth is an Architect Evangelist in theDeveloper and Platform Evangelism Team at Microsoft. Prior to joiningMicrosoft, Mark was the Chief Solutions Architect at BBC Worldwide, where heled a team responsible for architecture and systems analysis. This roleencompassed technical strategy, architecture, and team management. Mark'sbackground is in software development and design, specializing in Webapplications and integration. Most of his career has been focused on usingMicrosoft technologies, especially .NET, with a little Java thrown in for goodmeasure. Mark keeps a blog at remark.wordpress.com.
Marc Holmes is an Architect Evangelist for theDeveloper and Platform Evangelism Team at Microsoft in the U.K., where hespecializes in architecture, design, and proof-of-concept work with a varietyof customers, partners, and ISVs. Prior to Microsoft, Marc most recently led asignificant development team as Head of Applications and Web at BBCWorldwide. Marc is the author of Expert .NET Delivery Using NAnt andCruiseControl.NET (Berkeley, CA: APress, 2005) and keeps a blog at http://www.marcmywords.org.
This articlewas published in the Architecture Journal, a print and online publicationproduced by Microsoft. For more articles from this publication, please visitthe Architecture Journal Web site.
