Developers are faced with a smorgasbord of architecture activities but few models telling them which activities to use. Alternatives include the documentation package model, which advocates a complete architectural description from many perspectives, and the evolutionary design model, which advocates no up-front architectural work.
This talk explains the risk-centric model, inspired by Attribute Driven Design (ADD), Global Analysis, and the Spiral model. In the risk-centric model, risks are central, so developers: (1) prioritize the risks they face, (2) choose appropriate architecture techniques to mitigate those risks, and (3) re-evaluate remaining risks. It encourages “just enough” architecture by guiding developers to a prioritized subset of architecture activities. It makes explicit the mappings between risks and corresponding architecture techniques.
Like ADD and Global Analysis, and unlike the Spiral model, the risk-centric model is not a full software development process and can instead be used inside a process such as XP or RUP.
In his recent book, Clean Agile, Robert C "Uncle Bob" Martin chooses Extreme Programming (XP) for the basis of his explanation of Agile because "of all the Agile processes, XP is the best defined, the most complete, and the least muddled."
So why is it that in my professional life I only hear us speaking about Agile in terms of Scrum, Sprints, and possibly Kanban? Often I mention XP and people are not sure what I mean. Am I sure myself?
Coined in 1999 by Kent Beck and Ward Cunningham, XP has been with us for twenty years, but may of its practices have been with us for much longer. Many of them will be familar to you, but did you know they came from XP?
This talk aims to take us back to what XP is, how it fits in the Agile world, how it sits alongside other methodologies, and why, like Uncle Bob, I believe it is the best defined methodology, and what we should all be talking about.
The talk is based on a heavily refactored talk that Mike gave previously at Agile on the Beach conference, updated for 2020.
Given at Ox:Agile Meetup on February 11th 2020: https://www.meetup.com/OXAGILE/events/nxrdmrybcdbpb/
Model-Driven Architecture for Cloud Applications Development, A survey Editor IJCATR
Model Driven Architecture and Cloud computing are among the most important paradigms in software service engineering now a days. As cloud computing continues to gain more activities, more issues and challenges for many systems with its dynamic usage are introduced. Model Driven Architecture (MDA) approach for development and maintenance becomes an evident choice for ensuring software solutions that are robust, flexible and agile for developing applications.
This paper aims to survey and analyze the research issues and challenges that have been emerging in cloud computing applications with a focus on using Model Driven architecture (MDA) development. We discuss the open research issues and highlight future research problems.
Attribute Driven Styles: The Good, the Bad, and the Unknown (SassConf 2015 Di...Jonathan Cutrell
Attributes provide us with a high amount of flexibility that we have largely ignored. In this discussion, we'll explore how attributes may help create a more flexible, maintainable, and intentional way of building stylesheets.
In his recent book, Clean Agile, Robert C "Uncle Bob" Martin chooses Extreme Programming (XP) for the basis of his explanation of Agile because "of all the Agile processes, XP is the best defined, the most complete, and the least muddled."
So why is it that in my professional life I only hear us speaking about Agile in terms of Scrum, Sprints, and possibly Kanban? Often I mention XP and people are not sure what I mean. Am I sure myself?
Coined in 1999 by Kent Beck and Ward Cunningham, XP has been with us for twenty years, but may of its practices have been with us for much longer. Many of them will be familar to you, but did you know they came from XP?
This talk aims to take us back to what XP is, how it fits in the Agile world, how it sits alongside other methodologies, and why, like Uncle Bob, I believe it is the best defined methodology, and what we should all be talking about.
The talk is based on a heavily refactored talk that Mike gave previously at Agile on the Beach conference, updated for 2020.
Given at Ox:Agile Meetup on February 11th 2020: https://www.meetup.com/OXAGILE/events/nxrdmrybcdbpb/
Model-Driven Architecture for Cloud Applications Development, A survey Editor IJCATR
Model Driven Architecture and Cloud computing are among the most important paradigms in software service engineering now a days. As cloud computing continues to gain more activities, more issues and challenges for many systems with its dynamic usage are introduced. Model Driven Architecture (MDA) approach for development and maintenance becomes an evident choice for ensuring software solutions that are robust, flexible and agile for developing applications.
This paper aims to survey and analyze the research issues and challenges that have been emerging in cloud computing applications with a focus on using Model Driven architecture (MDA) development. We discuss the open research issues and highlight future research problems.
Attribute Driven Styles: The Good, the Bad, and the Unknown (SassConf 2015 Di...Jonathan Cutrell
Attributes provide us with a high amount of flexibility that we have largely ignored. In this discussion, we'll explore how attributes may help create a more flexible, maintainable, and intentional way of building stylesheets.
This presentation describe the importance of trade-off between software architecture quality attribute (NFR). Explain about Performance, Security, Availability and Scalability in depth and other in briefly.
Presented on tech talk @ DFN Technology.
How To Close-Out Your Project Successfully!Louis Henry
Here are 4 steps that you can use to close-out your projects.
If you're a entrepreneur or salesperson then you should set up a closing system for yourself; it will only give you room to improve your results...
Today’s mainstream acceptance of Agile+DevOps as the preferred way of working once again raises questions of what architecture work is and who does it. It simultaneously challenges much of our previously accepted wisdom, preferring architecture to be a “shared commons” across the development organisation, while demanding a sophisticated level of software architecture practice to deliver on the promises of Agile+DevOps.
One way of describing this situation is the need to “democratise” software architecture so it becomes a shared responsibility rather than a centralised impediment to rapid delivery. In this talk we’ll examine the challenges of software architecture in today’s modern distributed teams and ask how we might make the architecture of their systems a shared responsibility to allow them to achieve the software architecture that they need at the speed that they need it.
What can we learn from other design disciplines? How do they learn design? What can we copy from them?
This is a challenge for software developers to start thinking as code designers, as people who use code as a material to prototype solutions to problems.
This presentation describe the importance of trade-off between software architecture quality attribute (NFR). Explain about Performance, Security, Availability and Scalability in depth and other in briefly.
Presented on tech talk @ DFN Technology.
How To Close-Out Your Project Successfully!Louis Henry
Here are 4 steps that you can use to close-out your projects.
If you're a entrepreneur or salesperson then you should set up a closing system for yourself; it will only give you room to improve your results...
Today’s mainstream acceptance of Agile+DevOps as the preferred way of working once again raises questions of what architecture work is and who does it. It simultaneously challenges much of our previously accepted wisdom, preferring architecture to be a “shared commons” across the development organisation, while demanding a sophisticated level of software architecture practice to deliver on the promises of Agile+DevOps.
One way of describing this situation is the need to “democratise” software architecture so it becomes a shared responsibility rather than a centralised impediment to rapid delivery. In this talk we’ll examine the challenges of software architecture in today’s modern distributed teams and ask how we might make the architecture of their systems a shared responsibility to allow them to achieve the software architecture that they need at the speed that they need it.
What can we learn from other design disciplines? How do they learn design? What can we copy from them?
This is a challenge for software developers to start thinking as code designers, as people who use code as a material to prototype solutions to problems.
Getting Started with Architecture Decision RecordsMichael Keeling
Documenting architecture design decisions is commonly considered a good practice and yet many teams don't take the time to write down the decisions they make. In our experience this happens for a few reasons: documentation is rejected as being too heavyweight, documentation has little influence since it is typically out of sight and out of mind, and many developers don’t know what to document. Architecture Decision Records (ADRs) address many of these problems by capturing design decisions in a simple, lightweight templates that is stored close to repositories used by stakeholders -- often in the same repository as code affected by the ADR.
In this hands-on workshop you will learn how to write effective ADRs and how to overcome road bumps teams often experience when first getting started with ADRs. By the end of this session you will have the skills you need to champion ADRs and help your team start (or improve) your design decision log.
Minimum Viable Architecture - Good Enough is Good EnoughRandy Shoup
The “right” architecture and organization depends on the size and scale of your company. The only constant is change, and what works for 5 engineers does not work for 5000. Based upon lessons from Google and eBay, learn how to evolve both technology and organization together successfully.
This presentation is based on many hard-won lessons by the speaker, who led large-scale engineering teams at Google and eBay, but also co-founded a tiny startup and tried (unsuccessfully) to apply the same techniques. This session hopes to help others from making the same mistakes by introducing the concept of “Minimal Viable Architecture”. It outlines the common architectural evolution of a company or project through the search, execution, and scaling phases, and discusses the appropriate technologies, disciplines, and organizational structures at each phase. You'll start with a monolith, and end up with microservices, and that's completely and entirely appropriate.
No I’m not talking about the feedback loops that you might hear over a bad PA system. I’m talking about building into your architecture the feedback gathering that will give you valuable insights into how your users are using your application, the perceived performance of your application, how the quality of your application is trending over time, how effective your development process is, and allow you to fix bugs before your users report problems. This knowledge will empower the team to make fact-based decisions based on data, rather than only being able to use the team’s intuition.
This presentation will cover: the theory behind why feedback is important, the ways you can progressively build feedback into your architecture, and detail some real world examples.
Scott Davis presented on Resource-Oriented Architecture (ROA) and REST on August 17th at IASA Denver.
Google quietly deprecated their SOAP search API at the end of 2006. While this doesn't mean that you should abandon SOAP, it does reflect a growing trend towards simpler dialects of web services. Google joins a number of popular websites (Yahoo!, Amazon, eBay, and others) that offer all of the benefits of web services without all of the complexity of SOAP.
In this talk, we look at the semantic differences between a Service-Oriented Architecture and a Resource-Oriented Architecture. We contrast RPC-centric interfaces with object-oriented interfaces. We discuss HTTP-RPC services that call themselves RESTful, and compare them to fully RESTful web services that leverage HTTP verbs like GET, POST, PUT, and DELETE. We look at RESTful implementations using Java Servlets and exploit Grails' native REST support.
Business and Strategic Alignment in EA – Practical Guidelines Based on Indust...IASA
Business and Strategic Alignment in EA – Practical Guidelines Based on Industry Best Practices - Dave Guevara
As IASA members we are constantly reminded that architects are responsible for connecting business to IT. Business alignment is indicated in architecture frameworks like TOGAF or Zachman as an important step. However, the challenge comes in getting this done where EA is not top-down driven, short term deadlines always win over strategic efforts and standards like ITIL, COBIT and BPMN help but don’t really answer how There is a great deal of writing about EA, SOA, their benefits and how they need to be driven by business needs. The architect is still left with diverse guidance that provides little practical help on how exactly to conduct line-of-sight alignment between business strategy and system implementation. In this discussion, we will look at this issue from four perspectives:
1. Practical means of determining business value and impact, then creating alignment to your future state architectures.
2. Top-down view using an EA framework.
3. Bottoms up view in a future state architecture
4. Business functional model related to an application functional model
5. Practical suggestions that work now and can scale over time
Rethinking Object Orientation - By Kathleen Dollard
Decades after object orientation design altered programming, it’s still evolving, and we’re still learning to use it better. Many changes in the tools we use and how we write applications affect the approach we take to OOD. Some of these changes relate to architecture where approaches like SOA and the layering revolution behind Silverlight alter the place of traditional OOD within the bigger picture of architecture. Other changes are language improvements that alter the very meaning of the phrase “object” from a design point of view. Language features that alter our implementation of logical objects include generics, extension methods, delegates/lambda expressions, partial classes/methods, reflection, anonymous types, and declarative programming.
We’ll also explore the growing role of interfaces as a contractual base in composable applications and explore differences between traditional applications and ecosystem empowering applications. I’m really excited to give this talk to a group with diverse skillsets! Come ready for multi-way conversations because I want to learn from you.
Making Architecture Business Value Driven - Dave Guevara
The Denver IASA June 2008 meeting looked at the Business of Architecture. This discussion will look at one part of the broad topic, the business and strategic alignment processes that align IT to be business value driven.
The alignment that we will focus on is between the strategic intent of a company, and the capabilities that are needed to implement the business processes and technologies that will execute that strategic intent. A case study example will be used to illustrate some of the “how to” methods for doing this in your organization. This session will be interactive.
In addition to discussion these new concepts relating strategic intent to capabilities (Business, Organizational, Technical, Integration) we will also take a brief look at getting from capabilities down to User Story inventories and ultimately into services development. Recent feedback from the Agile conference was that these concepts and their use were spot on to where the thought leadership is moving to in the Agile field.
An astonishing, first-of-its-kind, report by the NYT assessing damage in Ukraine. Even if the war ends tomorrow, in many places there will be nothing to go back to.
‘वोटर्स विल मस्ट प्रीवेल’ (मतदाताओं को जीतना होगा) अभियान द्वारा जारी हेल्पलाइन नंबर, 4 जून को सुबह 7 बजे से दोपहर 12 बजे तक मतगणना प्रक्रिया में कहीं भी किसी भी तरह के उल्लंघन की रिपोर्ट करने के लिए खुला रहेगा।
31052024_First India Newspaper Jaipur.pdfFIRST INDIA
Find Latest India News and Breaking News these days from India on Politics, Business, Entertainment, Technology, Sports, Lifestyle and Coronavirus News in India and the world over that you can't miss. For real time update Visit our social media handle. Read First India NewsPaper in your morning replace. Visit First India.
CLICK:- https://firstindia.co.in/
#First_India_NewsPaper
03062024_First India Newspaper Jaipur.pdfFIRST INDIA
Find Latest India News and Breaking News these days from India on Politics, Business, Entertainment, Technology, Sports, Lifestyle and Coronavirus News in India and the world over that you can't miss. For real time update Visit our social media handle. Read First India NewsPaper in your morning replace. Visit First India.
CLICK:- https://firstindia.co.in/
#First_India_NewsPaper
01062024_First India Newspaper Jaipur.pdfFIRST INDIA
Find Latest India News and Breaking News these days from India on Politics, Business, Entertainment, Technology, Sports, Lifestyle and Coronavirus News in India and the world over that you can't miss. For real time update Visit our social media handle. Read First India NewsPaper in your morning replace. Visit First India.
CLICK:- https://firstindia.co.in/
#First_India_NewsPaper
El Puerto de Algeciras continúa un año más como el más eficiente del continente europeo y vuelve a situarse en el “top ten” mundial, según el informe The Container Port Performance Index 2023 (CPPI), elaborado por el Banco Mundial y la consultora S&P Global.
El informe CPPI utiliza dos enfoques metodológicos diferentes para calcular la clasificación del índice: uno administrativo o técnico y otro estadístico, basado en análisis factorial (FA). Según los autores, esta dualidad pretende asegurar una clasificación que refleje con precisión el rendimiento real del puerto, a la vez que sea estadísticamente sólida. En esta edición del informe CPPI 2023, se han empleado los mismos enfoques metodológicos y se ha aplicado un método de agregación de clasificaciones para combinar los resultados de ambos enfoques y obtener una clasificación agregada.
1. Risk-Centric Model of
Software Architecture
George Fairbanks
16 November 2009
Rhino Research
Software Architecture Consulting and Training
Full paper: http://rhinoresearch.com/content/risk-centric-model-software-architecture
2. Overview
• Software architecture techniques are helpful
• We cannot afford to apply them all
• Important: How much should we do?
• Old: Yardstick model
• Old: Full description model
• This talk describes a new model: Risk-Centric Model
1. Identify and prioritize risks
2. Apply relevant architecture activities
3. Re-evaluate
• It is not: Big Design Up Front
• It is not: A full software development process
• It is: Compatible with agile & other processes
16 November 2009 George Fairbanks – RhinoResearch.com 2
3. Talk outline
• Architecture essentials
• When do we design the architecture?
• How much architecture should we do?
• Risk-centric model
• Risks
• Techniques
• Processes & related work
• Conclusion
16 November 2009 George Fairbanks – RhinoResearch.com 3
4. What is software architecture?
The software architecture of a program or computing system is
its structure or structures, which comprise software elements, the
externally visible properties of those elements, and the relationships
among them. [Bass, Clements, Kazman 2003]
• In loose language:
• It’s the macroscopic organization of the system
• Must keep these ideas separate:
• The job title/role “architect”
• The process of architecting/designing (also: when)
• The engineering artifact called the architecture
• Every system has an architecture
• Identify it by looking back (avoids tangling with process & roles)
• E.g., “Aha, I see it is a 3-tier architecture”
16 November 2009 George Fairbanks – RhinoResearch.com 4
5. Every system has an architecture
Viewtype Contents
Module Modules, Dependencies, Layers
Runtime Components, Connectors, Ports
Allocation Servers, Communication channels
• Three primary viewtypes: Module, Runtime, Allocation
• Many views within a viewtype
• Architectural styles
• Big ball of mud
• Client-server
• Pipe-and-filter
• Map-reduce
• N-tier
• …
16 November 2009 George Fairbanks – RhinoResearch.com 5
6. Architecture as skeleton
• An animal’s skeleton:
• Provides its overall structure
• Influences what it can do
• Examples
• Birds fly better because of wings and light bones
• Kangaroos jump because of leg structure
• Convergent evolution: Bat skeletons have wings
• Tradeoffs
• 4 legs faster vs. 2 legs easier to use tools
• Software skeleton examples
• 3-tier: localize changes, concurrent transactions
• Cooperating processes: isolate faults
• Peer-to-peer: no central point of failure
16 November 2009 George Fairbanks – RhinoResearch.com 6
7. Architecture influences quality attributes
• Function: Carrying apples to market
• Solution 1: Use humans
• Solution 2: Use horses
• Both solutions work
• Yet differ in their quality attributes
• Quality attributes
• A.k.a. extra-functional requirements, the “ities”
• E.g., latency, modifiability, usability, testability
• Architecture influences the system’s quality attributes
• E.g., pipe and filter is reconfigurable
• E.g., map-reduce is scalable
16 November 2009 George Fairbanks – RhinoResearch.com 7
8. Architecture orthogonal to functionality
• Architecture orthogonal to functionality
• Can mix-and-match architecture and functionality
• Can (mostly) build any system with any architecture
• Shift in thinking
• No: good or bad architectures
• Yes: suitable or unsuitable to supporting the functions
• Architecture can help or hurt you achieve functionality
• Help example: use horses to transport apples
• Hurt example: use horses to stack apples
16 November 2009 George Fairbanks – RhinoResearch.com 8
9. Talk outline
• Architecture essentials
• When do we design the architecture?
• How much architecture should we do?
• Risk-centric model
• Risks
• Techniques
• Processes & related work
• Conclusion
16 November 2009 George Fairbanks – RhinoResearch.com 9
10. Q: When do we design the architecture?
The software architecture of a program or computing system is
its structure or structures, which comprise software elements, the
externally visible properties of those elements, and the relationships
among them. [Bass, Clements, Kazman 2003]
• Recall these three distinct ideas:
• The job title/role “architect”
• The process of architecting/designing (also: when)
• The engineering artifact called the architecture
• At some point, the architecture (the artifact) exists
• Question: When did we decide on it? (our process)
• To understand, worth considering two design styles:
• Evolutionary design
• Planned design
16 November 2009 George Fairbanks – RhinoResearch.com 10
11. Evolutionary design vs. planned design
Evolutionary design Planned design
• Fundamental beliefs • Fundamental beliefs
• Hard to correctly decide • Possible to paint yourself
early in project into a corner
• Refactoring reduces cost of • Cost of change is high
change
• So: Defer decisions when • So: Decide now to reduce costs
possible
Shared ground
• Cost of change is never zero
• Every project has some evolutionary, some planned design
16 November 2009 George Fairbanks – RhinoResearch.com 11
12. Engineering failures
The concept of failure is central to the design process, and it is by
thinking in terms of obviating failure that successful designs are
achieved. ... Although often an implicit and tacit part of the
methodology of design, failure considerations and proactive failure
analysis are essential for achieving success. And it is precisely when
such considerations and analyses are incorrect or incomplete that
design errors are introduced and actual failures occur. [Henry
Petroski, Design Paradigms, 1994]
Required You can choose
• Considering failures • When design happens
• Analyzing options • Which analyses
• Designing a solution • Formality / precision
• Depth
16 November 2009 George Fairbanks – RhinoResearch.com 12
13. Talk outline
• Architecture essentials
• When do we design the architecture?
• How much architecture should we do?
• Risk-centric model
• Risks
• Techniques
• Processes & related work
• Conclusion
16 November 2009 George Fairbanks – RhinoResearch.com 13
14. How much architecture?
• Situation: • Answer 1: Yardstick
• Lots of architecture • E.g., spend 10% of your
techniques time designing
• All cost something • Not so helpful on
• Cannot afford to do them all Wednesday
• No technique choice
• Two problems
• Which techniques? • Answer 2: Documentation
• When to stop? package (i.e., full design)
• Expensive
• Overkill for most projects
• Answer 3: Ad hoc compromise
• Unrepeatable
Desired: A principled way to decide how much is enough
16 November 2009 George Fairbanks – RhinoResearch.com 14
15. Inspiration: Dad vs. mailbox
• My Dad
• Mechanical engineer
• Capable of analyzing stresses and strains
• The problem
• Install new mailbox
• His solution
• Dig hole
• Fill with concrete
• Stick in post
• Q: Why no mechanical engineering analyses?
• A: Risk
• He just wasn’t worried enough
16 November 2009 George Fairbanks – RhinoResearch.com 15
16. Insight #1: Prioritize using risks
• At any given moment, you have worries and non-worries
• Worry: Will the server scale up?
• Worry: Will bad guys steal customer data?
• Response time will be easy to achieve
• We have plenty of RAM
• Cast these worries as engineering risks
• Focus on highest priority risks
• Good news: prioritizing risks is easy for developers
• They can tell you what they are most worried about
• I.e., possible failures
• Bad news: you might get blindsided
• But you cannot plan for the unexpected
16 November 2009 George Fairbanks – RhinoResearch.com 16
17. Insight #2: Techniques mitigate risks
• Many architecture techniques exist
• Protocol analysis
• Component and connector modeling
• Queuing theory
• Schedulability analysis
• Threat modeling
• Techniques are not interchangeable
• E.g., cannot use threat modeling on latency risks
• So, must match risks with techniques
• I.e., mapping from risks à techniques
16 November 2009 George Fairbanks – RhinoResearch.com 17
18. Talk outline
• Architecture essentials
• When do we design the architecture?
• How much architecture should we do?
• Risk-centric model
• Risks
• Techniques
• Processes & related work
• Conclusion
16 November 2009 George Fairbanks – RhinoResearch.com 18
19. Risk-centric architecture
• The risk-centric model:
1. Identify and prioritize risks
2. Apply relevant architecture activities
3. Re-evaluate
• Promotion of risk to prominence
• Today, developers think about risks
…but they think about lots of other things too
• [Babar 09] describes team so functionality focused that quality
attribute concerns deferred until development ceased and
product was in maintenance mode.
• [Kruchten08] Agile2008 keynote talk: similar story
• Must balance
• Wasting time on low-impact techniques
• Ignoring project-threatening risks
16 November 2009 George Fairbanks – RhinoResearch.com 19
20. Risk-centric model applies to design
• Many models organize the software development lifecycle:
• Spiral, waterfall, iterative, RUP, XP
• Risk-centric model applies only during design
Example of use inside an iterative process
Iteration 0 Iteration 1 Iteration 2 Iteration 3 …
Architecture and design activities
Other development activities
• Q: When were (perceived) risks the highest?
16 November 2009 George Fairbanks – RhinoResearch.com 20
21. Risk-centric model is uncommon
• I.e., You are probably not doing this today
• Some test questions:
• Are risks primary?
• Are your risks written down?
• Any developer can list the features
…but list of risks seems to be made up on the spot
• Are techniques decided per-project?
• Most teams have standard set of techniques
• Often defined by process or template
• Do all projects have the same risks?
• E.g., customer-facing and infrastructure
16 November 2009 George Fairbanks – RhinoResearch.com 21
22. Talk outline
• Architecture essentials
• When do we design the architecture?
• How much architecture should we do?
• Risk-centric model
• Risks
• Techniques
• Processes & related work
• Conclusion
16 November 2009 George Fairbanks – RhinoResearch.com 22
23. Definition of risk
• Simple definition
Risk = probability of failure x impact of failure
• But, uncertainty is inherent
• Uncertain probability; uncertain impact
• So, resort to educated guesses = perception
• Revised definition
Risk = perceived probability of failure x perceived impact of failure
• Consequences of uncertainty
• Can perceive risks even if none exist
• Can fail to perceive risks
• Risk prioritization is hard and subjective
16 November 2009 George Fairbanks – RhinoResearch.com 23
24. Describing risks
• Schemas for describing risks
• Condition-Transition-Consequence [Gulch94]
• Failure scenarios (testable)
• Categorical (e.g., “security risk”)
• Examples
• “[Cr|H]ackers exist, so sensitive data may be revealed leading to
reputation and financial loss.”
• “The chosen web framework may prevent us from meeting
transactions-per-second requirements”
16 November 2009 George Fairbanks – RhinoResearch.com 24
25. Engineering risk vs. management risk
Software engineering risks Project management risks
• “I’m afraid that the server will • “Lead developer hit by bus”
not scale to 100 users”
• “Customer needs not
• “Parsing of the response understood”
messages may not be robust”
• “Senior VP hates our manager”
• “It’s working now but if we
touch anything it may fall • “Competitor is first to market”
apart.”
Mismatches
• Use PERT chart to eliminate buffer overruns
• Use caching to prioritize features
16 November 2009 George Fairbanks – RhinoResearch.com 25
26. Canonical risks in domains
• Information Technology (IT)
• Complex, poorly understood problem domain
• Unsure we’re solving the real problem
• May choose wrong COTS software
• Integration with existing, poorly understood software
• Domain knowledge scattered across people
• Modifiability
• Systems
• Composition risk—will it go together?
• Performance, reliability, size, security
• Concurrency
• Web
• Developer productivity
• Security
• Scalability
16 November 2009 George Fairbanks – RhinoResearch.com 26
27. Talk outline
• Architecture essentials
• When do we design the architecture?
• How much architecture should we do?
• Risk-centric model
• Risks
• Techniques
• Processes & related work
• Conclusion
16 November 2009 George Fairbanks – RhinoResearch.com 27
28. Techniques in other fields
• In mechanical engineering
• Stress calculations, breaking point tests
• In electrical engineering
• Circuit analysis
• In aerospace engineering
• Thermal analysis, electrical analysis, mechanical analysis
• Prototyping: everywhere
16 November 2009 George Fairbanks – RhinoResearch.com 28
29. Recall insight #2: Map techniques to risks
• This talk: How much architecture? When to stop?
• Also: Which architecture techniques? Ad hoc choices?
• Desire: Choose like virtuoso?
• Virtuosos solve problems intuitively
• Often they can jump directly to the solution / choice
• Mysterious
• Aha!: Encode virtuoso judgment
• Make tacit knowledge explicit
• Accelerate learning
• Can discuss suitability
• If risk X, do technique Y
• Thinking process
• Tabularized data
16 November 2009 George Fairbanks – RhinoResearch.com 29
30. Risk à technique table
Risk Technique
Problem domain poorly • Create a Domain model (Problem frames, info model,
understood behavior model including use cases)
Others must understand • Create a context diagram
our design • Create a use case model
• Low fidelity UI prototyping (e.g., cards)
We don’t know the • Create Module and Component & Connector view of system
interfaces between our • Co-locate teams
components / teams • Peer-to-peer communication not mediated by managers
Problem is too big to be • Partition into components
solved by one person or • Encapsulate components
one team • Design for extension. Ensure style is clear (e.g., J2EE, or
WinAmp plugin API)
• Document architecture (all 3 viewtypes) and invariants
clearly and communicate it to teams
…
• Just an illustrative example
• Goal: general handbooks; company-specific best practices
16 November 2009 George Fairbanks – RhinoResearch.com 30
31. Talk outline
• Architecture essentials
• When do we design the architecture?
• How much architecture should we do?
• Risk-centric model
• Risks
• Techniques
• Processes & related work
• Conclusion
16 November 2009 George Fairbanks – RhinoResearch.com 31
32. Related work
• Attribute Driven Design (ADD)
• Tabularizes mapping from quality attributes à patterns
• E.g., availability à ping/echo pattern
• Bass, Clements, Kazman, Software Architecture in Practice, 2003
• Global Analysis
• Identify “Factors”, choose matching “Strategies”
• Bridges engineering & management
• Hoffmeister, Soni, Nord, Applied Software Architecture, 2000
• Spiral model
• Specialization of iterative model that prioritizes risk
• Boehm, A Spiral Model of Software Development and Enhancement, 1988
• Balancing agility and discipline
• Processes: use risk to choose process rigor
• Boehm and Turner, Balancing Agility and Discipline, 2003
16 November 2009 George Fairbanks – RhinoResearch.com 32
33. Talk outline
• Architecture essentials
• When do we design the architecture?
• How much architecture should we do?
• Risk-centric model
• Risks
• Techniques
• Processes & related work
• Conclusion
16 November 2009 George Fairbanks – RhinoResearch.com 33
34. How much architecture?
• How much architecture is enough?
• Time spent designing vs. time spent building
• Desired: objective, quantitative decision
STOP?
• Old answers: Yardsticks, full design, and ad hoc
• Risk-Centric Model answer
• Do architecture until risks subside
• But: Risks never eliminated, subjective risk estimates
• So, does risk help?
• Yes: Shared vocabulary (“risks”) with management
• Yes: Refined evaluation ability
• Subjective risk estimate better than:
• Yardstick (e.g., spend 10% of your time designing)
• Full design
16 November 2009 George Fairbanks – RhinoResearch.com 34
35. Takeaway ideas
• 3 distinct ideas:
• The job title/role “architect”
• The process of architecting/designing
• The engineering artifact called the architecture
• Every project is combination of planned & evolutionary decisions
• You should calibrate your project’s balance using risks
• Risk is a unifying concept
• Managers understand it
• Engineers understand it
• Architecture is compatible with agile
• Agile will do more evolutionary design
• Use risk to mix in architecture design
• Inspiration: Dad vs. Mailbox
16 November 2009 George Fairbanks – RhinoResearch.com 35
36. Conclusion
• Software architecture techniques are helpful
• We cannot afford to apply them all
• Important: How much should we do?
• Old: Yardstick model
• Old: Full description model
• This talk describes a new model: Risk-Centric Model
1. Identify and prioritize risks
2. Apply relevant architecture activities
3. Re-evaluate
• It is not: Big Design Up Front
• It is not: A full software development process
• It is: Compatible with agile and other processes
16 November 2009 George Fairbanks – RhinoResearch.com 36