Topic
  • 6 replies
  • Latest Post - ‏2012-12-07T23:13:36Z by SteveDiCamillo
HazelWoodcock
HazelWoodcock
15 Posts

Pinned topic Virtual Roundtable - Agile Systems Engineering - Architecture and Modelling breakout [Event closed]

‏2012-11-29T15:57:16Z |
**Even though this event is over, you are welcome to browse this discussion**
 
 Architecture and Modelling

This thread is discussing the place of architecture and modelling in agile systems engineering.

Some key points raised so far include
- Modelling can help early in a project to help in the design activity.
- Model driven development is increasingly being used
- When we have an outline architecture we can start to make progress
- Good architecture and interface definitions reduce the complexity of the parts and so agile practices are easier to apply
Updated on 2013-01-07T22:50:17Z at 2013-01-07T22:50:17Z by sjpeich
  • WalkerRoyce
    WalkerRoyce
    14 Posts

    Re: Virtual Roundtable - Agile Systems Engineering - Architecture and Modelling breakout

    ‏2012-11-29T16:37:09Z  
    The trends in changing executable software baselines and particularly the cost-of-change trends are the true measure of the agility. Agility means changing easily so we need to quantify change trends. Both architectural integrity and process effectiveness will drive the cost-of-change. Therefore, agility is NOT just a process attribute, it is equally, if not more, an attribute of good design.
     
    In the past, it has always struck me that most of the "value" of modeling was attributed to better representation of the architecture, namely more accurate, more shareable, and more machine processable.In this sense, modeling was seen to be much more effective documentation, more than anything else.
     
    Far too little emphasis has been placed on the value of modeling for: reducing the cycle time from concept to executable. In several of my past experiences (most notably TRW and Ericsson), the primary value of modeling and its most discriminating contribution to agility was that it reduced the cost-of-change and cycle time in architectural prototyping, early refactoring, later iteration and maintenance. When change was easier, more experimentation got done and architectural quality improved dramatically, thereby increasing overall project agility and reducing late scrap and rework.
     
     
  • JimDensmore
    JimDensmore
    17 Posts

    Re: Virtual Roundtable - Agile Systems Engineering - Architecture and Modelling breakout

    ‏2012-11-29T19:37:14Z  
    The trends in changing executable software baselines and particularly the cost-of-change trends are the true measure of the agility. Agility means changing easily so we need to quantify change trends. Both architectural integrity and process effectiveness will drive the cost-of-change. Therefore, agility is NOT just a process attribute, it is equally, if not more, an attribute of good design.
     
    In the past, it has always struck me that most of the "value" of modeling was attributed to better representation of the architecture, namely more accurate, more shareable, and more machine processable.In this sense, modeling was seen to be much more effective documentation, more than anything else.
     
    Far too little emphasis has been placed on the value of modeling for: reducing the cycle time from concept to executable. In several of my past experiences (most notably TRW and Ericsson), the primary value of modeling and its most discriminating contribution to agility was that it reduced the cost-of-change and cycle time in architectural prototyping, early refactoring, later iteration and maintenance. When change was easier, more experimentation got done and architectural quality improved dramatically, thereby increasing overall project agility and reducing late scrap and rework.
     
     
    Exactly.  And I always wondered about the application of this idea to systems until I got a great example from Mike, Elko's Fishing Fiend.  Certainly this applies to the software within systems.  Mike's notion of Model Driven CDRLs (which is just one example) made it clear to me that the application to systems is larger.  More fundamentally, I've found that modeling increases the communications bandwidth.  This is one aspect of modeling that reduces the cycle time from concept to executable.  (Another, more obvious, is code generation, but that doesn't always apply in SE contexts.)  When you put the powerpoint slide in front of me, I have a significant chance of misinterpreting it unless I hear from a briefer who understands it and/or authored it.  What I say about this is "Powerpoint presentations require a briefer."
     
    It's true that UML/SysML (or whatever your semantically rich diagram language of the moment is) can still require a briefer.  Nonetheless, my experience is that I'm much less likely to misinterpret a SysML diagram than a powerpoint diagram.  This leads to discussions that center much less around what the diagram says and much more about decisions we may make as a collaborative team given the information on the diagram.  Architects who use rich visual languages find themselves in low bandwidth meetings far less often.  (Low bandwidth meeting: loosely, I define this as people having to re-explain themselves).  Instead, that information is conveyed with sufficient precision in the visual model, and so the discussion centers around what is next
  • BrianNolan
    BrianNolan
    9 Posts

    Re: Virtual Roundtable - Agile Systems Engineering - Architecture and Modelling breakout

    ‏2012-11-29T21:45:49Z  
    Exactly.  And I always wondered about the application of this idea to systems until I got a great example from Mike, Elko's Fishing Fiend.  Certainly this applies to the software within systems.  Mike's notion of Model Driven CDRLs (which is just one example) made it clear to me that the application to systems is larger.  More fundamentally, I've found that modeling increases the communications bandwidth.  This is one aspect of modeling that reduces the cycle time from concept to executable.  (Another, more obvious, is code generation, but that doesn't always apply in SE contexts.)  When you put the powerpoint slide in front of me, I have a significant chance of misinterpreting it unless I hear from a briefer who understands it and/or authored it.  What I say about this is "Powerpoint presentations require a briefer."
     
    It's true that UML/SysML (or whatever your semantically rich diagram language of the moment is) can still require a briefer.  Nonetheless, my experience is that I'm much less likely to misinterpret a SysML diagram than a powerpoint diagram.  This leads to discussions that center much less around what the diagram says and much more about decisions we may make as a collaborative team given the information on the diagram.  Architects who use rich visual languages find themselves in low bandwidth meetings far less often.  (Low bandwidth meeting: loosely, I define this as people having to re-explain themselves).  Instead, that information is conveyed with sufficient precision in the visual model, and so the discussion centers around what is next
     This is a very good point.  We have at least one example where modeling has been cited as a major factor in improving communication across natural language differences--precisely because of the precision inherent in the modeling language.
     
    Walker's point is also a good one--models can reduce the cycle time from concept to executable.  There is an initial learning curve/investment that has to be made in modeling, but it is more than made up downstream.
  • timtom27
    timtom27
    6 Posts

    Re: Virtual Roundtable - Agile Systems Engineering - Architecture and Modelling breakout

    ‏2012-11-30T02:57:45Z  
     This is a very good point.  We have at least one example where modeling has been cited as a major factor in improving communication across natural language differences--precisely because of the precision inherent in the modeling language.
     
    Walker's point is also a good one--models can reduce the cycle time from concept to executable.  There is an initial learning curve/investment that has to be made in modeling, but it is more than made up downstream.
     I'll agree, but I think it's more than that.  Any reasonable project will have an architecture, and the people will all think they know what that is.  The problem is that if you ask representatives from different functional groups, you'll get pretty different things.  I ran into that doing a review of a project at a company in Texas (will be nameless).  I asked quite a few to show me the architecture, and every one went to a white board and drew something pretty different.  They all had something in their head, and all had something different. 
    Here modeling would have, at the least, given this project a coherent architecture, with identified interfaces, for everyone to work against.  In this case they all really thought that the only way to do this project was by spending 24/7 in the lab with the HW, testing it and fixing bugs that they found.
  • Graham Bleakley
    Graham Bleakley
    8 Posts

    Re: Virtual Roundtable - Agile Systems Engineering - Architecture and Modelling breakout

    ‏2012-11-30T14:32:10Z  
     This is a very good point.  We have at least one example where modeling has been cited as a major factor in improving communication across natural language differences--precisely because of the precision inherent in the modeling language.
     
    Walker's point is also a good one--models can reduce the cycle time from concept to executable.  There is an initial learning curve/investment that has to be made in modeling, but it is more than made up downstream.
     I think communication is one of the key benefit that modelling brings to teams, everywhere that i have success with modelling it is because it has helped break down the silos of communication and created a stake in the ground that people can identify with and discuss.
    The model ends capturing a unified picture across the teams of what the architecture should look like.
  • SteveDiCamillo
    SteveDiCamillo
    15 Posts

    Re: Virtual Roundtable - Agile Systems Engineering - Architecture and Modelling breakout

    ‏2012-12-07T23:13:36Z  
    The trends in changing executable software baselines and particularly the cost-of-change trends are the true measure of the agility. Agility means changing easily so we need to quantify change trends. Both architectural integrity and process effectiveness will drive the cost-of-change. Therefore, agility is NOT just a process attribute, it is equally, if not more, an attribute of good design.
     
    In the past, it has always struck me that most of the "value" of modeling was attributed to better representation of the architecture, namely more accurate, more shareable, and more machine processable.In this sense, modeling was seen to be much more effective documentation, more than anything else.
     
    Far too little emphasis has been placed on the value of modeling for: reducing the cycle time from concept to executable. In several of my past experiences (most notably TRW and Ericsson), the primary value of modeling and its most discriminating contribution to agility was that it reduced the cost-of-change and cycle time in architectural prototyping, early refactoring, later iteration and maintenance. When change was easier, more experimentation got done and architectural quality improved dramatically, thereby increasing overall project agility and reducing late scrap and rework.
     
     
    One other benefit or modeling is the ability to visualize the data captured in the model in different ways.  This can be helpful in many ways including making it clearer when an architecture that has been enhanced, extended, modified, is really in need of an overhaul.