This is the governing body for certification in Disciplined Agile.

Identify Initial Architecture Strategy Goal

<< First  < Prev   1   2   Next >  Last >> 
  • 22 May 2018 9:56 AM
    Reply # 6251714 on 5879723
    Scott Ambler (Administrator)

    @Valentin:

    • Good points about cross-cutting concerns.  We've updated our Views & Concerns diagram to reflect what you've written. I'm also going to include that in the discussion around Capturing Non-Functionals in the Explore Initial Scope process goal.
    • I agree with your point about how business use cases can drive your architecture, amongst other types of usage requirements.  BUT, use cases are something we cover in Explore Initial Scope to explore usage.  
    • Lifecycle selection - Good stuff.  We have similar material on this topic already but will use what you've written here to enhance the material.  This is a topic for chapter 4 in the book (if I'm not mistaken) but we haven't focused on that yet.


  • 09 Apr 2018 11:37 AM
    Reply # 6077840 on 5879723
    Architecture of a component

    (cross-cutting concerns - only a detail)

    When we are building a new product, or when we have a major upgrade (of the product), the architecture of a component a fundamental aspect. We have made major products upgrades where the most of the components remain the same (forced move: one component represent an aspect of the usage), but the major architectural change is related to the interior of a component.

    Ime the work related to the interior of a component could suppose hundreds of times more effort than identification of the high-level components. This part of the architecture could include the main decisions related to the separation of concerns, addressing some NFRs for each component, addressing cross-cutting concerns.

    If I do not have a solution/architecture for each type of component, I have no solution, but just some drawings and concepts.  

    If I play the role of the product sponsor I will consider that the development team has a proven architecture only if they have proved each major type of components. IME this was the fundamental aspect that makes a solution approach valuable. I will deliver value by delivering components. I will continuously deliver components only if I have a solution for each component type. Just the list of the components is not the architecture, but only having also an architecture for each type of component.

    Examples fro types of components:

    • Background service
    • UI-Business-DB component
    • (network) Service
    • Data-exchange mechanisms 

    I expect that the main cross-cutting concerns to be addressed for each type.  Here are some of them that I would consider mandatory in architecture envisioning: error response, memory management, internationalization and localization, information security, logging
    monitoring, exclusive access (locking).  I saw too many problems created by these aspects, and now I expect architectures that will give a consistent approach.  

    I think we should not discrimnate between various dimensions of the architecture.  

  • 09 Apr 2018 10:29 AM
    Reply # 6057021 on 5879723

    Business use cases to explore the architecture

    Intro: The development aspects are interrelated, and a decision about requirements could affect the optimum about the solution approach (the optimum is about the whole, not about the parts). 

    A good architecture approach could explicitly represent the usage and decouple this usage from other aspects (easy to change). For example, we could use the functional criteria to create components

    We could also think to a very high-level TDD/validation, so the usage is a significant aspect of the architecture. 

    A more concrete example - software for a retail store. The main business cases in a day are

    • Open the store; including import of the product catalogs
    • Sales, stock values update, average cost recomputation from stock
    • Other stock movements
    • Close the day for that store
    Use cases (business use cases included) are an explicit representation of the usage ~ that directly drive a solution validation (easier to imagine, implement test cases; easier to understand if I will fulfill the business needs). Just looking to above business use cases, I could note some basic solution decisions:
    • I would need a scheduled service for opening and closing the store (that will orchestrate other specialized services); I could need reverse/retry and monitoring features
    • I would need a mechanism to centralize sales information
    • I would need regression tests (TDD) for a business day starting from these business use cases.
  • 09 Apr 2018 9:54 AM
    Reply # 6053935 on 5879723
    @Scott

    Life-cycle selection

    We could have two categories of factors: context forces (complexity, incertitude) and process improvement decisions (e.g., evolution to continuous delivery). If I need to enumerate the principal context forces that could influence the life-cycle selection I will pick:

    • Incertitude and complexity related to the requirements (new product, or significant new business)
    • Incertitude and complexity related to the solution. Examples: using new technology, creating new kind of components and design mechanisms, addressing much stronger performance requirements, or concurrency
    Depending on these mentioned risks, we can change our life-cycle options. Examples: 
    • Switch from continuous delivery to a life-cycle that had inception and proven architecture milestone
    • Switch from Agile Basic to Exploratory Lean Startup
    We can have an idea about life-cycle before Inception, but when we gather some more info during the envisioning, we could improve our preliminary choise. An output of the Inception should also be an updated decision related to the life-cycle (skeleton for our plan).
  • 08 Apr 2018 4:20 PM
    Reply # 6053122 on 5879723
    Scott Ambler (Administrator)

    @Valentin:

    • Good point about enhancing initial scoping efforts.  Similarly, it also enhances planning.
    • Not so sure about picking a lifecycle though.
    • In your points about spikes, it got us thinking about how our Explore XX Architecture decision points are really Model XX Architecture decision points, and that we're missing an Explore Architecture decision point that has options such as Discuss, Spike, Model, and Mob Programming.
    • Not sure about business use cases to explore the architecture.  Certainly an option to explore usage requirements.  Can you give me an example of capturing architecture/design considerations using business use cases?
    • For cross-cutting concerns, I've never seen anyone specify this except in the cases of capturing NFRs (address by the Explore Initial Scope goal) or as part of a detailed architecture specification (which I've now fleshed out the description for).

    @Jerry: Good point.

    @Edson: This goal is within the scope of Inception, which would be an extension of a "Design sprint" I suppose.


    All: We hope to get an updated excerpt published in the next day or so.  As you can see we have a fair number of great ideas to act on!   

  • 31 Mar 2018 6:26 PM
    Reply # 6009590 on 5879723

    Hi folks, Identify Initial Architecture Strategy-> Apply Modeling Strategy(ies)

    I suggest applying "Design Sprint" as an approach to model the initial solution and User Interface Needs as well.

    Thanks


  • 16 Mar 2018 7:48 AM
    Reply # 5981916 on 5879723

    In investigating legacy assets - we have found that establishing whether a legacy asset has API's or not helps with forming a strategy on architectural solutions. Sometimes having a roadmap for legacy assets to expose their data via API as an enabler to product delivery is a strong consideration when determining a MVP, for example, would not probably integrate with a legacy asset on a first release of a mobile solution but would ensure that that a roadmap was put in place to ensure that the legacy asset was reviewed or opened up such that at a future point in time such integration was possible without creating unnecessary bottlenecks and key dependencies.

  • 04 Mar 2018 7:08 AM
    Reply # 5888114 on 5879723

    Identify Initial Architecture Strategy – Reasons: complement Initial Scope

    Another significant reason to identify Initial Architecture early is to complement identifying Initial Scope earlier: these aspects could never be investigated separately and will be more iterations. Investigation solutions (and consequences) could trigger, for example, scope clarifications and negotiation.   

     

    Identify Initial Architecture Strategy – Reasons: life-cycle approach  

    Incertitude related to solution (and scope – I forgot to mention for that section) and possible solution delivery approach are the main decision points and factors to select a life-cycle approach

    • Size of Inception
    • If we need Exploratory Lean Start-up life-cycle
    • I propose to mention this aspect
      • In the list of reasons for using Initial Architecture Strategy
      • In Identify solution delivery strategy

     

    Identify Initial Architecture Strategy – explore by modeling & spiking

    In the course diagrams for activities needed during the inception for both Architecture and Design, we could find Envisioning, Look Ahead Modeling but also Spikes. Every time when we need to invest more in modeling we should check if prototyping/spikes are also needed. Should be a normal approach that we do not need prototyping only for UI, but also for other solutions aspects. When we have high incertitude for some solutions aspects spikes could be one of the best options.     

    Here are some factors where spikes could be mentioned

    • Identify a Delivery Strategy – Build from the scratch (see below)
    • Identify a Delivery Strategy – Use/Extend a Commercial Package/Open sources; commercial or open source packages cannot be used directly without investigations. We can have big surprises when we will try to use them for our features. Examples: cannot be extended enough, defects where we have the key features, memory wastes, etc.  If we do not have experience on using that external software, it is much better to not (!) decide without spikes.    
    • Explore Technology Architecture – prototyping and spikes are a good option beyond various modeling options. As Walker Royce recommend: integration tests first.

    Even some of the spikes could be realized during the Construction, and especially for Proven Architecture Milestone, we still need Spikes as an option during Inception. From my experience, the best engineers are using spikes early earlier and more often.  

     
     Identify Initial Architecture Strategy – Build from the scratch (crucial decision point)

     It is very likely to be a high incertitude case – so we can need Spikes. More: here it is a very important decision point to use one of the ordinary Agile/Lean life cycles or Lean Explore Startup Life-Cycle.


    Identify Initial Architecture Strategy - Explore Business Architecture: business use cases

    Business use cases are a good option vs. classic BPM and have a much more reduced “impedance” difference versus solution modeling.


    Identify Initial Architecture Strategyà Choose the Level of Detail: "vertical" architecture & cross-cutting aspects  

    The list of options it is mainly related to “interfaces”, that will drive understanding for sub-systems components and inter-system decoupling and collaboration. A missing aspect is the one related to cross-cutting concerns. It is like we have most of “horizontal” architectural views, but we do not have enough about “vertical” views. A major decision related to architecture is how will be built a component and sometimes is far more difficult than deciding which will be the components (that could be domain-driven). Too often inexperienced teams and developers consider that this aspect it is a detail and not architectural. In my experience 80% of the architectural effort (concept and proving) it is related to the internal architecture of the component (or component types).    

    So, level of details should have at least these aspects:

    • componentization (sub-systems, components, inter-system interfacing)
    • (“vertical”) internal architecture of the components   
    • cross-cutting concerns

    Note: for internal architecture of the components we could also use interfaces, but that is just an intention that needs to be proved. The internal architecture of the component it is a decision with long-term consequences – so it is never trivial.      

    Many Agile knowledge sources about architecture are referring mostly this internal architecture as Jim Coplien Lean Architecture, Uncle Bob Clean Architecture or Universal Design Pattern by Koni Buhrer from Rational.

     

  • 03 Mar 2018 10:17 AM
    Reply # 5887426 on 5879723
    Scott Ambler (Administrator)

    I have just published an update to the excerpt where I've added a decision point to Investigate Legacy Assets.

    This is something long in coming, IMO.

  • 28 Feb 2018 7:28 PM
    Reply # 5882924 on 5879723
    Scott Ambler (Administrator)

    Klaas, interesting point.  I will think about that a bit.  Perhaps the issue is that there is a missing decision point around exploring the existing architecture.  Basically do some archeological exploration in your case.

<< First  < Prev   1   2   Next >  Last >> 

© 2013-2019 Project Management Institute, Inc.

14 Campus Boulevard

Newtown Square, PA 19073-3299 USA

Powered by Wild Apricot Membership Software