Tag: enterprise architecture

Categories
Business Strategy Research Strategy Technology Technology Strategy

Beyond Build vs Buy: A Multi-Layer Technology Sourcing and Governance Decision Model under Strategic, Economic, and Uncertainty Constraints

Thesis Draft

Author: Yannick Huchard

Date: 29 April 2026

Discipline: Technology Strategy / Information Systems / Enterprise Architecture

Abstract

This thesis develops a technology sourcing and governance decision model that extends the classical build-versus-buy dilemma into a broader, more realistic decision space. In contemporary enterprises, technology leaders no longer choose only between internal development and external acquisition. They also decide whether to rent capabilities as services, partner for co-development, reuse existing assets, compose modular ecosystems, or accelerate implementation through AI-assisted engineering. Existing frameworks often remain binary, heuristic, or narrowly cost-centric, making them insufficient for digital, regulated, and innovation-intensive environments. This thesis proposes a multi-layer decision model that separates governance alternatives from implementation modes. Governance alternatives include Build, Buy, Rent, and Partner. Implementation modes include Reuse, Compose, Generate, and conventional custom development. The model evaluates alternatives across nine dimensions: strategic value, internal capability, externalization capability, technology maturity and accessibility, economic attractiveness, control/compliance/sovereignty, risk exposure, flexibility/reversibility, and option value under uncertainty. The thesis integrates transaction cost economics, the resource-based view, dynamic capabilities, real options reasoning, and multicriteria decision-making into one coherent framework. It argues that technology sourcing should be treated not merely as a procurement or engineering choice, but as a capital allocation decision over future capabilities, control positions, learning trajectories, and strategic optionality. In addition to the conceptual model, the thesis provides a scoring system, gating rules, measurement constructs, and an empirical validation design suitable for expert calibration and multi-case analysis.

Keywords: technology sourcing; build versus buy; IT outsourcing; governance; dynamic capabilities; real options; platform strategy; multicriteria decision-making.

Table of Contents

Chapter 1. Introduction

The build-versus-buy decision has long been one of the most persistent questions in technology management. In its classical form, the dilemma appears simple: should an organization develop a capability internally or obtain it through the market? That formulation remains useful as a starting point, yet it no longer captures the full reality of contemporary technology governance.

Modern enterprises operate in a decision space shaped by cloud platforms, modular ecosystems, software-as-a-service, platform-as-a-service, open-source infrastructure, strategic partnerships, managed services, and AI-assisted engineering. In this environment, leaders do not decide only whether to build or buy. They decide what they must control, what they should learn, what can remain reversible, what can be standardized, and what should become part of the organization’s enduring capability base.

The central argument of this thesis is that technology sourcing decisions should be understood as governance choices over future capability ownership, dependence, learning, optionality, and value capture. A sourcing decision does not only determine how a capability will be obtained. It determines what the firm will know, what it will govern, what it will outsource, what it can later change, and where it will sit in a broader ecosystem of technology providers and partners.

This thesis therefore proposes a multi-layer technology sourcing and governance decision model. The model extends the traditional binary by introducing four governance alternatives—Build, Buy, Rent, and Partner—and by treating Reuse, Compose, Generate, and Custom Develop as implementation modes that can exist across those governance forms. The resulting framework is intended to be both theoretically grounded and practically usable.

The work contributes in four main ways. First, it updates the conceptual vocabulary of sourcing. Second, it separates governance choice from implementation logic. Third, it makes flexibility and reversibility central rather than secondary. Fourth, it provides a research-ready operational structure capable of calibration, testing, and application in executive decision contexts.

1.1 Research Problem

Organizations increasingly make technology sourcing decisions under strategic pressure, regulatory constraint, technological turbulence, and uneven internal capability. Yet the frameworks used to guide those decisions often remain narrow, local, and heuristic. Many organizations still rely on informal judgments, isolated business cases, or cost-led reasoning that underweights control, risk, learning, and optionality.

The research problem addressed in this thesis is therefore the lack of an integrated, rigorous, and operationally usable model for selecting among modern technology sourcing and governance alternatives.

1.2 Research Question and Objectives

The core research question is: how should organizations evaluate and choose among Build, Buy, Rent, and Partner alternatives when sourcing technology capabilities under strategic, economic, regulatory, and uncertainty constraints?

  • reconceptualize build-versus-buy as a broader technology sourcing and governance problem;
  • distinguish governance alternatives from implementation modes;
  • identify the constructs that materially shape sourcing decisions;
  • operationalize those constructs into a scoring and decision model;
  • define a robust empirical validation pathway for the proposed model.

Chapter 2. Literature Review

2.1 Scope of the Review

This literature review draws from five major streams: make-or-buy and boundary-of-the-firm theory, information systems outsourcing, the resource-based view and dynamic capabilities, real options reasoning, and multicriteria decision-making. The purpose of the review is not merely to summarize these streams, but to show why none of them, in isolation, fully explains the modern sourcing decision.

The review demonstrates that technology sourcing is now a hybrid problem. It is simultaneously a governance problem, a strategic capability problem, a risk problem, a flexibility problem, and a decision-structuring problem. This multi-dimensionality explains why a more integrated model is necessary.

2.2 Historical Evolution of Make-or-Buy

The make-or-buy question originates in the broader economic problem of firm boundaries. Coase explained the existence of firms through the comparative costs of using markets versus organizing activities internally. Williamson later expanded this logic by emphasizing transaction costs, asset specificity, uncertainty, and governance hazards.

In operations and manufacturing, make-or-buy was associated with cost structures, quality control, supply dependence, and vertical integration. In strategic management, it became linked to the protection of core competences and the preservation of competitive advantage. In information systems, the problem evolved into decisions over outsourcing, application development, infrastructure management, and technology services.

What has changed most in recent decades is not simply the number of sourcing options, but the nature of what is being sourced. Organizations now source embedded expertise, operational maturity, innovation velocity, elasticity, compliance support, ecosystem access, and in some cases signaling value through association with technology leaders. This widening of the sourced object is central to the present thesis.

2.3 Information Systems Outsourcing

The information systems outsourcing literature provides the most direct foundation for this thesis. It has shown that outsourcing decisions are shaped not only by cost, but also by strategic importance, measurement difficulty, skill availability, governance quality, partnership structures, and outcome uncertainty.

Dibbern and colleagues demonstrated that IS outsourcing research had already become a complex, multi-stage field involving decision, transition, governance, and outcome phases. Later reviews by Lacity, Khan, Willcocks, and others further clarified that the field could not be explained by a single theory and that outsourcing outcomes depended strongly on client capability, vendor governance, and contextual factors.

This literature is especially important because it makes clear that externalization is not passive. Successful buying, renting, or partnering requires organizational ability to specify, select, negotiate, integrate, govern, monitor, and exit external arrangements. That insight directly informs the construct of Procurement and Externalization Capability in this thesis.

2.4 Transaction Cost Economics

Transaction cost economics remains one of the most influential foundations for sourcing research. It explains governance choices by comparing the hazards and costs associated with market exchange and internal coordination. Asset specificity, uncertainty, measurement difficulty, and opportunism are central variables.

