1 Understanding ESA

Like a building, an enterprise IT environment needs an architecture to be most useful and efficient. Thus, the need for IT architecture, or “EA” is well-understood. But what is an ESA, and why should customers care?

Security architecture has different, or additional, perspectives to IT architecture. It must address risks, threats, and vulnerabilities without impeding the very business it is intended to protect. Security is also a weakest link problem; the defender must protect many different systems and components whereas the attacker need only compromise one – or a few – to break in.

Therefore, security architecture must exist in parallel with all elements of EA. As originally written, EA disciplines have not incorporated any security or risk management drill down. Security architecture has evolved as a separate discipline. However, the Open Group TOGAF EA group has worked over the last few years to better-align EA with security. Rather than reinventing the wheel by developing extensive security disciplines within TOGAF, the Open Group has chosen to reference existing ESA works, such as the Sherwood Applied Business Security Architecture (SABSA).

EA and ESA alignment is a relatively new concept in the industry. Must enterprises do not have an ESA yet. Instead, they have bits and pieces of security architecture that define how their existing systems are protected. Fortunately, much of the typical customer’s prior work on security architecture can be reused. Both EA and ESA (a la SABSA) modeling employ the following multi-layered architecture framework:

• Contextual architecture: How does IT/security support and protect the business?
• Conceptual architecture: What are the people, process, and technology “pieces” of IT and security (at a high level)?
• Logical architecture: How can we specify policies, standards, interfaces, and rules to make the pieces (or components) fit together securely?
• Physical, Component, or Solution architecture: How is each component designed, implemented, deployed, managed, or operated?

ESA can coexist with existing enterprise IT and security architecture specifications, fragmented though they may be. It is easy enough to see that the PowerPoint slides for Board of Directors may already provide a contextual and/or conceptual view. The abstract diagrams the CIO and the CTO teams communicate with may form part of a logical architecture, and the Cisco network diagrams a physical/solution architecture. Some may only be about IT, others about security, some are about both. Through its unifying framework and its connection to EA, ESA can coexist with them; incorporating some, rationalizing others, perhaps replacing a few, and unifying all. Through ESA, enterprises will have better-protected IT systems to support the business.