Why three Architecture Domains?

27 April 2007

Enterprise Architecture encompasses a number of Architecture Domains.

The four primary ones that everyone usually agrees on are the

  • Process Architecture (also known as Business Architecture) ,
  • Information Architecture,
  • Application Architetcure,
  • Technology Architecture (also known as Infrastructure Architecture).

However, one thing I notice is that many EA Frameworks and papers about EA only like to show three primary Architecture Domains.

What is this fixation on the number three?

These three Architecture Domains are typically broken down into further sub-Architecture Domains, but it’s often the Information Architecture that loses out and is either relagated as a subordinate to the Business Architecture or the Application Architecture.

TOGAF identifies Business Architecture, Data Architecture, Applications Architecture and Technology Architecture but then goes on to combine Data Architecture and Applications Architecture as Information System Architecture, resulting once again in three primary Architecture Domains.

The Dynamic Enterprise Architecture (DYA) defined by Sogeti still has only three primary Architecture Domains and places Application Architecture as subordinate to Information Architecture.

The Archimate is a useful framework because it shows the Information Architecture cutting across the other three primary Architecture Domains, as well as sub-Architecture Domains that distingish between Service (behaviour) and structure.

I prefer to talk about all eight primary Architecture Domains given them equal importance.

These are:

  • Strategy & Principles Domain
  • Products & Business Service Domain
  • Process Architecture Domain
  • Organisation Architecture
  • Information Architecture
  • Application Architecture
  • Technology Architecture
  • Performance Architecture

The result of having these eight Architecture Domains is that within an EA team each of these domains will be managed equally, and Information Architecture in particulary will not lose out.

Models  &  deliverables in each of these Architecture Domains are then further classified using categories based on the Reference Models in the FEA Framework.

  • The FEA Performance Reference Mode, PRM is then used with the Strategy & Princiepls Domain and the Performance Architecture Domain.
  • The FEA Business Reference Model is used with the Process Architecture (business process) models.
  • The Service Component Reference Model (SRFM) is used with the Application Architecture models.
  • The FEA Data Reference Model is used with the Information Architecture models.
  • The FEA Technical Reference Model (TRM)  is used with the Technology Architecture models.

Hopefully as the EA discipline evolves, there will be increasing standardisation of how EA is structured. The Archimate EA language is a good start but needs to continue evolving.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: