Download - 10 Things Every Architect Should Know

10 Things Every Architect 10 Things Every Architect Should KnowShould KnowRichard Monson-Haefel

This work is licensed under Creative Commons Attribution 3.0

10 Things Every Architect 10 Things Every Architect Should knowShould know

Or

If you put 10 architects in a room and ask them to create a list of 10 things every Architect should know they will come up with either 10 different lists or a list of 100 things or both. This work is licensed under Creative Commons

Attribution 3.0


People are the platform All solutions are obsolete Data is forever Flexibility breeds complexity Nothing works as expected Documentation is the universal source

code Know the business Maintain the vision Software architects should also be coders There is no substitute for experience

- according to RMH


People are the PlatformPeople are the Platform

Applications are for making users as effective as possible- Ben Geyer, Caterpillar Inc.



Work on the things that matter most to customers first.

- Sean Neville



People are the platformPeople are the platform

Business

People

User Interface

Information Systems


Don't put domain modeling and service design on a pedestal and turn up your nose at UI and web work … domain modeling and data management are not the hard or time-consuming aspects of a project, the UI is.

- Sean Neville



One aspect of "giving in" to a great architecture is continually assessing if the decisions we're making are designed with the customer and their needs first and foremost, and our willingness to change prior decisions when we find they're not.

- Luke Hohmann





- according to RMH


All solutions are obsoleteAll solutions are obsolete

Hope that nothing you do will last.

- Sean Neville


All Solutions are obsoleteAll Solutions are obsolete

Idea

Development

Deployment

MaintenanceEarly Adopters

Mainstream

Old School

Irrelevant


All Solutions are obsoleteAll Solutions are obsolete

Today’s solution is tomorrows problem- RMH


All solutions are obsoleteAll solutions are obsolete

Understand disposable applications. These didn't exist even as recently as two years ago, but the combination of social platforms, hosted business models, certain methodologies, and certain frameworks has made it less expensive to start over and re-architect certain kinds of systems than it is to make those systems extensible and evolve them.

- Sean Neville





- according to RMH


Data is foreverData is forever

Technology, methodologies and business practices change, but data is forever- RMH


Data is foreverData is forever





- according to RMH


Flexibility breeds Flexibility breeds complexity complexity

Decide where you want to build in flexibility, it doesn't come for free and it will always adds complexity.

- Rebecca Wirfs-Brock



Simple Complex

Flexible / ExtensibleRigid / Constrained



Simplicity requires courage and time - it takes a lot of guts to hold the line on a simple design and several iterations to shake out the redundancies and noise to get there.

- Don Box



The strength of a framework comes not from what it allows you to do, but rather from what it does not allow you to do.

- Richard Öberg



Adherence to or intellectual appreciation for a particular pattern is not an excuse to employ elaborate, complex frameworks that implement those patterns. Most new architects can't tell the difference, and are wedded to the expected solution rather than the actual problem.

- Sean Neville


Flexibility breeds Flexibility breeds complexitycomplexity

The more things are stable the more disruptive they are to your architecture when they change. But that doesn't mean you should make everything changeable.

- Luke Hohmann





- according to RMH


Nothing works as Nothing works as expectedexpected

Independent of what the vendor says, the next version will not fix all your problems (and will even create many new ones).

- Nitin Borwankar



Gartner's Hype Cycle

VISIBILITY

TIME

Peak of Inflated Expectations

Plateau of Productivity

Slope of Enlightenment

Trough of Disillusionment

Technology Trigger



Gartner's Hype Cycle for 2007This work is licensed under Creative Commons Attribution 3.0

Nothing works as expctedNothing works as expcted

Not all new technology is necessarily good technology, or better than older technology, just because it’s new and hyped and supposedly sexy

- Randy Stafford





- according to RMH


Documentation is the Documentation is the Universal Source CodeUniversal Source Code

A simple line of text is worth a thousand pictures.- Don Box



1700 BC 1800 BC 1900 BC 2000 BC

Modern English

FORTRAN

1950’s



Re-use is about people and education, not about architecture- Jeremy Meyer





- according to RMH


Know the businessKnow the business

Business stuff and technical stuff are forever inter-twined. If you're an architect, learn to live in the white space.

- Luke Hohmann



Architecting is about balancing the needs of all the stakeholders in a system, from users to CEOs to operations personnel to future programming staff, over the short and long term, in the way that is appropriate to the context at hand.

- Randy Stafford



The first few members of your team will define the culture of your team for a long time to come.

- Nitin Borwankar