In technology contexts, transaction cost economics is highly relevant whenever a capability is difficult to contract for completely, highly interdependent with internal processes, subject to future adaptation, or exposed to significant dependency risk. It helps explain why some capabilities should remain internal even when external markets appear efficient.

At the same time, transaction cost economics is limited when the sourcing decision is driven by learning, strategic differentiation, or long-term capability accumulation rather than purely governance efficiency. This is one reason why the present thesis integrates it with other perspectives.

2.5 Resource-Based View and Dynamic Capabilities

The resource-based view shifts attention from governance hazards to value creation. It suggests that firms should protect and cultivate resources and capabilities that are valuable, rare, difficult to imitate, and difficult to substitute. In technology management, this implies that some software, data, orchestration, and algorithmic capabilities should not be treated as ordinary procurement items.

Dynamic capabilities extend this perspective by emphasizing the capacity to sense opportunities, seize them, and reconfigure assets over time. This is highly relevant for sourcing because the attractiveness of Build, Buy, Rent, or Partner is rarely stable. Technology standards mature, providers change, regulatory conditions evolve, and internal capabilities improve or decay.

Together, these perspectives support two key ideas in the thesis: first, strategic value and knowledge accumulation matter materially to sourcing; second, sourcing decisions must include reassessment logic rather than assuming permanent optimality.

2.6 Real Options and Decision Structuring

Real options reasoning contributes the idea that flexibility has economic value. Under uncertainty, the ability to defer, stage, switch, expand, contract, or exit may be worth more than apparent short-term cost advantages. This logic is especially important in fast-moving domains such as AI, cloud services, and digital platforms.

The multicriteria decision-making literature contributes methodologically. It demonstrates that heterogeneous criteria can be structured, weighted, and compared systematically rather than left to informal executive judgment alone. Approaches such as AHP and TOPSIS are especially relevant because they make trade-offs explicit while still allowing hard constraints to override compensatory scoring.

Taken together, the literature points toward a sourcing model that must be multi-theoretical, multi-layered, and operationally explicit. That is the role of the model developed in this thesis.

Chapter 3. Theoretical Foundations and Research Gap

3.1 Integrated Theoretical Position

This thesis adopts an explicitly integrative theoretical position. Transaction cost economics explains governance hazards and dependency. The resource-based view explains strategic value and the protection of capability advantage. Dynamic capabilities explain reassessment, adaptation, and reconfiguration. Real options explain the value of reversibility and delayed commitment. Multicriteria decision-making explains how such dimensions can be structured into a usable decision artifact.

The research gap emerges from the fact that existing frameworks either remain too binary, too heuristic, or too fragmented across these theoretical traditions. Many models explain part of the sourcing problem well, but few integrate the full modern decision space in a structured way.

3.2 Identified Gaps

  • the dominant vocabulary remains too narrow: Build and Buy are no longer sufficient to describe the decision space;
  • governance choice and implementation logic are often conflated;
  • flexibility, reversibility, and option value remain under-modeled;
  • externalization capability is rarely treated as a strategic organizational capability in its own right;
  • dynamic reassessment is insufficiently represented in most sourcing frameworks.

The thesis responds to these gaps by proposing a multi-layer technology sourcing and governance decision model that is conceptually clear, empirically operationalizable, and directly relevant to executive technology governance.

Chapter 4. Conceptual Model Development

4.1 Model Architecture

The proposed model is structured in four layers: a pre-decision layer, a strategic qualification layer, an evaluation layer, and a decision-and-reassessment layer.

The pre-decision layer asks whether the problem requires a fresh sourcing decision at all. It applies a reuse-first logic and checks whether the requirement can be met through governed extension of existing assets.

The strategic qualification layer classifies the capability according to strategic profile and lifecycle profile. The evaluation layer scores the capability across the core constructs of the model. The decision layer applies gating rules, calculates alternative utilities, ranks governance alternatives, and specifies future reassessment triggers.

4.2 Governance Alternatives

Build

the organization develops and retains primary governance over the capability, including architecture, prioritization, and often operations.

Buy

the organization acquires a product or licensed solution as the core source of the capability.

Rent

the organization accesses the capability as a service, subscription, utility, or managed operational arrangement.

Partner

the organization co-develops, co-governs, or strategically aligns with an external actor in a more relational form than ordinary procurement.

4.3 Implementation Modes

Reuse

leveraging existing internal or governed external assets before creating or sourcing anew.

Compose

assembling the capability from modular services, APIs, or components.

Generate

using AI-assisted software engineering or agentic development to accelerate creation, integration, or adaptation.

Custom Develop

bespoke development without strong dependence on an existing governed base.

4.4 Strategic and Lifecycle Qualification

The model classifies capabilities by strategic profile: Commodity, Differentiating, Core, or Disruptive. Commodity capabilities typically bias toward Buy or Rent. Core and Disruptive capabilities increase the relative attractiveness of Build or carefully governed Partner arrangements.

Capabilities are also classified by lifecycle profile: Disposable, Transitional, or Enduring. Disposable capabilities may rationally privilege speed and optionality. Enduring capabilities require stronger attention to evolvability, control, and long-term operating logic.

4.5 Formal Propositions

P1. Higher Strategic Value increases the relative attractiveness of Build and strategically aligned Partner arrangements.

P2. Higher Internal Capability increases the feasibility and attractiveness of Build.

P3. Higher Procurement and Externalization Capability increases the attractiveness of Buy, Rent, and Partner.

P4. Higher Technology Maturity and Accessibility increases the attractiveness of Buy and Rent.

P5. Higher Control, Compliance, and Sovereignty requirements increase the attractiveness of Build and constrained Partner structures.

P6. Higher Risk Exposure decreases the attractiveness of the affected option.

P7. Higher Flexibility and Reversibility increase the attractiveness of Rent and many Partner arrangements.

P8. Higher Option Value under uncertainty increases the attractiveness of Rent and, in some cases, Partner.

P9. Greater Reuse Availability reduces the likelihood of Build-from-scratch across all governance forms.

P10. The relationship between Strategic Value and preferred governance alternative is moderated by Internal Capability, Technology Maturity, and Control requirements.

Chapter 5. Construct Definitions and Operationalization

This chapter formalizes the constructs that support the model. The intent is to make the framework research-ready and decision-ready. Not all variables are treated as reflective latent constructs. Several are better modeled as composite indices built from heterogeneous but decision-relevant components.

Strategic Value

Definition: the extent to which a capability contributes to competitive advantage, differentiation, innovation potential, and valuable knowledge accumulation.

Indicative dimensions: Core Strategic Relevance; Differentiation Contribution; Innovation Potential; Knowledge Accumulation Value.

Expected directional effect: higher levels generally strengthen the attractiveness of Build and Partner.

Internal Capability

Definition: the organization’s ability to design, build, deliver, govern, and operate the capability internally over time.

Indicative dimensions: Engineering Expertise; Domain Expertise; Delivery Maturity; Human Bandwidth; Operational Capability.

Expected directional effect: higher levels generally strengthen the attractiveness of Build.

Procurement and Externalization Capability

Definition: the organization’s ability to identify, assess, contract, integrate, govern, monitor, and exit external sourcing arrangements.

Indicative dimensions: RFP Maturity; Contracting Capability; Vendor Governance; SLA Management; Integration Capability; Exit Management Capability.

