This is the governing body for certification in Disciplined Agile.

Align with Enterprise Direction

  • 28 Mar 2018 3:19 PM
    Reply # 6004588 on 5877970
    Scott Ambler (Administrator)

    @Jerry - Yes.  We have an EA process blade at the DAIT/DAE level of the framework.  In DAD there is an architecture owner role who is expected to work closely with the EAs, and may even be an EA.  Then part of this process goal is for the team to align with the architectural direction of the organization.

  • 16 Mar 2018 7:41 AM
    Reply # 5981902 on 5877970

    To help align with the enterprise direction - it is helpful if there is an Enterprise Architecture (EA) function that they set down architectural principles and patterns that can be traced or followed by Product Delivery teams this will help ensure that teams are aligned. We have found that having patterns on wiki has been helpful for teams to align.

  • 05 Mar 2018 6:36 AM
    Reply # 5889497 on 5877970
    Scott Ambler (Administrator)

    @michelle - In the text I've called out API as an access mechanism for applications/systems.

    @Klaas - Good points about templates.  I fleshed out the description in the update to the decision point.  When it comes to components we're trying to squeeze out the concept of small single-purpose components (what we call components) and large-scale domain components.

    @Valentin - Good points about architecture guidelines and templates, I have updated the text.  Good point about domain components, I've fixed both the diagram and the text.

    The v2 update has now been posted and is available for download.

  • 03 Mar 2018 2:45 PM
    Reply # 5887673 on 5877970

    Align with Enterprise Direction à Adopt Common Guidelines: Architecture

     “Architecture” is related to all solutions aspects, where “technology” it is important but is not cover all common guidelines needs.    Architectural decisions about separation of concerns are more important than technology.  In fact, the most important decisions related to software architecture are the ones that make easier changing (!) the technologies. So, my proposal is to put to a more generic description for architecture related guidelines: guidelines related to significant solution decisions, architectural styles, solution adaptiveness … and preferred technologies (consistencies and other reasons).

    In the text we have now “architectural vision”, but only technologies are described as example aspects.

    About Architectural style guidelines: have at least the same importance as coding guidelines.       

     

    Align with Enterprise Direction: Precondition for templates, governance & others

    I cannot select templates before knowing the process approach. I will have other templates for a Waterfall or Unified Process or Agile. One of the “strongholds” of resistance to improvement are the traditional process templates: “Agile” teams with Enterprise waterfall templates for example.

    Idem, we will have a completely different governance in waterfall or Agile. Real case example: we need to build Gant charts for stakeholders that do not want to use our Agile information radiators, and there is no real useful information in that Gants charts.   

    More: even in Agile case, we have diverse types of releases, products, etc.  

    So, I propose to mention also the followings:

    • Align with enterprise directions must be always an adaptive & evolutive, emergent endeavors: adapt them to context & change them continuously to reflect what is (really) common in different delivery contexts
    • That should be mentioned at the beginning of the section and also shortly for each factor

    Some of the Enterprise Direction could be triggered by external context strategical factors, but all the others are rather part of a common “wisdom”, “architecture”, resulted, emergent from a shared experience and knowledge.  Enterprise assets will not exist (or will not be useful) without this sharing process.

     

    Align with Enterprise Direction à Reuse Existing Infrastructure:  Domain Components

    <<Microservices/domain components. An independently deployable set of functionality, with a well-defined interface, that addresses a cohesive business or technical goal.>>

    Imo should be rather <Domain Components (Microservices or others)>. The core of Disciplined Agile is to promote <choice is good> concept. Microservices are only a very particular (trendy!) option of <Domain components> architectural style. I saw too many teams that adopt Microservices without having the real need in their context of all the Ms related decisions. They code and invest too much, just blindly following the examples from Netflix, Amazon, and others. In the same time, similar with Scrum, some companies have an aggressive marketing. Microservices are <Domain components> with a series of choices already made: binary interface, distinct process, etc, etc. For example, Netflix choose to use Microservices because they need to measure and control performance per set of functionalities, so they decide that for their context to allocate a distinct process for a such set.  Also, the decision to have asynchronous communication between services introduce huge extra problems and complexity, solved with significant extra-design effort, prohibitive for other smaller companies.

    So Microservices cannot be a default, most efficient and agile form of reuse!

    Domain Component can be …  a default, most efficient and agile form of reuse! Where is some very particular context cases, an example of implementing Domain Components are the Microservices.

  • 27 Feb 2018 2:45 PM
    Reply # 5880389 on 5877970

    "Adopt Common Templates" is probably something no team can avoid in a larger corporate environment.

    In my current environment we can get away with only a few of the existing templates, but we always have to deliver a "Feature Complete Sheet" after we declare a feature finished. These are the base for the release notes of the final grand product to our service and support department.

    I can imagine in a full Health & Safety (FDA approval) environment, templates are totally mandatory and choosing is not an option. You may want to highlight that.


    I feel that "Components" are receiving too little attention. Many companies have basic frameworks and components that achieve certain goals. Not just for UI, but also for logging, health monitoring, hardware abstraction and such. In my experience, UI components are much harder to re-use than those "single function components". In the end, components (near the bottom) and "micro services" (near the top) are the same thing but built on a different paradigm: components run locally, where microservices run remotely. In both cases, my development effort is limited to glueing and validation.

    Hope this helps!

  • 26 Feb 2018 10:14 PM
    Reply # 5879217 on 5877970
    Deleted user
    Should APIs be added the reuse existing architecture options?


  • 26 Feb 2018 11:21 AM
    Message # 5877970
    Scott Ambler (Administrator)

    Please respond to this with any feedback you may have about the Align with Enterprise Direction process goal.

    Thanks in advance.

© 2013-2020 Project Management Institute, Inc.

14 Campus Boulevard

Newtown Square, PA 19073-3299 USA

Powered by Wild Apricot Membership Software