- according to RMH


Maintain the visionMaintain the vision

Conceptual integrity is the job of the architect. And it matters. - Luke Hohmann


Maintain the visionMaintain the vision

Don't ignore (put your favorite quality here) until the last moment could be performance, security, scalability, whatever....all I know is when these qualities get shoe-horned in, the projects and architecture suffer. - Rebecca Wirfs-Brock





- according to RMH


Software Architects Should Software Architects Should also be Codersalso be Coders

If you're unwilling to be hands-on, maybe you should keep your hands off.

- Barry Hawkins



Get out of your Ivory Tower Get into the trenches



People who are responsible for a given technology should write code against it (or better yet as part of it) every single day. Bits talk, bullshit walks.

- Don Box

Every architect should spend at least 10% of their time doing code reviews with the engineers building their product. - Don Box





- according to RMH


There is no substitute for There is no substitute for experienceexperience

You're not an architect until you've been working on the same system, and DEALING WITH YOUR CHOICES, for multiple releases. You're certainly not an architect just because you have a fancy title.

- Luke Hohmann



Don't go looking for an architect after the foundation has been laid

- Nitin Borwankar



Creating great enterprise software isn't a matter of intellect as much as wisdom and tenacity -- the ability to see the similarity between one past experience (particularly a failure) and some aspect of your current context.

- Sean Neville





- according to RMH


More words of wisdom from More words of wisdom from seasoned architectsseasoned architects

RembrandtThis work is licensed under Creative Commons Attribution 3.0

Luke HohmannLuke Hohmann We "give in" to great architectures. An architect or development team "gives in" to a

design when they subordinate their experiences and expectations about what is "right" and instead lets the forces of the problem domain guide them in the realization of the architecture. Some people claim this is not a problem, and that they or their team always creates an architecture that is solely based on an objective understanding of the customers problems and how best to structure a technical solution. The operative word, of course, is "best". Your opinion of "best" may not match mine, and is probably more heavily influenced by my experiences than the problem domain -unless my experiences are borne from this problem domain. One aspect of "giving in" to a great architecture is continually assessing if the decisions we're making are designed with the customer and their needs first and foremost, and our willingness to change prior decisions when we find they're not.

“Give in” to the architecture

Read The Mythical Man-Month. Hell, memorize it.

Conceptual integrity is the job of the architect. And it matters.

Developers do what you ask them to do. So ask carefully (read Weinberg).

Collaborate with your product management team so that you're architecture can evolve along with your roadmap. (Read Pattern Language for Strategic Product Management /Roadmapping).

Business stuff and technical stuff are forever inter-twined. If you're an architect, learn to live in the white space.

You're not an architect until you've been working on the same system, and DEALING WITH YOUR CHOICES, for multiple releases. You're certainly not an architect just because you have a fancy title.


Rebecca Wirfs-BrockRebecca Wirfs-Brock Don't ignore (put your favorite quality here*) until the

last moment*could be performance, security, scalability, whatever....all I know is when these qualities get shoe-horned in, the projects and architecture suffer.

Use patterns, follow accepted practices...don't try to re-invent the wheel


Randy StaffordRandy Stafford Application architecture (not selected technology stack)

determines application performance The number of IPCs in response to a stimulus usually drives

response time There is no one-size-fits-all solution; the right solution is

