Tag: Traceability

The TOGAF Architecture Development Method (ADM) is designed to be sufficiently generic to cover all types of IT programmes. This generalism means that the ADM method can support both organisation and governmental identity management projects. This blog post, as part of a series on identity management in TOGAF, shall cover the best fit of the ADM to a IdM project and will try to answer the following questions:

• What is the best way to realise Identity Management (capability & project) within TOGAF’s ADM?
• Is TOGAF a suitable Enterprise Architecture model for something as generic and security conscious as identity management?

What is the best way to realise IdM in ADM? The ADM may be generic but it depends upon co-operation with more specific industry verticals (e.g. TeleManagement Forum (TMF) in telecoms) for a more detailed realisation of a technology architecture. Identity Management is as equally inclusive as TOGAF and hence equally applicable across all industry verticals. TOGAF defines four architecture domains (BDAT): Business, Data, Application, and Technology. And the TOGAF Architecture Development Method describes a process for “deriving an organisation-specific enterprise architecture that addresses business requirements”. As such the ADM requires manipulation to fit your organisation and any specific programmes. In an earlier post in this series (IdM Stakeholders, View and Concerns) I produced a set of building blocks necessary for producing a successful identity management system. For traceability I have mapped these building blocks to the four BDAT architecture domains and to the various phases in the ADM. As part of this mapping I have described which building blocks need for an identity management system to be delivered early.

Building Blocks to be delivered earlier that normal within the TOGAF ADM:

1. Phase B: Business Architecture & Business Architecture Requirements
   • As identity management projects are regularly treated as an enabler it can be a challenge to produce a business case for identity management 
2. Phase C: Information Systems Architecture & Application Architecture: Vendor selection & Component list
   • It is crucially important when working with a technology that may have multiple components to be able to explain each component in terms of its business capabilities.
   • Depending on the software vendor the component names and areas of responsibility will change. For example Oracle & ForgeRock’s definition of Access Management differs.
   • The business case should have already have been completed at this stage but it is important to split out responsibility to each component.
   • The test cases can be promoted at this stage so that both component independent and project overall tests are defined early.
3. Phase D: Technology Architecture & Technology Architecture: Physical arch & deployment model
   • It is critical to promote the necessary environments for a IdM implementation. These are required for testing and patching and for integrating each individual system to which access will be granted.
   • In a federated architecture working with 3rd parties then for each third party a set of test & contract agreement environments will be needed
   • If the architecture is a partial migration then environments may need to be consolidated
   • As the IdM system is a security component it is recommended to introduce good deployment policies at this stage, for example separation of package naming and deployment.
4. Phase F: Information Systems Architecture & Technology Architecture: Security Policies
   • Security risks must have been identified and the responsibility for the identity management system must be agreed early
   • If the solution is a migration project then the legacy security policy from implementation must be compared with the organisation’s policies and the ambition for secured systems

Conclusion: Is TOGAF a suitable Enterprise Architecture model for something as generic and security conscious as identity management At an organisational level an identity management programme is normally initiated to provide a business enablement capability (e.g. SSO or Federation), a legal requirement (e.g. Healthcare) and / or a security capability (e.g. reduced DDoS exposure). At a national / government level an identity management projects vary in scope and identity ownership architecture. Austria’s Zentrales Melderegister (ZMR) or Denmark’s Det Centrale Personregister are examples of identity owning identity management projects working to enable access to eGovernment services. The UK Cabinet Office’s Identity Assurance programme has the same goals but externalises the identity lifecycle to trusted identity providers. Furthermore some programmes such as the UK land registry are not immediately concerned with individual identity but have a strong identity management capability encapsulated within a larger data structure. For both organisational & governmental IdM deployments the TOGAF ADM model can be applied. The TOGAF ADM model is designed to provide an organisational enterprise architecture capability. However TOGAF ADM can be applied to just IdM because Identity Management is a sufficiently complex area and the number trusted identity providers increases. The ADM is suitable for an Identity Management programme but overall enterprise architecture should be applied to all organisational data & security capabilities.