Developing Enterprise Architecture Principles which align to Strategy

Every organization either annually or bi annually develops a strategic plan for their enterprise. They develop all the key elements of a good strategy, goals, objectives, strategy and tactics. Many companies use Key Performance Indicators (KPIs) to develop performance metrics to measure the success of key tactics that are identified or Objectives and Key Results (OKR's) which is used as a metric that outlines an organizations objectives along with clear defined key results.

If an organization has maturity with this process the implementation of this process will cascade down to every employee to ensure everyone is on the same page as to what the organization should be focused on. Where I see organizations missing the mark is that they do not develop enterprise architecture principles which are directly aligned to the business's strategy. These principles cascade into how technology decisions or governance is assured as projects cycle through, so if there is not alignment, leaders will not have real visibility when these decisions are made or how those decisions align to the strategy.

Enterprise architecture principles are a set of guidelines which improve the consistency and quality of technology decision making. Typically the tactics or initiatives which have been identified to help an organization achieve a strategy have an associated effort or project to acquire or modify systems to improve a service. Principles which are aligned to an enterprise strategy ensure that decisions being made stay aligned to the company's strategic objectives by using the technical processes which already exist in IT Governance.

The good news, once you have established a solid base of principles which adhere to industry best practices, cybersecurity and compliance standards, modifying them during your strategic planning is a cake walk but you need a solid base from which to begin.

Over the years, I have been gathering a set of standard principles from all kinds of organizations and gradually improving, modifying and grooming them. These principles can easily apply to most organizations and can be modified pending on a company's focus.

Should you have additional principles to add to this list, please send me a note and I will incorporate. Feedback is always welcome!

Operational Excellence Principles

These principles should directly tie to your goals and objectives where the enterprise is either trying to improve or maintain operational excellence within the enterprise.

PRINCIPLE 1: SOLUTIONS SHOULD BE BUSINESS EVENT DRIVEN

Statement: Solutions must respond to state changes of business transactions; they must preserve the integrity of the event and the solution response.

Rationale:

• Business event driven solutions promote customer centric architectures and increase visibility to the business.
• Interactions between systems and events are formally defined; adhere to a communication standard and have measured performance.
• Cohesive modules are easier to change, test and reuse.
• Loosely coupled modules are easier to change, test and reuse.
• Enables better understanding of the impact or ramifications of a change.
• Reduces development time and total cost of ownership.

Implications:

• Solution revitalization efforts must ensure that the target solution is business event driven.
• Business Transactions are event initiated and integrity will be maintained and monitored. Business processes should be business event initiated.
• Each solution component, application, and architecture artifact must be well documented.
• Solution components and architecture elements must be clearly distinguished from the mechanisms that allow them to interact.
• Compliance business rules must be embedded in solutions in a manner that minimizes the need for change in solution or application programming logic.

PRINCIPLE 2: PURCHASE RATHER THAN DEVELOP SOLUTIONS

Statement: Technology, application and services shall be purchased off the shelf if the solution meets more than 70% or more of the requirements.?Technological diversity should be controlled to minimize the costs of maintaining multiple products providing common capabilities defined by these business requirements.

Rationale:

• Commercial products can provide a greater longevity, supportability and are therefore more sustainable; whereas in house developments are likely to be constrained by company staffing and experience limitations.?
• Commercial Off-The-Shelf (COTS) products often provide a wealth of business logic, process modelling and workflows already developed or that can been altered to meet the enterprises requirements.?
• Commercial products adapt to the collective feedback and experience of more than one organization resulting in a system that incorporates more functionality and adapts to a broader range of security events.

Implications:

• There will be detailed business requirements defined prior to procurement of a technology.?Evidenced based requirements mapping must be provided.
• Supplier and contract management must be included during requirement gathering activities.
• Supplier and contract management must be active within the software and middleware management lifecycle.
• The acquisition of a solutions must include:
• Formalized training must be included into scope of implementation.
• Implementation of all standard operating procedures for operational support.
• An upgrade roadmap for maintaining compliance and security for the expected life of the solution.

PRINCIPLE 3: SOLUTIONS ARE RESILENT AND AVAILABLE

Statement: Solutions shall be constructed and implemented in a manner that ensures that business capabilities continue to be available in the face of a component failure, underlying changes in the technology, adverse events and continue to meet the business needs.

Rationale:

• Ensures business service levels are attained and business can continue even in the face of an adverse event.
• Ensures that transition from an existing solution to a newly developed or acquired solution is achieved with minimum business impact.
• Enables service maintenance outages to be planned in a manner that minimizes business impact.
• Ensures business survival by reducing the impact of a disaster or major failure.

Implications:

• Enterprise must establish system availability architecture commensurate with stated SLA’s.
• Resiliency and availability is well represented in applicable non-functional requirements.
• Preventive maintenance shall employ periodic inter-site and intra-site failover testing.
• Enterprise must periodically perform system portfolio reviews to ensure application health is maintained and consistent with business requirements.
• The environment, as a whole, must be able to detect attacks or adverse conditions.
• In the face of component failure, the environment as a whole would remain functional to the level service permitting the completion of its mission.
• Following a component failure, resiliency procedures exist to restore back to service.
• Development risk is reduced when stable reliable components are reused.

PRINCIPLE 4: SOLUTIONS MUST SUPPORT AN INTEROPERABILITY, MODULAR MODEL

Statement: Solutions, software applications and technology components must be designed, developed and implemented in support of a modular model.?

Rationale

• Permits change to an architectural element with minimized impact on collaborating elements.
• Allows for the reuse of software components across different modules and within the architectural model.
• Reduces overall IT and Process complexity, in turn reducing Total Cost of Ownership of the systems that work well together.
• Allows for the creation and reuse of common user interfaces and components across multiple business applications.
• Allows for development and maintenance of different modules to be handled individually given well defined interfaces.
• Promotes the use of middleware for system integration, and may provide opportunities to derive greater value from a given system through reuse.
• Enterprise must include adaptive capabilities (interoperability, portability, flexibility, scalability and reusability) in the design, development and/or acquisition of software technology components.

Implications:

• Enterprise must establish and follow an approach to integration and interoperability.
• Enterprise must establish and follow a conceptual architecture that clearly defines architectural tiers as conceptual architecture components.
• The integration and interoperability approach must adhere to the conceptual architectural model.
• Interactions between modules should be accomplished via well defined interfaces and standard protocols.
• An integration and interoperability approach must be constructed to ensure the separation of business functionality and technology elements.
• Enterprise must ensure established solution components are serviced by multiple layers of operational support (automated monitoring, IT Help Desk, IT operations, subject matter experts).
• Vendor solutions and technologies must be evaluated for their ability to provide interoperability.

PRINCIPLE 5: SOLUTIONS MUST BE PHYSICALLY SECURE

Statement: Solutions must be deployed in a manner that ensures the security of enterprise physical assets and ensures the fulfillment of the business availability requirements as necessitated by business compliance policies and enterprise security policies.

Rationale:

• Preserves the value of enterprise assets by protecting them from loss or unauthorized use.
• Contributes to assuring information quality of enterprise and customers, proprietary information which in turn serves to increase confidence and customer satisfaction.
• Ensures that exposure to physical loss is mitigated.
• Contributes to business continuity by protecting the availability of business and information technology capabilities.

Implications:

• Enterprise must create a conceptual architecture model that contains a facilities component.
• Threat models must be an element of the conceptual architecture facilities component.
• Solutions must employ classification models governing deployment.
• Physical loss exposure analysis is part of the solutions process.
• Solutions must adhere to enterprise physical asset protection standards.

PRINCIPLE 6: MONITOR OPERATIONAL PERFORMANCE

Statement: A solution shall be measured to monitor its performance in relation to the enduring qualities.

Rationale:

• Ensures business service levels are attained.
• Ensures solutions are performing to design expectations.
• Allows for measurement of business usage and comparison to planned usage.
• Permits rapid identification of failure points or components reaching design tolerances.

Implications:

• Enterprise must establish a consistent business application monitoring capability for all applications that affect enterprise core missions.
• Real time fault isolation, event logging and transactional latency must be accessible to monitoring, trending and metrics.
• Monitoring shall be part of test environments and evaluated for proper operation prior to promotion to production environments.
• Enterprise must identify and adopt technologies to enable monitoring, trending and analysis of performance metrics.
• Performance measurement models shall be applied to new solutions and retrofitted to existing solutions when practical.
• Performance measurement is a consideration of solution architecture.
• Critical equipment monitoring measures are utilized in trend analysis models to predict and prevent failure.

PRINCIPLE 7: SOLUTIONS MUST BE SCALABLE

Statement: Solutions should be scalable (up or down) in size, capacity and functionality.?

Rationale:

• Allocates the appropriately sized technical solution to satisfy business need.
• Provides agility in support of business growth and changes to the business and technical requirements.
• Extends the lifetime of solutions and enables reuse of solution elements.

Implications:

• Scalability requirements may increase the initial costs of development and implementation.
• Solutions must have planned capacities for known and unpredicted growth. Solutions must have planned capacities for known and unpredicted growth.
• Solutions must be designed to scale the addition of additional instances of the application to support the workload or to utilize additional resources made available to the application host on which the solution runs.

PRINCIPLE 8: TECHNOLOGY MUST BE STANDARDS BASE

Statement: Solutions must incorporate industry-accepted technology standards with a preference to open architecture solutions.

Rationale:

• Enables measured and consistent software delivery.
• Reduces reliance on specific vendor implementations and proprietary technology.
• Provides application development areas with guidance.

Implications

• Enterprise must establish a capability to examine, adopt, promote and integrate technical standards and corporate policies.
• Enterprise must establish a solutions review practice that ensures that all development projects are adhering to approved standards
• If no explicit industry standard exists in a solution space, enterprise should select the de facto standard and/or work with industry principles to develop a shareable, open standard.

PRINCIPLE 9: RESPONSIVE CHANGE MANAGEMENT

Statement: Changes to the enterprise information environment are implemented in a timely manner.

Rationale:

• The information environment must be responsive to their needs of the people using the environment.
• Requestors for change should clearly know and understand how to engage and request change.
• Requestors for change should be able to track how their change is progressing through the process.

Implications:

• Processes for managing and implementing change must be developed that are efficient and timely while ensuring compliance.

PRINCIPLE 10: EASE OF USE, INTERFACES MUST BE WELL DEFINED

Statement: Applications should be easy to use and the underlying technology is transparent to users. The user interfaces should be clearly defined and adhere to enterprise user interface and UX standards.

Rationale:

• Ease-of-use encourages users to work within the integrated information environment instead of developing isolated systems.
• Training is kept to a minimum, and the risk of using a system improperly is low.
• Creates standardized processes across user interface service design.
• Creates common platform for user interface design for all projects.
• Enable reduction of nonstandard configurations.

Implications:

• Applications will be required to have a common "look-and-feel" and support ergonomic requirements.
• Guidelines for user interfaces should not be constrained by narrow assumptions about user location, language, systems training, or physical capability.
• User experience and human factors engineering should be included with the acquisition, development or modification of any solution.
• A solution and its interfaces must be verified and validated by the systems’ end users.
• Interfaces must have precise and formal definitions.
• All collaborations are formally defined; adhere to a communication standard and have measured performance.
• Compliance with enterprise standards should be verified via automation.

Data and Information Management Principles

No matter what kind of enterprise you have, every company usually has goals around information management. Improving the quality or access, data protection and security of the information are absolutely essential to an organizations success. Below are some key principles you can tie directly to these kinds of objectives within your enterprise.

PRINCIPLE 11: LEAST PRIVILEGE

Statement: Access shall be granted on the basis of least privilege; rights model shall be employed to ensure that access and usage provisions grant the lowest level of access required to complete task.

Rationale:

• Protects enterprise assets by providing only the access necessary to perform a specific task.
• Supports “Information must be Judiciously Shared” principle.

Implications:

• Solutions shall employ role and task aware security models.
• User role based modelling should be performed during solution analysis.
• Access models shall be created that are role and task cognizant.
• Access models are reviewed and assessed according to a delineated schedule and on an ad hoc basis.

PRINCIPLE 12: INFORMATION LIFECYCLE IS PRESERVED

Statement: The integrity of an information element should be preserved throughout the lifecycle of the information.

Rationale:

• Lifecycle state integrity is required to ensure the non-repudiation of transactions.
• Information integrity is required to ensure information viability as an asset and Enables business compliance.

Implications:

• Supporting policies must have clear instructions on the lifecycle of the information.
• State transition models must delineate the progress of information through its lifecycle.
• Polices for read-only, online-archive, offline-archive and disposal are clearly identified and implemented.
• Performance and availability service level requirements are identified for older data.
• Information models are living artifacts.
• All parties to transactions shall be authenticated.
• Enterprise must develop transactional models that provides the end-to-end enterprise level business transaction monitoring and auditing capability.
• Non-repudiation of transactions will be applied in accordance with the transactional classification of a solution.
• Transaction information shall be retained in accordance to enterprise retention policies and standards.

PRINCIPLE 13: DATA SECURITY

Statement: Data is protected from unauthorized use and disclosure. ?Depending on the data classification, all parties to a transaction must be confident that the transaction is secure.

Rationale:

• Open sharing or release of information via relevant legislation must be balanced against the need to restrict the availability such information.
• Existing laws and regulations require the safeguarding of national security and the privacy of data, while permitting free and open access based on the classification.
• Pre-decisional (work-in-progress, not yet authorized for release) information must be protected to avoid unwarranted speculation, misinterpretation, and inappropriate use.
• Message integrity of a transaction is necessary for both sides of a transaction to trust that the sender’s intent is understood by the receiver.
• Non-repudiation of a transaction is necessary to minimize the enterprise exposure to liability.
• Confidentiality of a transaction is necessary when the nature or content of a transaction is proprietary between the sender and receiver.

Implications:

• Periodic data review and de-classification procedures to maintain appropriate control.
• Access control systems must ensure that policies and procedures are followed.
• Data security needs must be identified at the data level, not the application level in order to adequately provide access to open information while maintaining the information’s security.
• Data security safeguards can be put in place to restrict access relative to the classification of the data.
• Security classification must be designed into data elements from the beginning.
• Improved security posture and data management for the enterprise.

PRINCIPLE 14: SINGLE AUTHORITATIVE SOURCE

Statement: Information has a singular authoritative source that defines information content.?Information is defined, validated, maintained at its originating source.

Rationale:

• Ensuring information accuracy is less costly when it is defined at a single point.
• Information lifecycle state integrity is required for non-repudiation of transactions.
• Information validation at the source is necessary to support event driven solutions and interfaces must be well defined.

Implications:

• Information is defined once and Information is Judiciously Shared.
• Information lifecycles and usage must be modeled.
• Information includes the definition of metrics and performance measures.
• Aggregation and calculated inferences resulting from measures and their aggregations must be tied to an authoritative source.
• Shared information should not be replicated in other solutions unless it serves to increase the robustness of the overall architectural qualities between both the supplying and consuming solutions.

PRINCIPLE 15: INFORMATION IS JUDICIOUSLY SHARED

Statement: The enterprise desires that its solutions instill a practice of judicious information sharing.?Information shall be shared on the basis of cause; the means by which business information is shared will be determined by the classification of the information and arbitration of enterprise architectural qualities.

Rationale:

• This principle should directly align to the enterprise information governance policies.
• Information sharing is critical to avoiding information redundancy which contributes to maximize corporate benefit.
• Information sharing is critical to performance of different business functions.
• Information is shared based on the classification and to the stakeholders with appropriate entitlement.

Implications:

• Information metamodel must delineate the usage of information throughout the enterprise.
• Information sharing and exposed services are governed by enterprise information management policies.
• Solutions must create and employ classification models for information access and usage.
• Enterprise must create and establish an information management approach that defines:
• Replication and migration of information
• The structure and usage of information stores
• Information management standards, patterns and best practices
• Classification for information access

Cost Optimization Principles

Inevitably every organization is going to be focused on cost reduction. Here are a few principles that can be used to support cost control objectives.

PRINCIPLE 16: TECHNICAL DIVERSITY AND HEALTH

Statement: Technological diversity is controlled to minimize the costs of maintaining multiple products providing common capabilities.?Applications will be developed for enterprise wide use.?Applications and Infrastructure must maintain optimal technical health on supported versions.

Rationale:

• Ensure all components maintain technical health reduces total cost of ownership for extended support and support service resiliency of business capabilities.
• Limiting the number of supported components will simplify maintainability, enable faster delivery and reduce costs.
• Common technology across the enterprise brings the benefits of economies of scale and reducing technical administration and support.
• Duplicative capabilities are expensive and proliferates conflicting data.
• Specialization of applications should be minimized and be driven by quantifiable business requirements.

Implications:

• Technical Health should be reported and reviewed annually for all core platforms which support business capabilities.
• Policies, standards, and procedures that govern technology acquisition must limit technology diversity
• Technology choices will be constrained by the choices available within the technology standards and patterns
• Technology standards and patterns will change to accommodate compatibility with the current infrastructure, improvement in operational efficiency, or to provide a capability not available
• Departments will not be allowed to develop capabilities for their own use which are similar or duplicative of enterprise-wide capabilities; in this way, expenditures of scarce resources to develop essentially the same capability in marginally different ways will be reduced.
• Exceptions will be limited and must be made based upon quantifiable business requirements.

Managing technical health of your enterprise is absolutely critical for an enterprise to control costs and manage technical debt. For more information on building an enterprise evergreen strategy, see a recent blog I posted, Developing Enterprise Evergreen Strategy.

PRINCIPLE 17: SOLUTIONS SHOULD BE COST EFFECTIVE

Statement: Solutions must meet business requirements while being made as economical as possible by leveraging existing assets, lower cost technology and productive development environments that meet or exceed the technology requirements.

Rationale:

• Financial and resource limitations dictate that enterprise must find the most economical solution that fits the requirements.

Implications:

• Architectural decisions must weigh the enduring qualities of the solution with the economics of achieving the architectural qualities.
• Option choices must be cost conscious; considering total cost of ownership: lifetime operations cost as well as development / purchase costs; leverages existing common infrastructure.
• Costs of integration, support and customization must be included in total costs of ownership.
• Asset shelf life is a consideration of every solution approach and capacity decision.

PRINCIPLE 18: INTELLECTUAL PROPERTY MUST BE ASSURED

Statement: Solutions developed in conjunction with partners or vendors must be structured to ensure that enterprise retains sufficient intellectual property rights.

Rationale:

• Serves to reduce total cost of ownership.
• Contributes to enable business compliance and serves to protect enterprise from legal action.
• Protects enterprise from paying for the development of an asset and having others control the IP rights in the process losing control over assets evolution.

Implications:

• Supporting principle needs to directly align to the enterprise information governance principles.
• Enterprise shall create measured criteria for intellectual property rights pertaining to vendor supplied solutions that can allow enterprise to view vendor proprietary intellectual property.
• Enterprise must create and establish a vendor relationship approach that preserves and protects intellectual property rights while allowing timely response to critical system events.
• All parties Intellectual Property Rights may be referenced in architectural artifacts and must be included in the products license agreement

Once you have established these principles, you will want to review these with every new strategic plan for the enterprise. You may want to add specific ones that align to company specific goals more focused on their vertical strategy. For example, if you are a manufacturing company and safety is a primary focus for you I would consider adding specific principles aligned to these objectives. The enterprise architecture principles in this blog should be baseline for almost any enterprise.

Each principle you establish will need one or more supporting non functional requirements. Should a business owner during a project want to deviate from these non functional requirements, leverage your architecture review board or corporate governance to ensure the effort remains compliant and have a well defined exception policy with leadership approval if necessary if there is an attempt to bypass. An example matrix is below:

For more information on developing best practice non functional requirements, refer to my Optimizing the Non Functional Requirements Process.

As always, if you are interested in providing feedback, additional principles please send along or set up some time with me for a discussion!