sensitive to context (see http://c2/com/cgi/wiki?ContextualSense)

Architecting is about much more than just the technical aspects (of applying patterns, modularizing systems, optimizing performance, etc.); architecting is about balancing the needs of all the stakeholders in a system, from users to CEOs to operations personnel to future programming staff, over the short and long term, in the way that is appropriate to the context at hand

Not all new technology is necessarily good technology, or better than older technology, just because it’s new and hyped and supposedly sexy

The most popular product is usually not the most technically superior product (http://c2.com/cgi/wiki?WorseIsBetter)

Everywhere I go, every day, I see money and opportunity being wasted by poor software architecture


Nitin BorwankarNitin Borwankar Database design != SQL programming (most

developers raised on MySQL do not know this) The first few members of your team will define the

culture of your team for a long time to come (by hiring people like themselves)

Stay away from projects that require you to be an architect and a project manager (if at all you can; sometimes you just can't)

Don't go looking for an architect after the foundation has been laid (this one is for the project manager rather than the architect )


Sean NevilleSean Neville A problem's difficulty or intellectual attraction doesn't necessarily equate to importance or customer-

relevance. Work on the things that matter most to customers first. Highlight the ROI story and customer story instead of the technical story to your Board and your internal team.

Understand disposable applications. These didn't exist even as recently as two years ago, but the combination of social platforms, hosted business models, certain methodologies, and certain frameworks has made it less expensive to start over and re-architect certain kinds of systems than it is to make those systems extensible and evolve them.

Hope that nothing you do will last. Software is less permanent than items produced in most engineering disciplines, therefore as long as our field continues to evolve and improve, none of your stuff will last very long (even legacy stuff gets ripped and replaced every 20 years or so) and most of what you know may eventually be wrong. It's still a young and rapidly-changing area with an element of Zen- like impermanence that is certain eventually to humble even the most brilliant software minds you know (including your own if you put yourself in that category).

Don't put domain modeling and service design on a pedestal and turn up your nose at UI and web work. For most web and rich apps today, considering the tools, frameworks, and experiences at our disposal, domain modeling and data management are not the hard or time-consuming aspects of a project, the UI is. There's been a shift of R&D bottleneck away from devs and toward IA and designers on one end, and systems infrastructure guys on the other end.

If most of your developers' time is spent on build processes, bug tracking, managing metadata files (XML or otherwise), etc. instead of coding or working with customers to solve problems, then you're not really agile, you've just moved the time bottleneck from one area to another far less interesting area.

Learn the hardware that your stuff will be deployed on; you're not really a technical architect if all you know is a tiny slice of software in the overall system of hardware, economic, and network factors at play.

Be careful not to degrade the person behind the platform/language/ technology/opinion you scoff at. Software is still a surprisingly small world, and while strong opinions and conflicts about technology are often healthy, personal conflicts on the other hand can have lengthy and unexpected consequences for you and your organization, so don't let your ego drive you into such unnecessary pitfalls.


Sean NevilleSean Neville Open source is free only if you don't put a dollar value on your team's time. When creating budgets and schedules for exec staff,

this must be kept in mind, though obviously filtered through the strengths of your team (which will occasionally render the point irrelevant).

Lone wolf architects tend to make people suspicious and/or resentful. Find a partner. This is especially true of architects who have no accountability for budget or personnel, yet are accountable for the health of the system. Having an internal champion at your peer level or above who can advocate on the business side helps get things done. Sadly, this person is almost never your product manager. Network internally beyond the geeks in R&D to find the right person.

The skills which will do the most to advance your career are quite likely not technical, but communication skills: writing, translating concepts into simple analogues and teaching them, coordinating in email across conflicting philosophies from different corners of the organization, pitching ideas to your Board or exec staff, etc. Written and oral ability is enormously beneficial.

But on a negative corollary, people who write more books, papers, specs and presentations than they have written actual code and successful products are not generally the people you want accountable for the core of your code, no matter how intelligent they are or what their external reputation may be to the masses. But they do make brilliant marketing/evangelist/advocate -types. In other words, the team lead who spends hours on his blog answering questions or participating in forum arguments is not spending those hours working on the software itself.

Developers tend to like writing code, but coding doesn't scale particularly well; small teams produce less code than large teams do, less code is less expensive to maintain than is a large body of code, and the least amount of code needed to do a thing properly and lucidly is the goal (discourage lines of code as a metric). Adding more people is not only not beneficial, it's detrimental (Mythical Man-Month).

Many architects have a problem prioritizing and translating business priorities into technical priorities. The ROI story for most architects is the lowered overhead in developing and maintaining solutions over time, since in most organizations the architect is not creating a new revenue stream but rather reducing the cost of an existing process. This isn't true in some cases (example: building new software for commercial software companies dependent on software licensing as the primary revenue source), but it's true in most corporate cases. A problem's difficulty or intellectual attraction doesn't necessarily equate to importance or customer-relevance. Work on the things that matter most to customers first. Highlight the ROI story and customer story instead of the technical story to your Board and your internal team.

Creating great enterprise software isn't a matter of intellect as much as wisdom and tenacity -- the ability to see the similarity between one past experience (particularly a failure) and some aspect of your current context and thus avoid costly downtime, or security problems, or concurrency issues (etc.) is often more beneficial to the larger organization and to customers than is your technical vision.

(cont.)


Barry HawkinsBarry Hawkins Value stewardship over showmanship The only people who belong in ivory towers are

captured princesses, and even that wasn't their choice

If you're unwilling to be hands-on, maybe you should keep your hands off.

The architect of software begins with a lower-case "a"; if you can't handle that, go do something else and stop inflicting yourself on others.


Download - 10 Things Every Architect Should Know

Top Related