Sponsor Link: EAS Training - Get training in the Essential toolset. Register your interest now. Read more
     
Home Technology Modelling Technology Architecture Modelling Overview
Technology Architecture Modelling Overview PDF Print E-mail
The Technology Layer of the Essential Meta Model is concerned with the Technology that provides and supports the systems that are in use in the organisation - both software and hardware technology. This tutorial introduces the Technology Layer and gives an overview of the main constructs available for modelling Technology Architecture.
As with the other layers of the core meta model, the Technology Layer is split into the following views:
  • Conceptual - The conceptual area is where we define the ‘what’. In technology terms this means ‘what’ technology capabilities are required to provide the appropriate technology infrastructure for the enterprise. For example, Data Integration Services is a technology capability that describes ‘what’ is needed - but does not stipulate how - this capability is to be realised.
  • Logical - The logical area is where we define the ‘how’. In technology terms this is the next level of abstraction of ‘how’ the ‘what’ will be achieved. These deals in terms of the classes of technology and the technology products that are available to realise the Technology Capabilities.
  • Physical - The physical captures the implementation and deployments of technology in the enterprise.  In the technology layer this means the lowest level of abstraction and captures the instances of the technology products and where they are physically deployed.
Technology Layer Overview

The major constructs for capturing Technology Architecture elements are shown in this diagram. The following definitions describe and provide some examples of each construct.

 

Conceptual Layer

  • Technology Architecture Objective - A strategic goal associated with the technology architecture of an enterprise.
    • Examples - Converge Technology Infrastructure to a shared platform
  • Technology Architecture Principle - High level rules that govern the manner in which technology capabilities are delivered by the enterprise and provide the context for designing and defining how these capabilities will be realised.
    • Examples - We will take a service oriented view to delivering technology platforms.
  • Technology Domain - This is the top level construct in the Technology Architecture.  It provides a means of grouping technology into particular areas of focus. 
    • Examples - Integration, Platforms, Development, Storage
  • Technology Capability - Technology Capabilities are conceptual constructs used to describe what a technology fundamentally does or needs to do. These often have quite abstract names in order to cover several Technology Components (see below) that fundamentally provide the same capability.
    • Examples - Application Runtime Services, B2B Integration Services, Messaging Services, Data Management Services.

Logical Layer

  • Technology Component - Describes a particular class of technology that is used to provide a Technology Capability. While Technology Capabilities can be used to capture capabilities that are currently not available, Technology Components should reflect which is currently (or coming soon) available in the technology marketplace.
    • Examples - Application Server, Message Oriented Middleware, Operating System, Document Management System, ETL Platform
  • Technology Function - Describes the functionality that a Technology Component or Technology Product should (in top-down design) can (capturing real products) provide.
    • Examples - RDBMS::read, RuleEngine::load_rules
  • Technology Provider - Captures a Technology Product or a Technology Product Build (a 'standard' Technology Architecture in use in the enterprise) that is being used to provide Technology Components in the architecture. 
    • Examples - Oracle Corporation::Oracle 10g, IBM::COBOL
  • NOTE: The software product that is purchased as a packaged application is captured as a Technology Product, rather than as an application. The particular configuration of that packaged application software deployed in your organisation is captured as an Application Provider.
  • Technology Product Role - A relationship class (reified relation) that captures how a Technology Product or a Technology Product Build provide a Technology Component - using the concept of that product playing the role of the component. This class enables products that provide more than one Technology Component to be accurately captured and to associate the current architectural standard status for the product playing that role. 
    • Examples - Oracle 10g::as::RDBMS is production, Oracle 10g::as::Java Application Server is prototype.

Physical Layer

  • Technology Node - a locate-able technology device that exists in the physical environment of the enterprise. Technology Nodes capture both physical and virtual devices. When capturing physical or virtual server nodes, the hostname is normally used as the name of the Technology Node. Technology Nodes can also contain other Technology Nodes, e.g. for capturing how virtual servers are hosted by a physical server. 
    • Example - server123
  • Technology Instance - A physical instance of an element of technology that exists in the architecture. Technology Instances are exist deployed to Technology Nodes, and the dependencies between these instances are captured - in particular between instances that are deployed on different Technology Nodes. Technology Instances are sub-divided into
    • Application Software Instance - instances of Application Deployments
    • Hardware Instances - instances of hardware technology, such as external disk drives, RAID arrays.
    • Information Store Instance - instances of Information Stores
    • Infrastructure Software Instance - instances of Technology Products
  • Technology Deployment Group - a convenience construct that enables you to define a 'template' deployment of a Technology Node and the Technology Instances that are deployed on that node. You can then specify the number of instances of this 'template' that exist in the enterprise. This is particularly useful for managing scenarios such as standard desktop builds over hundreds or thousands of installations.

 

 
Related Articles