The Architecture of Change – Part 3

Oct 25, 2016

The Architecture of Change; business architecture and the meaning of Digital Transformation


    figure1        Figure 1: Wave of the Future.  Image from “Wave of the Future” poster by Brad Pomeroy and Judy Kirpich (1982)

[This is the final installment of a three-part article describing digital transformation and its illumination using a discipline known as business architecture.  The Part 3 lays out the basic principles of business architecture and applies them to a business planning its own digital transformation.  Finally, I argue that, insofar as digital transformation has a meaning, it is architectural in nature.]

The Story So Far

In parts 1 and 2 of this article, I sought to understand what was meant by “digital transformation” as described by the consultants and scholars using the term in contemporary literature.  I then asked the question: how would one go about deliberately transforming a business using digital technology?

Because transformation is by definition a fundamental change in the nature of a thing,[1] the method for purposeful change must look beyond the particular and accidental features of a business.  Building a website or a mobile app to take orders online rather than by phone is not necessarily transformational and does not necessarily impact either the business model or the position of the business vis-ā-vis the competition.   Such changes can be very superficial and even counterproductive, as many a CMO or CEO can attest.

I observed that transformational change requires that we abstract from particulars and identify those features of a business that are essential to its function and that are stable over time.  By identifying the systemic and enduring components of a business in a rigorous and systematic way, we free the imagination to envision alternate configurations that might better satisfy the goals we are after.  Far from constraining creativity, an exacting and structured process enables the imagination by providing definiteness to our abstractions.  We concluded that the tool we need for business transformation is a system architecture that that describes the structure and behavior of a business –a business architecture.

Business Architecture as Essential Structure

I argue that the concepts of business architecture[2] offer the just the generative abstractions we are seeking.  They are among the most well-developed and universal of business abstractions, useful and comprehensible across all businesses. Business architecture provides common terms for addressing the what, who, how and why of all businesses, so that we can agree (or disagree) on our descriptions of particulars.  It provides for an essentially complete model of all the elements comprising the business, and is capable of aligning with other low-level, domain-specific or viewpoint-specific models of the business related to IT, Marketing, Product Development, Strategy, Process, and so on.

Business architecture enables us to build a model of a particular business (or of a type of business), which in turn allows us to ask questions and pose hypotheticals about what the business consists in and how it operates. Just as a building architecture establishes a basic vocabulary and set of principles for describing surfaces, structures, materials, functional units, aesthetic patterns and the like, so too does business architecture use certain fundamental concepts to describe the way a business is constructed.

The core elements of business architecture are value, capability, information and organization.  These are stable, enduring business structures that persist over long periods of time, both during the lifetime of a specific business and over the course of history for businesses of that sort (existing for perhaps hundreds of years).  These elements are fundamental to a business and attach directly to strategy, and it is to strategy where we must look first for truly transformational change.


Figure 2: core business architecture elements

To avoid becoming pedantic in what is hopefully an interesting and even entertaining article, I’ll refer the reader to the Business Architecture Guild’s free introductory chapter of BIZBOK,[3] or to its video overview[4] for a full description of the basic concepts.  For those nevertheless wanting a short primer, here is a footnote.[5]

Let’s forge ahead employing business architecture concepts ‘on the fly’ in the example that follows.  I’ll hope to convey their meaning by using them in an imaginary but concrete context.

Act Locally, Think Globally, Hold the Starch

The substrate for our story of digital transformation is a business familiar to anyone who has ever worn dress attire: the neighborhood dry cleaner –  it accepts shirts, dresses and suits for cleaning and pressing, gives you a pink ticket and makes your clothes available for pickup a couple of days later, clean, pressed and on hangers or folded.

Why use such a humble, prosaic small business example for illustration?  Business architectures have been developed for banks and large financial institutions, aircraft manufacturers, drug companies, insurance companies, utility companies, airlines and even the U.S. Patent Office.  Dramatic case studies of digital transformation have been documented for paints manufacturers, apparel manufacturers, international mortgage companies, media companies and airport operations specialists.

