Editor's Notes
- #2: Objectives for this talk: - To help you understand how we think about software architecture - To make reading and applying the guide easier for you when you read itMetaphors can be helpful - They can help you conceptualize things in a unique way - But we’re not going to use the typical “architecting buildings”Now let’s try an exercise. Provide 3 descriptive words to finish the sentence and remember them.Prepared and delivered by:Don Smith, Program ManagerMicrosoft patterns & practices
- #3: I’ve done that exercise with a number of people, and every time, the word “hard” or “difficult” makes it in the top three. This talk asserts that the same descriptive words that describe architecting software can be said about raising children.After we cover some initial goals and principles, we’ll spend some time describing the scope of software architecture and close with how you might apply an iterative method (process) for applying what we’ve learned.By the way, if you’re reading these notes in PowerPoint, the “Notes Page View” tends to work better than the “Normal” view.Photo credit: http://www.flickr.com/photos/ian_riley/2345482452/
- #4: As far as these kids were concerned, it’s pretty clear what the “goal” was, huh? The solutions we architect provide value to the business by giving its users tools to work, but must live within the constraints imposed by both users and the business in addition to the environment those solutions execute in and the teams that are building them. Therefore it’s important to establish goals for each one of these areas.Remember, software architecture is about making decisions … and those decisions primarily revolve around the structure of the system. So as you are considering your goals for each of these influences on the solution you’re building, be sure to consider the structural impact of those goals.Photo credit: http://www.flickr.com/photos/ian_riley/106239828/
- #5: Throughout school, children are separated by age because in school, the “concerns” are all related to particular age groups. We do the same thing with our children. For example, I sometimes separate my 13 year old daughter from concerns I am working with my 16 year old on.In most relationships, transparency is a very good thing. In the relationship various structures have in a software solutions, it is not. Encapsulation prevents other structures from accessing or even knowing about the internal data of a structure or how that data is used.In my opinion, duplication is the single biggest problem that causes systems to become brittle in the face of keeping that solution up to date and free from bugs. This is because when a bug needs to be fixed or the design of the system needs to be evolved, the same change must be applied in multiple places. If you don’t, the system will just break in a different way or in a different place.The adage “the only constant is change” is more true in software than anywhere. Rather than try to avoid it, we should embrace it and learn to manage it.Both composition and inheritance describe a relationship between 2 structures. Over the years, we’ve come learn how to manage composition much better than inheritance. This isn’t to say you should never apply inheritance … you should just consider composition first.Photo credit: http://www.flickr.com/photos/21967211@N02/2153112397/
- #6: There are a number of factors that are taking place in our industry that influence architectural decisions. In the face of the Agile movement (Scrum/XP/etc) development teams are getting smaller to increase the fidelity of the communication in the team. This is causing architects to give more thought to the structure of the system so parts of it can be developed independently and composed later.Social computing (Facebook, Twitter, Digg, etc.) are putting a tremendous amount of power in the hands of their users to manage their personal relationships. Services like these and others (outside of social networking) are giving users a very important thing: choice. This causes those of us building solutions to put the users at the forefront of decisions … assuming we want them to use our system. But even in “captive audiences”, they see what is available and they are demanding more of us.Our industry has made massive progress in the past decade when it comes to building software (.NET, Java, network infrastructure, etc). All of this capability provides us the freedom to rethink our designs and decisions on the solutions we’re building.There are more advances coming. And if you look at some of the trends carefully enough (multi-core, HPC, mobile devices, cloud computing, modeling, etc), you can see the opportunities you’ll have in your decision making in the near future. The better you plan for them now, the easier it will be to take advantage of them when they arrive.Photo credit: http://www.flickr.com/photos/ian_riley/2314516818/
- #7: This is the “what” of architecture from our perspective. This section provides a way to organize many architectural concepts in a digestible way that can be actionable later.I chose this picture (not just because it is a beautiful shot), but because of the expressions on the girls faces. I believe they relate to the reaction many people will have about 3 of the main areas we’re going to talk about: The architecture frame Architecture Styles Application TypesThe girl on the right is smiling. I think most people will immediately understand these types because they are the language we use today to describe applications. The girl in the middle looks somewhat confused. Most of us have heard of these styles, but probably not ever seen them related this way. I’ll try to make sense of their relationship in a moment. The captivating girl on the left (my personal favorite) looks thoughtful, which is exactly the way the architecture frame should be approached.The forth area is Quality Attributes. We could say that represents the beautiful scene behind the girls, but I wouldn’t argue if you said that was a stretch. Let’s now discuss each of these areas individually, starting with application types.Photo credit: http://www.flickr.com/photos/krisvdv/336502237/
- #8: Application types could be considered the careers we would wish for our children – the impact we hope they can have when they get older. These are commonly understood and sometimes they can be identified early … sometimes we need more information to make a choice. Application Types relate to how consumers interface with their capabilities.[provide written descriptions of each of these later] Rich Client Web Client Rich Internet Client Remote Services Mobile ClientNow let’s peek into other ways we can describe and think about the applications we’re building.Photo credit: http://www.flickr.com/photos/30128498@N05/2836060972/
- #9: Architecture styles are common terms in our industry that have never seemed to have a good way of relating to each other. This is because their characteristics differ across various factors and at various levels. They tend to represent a collection of various patterns, deployment assumptions, and benefits. When architecting solutions, it can be very helpful to have an understanding about which styles you will use and how you think about them.Photo credit: http://www.flickr.com/photos/rudiroels/2978700418/
- #10: These children are doing calisthenics to gain some Quality attributes – specifically a strong spirit and body. We should know which are the most important for our application.Quality attributes and their priority have a substantial influence on the architectural decisions we make. These are just a few of the most important ones for most enterprise applications.Patterns & practices has done a significant amount of work in security and performance. This guide can pave the way for us to do more in these other areas.Photo credit: http://www.flickr.com/photos/knezovjb/2102314562/
- #11: The architecture frame exists to make sure we don’t miss anything in our decisions. She certainly looks like she doesn’t want to miss anything.Photo credit: http://www.flickr.com/photos/crabom/3050306836/
- #12: Now that we’ve had a chance to see the different areas that make up the scope of architecture, now let’s see how we can apply that knowledge in an iterative way. Let’s go back to our metaphor to get an overview of this process and then we’ll go into each step and apply it to architecture.1: As you raise your children, you will have a sense of the most important things are. These are generally the most important things to you (health, intelligence, a sense of service). 2: Over the years you will likely encounter problems … and these problems will need solutions. In this step, you choose the specific scenario that exemplifies the problem (bedtime, dinner time, behavior in public). As a parent, you will likely pick the most important ones first.3: In this step, you choose an approach to fix the problem. As a parent, you’ll try different communication approaches, different styles of motivation, different forms of punishment.4: After you’ve decided on an approach, it’s important that you’re being comprehensive, and that the choice isn’t violating an important concern. For example, you wouldn’t want to choose a form of punishment that get’s them to school on time, but completely unmotivated to do their best5: After all of these choices and consideration, you should try it and see if the outcomes are what you were expecting.Photo credit: http://www.flickr.com/photos/wwwflickrcomphotosjaggy/3049614631/
- #13: Know what your goals are from the outset. Make sure they represent the level of effort you intend to apply.Know who all of the consumers are of your architecture. Developers Testers Writers Other architect Business representativesMake sure you’ve identified your constraints around: People Money Environment Knowledge of the domainPhoto credit: http://www.flickr.com/photos/yilud/533597179/
- #14: It’s pretty obvious in the picture what the key scenario was. It certainly wasn’t to find a table Business Critical scenarios illustrate challenge having to do with the domain. Can be response time, number of users.Broad Impact scenarios are those that impact many parts of the solution. This is common with cross cutting concerns. For example, how to flow a user’s security credentials to a back end system.High Impact scenarios are the most important … the ones of highest importance.We will use these scenarios later to test the other steps of this method.Photo credit: http://www.flickr.com/photos/ian_riley/2313703797/
- #15: Step 3 is about making choices based on the goals, objectives, and key scenario you identified in the previous steps.I’m not exactly sure what these boys are doing, but I’m convinced they are making choices about something vitally important.Photo credit: http://www.flickr.com/photos/ian_riley/478284591/
- #16: Okay, I’m pretty sure this little boy isn’t actually taking a test, but I just liked the picture so much I had to use it. Although, he is giving a lot of thought to something.In this step, ensure the choices you made in the last step don’t violate important hotspots in the architecture frame and that they enforce the highest priority quality attributes.Photo credit: http://www.flickr.com/photos/zhujmu/2964662532/
- #17: This is the step where you get to validate your work with a real, end-to-end, thin implementation. When you start the iteration over again, validate your implementation of your architecture. Then you can choose the next scenario and continue this process (refactoring as necessary) along the way.Photo credit: http://www.flickr.com/photos/mfi/2829003030/
- #18: Photo credit: http://www.flickr.com/photos/chrissuderman/248876814/
- #19: Use the guideApply the methodSpeak the language Give us feedbackPhoto credit: http://www.flickr.com/photos/dbhillyard/444538787/