101 Principles of Enterprise Architecture
posted by Anna Mar, June 27, 2016Principles are the foundation of your Enterprise Architecture — the enduring rules and guidelines of your architecture. They send an important message to your stakeholders — that EA recommendations are not arbitrary.
Principles should enable the business to achieve their strategy and be simple, consistent, flexible, enduring and useful:
One bad principle can lead to thousands of bad architectural decisions — principles must be chosen with care. Below are a few examples to inspire.
General
1. Non-proliferation of TechnologyTechnical diversity will be controlled in order to reduce complexity.
2. Compliance with Law
Compliance with all relevant laws and regulations.
3. Business Continuity
The enterprise will be resilient to internal and external threats.
4. Business Alignment
Every IT project must be aligned with business goals and strategy.
5. Common Use Solutions
Cross-silo solutions are preferred over duplicative silo specific applications, systems and tools.
6. Simple Solutions
IT will be as simple as possible. Where complexity is required it will be encapsulated and hidden behind a interface that is as simple as possible.
7. Quality
A minimum standard of quality will be maintained despite time to market concerns.
8. Think Globally, Act Locally
Solutions will consider the enterprise impact of architectural decisions.
9. Shared Resources
Solutions will seek to maximum sharing of resources such as network, computing, storage and data.
10. Protection of Intellectual Property (IP)
Patents, copyrights, trade secrets and other IP will be preserved and protected.
Data
11. Information OpennessInformation must be open and available to support productivity and innovation.
12. Shared Asset
Data is a shared enterprise asset and can't be owned by a department, team or individual.
13. Information Relevance
Data must be business relevant and have value.
14. Data Currency
Data must be timely.
15. Protection of Data
Data is an asset that must be protected.
16. Data Confidentiality
Confidential data must be protected.
17. Data Stewardship
Data elements must have a designated trustee who is responsible for data quality.
18. Data Interpretation
Data definitions and vocabularies will be consistent throughout the organization.
19. Globally Unique Identifier
Business critical data objects will have a globally unique identifier.
20. Master Data
All data will have a golden copy.
21. Data Backup
All data will be backed up.
22. Data Validation
Data will be validated at the point of collection.
23. Data Corrections
Data corrections will occur in the system furthest upstream and be cascaded down.
24. Data Retention Policy
Master data repositories will maintain a data retention policy that is in line with enterprise and regulatory requirements.
25. Data Quality
Data quality targets will be published for all master data repositories.
26. Decoupled Data
Data should be maintained in a separate data layer decoupled from applications.
27. Re-keying
Users will never be asked twice for the same data.
Data Integration
28. Real-time IntegrationReal-time integration is preferred over batch integration.
Service Oriented Architecture (SOA)
29. Separation of ConcernsIt will be possible to change a component with minimal impact to other components.
30. Loosely Coupled Services
Services will be loosely coupled (producers loosely coupled from consumers).
31. Self Describing Services
Services will be self-describing.
32. Reusable Services
Services will be designed to maximize enterprise wide reuse.
33. Discoverable Services
Services will be discoverable.
34. Service Abstraction
Services will hide their underlying implementation details.
35. Service Statelessness
Services should avoid saving state where possible.
36. Service Autonomy
Services should have significant control over the functionality they provide.
37. Policy Driven Security
Services will have a defined security policy.
Usability
38. Equitable UseUser interfaces will be designed to maximize accessibility (to as wide an audience as possible).
39. Easy of Use
User interfaces will be as simple and intuitive as possible.
40. Learnability
An application should be easy to learn.
41. Technology Transparency
Underlying technical implementations should be hidden from users.
42. Fail-safe
User interfaces will provide fail-safe features to protect users from unintended consequences of actions.
43. Consistent Navigation
Content and navigation will be consistent.
44. Predictable Interface
User actions should have predicable results.
Processes
45. Zero TouchManual tasks should be managed as a workflow.
46. Straight Through Processing
Enterprise level processes will be automated end-to-end including integrations with customers and partners.
47. Productivity
Processes will seek to maximize productivity.
48. Process Reinvention
When a new system is implemented — impacted processes will be investigated for simplification.
49. Continuous Improvement
Processes will be designed from the ground up to support continuous improvement.
50. Process Realism
Processes will reflect the real world.
51. Problem Identification
Processes should be designed to bring problems to the surface as soon as they occur.
Business
52. Business GoalsBusiness units will publish business goals and strategy.
53. SMART Business Goals
Business goals will be Specific, Measurable, Attainable, Relevant, Timely.
54. Customer Focus
Architectural decisions will seek to maximize value to the customer.
55. Simplified Operations
Architectural decisions will seek to simplify operations.
56. Response to Customers
Customer requests will be addressed in a timely manner.
57. Long Term Focus
Decisions will be based on long term strategy — even at the expense of short term profitability.
58. Time to Market
Business units will respond to opportunities in a timely manner.
59. Threats
Business units will respond to external threats in a timely manner.
60. Empowerment of Employees
Employees will be empowered to do their jobs.
61. Diligent Requirements
Business will provide rigorous functional and non-functional requirements for projects.
62. Quality First
Honest errors are not punished and stopping to fix problems is encouraged.
Applications
63. MobilityApplications should be built to maximize the locations from which they can be used.
64. Extensibility
Applications will provide hooks that allow functionality to be extended in future.
65. Flexibility
Applications will be architected to minimize the costs of future changes.
66. Monitoring and Measurement
Applications will designed to support monitoring and measurement.
67. Platform Independent, Open Standards
Applications that support open standards are preferred.
68. Interoperability
Applications will be interoperable.
69. Application SLA
All applications will publish a SLA that has been agreed upon with the business.
70. High Availability
All applications will publish availability targets that have been agreed upon with the business.
71. Application Documentation
Applications must have architecture, design and runbook documentation.
72. Capacity Management
IT capacity will meet current and future business requirements.
73. Reuse of Components
Where possible applications will re-use existing components.
74. Standards Compliance
Applications will comply with established standards, conventions, agreements, processes, practices and methods.
75. Scalable
Applications will be designed to handle higher loads when allocated more resources.
76. Error Robustness
Applications will handle errors in a controlled fashion and continue to operate normally (graceful degradation).
77. Modernization
Applications have a limited life span — end of life should be anticipated and plans for replacement developed.
78. Minimum Feature Set
Features add complexity and should be kept to a minimum (avoid bells and whistles and systematic handling of improbable exceptions).
79. Collaborative
Applications should consider incorporating tools to facilitate collaborative processes.
Technology (General)
80. Bleeding EdgeExperimental or early release technologies will not be used unless they are critical to competitive advantage.
Security
81. Separation of DutiesThe builder and operator of a application will be independent roles.
82. Security by Design
Security is embedded into business, application, data and technology architecture.
83. Security is a Management Discipline
Security is more than a technical problem. Security needs to be managed at every level of the business.
84. Confidentiality
The confidentiality of sensitive data will be maintained.
85. Security Transparency
Security supports business goals and should be as transparent as possible.
86. Defence in Depth
Security will be layered.
87. Least Permissions
Security privileges will be just enough to perform requisite activities.
88. Balanced Controls
Security controls will be balanced and proportional to risk.
89. Cost-effective Security
Security costs need to be balanced with security benefits.
90. External Security Responsibilities
The organization has security responsibilities to customers, partners and regulators.
91. Security Ownership
Security accountabilities and responsibilities should be made explicitly clear.
92. Security Reassessment
Security is not a one time activity — it must be periodically reassessed.
93. Enterprise Security
Security must be considered at the Enterprise level (not only at the system or departmental level).
94. Consistent Policy
Security policies will be applied consistently across the enterprise.
95. Security Requirements
System requirements must specify security features, controls, and operational practices.
96. User Management
All systems must have defined processes for requesting, issuing, and closing user accounts.
97. Direction of Threat
Both internal and external threats will be considered in security architectures.
98. Audit Trail
All significant user and system actions should leave an audit trail.
Infrastructure
99. Horizontally ScalableInfrastructure should be capable of scaling up by adding devices.
100. Logical Partitioning
It should be possible to logically partition infrastructure capacity.
101. Enterprise-wide Security
Infrastructure should enable enterprise-wide security.
Tailoring
The principles above are only intended as samples to inspire. Your principles should be based on the nature of your business and the maturity of your organization.
IT Governance
Information technology governance
|
|
Back-to-basics ITIL definitions that may serve as a useful executive overview. |
|
Understanding your vulnerabilities is the first step to managing risk. |
|
Should EA report to the CIO? COO? CFO? CEO? How about the Board of Directors? |
|
The most important diagram in all of business architecture — without it your EA efforts are in vain. |
Recently on Simplicable
| Honeypot Explained (Security)posted by Anna MarA honeypot is decoy designed to distract attackers from your information infrastructure. |
|
| The Difference Between Public, Private and Hybrid Cloudposted by Anna MarPopular ideas such as cloud computing get twisted, turned and flipped upside down before anyone can agree on common definitions. |
| 5 Levels of Tech Savvy Blissposted by Anna MarModern technology customers and industry insiders are faced with a constant stream of change. Human ability to adapt to this pace of change is remarkable. |
