Updates from pierrepureur Toggle Comment Threads | Keyboard Shortcuts

  • pierrepureur 10:44 pm on March 25, 2016 Permalink | Reply
    Tags: , , , , ,   

    Delaying Decisions in Continuous Architecture 

    Delaying Design Decisions Yields Better Results!

    In the previous installment of our “Continuous Architecture” blog as well as in our book, we discussed how to effectively capture requirements.

    The second Principle of Continuous Architecture provides us with guidance to make architectural and design decisions to satisfy quality attribute requirements, and not to focus exclusively on functional requirements. Functional requirements often change frequently, especially if we are architecting one of those “Systems of Engagement” delivered over a mobile device whose user interface is likely to change frequently in response to changing customer needs, competitive response, and ever-evolving mobile technology.

    Even quality attribute requirements are subject to change, or at least to underestimation. When a mobile or web application’s popularity goes “viral”, even the most carefully crafted applications can collapse under the unexpected load. In addition, performance and availability targets may be vaguely described as Service Levels Agreements (SLA’s) or Objectives (SLO’s) are not always clear. A common practice is to err on the side of conservatism when describing those objectives which may result in unrealistic requirements.

    We recommend making design decisions based on known facts – not guesses. In our book and elsewhere in this blog, we describe how to leverage a Six-Sigma technique (Quality Function Deployment or QFD for short) to make sound architecture and design decisions. One of the advantages of the QFD process is that it encourages architects to document the rationale behind architecture and design decisions and to base decisions on facts, not fiction.

    An interesting parallel can be made between the principle of delaying design decisions and a technique called simulated annealing which is a probabilistic technique used for solving optimization problems.

    Image processing is one area where this technique is used.  Basically if you want to clean up a noisy image, instead of applying a deterministic model you iterate over the image thousands of times. At each iteration you make a decision for a particular pixel based on the value of its neighbors. The interesting part is that in the early iterations you allow a high value of uncertainty in that decision – i.e. you make a probabilistic guess. As iterations evolve you restrict the uncertainty, of the probabilistic jump. So the image cools down, just like steel cooling down when you anneal it – hence the simulated annealing term.

    How does this relate to architectural decisions? Simply put if you cool down the image too quickly it cracks – just like steel cracking if you cool it down too quickly. The same concept applies for architectural decisions, if you make too many decisions early on in the process your architecture will fracture.

    Below is a picture of a simulated annealing example, showing results of two parameter sets used in the algorithm (bottom left and bottom right quadrants)

    CA Figure 2-5

    As we move away from waterfall application development lifecycles involving large requirement documents and evolve toward the rapid delivery of a viable product, we need to create Minimum Viable Architectures (MVAs) to support the rapid delivery of those products. This concept is discussed in more details in Chapter 7 of our book and in one of our blog entries.

    To that effect, limiting the budget spent on architecting is a good thing; it forces the team to think in terms of a Minimum Viable Architecture that starts small and is only expanded when absolutely necessary. Too often, a team will solve problems that don’t exist, and yet fail to anticipate a crippling challenge that kills the application. Getting to an executable architecture quickly, and then evolving it, is essential for modern applications.

     

    Please check our blog at https://pgppgp.wordpress.com/ and our “Continuous Architecture” book (http://www.store.elsevier.com/9780128032848) for more information about Continuous Architecture

    Advertisements
     
  • pierrepureur 12:11 am on February 18, 2016 Permalink | Reply
    Tags: , , , , ,   

    Requirements in Continuous Architecture: Let’s Clarify! 

    CA Book Cover Small 2

    Clarifying Requirements is Important

    In the previous installment of our “Continuous Architecture” blog as well as in our book, we discussed an effective approach for capturing requirements. We suggested that thinking in terms of testable hypotheses instead of traditional requirements enables teams following the Continuous Architecture approach to quickly deliver systems that evolve in response to users’ feedback and meet or even exceed users’ expectations. But are we sure that we always understand what the system stakeholders want, even when they are able to precisely quantify those requirements?

    Philippe Kruchten tells the following story about the importance of clarifying requirements. Back in 1992, Philippe was leading the Architecture team for the Canadian Air Traffic Control System (CAATS), and the team had a requirement of “125 ms time to process a new position message from the Radar Processing System, from its arrival entry in the Area Control Center till all displays are up-to-date”.

    Here is how Philippe tells the story: “After trying very hard to meet the 125 ms for several months, I was hiking one day, looking at a secondary radar slowly rotating (I think it was the one on the top of Mount Parke on Mayne island, just across from Vancouver Airport). I thought … “mmm, there is already a 12-20 second lag in the position of the plane, why would they bother with 125ms…?”

    radar

    Note: primary radar uses an echo of an object. Secondary radar sends a message “who are you?” and the aircraft respond automatically with its ID and its altitude (http://en.wikipedia.org/wiki/Secondary_surveillance_radar). It looks like this: https://www.youtube.com/watch?v=Z0mpzIBWVG

    I knew all this because I am myself a pilot…

    Then I thought:  “in 125ms, how far across the screen can an aircraft go, assuming a supersonic jet… and full magnification”. Some back of the envelope computation gave me…about 1/2 pixel! When I had located the author of the requirement, he told me: “mmm, I allocated 15 seconds to the radar itself (rotation), 1 second for the radar processing system, 4 seconds for transmission, through various microwave equipment, that left 1 second in the ACC, breaking this down between all equipment in there, router, front end, etc.., it left 125ms for your processing, guys, updating and displaying the position…” These may not have been his exact words as this happened a long time ago, but this was the general line… Before agile methodologies made it a “standard”, it was useful for the architects to have direct access to the customer, often on site… And in this case being able to speak the same language (French)”.

    Philippe’s story clearly stresses that it is important for an Architect to question everything, and not to assume that requirements as stated are absolute.

     

    Please check our blog at https://pgppgp.wordpress.com/ and our “Continuous Architecture” book (http://www.store.elsevier.com/9780128032848) for more information about Continuous Architecture

     
  • pierrepureur 12:10 am on February 8, 2016 Permalink | Reply  

    Continuous Architecture and Requirements 

    Source: Continuous Architecture and Requirements

     
  • pierrepureur 12:09 am on February 8, 2016 Permalink | Reply
    Tags: , , , ,   

    Continuous Architecture and Requirements 

    CA Book Cover Small 2

    Don’t Think Functional Requirements, Think Faster Time to Feedback

    As we discussed in Chapter 1 of the “Continuous Architecture” book and elsewhere in this blog, capturing and managing requirements accurately and timely  – especially Quality Attribute Requirements – is an essential part of the Continuous Architecture approach. Traditionally, the approach to capturing and managing requirements has been based on conducting interviews of subject matter experts (SMEs) in order to document  requirements that the system must satisfy, often documented in voluminous documents which are hard to read and analyze. Ideally, the interviewees should be actual or prospective users of the system being developed, but in practice the interviewers often have to settle for representatives from the business who believe that they are familiar with the way the system is (or will be) used.

    Requirements Interviews Dilbert

    Collecting requirements from user representatives who attempt to guess the needs of real users as well as the best ways to satisfy those needs often result in systems that fall short of real users’  expectations. In addition there is often a significant time interval between the interviews and the delivery of the system, and this may lead to further disappointment as requirements  may change due to evolving business conditions.

    As Forrester Research Principal Analyst Kurt Bittner states, “The problem is the SME paradigm itself. No one person can represent the needs of all users, no matter how hard they try. The problem goes deeper: The conscious mind often cannot express what is really needed, and only knows what it doesn’t like when it sees it. As a result, the surest path to success is to put something out there that minimally satisfies some need, sometimes called a minimum viable product, and then improve upon that in rapid cycles.”

    The objective of the Continuous Architecture approach is to enable the rapid delivery of a minimum viable product that may be designed to satisfy some need or validate some hypothesis, and will continuously evolve as feedback from the users is received. As we describe in the book and in this blog, we achieve this objective by creating a “minimum viable architecture” that also continuously evolve as user feedback is received, and enables the delivery of a system that meets or even exceeds its users’ expectations.

    Please check our blog at https://pgppgp.wordpress.com/ and our “Continuous Architecture” book (http://www.store.elsevier.com/9780128032848) for more information about Continuous Architecture.

     
  • pierrepureur 12:41 am on January 20, 2016 Permalink | Reply  

    When Should Continuous Architecture Be Used? 

    Source: When Should Continuous Architecture Be Used?

     
  • pierrepureur 12:36 am on January 20, 2016 Permalink | Reply
    Tags: , , , ,   

    When Should Continuous Architecture Be Used? 

    With respect to release cycles and deployment mechanisms, modern architectures may need to function at multiple speeds. An IT organization is going to have a “portfolio” of applications, some of which can support high rates of change (due to their loosely coupled architectures), and some of which cannot be released very fast because they are tightly coupled and therefore tend to be brittle.

    A “Continuous Architecture approach” takes this into account and is able to deal with different release rates. For example, Systems of engagement (especially mobile and cloud applications) lend themselves to a Continuous Delivery approach. Systems of Record and Systems of Operation are usually not a good fit for Continuous Delivery as traditional tightly-coupled architectures often require substantial rewrites in order to keep pace with evolving business needs and enhancements are often postponed until the need becomes critical.

    As we discussed in an earlier post, Continuous Architecture is not a formal methodology. We think of it as an approach to adapt formal architecture thinking and discipline to an ever changing and evolving world. Our approach is driven by six simple principles (see figure below) and supporting tools.

    CA Figure 2-1

    As we describe in our book as part of our discussion of Principle 4 (Architect for Change – Leverage “The Power of Small”), loosely coupled architectures enable rapid changes and provide a significant advantage when “future-proofing” architectures.  However very few projects have the luxury of starting from a blank slate, and frequently architects have to deal with legacy, monolithic systems which often contain tightly coupled components. Uncoupling monolithic architectures is often a significant challenge but not an impossible one, and we offer some techniques in our book to deal with this challenge.

    Using a Continuous Delivery approach, IT teams can rapidly and safely implement new requirements from the business by creating a regular, controlled, and highly automated delivery pipeline. Using that approach, an IT organization is able to move from a traditional model where business partners specify requirements to one where they switch to “testable hypothesis”. This in turn creates a new, high-speed IT function that sits alongside the legacy IT function. Using this approach, the high-speed IT function can focus on the systems of engagement for a few business areas, and provide a lot of value to the business. However we believe that the Continuous Architecture approach isn’t limited to Agile and Continuous Delivery projects. We have used it on projects using iterative and even waterfall methodologies, and it produces excellent results!

    Please check other entries in this blog and our “Continuous Architecture” book (http://www.store.elsevier.com/9780128032848) for more information about Continuous Architecture

    CA Book Cover Small 2

     
  • pierrepureur 12:10 am on December 15, 2015 Permalink | Reply  

    Applying Continuous Architecture in Practice 

    Source: Applying Continuous Architecture in Practice

     
  • pierrepureur 12:09 am on December 15, 2015 Permalink | Reply
    Tags: , , , ,   

    Applying Continuous Architecture in Practice 

     

    Continuous Architecture is a set of principles and supporting tools.

    We do not aim to define a detailed architecture methodology or development process. Our main objective is to share a set of core principles and tools we have seen work in real-life practice. So applying Continuous Architecture is really about understanding the principles and applying them to the context of your environment. While doing this you can also decide about the tools you would want to recommend.

    We are responding to the current challenge of creating a solid architectural foundation in the world of agile and Continuous Delivery. However, that does not mean that applying Continuous Delivery is a prerequisite for adopting the Continuous Architecture approach. We realize that some companies may not be ready to adapt agile methodologies. Moreover, even if a company if fully committed to agile methodologies, there may be situations such as working with a third party software package where other approaches such as Iterative or incremental may be more appropriate.

    CA Figure 1-5

    Does this mean that Continuous Architecture would not work in this situation? Absolutely not.  This is one of the key benefits of the “Toolbox” approach. Its contents can be easily adapted to work with Iterative or Incremental instead of Agile.

    Continuous Architecture also operates in two dimensions: Time and Scale

    CA Figure 1-6

    The time dimension addresses how we enable architectural practices in a world of increasingly rapid delivery cycles, while the scale dimension looks at the level we are operating at (such as project, line of business, enterprise, etc…). We believe that the Continuous Architectural principles apply consistently at all scales, but the level of focus and the tools used might vary.

    Please check our blog at https://pgppgp.wordpress.com/
    and our “Continuous Architecture” book (http://www.store.elsevier.com/9780128032848) for more information about Continuous Architecture

     
  • pierrepureur 5:52 pm on December 2, 2015 Permalink | Reply  

    The Benefits of Continuous Architecture 

    Source: The Benefits of Continuous Architecture

     
  • pierrepureur 1:20 am on December 2, 2015 Permalink | Reply
    Tags: , , , ,   

    The Benefits of Continuous Architecture 

    CA Book Cover Small 2

    The cost-quality-time triangle is a well-known project management aid that basically states the key constraints of any project.

    CA Figure1-4c

    The basic premise is that it is not possible to optimize all three corners of the triangle; you are asked to pick any of the two corners and sacrifice the third.

    We do not claim that Continuous Architecture solves this problem, but the triangle does present a good context to think about benefits of Continuous Architecture. If we identify good architecture as representing quality in a software solution, then with Continuous Architecture, we have a mechanism that helps us balance time and cost. Another way of saying this is that Continuous Architecture helps us balance time and cost constraints while not sacrificing quality.

    The time dimension is a key aspect of Continuous Architecture. We believe that architectural practices should be aligned with Agile practices and not contradict them. In other words, we are continuously developing and improving the architecture rather than doing it once and creating the Big Architecture up Front (BARF). As we discuss in detail in our book  (“Continuous Architecture“- http://www.store.elsevier.com/9780128032848) and elsewhere in this blog, Continuous Architecture puts special emphasis on Quality Attributes (Principle 2: Focus on Quality Attributes, not on functional requirements). We believe that cost is one of the Quality Attributes that is often overlooked but is critical in making the correct architectural decisions.

    Continuous Architecture does not solve the cost-quality-time triangle, but it gives us tools to balance it while maintaining quality. An element that the cost-quality-time triangle does not address is sustainability. Most large enterprises have a complex technology and application landscape as a result of years of business change and IT initiatives. Agile and Continuous Development practices focus on delivering solutions and ignore addressing this complexity. Continuous Architecture tackles this complexity and strives to create a sustainable model for individual software applications as well as the overall enterprise.

    Applying Continuous Architecture at the individual application level enables a sustainable delivery model and a coherent technology platform resilient against future change. Applying Continuous Architecture at the
    enterprise level enables increased efficiency in delivering solutions and a healthy ecosystem of common platforms.

     
c
Compose new post
j
Next post/Next comment
k
Previous post/Previous comment
r
Reply
e
Edit
o
Show/Hide comments
t
Go to top
l
Go to login
h
Show/Hide help
shift + esc
Cancel