Session:Requirements and Design Process--Discussions
From WICSA Conference Wiki
Please use this page to capture ideas, thoughts, reactions, opinions and so on about the content of this session.
Moderator: René Krikhaar
Contents |
Key ideas
(key ideas, how papers relate to each other and support the session theme)
- key idea 1
Discussion questions
- question 1
Discussions
(pre-session, session, post-session, post-mortem)
Towards a Unified Architecting Method (UAM)
Do we need an Unified Architecting Method?
Is it Feasible?
If yes who should design it?
What will be it benefits?
Will real architects ever use it?
Should it be domain specific?
Should it be artifact centered or activity centered?
Should it be small or BIG?
List a number of requirements.
Which Ingredients should it contain?
Who should determine what goes in and what's left out?
How should one validate it?
What's the role of context?
(Henk Obbink)
Architecture is both an art and a science. The science part is the repeatable engineering practice that can be standardised and followed by practitioners. For instance, if architect is to design for security, there are considerations in performance, maintenance etc. Architecture patterns based on well-tested practices can aid architects. Other methods dealing with the architecture and decision-making processes also help.
Despite similar characteristics of systems, the conditions under which a system is built or enhanced can be quite different. So a decent architecture job relies on the experience of the architect. This is where architecture becomes an art. No method can fully address the behaviour of an architect during requirements elicitation and negotiation. Having said that, identifying the key areas where architects must focus on is a big step because at least there is a check-list where architects can refer to. Some design theories and practice knowledge will support this area nicely. I see an analogy between the practice of architecture and project management, PMBOK spells out 9 areas of concerns for project managers. Perhaps UAM could be along the same line of thoughts?
--Atang 04:52, 8 November 2005 (EST)
How is UAM different from TOGAF? Are we trying to re-invent the wheel?
- Art.akerman 11:19, 9 November 2005 (EST)
The TOGAF work is certainly relevant, but is on the same level as the other methods discussed in our paper. In my talk I indicated that more IT systems knowledge and experience should be fed into this UAM idea. TOGAF might be an appropriate candidate.
(Henk Obbink)
Perhaps other architecture frameworks such as Federal Enterprise Architecture Framework (CIO Council), DoDAF (used to be called C4ISR) and the Zachman Framework might also shed some light on the subject. However, the difficulty might be to find an organisation who is willing to share intimate knowledge of how the AF has changed their practice.
--Atang 22:51, 9 November 2005 (EST)
