Category Archives: IT Strategy

Architectural Reference Models related to Smart, Connected Devices

Lately I figured out that I haven’t covered resources on the topic of Smart, Connected Devices (aka Internet of Things (IoT)) in the knowledge base. As the topic spreads across multiple architectural domains (business, application and infrastructure), I’ve updated several knowledge base pages. Please note that the current resources are just a start.

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 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 focussing 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.

In detail they developed:

  • a definition of Smart, Connected Products,
  • a capability-based reference model for managing Smart, Connected Products,
  • a capability model for Smart, Connected Products,
  • 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.

My personal takeaways related to Smart, Connected Devices are:

  • Software should be a key component of the product development cycle of a lot of industries and
  • Software architecture and development capabilities are mandatory to design and deliver Smart, Connected Products (see also Marc Andreessen’s essay Why Software Is Eating The World).

Views on the Application & Technology Architecture

There are a lot of reference architectures on the topic Internet of Things available. In particular, a lot of major software companies have some IoT-related product and/or service in their portfolio. However, if the focus is set on non-proprietary reference models, I recommend the deliverables of the European research project Internet of Things Architecture (IoT-A). Essentially this project delivered:

  • an in-depth architectural reference model,
  • definitions of initial set of key building blocks and
  • several accompanying deliverables like introductive guides and initial API designs.

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.

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!

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 widespread used, 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, 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 including for example 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 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 (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 look after those patterns and try to figure out whether you could reuse a specific pattern. 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 your 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 Open Group Introduced New Standards Supporting Risk Management

At the latest The Open Group conference in London the Security Forum introduced version 2.0 of the Risk Taxonomy (O-RT) technical standard and released the new technical standard Risk Analysis (O-RA). The new version of the Risk Taxonomy standard incorporates some minor updates based on the feedback by practitioners that have been using it. As a companion to it, the Risk Analysis standard provides a process framework that supports FAIR-based risk analysis.
For further details refer to the official blog posts by The Open Group that summarize both standards quite good (part I, partII).
I’ve added both standards to the knowledge base section IT Strategy and Governance.

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

Frameworks and Conceptual Models for Documenting Business Models and Strategy-related Parts of an Enterprise Architecture

A fews weeks ago Nick Malik released version 3.5 of the Enterprise Business Motivation Model (EBMM) (see his corresponding blog post here). On the occasion of that new release I reflected the list of frameworks and conceptual models I know for documenting business models and strategy-related parts of an enterprise architecture.

Actually this list is manifold. The frameworks and models differ in their objectives, background and coverage. Depending on your specific
modeling goals you have to select, combine and/or extend one or more frameworks/models. Hopefully your modeling tool is flexible enough to supports these operations (but this is maybe worth another post).

Here’s the list in arbitrary order with a short description of each framework/model:

Business Motivation Model (BMM) by the OMG

The Business Motivation Model (BMM) describes a framework for developing, communicating and managing business plans (cp. [OMG2008, p. 1]). The common elements of business plans and their relationships are defined and described. It claims to be an simple model, i.e. the elements have only a few simple attributes and the relationsships are primary many-to-many. There are no detailed definitions and classifications of the relationships.

Source: [OMG2008, p.12]

The BMM focuses only on the motivational part of an enterprise architecture and can be used to build models that answer why an enterprise architecture is designed in way it is designed. It does not describe the structural and behavioral parts of an enterprise architecture, i.e. elements like business processes, business objects, applications or technology-related components are not focused by the specification.
Related to the business plans, the BMM can be used to describe a single business plan. Big and complex companies with diverse business units, business models, capabilities and different goals can not be modeled directly.

TOGAF’s Architecture Content Framework with the Motivation Extension

TOGAF contains the Architecture Development Method (ADM) which is a methodology for developing and using enterprise architectures (cp. [TOGAF2009]).  To describe the inputs and outputs of this method in a structured and consistent way TOGAF specifies the Architecture Content Framework and a Content Metamodel. This framework is aimed to be used as a startup-framework so that the ADM can be described and used (cp. [TOGAF2009, p. 361]). TOGAF recognizes that there other and more detailed enterprise architecture frameworks and meta models that can be used with the ADM and therefore replace or extend the Content Metamodel.
The Content Metamodel distinguishes core content and a few optional extensions (Content Metamodel Extensions) that can be used if needed.

Source: [TOGAF2009, p.379]

The Motivation Extension supports the linkage to the motivational aspects of an enterprise architecture by defining the meta model elements Driver, Goal and Objective.

Motivation Extension for the ArchiMate Standard by The Open Group

The ArchiMate standard defines a modeling language for enterprise architectures. It comprises a meta model and graphical notation for modeling the structural and behavioral parts of an enterprise architecture (cp. [Arch2009, p. 1]). The ArchiMate standard complements TOGAF because it describes a meta model (and notation) that goes beyond the Content Metamodel of TOGAF and can be smoothly integrated with the ADM (cp.[JoPT2009]). But version 1.0 of the ArchiMate standard does not support motivational aspects of an enterprise architecture. Therefore it can be used primary to build models within the TOGAF phases B, C and D. To extend the scope the standard there are currently two extensions for the ArchiMate standard specified:

Unlike the main ArchiMate standard theses extensions are currently no Technical Standards but only White Papers submitted to the Open Group. I suppose that both extensions will be integrated in future versions of the ArchiMate standard. Especially the ArchiMate Extension for Modeling and Managing Motivation, Principles and Requirements can be used to model the motivational parts of an enterprise architecture and describe why an enterprise architecture is designed the way it is designed. The Motivation Extension goes beyond the Content Metamodel defined within TOGAF but compared to the Enterprise Business Motivation Model (EBMM) (see below) it is quite small. It defines the elements Stakeholder, Concern, Assessment, Goal, Principle and Requirement and the relationship types Aggregation, Realization, Conflict, Contribution, Specialization and Association (actually only the relationship types Conflict and Contribution are new. The others are reused by the ArchiMate standard.).

Source: On the basis of [Arch2009, QuEJ2010 and JvIQ2010]

The Motivation Extension has two strengths: First it defines the motivational parts of an enterprise architecture and a corresponding notation (analogous to the ArchiMate standards which describes the content and notation too). Second it smoothly integrates with the structural and behavioral parts of an enterprise architecture specified by the ArchiMate standard. It can be used to explicit model why a structure and/or  behavior is designed the way it is designed. Particularly the motivation part of the enterprise architecture can be linked to the structural and behavioral part. The Requirement element is the primary connection to the structural and behavioral part and can be linked to any structural or behavioral element to model that a single or a group of elements realize a requirement (cp. [QuEJ2010, p. 17]).

Enterprise Business Motivation Model (EBMM)

The Enterprise Business Motivation Model (EBMM) was developed by Nick Malik, an Enterprise Architect from Microsoft, in cooperation with several practitioners across various companies and industries (cp. [Malik2011]). The EBMM has a strong focus on the motivational part of the business architecture and for that part supports the modeling of big and complex companies with many business units implementing different business models, capabilities and goals. Other structural and behavioral parts are in scope but are considered only rudimentary. On the highest abstraction layer the EBMM defines the elements Business, Business Unit, Business Process, Directive, Assessment, Business Model, Business Capability, Data Object, Influener, Driver, Initiative and Application (cp. [Malik2011, p. 14 ff.]).

Source: [Malik2011, p. 14]

The relationships are based on a few general connection types and define the specific semantics in the context of the model. The EBBM defines no notation for a graphical representation of its elements and relationships.


If you want to document business models and strategy-related parts of a business architecture take an in-depth look at the frameworks and conceptual models reviewed in this post. They describe the structure and elements of business models and strategy-related parts of an enterprise architecture. Especially they help you to get the big picture with respect to this modeling domain.

Then depending on your modeling scope and level of detail select one framework/model and reuse the concepts and definitions as much as you can (because you shouldn’t reinvent the wheel and it takes a lot of effort to build such models from scratch).

If the framework/model does not meet you modeling requirements completely, extend or combine it with other frameworks/models. Some of them – for example the ArchiMate standard – defines explicit extensions mechanisms which can be used to implement custom extensions that are in line with the standard.

Particularly distinguish between the motivational and the structural/behavioral part of your model. The latter describes what the business, application and infrastructure architecture look like. It encompasses concepts like e.g. business processes, applications , servers and networks. The motivational part describes why these structures are designed the way they are. It contains elements like e.g. objectives, principles and requirements. Both views have to be interconnected to document the design decisions made in the model.



  • [Arch2009] The Open Group: ArchiMate Specification. Technical Standard, Version 1.0, 2009.
  • [JoPT2009] Jonkers, H; Proper, E.; Turner, M.: TOGAF 9 and ArchiMate 1.0. The Open Group White Paper, 2009.
  • [JvIQ2010] Jonkers, H.; van den Berg, H.; Iacob, M.-E.; Quartel, D.: ArchiMate Extension for Implementation and Migration. The Open Group White Paper, 2010.
  • [QuEJ2010] Quartel, D.; Engelsman, W.; Jonkers, H.: ArchiMate Extension for Modeling and Managing Motivation, Principles and Requirements. The Open Group White Paper, 2010.
  • [Malik2011] Malik, A. Nicklas: Enterprise Business Motivation Model. Full Model Documentation, Version 3.5, 2011.
  • [OMG2008] Object Management Group (OMG): Business Motivation Model. OMG Specification, Version 1.0, August 2008.
  • [TOGAF2009] The Open Group: The Open Group Architecture Framework (TOGAF). Version 9, 2009.