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

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

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

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

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

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

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

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

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

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

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

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

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

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

More Related Content

What's hot (18)

Viewers also liked (8)

Similar to O'Reilly Webcast: Ten Things Every Software Architect Should Know (20)

More from O'Reilly Media (20)

Recently uploaded (20)

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