Expected directional effect: higher levels generally strengthen the attractiveness of Buy, Rent, and Partner.

Technology Maturity and Accessibility

Definition: the degree to which the technology domain is standardized, tooled, supported, and practically accessible.

Indicative dimensions: Standards Maturity; Tooling Maturity; Talent Availability; Ecosystem Maturity; Technology Accessibility.

Expected directional effect: higher levels generally strengthen the attractiveness of Buy and Rent, and secondarily Build feasibility.

Economic Attractiveness

Definition: the overall economic desirability of an alternative across initial cost, medium-term cost, change cost, and time-to-value.

Indicative dimensions: Initial Cost Attractiveness; TCO Attractiveness; Cost of Evolution Attractiveness; Time-to-Value Attractiveness.

Expected directional effect: higher levels generally strengthen the attractiveness of Context dependent.

Control, Compliance, and Sovereignty

Definition: the degree to which the capability requires internal authority over roadmap, operations, data, compliance execution, and jurisdictional assurance.

Indicative dimensions: Data Sensitivity; Regulatory Burden; Roadmap Control Need; Operational Control Need; Sovereignty Requirement.

Expected directional effect: higher levels generally strengthen the attractiveness of Build and constrained Partner.

Risk Exposure

Definition: the level of vulnerability associated with a governance option, including vendor, geopolitical, cyber, legal, dependency, and immaturity risk.

Indicative dimensions: Vendor Fragility; Geopolitical Risk; Security Risk; Legal/Compliance Risk; Dependency Risk; Immaturity/Beta Risk.

Expected directional effect: higher levels generally strengthen the attractiveness of Penalizes the exposed option.

Flexibility and Reversibility

Definition: the degree to which the arrangement allows adaptation, switching, scaling, exit, or reconfiguration without excessive disruption.

Indicative dimensions: Ease of Exit; Portability; Modularity; Switching Cost Attractiveness; Scalability Elasticity; Update Velocity.

Expected directional effect: higher levels generally strengthen the attractiveness of Rent and Partner.

Option Value

Definition: the strategic and economic value of preserving future choice under uncertainty.

Indicative dimensions: Technology Uncertainty; Demand Uncertainty; Innovation Velocity; Exit/Change Strategic Value.

Expected directional effect: higher levels generally strengthen the attractiveness of Rent and selected Partner arrangements.

Collaboration Fit

Definition: the extent to which a co-development or co-governance arrangement is strategically, operationally, and relationally viable.

Indicative dimensions: Co-development Willingness; Strategic Alignment; Shared Governance Feasibility; Acceptability of Value and IP Sharing.

Expected directional effect: higher levels generally strengthen the attractiveness of Partner.

5.1 Measurement and Normalization

Judgment-based items are measured on a 1–7 Likert-type scale and normalized to a 0–100 scale. Objective variables such as cost or expected implementation duration can also be normalized to 0–100 through a desirability or min–max transformation.

The generic normalization formula for 1–7 items is shown below.

xₙ = ((x − 1) / 6) × 100

Dimension scores are calculated as arithmetic means unless a context-specific weighting of sub-dimensions is explicitly justified.

5.2 Contextual Variables

The model also includes contextual variables that influence interpretation and gating: Strategic Profile, Lifecycle Profile, Time Criticality, Mandatory Sovereignty Constraint, Reuse Availability, Trigger Exposure, and Brand Leverage Potential.

Chapter 6. Scoring Model and Decision Logic

6.1 Pre-Decision Rule

The model begins with a mandatory principle: Reuse before Try before Build, Buy, Rent, or Partner. If a reusable governed asset already satisfies the need above a defined threshold, the decision should be reframed around reuse or extension before greenfield sourcing is considered.

6.2 Gating Rules

  • If sovereignty is mandatory and an external arrangement cannot satisfy jurisdictional requirements, the incompatible Rent or Buy option is disqualified.
  • If internal capability is below a minimum threshold and time criticality is extreme, Build may be disqualified.
  • If vendor fragility, geopolitical exposure, or compliance incompatibility exceed tolerance, the affected external option is disqualified.
  • If lifecycle intent is disposable and strategic value is low, heavy Build should generally be discouraged unless explicit learning value is high.

6.3 Illustrative Utility Logic

Build Utility

U(Build) = 0.24·SVS + 0.22·ICS + 0.16·CCSS + 0.10·TMAS + 0.08·FRS + 0.10·(100−PECS) + 0.10·(100−EASext)

Buy Utility

U(Buy) = 0.18·(100−SVS) + 0.18·PECS + 0.15·TMAS + 0.20·EAS + 0.10·(100−CCSS) + 0.10·(100−RES) + 0.09·FRS

Rent Utility

U(Rent) = 0.14·PECS + 0.14·TMAS + 0.16·EAS + 0.18·FRS + 0.18·OVS + 0.10·(100−CCSS) + 0.10·(100−RES)

Partner Utility

U(Partner) = 0.20·SVS + 0.10·ICS + 0.18·PECS + 0.12·TMAS + 0.10·EAS + 0.12·FRS + 0.18·CFS

These utility functions are thesis-draft formulas intended for calibration rather than universal fixed weights. In a full empirical phase, weights should be calibrated through AHP or a comparable structured expert procedure.

6.4 Decision Outputs

  • primary recommendation;
  • secondary recommendation;
  • disqualified alternatives and reasons;
  • dominant decision drivers;
  • confidence score based on the gap between the top two options;
  • robustness score based on sensitivity analysis;
  • review interval and reassessment triggers.

Chapter 7. Research Methodology

This thesis adopts a pragmatic, abductive, and design-oriented methodology. It combines conceptual theory building with the design of a decision artifact and a future empirical validation pathway. A purely positivist approach would be too narrow because several constructs depend on structured executive judgment. A purely interpretivist approach would be insufficient because the thesis aims to produce a formalizable, reproducible decision model.

The methodology is therefore hybrid. It starts from theory, learns from practical decision realities, and culminates in an artifact capable of calibration and testing. This is appropriate for a problem that is simultaneously explanatory, normative, and decision-support oriented.

7.1 Research Design

  • Phase 1: conceptual development of the model from literature synthesis and structured practitioner reasoning;
  • Phase 2: construct refinement and content validation through expert review and Delphi-style convergence;
  • Phase 3: weight calibration using AHP and structured pairwise comparison;
  • Phase 4: empirical application and validation using retrospective and comparative sourcing cases.

7.2 Unit of Analysis

The primary unit of analysis is the technology capability sourcing decision. This may be a customer identity platform, fraud engine, claims workflow, reporting engine, pricing engine, AI assistant, integration layer, or other bounded capability. This unit is appropriate because sourcing decisions are often made at capability level and may differ materially within the same organization.

7.3 Measurement Design

The model combines objective indicators, structured ratings, composite indices, and contextual qualifiers. Content validity is strengthened through literature grounding and expert review. Because multiple evaluators may apply the model to the same case, inter-rater reliability and evaluator training are important.

7.4 Validation Logic

A full empirical validation should include content validity, face validity, inter-rater consistency, sensitivity analysis, and multiple-case comparison. The model’s recommendation should be compared not only with historical decisions, but also with observed post-decision outcomes, because a mismatch may indicate that the original organizational choice was itself weak.

