Saturday, July 20

Contextual Understanding of SABSA for Non-SABSA Architects

Muhammad Amir Jamil

Security Risk Management Practice Lead and Head of CoE for Architecture for the Middle East and Africa at DXC Technology.

Being an Enterprise Architect by passion and Enterprise Security Architecture by role, I like exploring the enterprise architecture domains from different angles and perspectives and then refine my conclusions whenever I find the time and opportunity. Resultantly, I can say that it’s fruitful to learn and blend the best elements of all the EA (Enterprise Architecture) frameworks and methodologies together for delivering the assignments. This is how an architect should evolve and add more value. Comparing different methodologies and their key areas concludes that although each methodology uses different terminologies, level of depth and the way organizations is looking at them; but the core objectives and concepts will always be similar or closer to each other.

This narrative is an experience gained from the complex engagements and deliveries (including but not limited to) from Smart City, Large Scale Digital Platforms (scaled over 40 countries, 9 million users, etc.) to the strategies and roadmaps for national critical infrastructures.

In this era, organizations are transforming to digital platforms and using data, automation and augmented intelligence as tools to grow their business. Consulting companies at the same time are helping the market to realize its goal. Realizing a goal of securing an opportunity needs a systematic and proven approach that’s called an Enterprise Architecture. It provides you a methodology to have a well-architected strategy, design and implementation guidance that is business-driven and fully aligned with management goals.

SABSA for Non-SABSA Architects

SABSA (Sherwood Applied Business Security Architecture) is a very known security architecture framework for developing enterprise security architecture. Few of its components are truly worthy particularly its methodology of driving business attribute profiles. This small writeup is a try to bridge the gap between ZACHMAN based SABSA and the methodology commonly used in the market by non-EA (Enterprise Architect) teams.

Architects and design teams (non-SABSA) are very familiar with the following terminologies:

SABSA, on the other hand, has the following phases and activities to be performed at each stage:

  • Strategy and Planning
    • Contextual Architecture: In SABSA context, this can be compared to the stage when a person goes to an architect after buying a piece of land and share all the needs and preferences with the architect. The architect discusses and documents all the requirements.
    • Conceptual Architecture: Once the contextual architecture is developed, the team moves into more visual context and puts together the diagrams that explains the conceptual architecture. The conceptual architecture has a high-level look and feel only from an understanding point of view but needs more refinements.
  • Design
    • Logical Architecture: While the conceptual architecture is more for the architect to understand, the logical architecture goes one step ahead to map the requirements. In this phase, the architect engages different teams to add more look and feel to the design. At this stage, the brand/product may not be identified but at least the requirement is clear. For example, 4 Firewalls, 3 IPS would be required without worrying much about the specifications and vendor. 
    • Physical Architecture: Once the logical architecture is finalized, we have a list of items that are required to complete the solution. The architect then extracts the details and take the person to store where they finalize the brands and select the type of items going to be installed.
    • Component Architecture: At the component architecture level, we have the list of all the items, specifications, brands, quantity along with instructions and design of where each item would be installed.
  • Implementation
  • Manage & Measure

The following diagram explains of what a SABSA architecture would look like to a Non-SABSA architect.

Term architecture at the second level is an “architect’s view” and is part of the strategy and planning phase (first phase) of SABSA.

 

Conclusion:

There are a few goods and common architecture frameworks and methodologies (like TOGAF, ZACHMAN/SABSA, etc.) in the market and exploring them up to a certain level is worthy. It will make your life easier being part of “architecture and design squad” while dealing with business management, enterprise architects and especially with internal ICT or external (clients, consultants, etc.) parties by quickly understanding their language and aligning it with yours.

Share