Category Archives: Change Management

Reference Models and Architectures related to Smart, Connected Devices and Internet of Things


It’s been a while since I started to collect and review reference models for the domain of Smart, Connected Devices aka Internet of Things (IoT) (see this former blog post). A reference model is a standard decomposition of a known problem into parts that cooperatively solve the problem (see [BaCK2003, p. 24 ff.). It facilitates the transfer of knowledge in relation to a problem domain and supports the communication between stakeholders, architects and developers. The design and implementation of IT systems connecting to, integrating with and managing Smart, Connected Devices or the Internet of Things is such a problem. Actually it’s an extensive and diverse problem domain consisting of numerous variations of the problem and many feasible solutions. Furthermore, the vendors of so-called IoT platforms usally have their own view on the architecture, services and protocols necessary to deploy IoT-related solutions. Thus, architects have to put those IoT platforms and their underlying architecture into perspective. In addition an IoT-related solution generally isn’t built from scratch and has to be integrated with existing operational technology (OT) systems and business applications. In order to grapple with those challenges architects require knowledge about the problem domain of Smart, Connected Devices/the Internet of Things. Therefore, any stakeholder, architect and developer who’s not familiar with this problem domain, should investigate some reference models to get to know scenarios, variations and options.

Consider this post as a starting point and guide to existing reference models in the domain of Smart, Connected Devices or the Internet of Things – as far as I know them. The release of an Open Group white paper by Chris Harding inspired me to revise my inital blog post and update my knowledge base once again.

Looking at Smart, Connected Devices or the Internet of Things in its entirety, the problem spreads across multiple architectural domains (business, application and technology). Therefore, I differentiate at first between views on business model & business architecture and views on application & technology architecture.


Views on the Business Model & Business Architecture

The high-level business view on the topic of Smart, Connected Devices is excellently described in two Harvard Business Review articles by M. E. Porter and J. E. Heppelmann (see also the section Smart, Connected Devices (aka Internet of Things) on the knowledge page Business Strategy and Business Models):

As far as I know, Porter and Heppelmann coined the term Smart, Connected Devices to separate their work focusing on the ‘changing nature of things‘ from the technology that enables and connects the things. Although they don’t refer to the concepts explicitly, Porter and Heppelmann elaborate on the business strategy and business architecture related to Smart, Connected Devices.

Smart, Connected Devices - Capability Model

A Capability Model for Smart, Connected Products (Source: Porter, M.E.; Heppelmann, J.E.: How Smart, Connected Products Are Transforming Competition. In: Harvard Business Review, November 2014.)

In detail they’ve developed:

  • a definition of Smart, Connected Products,
  • a capability-based reference model for managing Smart, Connected Products,
  • a capability model for Smart, Connected Products (see figure above),
  • a composition of ten new strategic choices in relation to Smart, Connected Products,
  • a summary of the change impacts in relation to the generic, high-level value chain and
  • a summary of the implications for the organizational structure of a company.

Although some of the reference models considered in the next section are also dealing with the business architecture by providing dedicated viewpoints, the aforementioned articles represent the most extensive business-oriented views that I know so far.


Views on the Application & Technology Architecture

There are a lot of reference models on the topic Internet of Things available. In particular, a lot of software companies have some IoT-related products and/or services in their product and service portfolio. However, if the focus is set on non-proprietary reference models, I recommend considering the following existing and emerging architectural deliverables:

The following sections provide an overview of each reference model and put the included deliverables into perspective.


Internet of Things Architecture (IoT-A)

The Internet of Things Architecture is a deliverable of the collaborative European Lighthouse Integrated Project ‘IoT-A’ which was conducted between September 2010 and November 2013. Essentially this project delivered:

  • The IoT-A Architectural Reference Model consisting of a reference model, a reference architecture, corresponding usage guidelines and design choices,
  • a definition of the terminology used across all deliverables,
  • concepts for modeling IoT-related processes and interactions (see deliverables D2.1, D2.2, D2.3 and D2.5),
  • an initial analysis of the appropriate M2M API design (see deliverable D3.1),
  • concepts and solutions for IoT-related resource management (see deliverables D4.1 and D4.3),
  • concepts and solutions for privacy and security (see deliverables D4.2) and
  • a dedicated book providing detailed guidance on how to use the reference model and architecture.

The aforementioned concepts and solutions are supposed to complement the IoT Architectural Reference Model. They deal with distinct aspects of an IoT-related IT system and elaborate on specific design choices and concrete solution architectures.

The reference model aims at establishing a common conceptional foundation and language for IoT architectures and systems. It consists of the following IoT-related models (see figure below):

  • Domain model,
  • information model,
  • functional model,
  • communication model and
  • trust, security and privacy model.

The reference architecture is designed as a generic blueprint for specifying concrete IoT-related architectures. It rests upon and extends the reference model.

IoT-A Reference Model

Interactions of all the Sub-Models in the IoT Reference Model (Source: IoT-A: Updated Reference Model for IoT v1.5. Deliverable D1.3. June 16, 2012.)

The following views are described as part of of the reference architecture:

  • Functional view,
  • information view and
  • deployment and operation view.

Furthermore, the following four architectural perspectives document a collection of activities, tactics and guidelines that support the achievement of non-functional quality attributes of a concrete architecture:

  • Evolution and interoperability,
  • availability and resilience,
  • trust, security and privacy, and
  • performance and scalability.

The IoT Architectural Reference Model also contains detailed guidance on how to use the model to craft concrete IoT-related architectures. Furthermore, the project has delivered a book which provides an overview of the model and guidance on its usage.


Industrial Internet Reference Architecture (IIRA)

The Industrial Internet Consortium is a global, member-supported, organization that promotes the Industrial Internet of Things in order to accelerate market adoption and decrease barriers to entry. There are various working groups and teams working on currently seven areas (Business Strategy & Solution Lifecycle, Legal, Liaison, Marketing, Membership, Security, Technology and Testbeds).

The Architecture Task Group has developed and published the Industrial Internet Reference Architecture (IIRA) as a technical report.

IIRA Architecture Viewpoints

Industrial Internet Architecture Viewpoints (Source: Industrial Internet Consortium: The Industrial Internet of Things Volume G1: Reference Architecture. IIC:PUB:G1:V1.80. January 31, 2017.)

The reference architecture contains the following architectural views (see figure above):

  • Business,
  • usage,
  • functional and
  • implementation.

With the exception of the functional view, all views are rather abstract. They define the elements and relationships of the view and describe some instances of them. The business view focuses on the stakeholders, vision, values and objectives for implementing an IoT-related IT system that is to say it isn’t describing a complete business architecture consisting of business capabilities, processes, roles, etc. The functional view documents five functional domains which are further refined by functions. The implementation view refers to five architectural patterns which can be leveraged to implement IoT-related IT systems.

In addition to the documented views the reference architecture elaborates on the key quality attributes of IoT-related IT systems and discusses how those quality attributes can be achieved generally. However, the level of detail of this discussion varies across the selected quality attributes. Overall it doesn’t reach a level of detail required for the description of an architectural tactic.

The other working groups and teams have produced further technical reports which should be considered too:

The Business Strategy and Innovation Framework identifies and analyzes the problems and approaches on a strategic level that need to be addressed when the IoT in considered in scope of a business or innovation strategy. The Industrial Internet Security Framework rests upon the Industrial Internet Reference Architecture and elaborates on the security concerns of an IoT-related architecture. The Industrial Internet Vocabulary defines common terms which are reference across all other deliverables.

Finally, the Industrial Internet Consortium organizes Testbeds which are opportunities to implement and evaluate IoT-related processed, applications, technologies, products, etc. The experiences and results of the Testbeds are supposed to be reinforced within the working groups and teams.


Reference Architectural Model for Industrie 4.0 (RAMI 4.0)

The Reference Architectural Model for Industrie 4.0 (RAMI 4.0) is a collaborative result of several organizations and institutions: The Plattform Industrie 4.0, VDI/VDE Society for Measurement and Control (GMA), ZVEI and German Commission for Electrical Engineering (DKE). The German term Industrie 4.0 was coined as part of the high-tech strategy of the German government which promotes the enhanced automation and data exchange in manufacturing technologies. The Plattform Industrie 4.0 is a research and collaboration platform which supports the implementation of the aforementioned high-tech strategy. The Industrie 4.0 is considered to be a specialization on the Internet of Things.

The Reference Architectural Model for Industrie 4.0 rests upon the Smart Grid Architectural Model (SGAM) which was developed by the European Smart Grid Coordination Group (SG­CG). It was adapted and extended to fulfill the requirements of the Industrie 4.0 strategy. The model was developed to meet to following objectives:

  • Mapping to existing standards,
  • identification and location of missing standards,
  • identification of relationships within the model and
  • the deduction of high-level rules for the implementation of Industrie 4.0 applications.

It is a three-dimensional model which essentially structures the problem domain of Industrie 4.0-related IT systems (see figure below).

RAMI Reference Model

Reference Architecture Model for Industrie 4.0 (Source: ZVEI/VDE/VDI: Reference Architecture Model Industrie 4.0 (RAMI4.0). July 2015.)

The first dimension consists of the following layers which are located along the vertical axis of the model:

  • Business,
  • functional,
  • information,
  • communication,
  • integration and
  • asset.

Along the left-hand horizontal axis the model outlines the value stream and life cycle of a product. The value stream Type contains the life cycle phases Development and Maintenance/Usage and the value stream Instance comprises the life cycle phases Production and Maintenance/Usage.

The third dimension describes the location of functio­nalities and responsibilities within the factories/plants along the right-hand horizontal axis as a functional hierarchy including the following levels:

  • Connected world,
  • enterprise,
  • work centers,
  • station,
  • control device,
  • field service and
  • product.

Reference Model for Industrie 4.0 Components

An Industrie 4.0 component is defined as either hardware or software which must have certain common properties. Such a hardware or software component can be located in any dimension/layer of the Reference Architectural Model for Industrie 4.0.

The Reference Model for Industrie 4.0 Components elaborates on the definition, characteristics, capabilities and requirements of Industrie 4.0 components. It is the initial publication of a series of elaborations that aim at detailing the reference model.

RAMI Industrie 4.0 Component

Industrie 4.0 Component Model (Source: ZVEI/VDE/VDI: Reference Architecture Model Industrie 4.0 (RAMI4.0). July 2015.)

The definition of an Industrie 4.0 component is based on the description of its characteristics (e.g. type vs. instance, virtual presentation and communication ability) and requirements that each component is supposed to implement. The Administration Shell is a core element of the Industrie 4.0 component concept and encapsulates the virtual presentation and technical functionality a component. It makes the data and functions available to the outside world that is to say other IT systems or human actors.

Web of Things (WoT) Architecture

The W3C has established three groups related to the Internet of Things: Web of Things Interest Group, Web of Things Working Group and Web of Things Community Group. These groups grapple with the lack of interoperability between different IoT-related platforms and aim at identifying and developing standards that facilitate the development of applications independent of the underlying IoT platform.

The Web of Things (WoT) Architecture is a deliverable by the Web of Things Interest Group. It focuses on the application layer of an IoT-related IT system and describes a functional view consisting of logical modules, implemented requirements (see figure below) and reasonable deployment scenarios (deployment view).


Conceptual Architecture of the WoT Building Blocks (Source: World Wide Web Consortium: Web of Things (WoT) Architecture. W3C Editor’s Draft. ‎August‎ 29, ‎2017.)

The WoT Architecture is further detailed by the following deliverables:

  • The Web of Things (WoT) Thing Description defines a fundamental semantic metadata model of a thing and a basic description of its functional interface. The model was designed to describe the capabilities of a thing: properties, actions, and events.
  • The Web of Things (WoT) Scripting API elaborates on the programming interfaces to the Web of Things (WoT) that is to say the different APIs outlined in the WoT Architecture. The APIs deal with the discovery, access and control of Things.
  • The Web of Things (WoT) Binding Templates are supposed to describe standard binding templates for most common protocols which are implemented by the Protocol Binding component of the Web of Things (WoT) Architecture. However, as of this writing the deliverable doesn’t contain any description (W3C Editor’s Draft ‎26‎ ‎February‎ ‎2017).


OPC Unified Architecture (OPC UA)

The OPC Unified Architecture is a platform-independent, service-oriented architecture specification which supports the communication between various systems and devices. It originally focused on promoting interoperability within manufacturing industry but recently it’s also increasingly considered for implementing IoT and Industrie 4.0 scenarios. The specification is maintained by the OPC Foundation which is an industry consortium currently consisting of more than 450 members.

The scope of the specification is the secure and reliable exchange of process data, alarms, events, historical data and batch processes between sensors, instruments, controllers, software systems and notification devices. Therefore, the specification elaborates on the following models:

  • An information model to represent structure, behaviour and semantics,
  • a message model to interact between applications and devices,
  • a communication model to transfer data between endpoints and
  • a conformance model to guarantee interoperability between systems.

Actually it’s a multi-part specification subdivided into three groups: Core specification, access type specification and utility specification (see OPC UA Part 1: Overview and Concepts).

The OPC UA architecture describes a standard by which systems and devices can communicate by exchanging messages between clients and servers over various types of networks. A server hosts a collection of data (so-called AdressSpace) that is provided to clients via services. Each server defines the set of services that it provides and a client can dynamically discover those services. Servers can host current and historical data as well as alarms and events. They can also notify clients of important changes.

Servers provide clients with type definitions for the objects which are accessed based on the AdressSpace. OPC UA supports different data formats like binary and XML. However, the semantics of the data beyond the type definitions is not in scope of the specification.

Due to its flexibility, OPC UA is not targeted at the integration of SCADA, PLC or DCS only but also as a standard to integrate with non-operational technology systems (see figure below).


OPC UA Target Applications (Source: OPC Foundation: OPC Unified Architecture: Part 1: Overview and Concepts. Release 1.03. October 10, 2015.)

The OPC UA rests upon a client-server architecture and the fundamental message exchange pattern adheres to a request-response model. However, the OPC UA Working Group is currently introducing additional communication pattern into the standard (see OPC UA Part 14: PubSub). This will particularly enhance the usage of the standard within IoT-related scenarios where the communication with devices will not be directly but some cloud-related service will be involved.

The Reference Architectural Model for Industrie 4.0 (RAMI 4.0) considers the OPC UA as a standard for implementing the communication layer. However, a detailed mapping of all the standards which were consulted for reuse in RAMI 4.0 is not part of the reference architecture.



The oneM2M is a global standards initiative consisting of eight regional information and communication technology (ICT) standardization bodies, various industry consortia and over 200 member organizations. The fundamental architectural model is the oneM2M Layered Model (see figure below).


oneM2M Layered Model (Source: oneM2M: Functional Architecture. Technical Specification TS-0001-V2.10.0. August 30, 2016.)

The initiative aims at developing technical specifications which focus on a Common Service Layer (also called M2M Service Layer) which supports the connection of heterogenous hardware devices and software components in Machine-to-Machine (M2M) and Internet of Things (IoT) scenarios. The Common Service Layer abstracts the different characteristics of various network protocols and provides a common, standardized set of functions to the Application Layer. Applications don’t have to consider specific networks and technologies. They are decoupled from the network layer and thus can be developed (and maintained) cheaper and faster. The technical specifications are independent of an industry that is to say there are no industry-specific processes, functions and interfaces considered. An exception is the Home Appliances Information Model and Mapping (see TS-0023 and the summary below).

The deliverables of the oneM2M initiative encompass technical reports and technical specifications. The former have supported the development of the technical specifications as intermediate deliverables. They describe for example the results of an analysis of existing architectures and standards proposed for consideration. The latter are considered draft versions of official standards that will be made available by the eight regional ICT standardization bodies (ARIB, ATIS, CCSA, ETSI, TIA, TSDSI, TTA and TTC).

The technical specifications focus for example on the following topics:

  • Requirements (see TS 0002),
  • Functional Architecture (see TS 0001),
  • Security Solutions (see TS 0003),
  • Service Layer Core Protocols (see TS 0004),
  • Common Terminology (see TS 0011),
  • Base Ontology (see TS 0012),
  • Binding to several protocols (HTTP see TS 0009, MQTT see TS 0010, CoAP see TS0008) and
  • Integration and reuse of existing standards (e.g. OMA see TS 0005, BBF TS 0006).

The Functional Architecture elaborates on the oneM2M Layered Model and provides a reference architecture consisting of the following models and views:

  • A functional architecture defining the different components (called entities) in Machine-to-Machine (M2M) and Internet of Things (IoT) scenarios and their interfaces,
  • a detailed functional view describing the concepts, functions and features of the Common Service Layer,
  • architectural concepts and features (e.g. supported configurations and deployment scenarios),
  • concepts for identifiers of entities and objects,
  • fundamental interfaces and information flows, and
  • security aspects.

The descriptions of the concepts and functions of the Common Service Layer are informative. They cover a description of the underlying concepts and elaborate on the capabilities each function should support (see figure below).



Functions of the Common Services Layer (Source: oneM2M: Functional Architecture. Technical Specification TS-0001-V2.10.0. August 30, 2016.)


Furthermore, the Functional Architecture defines so-called reference points to the other layers and Common Service Entities. The reference points encompass one or more interfaces which are detailed in the Service Layer Core Protocols technical specification (see TS 0004). The specification defines the data, interfaces and message sequences that is to say an application-level protocol for all reference points. The application protocol in turn is mapped to a set of supported transport protocols (HTTP see TS 0009, MQTT see TS 0010, CoAP see TS0008 (in release 1 specifications)).

The oneM2M Base Ontology defines a fundamental ontology (i.e. a vocabulary and structure) for the M2M and IoT domains (see TS 0011). Specifc and external ontologies are assumed to be mapped to the oneM2M Base Ontology. The specification also contains the instantiation of fundamental classes which are required to map other ontologies into the Base Ontology (Thing, ThingProperty, Device, Operation, Command, etc.).

One example for a specific ontology is the technical specification Home Appliances Information Model and Mapping (see TS-0023). It defines an unified information model for home appliances by abstracting common elements from existing information models of the home domain (e.g. AllJoyn, Apple HomeKit, ECHONET).

In addition to the aforementioned deliverables the oneM2M comprises more technical specifications and reports. Those deliverales deal with for example requirements and use cases, security, interoperability testing, reuse and integration of existing protocols.


ISO/IEC CD 30141 Internet of Things Reference Architecture (IoT RA)

The ISO/IEC Working Group 3 of the Joint Technical Committee 1 is currently working on the new international standard ISO/IEC CD 30141 Internet of Things Reference Architecture (IoT RA). As of this writing this standard is being reviewed according to the ISO/IEC life cycle process. The draft version of the standard is unfortunately not publicly available. However, when it reached the status of international standard, it will constitute an authoritative reference for IoT-related terminology and concepts.

It will consist of the following elements:

  • Description of the characteristics of an IoT system (e.g. compatibility, usability, robustnes, etc.),
  • conceptual model,
  • reference model and
  • corresponding architectural views (functional, system, information, communication and usage).

Overall the standard will provide guidance for developing a IoT-related system architecture by describing the overall structure of IoT systems.


Summary and Conclusion

The problem domain of Smart, Connected Devices or the Internet of Things is extensive and diversified. It involves numerous variations of the problem and many possible solutions. The introduced reference models and architectures abstract and define the fundamental elements and relationships of IoT-related solutions. Therefore, they are a valuable source to acquire knowledge about the problem domain. Nevertheless, they have miscellaneous emphases and are defined on different levels of detail.

The deliverables by Porter and Heppelmann elaborate on the business strategy and business architecture related to Smart, Connected Devices. However, the primary focus of their work in on the consumer market. The perspectives of the industrial automation domain (or Industrie 4.0) is not represented completely.

The Internet of Things Architecture (IoT-A) which was delivered by the European Lighthouse Integrated Project ‘IoT-A’ consists of an extensive reference model and architecture including several views, concepts and solutions, architectural tactics and guidelines, and even a dedicated book providing detailed guidance on how to use the reference model and architecture.

The Industrial Internet Reference Architecture (IIRA) focuses on industrial IoT scenarios. It encompasses multiple views which are – with the exception of the functional view – rather abstract. The reference architecture elaborates on the key quality attributes but not on level of detail required for the description of an architectural tactic. The Business Strategy and Innovation Framework identifies and analyzes the problems and approaches on a strategic level but doesn’t describe business architecture like Porter and Heppelmann do.

The Reference Architectural Model for Industrie 4.0 (RAMI 4.0) is a three-dimensional model which essentially structures the problem domain of Industrie 4.0-related IT systems. It was developed to conduct e.g. a gap analysis in relation to IoT standards. Therefore, the model is quite high-level compared to e.g. the Internet of Things Architecture (IoT-A) or Industrial Internet Reference Architecture (IIRA).

The Web of Things (WoT) Architecture isn’t aiming at a specific vertical industry or use case. However, it focuses on establishing a common application layer that abstracts from the different underlying IoT platforms. In addition it has a strong bias towards the reuse of existing W3C standards.

The OPC Unified Architecture (OPC UA) focuses on interoperability in industrial automation and Industrie 4.0 scenarios. Moreover, it zooms in on the communication and integration of sensors, instruments, controllers, software systems and notification devices. The OPC UA specifications describe various communication-oriented models and the capability to dynamically define and exchange type definitions. It doesn’t define an additional capability or functional view of an IoT-related architecture.

The oneM2M technical specifications are independent of a specific industry but focus on establishing a common access layer for applications (Common Service Layer) that abstracts from specific networks and technologies. The reference architecture includes multiple views, concepts, protocol bindings and a fundamental ontology for the IoT domain. It is an extensive reference architecture which scope and level of detail can be compared with the Internet of Things Architecture (IoT-A).

The ISO/IEC CD 30141 Internet of Things Reference Architecture (IoT RA) elaborates on the characteristics of an IoT system and describes various models and corresponding views. The level of detail can be compared with the Industrial Internet Reference Architecture (IIRA) although it doesn’t focus on a specific industry. Considering the reference architectures presented in this post, it is the only reference model and architecture defined as part of an authoritative standard. Unfortunately the draft version is not publicly available and therefore the value of the reference architecture is (at least at the moment) constraint.

An interesting finding of my analysis is that the business architecture is rather underrepresented. The deliverables by Porter and Heppelmann are the only ones just focusing on the business architecture. All the other reference models and architectures considered in this post have a strong emphasis on the application and technology perspective. This bias of the reference models and architectures is in line with another perception: The overarching engineering problem of the domain of Smart, Connected Devices/the Internet of Things is not about technology. It’s about the challenge to develop feasible business models, design adequate business capabilities and acquire the necessary skills. Furthermore, most IoT-related scenarios aren’t build up from scratch. Thus, the challenge shifts to the challenge of changing existing business capabilities including business processes, functions, rules and data sets. I assume that reference models and architectures focusing on the business architecture will develop on the basis of the use case scenarios which are already in scope of IoT-related solutions: Optimization of physical assets, enriched products and services, and transformed customer engagement.

Do you know further resources which you consider as fundamental in relation to the topic Smart, Connected Devices or Internet of Things (IoT)?

Sound off in the comments!


With the exception of the ISO/IEC CD 30141 IoT RA, all deliverables are publicly available. You can find a list and corresponding links in the section Smart, Connected Devices (aka Internet of Things) on the knowledge page Reference Models and Architectural Styles.


[BaCK2003] Bass, Len; Clements, Paul; Kazman, Rick: Software Architecture in Practice. 2nd Edition, Addison-Wesley, Boston et al. 2003.

The Myth of Digital Transformation

At the moment Digital Transformation (sometimes also called Digitalization or just Digital) is a prevalent term used on the Internet, in research and various industries. The behemoths of the consulting business have shaped offerings around Digital Transformation (e.g. Accenture, PWC, CapGemini, McKinsey) and established research organizations have embraced the theme (e.g. MIT Center for Digital Business, Digital Business Initiative of Stanford Graduate School of Business). Of course, the big IT research and advisory companies picked up the topic too (e.g. Gartner, Forrester).

In essence, all the fundamental ideas, concepts and approaches of Digital Transformation can be summarized as follows:

  • The leverage of technologies like cloud computing, data analytics, mobile apps, APIs, social media platforms, machine learning, Internet of things, smart & connected devices, etc.
  • The leverage of concepts and approaches like DevOps, agile software development, pace layering, bimodal IT, etc.
  • The usage of those technologies, concepts and approaches to design and implement new business models.

Although the term is used on a widespread scale, I’m amazed that it isn’t put into some kind of perspective and therefore often conveyed and hailed as a new concept.

When I was reading various books, articles and posts on the topic, the idea struck me that Digital Transformation is essentially a just specific pattern of business and IT alignment and therefore isn’t a new concept. Hence, I revisited the fundamentals of strategic business and IT alignment to verify my idea.

Eventually, I contend that the concept of Digital Transformation isn’t fundamentally new. It is a just specific perspective of the problem how to align strategic choices of the business and IT domain effectively. This can be proved by mapping the ideas, concepts and approaches of digital transformation to the Strategic Alignment Model of J.C. Henderson and N. Venkatraman – a model that is nearly 24 years old and still valid.

Introduction of the Strategic Alignment Model

J. C. Henderson and N. Venkatraman developed the Strategic Alignment Model to support the strategic management of evolving IT in 1993. It consists of four fundamental parts: Business Strategy, IT Strategy, Organizational Infrastructure and Processes, and IT Infrastructure and Processes. The parts are discrete and contain categories of strategic choices.


The Business Strategy and IT Strategy make up the external domain: An outward-oriented view on how the organization differentiates from its competitors. The Organizational Infrastructure and Processes, and IS Infrastructure and Processes represent the internal domain: An internal view on the set strategic choices that can be leveraged within the organization.

In addition, the Business Strategy and Organizational Infrastructure and Processes are focusing on the business and thus represent the business domain. The IT Strategy and IT Infrastructure and Processes zoom in on IT aspects and therefore represent the IT domain.

Although the domains and parts of the model are self-contained, they interrelate with each other. In fact, the effective management of business and IT requires to balance all strategic choices within each part. In particular, the alignment of the external and internal domains is called strategic fit and the alignment of the business and IT domains is named functional integration.

Each part of the model contains three categories of strategic choices. Although some of the names seem to be odd today, the scope and contents of each category are still consistent.

The Business Strategy groups strategic choices with respect to the scope and distinctive competencies of the business, and the Business Governance. The former deals with all aspects of a business model for example this includes customer segments, value propositions, channels, customer relationships, etc. (cp. with the Business Model Canvas from A. Osterwalder and  Y. Pigneur). The latter category called Business Governance is quite confusing: It deals with make-or-buy choices as part of the business strategy – an aspect that could also be included in a business model today.

The IT Strategy is similar to the Business Strategy part but it has a distinct focus on the IT domain. The Technology Scope deals with the deliberately-defined compilation of information technologies which support current and future business strategies. The Systemic Competencies are the IT-related capabilities that support the business strategy by contributing a distinctive, competitive advantage to the organization.

As part of the internal and business domain, the Organizational Infrastructure and Processes define how the business should work and what business-related skills are required within the organization. This part consists of administrative functions, (business) processes and (business) skills. Today the term business architecture could be a more appropriate name for this part.

The last part is the internal and IT-related domain called IS Infrastructure and Processes. It consists of (IT) Architectures, (IT) Processes and (IT) Skills, and essentially describes how the IT should work, what applications and infrastructure components are deployed and which skills are required in the internal IT-related domain.

In order to effectively manage business and IT coherently, an organization has to balance all strategic choices within each category, part and domain. As there are a lot of combinations across all strategic choices possible, J. C. Henderson and N. Venkatraman postulate to focus on the cross-domain relationships. Particularly, they suggest four common patterns which describe the fundamental sequence in which the four parts should be aligned:

  1. Strategic Execution: Business Strategy  Organizational Infrastructure and Processes  IS Infrastructure and Processes
  2. Technology Transformation: Business Strategy IT Strategy IS Infrastructure and Processes
  3. Competitive Potential: IT Strategy  Business Strategy  Organizational Infrastructure and Processes
  4. Service Level: IT Strategy IS Infrastructure and Processes  Organizational Infrastructure and Processes

Of course, those patterns just represent general guidelines of how to align all strategic choices according to the defined sequence. Actually, a lot of other dependencies and trade-offs between the strategic choices have to be considered.

Mapping of the Digital Transformation Concepts to the Strategic Alignment Model

The essential ideas, concepts and approaches of Digital Transformation can be mapped to the Strategic Alignment Model as shown in the following figure.


If an organization wants to leverage technologies like cloud computing, data analytics, mobile apps, APIs, etc., the Technology Scope of the IT Strategy is the main category to start with. Essentially, the technologies which are available in the market have to be identified, analyzed and evaluated. Any technology that supports the current business strategy or could potentially shape the design of a new business strategy (or business model) should be included within scope of technologies.

The idea to leverage concepts and approaches like DevOps, agile software development, pace layering, bimodal IT, etc. can be assigned to the category Systemic Competencies of the IT Strategy. Along the lines of the Technology Scope, any IT-related capability that supports the current business strategy or could potentially enable a new business strategy should be a strategic competency of the organization.

Of course the selection of strategic technologies and capabilities is only a starting point. If an organization wants to embrace and master a technology, a change activity is required to learn the new technology, build up the skills and make the technology generally available within the organization. Analogous IT-related capabilities have to be build up or enhanced by implementing a change process within the organization. Think of both categories as the initial trigger on the strategic level to introduce a specific technology or capability to the organization.

The usage of technologies and capabilities to design and implement new business models is clearly related to the part Business Strategy. The Business Scope, Distinct Competencies and Business Governance (that is to say the business model) should consider and work with all technologies and capabilities defined within the IT Strategy. Of course, as with the IT Strategy, this is just the starting point and a business model has to be implemented eventually.

The latter aspect of Digital Transformation also indicates the primary pattern of aligning all the strategic choices: Competitive potential. The IT Strategy including the Technology Scope and Systemic Competencies is the enabler for the business: IT could enhance or facilitate business models and thus the Business Strategy.


Certainly there are a lot of other dependencies in relation to the IS Infrastructure and Processes that is to say the internal, IT-related part but the pattern prescribes the fundamental sequence in which the parts should be aligned.


The concept of Digital Transformation isn’t fundamentally new. It is a specific perspective of strategic business and IT alignment. The ideas, concepts and approaches of Digital Transformation smoothly fit into the components of the Strategic Alignment Model – a model which is nearly 24 years old. Therefore, within any conversation you should pay attention to the way Digital Transformation is explained and positioned. In either case challenge your interlocutor (or the book, article or post you’re reading) by simply asking: What is essentially new to the concept of Digital Transformation?

In addition, there are further implications that should be considered. Firstly, as Digital Transformation is fundamentally just a specific perspective of strategic business and IT alignment, all the existing concepts, frameworks and tools could (and actually should) be considered and reused. Thus, if you have to deal with Digital Transformation, you should have a look at the fund of knowledge that is already available. The following figure illustrates some building blocks that could be leveraged to support the effective alignment of business and IT.


Please note that further sources in relation to the shown concepts, frameworks and tools are available on the following knowledge base pages: Business Strategy and Business ModelsIT Strategy and Governance, Enterprise Architecture Management, Pattern and Good Practices.

Secondly, if there is anything new to the concept of Digital Transformation, it is related to new combinations of technologies, capabilities and business models that enable an organization to accomplish a goal that wasn’t possible before. A new and effective combination can be considered as a pattern of specific, strategic choices and their successful implementation. Therefore, if you have to deal with Digital Transformation take a deeper look after those patterns and try to figure out whether you could reuse a specific one. A good example is the book by G. Westerman, D. Bonnet and A. McAfee: Leading Digital – Turning Technology into Business Transformation. Although they aren’t describing those patterns explicitly, the book contains some interesting case studies about organizations and companies successfully implementing those combinations. The authors were also involved in several empirical studies verifying the effectiveness of implementing ‘digital pattern’. Nevertheless, the concept and approach for analyzing and implementing those patterns aren’t new – it is essentially business and IT alignment.

Thirdly, the methods for delivering the pattern are available but what’s currently unavailable is an approach for documenting the ‘digital pattern’ in a structured and detailed way. I’m thinking of a structure which has to be described up to the level of an enterprise architecture model (see for example the ArchiMate standard) and that elaborates on the objectives and trade-offs of each pattern.

Fourthly, it is amazing to see that the Strategic Alignment Model – which was developed by J. C. Henderson and N. Venkatraman nearly 24 years ago – is still valid and thus can be used today. Some names sound odd but the semantics and logic are still substantive.

What do you think about Digital Transformation? Do you know common ‘digital pattern’? Did you already find the pattern that supports your organization effectively?

Sound off in the comments!


Henderson, J.C.; Venkatraman, N. : Strategic alignment – Leveraging information technology for transforming organizations. In: IBM Systems Journal, Vol. 32, No. 1, 1993.

Osterwalder, A.; Pigneur, Y.: Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers. John Wiley & Sons, 2010.

Westerman, G.; Bonnet, D. ; McAfee, A.: Leading Digital – Turning Technology into Business Transformation. Harvard Business Review Press, 2014.

The Links and Knowledge We Have to Share

Recently I found an interesting article by Hossein Derakhshan titled ‘The Web We Have to Save‘. Hossein was sentenced to jail because he blogged on Iran-related topics and motivated other Iranians to start blogging. After he spend six years in jail, he was abruptly pardoned and freed. During the time in jail he actually missed major events like social media and the raise of companies like Facebook, Instragram, WhatsApp, Youtube, etc. Thus, he was confronted with a major shift how the Web developed so far and it is used today.
In his article he elaborates on his experiences with social media and compares the current usage of the Web with the one he used to know. He argues that a few social media companies dominate the way and type of information people access over the Internet. Hossein criticizes the vast devaluation of the hyperlink because the major social media companies constrain the usage of links on their platforms. Some of them are even constrain the usage of external links and manipulate user traffic to stick to their platform. He concludes that we experience a decline of diversity and opinions on the Web today.
Although Hossein’s experience and conclusion isn’t new – I’m observing the same movement for a while – I really think that he put this development brilliantly into words. I share his observations but I’m not sure about the magnitude of this trend. Maybe I’m biased in favour of information technology because that was (and still is) the main motivation for me to get access to some network and share information, experiences, software, games, knowledge etc. with people around the world. I still remember the 1980s when this access was only provided by some local bulletin board systems (BBS) and companies like CompuServe. Meanwhile the technologies evolved, especially the Internet and Web led to disruptive changes in almost every domain.
‘Information at your fingertips‘ was concept that was presented by Bill Gates initially in 1994. Today, I think this concept is real but the current Web is developing even beyond the fundamental idea behind this concept. Nowadays we can access so much information that we need dedicated technologies like search engines, data analysis tools, etc. to guide us through the vast amount of information. Otherwise there is still so much valuable information (and therefore knowledge too) available in books, journals, newspapers, etc. that is not directly accessible via the Internet or Web.
In addition to Hossein’s observations, I think of two related trends. First, information that is not available on the Internet or Web, is assumed to not exist. Therefore, it is simply ignored and sometimes concepts, ideas, etc. are developed twice without any notice. I’ve observed this attitude in the domain of computer science and particularly information systems management. Second, the proliferation of information doesn’t correlate with the quality of information. The quality of information is, of course, defined by the consumer but overall I wonder whether really all the information has some value. I’m specifically thinking of all the data that is produced and uploaded on social media platforms. Nevertheless, at least the ad industry is paying a lot of money for such data… On the other hand, I really believe that there is value in technologies like for example big data or the Internet of Things that isn’t directly related to advertising.
In summary, I draw the following conclusions. First, respect the free Internet/Web and appreciate the freedom of speech and opinion. Don’t take both for granted. There’s still restriction, censorship and arbitrariness. Second, consider the existing knowledge beyond the Web. Each domain has, of course, its own history and nature of knowledge sources. Nevertheless, keep in mind that the Web is definitely not the only one. Third, support the communication and collaboration beyond the major social media companies and therefore the freedom of links. There is something beyond those social media platform. Fourth, I should revive my blog. Although it’s not dealing with political topics, it supports all the conclusions mentioned above. Of course, the scope is focussed on the domain of architectural change management but that’s fine. Therefore, subscribe and watch out for updates!

Upcoming Tweet Jam on the Convergence of Emerging Technologies hosted by The Open Group

At first Gartner picked up the thought and named it ‘The Nexus of Forces’. IDC coined the term ‘third platform’ and The Open Group established a new forum named ‘Platform 3.0’. All of them recognized that there are several (emerging) technologies that are likely to converge in the future and potentially change the way businesses and people engage with each other. The lists and names of the technologies in scope differ depending on the organizations named before. In general they refer to the following technologies: social media, cloud computing, mobile computing, Internet of things and processing of big data.

From the perspective of the discipline of enterprise architecture management this convergence raises the question if (major) architectural changes are required to cope with this development.

To encourage knowledge exchange on this question, The Open Group will host a tweet jam on Thursday, June 6 at 9:00 a.m. PT/12:00 p.m. ET/5:00 p.m. GMT (see this blog post).

Please find below an initial set of links suggested for further reading.



The Open Group

Avolution’s ABACUS® 4.0 is ArchiMate® 2.0 Certified

Avolution today announced that its latest release of ABACUS (version 4.0) is now officially certified against The Open Group’s standard, ArchiMate® 2.0 (see Avolution’s press release here). I want to point out that I’m not sponsored by Avolution or any other vendor but what’s interesting from my point of view is that currently only a three tools are currently ArchiMate 2.0 certified: ABACUS® 4.0, Architect 3® by BiZZdesign and ArchiMate for IBM’s System Architect® (see The Open Group’s Tool Certifcation Register here).

Seems to me that the other vendors struggle with the flexibility in relation to the metamodel which is required by ArchiMate 2.0 (see this post for more details on that issue).

I’ll keep an eye on other ArchiMate 2.0 tool certifications… 😉

No Politics, Just Great Architecture

A few days ago a friend of mine changed the short description of his business on his Linkedin page to the slogan: ‘No politics, just delivery.’. What a brilliant slogan! He’s working in the IT project business for many years and I assume that he’s tired of all these projects that are heavily influenced by politics. Of course each nontrivial IT project has to deal with miscellaneous stakeholders and their conflicting objectives/requirements including politics but I think he’s referring to those ones where politics dominates and sometimes leads to strange decisions and project conditions.

Transferring his idea to my primary business of (enterprise) architecture management I adopted it spontaneously to ‘No politics, just great architecture.’ because sometimes there is architectural work that is heavily influenced by politics too. When I spend a few more thoughts on it I was struggling with the adjective great. Of course there is no great or even bad architecture. Remembering the very basics of evaluating architectures an architecture always has to be considered in its context that is framed by the specified requirements (including objectives, principles, constrains) that it has to fulfill (see [ClKK2002, Mali2008]). So it’s much better to characterize it as a capable architecture, i.e. an architecture that fulfills all the requirements that are imposed to it, but ‘No politics, just capable architecture.’ doesn’t sound so smashing… 😉

Anyway there is still the question how to deal with such situations which are heavily influenced by politics. When looking at the enterprise architecture discipline in particular what should an enterprise architect do if he realizes that he is doing architectural work in a politics dominated environment? Furthermore from my point of view it is interesting if there are any best practices or strategies how to cope with such challenges. When looking at TOGAF for example (see [TOGAF2011]) there’s no special chapter or topic explicitly dealing with this question but of course there are a lot of basic methods, guidelines and techniques described in this framework (e.g. architecture requirements management, stakeholder management) that provide the foundation for coping with such situations.

When thinking of the most important pillars of this foundation I came up with the following ones:

1. The role of the enterprise architect should be executed in an objective manner

The enterprise architect role is responsible for providing a capable (alias ‘great’) architecture that fulfills the requirements imposed to that architecture as good as possible. When investigating and evaluating the architectural options the architect himself should be objective, i.e. he should adhere to the facts and should not rely on personal flavor. You might say: ‘Yes, of course!’. Sounds like simple logic but it isn’t… According to Bass, Clemens and Kazman there are four major factors that influence the development of an architecture: Stakeholders, the developing organization, the technical environment and the architect’s experience (cp. [BaCK2003, p. 9-12]).

Source: On the basis of [BaCK2003, p.11]

The latter characterizes the fact that within the development of an architecture the architect gains additional knowledge and extents his experience (cp. [BaCK2003, p. 11]). A successful implemented architecture will inspire an architect to design a similar architecture for another project. An architecture that fails to deliver the expected requirements (including objectives, principles and constraints) is unlikely to be chosen second time. If an architect has little experience with respect to an architecture, architectural building block and/or architectural pattern it is less likely that he will take it into the range of design options.

Therefore an architect should be beware of the fact that his experience influences the architectural design process. In addition he should be open and curious in relation to previously unknown or unapplied design options. These might be the better ones although they were not used by the architect yet.

2. Document the design decisions taken and their rationale

Going back the very basics of documenting architectures the design decisions taken and their rationales should be a mandatory part of the architecture documentation. For example Clements, Bachman, Bass et al. describe this idea in their ‘Seven Rules for Sound Documentation’ (Rule 5: Record Rationale, see [CBBG2003, p. 24-29]). Here it is important to notice that all evaluated options should be documented to support the transparency of the decision process – not only those leading to the final design. Therefore each template for architecture documentation should contain a dedicated chapter and/or structure supporting this part of the documentation.

In case the architect works on the enterprise architecture level a motivational model as part of an overall EA metamodel supports the explicit modeling of the objectives, principles, requirements and constraints and their linkage to the architectural decisions and elements respectively. Take for example Open Groups’ ArchiMate standard which contains such an motivational model in its latest version 2.0 (see [TOGAF2012] and this related post).

3. Use qualitative metrics to the most possible extend

The paramount architectural evaluation is based on qualitative metrics solely but in rare cases the architect has all underlying data and evaluation models and therefore is able to calculate all required metrics. Nevertheless the architect should strive for using qualitative metric by identifying available basic data, useful evaluation models and trying to combine architectural decisions with relevant metrics. In case there are at least some metrics available pure political decisions could be argumented against easily.


  • [BaCK2003] Bass, Len; Clements, Paul; Kazman, Rick: Software Architecture in Practice. 2nd Edition, Addison-Wesley, Boston et al. 2003.
  • [CBBG2003] Clements, Paul; Bachmann, Felix; Bass, Len; Garlan, David; Ivers, James; Little, Reed; Nord, Robert; Stafford, Judith: Documenting Software Architectures – Views and Beyond. Addision-Wesley, Boston et al. 2003.
  • [ClKK2002] Clements, Paul; Kazman, Rick; Klein, Mark: Evaluating Software Architectures – Methods and Case Studies. Addison-Wesley, Boston et al. 2002.
  • [Mali2008] Malich, Stefan: Qualität von Softwaresystemen – Ein pattern-basiertes Wissensmodell zur Unterstützung des Entwurfs und der Bewertung von Softwarearchitekturen. Gabler, Wiesbaden 2008.
  • [TOGAF2011] The Open Group: The Open Group Architectural Framework (TOGAF).  Version 9.1, 2011.
  • [TOGAF2012] The Open Group: ArchiMate 2.0 Specification. Technical Standard, February 2012.

Welcome to the Architectural Change Management Blog!

My name is Dr. Stefan Malich and I devote myself to the disciplines of enterprise and software architecture. I started my career as a freelance IT consultant and software developer. In 2001 I joined the global management consulting company Accenture. Within the consulting business I developed many architectures and led several architecture teams mainly in whole sale, the financial services and energy industry. In a sabbatical leave I was engaged
at the Institute for Computer Science and Business Information Systems and worked on a personal PhD research project which dealt with pattern-based architectural knowledge. After finishing my doctoral thesis I’ve focused on enterprise architectures and worked on several enterprise architecture projects within the financial services and energy industry. I led projects to build up or enhance enterprise architecture capabilities and gained explicit knowledge of the various aspects of an enterprise architecture capability (processes, models, governance, roles and functions, tools, maturity models etc.).

Lately I’m looking into the change management aspects of the enterprise architecture management discipline and that’s what this blog is all about.
My observations led to the thought that – especially when building or enhancing an enterprise architecture capability – enterprise architecture management is even more than e.g. staffing an enterprise architecture team, defining an EA meta model and deploying an EA tool. It is about developing
an EA team with the right skills, building up the relevant architectural knowledge and positioning the results of the EA team for use within the company. In many companies this situation leads to a fundamental change in the way it is concerned with enterprise and software architectures. Existing capabilities, goals, skill sets, processes, governance and organizational structures etc. are questioned and major change transformations are needed to build up or enhance the enterprise architecture capability.

This blog will adress the challenges of such an architectural change transformation. Currently I think of the following questions that guide my work:

  • To develop an EA team with the right skills and relevant architectural knowledge you need know the state of art of the enterprise and software architecture disciplines. You do not want reinvent the wheel, right? This blog already contains a pretty large list with links and knowledge sources covering enterprise architecture, software architecture and other topics. Of course this list is not exhaustive but to my mind all entries are valuable.
  • How do you effectively build up architectural knowledge? With regard to the architecture itself patterns and ‘best practices’ are a proven approaches. Take a look at the Patterns and Good Practices page. But how  do you build up knowledge  concerning the enterprise architecture management capability (e.g. processes, models, governance, roles and functions, tools)?
  • What is the state of the art of the change management discipline? What can we learn and reuse from this discipline?

If you interested in this challenges revist this blog, subscribe to it or contact me directly.