The Skeptical Architect – February 2013

Today’s businesses are being assaulted by various architectural perspectives having different meanings. For example, let’s take a look at some of the common terms being used: enterprise architecture, business architecture, process architecture, data architecture, systems architecture, application architecture…on and on. With various architecture names, all purporting to represent the business in some fashion, it looks like we are descending into a naming chaos – another tower of Babel, with everyone claiming to have the one and only true architecture approach. Yet none of these can be used for much more than defining requirements for systems or aligning the business with systems. Artifacts for the architectures look like typical IT-based architectures with “Use Case” and “UML diagrams” that most users don’t understand nor want to work with. How can we bring some order the chaos of architecture today?

There are several key issues to deal with:

  1. There are a number of architectures we must deal with today and the names are confusing especially to management.
  2. Three of these are families of architectures:
    1. Enterprise IT Architecture (the IT view of the world supported by the TOGAF proponents and based on IT architecture concepts)
    2. Business Architecture (the alignment view of the world supported by the Business Architecture Guild)
    3. Strategic Business Architecture (the business view of the world, quietly used for many years by business consulting firms and linked to quantitative and financial techniques for business analysis, but with no formal name for the approach)
  3. The families overlap in order to get some form of linkage and transformation capability.
  4. Only Strategic Business Architecture uses quantitative and semantic-based analytics to provide insight into various structural business changes.
  5. Above all…all three families are needed and used for different reasons.

Architecture EvolutionWhy are these three families so important to business strategy and opportunities? They address key architecture issues of interoperability and completeness from 3 different business perspectives:

Enterprise IT Architecture: The enterprise IT architecture is the linchpin of the “digital enterprise” transformation. Since the CASE tool era, engineering of IT solutions is recognized as required to produce high-quality, robust, scalable, and adaptable implementations that will sustain business growth and opportunities supporting enterprise strategic direction. The main purpose of enterprise IT architecture is to produce reliable requirements that lead to high quality applications. For a successful enterprise, IT architecture must connect with the business components and their relationships.

The key components of the business traditionally are strategies, functions, and a limited view of organizations, locations, documents, processes and sometimes process risk. This limited view is often called a ‘sliver’ of the enterprise structure. Each of these components has architecture within itself and also has an architecture that links them to other components especially the IT architecture components of systems, databases, communications and platforms.

Business Architecture: The use of the term business architecture is focused on the alignment of the digital part of the enterprise with the business operation. Alignment has been an issue with IT support for as long as IT has existed and will continue to be an issue in the future. How it is dealt with may change, but the issue will stay. A common thread of the business architecture and that of the enterprise IT architecture is the focus on the enterprise’s resources on business transformation and aligning IT to match the need of that transformation.

Business architecture represents a tighter link of the IT view into the strategic business view. Added business components are used here both in type and scope. This has been emphasized in Information Systems Transformation: Architecture-Driven Modernization Case Studies by William M. Ulrich and Philip H. Newcomb.1 They state: “architecture-driven modernization can play a strategic role in building a more agile, more competitive enterprise in the face of increasing internal and external pressures and demands.” The significance is that executives are beginning to understand the criticality of systems for the continuity and survivability of the enterprise. It is of great concern that understanding the digital underpinnings of the organization is largely a mystery to management and planning teams. Building and maintaining business architecture provides the opportunity to see the implications and impact across the business.

Strategic Business Architecture: Finally, the Strategic Business Architecture represents the foundation for the business structure needed to support the courses of action that the enterprise pursues with respect to its markets, customers, clients, citizens or victims. The goals, objectives, markets, products, services, organizations, decisions, locations, risks, policies, procedures, systems, rules, documents, applications, databases, platforms, and a number of other components are enumerated across the enterprise that relate to and identify the initiatives that the enterprise will focus on over some timeframe. The strategic business architecture often contains from 25 to 50 different categories of components that span the enterprise.

The primary use of strategic business architecture is a complete picture of the enterprise that can be used for analytics relating to consolidation, merger, acquisition, divestiture, disposal, restructuring due to product, service, and market changes and other strategic changes the enterprise may take.

Analytics provide for impact analysis needed by Business Architecture and Enterprise IT Architecture. So, all three perspectives are really needed to execute change in an enterprise. The goal is to understand the business change, the impact on the transformation effort and the development of requirements that eventually result in digitized parts of the enterprise.

Models that represent all three architecture families use descriptions and relationships among the descriptions. These descriptions and the quantitative assessments that go with related models, provide the basis for execution, transformations, and digitization in the enterprise to sustain growth and opportunities. Using descriptive analytics, it provides the structural analysis of various architectural components.

