Privacy and Security in Enterprise Architecture Frameworks
The concept of "enterprise architecture," a unified approach to all information systems, has had a resurgence in interest due in part to the mandate of deferral agencies for business to manage and maintain business information. This document will examine two of the most widely adopted frameworks (Zachman and Federal) with an eye toward their use to meet the security and privacy needs of an organization.
INTRODUCTION
IT management has become complex over the years, and technology from different eras (independent machines, mainframe systems, client-server, distributed computing) is often blended in a single organization. The net result is that it's exceedingly difficult for a company to have an accurate "map" of all its information systems or a consolidated plan to manage them.
In the wake of the Sarbanes-Oxley act, companies are scrambling to conform to information security and privacy regulations. Enterprise Architecture frameworks offer a shrink-wrapped solution for doing so, and have been adopted to address these issues. Many such solutions exist, though two (the Zachman Framework and the Federal Enterprise Architecture Framework) are among the more common.
ENTERPRISE ARCHITECTURE
"Enterprise Architecture" is a term that has been defined in a number of ways - management program, documentation method, planning method, a taxonomy - with a myriad of goals. The common thread seems to be a singular method for having oversight of the various systems in which information is stored and processed across an organization.
EA Frameworks have five core components:
- Enabling the organization to better coordinate its information technology with its business operations
- Establishes a standard infrastructure so that business rules can be consistently applied across an organization
- Eliminates system redundancy and identifies opportunities for sharing resources
- Facilitates change management in information systems
- Facilitates legal and regulatory compliance is business practices across the organization
EA includes four different architectures:
- Business architecture - The processes necessary to accomplish the mission of the business and support its operations
- Information architecture - The coordination and maintenance of all data stored by the business for any reason
- Application architecture - The coordination and maintenance of application programs that act upon that data
- Technical architecture - The management of the hardware and software used by the organization
Of key importance is that EA is comprehensive in scope: it means to manage every information system within an organization.
Security and Enterprise Architecture Frameworks
Systems security is assumed to be compromised when there is a lack of central coordination. Each system has its own methods for handling security, which are probably inconsistent, and the chaos of it all is expected to lead to may security leaks and greater vulnerability (EN: As opposed to "one neck for one noose" I suppose?)
ZACHMAN FRAMEWORK
Developed in 1987, Zachman categorizes each business system according to the basic questions:
- WHAT - What data does the system contain or act upon
- HOW - What actions does it take upon that data
- WHERE - Where (systems and network) is the data and application logic housed
- WHO - Which individuals have access
- WHEN - The conditions under which the system is used
- WHY - What is the rationale for having this system in place.
Information is presented in a matrix, where these six questions are answered of several kinds of systems. EN: to be honest, I don't understand it at all - seems unnecessarily complex - but even so, it seems that most of these questions have some implications for security and privacy of the data.
FEDERAL ENTERPRISE ARCHITECTURE FRAMEWORK
The Federal framework (FEAF) arose from a law (Clingler-Cohen act of 1996) requiring all braches of the US government to develop and maintain an EA framework for its IT assets, and a single system that would used by all was derived. This was adopted by business, as it was assumed that the framework developed by the regulators would meet regulatory requirements.
As with Zachman, it's a matrix, and equally complex and incomprehensible - but the core of it seems to be a three-column table:
- Data Architecture - What data is contained in a system
- Application Architecture - What functions act on the data
- Technology Architecture - What hardware and software is involved
This is matrixed against four different perspectives: planner, owner, designer, builder, and subcontractor.
CONCLUSION
Clearly, the author lost me when he got into the nuts-and-bolts details of the two systems. I'm not overly concerned by that, as it seems to depart from the more theoretical discussion of the rest of the book and get into the guts of a specific implementation, which doesn't concern me.