Compliance Blog

A couple of weeks ago we blogged about the Federal Financial Institutions Examination Council’s (FFIEC) recently issued Architecture, Infrastructure, and Operations (AIO) booklet. Because of the length of the booklet, the blog examined how the new AIO Booklet differed from the Operations booklet, which was retired after being around since 2004, without getting into too much detail. Today’s blog will take a closer look at what architecture means and FFIEC’s expectations for managing risk associated with architecture.

What is Architecture?

The AIO booklet explains what FFIEC means when it refers to architecture:

“Architecture refers to the manner in which the strategic design of the hardware and software infrastructure components (e.g., devices, systems, and networks) are organized and integrated to achieve and support the entity’s business objectives. Planning and designing an effective IT architecture facilitate management’s ability to implement infrastructure that aligns with the entity’s strategic goals and business objectives.”

Architecture describes how credit unions design the use of hardware and software to achieve their business goals. The booklet notes that architecture “should meet the entity’s needs for confidentiality, integrity, and availability and adhere to the entity’s policies, standards, and procedures.”

The Design Process

Because architecture needs to be aligned with the credit union’s business objectives, the booklet suggests that the architecture design process needs to be flexible to plan for usage of different hardware and software in the future. In planning for the future, the booklet explains that credit union management needs to understand its existing architecture, what is common in the industry, and what future architecture might best align with the credit union’s business goals before “perform[ing] a gap analysis to determine the requirements to reach its future state.”

The booklet explains that there is an expectation that credit unions have policies and procedures controlling the architecture design process and that the process should consider the following:

• Which stakeholders are responsible for the different processes in the design and who makes decisions?
• What kinds of requirements are needed by the architecture design?
• Is the architecture design consistent with the credit union’s information technology (IT) and business goals?
• What existing IT assets does the credit union have and how are they used?
• Does the contemplated architecture design make sense from a cost-benefit perspective?
• What kind of sign-off is needed for a contemplated change to the architecture design?
• What kinds of resources are needed to implement the contemplated architecture design and what kinds of resources are needed to support the design in the future?
• How will the credit union resolve issues with architecture?

The booklet discusses the importance of having an architecture plan, which identifies the credit union’s current architecture and how it aligns with its strategic plan and business goals. The booklet explains that (1) credit unions are expected to have policies and procedures in place to guide how credit unions change their architecture plans; (2) architecture plans can be tailored to a credit union’s size and complexity; and (3) complex changes should incorporate a three-phase process—preparing for the change, effecting the change and observing the effects of the change, and documenting the changes in the architecture plan.

The booklet talks about the importance of collaboration with business lines in architecture design. The booklet identifies several things that credit union management should address in its architecture design, including things like data security and data privacy, third-party integration, the effects of future technology, etc. The booklet also suggests that credit union management should think about how future technology may affect the credit union’s architecture design and account for end-of-life considerations (i.e., “when an asset has reached the end of its useful life cycle or when the vendor will no longer support the asset or continue to sell or license it.”).

The booklet notes that architecture design needs to consider whether the design environment should be handled internally by the credit union or by a third-party and identifies some risks that may arise with virtualization. Virtualization is defined in the National Institute of Standards and Technology’s (NIST) Special Publication 800-125 as “[t]he simulation of the software and/or hardware upon which other software runs.” Other usages of virtualization in NIST publications suggest that virtualization can lead to efficiencies in managing IT resources.

The last section on architecture deals with enterprise architecture, which appears to be analogous to enterprise risk management (ERM). It describes how all the information systems of a credit union work together. Just like ERM looks at risk management across the credit union, enterprise architecture takes a holistic view of architecture. It looks at the current architecture, the credit union’s intended architecture in the future, and how the credit union plans to get from point A to point B. It “provides a logical structure allowing management to classify, organize, and document elements of the entity’s systems, functions, and information.” The booklet notes that smaller or less complex credit unions may not need enterprise architecture, but it recommends that larger or complex credit unions may benefit from making enterprise architecture part of how they manage their information systems.