Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Comment on compatibility with IEEE 42010 #85

Open
socadk opened this issue Nov 11, 2022 · 1 comment
Open

Comment on compatibility with IEEE 42010 #85

socadk opened this issue Nov 11, 2022 · 1 comment

Comments

@socadk
Copy link
Contributor

socadk commented Nov 11, 2022

See page 18 and 19 of http://www.iso-architecture.org/42010/templates/42010-ad-template.pdf

@InAnYan
Copy link

InAnYan commented Dec 7, 2024

Several things I noticed there:

  1. "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?

  2. 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.

  3. 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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants