You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
"Stakeholders". (disclosure, as a hobbyist and GSoC student at JabRef, I never build such production grade applications except JabRef, IDK about business stuff). IMHO, isn't "decision drivers" a more general category?
It talks about who made the decision. But I wonder, is it necessary? I think ADR should be discussed in a group and definitely not taken by a single person. This means that for every ADR there would be a single author "developers", and this makes the whole point redundant. Also, someone can look at the commit author, if a Git repository is used for docs and/or application code.
It also talks a lot about consequences of the decision. I think in current versions of MADR, there is no such thing, and it's typically encoded in "Good, Bad, Neutral". This is an interesting topic, as: Should MADR (or ADR) separate pros/cons of an option + effort to implement it? Pros and cons are stable things tightly related to the option itself, however "consequences" are tightly related to the concrete project developers work on.
Point 1 with stackeholders makes think about "Where do decision drivers come from?" - I think this is a more general question.
Overall, I think IEEE 42010 is too broad and concerning the whole architecture, while MADR only about decisions and is much more detailed. Though, there are probably some components that are not included in MADR, but talked about in IEEE 42010
See page 18 and 19 of http://www.iso-architecture.org/42010/templates/42010-ad-template.pdf
The text was updated successfully, but these errors were encountered: