The document discusses enterprise architecture frameworks and how they can help DreamKart, an ecommerce company facing several IT challenges. It describes the Zachman Framework, which provides a taxonomy for organizing architecture artifacts, and TOGAF, which defines an architecture development method (ADM) process. Using Zachman's taxonomy, DreamKart could classify artifacts, ensure all stakeholder perspectives are considered, and trace business requirements to technical implementations. However, Zachman alone does not provide a process for creating new architectures. TOGAF's ADM process could guide DreamKart in developing enterprise architectures by moving from generic to specific. Using both approaches could help address DreamKart's problems.

1. Enterprise Security Architecture
Arnab Chattopadhayay
Senior Director
MetricStream Inc.

2. Enterprise Architecture
• A field born about 30 years ago
• Initially targeted to address two problems
– System complexity
– Inadequate business alignment
– Resulting into
• More Cost, Less Value

3. Enterprise Architectural Methodologies
• Consortia-developed Frameworks
– ISO 19439
– RM-ODP (ITU-T X.901-904)
– TOGAF
• Defense Industry Framework
– DoDAF
– MODAF
– NAF
• Government Framework
– ESAAF
– FEAF
– NIST Enterprise Architecture Model
• Open Source Frameworks
– TRAK
– SABSA
• Proprietary Frameworks
• Zachman Frameworks
• IAF (Capgemini, 1993)

4. A Brief History of Enterprise Architecture
Zacman’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

5. Enterprise Security Architecture Evolution
Ref: Wikipedia

6. Focus for today’s presentation
• Zachman Framework for Enterprise
Architectures
• TOGAF

7. How are we going to discuss
• Each approach would be described in the context of
the following real-life problems of a fictional enterprise
– IT systems that have become unmanageably complex and
increasingly expensive to maintain
– IT systems that are hindering the organization's ability to
respond to current and future market conditions in a
timely and cost-effective manner
– Mission-critical information that is consistently out-of-date
and/or wrong
– A culture of distrust between the business and technology
sides of the organization
• The question that we would address is:
– How would the enterprise choose from the approaches

8. Enterprise Architecture Approaches Comparison Metric
(1)
• Taxonomy completeness (how well you can use the methodology to
classify the various architectural artifacts)
• Process completeness (how fully the methodology guides you through a
step-by-step process for creating an enterprise architecture)
• Reference-model guidance (how useful the methodology is in helping you
build a relevant set of reference models)
• Practice guidance(how much the methodology helps you assimilate the
mindset of enterprise architecture into your organization and develop a
culture in which it is valued and used)
• Maturity model (how much guidance the methodology gives you in
assessing the effectiveness and maturity of different organizations within
your enterprise in using enterprise architecture)
• Business focus (refers to whether the methodology will focus on using
technology to drive business value, in which business value is specifically
defined as either reduced expenses and/or increased income)

9. Enterprise Architecture Approaches Comparison Metric
(2)
• Governance guidance (how much help the methodology will be in
understanding and creating an effective governance model for enterprise
architecture)
• Partitioning guidance (how well the methodology will guide you into
effective autonomous partitions of the enterprise, which is an important
approach to managing complexity)
• Prescriptive catalogue (how well the methodology guides you in setting
up a catalogue of architectural assets that can be reused in future
activities)
• Vendor neutrality (how likely you are to get locked-in to a specific
consulting organization by adopting this methodology)
• Information availability (amount and quality of free or inexpensive
information about this methodology)
• Time to value (the length of time you will likely be using this methodology
before you start using it to build solutions that deliver high business value)

10. Case Study
• DreamKart is an eCommerce company selling wide
range of products to retail market
• It has the following systems:
– Sales management
– Customer portal
– Inventory management
– Logistics management
– Warehouse management
– Identity and Access Management
– Billing
– Credit check
– A range of integrated third party services

11. Challenges
• DreamKart requires regional specializations. For example, different offers
and product ranges are needed to be supported in different regions
• The logistics companies were acquired and they maintain their own
systems and processes
• There are number of different inventory management systems
• The technical debt is significant and is increasing since changing one
system impacts a number of others and rolling out patch in production
requires to take systems down
• Lines of code is more than one million
• Introduction of new features is time consuming and effect the system
stability
• Due to that, there has been tussle between sales and IT department and
as a result, the two departments are not working together.
• As a result, the IT is building software without good validation from the
user organization