Taxonomy of ArchitecturesThis leads to a possible taxonomy of architecture types that may overlap in part or completely by all three architecture perspectives. Here is a starter structure of architectures that belong to each architecture family:

  1. Strategic and Operational Business (what the business talks about) requires models that describe the following:
    1. Direction architecture (strategy, objectives, missions, goals, the direction of the business)
    2. Risk architecture (structure from enterprise level to process steps)
    3. Knowledge architecture (the intellectual property of the business)
    4. Business market architecture (the target consumers/markets)
    5. Product architecture (what products and services are offered to the market)
    6. Process/operational architecture (how products and services are delivered to the market)
      1. Functional decomposition of process (3 types)
      2. Process flow models (7 types)
      3. Matrices of process interaction
    7. Performance architecture with measures, results and excellence components (how well the enterprise did based on monetary results indicators)
    8. Business technology architecture
    9. Business environment architecture (outside the business)
      1. Legislative (linkage of political and legislative actions)
      2. Market (overall market structure)
      3. Technology linkages
      4. Social structure
      5. Economic structure
    10. Interaction architectures – matrices that relate the various architectures together from a high-level view to more detailed-level views
    11. Other business components that may be described as part of other architectures like:
      i.    Documents
      ii.    Locations
      iii.    Decisions
      iv.    Rules
      v.    Polices
      vi.    Procedures
      vii.    Skills
  2. Business Alignment to IT (what the Business Architecture Guild proposes and calls business architecture) requires models that describe the following:
    1. Target strategic business architecture components (subset of the strategic business view related and focused on transformation)
    2. Target enterprise IT architecture components (the digital part of the business)
    3. As-Is and To-Be architectures for components involved in the transformation and alignment.
  3. Enterprise IT Architecture (what the current IT view is) requires models that describe the following:
    1. Information/data architecture (who is really doing this today?)
    2. System/application architecture
    3. Infrastructure/digital Technology
    4. Communications architecture
    5. Process architecture
    6. Business Rules architecture
    7. Parts of the strategic business architecture such as process models and strategies
  4. As part of competitive intelligence, the competitive analysis of existing competing company architecture and business models especially as it relates to target markets.

What Does It All Mean?Given this taxonomy scenario, which can be quite large, organizations may not be able to implement an infrastructure that supports all of the various architecture types and the large number of models needed. The good news is that they can be built incrementally and integrate as parts become available. To do this a methodology and framework is needed that links the components together. This means architecture and execution implementations can be scaled with the growth and need of the enterprise.

Using the above starter taxonomy framework of architecture types, stakeholders would be on the same page and properly aligned to make the structural changes, business transformations, and digitization actions that are required. For best use, the taxonomy framework is storing and analyzing the architecture in a “repository” that centralizes this information for an enterprise such as depicted below.

Because of overlapping architectures and models, these architecture families are intertwined and must be explicitly defined, analyzed, and communicated throughout the organization. Our position is that semantic-based and quantitative architectures are so tightly coupled that without sufficient analysis insight, decision making and the implementation that follows may be haphazard, costly, and even detrimental to the long-term goals and objectives sought.

The reality is that analysis before a strategic change is often not complete. There have been plenty of rationalizations following a major strategic change that justify a poor decision. Among them are the favorites such as “increasing shareholder value” used both when the strategic change is announced and several years later when it is undone. Also, “the markets, financials and legal aspect were in line for the acquisition or merger, the operations and culture did not fit.” One of the favorites is “we know these markets and businesses so added analysis is not needed.” The number of failed mergers, acquisitions and consolidation are evidence of the limited analysis problem. The solution is to improve the analysis with tools, analytics and methods that provide better decision input. Architectures, especially strategic business architecture, are one of the key components of the solution. This will help limit the after the fact insight that a particular strategic change was not a good idea.

End Note:

  1. Ulrich, William M. & Newcomb, Philip H, Information Systems Transformation: Architecture-Driven Modernization Case Studies, Morgan Kaufmann OMG Press, Burlington, MA. 2010

Share this post

Gil Laware

Gil Laware

Gil Laware is President/CEO of Information By Design, LLC, a firm who delivers consultative solutions for strategic, tactical, and operational management of organizations. He has over 30 years of consulting and industry experience with Fortune 50 companies He has experience in manufacturing, transportation, government, finance and banking services including business and IT strategic planning; business process management, redesign and improvement; data management; warehousing and business intelligence; enterprise resource planning; project management; manufacturing systems; and customer relationship management. Previously, he was an Associate Professor of Computer and Information Technology in the College of Technology at Purdue University, an Associate Director for Fujitsu Consulting, Manager of Data Services for Whirlpool Corporation, Vice President of Information Services for Franklin Savings Bank, held various managerial and consultative roles with the IBM Corporation, and was President of Management Support Systems. He also provides training internationally. Gil published with TDAN.com and has authored over 30 papers including a NIST chapter that discusses the gaps that exist in the manufacturing systems software development process. He served the DAMA International Education and Research Foundation (DAMAF). He may be contacted by email at gwlaware@ibd-us.com.

scroll to top