… or any Enterprise Architecture framework.
As you may know TOGAF puts Requirements Management in the centre of its ADM method:
As one might expect, since this aspect of enterprise architecture is so prominently placed, it will be given a lot of attention in the TOGAF standard, right? Not so. The number of pages dedicated to this phase in the ADM in the 9.1 version of TOGAF is 8 pages.
| Preliminary | 12 |
| Architecture Vision | 10 |
| Business Architecture | 14 |
| Information Systems Architecture | 16 |
| Technology Architecture | 18 |
| Opportunities and Solutions | 10 |
| Migration Planning | 8 |
| Implementation Governance | 8 |
| Architecture Change Management | 10 |
There are an additional number of pages dedicated to Integration Requirements Management, one aspect of Requirements Management, and there is considerable attention for stakeholder analysis and the motivational model, which to a large extend translates into requirements of course. But many of my students in the TOGAF trainings I give are left with a lack of clarity and tooling to tackle this supposedly important phase.
The problem with requirements management is the meagre metamodel entities associated with it in the TOGAF metamodel:
- Requirement
- Assumption
- Constraint
- Gap
In ArchiMate this has (as yet, keep in mind the ArchiMate metamodel is working hard to get in line with TOGAF) not yet improved much. Remember in the ArchiMate 1.0 standard the word non-functional did not appear at all, so we are getting there.
SABSA Business Attribute Profile
hings are improving however. Some organisations have adopted the SABSA Business Attribute Profile. In fact, the Open Group has adopted SABSA not only for security architecture, but also for requirements management, thus introducing a robust and proven process to develop architectures on solid requirements, aligned with business capabilities.
The 6×6 matrix usually developed in the application of the SABSA framework looks a lot like Zachman:
Within this framework, the Business Attributes Profile plays an important role. It is the basis for requirements gathering.
In general, I have found similar lists of quality attributes useful enough (for example the ISO/IEC 25010:2011 standard, one which I have used extensively since 1997, especially while working on software in the medical sector). But there is also a risk associated: only experience (should I even say wisdom?) will tell you which attributes are important and how to implement them. This should be strongly stakeholder-driven, so an important quality for enterprise architects is to be able to explain these attributes to the relevant stakeholders and take their input to formulate your quality attributes in a SMART way.
After all, you want your architecture to be requirements-driven. Right?
Leave a Reply