Minimum Enterprise Requirements (MERs)

Believe it or not, many people in IT and business are still struggling with the concept of Enterprise Architecture, and the actual value it provides to the organisation. The theory is clear, less so how it translates into real value in practice.

The need for well articulated and clear Requirements, however, is well understood. And people generally understand that designing and implementing IT Systems to satisfy requirements generates value to the firm.

Rather than EA and Architecture Standards, I prefer to talk about Minimum Enterprise Requirements (MERs).

What are Enterprise Requirements?

Enterprise Requirements are requirements that exist beyond the boundary of a project or program. They are Minimum when satisfying them is not discretionary. Typically, requirements deriving from a security policy, regulatory demands or strict business constraints are good candidates for MERs.

A MER is a requirement coupled with a clear applicability trigger criteria. This is important, because designing and implementing MERs can (and normally is) expensive. Whether a MER applies to a specific Business System needs to make business sense. Implementing Security MERs to provide a very high level of assurance, for example, makes only sense if the System stores/processes/displays data that is classified as strictly confidential.

I often use the example of Building Regulations to explain MERs and triggers. Building regulations contain the rules for building work in new and altered buildings to make them safe and accessible and limit waste and environmental damage. People carrying out building work must usually arrange for their work to be checked by an independent third party to make sure that their work meets the required standards. In some cases the installer can certify themselves that their work complies (https://www.gov.uk/government/policies/providing-effective-building-regulations-so-that-new-and-altered-buildings-are-safe-accessible-and-efficient). In other words, if you’re building a hospital, there is a MER for disabled access. It’s applicable to all hospitals, and is not discretionary!

To evaluate whether a MER is well defined, I have devised a TUSIV test. As such, MERs must be:

• Traceable (to a business approved firm policy, standard or directive)

• Unambiguous

• Singular

• Implementable

• Verifiable

MER Example

In the digital world, a useful example is a MER related to resilience for systems supporting critical functions (e.g., Core Banking or Trading systems in a bank). For such systems the MER could be something like:

Business Continuity MER:

1. Purpose

This requirement defines the mandatory resilience and business continuity capabilities for a critical banking system to ensure uninterrupted delivery of essential services, protection of customers, and compliance with applicable regulatory and operational resilience obligations.

...

2. Traceable Origin

This MER operationalises the firm policy on Business Continuity, set to satisfy FCA's regulation requiring banks to identify Important Business Services (IBS), set impact tolerances (max disruption time without consumer harm), ...

3. Applicability Criteria

This requirement applies to:

All business applications classified as Tier 0 or Tier 1 under the bank’s Business Impact Analysis (BIA), including all internal and third-party dependencies required for end-to-end service delivery...

4. Business Requirement Statement

The system shall be designed, implemented, and operated to remain available and recoverable during and after disruptive events, including infrastructure failures, regional outages, cyber incidents, and operational errors, such that critical business services can continue to operate within defined tolerance levels.

...

Detailed Quality Attribute Requirement:

Availability ≥ 99.99% during business hours (excluding approved maintenance)

Recovery Time Objective (RTO) ≤ 15 minutes for regional failure

Recovery Point Objective (RPO) ≤ 1 minute data loss

Maximum Tolerable Disruption (MTD) ≤ 30 minutes

...

5. Standard Reference Architecture

The proven standard architecture to address the requirement is as follows

• Multi-Region Deployment: The system must be deployed across a minimum of two geographically separate MS Azure regions...

• ....

• 
  

Any implementation not using the above standard reference architecture must be approved by .....

6. Validation & Verification

• ...