But if business architecture is sufficiently universal, and digital transformation sufficiently pervasive, each should apply in equal measure to all strata of business activity.  Small business retailers are no less affected by truly profound changes than large multinationals, and the fundamental structure of their operations is simpler and more amenable to illustration than that of large and complex organizations. Solving the strategic challenges of a local dry cleaner will be clearer, simpler and perhaps even more rewarding and entertaining than grappling with a large and complex big business.

I will first develop a baseline business architecture for the dry cleaner, using my own casual acquaintance with the way dry cleaning operates, supplemented by a modicum of web research.  In a real world setting, the business architecture would be driven to far greater levels of detail, undergirded by detailed interview and review by subject matter experts far more qualified than I.  To detail a real architecture, I would examine documents, interview stakeholders and engage in deep discussions about what a dry cleaner does with those who actually perform the work.

Next I’ll posit a strategy for the business, which will lay out some basic objectives and provide a target state against which its initiative can be measured and evaluated.  I then engage in an act of imaginative abstraction involving both the rigorous structure supplied by business architecture and the free play of fantastic potential that modern digital technology represents.  Finally, I will speculate on what a to-be architecture might be, which is necessary to facilitate transformative change to the business model.[6]

Sauber. Like Uber only Cleaner

Sauber[7] is a full service dry cleaner, located on the main highway near the commercial center of the city, but on the opposite side of town from a growing residential area.  It operates a retail store for customers to drop-off, pick-up and pay for their clothing.  In an adjacent property, Sauber operates a laundry that allows it to save costs of outsourcing and provide fast turn-around for clean laundry.

Sauber exists to serve its stakeholders: its customers, owners, investors and employees.  It provides value to these stakeholders through a set of connected activities that produce the item value to the stakeholder, called value streams.  Sauber’s most important stakeholder is the Customer, who receives freshly laundered clothes packaged for immediate use.  The core value stream that provides this value is called simply “Customer Laundry” and it is comprised of stages that encapsulate the activities that must be completed to deliver the customer value.  The value stream for Sauber is probably very similar to other dry cleaners’ and looks simply like this:


Figure 3: Customer Laundry Value Stream

Each of the stages Customer Intake, Clothes Clean and Customer Fulfillment produces value for its own stakeholder (which may be an employee), and each has it its own entry and exit criteria.  Intake, for example, is initiated by the customer stakeholder and the value delivered to the employee stakeholder is wash-able laundry, properly identified and tagged.  Tagging the laundry enables it to transition to the “Clothes Clean” stage.



Each stage requires certain abilities or capacities in order to complete successfully.  In the case of Customer Intake, the business must be able to greet the customer, record her or his name and describe the clothing for dry cleaning, provide a quote and a ready date, bundle the clothes for cleaning and tag the clothing with a number and record that number of a receipt for customer pickup.  Each of these business aptitudes is a capability; “a particular ability or capacity that a business may possess or exchange to achieve a specific purpose or outcome”.[8] In short, capabilities are what the business does.  The capabilities necessary to support each value stage might look like this:·        Clothes Pre-treatment



Figure 4: Value Stages and supporting Capabilities

Each capability can be decomposed into more specific constitutive capabilities; Clothes Tagging, for example, might consist of Tag Printing, Tag Sequence Management, Tag Attachment, Tag Numbering, Tag Matching and the like (not shown).  The level of granularity is dictated by what is necessary to fully articulate what the business does and to fully identify the business objects[9]  that are required for the analysis.

Capabilities act on business objects, which may be tangible (Clothes) or intangible (an Agreement).  The action of capabilities produces a result – an “outcome” – that can be used by other capabilities; for example, Agreement Creation produces an executed Agreement, which becomes a specification for capabilities supporting the “Clean” value stage (“6 shirts – easy on the starch – complete by Thursday the 10th”).

To the degree that the outcome of a capability has a name, it can form part of the essential structure of an information map – another essential business architecture modeling principle.  An information map is comprised of concepts like “shirt” or “jacket” or “pants,” which may be organized hierarchically (“dress shirt” and “causal shirt” are “shirts”) and whose relationship to other concepts can be specified (“casual shirts are not ironed”).  These rudimentary business concepts, which are undoubtedly part of the pricing structure, form a vocabulary that can be later be used to found and validate a database logical schema and drive requirements for data processing (we’ll get to IT / automation alignment and requirements below).