Chapter 8. Empirical Validation Design

The empirical validation design is phased and cumulative. It begins with expert validation of constructs and decision logic, proceeds to weight calibration, and culminates in case-based application and cross-case comparison.

The purpose of validation is not only to confirm plausibility, but to assess whether the model can be understood, applied consistently, calibrated transparently, and used meaningfully in real sourcing contexts.

8.1 Expert Validation

A panel of CTOs, CIOs, enterprise architects, procurement leaders, risk officers, and senior delivery or engineering leaders should assess construct completeness, terminology clarity, missing dimensions, and gating logic.

8.2 AHP Weight Calibration

Pairwise comparisons across the major criteria should be used to derive context-aware weights and consistency ratios. Subgroup comparison may reveal meaningful differences between technology, procurement, and risk leadership populations.

8.3 Case-Based Validation

The model should be applied to a theoretically sampled set of historical sourcing cases covering successful and unsuccessful Build, Buy, Rent, and Partner decisions. Each case should document the capability, context, alternatives considered, actual choice, and observed outcomes.

8.4 Evaluation Metrics

  • recommendation plausibility;
  • alignment with historical decision;
  • consistency with observed outcomes;
  • inter-rater reliability;
  • robustness under changed weights or uncertain inputs;
  • managerial usefulness in governance discussions.

Chapter 9. Discussion

This thesis suggests that technology sourcing should be treated as a structured decision over future capability ownership, control, adaptability, and learning. It is not simply an argument about cost minimization or engineering preference.

The model also highlights that sourcing decisions are path-dependent. Every Build decision develops internal muscles. Every Buy or Rent decision develops—or fails to develop—externalization muscles such as procurement maturity, vendor governance, and integration discipline. Every Partner decision shapes the firm’s relationship to ecosystem dependence, collaborative learning, and shared control.

From this perspective, sourcing is a portfolio discipline. It requires explicit choices about what the firm wants to own intellectually, what it wants to own operationally, what it wants to accelerate externally, and what it wants to keep reversible.

Chapter 10. Contributions

10.1 Theoretical Contributions

The thesis extends classical boundary-of-the-firm reasoning into a contemporary technology governance context by formalizing Build, Buy, Rent, and Partner as distinct governance alternatives. It also integrates transaction cost economics, the resource-based view, dynamic capabilities, real options, and multicriteria decision-making into one coherent decision architecture.

A further theoretical contribution is the reframing of sourcing as capability capital allocation. Each sourcing decision is treated as an investment in future knowledge, control, dependence, optionality, and organizational muscle formation rather than merely as a choice of delivery mechanism.

10.2 Conceptual Contributions

One of the strongest conceptual contributions is the explicit separation between governance alternatives and implementation modes. This distinction resolves a persistent confusion in both practice and prior frameworks.

The thesis also contributes a layered decision logic that combines reuse-first reasoning, strategic qualification, construct-based evaluation, non-compensatory gating, utility scoring, and dynamic reassessment.

10.3 Methodological and Managerial Contributions

The thesis translates a strategic managerial debate into a research-ready model with formal constructs, scoring logic, utility functions, decision outputs, and validation pathways.

For practitioners, it offers a more mature executive language for technology investment. It recognizes that buying and renting also require capability, and it gives organizations a structure for governing sourcing decisions with greater transparency and repeatability.

Chapter 11. Limitations

The model is intentionally broad, which increases relevance but also creates abstraction. A framework capable of spanning software platforms, cloud services, ecosystems, and AI-assisted delivery cannot capture every domain-specific nuance without contextual tailoring.

The thesis also integrates multiple theoretical traditions that do not share identical assumptions. This is a strength from a design perspective, but it means the work contributes more to theory integration and decision architecture than to isolated extension of any single theory.

Several constructs remain partly judgment-based. Strategic Value, Collaboration Fit, and Option Value can be structured rigorously, but they cannot be reduced to purely objective measures. Weighting also remains context-sensitive, which means calibration matters materially.

Finally, the manuscript provides a strong empirical validation design but not yet the full executed validation at scale. The thesis is therefore conceptually strong and methodologically ready, but its predictive and comparative performance still requires systematic empirical testing.

Chapter 12. Conclusion

This thesis began from the observation that the classical build-versus-buy framing no longer captures the full reality of contemporary technology sourcing. Modern organizations operate in a richer and more volatile decision space shaped by platform ecosystems, service models, modular architecture, regulation, and AI-assisted software creation.

The thesis responded by proposing a multi-layer technology sourcing and governance decision model that distinguishes governance alternatives from implementation modes, embeds sourcing decisions in capability and control logic, and treats flexibility and optionality as central rather than peripheral variables.

The work has argued that sourcing decisions should be understood as decisions over strategic possibility. A Build decision may create long-term control and learning. A Buy decision may secure speed and embedded expertise. A Rent decision may preserve elasticity and option value. A Partner decision may accelerate innovation while sharing risk and governance. None of these options is inherently superior in the abstract; each becomes more or less attractive depending on strategic value, capability maturity, uncertainty, control need, and risk.

The enduring contribution of the thesis is therefore not only the model itself. It is the invitation to treat technology sourcing as a serious discipline of strategic governance under uncertainty.

References

Alaghehband, F. K., Rivard, S., Wu, S., & Goyette, S. (2011). An assessment of the use of transaction cost theory in information technology outsourcing. The Journal of Strategic Information Systems, 20(2), 125–138.

Aubert, B. A., Rivard, S., & Patry, M. (1996). A transaction cost approach to outsourcing behavior. Information & Management, 30(2), 51–64.

Aubert, B. A., Rivard, S., & Patry, M. (2004). A transaction cost model of IT outsourcing. Information & Management, 41(7), 921–932.

Balliauw, M., Kort, P. M., & Zhang, A. (2021). From theoretical real options to practical decision support: An analysis of the real options approach and its pitfalls for decision-makers. Journal of Economic Dynamics and Control, 129, 104172.

Barney, J. (1991). Firm resources and sustained competitive advantage. Journal of Management, 17(1), 99–120.

Bharadwaj, A. S. (2000). A resource-based perspective on information technology capability and firm performance: An empirical investigation. MIS Quarterly, 24(1), 169–196.

Brewer, B., Ashenbaum, B., & Ogden, J. (2014). Outsourcing the procurement function: Do actions and results align with theory? Journal of Purchasing and Supply Management, 20(2), 94–104.

Coase, R. H. (1937). The nature of the firm. Economica, 4(16), 386–405.

De Giovanni, P. (2018). Capacity investment under uncertainty: The effect of volume flexibility and the value of real options. International Journal of Production Economics, 198, 105–119.

Dibbern, J., Goles, T., Hirschheim, R., & Jayatilaka, B. (2004). Information systems outsourcing: A survey and analysis of the literature. The DATA BASE for Advances in Information Systems, 35(4), 6–102.

Eisenhardt, K. M., & Martin, J. A. (2000). Dynamic capabilities: What are they? Strategic Management Journal, 21(10–11), 1105–1121.

Espino-Rodríguez, T. F., & Padrón-Robaina, V. (2006). A review of outsourcing from the resource-based view of the firm. International Journal of Management Reviews, 8(1), 49–70.

