This is a great article defining IA Principles:


Information architects still struggle to define the design principles that operate in their environment. Today I would like to give a set of design principles that was developed with an Information Architect a while ago. Design principles are not necessarily right or wrong but should be an accurate reflection of the fundamentals that guide decision making in an enterprise. The following should therefore not be seen as design principles fixed in concrete but rather as examples of business principles. Best practice is to define the design principle in terms of its Benefits and rationale as well as the implication to the enterprise and the counter argument expressing the potential negative impact of the design principle.

Design principle 1: Central management information


All management information and business intelligence will be sourced from a single consolidated source of information

• A central source of management information will provide the enterprise with a wide breath of reporting and analysis without being constraint by the organisations functional structuring.
• Users will become used to a single interface to management information allowing managers to become familiar with the infrastructure and extracting maximum benefit from all information available in the organisation.
• The central information will eliminate contradicting information sources and ensure accurate reporting of current affairs and identification of issues and opportunities.
• Increase the flexibility and manageability of providing information rapidly and effectively to support business decisions.
• Use best of breed analytic functionality to support management decision making
• Increased security in managing access to The enterprise’s management information

• Information must be sourced to the central information infrastructure from all the various operational applications as close to real time as possible
• No additional analytical modules are required for transactional applications.
• The interface to management information and training should be rolled out to all decision makers to effectively access information.

Counter argument
• The central management information might not be adequate in situations where real time analytics of transactional information is needed
• Information in the central information source might not be structured for a specific requirement and the development time might be too long to provide the information in time for a once off request.
• The assumption cannot be made that a single tool will satisfy all the information requirements. The information infrastructure will therefore consist of a variety of integrated tools.

Design Principle 2: Internationalisation

Information must be structured for global deployment in various cultures and support multi-currency, multi-language and multi platforms

• Flexibility to enter into other global markets
• Consistency of being able to deploy a proven business model and then adapt to local conditions

• Applications should be much more flexible to accommodate differences defined by different countries
• Current applications should be evaluated in terms of internationalisation requirements.

Counter argument
• Applications designated for use locally in South-Africa only does not have to comply to the internationalisation principle
• The enterprise might strategise to enter only into markets that have a certain set of international commonality which make the rigid application of this principle unnecessary
• It might be too expensive to change or replace legacy systems to adhere to the internationalisation requirement.

Design Principle 3: Single contact database


A single contact database for all business contacts e.g. policyholders, intermediaries and service providers

• A central source of information to manage relationships effectively
• Have a more comprehensive view of interrelationships between business contacts.
• More effective marketing campaign design and management

• High levels of data integration with transactional systems updating contact information.
• Transactional systems updating information must be assigned with levels of trust.
• Central contact information should not .complicate functional requirements to only view specific relationships.

Counter argument
• Some functional units might not want to share contact information for the fear that it might be used wrongly or out of context by other parts of the organisation.

Design Principle 4: Single point of authentication

Access for to information should be constraint through a single point of authentication infrastructure

• Improved security of information

• Central management of user access to information.

Counter argument
• The current infrastructure might not be mature enough to implement the principle.

Design Principle 6: Data quality measurement

Data quality will be measured both in quantitative and qualitative terms eg. Audit procedures and Data quality questionnaires

• Improved data quality
• Accurate usage of data
• Improved management information
• Increased operational efficiency

• Bi-annually measure data through with a data quality survey
• Audit data ownership procedures annually
• Build in data quality measures into applications
• Connect data quality results with performance incentives

Counter argument
• Regular audits and subjective measurement techniques e.g. surveys might be time consuming.

Design Principle 7: Formalised data exchange/enrichment

All data exchange/enrichment activities are managed and approved by the appointed data strategist and the exchange of information must be subjected to a standardised methodology for information exchange/enrichment.

• Control costs associated with data exchange and enrichment
• Protect operational data
• Improve data quality and value
• Data sharing to allow for better detection of fraud

• Development of a formal policy and methodology for data exchange and enrichment
• Data strategist must be responsible for approving data exchange/enrichment efforts and minimise cost.
• Identification and management of organisations that can enrich and/or validate the enterprise data.

Counter argument
• The formalised methodology should not become a constraint to enrich and improve data quality.
• The enterprise might not always be in a position to demand compliance from external parties to comply with data sharing standards.
• Current lack of industry standards might make it difficult to implement the principle.

Design Principle 8: Central repository of data naming standards

Data names and field content must be standardised through a central reference repository and must be accessible to the business e.g. Street rather than str. is used to reference a street.

• Consistency of information across all business processes
• Usability of information increases across the organisation.

• Alignment of all applications to support the standardised naming standards

Counter argument
• Difficulty to implement naming standardisation in some applications

Design Principle 9: Align information requirements with data model

All information requirements must be aligned with the corporate data model before requesting changes to the information architecture:

• Integrity of transactional data model stays in tact
• Prevent duplication of information

• The corporate data model must be maintained to be up to date at all times
• In any application development life cycle it is a condition to align the application with the corporate data model

Counter argument
Data owners might not understand the data model to update it with changes.

Design Principle 10: Information governance on all data elements

All information elements must be subjected to information architecture governance

• Sustain data quality
• Improve operational efficiency.

• Design the business process application of the data element
•Assign Applications sourcing the information
• Align with corporate data model, rules, validations, naming standard
• Define data management policies e.g. security, back-up, archiving/retrieval
• Assign data ownership

Counter argument
• Lack training to adhere to information governance
• Information governance is not adequately communicated

Design Principle 11: Data privacy and legality

Client privacy must be respected and legal requirements must be complied with, in any event of data exchange or commerce

• Maintain good relationships with clients and protect premium income
• Avoid legal costs due to mismanagement of information resulting in lawsuits.

• The enterprise must be up to date with laws relating to information
• Communicating The enterprise’s data policy to clients
• Legal department needs to be up to date with laws governing information usage, commerce and distribution

Counter argument
• Uncertainty of what constitutes data privacy might make it difficult to implement this principle.

Bottom line: Design principles for enterprise architecture must provide a decision framework based on a clear rationale defined in terms of the benefits, implications and counter argument relating to the design principle