12. Zachman Framework (1)
• Although the name states, it isn’t a ‘Framework’ in true sense
– A framework is defined as a structure for supporting or enclosing
something else, especially a skeletal support used as the basis for
something being constructed; An external work platform; a scaffold; A
fundamental structure, as for a written work; A set of assumptions,
concepts, values, and practices that constitutes a way of viewing reality
[source: American Heritage Dictionary]
• Zachman can be called a Taxonomy
– The classification of organisms in an ordered system that indicates natural
relationships; The science, laws, or principles of classification; systematics;
Division into ordered groups or categories
• The Zachman "Framework" is actually a taxonomy for organizing
architectural artifacts (in other words, design documents,
specifications, and models) that takes into account both who the
artifact targets (for example, business owner and builder) and what
particular issue (for example, data and functionality) is being
addressed
• Zachman used Building industry as an analogy

13. Zachman Framework (2)
• Two dimensions
– Players in the game
– Architectural Artifacts
• Players in the game: Actors
• Architectural Artifacts: the What, How, Where, When, Who
and Why
• The second dimension is independent of the first
– Both the Builder and the Owner need to know the ‘What’
– But, they need to know different ‘What’
• From a Business Owner’s perspective, ‘Data’ means business
entity
– Example: Customer, Product, Demographic Groups, Inventory
• From the developer’s perspective i.e. Builder’s perspective,
‘Data’ means rows and columns organized into table,
mathematical joins to implement relationships

14. Zachman Framework (3)
• Zachman Framework is typically depicted as a 6 x 6 matrix
– Columns: Communication Interrogatives
– Rows: Reification Transformation
– The Framework Classification is represented by 36 cells
– Each cell represents a player’s perspective (e.g. business owner) and a
descriptive focus (e.g. data)
• Moving horizontally changes description of the system from
same player’s perspective
• Moving vertically pin down to single focus but changes players

15. Zachman Framework (4)
Source: zachmaninternational.com

