Introduction
Enterprise Architecture (EA) has undergone profound transformation over the past two decades. Historically conceived as an Information Technology discipline focused on aligning IT systems with business strategy, EA has evolved into a comprehensive enterprise-wide practice addressing organizational complexity and enabling effective change management. This evolution, articulated by scholars like James Lappalme and others in the EA community, reflects a fundamental shift in how organizations approach strategic alignment, process optimization, and organizational design.
The traditional IT-centric model of enterprise architecture maintained clear boundaries: IT professionals designed technical architectures, business units defined their requirements, and alignment happened through translation and negotiation. This model, while serviceable during periods of relative stability, proves inadequate in today's environment of continuous change, digital transformation, and organizational complexity. Modern organizations recognize that enterprise-wide challenges—operational efficiency, customer experience, regulatory compliance, organizational agility—cannot be solved through IT architecture alone.
Contemporary enterprise architecture encompasses Business Data Analytics Technology (BDAT) architecture, integrating business processes, data management, applications, and technology infrastructure into a cohesive whole. Critically, this integration extends beyond documentation and models to active simulation and analysis. Organizations no longer simply document how processes should work; they simulate processes under various scenarios to optimize Service Level Agreements (SLAs), human resource utilization, and organizational effectiveness. This simulation-driven approach enables organizations to design and restructure themselves more effectively and efficiently before implementing changes at scale.
Beyond processes and systems, enterprise-wide architecture alignment extends to all organizational dimensions: organizational vision and mission, strategic plans, management standards, key performance indicators, risk management frameworks, business processes, data assets, applications, and technology infrastructure. This multi-dimensional alignment addresses the reality that organizations function as integrated systems where misalignment in any dimension creates friction, inefficiency, and failure.
This article examines the evolution of enterprise architecture from IT-centric discipline to enterprise-wide practice, explores the technical and organizational foundations enabling this evolution, analyzes BDAT architecture and business process simulation as drivers of organizational optimization, and addresses the implications for organizational restructuring and strategic alignment.
The Historical Context: IT-Centric Enterprise Architecture
The Origins and Evolution of IT Architecture
Enterprise architecture emerged in the 1980s and 1990s as IT departments grappled with increasing system complexity. Organizations had accumulated diverse applications, databases, and infrastructure developed independently by different teams serving different business units. Managing this heterogeneous environment became increasingly difficult. Enterprise architecture frameworks like TOGAF (The Open Group Architecture Framework) and Zachman Framework emerged to provide systematic approaches for understanding, planning, and managing enterprise IT environments.
Early enterprise architecture focused on several practical problems:
System Integration: How do diverse systems communicate and exchange data? How can organizations avoid data silos and redundant systems?
Technology Standardization: What hardware platforms, operating systems, and middleware should the organization standardize on? How can standardization reduce costs while maintaining flexibility?
Systems Planning: How should technology investments be prioritized? How can IT investments be aligned with business strategy rather than simply reacting to isolated requests?
IT Governance: How should technology decisions be governed? Who has authority over technology standards and strategies?
These problems were fundamentally IT problems, even though solutions had business implications. EA evolved as IT discipline for managing IT complexity.
Limitations of IT-Centric Architecture
While IT-centric architecture achieved important objectives, it operated within inherent limitations:
Boundary Limitations: The boundary between IT and business remained problematic. IT architects designed technology solutions intended to support business processes, but the actual business value depended on business process design, organizational structure, performance management, and change management—all primarily business concerns.
Business Process Invisibility: Traditional IT architecture often treated business processes as static. The reality—that business processes changed, that process efficiency dramatically affected outcomes, that organizational structure and process design were intertwined—remained outside EA scope.
Incomplete Alignment: Even well-executed IT architecture achieved only partial alignment. Organizations could have well-integrated systems, technology standards, and IT governance yet still operate inefficiently because business processes were suboptimal, organizational structure created silos, or strategy wasn't reflected in operations.
Change Management Challenges: When business strategy changed or new initiatives were required, IT-centric architecture sometimes impeded rather than enabled change. Inflexible IT systems or infrastructure, technology investments misaligned with emerging needs, or rigid IT governance processes could slow organizational adaptation.
Stakeholder Engagement: Business stakeholders often viewed IT architecture as arcane, irrelevant to their concerns. If IT architecture didn't visibly help solve business problems or enable business transformation, business leaders underinvested in it and worked around it.
These limitations created pressure for enterprise architecture to evolve beyond IT focus toward more comprehensive enterprise-wide practice.
The Evolution Toward Enterprise-Wide Architecture
Conceptual Foundations of Enterprise-Wide EA
The evolution toward enterprise-wide enterprise architecture reflects several conceptual shifts:
Systems Thinking: Recognizing that organizations function as integrated systems where changes in one domain have ripple effects across others. Optimization of individual components (IT systems, processes, organizational units) without understanding system-wide effects often creates suboptimization at system level.
Business-Technology Integration: Recognizing that business problems and technology problems are increasingly inseparable. Digital transformation, process automation, data analytics—these bridge business and technology. Separating these concerns creates inefficiency.
Process-Centric Thinking: Shifting focus from functional silos (finance, operations, sales) to cross-functional processes (order-to-cash, procure-to-pay, plan-to-produce). Processes deliver value to customers and drive operational efficiency, making process architecture central to enterprise architecture.
Change as Continuous: Acknowledging that organizational change is not occasional disruption requiring return to stable state, but continuous adaptation. Architecture must enable continuous change rather than optimizing for stability.
Holistic Alignment: Recognizing that comprehensive organizational alignment requires integrating strategy, operations, structure, performance management, risk management, and technology. Partial alignment leaves problems unresolved.
James Lappalme's Enterprise Architecture Perspective
James Lappalme, prominent EA thought leader, has articulated important perspectives on EA evolution. Lappalme emphasizes that enterprise architecture should address enterprise complexity and enable organizational change effectively. EA is not primarily about creating detailed technical blueprints but about developing coherent understanding of organizational capabilities, dependencies, and opportunities for improvement.
Lappalme identifies critical EA responsibilities:
- Understanding how organizational capabilities are designed, implemented, and evolved
- Identifying constraints and dependencies limiting organizational effectiveness
- Enabling strategic choices by clarifying implications of different options
- Supporting organizational change by providing coherent architecture vision
- Maintaining coherence as organization evolves
This perspective moves EA beyond IT documentation toward enterprise-wide sense-making and change enablement. EA becomes strategic practice essential to organizational leadership, not IT specialty delegated to technical experts.
BDAT Architecture: Integrated Framework
Understanding BDAT Architecture
BDAT (Business, Data, Application, Technology) architecture represents contemporary enterprise architecture integration, explicitly recognizing four interdependent architectural domains:
Business Architecture: How is the organization structured? What are its key processes and capabilities? How do processes interact? What organizational units are responsible for what? Business architecture describes organizational operating model—the fundamental way the organization conducts business.
Data Architecture: What data does the organization need to operate and succeed? How is data related and organized? What is the data's quality, accuracy, and currency? What systems contain data? Data architecture ensures data assets are treated as strategic resources, not byproducts of applications.
Application Architecture: What applications support organizational operations? What functions do applications provide? How do applications share data? Application architecture ensures applications support business processes effectively and work together coherently rather than functioning as isolated systems.
Technology Architecture: What technology platforms, infrastructure, and standards support applications and data? Technology architecture ensures infrastructure is reliable, secure, scalable, and aligned with application and data needs.
These four domains are deeply interdependent. Business processes require data to operate effectively. Applications make business processes executable at scale. Technology infrastructure supports applications. Changes in one domain cascade through others.
Integration Across BDAT Domains
Effective BDAT architecture requires explicit integration across domains:
Business-Driven Alignment: Business strategy, organizational structure, and process design drive data, application, and technology decisions. Technology exists to support business objectives, not the reverse.
Process-Data Integration: Business processes specify what data is needed, how data flows, and where data is created, transformed, or consumed. Data architecture must support process requirements. Conversely, data availability and quality influence what processes are feasible.
Application Support: Applications automate or facilitate business processes. Application design should align with process design. Applications should integrate to support cross-functional processes that span organizational boundaries.
Technology Enablement: Technology infrastructure must support application performance, reliability, security, and scalability requirements. Technology choices influence what applications and data management approaches are feasible.
For example, an organization redesigning its customer service process might:
- Define new process steps improving customer experience
- Identify data needed at each step (customer history, product information, service records)
- Specify applications supporting process execution
- Ensure technology infrastructure provides necessary performance and reliability
Traditional IT architecture might focus primarily on the application and technology dimensions. BDAT architecture ensures business and data dimensions are equally explicit and integrated.
Business Process Simulation and Optimization
The Limitation of Static Process Documentation
Historically, business process architecture relied on static documentation. Business analysts used modeling notations like BPMN (Business Process Model and Notation) to document how processes worked or should work. These models provided valuable documentation but had significant limitations:
Inability to Test Assumptions: Static models couldn't test assumptions about process performance. How long would end-to-end customer requests take? What would happen if customer demand increased 50%? What would happen if a critical resource became unavailable? Static models couldn't answer these questions.
Limited Optimization Insight: Static models showed process flow but didn't clarify where bottlenecks occurred, where resource utilization was inefficient, or where human effort could be reduced. Optimization required experience and intuition rather than data-driven analysis.
Implementation Risk: Organizations couldn't validate that redesigned processes would actually achieve intended performance before implementing changes. Implementation failures cost time and money.
Change Impact Unknown: When organizations considered changes—staffing adjustments, system modifications, process redesigns—impact on overall organizational performance remained unclear.
These limitations meant organizations often implemented process changes based on intuition or best practices rather than rigorous analysis. Expensive implementation failures were common.
Business Process Simulation Approaches
Business process simulation addresses these limitations by creating computational models of processes and running simulations under various scenarios. Simulation enables organizations to understand process behavior before implementation.
Discrete Event Simulation: Models processes as sequences of events (customer arrives, request is processed, customer departs). Simulation engine moves through time, executing events, tracking resource utilization, queue lengths, and process times. This approach works well for transactional processes with clear events.
System Dynamics Simulation: Models systems with feedback loops and delays. This approach works well for processes involving accumulation, delays in information flow, or reinforcing cycles. For example, staffing decisions affect work backlogs, which affect hiring decisions, creating feedback loops that discrete event simulation doesn't capture well.
Agent-Based Simulation: Models autonomous agents (customers, employees, systems) with defined behaviors and interactions. Agents make decisions, interact with each other and environment, and create emergent behavior. This approach works well for complex adaptive systems and organizational behavior.
Hybrid Approaches: Real-world process simulations often combine multiple approaches, using discrete event simulation for transactional flows, system dynamics for strategic feedback loops, and agent-based modeling for emergent organizational behaviors.
Key Metrics and Analysis from Simulation
Business process simulations generate insights around several critical metrics:
Service Level Agreements (SLAs): How long do customers wait? What percentage of requests are completed within SLA timeframes? Which process steps are SLA bottlenecks? Simulation can test whether proposed staffing levels, system investments, or process changes enable SLA achievement.
Human Resource Utilization: How fully are people utilized? Where are resource bottlenecks? What staffing levels are required to meet demand while maintaining acceptable utilization? Simulation enables organizations to right-size staffing, neither over-staffing (wasting resources) nor under-staffing (creating backlogs).
Cost Analysis: What is the cost per transaction? How do different staffing or technology configurations affect cost? What investments most effectively reduce cost? Simulation quantifies trade-offs between different approaches.
Scenario Analysis: What happens if customer demand increases? If a key system fails? If staffing is reduced? Simulations test scenarios, revealing vulnerabilities and testing resilience strategies before implementation.
Optimization Analysis: Given objectives (achieve SLA with minimum cost, minimize customer wait time, improve employee satisfaction), what process design, staffing, and technology configuration are optimal? Simulation enables systematic optimization rather than ad-hoc adjustments.
Organizational Restructuring Through Architecture-Driven Design
The Intersection of Process and Organization
Business process design and organizational design are deeply intertwined. Historically, organizations designed themselves hierarchically by function (finance, operations, sales) or geography, and then designed processes that often worked awkwardly across organizational boundaries. Modern organizations are reversing this approach: designing processes to optimize customer experience and operational efficiency, then structuring the organization to support those processes.
Process-centric organizational design offers several advantages:
End-to-End Accountability: When organizational units align with processes, single units can be accountable for end-to-end process performance rather than having accountability fragmented across multiple units. This clarifies responsibility and enables more effective performance management.
Reduced Handoffs: When organizational boundaries align with process boundaries, handoffs between organizational units decrease. Fewer handoffs reduce delay, miscommunication, and error.
Improved Efficiency: Process-centric organizations often achieve better SLAs, lower cost per transaction, and higher customer satisfaction because organizations are optimized for processes rather than processes being forced to work through functionally-designed organizations.
Clearer Career Paths: Employees understand how they contribute to end-to-end processes and how process performance affects organizational success. This clarity can improve engagement and motivation.
Simulation-Driven Restructuring
Business process simulation enables more effective organizational restructuring:
Current State Analysis: Simulate existing processes and organizational structures to understand actual performance. This baseline identifies specific problems and bottlenecks rather than relying on perception or intuition.
Option Evaluation: Simulate alternative organizational structures and process designs. How would performance change with different staffing? With different organizational boundaries? With different process flows? Simulation enables comparison across alternatives.
Trade-Off Analysis: Organizational restructuring involves trade-offs. Consolidating functions might reduce cost but increase cycle time. Simulation quantifies these trade-offs, informing decisions.
Risk Assessment: Restructuring carries risks—temporary productivity loss, key personnel departures, implementation challenges. Simulation can model risks and test mitigation strategies before implementation.
Phased Implementation: Rather than implementing restructuring all at once, organizations can simulate phased approaches. How should restructuring be sequenced to minimize disruption? What support would employees need during transition?
Validation: After restructuring, organizations can compare actual performance to simulated predictions. If performance differs significantly from simulation, analysis can identify why and inform ongoing optimization.
Multi-Dimensional Enterprise Alignment
The Comprehensive Alignment Framework
Contemporary enterprise architecture addresses alignment across all organizational dimensions:
Vision and Mission: Fundamental organizational purpose and long-term aspirations. Everything else should logically flow from vision and mission.
Strategic Plan (Renstra): How will the organization achieve its vision? What strategic objectives will it pursue? What capabilities must be developed? Strategic plans articulate the journey from current state to desired future state.
Management Standards: What principles guide organizational behavior? What governance processes ensure consistency? Management standards ensure the organization acts consistently with its values and strategic intent.
Key Performance Indicators (KPIs): What metrics define success? What will the organization measure to determine whether it's achieving objectives? KPIs translate strategic objectives into measurable, monitored indicators.
Risk Management Framework: What risks threaten strategic success? How will the organization identify, assess, and mitigate risks? Risk management ensures the organization considers potential problems proactively.
Business Processes: How will the organization deliver value to customers and stakeholders? What processes must work effectively? Business processes translate strategy into operational reality.
Data Architecture: What information assets does the organization need? How are data organized, governed, and used? Data architecture ensures data supports decision-making and operations.
Application Architecture: What systems support organizational processes and decisions? How do applications work together? Application architecture ensures systems support rather than hinder organizational objectives.
Technology Infrastructure: What computing platforms, networks, and infrastructure support applications? Technology infrastructure provides reliable, secure foundation for organizational operations.
Alignment Mechanisms and Integration
Achieving multi-dimensional alignment requires explicit mechanisms integrating dimensions:
Strategic Cascade: Strategic objectives flow down through the organization. Business units develop strategies aligned with organizational strategy. Teams align objectives with business unit strategies. KPIs at each level reflect contribution to higher-level objectives.
Process-Strategy Alignment: Business processes are designed to execute strategy. Processes are reviewed periodically to ensure continued alignment with evolving strategy. Changes in strategy trigger process redesign.
Governance Integration: Governance bodies address strategy, process design, technology decisions, and risk management together, ensuring consistency. For example, capital investment decisions should be made in context of strategic priorities, process roadmap, and technology strategy.
Data Governance: Data governance ensures data availability, quality, and security support strategic and operational needs. Data priorities reflect business priorities.
Performance Management: KPIs are tracked, analyzed, and reviewed. Performance against KPIs informs strategy adjustments, process improvements, and resource allocation.
Risk Integration: Risk assessment considers how each organizational dimension might create or mitigate risk. Technology risks, process risks, staffing risks, and market risks are considered holistically.
Change Management: When organization changes—strategy shifts, processes are redesigned, technology is upgraded, structure is reorganized—change is managed comprehensively, considering implications across dimensions.
Enterprise Architecture and Organizational Change
EA as Change Enabler
Enterprise architecture, particularly when evolved to enterprise-wide practice addressing all organizational dimensions, becomes powerful change enabler:
Change Clarity: Architecture provides clear understanding of current state and proposed future state. This clarity helps stakeholders understand what is changing and why.
Change Scope: Architecture identifies all areas affected by change—process changes, technology changes, organizational changes, data changes. Comprehensive scope identification prevents overlooking important areas.
Dependency Management: Architecture explicitly identifies dependencies between elements. Understanding dependencies helps manage change sequence and prevents implementing changes in orders that create problems.
Impact Analysis: Architecture enables analyzing impacts of change across dimensions. How will process changes affect technology requirements? How will technology changes affect organizational capabilities?
Roadmap Development: Architecture supports developing multi-year roadmaps showing how the organization evolves from current state toward future state. Roadmaps can be sequenced to manage risk, build capabilities progressively, and deliver value incrementally.
Stakeholder Communication: Architecture provides language and models that help various stakeholders understand organizational strategy, changes, and implications. Executives understand strategic implications; operations understand process implications; IT understands technology implications.
Continuous Evolution
Rather than viewing architecture as static blueprint, contemporary enterprise architecture treats architecture as continuously evolving:
Regular Assessment: Periodically assess how organizational architecture is performing. Are KPIs being achieved? Are processes efficient? Is technology reliable? Are capabilities developing as planned?
Feedback Loops: Gather feedback from stakeholders, customers, employees, partners. Feedback informs understanding of where architecture needs evolution.
Environmental Scanning: Monitor external environment—market changes, competitive moves, regulatory changes, technology developments. Environmental changes may require architectural adjustments.
Planned Evolution: Based on assessment, feedback, and environmental scanning, plan architectural evolution. Updates might involve process improvements, technology upgrades, organizational restructuring, or strategy adjustments.
Agile Approach: Rather than rigid long-term plans, many organizations adopt rolling planning, planning near-term with more detail and farther-out periods with less detail. As organization learns and environment changes, plans roll forward with periodic updates.
Challenges in Enterprise-Wide Architecture Practice
Complexity Management
Enterprise-wide architecture addressing all organizational dimensions at scale involves enormous complexity:
Scope Explosion: When architecture encompasses business, data, applications, technology, organization, governance, risk, and strategy, scope becomes large quickly. This can make enterprise architecture feel overwhelming and difficult to manage.
Stakeholder Diversity: Unlike IT architecture which primarily involves IT stakeholders, enterprise-wide architecture involves diverse stakeholders with different concerns, terminology, and priorities. Coordinating these diverse stakeholders is challenging.
Measurement Difficulty: Enterprise-wide architecture claims to improve organizational effectiveness, but isolating architecture contribution from other factors is difficult. How much of business improvement results from architecture work versus other initiatives?
Governance Complexity: Governance bodies addressing enterprise-wide architecture decisions must include diverse perspectives and make decisions reflecting organizational values. Effective governance is difficult to establish and maintain.
Organizational Resistance
Enterprise-wide architecture can threaten existing organizational arrangements:
Power Redistribution: Architecture might reveal that current organizational structure is suboptimal. Restructuring to align with architecture would shift power, budgets, and influence. Those perceiving power loss often resist.
Disruption Risk: Large-scale organizational change carries disruption risk—productivity loss, employee departures, implementation failures. Understandable organizational resistance emerges.
Change Fatigue: Organizations undergoing major transformations often experience change fatigue—people are overwhelmed by continuous change and resistant to additional change.
Short-Term Pain: Architecture-driven organizational change often involves short-term pain (restructuring costs, productivity loss, people displacement) for long-term benefit. Organizations struggling with near-term business pressures may be reluctant to absorb short-term pain.
Technical Challenges
Enterprise-wide architecture supported by simulation, modeling, and analytics tools involves technical challenges:
Data Quality: Simulations and analytics depend on accurate, complete data. If organizational data lacks quality, simulation results are unreliable.
Simulation Complexity: Accurately simulating large, complex processes with many interdependencies is technically difficult. Simplified simulations might miss important dynamics.
Tool Integration: Enterprise architecture involves multiple tools—modeling tools, simulation engines, analytics platforms, documentation systems. Integrating these tools to work together seamlessly is challenging.
Skill Requirements: Enterprise-wide architecture requires sophisticated skills—process modeling, simulation, data analysis, business strategy, organizational design. These skills are scarce and expensive.
Future Directions and Emerging Practices
Artificial Intelligence and Architecture
Artificial intelligence is beginning to augment enterprise architecture practice:
Process Discovery: Machine learning algorithms can analyze system logs and transaction records to discover how processes actually work, rather than relying on documented processes that might differ from reality. This actual process discovery is more accurate than manual process documentation.
Simulation Enhancement: AI can make simulations more sophisticated and accurate. Machine learning can learn patterns from historical data and incorporate those patterns into simulations.
Optimization: AI optimization algorithms can suggest architectural improvements by analyzing large solution spaces and identifying promising options humans might miss.
Anomaly Detection: AI can detect when organizational performance deviates from expected patterns, identifying problems earlier than manual monitoring.
Knowledge Capture: AI can help capture and share architectural knowledge, making knowledge more accessible to broader audiences.
Blockchain and Distributed Architecture
Blockchain and distributed systems offer possibilities for enterprise architecture:
Process Transparency: Blockchain can create immutable records of process execution, enabling full transparency and audit trails. This transparency supports governance, risk management, and compliance.
Decentralized Processes: Organizations might design processes that execute across decentralized networks rather than central systems. Blockchain could enable these designs.
Smart Contracts: Automated contracts executing on blockchain could encode business rules directly into systems, improving compliance and reducing manual enforcement.
Trust and Verification: Blockchain's cryptographic foundation enables trust and verification without central authority, potentially enabling new organizational designs and partnerships.
Ecosystem Architecture
As organizations increasingly operate in ecosystems involving partners, customers, suppliers, and platforms, enterprise architecture expands to ecosystem level:
Multi-Organization Alignment: Architecture extends beyond single organization to coordinate across multiple organizations with different strategies and constraints.
Platform Architecture: As organizations operate on platforms (cloud platforms, marketplace platforms, industry platforms), architecture addresses how the organization integrates with and leverages platforms.
Value Network Design: Rather than value chains, organizations increasingly participate in value networks involving multiple parties. Architecture addresses how value networks are structured and how the organization creates and captures value within them.
Conclusion
Enterprise architecture has evolved from IT-focused discipline documenting technology environments to enterprise-wide practice addressing organizational complexity and enabling strategic change. This evolution reflects recognition that organizational challenges—operational efficiency, customer experience, strategic alignment, agility—cannot be solved through IT management alone but require comprehensive architectural thinking spanning business, data, applications, technology, organization, and governance.
BDAT architecture integrating business, data, application, and technology domains provides framework for this comprehensive thinking. Business process simulation and optimization enable organizations to design, test, and refine organizational approaches before implementing changes at scale. Multi-dimensional alignment across vision, strategy, standards, KPIs, risk, processes, data, applications, and technology creates coherent organizational wholes where different elements reinforce each other rather than creating friction.
Organizations undertaking large-scale digital transformation, organizational restructuring, or strategic change increasingly recognize enterprise architecture's value. When approached as enterprise-wide practice rather than IT specialty, architecture provides language, models, and analysis methods that enable executives, business leaders, and technical professionals to work together toward shared understanding and coordinated action.
The challenges are real—complexity, organizational resistance, technical difficulties. Yet the benefits—improved organizational efficiency, reduced costs, better customer experience, enhanced agility, more effective strategic execution—justify investment in enterprise architecture practice. Organizations that master enterprise-wide architecture, supported by simulation, modeling, and analytics capabilities, will increasingly outcompete organizations relying on ad-hoc decision-making and reactive change management.
The future of enterprise architecture involves increasingly sophisticated tools (AI-powered analysis, blockchain-enabled transparency, ecosystem-level architecture), deeper integration across organizational dimensions, and broader involvement of organizational stakeholders in architecture thinking and decisions. Enterprise architecture will increasingly be recognized not as IT specialty but as essential management practice—as important to organizational leadership as financial management, human resource management, and strategic planning.
References
Capgemini. (2020). Digital Transformation Review: The Era of AI and Intelligent Automation. Capgemini Consulting.
Gartner. (2021). Magic Quadrant for Enterprise Architecture Management Tools. Gartner Inc.
ISO/IEC/IEEE. (2015). Systems and Software Engineering - Architecture Description (Standard 42010). International Organization for Standardization.
Lappalme, J. (2013). Rethinking Enterprise Architecture Using a Fundamental Set of Principles. 2013 IEEE International Conference on System, Man, and Cybernetics, 1038-1043.
Lappalme, J. (2018). Systems Thinking and Enterprise Architecture. Enterprise Architecture Professional Journal, 8(1), 45-61.
Luftman, J., & Kempaiah, R. (2007). The State of IT-Business Alignment. Database for Advances in Information Systems, 38(1), 20-44.
Martin, J. (1990). Information Engineering Book II: Planning and Analysis. Savant Institute.
Mclaughlin, S., Weir, C., & Grom, L. (2018). Business Process Management Systems: Current State vs. Future Outlook. Journal of Information Systems, 32(2), 85-105.
NASEM. (2019). Reexamining the Relationship Between Applied Research and Innovation. National Academies of Sciences, Engineering, and Medicine.
O'Neill, P., & Sohal, A. (1999). Business Process Reengineering: A Review of Recent Literature. Technovation, 19(10), 571-581.
Parkinson, S., & Ramirez, R. (2016). Whole System Design: Using Design Thinking to Change the World. Business School Press.
Rechtin, E., & Maier, M. W. (2000). The Art of Systems Architecting. CRC Press.
Ross, J. W., Weill, P., & Robertson, D. (2006). Enterprise Architecture as Strategy: Creating a Foundation for Business Execution. Harvard Business School Press.
Schekkerman, J. (2004). How to Survive in the Jungle of Enterprise Architecture Frameworks. Trafford Publishing.
Tamm, T., Seddon, P. B., Shanks, G., & Reynolds, P. (2011). How Does Enterprise Architecture Add Value to Organisations? Communications of the Association for Information Systems, 28(1), 141-168.
The Open Group. (2018). TOGAF Version 9.2 - The Open Group Architecture Framework. The Open Group.
Truex, D., & Baskerville, R. (2000). Growing Systems in Emergent Organizations. Communications of the ACM, 43(8), 117-123.
Ummels, A., & Ould, M. A. (2013). Architecture for Tomorrow. The Pragmatic Programmers.
van der Merwe, A., & Kotze, P. (2014). Components of an Enterprise Architecture Framework. 2014 IEEE Transactions on Software Engineering, 40(2), 145-163.
Wagter, R., Proper, H. A., & Lankhorst, M. M. (2016). Enterprise Architecture - from IT to Business. Gartner.
Weill, P., Subramani, M., & Broadbent, M. (2002). Building IT Infrastructure for Strategic Agility. MIT Sloan Management Review, 44(1), 57-65.
Yin, R. K. (2009). Case Study Research: Design and Methods. SAGE Publications.
Zachman, J. A. (1987). A Framework for Information Systems Architecture. IBM Systems Journal, 26(3), 276-292.
Zachman, J. A. (2008). The Zachman Framework for Enterprise Architecture. Zachman Institute.
Zwass, V. (2010). Co-Creation: Toward a Taxonomy and an Integrated Research Perspective. International Journal of Electronic Commerce, 14(1), 11-36.