Enterprise Architecture
Enterprise Architectural Methodologies
A Brief History of Enterprise Architecture
Zachman Framework
Business Attributes
Features & Advantages
SABSA Lifecycle
SABSA Development Process
SMP Maturity Levels
2. About Me
• Love to design, build and protect large scale systems
• IAM, Cryptography, Consulting, Program Management and Governance
• Large MNC to startup across the globe
• VP Engineering of Infoworks (a silicon valley Big Data Startup)
• Prior to this, I had worked with British Telecom Research, BT Consulting, iViZ and
MetricStream
• Patent – USPTO 9,348,901
• MS (Telecom Engineering), University College London
3. Enterprise Architecture
•A field born about 30 years ago
•Initially targeted to address two
problems
•System complexity
•Inadequate business alignment
5. A Brief History of Enterprise Architecture
Zachman’s first article
1987
TAFIM released
1994
Clinger-Cohen bill passed
1996 1998
TAFIM retired
FEAF 1.2 released
1999 2002
FEA replaces FEAF
TOGAF EE 8.0 released
2003 2003
FEA mostly complete
2011
TOGAF 9.1
6. Zachman Framework
•The Zachman "Framework" is actually a taxonomy for
organizing architectural artifacts
•Two dimensions
• Players in the game
• Architectural Artifacts
•Players in the game: Actors
•Architectural Artifacts: the What, How, Where, When,
Who and Why
8. 4 Ways Zachman helps in Architecture Dev
•Every stakeholder's perspective is
captured
•Completeness of every artifact
•Provide strong traceability
•Improve Tech-Business Alignment
9. What Zachman does not provide
•Step-by-step process to create new
architecture
•Validating an architecture
•Deciding future architecture
•It is not a Methodology
10. Enterprise Information Security Architecture
•Is the practice of applying comprehensive and rigorous
methods for describing security of current and future
systems
• Ref: Wikipedia
•Applied to people, process and technologies
•Goals
• Provide structure
• Enable business-to-security alignment
• Enforce Top down approach
• Strong traceability
• Abstract complex concepts
• Establish common lingua of information security
11. Well Known Cyber Security Frameworks
•NIST CSF
•Sherwood Applied Business Security
Architecture (SABSA)
•We will discuss SABSA in details
12. What is SABSA
•Methodology for Building Security Architecture:
•Business-driven
•Risk and opportunity focused
•Includes security service management
• Comprised of a number of integrated frameworks,
models, methods and processes
13. SABSA Model
• Comprises of six layers
• Based on Zachman framework/taxonomy
• The Security Service Management Architecture has been
placed vertically across the other five layers
• Each horizontal layer is made of a series of vertical
communication interrogatives
• What (Assets)
• Why (Motivation)
• How (Process and Technology)
• Who (People)
• Where (Location)
• When (Time)
15. Business Driven Architecture
•Never losing site of the organisation’s
goals, objectives, success factors and
targets
•Contextual architecture captures and
presents the full set of relevant
requirements
16. Credible Abstraction is Key
•Meaningful traceability is enabled by
credible abstraction from business context
to business security context
•Traceability therefore starts by delivering
two slightly different sets of
requirements:
•Business Requirement: Business reputation
•Business Driver for Security: What can
security do to protect reputation
17. Business Attributes Profiling
•Conceptual abstraction
of a real business
requirement
•Standardized and re-
usable set of
specifications
•Provides standardized
lingua
18. Attributes Profiling Rules & Features
• Can be tangible or intangible
• Requires a meaningful name and details
• Can be customized specifically for a particular organization
• Requires a measurement approach and metric
• Must be validated (and preferably created) by senior
management & the business stake-holders
• Performance targets are basis for reporting and/or SLAs in the
SABSA Manage & Measure phase
21. Sample of Business Drivers
Driver ID Business Drivers
BD1
Protecting the reputation of the Organization, ensuring
that it is perceived as competent in its sector
BD2
Providing support to the claims made by the
Organization about its competence to carry out its
intended functions
BD3
Protecting the trust that exists in business relationships
and propagating that trust across remote electronic
business communications links and distributed
information systems
BD4
Maintaining the confidence of other key parties in their
relationships with the Organization
22.
23. Implementation - User Attribute
Business
Attribute Business Attribute Definition Measurement Approach
Metric
Type
Accessible
Information to which the user is
entitled to gain access should
be easily found and accessed by
that user.
Search tree depth necessary to find
the information
Soft
Anonymous
For certain specialized types of
service, the anonymity of the
user should be protected.
Rigorous proof of system
functionality
Red team review
Hard
Soft
Consistent
The way in which log-in,
navigation, and target services
are presented to the user
should be consistent across
different times, locations, and
channels of access.
Conformance with design style
guides Red team review
Soft
Protected
The exchanged information
must remain confidential
between exchanging parties
and must remain untampered
Conformance with confidentiality
and integrity policies
Hard
30. Architecture Measurement Categories
• Completeness
• Do we have all of the components?
• Do they form an integrated system?
• Assurance
• Does the system run smoothly?
• Are we assured that it is properly
assembled?
• Is the system fit-for-purpose?
• Compliance
• Do we maintain the system?
• Do we follow the architecture
roadmap
• Do we comply with the rules?
• Performance
• Is the system properly tuned?
• Do the components work together?
• Do we operate the system correctly?
• Justification & significance
• Does the system have business value?
Essentially started in 1987 with the publication of in the IBM Systems Journal of an article titled "A Framework for Information Systems Architecture," by J.A. Zachman where he laid out both the challenge and the vision of enterprise architectures that would guide the field for the next 20 years
U.S. DoD Technical Architecture Framework for Information Management (TAFIM) and was introduced in 1994 which had influenced creation of Clinger-Cohen Act of 1996 which was aimed at improving effectiveness of Govt. IT investments
Federal Enterprise Architecture Framework version 1.1 was released in 1999
FEAF renamed to FEA in 2002
TAFIM was retired in 1998 and the work done was turned over to The Open Group who morphed into what is today knows as TOGAF (The Open Group Architecture Framework)
First: use Zachman Taxonomy to the fact that every architecture artifact must live in one and only one cell
Second: achieve architectural completeness by completing every cell
Third: cells in columns should be related to each other.
Provide structure, coherence and cohesiveness.
Must enable business-to-security alignment.
Defined top-down beginning with business strategy.
Ensure that all models and implementations can be traced back to the business strategy, specific business requirements and key principles.
Provide abstraction so that complicating factors, such as geography and technology religion, can be removed and reinstated at different levels of detail only when required.
Establish a common "language" for information security within the organization
From a security architecture point of view, when compared to other security frameworks such as SABSA, NCF has gaps. Among other things, NCF lacks business alignment, traceability and assurance capabilities. For example, the NCF implementation process relies heavily on executives to inform the business about mission priority, risk appetite and budget. This information is critical to the selection of NCF Profiles for an organization. However, business executives are just now starting to engage in conversations about cybersecurity. This is a marked improvement over years past and NCF deserves credit for acting as a catalyst to start those conversations. Executive involvement is a step in the right direction but we still need to help executives and security professionals articulate their organization's security requirements in a way that yields business alignment and leads to successful implementations. Without a good understanding of the business drivers for security and the strategies that go along with them, it is very difficult for security architects to tailor their NCF Profiles effectively in a way that aligns the security technical solutions with the business risk appetite.
Business Requirements Engineering Framework (also known as Attributes Profiling)
Risk & Opportunity Management Framework
Policy Architecture Framework
Security Services-Oriented Architecture Framework
Governance Framework
Security Domain Framework
Through-life Security Service & Performance Management