Upload
roger
View
66
Download
8
Tags:
Embed Size (px)
DESCRIPTION
10 Things Every Architect Should Know. Richard Monson-Haefel. 10 Things Every Architect Should 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. - PowerPoint PPT Presentation
Citation preview
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
10 Things Every Architect 10 Things Every Architect Should knowShould know
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
This work is licensed under Creative Commons Attribution 3.0
10 Things Every Architect 10 Things Every Architect Should knowShould know
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
This work is licensed under Creative Commons Attribution 3.0
People are the PlatformPeople are the Platform
Applications are for making users as effective as possible- Ben Geyer, Caterpillar Inc.
This work is licensed under Creative Commons Attribution 3.0
People are the PlatformPeople are the Platform
Work on the things that matter most to customers first.
- Sean Neville
This work is licensed under Creative Commons Attribution 3.0
This work is licensed under Creative Commons Attribution 3.0
People are the platformPeople are the platform
Business
People
User Interface
Information Systems
People are the PlatformPeople are the Platform
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
This work is licensed under Creative Commons Attribution 3.0
People are the PlatformPeople are the Platform
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
This work is licensed under Creative Commons Attribution 3.0
10 Things Every Architect 10 Things Every Architect Should knowShould know
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
This work is licensed under Creative Commons Attribution 3.0
All solutions are obsoleteAll solutions are obsolete
Hope that nothing you do will last.
- Sean Neville
This work is licensed under Creative Commons Attribution 3.0
All Solutions are obsoleteAll Solutions are obsolete
Idea
Development
Deployment
MaintenanceEarly Adopters
Mainstream
Old School
Irrelevant
This work is licensed under Creative Commons Attribution 3.0
All Solutions are obsoleteAll Solutions are obsolete
Today’s solution is tomorrows problem- RMH
This work is licensed under Creative Commons Attribution 3.0
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
This work is licensed under Creative Commons Attribution 3.0
10 Things Every Architect 10 Things Every Architect Should knowShould know
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
This work is licensed under Creative Commons Attribution 3.0
Data is foreverData is forever
Technology, methodologies and business practices change, but data is forever- RMH
This work is licensed under Creative Commons Attribution 3.0
Data is foreverData is forever
This work is licensed under Creative Commons Attribution 3.0
10 Things Every Architect 10 Things Every Architect Should knowShould know
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
This work is licensed under Creative Commons Attribution 3.0
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
This work is licensed under Creative Commons Attribution 3.0
Flexibility breeds Flexibility breeds complexity complexity
Simple Complex
Flexible / ExtensibleRigid / Constrained
This work is licensed under Creative Commons Attribution 3.0
Flexibility breeds Flexibility breeds complexity complexity
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
This work is licensed under Creative Commons Attribution 3.0
Flexibility breeds Flexibility breeds complexity complexity
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
This work is licensed under Creative Commons Attribution 3.0
Flexibility breeds Flexibility breeds complexity complexity
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
This work is licensed under Creative Commons Attribution 3.0
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
This work is licensed under Creative Commons Attribution 3.0
10 Things Every Architect 10 Things Every Architect Should knowShould know
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
This work is licensed under Creative Commons Attribution 3.0
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
This work is licensed under Creative Commons Attribution 3.0
Nothing works as Nothing works as expectedexpected
Gartner's Hype Cycle
VISIBILITY
TIME
Peak of Inflated Expectations
Plateau of Productivity
Slope of Enlightenment
Trough of Disillusionment
Technology Trigger
This work is licensed under Creative Commons Attribution 3.0
Nothing works as Nothing works as expectedexpected
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
This work is licensed under Creative Commons Attribution 3.0
10 Things Every Architect 10 Things Every Architect Should knowShould know
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
This work is licensed under Creative Commons Attribution 3.0
Documentation is the Documentation is the Universal Source CodeUniversal Source Code
A simple line of text is worth a thousand pictures.- Don Box
This work is licensed under Creative Commons Attribution 3.0
Documentation is the Documentation is the Universal Source CodeUniversal Source Code
1700 BC 1800 BC 1900 BC 2000 BC
Modern English
FORTRAN
1950’s
This work is licensed under Creative Commons Attribution 3.0
Documentation is the Documentation is the Universal Source CodeUniversal Source Code
Re-use is about people and education, not about architecture- Jeremy Meyer
This work is licensed under Creative Commons Attribution 3.0
10 Things Every Architect 10 Things Every Architect Should knowShould know
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
This work is licensed under Creative Commons Attribution 3.0
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
This work is licensed under Creative Commons Attribution 3.0
Know the businessKnow the business
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
This work is licensed under Creative Commons Attribution 3.0
Know the businessKnow the business
The first few members of your team will define the culture of your team for a long time to come.
- Nitin Borwankar
This work is licensed under Creative Commons Attribution 3.0
10 Things Every Architect 10 Things Every Architect Should knowShould know
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
This work is licensed under Creative Commons Attribution 3.0
Maintain the visionMaintain the vision
Conceptual integrity is the job of the architect. And it matters. - Luke Hohmann
This work is licensed under Creative Commons Attribution 3.0
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
This work is licensed under Creative Commons Attribution 3.0
10 Things Every Architect 10 Things Every Architect Should knowShould know
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
This work is licensed under Creative Commons Attribution 3.0
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
This work is licensed under Creative Commons Attribution 3.0
Software Architects Should Software Architects Should also be Codersalso be Coders
Get out of your Ivory Tower Get into the trenches
This work is licensed under Creative Commons Attribution 3.0
Software Architects Should Software Architects Should also be Codersalso be Coders
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
This work is licensed under Creative Commons Attribution 3.0
10 Things Every Architect 10 Things Every Architect Should knowShould know
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
This work is licensed under Creative Commons Attribution 3.0
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
This work is licensed under Creative Commons Attribution 3.0
There is no substitute for There is no substitute for experienceexperience
This work is licensed under Creative Commons Attribution 3.0
There is no substitute for There is no substitute for experienceexperience
Don't go looking for an architect after the foundation has been laid
- Nitin Borwankar
This work is licensed under Creative Commons Attribution 3.0
There is no substitute for There is no substitute for experienceexperience
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
This work is licensed under Creative Commons Attribution 3.0
10 Things Every Architect 10 Things Every Architect Should knowShould know
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
This work is licensed under Creative Commons Attribution 3.0
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.
This work is licensed under Creative Commons Attribution 3.0
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
This work is licensed under Creative Commons Attribution 3.0
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
This work is licensed under Creative Commons Attribution 3.0
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 )
This work is licensed under Creative Commons Attribution 3.0
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.
This work is licensed under Creative Commons Attribution 3.0
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.)
This work is licensed under Creative Commons Attribution 3.0
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.
This work is licensed under Creative Commons Attribution 3.0