Folta, T. B. (1998). Governance and uncertainty: The trade-off between administrative control and commitment. Strategic Management Journal, 19(11), 1007–1028.

Grover, V., Cheon, M. J., & Teng, J. T. C. (1996). The effect of service quality and partnership on the outsourcing of information systems functions. Journal of Management Information Systems, 12(4), 89–116.

Henderson, J. C., & Venkatraman, N. (1993). Strategic alignment: Leveraging information technology for transforming organizations. IBM Systems Journal, 32(1), 4–16.

Kahraman, C., Engin, O., Kabak, Ö., & Kaya, İ. (2009). Information systems outsourcing decisions using a group decision-making approach. Engineering Applications of Artificial Intelligence, 22(6), 832–841.

Lacity, M. C., Khan, S. A., & Willcocks, L. P. (2009). A review of the IT outsourcing literature: Insights for practice. The Journal of Strategic Information Systems, 18(3), 130–146.

Lacity, M. C., Khan, S. A., Yan, A., & Willcocks, L. P. (2010). A review of the IT outsourcing empirical literature and future research directions. Journal of Information Technology, 25(4), 395–433.

Lacity, M. C., Khan, S. A., Yan, A., & Willcocks, L. P. (2011). Towards an endogenous theory of information technology outsourcing. The Journal of Strategic Information Systems, 20(2), 139–157.

McFarlan, F. W. (1981). Portfolio approach to information systems. Harvard Business Review, 59(5), 142–150.

McIvor, R. (2009). How the transaction cost and resource-based theories of the firm inform outsourcing evaluation. Journal of Operations Management, 27(1), 45–63.

Mikalef, P., & Pateli, A. (2017). Information technology-enabled dynamic capabilities and their indirect effect on competitive performance. Journal of Business Research, 70, 1–16.

Porter, M. E. (1985). Competitive advantage: Creating and sustaining superior performance. Free Press.

Prahalad, C. K., & Hamel, G. (1990). The core competence of the corporation. Harvard Business Review, 68(3), 79–91.

Saaty, T. L. (1980). The analytic hierarchy process. McGraw-Hill.

Sambamurthy, V., Bharadwaj, A., & Grover, V. (2003). Shaping agility through digital options: Reconceptualizing the role of information technology in contemporary firms. MIS Quarterly, 27(2), 237–263.

Teece, D. J. (2007). Explicating dynamic capabilities: The nature and microfoundations of sustainable enterprise performance. Strategic Management Journal, 28(13), 1319–1350.

Teece, D. J., Pisano, G., & Shuen, A. (1997). Dynamic capabilities and strategic management. Strategic Management Journal, 18(7), 509–533.

Tiwana, A. (2014). Platform ecosystems: Aligning architecture, governance, and strategy. Morgan Kaufmann.

Watjatrakul, B. (2005). Determinants of IS sourcing decisions: A comparative study of transaction cost theory versus the resource-based view. The Journal of Strategic Information Systems, 14(4), 389–415.

Wilden, R., Gudergan, S. P., Nielsen, B. B., & Lings, I. (2013). Dynamic capabilities and performance: Strategy, structure and environment. Long Range Planning, 46(1–2), 72–96.

Williamson, O. E. (1975). Markets and hierarchies: Analysis and antitrust implications. Free Press.

Williamson, O. E. (1985). The economic institutions of capitalism. Free Press.

Williamson, O. E. (1991). Comparative economic organization: The analysis of discrete structural alternatives. Administrative Science Quarterly, 36(2), 269–296.

Appendices

Appendix A. Example Measurement Instrument

Strategic Value

Rate each item from 1 (very low) to 7 (very high):

  • This capability is central to our long-term strategic positioning.
  • This capability contributes materially to market differentiation.
  • This capability may enable future innovation or disruption.
  • Internal control over this capability would generate valuable learning.

Internal Capability

Rate each item from 1 (very low) to 7 (very high):

  • We possess the engineering expertise required for this capability.
  • We have the business/domain expertise required.
  • Our teams are mature enough to deliver this capability reliably.
  • We have sufficient human bandwidth to absorb this work.
  • We can operate and evolve this capability after delivery.

Procurement and Externalization Capability

Rate each item from 1 (very low) to 7 (very high):

  • We can compare external solutions rigorously.
  • We can negotiate robust legal and commercial terms.
  • We can govern external providers effectively over time.
  • We can integrate external capabilities effectively.
  • We can prepare and execute an exit if needed.

Appendix B. Decision Output Template

  • Capability name and scope
  • Strategic profile and lifecycle profile
  • Reuse opportunities identified
  • Disqualified alternatives and reasons
  • Utility scores for remaining alternatives
  • Primary and secondary recommendation
  • Key decision drivers and key risks
  • Confidence and robustness indicators
  • Review interval and reassessment triggers

Appendix C. AHP and Case Validation Templates

TODO: The full empirical version of this thesis should include structured AHP pairwise comparison sheets, Delphi round prompts, case reconstruction templates, evaluator guidance, and sensitivity analysis worksheets.

Categories
Artificial Intelligence Information Technology IT Engineering Methodology Project Delivery Requirements Engineering Requirements Management Technology UX

Mastering Requirement Engineering: How to Steer Any Project Toward Predictable Outcomes – Part 1

Requirements Engineering HY

Project success boils down to one critical element: expressing requirements as the essential ‘foundational brick’ of every digital initiative—a lesson my experience leading as CTO, Chief Architect and IT Chapter Lead has taught me time and again.

Therefore, I will walk you through practical “ins” and “outs” of requirement engineering (all based from lessons learned during my career); by showing concrete and actionable solutions that will work directly when using proper process. And you’ll find that it’s far more dynamic and engaging than you might have been led to imagine.

The Starting Point of Clarity: Shifting Perspectives

The very first stage of any project aimed at establishing or changing a system inevitably involves stakeholders that bring varied perspectives. These stakeholders might arrive equipped with well-defined lists of requirements, or they may simply have a broad notion of what they need.

As seasoned business analyst, enterprise architect, or engineer in requirement engineering, it’s our charge to transform these somewhat misty ideas into concrete operational expectations.

A successful project rests on laying clear, solid building blocks from the start – but what happens when those very building blocks change mid-construction?

Deconstructing the Requirement

A requirement is nothing less than a unit describing the behavior of the system we’re about the construct, or upgrade. And by system, I’m obviously referring to every moving part of the machine here. I mean that is a blend of human input, machine outputs via technology, like the hardware itself, software systems, and sometimes specialized machinery. These factors all will work together to ultimately deliver goods or services to the end user, or consumer.

To describe requirement engineering as a step-by-step activity first we start at an “intake workshop” or initial “intake discussion” which we conduct. I always see that as an interactive interview that requires that stakeholders need be ready. They should be ready in bringing elements on the products or services to be offered. It as all interactions the diverse group who will consume the interaction . In addition to how different process are offered and interface used.

Having stakeholders ready at the door is not by chance; clear expectations early define strong and lasting project success further on.

Two Pillars of Success: Aligning Vision and Action

Business Objectives

From these interactive and in-depth interviews, we usually collect an initial set of business requirements. These encompass high-level organizational objectives — the global perspective from corporate leaders, what that single entity, at a macro level, expects to achieve.

