Last time I blogged about Togaf I said “TOGAF gives you some generic artefacts. But it is up to you to gather and decide which artefacts you need. How do you decide "what you need?" How do you know that "what you need" is "what it takes?”
Let’s focus on one single artefact: requirements.
Some of Togaf prescribed requirements are inputs or outputs to the following phases:
- Preliminary Phase: Stakeholder’s requirements
- Requirements Management: Requirements-related inputs/outputs from each Togaf ADM phase
- Phase Architecture Vision: Business requirements, Stakeholder’s requirements
- Business Architecture: Technical requirements, Business requirements
- Information Systems Architectures – Data Architecture: Architecture Requirements, Data interoperability requirements, Technical requirements, Business requirements, Application requirements
- Information Systems Architectures – Application Architecture: Application interoperability requirements, Technical requirements, Business requirements, Updated data requirements
- Technology Architecture: Technical requirements
- Opportunities & Solutions: Draft Architecture requirements, Interoperability and co-existence requirements
- Migration Planning: Finalized Architecture requirements specification
- Implementation Governance: Recommendations on service delivery requirements
From this large set of requirements, a subset will be used as input by solution architectures. The question that I want to pose is “how do we ensure that all artefacts created throughout the lifecycle of a software development project are verifiable against these requirements?” or more specifically “how do we know that the solution architectures we create actually meet the requirements that they are based upon?”.
Savara is your answer. Using Savara it is is possible to ensure that the delivered system conforms to the original set of requirements.
Integrating Togaf ADM and Savara puts you in the position of ensuring that the delivered systems conform to the original set of requirements.
The underpinings of this can be found in Steve’s blog
In my next blog I want to revist this and align it more explicitly to TOGAF.
Great blog. I look forward to a better and fuller understanding of how Savara and TA works with TOGAF. For me it has always been a missing link.
ReplyDeleteHi all,
ReplyDeleteI think that question you ask is great. But I think Savara is only partial answer, isn't it? As I understand Savara it handles procedural requirements only. I think you undervalue data domain model.
Business process is not everything - there are lot of requirements, which are easier to define in other ways (although they could be defined in procedural way probably). E.g:
- "That item must be charged without VAT!"
- "This kind of data can be seen by managers only!"
- "These VIP customers shall not be stored in CRM system!"
- "IVR shall be available 24x7!"
Using Savara to "ensure that the delivered system conforms to the original PROCEDURAL SUBset of requirements" is good enough. But I like your approach, which really moves IT forward...