Applying EA Principles in Enterprise Technology Architecture
The article explains how enterprise architecture (EA) principles and design architecture principles (DAPs) should be defined, prioritized, and linked to business goals to guide technical standards, overcome resistance, and drive effective governance and behavioral change within organizations.
Applying EA Principles in Enterprise Technology Architecture
Principles are a formal part of EA work, providing a stronger link between personal decisions and broad business objectives that are independent of specific choices. When used correctly, key decisions in a solution can be traced back to business requirements and strategies, helping the IT organization justify why certain actions are taken.
Therefore, before completing designs or models such as technical patterns and services, it is useful to define and agree on Design Architecture Principles (DAPs). Connecting DAPs with overall EA and business principles simplifies adoption and genuinely changes behavior.
Priority Principles
Because many principles can help define rules for managing or evaluating solutions, they need to be prioritized. In some cases principles may conflict (e.g., low‑cost vs. high‑availability), requiring preset decisions about which principle takes precedence, although project‑specific goals can override them.
Making Technical Standards Effective
Technical standards are often ignored, especially in organizations where business people rarely participate in architecture. A key missing element is the link between architecture and business benefits; architecture must be driven by business strategy to provide context for weighing the benefits of standards against granting exemptions.
Barriers to this link include finding and analyzing business strategy, gaining business support for architecture, and establishing proper governance arrangements. Cultural resistance from IT staff who dislike constraints also hinders adoption.
Ways to Overcome Resistance
Create an architecture panic diagram – a visual tool that conveys the need to reduce IT portfolio complexity.
Opportunistically select projects that involve multiple business units, optimize end‑to‑end processes, or build enterprise‑wide customer/product views.
Build relationships within the enterprise – understand business problems and help propose solutions that can feed into the next architecture iteration.
Include key stakeholders in technical‑standard development – their perspectives add valuable evaluation and opinion, increasing support and willingness to apply standards.
Proactively collaborate with projects – architects should be part of the senior design team, fostering healthier relationships with all project stakeholders.
Make technical standards easy to find and use – publish them on the corporate intranet, document them clearly, and aggregate them into reusable technical patterns for specific use cases such as high‑volume online transaction processing or secure web access.
Figure 1
Figure 2
For more discussion, see the original article at https://architect.pub/principles-and-standards-technology-architecture .
Architects Research Society
A daily treasure trove for architects, expanding your view and depth. We share enterprise, business, application, data, technology, and security architecture, discuss frameworks, planning, governance, standards, and implementation, and explore emerging styles such as microservices, event‑driven, micro‑frontend, big data, data warehousing, IoT, and AI architecture.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.