Figure 5: information mapping

We might continue to elaborate the basic architecture of Sauber (or any dry cleaner) by continuing our exploration into information, and from there to organization (which is not the same as an org chart), stakeholder, product, initiative and policy.  Each of these domains brings its own domain concepts (for example, “Product” and “Product Line” from product mapping), and each of these domain concepts maps back to value, capability, information or organization.  Changes in any of the domains can affect the structure of other domains (e.g., changes to the capability map may affect the organization map).  In this way, a complete “blueprint” of the business can be developed, shared and used for a variety of purposes, from investment analyses, to mergers and acquisitions to new product requirements, outsourcing, supply chain, joint venture, compliance and a host of other scenarios.

Location, Location, Location

More immediately, however, we are concerned with how the owners of Sauber might employ technology to address a very fundamental problem in their business.  Because of its location, Sauber is at a competitive disadvantage to other dry cleaners in the city, most of whom are located much closer to customers’ homes.  More importantly, Sauber is losing business as customers move further away from its downtown location.  Sauber is increasingly inconvenient even to the ‘white collar’ office workers whose commutes no longer go past Sauber’s retail storefront.  Retail expansion opportunities into these residential areas is limited, expensive and will be far from Sauber’s laundry, negating the competitive economic advantage that Sauber gains from having its own cleaning capabilities.

Sauber outlines a simple strategy (see Figure 6):  it wants to grow the customer base without growing its retail geographical footprint, and to retain and get more repeat business by keeping more customers longer and by increasing transaction frequency and regularity.  Each of these objectives is decomposable into sub-objectives, which can become ever-more specific.


Figure 6: Simple Strategy Map for Sauber

When the business superimposes these strategy objectives on its existing value and capability map, some interesting insights begin to emerge (see Figure 7).  The “Growth” objective (left) is anchored squarely in the Customer Intake value stream stage – to gain market share and enter new markets without geographic expansion means that the capabilities comprising the Intake stage will need to be examined for innovation possibilities.  The sub-objective of minimizing dependence on geography will happen in this stage, using these capabilities, if at all.

Meanwhile, the “Repeat Business” objective is, by definition, delivered after the Return stage (after the Customer Laundry value stream completes).  Objectives like increased loyalty and incidence will require that we examine what can be done to affect them in either existing value stages, or in an as yet non-existent post-Return stage (the “?” in figure 7).


Figure 7: Insight into Strategically Important Capabilities

We are beginning to know where to look in the architecture for changes to capabilities necessary to accomplish the strategic objectives, but we still lack the detailed insight necessary for transformational change.

An Atlas of the Innovation Landscape

Recall our earlier quote from Charles Owen:

For the creative mind, [abstraction] offers a way to step away from the mundane to find fresh ways to conceptualize… The power to abstract is fundamental to innovation. When ideas are scarce, a fresh viewpoint makes all the difference. [10]

How would we go about ‘stepping away’ from our mundane dry cleaning business and reimagining a basic business model that is nearly 200 years old?[11]  Now that we have an abstract ‘blueprint’ of Sauber’s business (and indeed, of all dry cleaners), how do we solve for its strategic goals leveraging new and emerging digital technology?  How do we take the imaginative leap that allows us to re-conceptualize Sauber’s business as a mid-21st Century dry cleaner?

