Domain Architecture

Parent Previous Next

Domain Architectures

Having concluded that an aggregate of Domains make up the Enterprise it is essential to understand the make-up of any particular domain.  To this end Domains are generally associated with the following characteristics

  1. Clear identifiable discrete subject area
  2. Big enough to warrant major architecture effort
  3. Can logically fit into the Enterprise
  4. Can easily be subdivided into one or more sub-domains

Noticeably a Domain being a division of the Enterprise can also be seen as sub-Enterprise and as such can cause slight confusion as to when is something Domain or when is it Enterprise.  In the final analysis it is not that important as long as the arrangement allows for sub-domains to roll into domains that roll into Enterprises.  Canonical reasoning typifies the following architectures as Domain type architectures.  Amongst others these are:

Foundation and Reference Architectures

Having said all that Domain Architectures naturally expose themselves in two forms, namely, Foundation and Reference Architectures.  Actually these should more aptly be called CORE and INSTANTIATION architectures.  Take for example Work Management as a type of domain architecture.  The foundation side lends itself in describing the Core competence.  The Reference side guide implementation efforts (Projects) that wants to implement Work Management.  This subdivision if you like naturally attracts on the one side Foundation to Enterprise and on the other side Reference to Solution Architectures.  It is about tempering the natural tension between strategic capacity and operational delivery and closing the gap.

Focus of Domain Architecture

Domain architecture naturally aligns to capability enablement. Domains should be use to assign architectural responsibility and ensure the sum of the parts form a coherent whole.

Created with the Personal Edition of HelpNDoc: Free help authoring tool