• Save
O'Reilly Webcast: Ten Things Every Software Architect Should Know
Upcoming SlideShare
Loading in...5
×
 

O'Reilly Webcast: Ten Things Every Software Architect Should Know

on

  • 8,403 views

This is the slide deck used in Richard Monson-Haefel's webcast "10 Things Every Software Architect Should Know." Richard is the editor of the O'Reilly book, "97 Things Every Software Architect Should ...

This is the slide deck used in Richard Monson-Haefel's webcast "10 Things Every Software Architect Should Know." Richard is the editor of the O'Reilly book, "97 Things Every Software Architect Should Know." Presentation give live on 2-17-09/

Statistics

Views

Total Views
8,403
Views on SlideShare
8,178
Embed Views
225

Actions

Likes
52
Downloads
0
Comments
2

15 Embeds 225

http://softarchitect.wordpress.com 125
http://developercontainer.blogspot.com 35
http://www.slideshare.net 33
http://calebesantos.wordpress.com 13
http://www.pearltrees.com 4
http://developercontainer.blogspot.fr 3
http://developercontainer.blogspot.in 3
http://developercontainer.blogspot.se 2
http://jujo00obo2o234ungd3t8qjfcjrs3o6k-a-sites-opensocial.googleusercontent.com 1
http://developercontainer.blogspot.co.il 1
http://developercontainer.blogspot.pt 1
http://feeds.feedburner.com 1
http://wrttn.in 1
http://www.scoop.it 1
https://spsites.microsoft.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

O'Reilly Webcast: Ten Things Every Software Architect Should Know O'Reilly Webcast: Ten Things Every Software Architect Should Know Presentation Transcript

  • 10 Things Every Architect Should Know Richard Monson-Haefel This work is licensed under Creative Commons Attribution 3.0
  • 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. This work is licensed under Creative Commons Attribution 3.0
  • 10 Things Every Architect Should 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 Should 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 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 Platform Work  on the things that matter most to customers first. - Sean Neville This work is licensed under Creative Commons Attribution 3.0
  • People are the platform This work is licensed under Creative Commons Attribution 3.0 Business People User Interface Information Systems
  • People 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 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 Should 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 obsolete Hope that nothing you do will last. - Sean Neville This work is licensed under Creative Commons Attribution 3.0
  • All Solutions are obsolete This work is licensed under Creative Commons Attribution 3.0 Idea Development Deployment Maintenance Early Adopters Mainstream Old School Irrelevant
  • All Solutions are obsolete Today’s solution is tomorrows problem - RMH This work is licensed under Creative Commons Attribution 3.0
  • All 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 Should 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 forever Technology, methodologies and business practices change, but data is forever - RMH This work is licensed under Creative Commons Attribution 3.0
  • Data is forever This work is licensed under Creative Commons Attribution 3.0
  • 10 Things Every Architect Should 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 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 complexity Simple Complex Flexible / Extensible Rigid / Constrained This work is licensed under Creative Commons Attribution 3.0
  • Flexibility breeds 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 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 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 complexity Simplicity can create flexibility - Luke Hohmann This work is licensed under Creative Commons Attribution 3.0
  • 10 Things Every Architect Should 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 expected 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 expected 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 expected Gartner's Hype Cycle for 2007 This work is licensed under Creative Commons Attribution 3.0
  • Nothing 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 Should 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 Universal 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 Universal Source Code 1700 AD 1800 AD 1900 AD 2000 AD This work is licensed under Creative Commons Attribution 3.0 Modern English FORTRAN 1950’s
  • 10 Things Every Architect Should 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 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 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 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 Should 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 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 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 Should 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 also 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 also 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 also 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 Should 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 experience 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 experience This work is licensed under Creative Commons Attribution 3.0
  • There is no substitute for experience 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 experience 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 Should 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 seasoned architects Rembrandt This work is licensed under Creative Commons Attribution 3.0
  • Luke 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-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 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 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 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 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 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