Business architecture is of direct and instrumental use here [12]

  • First, “value streams have a direct and defined relationship to automations of business processes, case management, user interfaces, and similar business design concepts.”[13] The entire set of activities involved in the delivery of value to stakeholders may be affected by technology.  Value streams provide a framework for envisioning how the business can establish innovative solutions for managing stakeholder interaction and automation to enable a customer’s laundry job to visibly transition across and among value streams.  Value stream analysis becomes a way of assessing how technology might be used to, for example, unite a variety of customer touchpoints –  digital and non-digital – in a way that transforms customer experience from a series of disconnected encounters to a progressively informed conversation concerning the customer’s needs and history as it relates to a given value item.  Business architecture, aligned with a customer experience analysis, shows how the customer story and the business story interlock.  There is much work afoot concerning mapping value streams to the customer journey, which will help us better understand how to align business and customer views.[14]
  • Second, technology instantiates capabilities.[15] Digital transformation is about the extension, enhancement, replacement or creation of capabilities that are involved in the delivery of value. The capability map becomes a focal point assessing application functionality, use cases and services orchestration.   Capabilities can be mapped directly to current state application architecture, which allows a business to determine where a given capability is automated, if it is automated consistently, and what type of strategy should be employed to address these and related challenges.  Where no apparent mapping is found, either no automation exists or the business architect must consider the possibility that shadow systems exist that provide automation.[16]
  • Third, insofar as digital transformation is primarily concerned with digital technology, it directly affects capabilities that use information. The information map, therefore, allows us to identify opportunities for formalizing, codifying and automating heretofore informal or even tacit business knowledge.  Information maps directly to data architecture. Robust, cross-business-unit definitions are important, and information mapping is the foundation of business semantics and basic relationship concepts that equip data architects with concise, agreed-upon building blocks for the data architecture.
  • Finally, the organization map can help us to understand the implications of technological change for the business units and partnerships that constitute the ‘human’ part of the enterprise. Business units deliver capabilities, and changes to either affect the other.


Figure 8: Strategy to Deployment. Source Business Architecture Guild, 2016

The business architecture becomes a sort of atlas for transformation and innovation, mapping out the territory where insight and imagination can explore the art of the possible.  I refer to this as “imaginative abstraction” and it is without a doubt, the most exciting and enjoyable activity one can engage in in business, because it is an act of discovery:

The true method of discovery is like the flight of an aeroplane. It starts from the ground of particular observation; it makes a flight in the thin air of imaginative generalization; and it again lands for renewed observation rendered acute by rational interpretation.[17]

Imagination is essential to the process of discovery involved in digital transformation.  Yet, untethered imagination wastes itself and can, at best, produce utility and even beauty in an accidental and random way.  Business architecture serves a constraint that is necessary for creative imagination and productive innovation.  It is because a business is fettered by a real world that true creativity in solving problems is necessary. The digital transformation practitioner must be knowledgeable of what is possible and feasible technologically, but must also be cognizant of what is required by the business to meet its objectives.  Because business architecture also supports performance management methods, such as the Balanced Scorecard, [18] an organization’s behaviors, results, and success can be measured, reported, and achieved as digital transformation is initiated – providing the kind of discipline necessary to see a transformation initiative through from ideality to reality.

Meanwhile, Back at the Dry Cleaners

To grow its intake funnel, Sauber realizes that the Intake value stage need not be location-bound to a retail store at all.  In the past, fielding all of the calls that might be made and sending out a vehicle for timely way for clothing pick-up would not have been feasible.  The volume of calls would have been too great for a single clerk, resulting in the need for an operator whose time would instead be slack.  Drivers carrying money was deemed risky and open to theft.  Opportunities for error were great and pick-up routes and times would have been wasteful and inefficient.  The Customer Intake value stage was of necessity a location-bound set of activities that required a customer to travel to the retail location.

But today, most, if not all, of Sauber’s customers have a mobile phone.  They can signal the need for a pickup, and transmit their order details without ever leaving home and without involving a human operator in a serial, customer-by-customer telephone conversation.  The capabilities involved – Customer Greeting, Agreement Creation, Clothes Handling, Clothes Tagging and Receipt Issuance can all be conducted digitally in a communication between a mobile app and a server, without the need for a retail presence.  The mobile presence greets the customer by name, allows him or her to specify a pickup order, date and time, see a projected delivery time and add it to their calendar, pre-pay for the order.  A truck with sufficient storage and a free, weather-proof dry cleaning box enables Sauber to conduct Intake at the customer’s home.

Moreover, in re-evaluating the capabilities involved in Customer Intake, we have a clue to transforming the ‘other end’ of the value stream involved in Customer Fulfillment.  The same mobile app can alert customers to the availability of clean laundry (via various notification media) and enable the customer to set a delivery date and time. Furthermore, because customer location and time information can be immediately entered into a constantly updating routing algorithm, Sauber’s driver can receive point-by-point GPS directions, optimized against order priority, drop-off orders and time of day.   Routing algorithms and the orchestration of order creation activities with order fulfillment activities will allow the driver to combine pickup and delivery runs.  This re-imagining at an architectural level is depicted in Figure 9 below.