As a concrete example that can also guide your thinking process. A business objective could be in reducing a specific pain by aiming that customer inquiries drop sharply YoY or perhaps aim. It could be also focused at improving service levels by making more efficient exchanges between front line agent and positive 4-star average ratings during 3 consecutive business months.

I am trying to tell you here what the entire business objectives expressed at the corporate level intend to accomplish when significant system refactors go live and are fully online. Remember that very often these type of grand and bold expressions does not precisely detail how results will emerge, I mean, these statements define “the what”— not exactly “the how.”

Individual Stakeholder Needs

Naturally as part of our overall journey we also investigate other pillars. We also cover in deep dives, all needs from all of our direct individual stakeholders. Those, when using this framework, will vary as they reflect individual viewpoints of different stakeholders within that entire new process. These are obviously the real system’s daily participants, and they start directly with the very consumer but also encompass a diverse group of customer representatives. To list even further members, those usually also include product managers, product owners, compliance officials at back- office positions, salespeople, system’s experts and also administrators of key areas.

So in synthesis, this captures requirements at hand when seen from an enterprise, internal, system users. This gives much clarity as how the system will need to behave from any angle possible to move further efficiently. Those stakeholders, these key needs or statements must absolutely initiate with a dedicated role’s identifier. And always, this unique role should clearly specify who performs which objective. Although a specific name, which does not change, could also fulfil the same need, it is recommend practice when using roles: the user might change over specific time and it also provides the benefit of being universal and interchangeable. We typically associate roles to a purpose describing specific mission with the very scope over our proposed enterprise solution.

For example, it reflects how an consumer should really be welcomed, or given needed support. Or exactly how the user receive help to fulfil exactly their goals and this translates practically in action. To describe it, or express in real business use case – or user stories -, we should use keywords of the quality or standard of must,  should, or could; or in an easier more customer oriented or “human readable” tone, the typical statements of want or could according to established principles of practice like the MoSCoW method; with an object that need specific measurable levels of activity, and these could refer typically as timed elements, or even similar dimensions.

These business requirements and user needs represent the yin and yang needed for a robust requirement engineering exercise… that said, how can a single vision encompass different realities without generating chaos?

Going Deeper

Lets get into more details on requirements. You absolutely should be taking specific points, that must always come to your considerations

Requirements fall into multiple forms and shapes with their nuances. There always will be a business requirements. By that I mean statements encompassing the entire purpose and outcome that must result when viewing it at the top- level. Think big picture; This can refer simply to revenue objectives, but also the general and overall improvement measures from new standards of service or level quality. Maybe even, why would need to change your very organization itself in by adding or reducing key employee functions. In short there should aim any time that new risks diminish across the processes with an even greater growth on specific business categories or customer bases.

Then, always, the stakeholder or even more simply stated user needs should always be on the list and it is just stating things from a concrete daily actions and tasks being required from a normal system’s everyday use and daily journey perspective. That means we include the very customer, any internal team like engineers working in service desk, an administrative expert plus relationship executives, a product lead and their team the real IT team covering areas such an compliance or network infrastructure departments. These all have diverse usage patterns with sometimes vastly diverse daily requirements. Now is that time to take advantage from these unique opportunities being offered in a timely process improvement initiative?

Then come the more refined aspects: all the expressions to define in concrete terms how “the system must work”, taking into consideration every angle. Functional statements, as requirement, does not only cover the idealistic perfect “happy situation but it must consider less likely scenarios and “exceptions cases”. All of this done in order of improving the very solution.

Every statement when dealing with functional requirement must systematically bring other additional questions too: functional, but mainly based on current user’s activities. A proper inquiry must target on how needs achieving business results, when looked through different perspectives that translates into real day-to-day steps to complete a goal being stated as core objectives. For instance. If part of a overall user journey, you must translate even complex workflows with concrete statement which translate as practical system behaviors along various user operations.

We need also to dig into another very specific requirement’s families: the less visible aspect, typically associated a system’s framework such compliance standards for performance that express real world hard, strict constraints. Or what we often coin as simply rules defining parameters, including regulatory statements, corporate norms, industry compliance benchmarks, or specific or established operating frameworks.

For example, if specific or even highly strict certification is paramount, for instance ISO norm 2022 or PCI-DSS norm of the international card processing businesses. As one example among many. Those frameworks brings their mandatory strict operating guide. And these will form that bedrock for all further development at all levels— whether a new or evolving application , an improvement to existing processes or system or even novel products, and new ventures, ensuring there exists no discrepancy when considering what must be done. And more, many businesses already have an internal guiding principles whether or not these are formally integrated for instance in a internal enterprise architecture manual. It means we must always check that aspect first. This can impact by default and most usually is defined from the outset but in rare events it also will emerge at a late, more mature phase, during one that intake deep dive, during session of brainstorming when the proper inquiry has commenced.

A business or process specialist and also an Architect usually must collect initial set of systemic assumptions and the single best and efficient practical means of doing that properly, starts asking good and pointed specific pertinent questions.

This layered approach to discovering and mapping the technical requirements ensures no stone will be left unturned. Do you wonder how you can reconcile these vastly different perspectives in practical project execution terms?

Let’s address this important question in next episode.

Categories
Strategy Architecture Artificial Intelligence Blockchain Business Business Strategy Enterprise Architecture Organization Architecture Technology Technology Strategy

Architecting the Future: How RePEL Counters VUCA for Modern Enterprises

RePEL vs VUCA
RePEL vs VUCA

I was first introduced to the term VUCA by my ex-colleague, Julian TROIAN, a leader in coaching who steers the talent management practice. This revelation came during a particularly challenging phase for us, mirroring the struggles of many other companies. We found ourselves navigating the intricacies of the COVID lockdown while simultaneously undergoing a significant shift in the corporate way of working. Our project portfolio was expanding, driven by the rapid pace of transformations, and we felt the weight of increasing regulatory pressures. But we recognized that these challenges were not ours alone. Then, significant disturbances emerged: the Eastern Europe conflict and a surge in inflation, to name a few.

Moreover, the world stood on the brink of simultaneous technological revolutions. Innovations like blockchain and the nascent promise of the metaverse hinted at new horizons. Yet, it was the seismic shifts brought on by Generative Artificial Intelligence that seemed most profound.

VUCA is an acronym encapsulating the themes of vulnerability, uncertainty, complexity, and ambiguity. Herbert Barber coined the term in 1992 based on the book “Leaders: The Strategies for Taking Charge”. I believe many can relate to these elements, sensing their presence in both professional settings—perhaps during office hours—and in personal moments with family.

Life, in its essence, might be described by this very term. We all traverse peaks and lows, facing situations of heightened complexity or vulnerability. The challenge is not just to navigate these periods but to foster strength and ingenuity, arming ourselves for future obstacles.

I consider myself fortunate to have garnered knowledge in enterprise architecture—a domain that inherently equips any organization, product, or service with resilience, making adaptability part of its very DNA.

In the subsequent sections, I explore strategies for developing VUCA antibodies.

From Vulnerability to Resilience: Building an Unshakable Future

