TOGAF vs. SABSA - Put them together
The idea of TOGAF vs. SABSA is absurd. The two architecture frameworks work together smoothly. They work together by design. Your security architecture is part of your enterprise architecture. SABSA addresses developing part of the enterprise architecture.
Let's start with TOGAF. TOGAF is larger than SABSA because it covers all architecture domains. TOGAF is an end-to-end enterprise architecture framework that provides essential scaffolding and is short on detailed how-to instruction. Possible enterprise architecture use cases prevent TOGAF from detailed how-to.
SABSA covers one architecture domain. It is a specific method supporting enterprise security architecture. It provides a series of integrated models, methods, and processes. We can independently use these or as a holistic technique. SABSA is a domain architecture framework.
Instead of SABSA vs. TOGAF, think of TOGAF plus SABSA. Think enterprise architecture with world-class risk and security.
Thinking enterprise architecture plus world-class security architecture led the SABSA Institute and The Open Group to collaborate. First with the TOGAF and SABSA Integration Paper, then the TOGAF Series Guide on Integrating Risk and Security into TOGAF.
SABSA plus TOGAF allows enhancing your enterprise architecture with the best security architecture approach.
What is the difference between TOGAF and SABSA?
TOGAF vs. SABSA - Enterprise vs. Security Architecture
TOGAF 9 is an enterprise architecture framework. TOGAF is modular in design. They cover the essential framework in TOGAF Fundamentals. They provide guidance on how to use the TOGAF Standard in the TOGAF Series Guides.
TOGAF 9.2 does not provide SABSA-independent guidance on security architecture. Instead, the best-practice integration of security architecture and enterprise architecture is in the TOGAF Series Guide Integrating Risk & Security with TOGAF Guide. TOGAF considers security architecture a cross-cutting domain. Every architecture domain has risk and security aspects.
SABSA vs. TOGAF - How to Guidance
SABSA is a specialized security architecture method. It does not have to account for the multitude of enterprise architecture use cases. Unlike TOGAF, SABSA has the freedom to tell you exactly how to do one job. Throughout SABSA are specific techniques, approaches, and templates that are universal best-practice.
TOGAF vs. SABSA - Level of Detail
SABSA, like most detailed methods, starts with many decisions about the enterprise made. SABSA's Contextual Layer asks what is the Enterprise vision and goals are. What the enterprise wants to achieve and what it cares most about.
In TOGAF, Architecture to Support Strategy exists to develop the answers to these questions. SABSA requires many decisions have been made that are within scope of architecture to support strategy. The lowest level normally covered in enterprise architecture, architecture to support solution delivery, remains architecture. SABSA provides an entire layer to manage security controls.
SABSA mapped to the TOGAF Framework
The TOGAF Framework provides the universal essential scaffolding for the three central problems facing enterprise architects:
- how to develop enterprise architecture (TOGAF ADM),
- how to document an enterprise architecture (TOGAF Content Framework),
- how to develop an enterprise architecture team (Develop an EA Team)
How to develop enterprise architecture - SABSA provides specialized guidance on how to develop an enterprise security architecture. The TOGAF Series Guide Integrating Risk and Security into the TOGAF Standard provides guidance on extending TOGAF to include best-practice enterprise security architecture. This integration assumes the overall approach is based on the TOGAF ADM.
How to document an enterprise architecture - SABSA provides set of standard work products. However SABSA Model is silent on how the end-to-end security architecture is documented or modelled. The basis of the SABSA Matrix is Zachman Framework, which also identifies the questions that must be answered for different stakeholders and is silent on how to document the architecture. The TOGAF Series Guide Integrating Risk and Security into the TOGAF Standard provides guidance on where different work products are produced. Configuring the TOGAF Content Framework with SABSA work products improves your enterprise architecture.
How to develop an enterprise architecture team - SABSA provides no guidance on how to establish or develop an architecture team.
TOGAF vs. SABSA - Leverage SABSA in Enterprise Architecture
SABSA vs. TOGAF - Using SABSA Business Attributes Profile
SABSA Business Attributes Profile is at the heart of the SABSA method. This ‘requirements engineering’ technique makes SABSA truly unique and provides the linkage between business requirements and technology / process design. If you take nothing else away, Business Attributes Profiling is the most powerful tool for creating translated, standardized and ‘normalized’ set of business requirements.
Like other excellent reference tools, the taxonomy provides a checklist of possibility. Instead of brainstorming from a blank piece of paper, start with a standard list. Spend your time on analysis. Decide whether to include an attribute. Once included, identify the metrics for performance targets.
SABSA vs. TOGAF - Using the SABSA Risk Model
SABSA explicitly ties threat and opportunity together in the SABSA Risk Model. Rather than limiting consideration of risk to minimizing potential threat, SABSA balances risk thinking. Everything we do creates opportunities and threats.
Embed SABSA's ‘risk thinking’ within an enterprise architecture team to be instinctive about the enterprise culture. Achieve balance between realizing opportunities for gains while minimizing losses. Apply an architecturally structured and comprehensive approach
SABSA vs. TOGAF - Using the SABSA Domain Model
Risk management is about balancing potential gains against potential loss. The SABSA Domain Model integrates and aligns risk silos. Test who realizes the benefit with who bears the cost. You holistically embed risk management into all levels and perspectives of enterprise.
Failing to ensure the cost and benefit decisions are made by an appropriate decision maker destroys risk management. Someone who only bears cost, always errs on the side of avoiding potential loss. Cost free benefit owners create massive potential downside for others.