To increase customer loyalty and order incidence, a new value stream stage may need to be added, which has the purpose of “feeding” the capabilities of other stages with correlations between customer satisfaction and business performance.  A new capability instance – perhaps “Evaluate” – must show up in each of the existing value stages to provide metrics on performance of each of their capabilities.  New organizational business units may be required in order to provide these new capabilities.

If we examine the business architectural implications of all this, we see that once-simple capabilities – Customer Greeting, Agreement Creation, Clothes Tagging and Receipt Issuance – have now become complex and multi-faceted and will be realized as automated machine activities.  In the past, the “signal” of the customer’s desire for dry cleaning was that they showed up at a location.  Now, the customer will initiate the value stream from an app and the Clothes Handling capabilities of the Intake stage will, so to speak, show up at the customer location.  In this way, old capabilities are instantiated in a very new form. The capabilities that are affected by the existence of technology in the new strategy are identified by blue gears in Figure 9.  The ‘internal’ structure of these capabilities, together with the IT and organization systems that own them, are subject to substantial renovation.


Figure 9: transformation options

In some cases, a strategy might call for the construction of entirely new value streams or value stream stages.  For instance, a new value stream stage, “Register Prospect,” may be required to optionally allow the customer to store basic account information (e.g., credit card) and even transmit their pickup location automatically.  They don’t do this today, in the physical retail environment.

The information map, derived from the capability map, can serve as requirements for IT development initiatives, both with regard to the apps that need to be developed and the data model that these apps will be working on.  Indeed, the information map forms a sort of business-led IT development initiative, which traces the entire relational schema design back to the business-developed information map:

The information map is an abstract model of data. A relational schema can be extracted from an information map by the following procedure:

  1. Select a Class that has a business identity (i.e., it corresponds to a Business Entity [i.e., business object])
  2. Identify the attributes of that Class that serve to identify Individuals in the Class – these will become the natural keys
  3. Identify all Roles the selected Class participates in that have 1-1 relationships with the Class and whose target Individuals are lifetime dependent on the existence of Individuals in the selected Class – these will be the columns of the Class.
  4. Identify all other Roles and implement them as foreign key or association tables relationship.

Similar techniques can be used to extract XML schema and RDF schema models from the information map.[19]

Thus, by mapping the key information concepts implicit in the interaction between capabilities (see Figure 9 at bottom), we have a nascent relational schema, subject to development by a skilled DBA but led by the business strategy.  This is an important feature of business architecture – it is a description of the business by the business, and one which “normalizes” all descriptions, even those employed by IT.

The organization map – the final domain belonging to the business architecture core – is to a degree a consequence rather than driver of digital transformation.  Insofar as a capability is realized by a business unit, the business units that own these newly-instantiated capabilities must evaluate changes in their composition and interaction.  The organization map allows us to perform this kind of analysis.  The rough organization map superimposed on the value stream above indicates that much of the retail business unit is dramatically affected by the proposed technology transformation.  Only two business units have any direct involvement in the customer value stream, and only Retail is customer-facing.  The alignment of business units to capabilities is simple and straightforward: Retail has all of the capabilities necessary for Intake and Return, and Laundry handles all of the capabilities necessary to accomplish the Clean value stage.  To the degree that Sauber wishes to hold onto its retail location, staffing may be largely unaffected, but this will ultimately be determined by the success of its digitally renovated form.  The simple organization suits the simple business model currently used by Sauber.

Of course, all of the modifications to capability instances, information concepts and organization maps can be traced back to the strategy map objectives.  This trace-ability is key, for it allows initiatives to be mapped to transformations required in capabilities, information and organization, and measured for budget, timeliness and effectiveness.  The data requirements can be derived from the information map and application functional requirements from the capability map.  In this way, the business can chart a transformational course for itself.

Conclusion: Business Architecture as the Meaning of Digital Transformation

We began this article by asking: what does “digital transformation” mean and how might we set about deliberately to digitally transform a business?  So far as the first part of the question is concerned, there seemed to be as many definitions as there were authors.  For the most part, the term “digital transformation” was ostensible; it was used to point to what the author thought was an instance of the phenomenon.