Rather than getting bogged down by vulnerabilities, it’s about harnessing resilience. Robustness is the key to building thick layers of protection, ensuring longevity in our ventures. By deliberately creating anti-fragile mechanisms, we’re better prepared for tough times. This resilience doesn’t just happen; it’s constructed. Architects weave it into their designs across various realms:

  • Information Systems: These are designed to be failure resistant. Potential mistakes and erratic behaviors are predicted and integrated into the system as possible anomalies. In such events, responsible teams must give clear procedures to users, operators, and administrators to restore the system to its standard operational mode.
  • Data Management: From acquisition and processing to analytics and visualization, there’s complete control over the data flowing into the system. This range from a service request made over the phone, a command initiated by an AI, or even a tweet that prompts the system to respond.
  • Security: Safeguarding the system against potential hacks is crucial. Additionally, it’s vital to design the system in a way that vulnerabilities don’t open doors for intrusions. Depending on the chosen architectural delivery method, this can be addressed proactively or reactively.
  • Infrastructure: The foundational physical infrastructure, tailored to the system’s needs, must be aptly dimensioned. At times, specialized hardware like GPU-driven servers, or programmable network devices might be essential to cater to particular needs during both the development and operational phases.
  • Organization: People, integral to the corporate ecosystem, influence the system’s effectiveness. Their actions and behaviors enhance system efficiency, especially when elements like trust, making amends for failures, regular maintenance, and adaptability to change are activated.

All these aspects aren’t mere byproducts; they’re deliberately designed system features.

From Uncertainty to Probable Planning: Navigating with Confidence Through Uncertain Waters

Predicting the future is beyond anyone’s capability, but architects can narrow down scenarios to the most probable outcomes. Through modeling techniques like system design, trend analysis, scenario planning, and causal loops, they can forecast with a higher degree of accuracy. However, the planning phase isn’t without challenges:

  • Resources: There are times when constraints in time, finances, skills, and materials can make a proposed solution unfeasible. Recognizing this early on is vital.
  • Leadership: A wavering decision-maker, filled with doubt, can be a significant impediment. This is a leadership challenge that needs addressing at the top. In such a situation, the architect must highlight the unstable matter with benevolence and candor.
  • Team: The implementation is only as good as the team behind it. If team members don’t possess the necessary skills or their abilities don’t align with the mission’s complexity, especially when executing multiple plans simultaneously, it will compromise the execution of the plan.
  • Expertise: last but not least, the architect’s seniority and the time allocated to address your transformation’s VUCA elements also play a critical role.

From Complexity to Engineering: A Blueprint for Simplification

Sometimes, complexity arises from perception, misunderstanding, or underestimating a situation – often, it’s a mix of these elements.

Imagine you have three wooden chairs, and you wish to create a sofa. Is it even possible? Fortunately, Ikea offers a DIY toolbox that can help you realize this vision. When you describe your idea to the store specialist, she confidently directs you to aisles A8 to C12 for the necessary components. At first, you feel relief. But soon, doubts about your abilities confront you. Even with your experience in crafting wooden furniture, you’re unsure about the mechanisms you’ll need, the type of finish to choose, the tools required for precise cuts, and the best materials for durability. Are these materials environmentally friendly? This confusion and uncertainty are akin to experiencing VUCA.

The architect’s role is to first understand the complexity, determine the facts, and uncover what’s unknown, converting it to known information. Then, the challenge or problem is segmented into manageable pieces. I refer to this process as “Undesign.” The goal of undesigning is to get a clear and detailed view of the end goal by atomizing the current state, structure, and behavior. This is achieved through methods like decomposition, deconstruction, alternate system modeling, and sometimes reverse engineering. Subsequently, the architect uncovers a path to transform and assemble these components.

The essence of engineering is to assemble these components using identifiable, simple building blocks. These blocks are selected, modified, added, and connected in a logical order, ensuring the right materials, technologies, and tools are used. People with the right skills can then efficiently bring the project to life, ensuring it’s as seamless and enjoyable as possible. Even the user’s psychological experience matters!

In summary, what seems intricate and complex can be distilled into simpler, manageable parts.

From Ambiguity to Lucidity: Transitioning from Wishful Thinking to Tangible Outcomes

Architects don’t just exist in the present; they shape the future. Their responsibilities lie in meticulously designing and planning changes that will inevitably impact an organization’s products or services. Any vision, no matter how abstract, becomes initially tangible through their work. They ensure this by providing explicit construction instructions, detailed models of the final product, and ensuring the requisite resources and skills are in place. By doing so, architects play a pivotal role in turning ambiguity into precision.

Moreover, it’s the architect’s responsibility to align ambitions with the resources available, ensuring that goals are realistically achievable.

In wrapping up, VUCA can be perceived as a daunting challenge. But, with the right leaders onboard, RePEL becomes a natural response to unfriendly environments and stressful times. They hold the key to transforming volatile situations into clear, well-defined future pathways, keeping the enterprise entropy under control.

Categories
Architecture Business Data Architecture Enterprise Architecture Information Technology IT Architecture Organization Architecture Technology UI Architecture

“Leading you to the best decisions” - A story about the unimaginable benefits of Architecture in Businesses

frank busch LpYcecGTifI unsplash
Green arrows that illustrate the theme "Leading you to the best decisions"

I am amazed by the sparkling eyes of someone discovering what he or she can achieve with Enterprise Architecture and IT Architecture. 

This wonderful effect usually starts with a casual conversation, like one of those happening when you meet someone for the first time at an event exposing the disruptive changes in your industries.

I had that conversation the other day.

Coming out of the main conference room, I was thirsty, so I walked in the direction of the bar. New beverages? Of course, count me in. The drink is unusually green. Same colors as one of those “Diabolo-Menthe” I had in my childhood in Paris. But this glass is foggy. While I am looking at the recipient trying to guess what that magic potion is made of, the bartender is observing me. During this moment of hesitation, he said: “It’s coming from Japan. You are going to like it”. Despite his confidence, he did not convince me. How could he know my tastes anyway? Nevertheless, I drank the mysterious beverage, and, oh boy, he was right. The — whatever the name — was delicious.

Someone next to me was trying a foggy red elixir. When she caught the surprise on my face, she engaged in the conversation.

I answered politely, and introduce myself.

“Nice to meet you. My name is Yannick. Chief Architect at ING”. I shake her hand and I follow up with: “We are experiencing interesting changes, indeed. For the better, I believe.”

“Ah, so you are in real estate construction? Very nice! the industry is flourishing, you must be a happy man!”

“I’m in construction indeed. However, I build businesses, not buildings.”
 
She pauses for a few seconds. “What do you mean? Are you not managing your own architecture firm?”

“Not a firm, but an Enterprise Architecture department in one of the largest financial technology groups on earth. Still, it feels the same as running your own business. The expertise of my team consists of methodically designing and planning the development of products, services, or even the entire lines of business, in the most optimal and sustainable way possible. Whatever we provide fits the customer’s needs, and is made according to its finance, timing, opportunities, technologies, regulatory scope, etc. We consider all aspects. Basically, no matter the complexity, we have a solution for you.”

“Ah, interesting! I didn’t know such a job even existed. And by “all aspects”, you mean…?” 