16. How Zachman Taxonomy can help DreamKart (1)
• Three suggestions
• First: use Zachman Taxonomy to the fact that every architecture
artifact must live in one and only one cell
– For an artifact if it is not possible to establish its cell unambiguously, then
there is something wrong in the selection of the artifact
– As DreamKartbegins accumulating artifacts in the development of
Enterprise Architecture, it can use the Zachman grid to clarify the focus of
each of these artifacts.
• Example: artifacts relating to a service-oriented architecture live mostly in the third row
(designer's perspective). They generally will not be of interest to the business owner
• Second: achieve architectural completeness by completing every
cell
– A cell is complete when it contains sufficient artifacts to fully define the
system for one specific player looking at one specific descriptive focus
– When every cell is populated with appropriate artifacts, there is sufficient
amount of detail to fully describe the system from the perspective of
every stakeholders looking at the system from every possible angle
(descriptive focus). So, DreamKart can use the Zachman grid to ensure
that appropriate discussions are occurring between all of the important
stakeholders

17. How Zachman Taxonomy can help DreamKart (2)
• Third: cells in columns should be related to each other.
– Example:take the data column (the first column) of the Zachman grid.
From the business owner’s perspective, data is information about the
business. From the database administrator's perspective, data is rows
and columns in the database
– While the business owner thinks about data quite differently from the
database administrator, there should be some relationship between
these perspectives. Somebody should be able to follow CxO’s business
requirements and show that the database design is, in fact, being
driven by those requirements. If the requirements that are not
traceable down to the database design, we must ask if the business
needs will be met by this architecture. On the other hand, it there are
database-design elements that do not trace back to business
requirements, we might ask if we have included unnecessary design at
the database level

18. How Zachman Taxonomy can help DreamKart -
Summary
• Five ways Zachman Taxonomy can help:
– Ensure that every stakeholder's perspective has been
considered for every descriptive focal point
– Improve the DreamKart Enterprise Architecture artifacts
themselves by sharpening each of their focus points to one
particular concern for one particular audience
– Ensure that all of CxO’s business requirements can be
traced down to some technical implementation
– Convince Business function of the organization that the
technical team isn't planning on building a bunch of
useless functionality
– Convince Technology team that the business folks are
including IT teams in their planning

19. What Zachman Taxonomy does not
provide
• Does not provide step-by-step process to create new
architecture
• Does not provide much help in validating an
architecture
• Does not provide help in deciding future architecture
• Inference: Zachman alone would not be sufficient to
meet DreamKart’s challenges

20. TOGAF
• Developed and owned by The Open Group
• Divides enterprise architecture into four categories:
– Business Architecture: describes the processes the business uses to meet its goals
– Application Architecture: describes how specific applications are designed and how
they interacts with each other
– Data Architecture: describes how enterprise data stores are organized and
accessed
– Technical Architecture: describes the hardware and software infrastructure that
supports applications and their interactions
• Although TOGAF claims itself to be a framework, the most important part
of TOGAF is known as Architecture Development Method (ADM) which is
an architecture development process
– Since ADM is the most visible part of TOGAF, I categorize (and many in the industry
as well) it as architecture process
• TOGAF compliments Zachman
– Zachman tells how to categorize architecture artifacts
– TOGAF gives the process to create them

21. TOGAF Description (1)
• TOGAF views the world of enterprise architecture as a continuum of
architectures, ranging from highly generic to highly specific.
• It calls this continuum the Enterprise Continuum.
• It views the process of creating a specific enterprise architecture as
moving from the generic to the specific.
• TOGAF's ADM provides a process for driving this movement from
the generic to the specific
• TOGAF calls most generic architectures Foundation Architectures.
– These are architectural principles that can, theoretically, be used by
any IT organization in the universe.
• TOGAF calls the next level of specificity Common Systems
Architectures. These are principles that one would expect to see in
many—but, perhaps, not all—types of enterprises
• TOGAF calls the next level of specificity Industry Architectures.
These are principles that are specific across many enterprises that
are part of the same domain

22. TOGAF Description (2)
• TOGAF calls the most specific level the Organizational
Architectures. These are the architectures that are specific to a
given enterprise
• TOGAF defines the various knowledge bases that live in the
Foundation Architecture.
– Technical Reference Model (TRM)
– Standards Information Base (SIB)
• The TRM is a suggested description of a generic IT architecture.
• The SIB is a collection of standards and pseudo-standards that The
Open Group recommends that you consider in building an IT
architecture
• A point of debate
– Many in the industry thinks that both the TRM and the SIB are flawed.
They are biased toward application portability, at the expense of
application interoperability and application autonomy.

23. TOGAF Enterprise Continuum

24. TOGAF ADM Processes
The TOGAF Architecture Development Method (ADM) provides a tested and repeatable process for
developing architectures.
Source: The Open Group

25. How TOGAF can be used to help DreamKart (1)
• DreamKart assigned one experienced TOGAF Architect to lead the
assignment
• In the Preliminary Phase, she meets with the major players at DreamKart
to introduce the TOGAF process Her three goals in the preliminary phase
are to:
– Make sure everybody is comfortable with the process
– Modify the TOGAF process, as necessary, to fit within the DreamKart culture
– Set up the governance system that will oversee future architectural work at
DreamKart
• She will work closely with CxOs to understand the business philosophy,
business models, and strategic drivers of DreamKart.
• She will work closely with the IT team to define the architectural principles
that drive technological architectures at DreamKart and document those
principles using the TOGAF-recommended format
• As soon as the Request for Architecture Work (or some equivalent) has
been received, the TOGAF consultant starts working on Phase A

26. How TOGAF can be used to help DreamKart (2)
• In Phase A, she will ensure that:
– the project has the necessary support within DreamKart
– define the scope of the project
– identify constraints
– document the business requirements
– establish high-level definitions for both the baseline (starting) architecture and
target (desired) architecture
• The culmination of Phase A will be a Statement of Architecture Work,
which must be approved by the various stakeholders before the next
phase of the ADM begins.
• The output of this phase is to create an architectural vision for the first
pass through the ADM cycle
• The TOGAF Architect will guide DreamKart in:
– choosing the project,
– validating the project against the architectural principles established in the Preliminary
Phase
– ensure that the appropriate stakeholders have been identified and their issues have
been addressed

27. How TOGAF can be used to help DreamKart (3)
• The Architectural Vision created in Phase A will be the main
input into Phase B
• The Architect’s goal in Phase B is to create a detailed baseline
and target business architecture and perform a full analysis of
the gaps between them.
– She will work primarily with Business Owners to achieve this.
• Phase B is quite involved. It involves:
– business modeling,
– highly detailed business analysis
– technical-requirements documentation
• A successful Phase B requires input from many stakeholders.
– The major outputs will be a detailed description of the baseline and
target business objectives, and gap descriptions of the business
architecture

28. How TOGAF can be used to help DreamKart (4)
• Phase C does for the information-systems architecture what Phase B does
for the business architecture
• In this phase, the Architect works primarily with the IT Team. TOGAF
defines nine specific steps, each with multiple sub-steps:
– Develop baseline data-architecture description
– Review and validate principles, reference models, viewpoints, and tools
– Create architecture models, including logical data models, data-management process
models, and relationship models that map business functions to CRUD (Create, Read,
Update, Delete) data operations
– Select data-architecture building blocks
– Conduct formal checkpoint reviews of the architecture model and building blocks with
stakeholders
– Review qualitative criteria (for example, performance, reliability, security, integrity)
– Complete data architecture
– Conduct checkpoint/impact analysis
– Perform gap analysis
• The most important deliverable from this phase will be the Target
Information and Applications Architecture.
• Phase D completes the technical architecture—the infrastructure
necessary to support the proposed new architecture.

29. How TOGAF can be used to help DreamKart (5)
• Phase E evaluates
– the various implementation possibilities
– identifies the major implementation projects that might be
undertaken
– evaluates the business opportunity associated with each
• The TOGAF standard recommends that the Architect’s first pass at Phase E
"focus on projects that will deliver short-term payoffs and so create an
impetus for proceeding with longer-term projects.“
• In Phase F, the Architect works with DreamKart governance body to sort
the projects identified in Phase E into priority order that include not only
the cost and benefits (identified in Phase E), but also the risk factors
• In Phase G, the Architect takes the prioritized list of projects and creates
architectural specifications for the implementation projects. These
specifications will include acceptance criteria and lists of risks and issues
• The final Phase is H. In this phase, Teri modifies the architectural change-
management process with any new artifacts created in this last iteration
and with new information that becomes available

30. Challenges of TOGAF
• Much of the results of the TOGAF process will be determined as much by
the Architect/DreamKart relationship as it will by the TOGAF specification
itself. TOGAF is meant to be highly adaptable, and details for the various
architectural artifacts is sparse
• TOGAF allows phases to be done incompletely, skipped, combined,
reordered, or reshaped to fit the needs of the situation. So, it should be no
surprise if two different Architects end up using two very different
processes—even when working with the same organization.
• TOGAF is even more flexible about the actual generated architecture
– TOGAF is, to a surprising degree, "architecture-agnostic“
– The final architecture might be good, bad, or indifferent
– TOGAF merely describes how to generate an enterprise architecture, not
necessarily how to generate a good enterprise architecture
– For this, you are dependent on the experience of your staff and/or TOGAF
consultant
– People adopting TOGAF in the hopes of acquiring a magic bullet will be sorely
disappointed (as they will be with any of the methodologies)

31. Comparison of the EA approaches
Criteria Zachman TOGAF
Taxonomy Completeness 4 2
Process Completeness 1 4
Reference Model Guidance 1 3
Practice Guidance 1 2
Maturity Model 1 1
Business Focus 1 2
Governance Guidance 1 2
Partitioning Guidance 1 2
Prescriptive Catalog 1 2
Vendor Neutrality 2 4
Information Availability 2 4
Time to Value 1 3
Assuming, all criteria have same weightage, the weighted average scores are:
Zachman: 1.41
TOGAF: 2.58

32. So, the Winner for DreamKart is
• TOGAF

33. Enterprise Security Architecture
• Enterprise information security
architecture (EISA) is a part of enterprise
architecture focusing on information
security throughout the enterprise
• The name implies a difference that may not
exist between small/medium-sized businesses
and larger organizations
Source: Wikipedia

34. Cyber Security Frameworks
• A Cyber Security Framework is a risk-based
compilation of guidelines designed to help
organizations assess current capabilities and
draft a prioritized roadmap toward
improved cybersecurity practices
Source: NIST

35. Well Known Cyber Security
Frameworks
• ISO/IEC 27001 & 27002 (formerly ISO 17799)
• NIST SP 800-53: Security and Privacy Controls
for Federal Information Systems and
Organizations
• Sherwood Applied Business Security
Architecture (SABSA)
• NIST SP 800-39: Risk Management Framework
• Security in Major IT Management Frameworks

36. Sherwood Applied Business Security Architecture
(SABSA)
SABSA Model
The SABSA Model comprises six layers. It is based on the well-known Zachman framework1
for developing
model for enterprise architecture, although it has been adapted somewhat to a security view of the world.

37. 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
– Security management issues arises in every horizontal layer
• Each horizontal layers are made of a series of vertical
communication interrogatives
– What (Assets)
– Why (Motivation)
– How (Process and Technology)
– Who (People)
– Where (Location)
– When (Time)

38. Source: sabsa.org

39. SABSA Lifecycle
• Strategy and Planning
• Design
• Implement
• Manage and Measure

40. SABSA Business Attribute Profile
• Business Attribute Profile is at the heart of SABSA
• It is the artifact that link security architecture with requirement engineering
• This is also the linkage between enterprise architecture like TOGAF and SABSA
• Each SABSA Business Attribute is an abstraction of real-life business requirements
created from years of business consulting knowledgebase
• Each SABSA Business Attribute in the taxonomy has detailed definition and
guideline metric for their selection
• A Business Attribute Profile is built by the architects
– using the taxonomy as a guideline to select the relevant attributes for the business case in
hand
– redefining each selected attribute in terms of the business case
– developing a measurement approach, specific metrics and performance targets related to the
business case
– adding new attributes and new definitions as required to fulfil the business requirements in
the specific case in hand
• The Manage & Measure activity in the SABSA Lifecycle is based upon the SABSA
Business Attribute Profile
– that was set out during the Strategy & Planning activity,
– which has been customized specifically to conceptualize the business of this unique
organization

42. Using SABSA
Define
Contextual
Security
Architecture
Define
Conceptual
Security
Architecture
Define Logical
Security
Architecture
Define
Physical
Security
Architecture
Define
Component
Security
Architecture
Define Operational Security Architecture

43. Contextual Architecture Development Process
• Gather, Assesses and Analyze Business Requirements and Current State
– Strategy, Drivers, Goals, CSF, Motivations and Risks
– Business Processes and Functions
– People and Organization
– Location and Time dependencies
– Budgets and Constraints
– Technology Infrastructure
– Service and Systems Management, Management Processes
– Security Policy and Practices
– Deliverable: Working Document
• Use Business Attribute List as a prompt to state key Business Drivers
– Input: Business Attribute Database
– Deliverables: Business Model
• Extract other requirements
– Assess, analyze and collate to create a set of output artifacts
– Deliverables: Business Process Model, Organization and Relationship Model, Business
Geography Model, Time Dependency Model
• Analyze Business Risk
– Assets in the form of Business Attributes with enterprise specific description
– Threat (prompted by Threat Database)
– Impacts (prompted by business knowledge)
– Technical Vulnerabilities, Procedural Vulnerabilities
– Deliverables: Business Risk Model

44. • Define Business Attributes Profiles
– Select Business Attributes mapped to Business Drivers
– Define enterprise specific business attributes, measurement approach,
metrics and performance targets
– Input: Business Attribute Database
– Deliverables: Business Attribute Profile
• Derive Control Objectives from Business Risk Model and
Business Attribute Profile
– Deliverables: Updated Business Risk Model with Control Objectives
• Assess Current State of Security against Business Risk Model
and Control Objectives
– Deliverables: Enterprise Security Posture Analysis Document
• Derive Conceptual Domain Model
– Deliverables: Security Domain Model
Conceptual Architecture Development Process (1)

45. • Derive Conceptual Time Model
– Deliverables: Security related Lifetime and Deadlines
• Derive Trust Model
– Entities (Internal and External)
– Trust Relationship
– Deliverables: Security Entity Model and Trust Framework
• Derive Major Security Strategies
– Mapped to Control Objectives and Business Attribute Profile
– Deliverables: Security Strategy
Conceptual Architecture Development Process (2)
Get Sign-off and Buy-in to Conceptual Architecture

46. How Strategy and Concept phase fits together
WHAT?
Business
Driver
WHY?
CSF
WHEN?
Time
HOW?
Function
WHO?
People
WHERE?
Location
Assets Risks Criticality Dependency Responsibility Logistics
Attributes
Profile
Control
Objectives
Time Model Trust Model
Domain
Model
Security Strategy
Critical Business Processes and Models
CONTEXTUAL LAYER
CONCEPTUAL LAYER

47. Logical Security Architecture Development Process
• Define Security Policy Architecture
– Deliverables: Security Policy Architecture
• Perform Policy Gap Analysis
– Use posture analysis artifact
• Define Security Policies
– Deliverables: Security Policies
• Define Security Services bases on Policies, Strategies and Control
Objectives
– Deliverables: Logical Security Services
• Define Entity Schema and Privilege Profiles
– Deliverables: Entity Schema and Privilege Profiles
• Define Security Domains and Association
– Deliverables: Security Domains and Association
• Define Security Processing Cycle
– Deliverables: Security Processing Cycle
• Perform Services Gap Analysis
– Deliverables: SIP
Get Sign-off and Buy-in to SIP

48. Physical Security Architecture Development Process
• Review Business Data Model
– Input: Pre-existing business data model
• Define Security Data
– Deliverables: Business Data Model updated with Security Data
• Define Security Rules, Practice and Procedures
– Deliverables: Security Rules, Practices and Procedures
• Define Security Mechanism
– Based on Policies, Rules, Practices, Strategies and Security Services
– Deliverables: Security Mechanisms
• Define Applications, User Communities and Design Security User Interface
for each application
– Deliverables: Users, Applications and the User Interface for Security
• Define Platform and Network Infrastructure
– Deliverables: Platform and Network Infrastructure Physical Layout
• Define Capacity and Resilience Requirements
– Using Business Attribute Profile
– Deliverables: Platform and Network Infrastructure Capacity Plan and
Resilience Model

49. Component Security Architecture Development Process
• Define Syntax of Security Data Structure
– Input: Data Dictionary
– Deliverables: Detailed Security Data Structure
• Define Security Standard
– Deliverables: Security Standards
• Select Security Products and Tools
– Input: Product Marketing Information
– Deliverables: Security Products and Tools
• Define Detailed Access Rights for Users and Application Entities
– Deliverables: Identities, ACL, Actions
• Define Details of Infrastructure
– Deliverables: Processes, Nodes, Addresses and Protocols
• Define Capacity and Resiliency Requirements using Business
Attribute Profile
– Deliverables: Security Step Timing and Sequencing

50. Operations Security Architecture Development Process
• Develop Framework for Assurance and Operational Continuity
– Deliverables: Framework for Assurance and Operational Continuity
• Develop Operational Risk Management Framework
– Deliverables: Operational Risk Management Framework
• Develop Security Service Management and Support Framework
– Deliverables: Security Service Management and Support Framework
• Develop User Management and Support Framework
– Deliverables: User Management and Support Framework
• Develop Security Management Frameworks for Sites, Networks and
Applications
– Deliverables: Security Management Framework
• Develop Security Operations Schedule
– Deliverables: Framework for Managing Security Operations Schedule

51. Bringing All Together
Business Strategy
Goals
Relatio
nship
Market
Regula
tion
People
Materi
als
Financ
e
Produc
tion
Logisti
cs
BAP
Risk
Model
Trust
Model
Security Strategy
Process
Design
Policy & Legal
Framework
Technical
Design
Logical Security Services
Confidentiality
Identification
Registration
Certification
Directories
Authentication
Authorization
Access Control
Audit Trail
Physical Security Mechanism
Encryption
Naming
Procedures
Signatures
Databases
Passwords
ACLs
Firewalls
Event Logs
Components
Trusted Business Operations
ProductsTools

52. How SABSA can be integrated with TOGAF

53. Thank You