These ostensive approaches might be helpful in conveying real world examples and case studies, but they do little to help to actually plan a transformation.  Sauber would be hard-pressed to re-imagine its business based on what banks, airlines and shipping companies have done using information technology.  The various white papers, research findings and marketing glossies are merely indicative, rather than providing procedural and systemic knowledge.

Now, with business architecture as a way of understanding transformation, we are at last in a position to answer the questions we posed at the outset.  To begin with, we can offer an intensional definition of digital transformation (i.e., one that states its necessary and sufficient conditions) as follows:

Digital transformation is a modification to business capabilities enabled by digital technology that empowers the business to achieve strategic objectives by means of changes its business model.

This squares with MIT/Deloitte dictum that “strategy, not technology, drives digital transformation”,[20] insofar as it is not technology per se that is transformative, but the impact of technology on the fundamental structure of the business, understood as a collection of value streams enabled by capabilities.  Digital transformation is a species of business transformation.

We have also described a transformation methodology.  It requires an as-is architectural analysis of some depth, relevant to the value streams at issue in the company’s strategic objectives.  It then employs the art of imaginative abstraction, constrained by knowledge of what is technologically possible and feasible and by the objectives that are required by strategy.  Finally, it re-maps capability instances in a digital-technological form and lays the foundation for IT initiatives necessary to carry them out.   The notion is similar to the sketch (from BIZBOK) in Figure 8, which posits a parallel business and IT transformation process.  What is different in the case of digital transformation is that the as-is IT architecture may not even exist (as was the case with Sauber), but may have to be invented as a consequence of the business model change necessary to fulfill strategic objectives.


Figure 10: Business / IT Transformation – TSG, Inc.

Of course, none of this is to suggest that I can offer a “cookbook” for digital transformation.  There is no algorithm for disruption, any more than there is a marketing plan for assuring a viral video.  Nor am I suggesting that Uber, AirBNB and other archetypes of transformation somehow employed a disciplined value stream and capability analysis to arrive where they did. My ambition was simple after all: to point up the need for some kind of shared conceptual framework – an architecture – if we are going to even begin to speak meaningfully and deliberately about digital transformation.  I hope I have had some success in this.



