From a Technology Perspective

The second of three (2 of 3) perspectives used to Organize Enterprise Content segments transformation scope from a Technology Perspective.

In general, this perspective will be most familiar to participants who work within the IT or Vendor organization(s) that transformation initiatives will affect.

However, participants from the other perspectives - Business and Delivery - also need to understand this perspective in order to align their efforts with those of their technology counterparts.

Previously, the related Business Perspective introduced several terms used below.  Additional terms introduced here include:

  • Application (Product) Architecture
  • Technology (System) Architecture
  • IT Services
  • Technology Groups and
  • Enablers.
On This Page
    Add a header to begin generating the table of contents

    ITM Technoloy Perspectives

    Application (or Product) Architecture

    To begin, Application Architecture is the first technology perspective.  It is one of several architectural domains upon which Enterprise Architecture and Solution Architecture are based.  Specifically, it describes the applications used to support business operations, how they interact with each other, and with end-users. Moreover, Application Architecture brings into focus the data produced and consumed by each application.

    Significantly, applications map to the Business Process(es) which they support.  In turn, each Business Process maps to a Process Group, Value Stream and Business Segment.  As a result, these provide the perspectives necessary for enterprise Portfolio Management.

    To be sure, the objective of Application Architecture is to ensure the applications, and their integrations, available to the Business align with the organization's growth strategy.  Additionally, it is also a means by which organizations seek to minimize costs and complexities by identifying and eliminating unnecessary redundancies.  To illustrate, the sample reference depicts:

    • Seven (7) physical applications (SAP, Oracle, JDE, etc.) currently available.
    • To support the Financial Management logical application.
    • Within Enterprise Resource Planning (ERP) application platform.

    Of course, this may indicate opportunities to consolidate the number of systems. In effect, this would free resources (license costs, platform costs, personnel) to provide better value elsewhere.

    Application Architecture Reference

    Scaled Agile Framework (SAFe)

    Within the Scaled Agile Framework (or SAFe), applications are one type of Solution - called Products.  As a result, the corresponding term Product Architecture is synonymous with Application Architecture.

    In larger organizations, major applications frequently have an individual designated as their architect.  Referred to as the Application Architect, or Product Architect, this person should possess a deep understanding of the given Product.  Further, they should be the primary point of contact for how to use the Product as well as how it integrates with other applications and systems.

    Other architectural domains and technology perspectives include:

    • Business Architecture - which defines enterprise aspects such as: Organization; Information; Value Streams; and Capabilities; amongst others.
    • Data Architecture - which defines the models, policies, rules and standards that govern which data is collected, as well as how it is stored, arranged, integrated and applied within Solutions supporting the organization; and
    • Technology Architecture - see next.

    There are other architecture domains.  However, they are pertinent to describe the objects used to Organize for Iterative Transformation.

    Technology (or System) Architecture

    Analogous to the Application Architecture, the Technology Architecture is another technology perspective.  In general, it describes the high-level map, or plan, of various IT assets within the organization.  Basically, Technology Architecture brings into focus the specifications, models and guidelines which describe how and when to use each asset.

    Typically, technologies map to functionality they provide.  The generic name for such functions is Enablers.  Accordingly, each Enabler maps to a Technology Group, IT Service and Business Segment.  Together, these provide the perspectives necessary for enterprise Portfolio Management.

    To clarify, the objective of Technology Architecture is to ensure the technologies available to the Business align with the organization's IT strategy.  Moreover, it is another means by which organizations seek to minimize costs and complexities by identifying and eliminating unnecessary redundancies.  To illustrate, this sample reference depicts:

    • Eight (8) physical technologies currently available.
    • To support the Database Management Systems logical technology.
    • Within the Data Services technology platform.

    Obviously, this may indicate opportunities to consolidate the number of systems.  As before, this would free resources (license costs, platform costs, personnel) to provide better value elsewhere.

    Technology Architecture Reference

    Scaled Agile Framework (SAFe)

    Within the Scaled Agile Framework (or SAFe), technologies are a second type of Solution - called Systems.  As a result, the corresponding term Systems Architecture is synonymous with Technology Architecture.

    In larger organizations, major systems frequently have one or more individuals designated as its architect.  Referred to as the Technology Architect, or System Architect, this person should possess a deep understanding of the given System.  Further, they should be the primary point of contact for how to use the System as well as how it supports and/or integrates with other applications or systems.

     

    Product Architecture, Systems Architecture and the other architecture domains share many interdependencies.  Each describes a perspective of knowledge, skills and abilities (KSAs) needed to enable information and business processes.

    IT Services

    IT services refers to the use of business and technical KSAs to enable organizations to create, manage and improve the use of, or access to, information and business processes.  Typically, the type of KSAs employed to deliver the service (design, build, operate) segment various IT Services.  Further, they may also categorize services which relate to Business Process, Applications (Products), or Infrastructure (Systems).

    IT Services are the Technology Perspective equivalent to Value Streams in the Business Perspective.  They seek to organize one or more Technology Groups into broader areas of business value.  Each reference diagram above depicts several IT Services also depicted in the figure below.  This provides a view similar to that which appears in the Business Perspective to describe Value Streams and Process Groups.

    3rd parties, such as Vendors or Business Partners, may provide some IT Services.  This is typically referred to as Business Process Outsourcing (BPO), Application Outsourcing (AO) and/or Infrastructure Outsourcing depending upon the IT Service(s) the 3rd-party provides.

    Technology Groups

    Technology Groups describe high-level functionality within each IT Service.  These allow the identification and grouping of related components in order to leverage similarities and mitigate redundancies.

    Each Technology Group is a set of one or more technology Enablers, managed by (i.e. provided by) an identifiable group, typically within IT.

    Technology Groups are the Technology Perspective equivalent of Process Groups in the Business Perspective.

    Enablers

    Enablers are the basis for all technology capabilities.  An Enabler is simply something which makes something else possible.  Enabler is a mid-level description of some functionality which provides value to the enterprise.

    Enablers are mid-level in that they roll up to, or are summarized by, Technology Groups.  Any given Enabler will roll up to one, and only one, Technology Group.

    If there is ever an attempt to make a single Enabler belong to multiple Technology Groups, something is amiss.  Each Technology Group, in turn, rolls-up to a single IT Service.

    Enablers are mid-level in that they also decompose into Design Patterns, Models and Specifications.

    Each Enabler is supported by a Solution.  More on Solutions after the Delivery Perspective.

    High-Level Content Segment Comparison

    IT Services

    The union of the Product (Applications) & System (Technologies) Architectures identify all IT Services and Technology Groups within the organization.

    Furthermore, just as Business Processes align with a specific Product Architecture, technology Enablers align with a specific System Architecture.  Common to both, Solutions make both Processes and Enablers available to consumers.

    Thus, comparable views exist across Business & Technology:

    Business Perspective
    Technology Perspective
    Value Stream IT Service
    Process Group Technology Group
    Business Process Technology Enabler

    While these higher-level segments used to Organize Enterprise Content differ between Business and Technology, the lower- level segments used to affect iterative change are the same for both.

    The Delivery Perspective introduces these lower-level content segments.

    Scroll to Top