One way or another, you will spend time designing it. Of course, time spent planning architecture also delays implementation thus potentially delaying value for stakeholders. If we spend no time up front on architecture, then we are more likely to make changes to the architecture after developing parts of the software system. Rework includes activities such as fixing design defects, rewriting code, and undoing mistakes.
To find the sweet spot, we must account for both design costs and the inevitable rework required to complete the software system. In this case, spending less than about 20 percent of the original project schedule on architecture has a diminishing return. While the amount of rework decreases with a greater investment in architecture, the total project schedule increases. Similarly, spending less time on architecture raises the amount of rework, creating a longer overall project timeline.
In the same research, Boehm also shows how the sweet spot moves depending on the estimated size of the software system. Use this data to decide if the amount of time you plan to dedicate to up-front architecture design is in the right range. In some cases, it can be faster to rewrite a small software system than to spend significant time designing architecture up front. Expect violent thrashing if you invest little into architecture design. Avoiding up-front architecture design in smaller software systems might be more cost effective and result in a shorter overall schedule, but rework will still be necessary.
Be prepared for this and account for design churn in your plans. Bigger systems will experience even more thrashing with less architecture design up front. The more you invest in architecture, the less rework will be required. Planning architecture helps avoid mistakes. If you favor predictable project schedules over schedule efficiency, you will benefit from more planning up front, even on smaller software systems. Up-front planning is a must in larger software systems.
Large systems can be complex, but not all complex systems are large. If a solution is routine, then your team might get away with less up-front planning even when the system is large. Another factor to consider is requirements volatility. Changes to architecturally significant requirements can invalidate the best-laid plans. If you anticipate a high degree of change, delay making binding decisions and focus on using lighter-weight design and documentation methods. Had we spent a little more time on architecture, say 17 percent of the estimated development schedule, then the total project schedule would have increased by only 38 percent.
It turns out Boehm also has an answer for this yes, he is that awesome. If we think about risk in the right ways, we can also use it to determine what to design and how to involve stakeholders in the design process. Let Risk Be Your Guide Shortly after the first stakeholder meeting on a new software project, I always feel a giant pit grow in my stomach. Software worth building always has risks. You should feel a bit uncomfortable at the start of a new project.
After all, if you knew everything at the outset and had no questions about what you were going to build, then why would an architect be needed? We can use that slight sinking feeling in our guts to our advantage. Risk is an excellent indicator of what might prevent us from succeeding. To harness the power of our guts, write down all the things that worry you about the software 1.
Next, prioritize the items on your list so that the things likely to cause the most trouble are highest on the list. Gut feelings tell us there is something wrong, but we can do a much better job than just listening to our lower intestines. Identify Conditions and Consequences A risk is something bad that might happen in the future.
We could play what if… all day and never get any closer to designing a useful architecture. There are two parts to every risk. The condition is a fact about the world that is currently true. The consequence is something bad that might happen in the future as a direct result of the condition. Condition, something true today A new burrito restaurant opened across the street from my office ; teammates might get sick eating too many burritos. Hire catering to bring in food a few days a week, and hold an info session on responsible meal portions.
Keep a supply of antacids in the office. Schedule meetings at lunch so people can eat burritos only for dinner. Move the office to a new location. Change the shift schedule so that everyone works at night when the new restaurant is closed. Sometimes people eat too many burritos mmmm… guacamole. Knowing the condition and the consequence creates hooks for deciding what to do about the risk.
So what? The negative impact is unclear. In fact, this sounds great. We love burritos! The team might overindulge in burritos. This sounds bad, but why should we be worried about this now? Eating too many burritos can make you sick. True, but what does this have to do with my team? If a teammate eats too many And if a radioactive meteorite falls on the burritos, he or she will get sick. What led you to be worried about burritos? OK, enough about burritos. If you can pick a condition and consequence that captures the essence of your bad feeling, then we can use that information to guide our design activities.
Here are some example risks from a past project I worked on and the design activities the team used to reduce the risk: The Model Training service was originally built for a different purpose; might overload it with new requests. Design Mindsets: Understand, Evaluate What we did: Talked to the team who built the Model Training service to understand scalability, ran experiments to measure throughput.
Data processing is time consuming and resource intensive; might not be able to finish processing jobs without failures. Design Mindset: Explore What we did: Brainstormed approaches for promoting reliability, researched job scheduling patterns, and sketched alternative designs that might reduce processing time. Design Mindset: Make What we did: Created a cost estimation model.
The model demonstrated pros and cons of different design options to stakeholders. Stored data may contain sensitive customer information; might require stricter data isolation than we can provide. Design Mindset: Evaluate What we did: Rated available compute platforms based on how well each met our needs. Engineering risks help us decide what to design. Design mindsets help us devise a strategy to decrease the risk. When facing a risk that must be reduced, first decide which parts of the risk you can address—condition, impact, probability, or time frame.
Next, choose a design mindset. Here are some questions to help decide which design mindset might be appropriate: Try… If… Understand Mindset The risk is about the problem. Do you need a deeper understanding of stakeholders or other system actors? Explore Mindset The risk about the solution. Have you seen enough solution alternatives? Make Mindset The risk is about communication.
Do stakeholders fully understand design concepts at play and can they see the architecture? Do we need to make a design decision? Risks are the GPS for our design process. With each loop through the think-do-check cycle discussed on page 21, think about the risks and use them to decide what to do next. Once we have reduced enough of the architectural risks, whatever that means for the software system, then our time is better spent elsewhere. Once architecture is no longer the greatest source of risk in the system, shift from active design to passive design, as shown in the graph.
With active design, we drive the design process in the pursuit of reducing risk. With passive design, we observe the architecture as it manifests in the working system and take corrective actions as necessary. There is still a lot for an architect to do in passive design mode. We might correct errant documentation or improve missing documents. Even with careful vigilance, architecture could reemerge as a significant risk. New risks might emerge. The implemented system could drift too far from our plans.
We could learn that our assumptions about the world are wrong or that the world around us changed. When these things happen, switch back to active design and adjust the architecture based on the new realities. Create a Design Plan Design plans outline a general strategy for how the team will spend their time on architecture. Will we do more analysis up front? Are we expecting change later? When do we start writing code? A good design plan sets expectations and explains these details.
Here are a few things every design plan should include: Capture your plan in a lightweight document such as an inception deck described on page Stopping conditions for design Will you time-box up-front design work, or will you reduce risks no matter how long it takes? Will you do minimal up-front design before starting to write code, or do you want more of the architecture laid out?
Can implementation start piecemeal, or do some areas need to start together? There is no single right answer. Stopping conditions depend heavily on the team, stakeholders, and project context. Required design artifacts Tell everyone how you plan to document the architecture before starting. Are you OK with pictures of whiteboards, or do you need a more traditional document? Does your team use specific templates?
Where should design artifacts be stored? Time line Describe the key design milestones within the project schedule. Many large projects have a dedicated elaboration phase for gathering requirements and exploring architecture. Smaller projects or continuously maintained software systems might regularly schedule design spikes. At a minimum, the time line should include milestones for reviewing architecturally significant requirements, reviewing draft designs, and conducting evaluations.
Also, include any major workshops with stakeholders. Call out when you think implementation will start and what is in scope for early implementation. Top risks Since we are using a risk-driven design approach, include the top risks in the design plan as context.
Notional architecture design Start with a potential solution. Recall that we need to think about the solution to help us define the problem.
A notional architecture can be a lightweight sketch, just enough to communicate the essence of your initial design thoughts. The amount of time spent on design could be hours, days, or even months depending on the software system. No matter your time horizon, if we use the four principles of design thinking covered on page 15 and focus on finding a satisficing solution discussed on page 27, then we should arrive at a working solution by the time we need it. We have a fixed final due date in about six months.
We need to focus on value up front and deliver as fast as possible. It also sounds like the core functional requirements will be based on an existing process, so there is a low probability of requirements churn. The solution seems like a classic data-driven web application with some search features.
That group may impose some unique constraints. You send Mayor van Damme an agenda for the on-site visit. We think we can get away with very little up-front design and want to concentrate on delivering value faster, even if that means rewriting parts of the application later.
The team wants to start writing code immediately after a two-week design spike. In this chapter, you learned how to use risk to plan our design activities. Risks can help us decide how much work to do up-front. We can also use risk to decide which design mindsets to adopt.
Since we create software to help people, we must understand the people whose lives will be affected by the software we make to understand the problem thoroughly. We call people with an interest or concern in our software stakeholders. Empathy is the engine that drives design. Talk to the Right People Stakeholders usually, but not always, have a business interest in the software.
They might pay for the software or directly profit from it. Users are important stakeholders but so too are the people who build and maintain the system.
In the wild, stakeholders rarely travel alone. We use the term stakeholder group to highlight this fact. Working with groups is different than working with individuals. Two people from the same stakeholder group can provide inconsistent or conflicting information.
Some Project Lionheart Stakeholders We want to make awesome software! Dev Team We need to cut the city s operating costs. I love security. I hate downtime.
System Administrator We manage the city s contracts and find the best prices. Enter the stakeholder map. How do I make sure I am bringing value to customers through my architecture?
My answer is to use a customer-centric design process. I start with who the customer is and what they want to do. I divide the system into tasks the customer performs.
For each task, I find out how they start it and where they run into issues. I call it Customer Experience Architecture. The prototype should be as interactive as possible, not just a flowchart. Step 3: Review the prototype as early as possible with the customer. Make sure they really understand what is changing in the new system and how it will impact them.
Using these four steps, you can create value for your customer through your architecture and become their hero, or at least not the person in the ivory tower who is ruining their life. Create a Stakeholder Map A stakeholder map is a network diagram showing all the people involved with or affected by the proposed software system.
Stakeholder maps are ideal for visualizing relationships and interactions among people. They also give you a snapshot of what motivates different stakeholders. Use stakeholder maps to decide who the most important people are to talk to about their concerns. There are several stakeholders not shown on this diagram for the sake of simplicity.
Additional stakeholders include IT vendors we might have to collaborate with, the Chamber of Commerce or other lobbying organizations , the deputy mayor, and various community groups who receive services from the city.
The city departments stakeholder can be made more precise by dividing it into the board of education, parks and recreation, public works, sanitation, and so on. If these groups have a similar stake in the system, then they could be lumped together as shown. Who is paying for the software?
Who is using it? Are there network hubs with many incoming or outgoing arrows? Are there stakeholders with potential conflicts of interest? These people are all excellent candidates for interviews and further research. Mayor van Damme hired us and we report to him, but the Office of Management and Budget receives policy direction from both the mayor and city council.
We should identify a few representative stakeholders and carefully validate our findings with the larger group. Some local businesses rely on lawyers to navigate the Request for Proposal process.
Different interaction patterns for the potential software might exist, which could influence the architecture. We should talk to the OMB directly. The steps for this activity are outlined in Activity 10, Stakeholder Map, on page Get Your Hands Dirty: Create a Stakeholder Map Pick an open source project you use or contribute to and create a stakeholder map for it. Are there subgroups within the organization who might have different vested interests? Who benefits from the choice of license?
What problems are they trying to solve? Discover the Business Goals Every software system is built to serve some fundamental purpose. Business goals describe what stakeholders hope to accomplish with the software. Business goals also seed conversations about quality attributes, trade-offs, and technical debt.
Business goals are a primary architectural driver and help prioritize competing concerns. Record Business Goal Statements Great business goal statements are measurable and have clear success criteria. Human-centered business goals allow your team to understand the people you are ultimately serving through the software you build.
Good business goal statements include three things: Subject A specific person or role. If the stakeholder or group has a name, use it. United Hamster Trainers Union is better than union groups. How does the world change if the system is successful?
You will design an architecture to achieve this outcome. For example, maybe the United Hamster Trainers Union needs a way to help members stay in touch with one another. Ideally context is insightful and not completely obvious. There are some business goals for Project Lionheart in the table on page Putting business goal statements in a slick-looking table sometimes makes them easier to read. Most systems only have only three to five business goals. More than this and the goals become confusing and difficult to remember.
A simple must have or nice to have designation is good enough for this purpose. Help Stakeholders Share Their Business Goals Stakeholders usually know what they want, but many stakeholders find it difficult to articulate their needs as measurable statements. Every architect should have a few simple templates in their toolbox to help stakeholders find their voice. Host collaborative workshops that create buy-in and get the whole team excited and involved in designing the software architecture.
Hands-on exercises, real-world scenarios, and practical team-based decision-making tools will give you the experience you need to become a confident software architect. Errata, typos, suggestions. Releases: P1.
The Way of the Web Tester. Liftoff, Second Edition. Talk about your software architecture with stakeholders using whiteboards, documents, and code, and apply architecture-focused design methods in your day-to-day practice. Hands-on exercises, real-world scenarios, and practical team-based decision-making tools will get everyone on board and give you the experience you need to become a confident software architect. This site comply with DMCA digital copyright. We do not store files not owned by us, or without the permission of the owner.
We also do not have links that lead to sites DMCA copyright infringement. Practical Node. Susanna Meier. So Vegan in 5: Over super simple and delicious 5-ingredient recipes. Tarty i zapiekanki. The Baby Led Feeding Cookbook: A new healthy way of eating for your baby that the whole family will love!
Roman Malkov. TypeScript 3. Hands-on exercises, real-world scenarios, and practical team-based decision-making tools will get everyone on board and give you the experience you need to become a confident software architect.
Nom de fichier : design-it-from-programmer-to-software-architect. Post a Comment. Monday, November 8, Design It!
0コメント