“Let’s say you’ve come up with a brilliant idea to differentiate yourself by proposing a new product line or rethinking your services. Using an Architecture construction method for businesses, I will first guide you in defining and detailing your requirements and the goals you want to achieve. Quite often, what you think you want is not what you need.

Second, I’ll ask you questions to discover requirements, including some you have not thought about in the first place, and some you wouldn’t believe it is important to care about them.

Third, we will list your constraints and spot the legal framework you must comply with. Moreover, I’ll check with you what you expect as an outcome given your budget and resources. The purpose is to demystify beliefs from the start, then, I will share with you what it takes to get what you want. Indeed, this practice is similar to the building industry, there are rules you have to follow, like environmental guidelines, materials used, construction permits, etc.” 
 
“Ok, I’m starting to get it now. Tell me more.” 
 
“Sure. 
After having completed the aforementioned activities, the Architect does the first design. It is a sketch of the solution to meet your expectations. The purpose is to assess the impacts, but also to make the product more visual and tangible. It is followed by some research to identify the components that can match your needs, in the best ways possible. I said “ways”, with an S, because what matters are the choices YOU make along the way. It all comes down to giving you alternatives to preserve your freedom of choice. 

Ultimately, the architect will lead you to the best decisions. 

In this design phase, they are several workshops, discussions, negotiations, and information sessions held to detail the master solution design and to thin out financial analysis. 

From this point, we will initiate together a dossier, based on the agreements and scope of work. This mutual understanding acts as a contract. 

The first phase starts with an order for which the result will be an iterative analysis of your requirements, an architecture blueprint, a construction planning, a quote, from which any partnership with product development companies can manufacture your product and services.”

“This looks like a very fun job, very complex, and demanding. Can you be knowledgeable in all these domains? “

“It depends” — This is the architects’ favorite quote.

“The architect is an expert in, at least, two domains: a business domain and a technological domain. They are PI-shaped. For example, I started my career as a Development Engineer, and evolved as an expert in Information Systems Integration, with a Business specialization in Financial Services and Insurances. 

Additionally, they must know the purpose and the mechanisms of other domains and how they fit together. They grow a System Thinking. For example, a company has a Marketing department, a Finance Department, an IT department, a Sales department, etc. Each of them has a specific reason to exist, and they are made up of a plethora of activities that are fundamental elements of the corporate machine. Before selling, the Marketing intent is to present, demonstrate, attract the customer but also to analyze the potential client while continuing to engage the existing customers. To sell better, IT digitize the sales catalog and specs of the products, while having the CRM available on a mobile app, so that Sales can connect with the prospect anywhere and anytime. 

I could go on, but the point is an architect considers each of these domains, each user interaction, each process, each application, each technology, each data, each skill as a building block that needs to be assembled to meet your needs and comply with the agreed requirements.

It is like getting several boxes of Lego, figuring out what the blocks are relevant, and detailing the instructions to achieve the construction. Therefore, there is no need to be an expert in multiple domains, but you need to appreciate their purpose and understand how an industry works to be relevant to your customers. In practice, we reach experts when needed.” 
 
“Humm. It sounds simple to understand yet complex in the execution.” 
 
“You are correct.”

“But how come I didn’t hear about Architects for businesses before? Thinking about it, your job seems necessary from the moment an enterprise reaches a certain size.”

“Perhaps you did, there are more architects than you think. For various historical reasons, Architecture is associated with the Information Technology department. Hence most of the time, people in companies consider us like IT folks doing IT stuff, whereas what we deliver are business and technology strategy, business and engineering analysis, business and engineering design, business and engineering planning, and business and engineering innovations. 

Almost every change and improvement in your value chains need software and hardware. So it does not surprise me, our core skill is engineering. We thrive in manufacturing predictability and precision. 

Nevertheless, I understand totally why people categorize architects exclusively in a technical domain if they are continuously presenting themselves using a single part of their expertise. Sometimes it is comfortable !” 
 
“Maybe. Now that you mention. In general, we discuss with our IT specialists whenever we need to change, create new features, or fix things. We trust them, but sometimes it feels like they over-complexify things.” 

We both joyfully laugh.

“I was just sharing my feeling here. I am nowhere near capable of assessing if they could do faster or better. We know they do their best. Yet, we wish we would have more flexible and more modern IT systems, more automated stuff, and good-looking user interfaces. Well, at least they do work!”
 
“Trust me, this is what matters the most. I have a very simple Architecture motto:

1st it needs to work great all the time,
2nd it must be easy to use, remember, teach, and maintain
3rd it should look awesome.” 

“Amen to that. It makes me wonder, though… If Business and IT people can build things already, why would I need an architect?” 

“Good question. To answer you, I’m going to start with: I prefer you to not need me.” 

“I wasn’t expecting this. I’m confused… And curious!”
 
“I know. Why would you need a civil architect to fix your light bulb, change your kitchen sink, or even change the facade of your building? No, you don’t need one for the activities. You call the electrician, plumber or you do it yourself. You need specialized builders or repair persons. And autonomy is the best for everyone. But if you’re looking for building a new house, extend your house with a new room, or change the location of your bathroom, you might want to call your architect. You can, eventually, do it without one. Though, it is your decision of running the risk to spend more money than expected, to have the construction take more time than expected, to receive something that may not meet your expectations or worse.
The decision is entirely yours.”

“I get your point. So when and where should I get an architect? Do I need a Bat-symbol?”

“For most small changes, you don’t need an architect. Rule of thumb, If the structure does not change, the scale of impact and volume stay similar, you don’t touch your foundation, and you don’t bring any new substantial data or business functions, ask your engineers, or senior business analyst to make the change. But at some point, your companies get big enough that people start losing sight, control, and understanding of how everything comes together. The systems of an enterprise are simply too complex to be dealt with by people busy with specific tasks daily. Furthermore, it is neither their core knowledge nor their core activities. And as if it wasn’t enough, the pace of technological disruptions keeps increasing.

As a rule of thumb, you need an architect when you: 

  • Want something custom 
  • Are dealing with complex programs of work
  • Don’t know where to start 
  • Need to acquire or leverage a piece of technology 
  • Seek guidance to build enterprise functions that are sustainable and scalable 
  • Require to plan an actionable strategy with a good level of accuracy 

Either you want something that everybody can get or you want something custom.”

“Are there different kinds of architects? I mean, we have different kinds of builders like plumbers, carpenters, electricians, etc.”

“Architects are … architects. There are flavors of architects. Let’s say they have specialties. Some of them are experts in the infrastructures, some in the data, others in software, while some focus their expertise on a specific industry. The only thing that matters, from a customer point of view, is that they provide the same service and they work together. 

They have the same fundamental knowledge and way of operating. Architects might differ in their technique though. with the practice of various Architecture methods such as Zachman, TOGAF. Some companies build their own because it fits better with their industry and their organization such as EAgile for ING. Some are more specialized, like my AMASE methodology for startups and innovative organizations.
I could tell you more but I’ll save this for another time.”

“I thank you for these explanations and for your time. To be frank, this is an eye-opener. I need to talk with my executive co-workers.”

“My pleasure, Ms. X. One more thing. Do you know what the origin of the word “Architect” is?”

She looks above like she was looking at the answer deep in her memory. Then a second later, the spark. She said, with the scintillating eyes

“Master Builder!”.

Photo by Frank Busch