[1] The Business Dictionary defines transformation as “transformation implies a basic change of character and little or no resemblance with the past configuration or structure.”  (  More generally, many dictionaries define it as “a complete change in the appearance or character of something or someone” (see, e.g., or ).

[2] As practiced by the Business Architecture Guild See

[3] See:

[4] See:

[5] The core elements or “domains” used by business architects in the analysis of a business are: value, capability, information and organization.  Each is described below in some detail.

  • Value is a benefit derived by a stakeholder interacting with the business.[5] A stakeholder, in turn is an internal or external individual or organization with a vested interest in achieving value in interaction with the business.[5]   A customer is clearly a stakeholder, but so too is a partner, a supplier, an investor or a regulator.  A business exists to provide value to stakeholders and has no other reason to exist.  Value is provided by a business in a series of activities that can be represented as stages or steps in a “value stream.”  Thus, while a taxi customer is seeking satisfaction in the form of safe, rapid and affordable transport to her destination, it occurs in “value stages” involving hailing the cab, passenger pick-up, passenger transport, passenger drop-off and passenger payment.
  • A capability is what a business does to produce and provide value; it is an ability or capacity that a business may possess or exchange to provide a particular outcome or purpose.[5] Capabilities are expressed as compound nouns comprised of a business object and one or more adjunct nouns that modifies it: Customer Communications, Trade Surveillance, Account Reconciliation, Package Shipment, Insurance Claim Management are examples of capabilities.  Capabilities can be decomposed or analyzed into constituent capabilities.  Thus “Account Management” might be comprised of “Account Acquisition,” “Account Information Management,” “Account Contact Management,” “Account Matching,” “Account Extinguishment” and the like.  Capabilities may exist in many different business units and in many forms across a company, but are defined only once for the entire business, and the business has only one “capability map” that describes the entirety of its capacities necessary for delivering value.
  • Information is data and a context for its interpretation, and in business architecture is comprised of concepts that represent both tangible and intangible business objects like a “loan,” “automobile,” “customer,” “product,” “location,” “account,” “policy” and the like. An information map shows these concepts in their interrelationship with one another and with capabilities, which create, modify, use and destroy information.  Information representing a business object can be traced through its interactions with capabilities along a value stream.
  • Finally, an organization is social unit of people, systematically structured and managed to meet a need or to pursue collective goals on a continuing basis.[5] An organization is comprised of business units, which are formal or informal collections of people organized around a specific purpose, and which constitute a business capability.  The standard business “org chart” is one way of mapping an organization along lines of command and control, but this form of organization map is not the exclusive or even the most effective way or representing an organization.  It is often more effective, for purposes of assembling a business architecture, to represent business units in relation to the capabilities they possess – this will often bring in extra-enterprise business units such as trading partners, suppliers, consultants and the like.

Business architecture is extended by strategy, initiative, stakeholder, product and other non-core concepts, but each of these maps back to the above “core” elements, and so provides a richer understanding of transformational change.   Business architecture is also “aligned” with various other enterprise and IT architectural practices, such as Lean Six Sigma, Case Management, Software Development Life Cycle, TOGAF and the like.  The actual elaboration of business architecture consumes well over 600 pages and many dozens of related presentations, which tell the story of how the architecture relates to strategy, business model creation and business process modeling, and how it can be used to align to IT strategy and IT transformation initiatives, case management and other business disciplines.

[6] I use the phrase “business model” throughout this article, but never elaborate on its use or meaning.  I have in mind Osterwalder’s famous “business model canvas” (, which has been influential in normalizing descriptions of the elements that comprise a business model and exploring their dynamics.  In fact, the business architecture literature makes extensive reference to the business model canvas and the set of relationships at work.  An original version of this article got overly complex in trying to integrate business model concepts into an already lengthy text.  So, despite the fact that it is a core concept, I merely allude to it without elaboration.  I hope to make up for this in a future article.

[7] German for “clean,” whereas Uber is German for “above” or “over.”

[8] 1 Ulrich Homann, “A Business-Oriented Foundation for Service Orientation”, Feb. 2006, .

[9] Business objects are tangible or intangible entities (e.g., Agreement, Shipment, Palette …) that the business uses or processes.

[10] “The Power of Abstraction” 2009, The Business Process Management Institute.


[12] Business Architecture Guild, A Guide to the Business Architecture Body of Knowledge® version 5.1. p. 415.  Hereinafter “BIZBOK”.  BIZBOK states:

  • Business architecture has a direct, unambiguous relationship to IT architecture.
  • Business capabilities have a direct and defined relationship to applications and deployable business services.
  • Value streams have a direct and defined relationship to automations of business processes, case management, user interfaces, and similar business design concepts.
  • Information concepts have a direct and defined relationship to data definitions within the data architecture.

[13] Business Architecture Guild, A Guide to the Business Architecture Body of Knowledge® version 5.1, Page 416. Hereinafter “BIZBOK”.

[14] See:

[15] Think of a capability like “Customer Complaint Receipt” – in the old days (when I was manning a customer service phone), this meant a human being taking calls as they came in and trying to discern the nature of the complaint and the appropriate hand-off.  The capability was embodied in a human and each human was an instance of the capability.  For better or worse, advances in phone technology have enabled diagnostics and even service to be automated, vastly decreasing the costs of this capability and (because of scale) increasing customer satisfaction (one no longer stays on hold waiting for a human being).

[16] BIZBOK, page 470

[17] A.N. Whitehead, Process and Reality: An Essay in Cosmology (1929).  We prefer “abstraction” to Whitehead’s “generalization,” but they are essential synonymous in this context.

[18] The concept was initially introduced by Robert Kaplan and David Norton in a Harvard Business Review article in 1992 and has since then been voted one of the most influential business ideas of the past 75 years.

[19] BIZBOK page 470.

[20] See the report of the same name, subtitled “FINDINGS FROM THE 2015 DIGITAL BUSINESS GLOBAL EXECUTIVE STUDY AND RESEARCH PROJECT”, Published in Summer of 2015 by MIT Sloan and Deloitte University Press.

No comments

Leave a Reply

Your email address will not be published. Required fields are marked *