Enterprise Architecture
Principles
Architecture Principles are the set of rules to guide business, information and technology decisions. They apply to the initial solution design, and across the lifecycle of any service and its components through incorporation into change procedures.
Principles provide an agreed reference or policy to be used for evaluation of alternatives and as the basis for decisions. The Principles' relative value may vary based on a particular decision to be taken.
DEVELOPING ARCHITECTURE PRINCIPLES
The Architecture Principles are relevant to the enterprise that represents the delivery organisation. In an Outsouring or Managed Services arrangement, the ultimate delivery organisation is the client, however the principles then also need to consider the full context including the interests of both the client and the provider - which has particular relevance for cloud services and XaaS. Principles then need to be compatible across both organisations. Where services may be provided as one part of a multi-sourcing arrangement with other ICT providers, then the principles should be consistent, or at least complementary, across the environment.
Principles should be specific to each individual customer's business, but can be derived from a standard reference set.
Principles are applied at each level - Business Architecture, Information Architecture, Systems Architecture and Infrastructure Architecture. Principles need not be limited to the Architecture levels, but can also be applied to a wider perspective such as for processes, for security or as general principles where they are relevant to, and provide guidance for ICT.
| RECOMMENDED FORMAT FOR DEFINING PRINCIPLES | |
| Name | Should both represent the essence of the rule as well as be easy to remember. Specific technology platforms should not be mentioned in the name or statement of a principle. Avoid ambiguous words in the Name and in the Statement such as: "support", "open", "consider". Be careful with "manage(ment)", and look for unnecessary adjectives and adverbs (fluff). |
| Statement | Should succinctly and unambiguously communicate the fundamental rule. For the most part, the principles statements for managing information are similar from one organisation to the next. It is vital that the principles statement be unambiguous. |
| Rationale | Should highlight the business benefits of adhering to the principle, using business terminology. Point to the similarity of information and technology principles to the principles governing business operations. Also describe the relationship to other principles, and the intentions regarding a balanced interpretation. Describe situations where one principle would be given precedence or carry more weight than another for making a decision. |
| Implications | Should highlight the requirements, both for the business and IT, for carrying out the principle - in terms of resources, costs,
and activities/tasks. It will often be apparent that current systems, standards, or practices would be incongruent with the principle upon adoption.
The impact to the business and consequences of adopting a principle should be clearly stated. The reader should readily discern the answer to:
"How does this affect me?" It is important not to oversimplify, trivialise, or judge the merit of the impact. Some of the implications will be identified
as potential impacts only, and may be speculative rather than fully analysed.
|
|
Source: The Open Group References:
| |
EXAMPLE ARCHITECTURE PRINCIPLES
The following are examples and are not intended to be comprehensive.
BUSINESS ARCHITECTUREWho defines a Business Architecture, and who sets out the Business Architecture Principles? Many organisations will have defined domain architectures and principles. Many more won't. So, does the Enterprise Architect then invent them? The purpose of Architecture Principles, and Architecture Views and Viewpoints, is to establish a clear, common reference and context for ICT systems and services and their development and deployment over time in line with business goals. While an Enterprise Architect's role is not to build or operate a busines or an organisation, an EA should be engaged with the business so that its interests and its objectives and strategies are best served by ICT architectures. Should any client organisation not have structured and defined Business Architecture and Principles, an Enterprise Architect should be in a position to develop them in consultation with the business, and have the business validate them. Aligning architectures with the business requires that the effort is expended and that the outputs are validated. | |
| Principle 1 | Business Goals |
| Statement: Business units will publish business goals and strategy that will be Specific, Measurable, Attainable, Relevant and Timely. | |
| Rationale: Clear, agreed business goals establish and align the objectives for all activities undertaken within the organisation. | |
| Implications: The contribution to achieving business goals is to be articulated for all architectures. Unqualified statements of the 'contributes to greater efficiencies' kind are to be avoided. The contributions are to be qualified and should be measureable. | |
| Principle 2 | Customer Focus |
| Statement: Architectural decisions will seek to maximise value to the customer. | |
| Rationale: All functions have a purpose. The customer can identify the value they derive from the services that substantiates the price that they pay. Customer value will be linked to Business Goals. | |
| Implications: Architecture considerations will extend beyond the end user and will consider the end users' interactions with their customers. | |
| Principle 3 | Simplified Operations |
| Statement:Architectural decisions will seek to simplify operations. | |
| Rationale: Complexity adds to costs, adds a greater chance of failure and adds delay. | |
| Implications: Architecture is to include, as inputs, a contribution to simplifying the operational activities it supports, and the operational activities required to support the architecture. | |
| Principle 4 | Long Term Focus. |
| Statement: Decisions will be based on long term strategy. | |
| Rationale: Architecture will look beyond immediate requirements, where it can develop and adapt in line with long term Business Goals and strategies. | |
| Implications: A Future State architecture will be devised based on a desired capability that addresses long term Business Goals that forms the basis for Target State architectures as a Technology Roadmap. | |
| Principle 5 | Empowerment of Employees |
| Statement: Employees will be empowered to do their jobs. | |
| Rationale: Employee empowerment is a strategy and philosophy that enables employees to make decisions about their jobs. Employee empowerment helps employees own their work and take responsibility for their results. Employee empowerment helps employees serve customers at the level of the organisation where the customer interface exists. | |
| Implications: Employees should have access to the information required to do their jobs, in the appropriate format, at the time it is needed using the devices that are most appropriate to their needs. | |
| Principle 6 | Diligent Requirements |
| Statement: Business will provide rigorous functional and non-functional requirements for projects. | |
| Rationale: A functional requirement specifies what a system should do. A non-functional requirement is a statement of how a system must behave. | |
| Implications: Functional requirements drive the application architecture of a system, while non-functional requirements drive the technical architecture of a system. | |
INFORMATION ARCHITECTUREInformation architecture is the art and science of organising and labelling websites, intranets, online communities and software to support usability. As information proliferates exponentially, usability is becoming the critical success factor for websites and software applications. Good IA lays the necessary groundwork for an information system that makes sense to users. (Information Architecture Institute). Information architecture principles should be relevant - they can apply across a wide range of scenarios from the way information is presented on a Web page, to an IaaS facility with a priority on information access and protection through to the way information is handled as it transits a network. | |
| Principle 7 | Information Openness |
| Statement: Information must be open and available to support productivity and innovation. | |
| Rationale: Information is valuable when it is accessible. Information access empowers employees - Principle 5. Information is an asset that needs to be shared (Principle 8) yet also protected - Principles 11 & 12. | |
| Implications: A successful balance between information security and information access requires clarity in the
classifications for information - Principles 11 & 12. Security risks need to be carefully considered to apply the right balance between openness and security. | |
| Principle 8 | Shared Asset |
| Statement: Data is a shared enterprise asset and can't be owned by a department, team or individual. | |
| Rationale: In a Knowledge economy, information is a valuable asset that should be shared - the 'Knowledge Is Power' syndrome
is to be avoided. Information, treated as a shared asset, facilitates Information Openness - Principle 7. | |
| Implications: Centralised repositories should be used for repositories, with access open to all those with the right to know. Collaboration tools and functions should be encouraged. | |
| Principle 9 | Information Relevance |
| Statement: Data must be business relevant and have value. | |
| Rationale: Relevance denotes how well a retrieved document or set of documents meets the information need of the user
(Information Retrieval). Retaining data is a cost - irrelevant data has no value. Relevant data and information is more able to be identified and accessed where it is not hidden amongst irrelevant material. | |
| Implications: Data search-ability using effective meta-data, classifications and archiving provides for access to
information that is relevant to the user. Data should be in a format that is relevant. | |
| Principle 10 | Data Currency |
| Statement: Data must be timely. | |
| Rationale: Out-of-date data is misleading. | |
| Implications: Currency is determined by the Business requirements - a long term focus (Principle 4) will need data over an extended period; whereas access to immediate data is necessary in many contexts - for example, share trading or military operations. However, in both of these examples, long term planning is also required, so the context needs to be considered at various levels within any organisation. | |
| Principle 11 | Protection of Data |
| Statement: Data is an asset that must be protected. | |
| Rationale: 'Knowledge Is Power' is a valid position at organisation level (Principle 8) - information provides a competitive and capability advantage. Protection of data needs to be balanced with access to data - Principles 7 & 8. | |
| Implications: Regulatory constraints should be identified Data protection covers Data Exchanged and Data At Rest. | |
| Principle 12 | Data Interpretation |
| Statement: Data definitions and vocabularies will be consistent throughout the organisation. | |
| Rationale: Ambiguity leads to misinterpretation and incorrect conclusions. | |
| Implications: From IBM developerWorks Developing trust in enterprise information assets requires organisations to develop and share a common understanding of business vocabulary. Business metadata documents the business meaning and categorisation of data assets. It is defined in business language, and it is independent of technology. Types of metadata:
| |
SYSTEMS ARCHITECTUREA systems architecture is the logical model that defines the structure, behaviour and more views of a system. An architecture description is a formal description and representation of a system, organised in a way that supports reasoning about the structure of the system which comprises system components, the externally visible properties of those components, the relationships (e.g. the behaviour) between them, and provides a plan from which products can be procured, and systems developed, that will work together to implement the overall system.Wikipedia Systems Architecture principles should be generic, and not based upon particular capabilities of a known system or vendor product. Appropriate systems should be identified based on their ability to meet the specified Principles, as the purpose of the Principles is to guide decision making.
| |
| Principle 13 | Mobility |
| Statement: Systems access should be independent of users' locations. | |
| Rationale: Users' locations are subject to change. Organisation locations are subject to change. Users should have the flexibility to work from any location. | |
| Implications: Systems should not constrain where work can be undertaken. Premises-based systems should allow for external access. Cloud-based systems (private or public) have an inherent advantage. Wireless systems have an inherent advantage. Security principles are to be adhered to. BYOD is a rapidly developing trend. | |
| Principle 14 | Platform independence |
| Statement: Options should not be constrained by proprietary systems, and open standards should be applied. Systems will comply with established standards, conventions, agreements, processes, practices and methods. | |
| Rationale: Allow for maximum flexibility and adaptability. | |
|
Implications: Systems need to interoperate and provide for a common user experience. New systems need to be backwards compatible. Open standards allows for re-use of components. | |
| Principle 15 | Monitoring and management |
| Statement: Systems should be able to be monitored where such monitoring serves a defined purpose and delivers a quantifiable benefit. Systems should be managed remotely as much as possible. | |
| Rationale: Monitoring should serve a purpose such as compliance with Service Levels and security policies. Remote management reduces costs. | |
|
Implications: Service Levels themselves should be linked to business outcomes. Security policies need to balance accessibility with protection. | |
| Principle 16 | Scalability |
| Statement: Systems should allow for growth while minimising investments in additional components. | |
| Rationale: Systems need to adapt to changing demographics and demands. Systems need to be scalable for capacity and functionality. | |
| Implications: The costs for allowing for scalability need to be considered in terms of business growth forecasts, and across the lifecycle of systems where possible. | |
| Principle 17 | Collaboration |
| Statement: Systems should provide for collaborative working through multiple media channels as far as is practicable. | |
| Rationale: Collaboration adds to efficiencies and innovation.. | |
| Implications: Multi-channel communications should be an inherent systems feature where they prove to be cost effective or to deliver a qualifiable benefit. | |
INFRASTRUCTURE ARCHITECTUREAs with Systems Architecture Principles, Infrastructure Architecture Principles should be generic, and not devised from the features of any particualr technology or product. The Principles are used to guide the architecture from which the appropriate technology and/or product can be nominated. | |
| Principle 18 | Coverage |
| Statement: Infrastructure should provide for an optimal footprint. | |
| Rationale: Systems need to be accessible from a maximum number of existing or potential locations. | |
|
Implications: Fixed, wireless and satellite communications and their relative merits and deficiencies need to be considered. Remote working and working from home are considerations. | |
| Principle 19 | Reliability |
| Statement: The availability of Infrastructure needs to support the availability requirements of critical applications at locations where they are used. | |
| Rationale: It is pointless having required availability metrics if they are not supported end-to-end. | |
|
Implications: Service levels across multiple domains should be complementary. Diversity provides for higher availability. Reliability needs to be factored into Availability Management and Business Continuity planning, or preferably vice versa. | |
| Principle 20 | Capacity |
| Statement: Infrastructure capacity must allow for peak loads. | |
| Rationale: Cyclical demand and special events need to be considered so that a consistent service quality is deliverable regardless of variations in demand. | |
| Implications: Infrastructure should be scalable, and preferably provided on a pay-for-use basis. Capacity Management - Capacity usage should be monitored and trended over time. | |
| Principle 21 | Integration |
| Statement: Integrated infrastructure reduces complexity. | |
| Rationale: Reduced complexity reduces costs and improves manageability and facilitates collaboration. | |
| Implications: Integration can affect the impacts of service interruptions. Integrated infrastructure needs to consider reliability. | |
SECURITY ARCHITECTURESecurity is applicable across all levels of architecture, and is not treated as a separate architecture level. Security systems (firewalls, IDS/IPS etc.) may be treated as specific architecture(s) or component architectures at the Systems level (as a Mission System or a Support System) - however security applies at all architcture levels from Business through to Infrastructure. | |
| Principle 22 | Security by design |
| Statement: Security is inherent in Business, Information, Systems and Infrastructure architectures. | |
| Rationale: Security is effective only where it is applied across all potential areas of vulnerability. | |
|
Implications: Security policies need to be defined so that architecture can consider them as design inputs. Security needs to be complementary across each level of architecture. | |
| Principle 19 | Defence In Depth |
| Statement: Defence-In-Depth applies security at multiple levels using multiple techniques to protect against real and potential vulnerabilities. . | |
| Rationale: A Defence-In-Depth approach to network security creates a network infrastructure that is highly resilient to both internal and external attacks. Building Defence-In-Depth security entails deploying different forms of security in various places throughout the converged network to mitigate a mix of risks. By setting up multiple checkpoints between a user attempting to gain network access and the intended destination data resource, organisations can accurately verify user access rights. | |
| Implications: Defence-In-Depth is a proactive practice that requires specialist knowledge and ongoing planning and testing. | |
| Principle 20 | Balance |
| Statement: Protection of information assets will be balanced with accessibility for authorised users. | |
| Rationale: Security should not unnecessarily inhibit business through unnecessary constraints on access to data and information that is necessary for an organisation to undertake its operations. | |
| Implications: Classification of data, effective identification of users and proper authentication is essential. | |
The 4 Levels of Enterprise Architecture