Experts & Communities

Technology Guiding Principles

3 people at a meeting
577 gradient

Helping you choose technologies with confidence

General Principles

Principle: Primacy & Scope of Principles

Strive for a Common Enterprise Architecture for the University

Enterprise architecture at the University of Minnesota is informed both by the University’s core missions and the specific business needs of its organizational units. Efforts should be coordinated and communicated across the organization to ensure cost and resource efficiency, promote reuse of technology, and simplify integration processes.

Rationale

Enterprise architecture at the University of Minnesota shall be informed both by the University’s core missions and those of its organizational units. This principle is established to ensure maximum alignment with the University’s teaching, learning, research, and outreach missions; as well as other strategic objectives of the University.

Implications
  1. Enterprise architects must have an understanding of the overall organizational mission(s), business goals, and strategic plans.

  2. Technology recommendations and roadmaps must ladder up to specific business needs.

  3. Architects must gain access to people and materials to identify and document all relevant business requirements.

Challenges
  1. Translating high­ level business goals to actionable technical solutions.

  2. Prioritizing diverse and competing business needs.

  3. Ensuring full participation of business partners.

Key Actions
  1. Establish direct communication channels between enterprise architects and all areas of the organization

  2. Review annual business and technology plans for all university units

Conform to Security Framework and Standards

Rationale

Security standards are specifications for how a particular technology is to be configured and deployed. All technologies specified must be risk assessed to ensure that they can be implemented and operated without introducing unacceptable risk. The implemented solutions shall align with the University Security Framework, including Data Classification.

Implications
  1. Changes in individual technologies shall be tracked in order that corresponding security standards may be kept up to date.

  2. Governance processes shall include the auditing of systems against the security standards.

  3. Change management processes shall include checks against applicable security standards.

Obstacles
  1. Changing technologies may demand changes to or the creation of University security standards.

Key Actions
  1. The governance process shall allow for the timely assessment of new or changed technologies.

  2. The governance process shall include an exceptions process in order that security standards and technologies may be brought into overall compliance in a timely manner that controls and tracks risk.

  3. A list of “approved” and/or “recommended” security-­assessed technologies shall be maintained.

Principle: Maximize Benefit to the Enterprise

An Enterprise Architecture for All

Rationale

The university’s enterprise architecture will acknowledge and accommodate business requirements from across the organization--including all system campuses, colleges, and administrative units. This approach will help to ensure cost and resource efficiency, promote reuse of technology, and simplify integration processes.

Implications
  1. Includes system campuses and all other organizational units.

  2. The enterprise architecture roadmap must articulate current, short-term, and long-term tactics, as well as look to future influences and opportunities in technology and business.

  3. Enterprise architecture strategy and roadmaps will be reviewed with the business owners on an ongoing basis.

Challenges
  1. Groups that are responsible for component parts of the end-to-end architecture must work together to ensure that solutions align to an overarching, strategic enterprise architecture.

  2. May be obligated to use third party systems whose compliance with University architectural standards cannot be assured.

Key Actions
  1. Establish and facilitate a University-wide enterprise architecture community including business and technology stakeholders.

  2. Ensure enterprise architecture efforts take a full enterprise-­wide view of business requirements.

  3. Establish architecture roadmap(s) that have current, short, and long-term views.

  4. Establish an enterprise architecture governance process, and review effectiveness with stakeholders.

  5. Establish exception management process.

  6. Create a complete technology, service, and solution portfolio that includes central and distributed investments.

Principle: Promote a Culture of Security

Information Security is Everybody’s Business

Information security shares characteristics with viral inoculation - it is only effective when almost everybody participates, a concept referred to as “herd immunity.” And just as it only takes a couple of un-inoculated individuals to put everybody else’s health at risk, it only takes a few people who lack security awareness to put everybody else’s data at risk. That makes information security everybody’s business.

In order to ensure that everyone is able to be aware of security at all times the enterprise must provide continuous security education that covers the entire lifecycle for employees, faculty, students, and guests, including arrival, onboarding, regular operations, de-provisioning and archiving of account data.

Rationale

In order to be effective, information security principles, policies, plans, processes, and procedures must be broadly communicated and promoted across all business and technology units and to all staff, faculty, students and visitors at the University of Minnesota.

Challenges
  1. The information and concepts underlying information security can be technical, picayune, and non-intuitive. For example password policies encourage longer, more complex passwords up to a point, after which passwords become unmanageable and people take the unsafe step of writing them down.

  2. As information security related laws, regulations, and technologies change the messaging will need to change, sometimes significantly. For example, were a technology developed that broke password security, other means of securely authenticating individuals would have to be rapidly adopted.

  3. Different rules apply to different audiences, for example HIPAA rules are extensive but focused on personnel working with or for companies that handle medical information. Therefore much of the messaging will need to be customized.

Implications
  1. An information security communications program must be established and maintained.

  2. The effectiveness of the information security program must be tracked and changes made to increase effectiveness.

  3. Different audiences need to be identified and information security messaging customized to ensure efficient and effective communications.

  4. Senior management needs to make clear that security is everybody’s business and individuals are responsible to maintain awareness.

Key Actions
  1. Existing information security efforts shall be reviewed for effectiveness and changes made where necessary to increase effectiveness.

  2. Information security communications shall be integrated into the overall enterprise architecture program.

Principle: Transparency & Communications

Communicate Broadly

Rationale

The enterprise architecture principles, plans, roadmaps, and decisions must be broadly communicated and promoted across all business and technology units at the University of Minnesota.

Challenges
  1. Identifying key audiences and communications channels

  2. Establishing effective messaging and cadence

  3. Agreement on common terminology and concepts

Implications
  1. Need to establish a communications plan with key audiences and channels

  2. Need full support from senior management.

Key Actions
  1. Establish and activate a communications strategy.

Principle: Business Continuity

Support Business Continuity

Rationale

Technology is critical to the business and mission of the University, so critical business solutions should provide service consistency and recoverability in the face of unexpected events.

Implications
  1. Business continuity requirements need to be defined and agreed upon with the business and then published.

  2. Infrastructure must support business continuity requirements.

  3. IT architecture must support business continuity requirements.

  4. IT and business must prepare for disaster or other unforeseen situations.

  5. Plans for technology change should strive to minimize downtimes, and the IT architecture should support this.

Obstacles
  1. Cost may outweigh the business benefits.

  2. Unrealistic business expectations can lead to excessive costs.  Cost / benefit analyses must always be included in all continuity requirements discussions.

Key Actions
  1. Establish business case for continuity.

  2. Define and publish business continuity requirements.

  3. Review business architecture to ensure that is compliant.

  4. Review IT architecture to ensure it supports business requirements.

NOTES: scalability, transition to new or different systems.

Principle: Common Use Applications

Leverage Strategic Suppliers

The University should use strategic suppliers and leverage existing relationships to streamline purchasing and support processes and to maximize return on investment.

Implications
  1. Strategic suppliers must ensure that all proposed solutions are aligned with the University architecture principles and standards.

  2. The Technical Architecture Group reserves the right to review any proposed solution to ensure overall conformance to standards and alignment across architectural domains and to ensure that any inter­domain dependencies are taken into account.

  3. Strategic suppliers must attend and participate in regular Domain meetings which will provide the forum for the discussion of new and strategic requirements.

  4. Strategic partners should ensure that there is a collaborative approach to technology solution selection for service provision.

  5. Strategic suppliers will provide the single interface into the University for the provision and on­going support for new services. Strategic suppliers will directly manage relationships with any other suppliers of the service.

  6. When strategic suppliers are not able to provide proposals the University will follow industry best practice and select a technology solutions based on fit to business requirements and total lifecycle costs.

  7. Leverage consortia purchasing to provide greater cost savings via economies of scale.

Obstacles
  1. Capacity, both in terms of specifying provision and change management.

  2. Tension with avoiding vendor lock-­in.

Key Actions
  1. Ensure that business and IT are aware of this requirement.

  2. The Domain Architects will need to work more closely with strategic suppliers to ensure service requirements are understood and met.

  3. Regular Domain architecture meetings will be arranged to provide the discussion forums for all new and strategic requirements.

  4. All proposals, where possible, will be provided in terms of both a service charge (e.g. cost per user), and a standard capital and operating cost.

Prefer Buy vs. Build

Rationale

The University prefers to purchase software solutions when the technology is well-defined and the solution is mature. Purchasing existing software products where available allows custom development to focus on emerging technology and innovation.

Implications
  1. Strategic suppliers must ensure that all proposed services are aligned with the University architecture principles and standards.

  2. When strategic suppliers are not able to provide proposals the University will follow industry best practice and select technology solutions based on fit to business requirements and total lifecycle costs.

Obstacles
  1. Capacity for service specification is limited.

Key Actions
  1. The Domain Architects will need to work closely with strategic suppliers to ensure service requirements are understood and met.

  2. Regular Domain architecture meetings will be arranged to provide the discussion forums for all new and strategic requirements.

  3. All proposals, where possible, will be provided in terms of both a service charge (e.g. cost per user), and a standard capital and operating cost.

Prefer Existing Solutions vs. Internal Development

Rationale

In a mature market, a company specializing in a particular solution will have an existing product with a wide range of functionality. Using the existing product allows the University to focus effort on the mission rather than developing a custom solution.

Implications
  1. The total cost of ownership for any solution includes not only development and implementation costs, but subsequent maintenance, development and support costs which must be considered.

  2. Self­build needs to be considered in the following circumstances:

    1. In a new market where commercial products do not currently exist.

    2. In­house development may be necessary to build competitive edge.

Obstacles
  1. Lack of skills within the business community to specify requirements at system and service level.

  2. Capacity to do this.

  3. Culture, within some specific areas of the organization.

Key Actions
  1. The Technical Architecture Community should participate in all product selection processes to ensure architectural principles are being adhered to.

  2. Ensure that the business community is aware of the requirements for buy not build and that this is clearly communicated.

Principle: Compliance with Law

Compliance principles require that solutions, policies, and practices meet legal, regulatory, and safety requirements. The security standards implemented must align with the University Security Framework. Adherence to regulations helps protect the University’s reputation and minimizes legal liability.

Solutions or practices are compliant with regulatory requirements and industry best practices. All solutions must be risk assessed to ensure that they can be implemented and operated without introducing unacceptable risk.

Comply with Health and Safety Guidance

Rationale

Health and safety guidelines shall be followed in order to comply with law, regulation, and safety requirements and to reduce risk to University personnel and the enterprise.

Implications
  1. The architecture group shall maintain awareness regarding new laws and regulations which may impact the design of IT systems.

Obstacles
  1. Changing legal, regulatory, and safety requirements may create unanticipated costs which shall require budget decisions.

Key Actions
  1. Create guidelines for health and safety conformance for solutions and services.

Meet Legal and Regulatory Requirements

Rationale

The University shall conform to all legal and regulatory requirements or be in violation of the law and subject to legal action, damage to institutional reputation, and punitive fines.

Not conforming to legal and regulatory requirements may result in legal action being taken against the University, which will both damage the institution's reputation and potentially result in compensation payments.

Implications
  1. The architecture group shall maintain awareness of new laws and regulations that impact the design of IT systems.

  2. All relevant requirements shall be analyzed to determine their impact on architecture standards.

  3. Architecture standards shall be defined and published.

  4. Enterprise Architecture governance shall be established and maintained.

Obstacles
  1. Conflicting laws and regulations, particularly across national boundaries, may in some circumstances make full legal and/or regulatory compliance impossible.

The global nature of the organization may result in conflicts for compliance.

Key Actions
  1. Should become part of scope of the security domain group.

  2. Define and publish standards.

  3. Ensure that all solutions are reviewed to ensure compliance with standards.

Data Principles

Principle: Common Vocabulary and Data Definition

Establish a Common Data Model

Rationale

Meaningful business intelligence and analysis of University data relies on the establishment and adherence to a model where data stored in systems and exchanged between components in systems is mapped to an enterprise-wide master data schema. This standard approach will assist in the identification of systems of record, and the establishment of common naming standards and data attributes to facilitate productive analysis and reporting.

Implications
  1. Need to establish enterprise data model and related processes

  2. Need to work with University data stewards on common naming standards and other data attributes

Challenges
  1. Determining ownership and responsibility for the data model.

  2. Ability to scale the model for simple integrations

  3. Alignment across the University on systems of record, classifications of data, naming standards, etc.

Key Actions
  1. Architecture Group to identify a single working group or community to identify, define and describe agreed data entities.

  2. Map the physical implementation of data across all systems.

Application Principles

Principle: Ease-of-Use

Use Industry Standard Interfaces

Rationale

The proposed architecture and constituent technologies must support open, industry standards and Application Programming Interfaces (APIs), and avoid proprietary interfaces. This will reduce the cost of development, integration, and maintenance.

Implications
  1. Enterprise architecture needs to create a set of patterns covering approved integration standards.

  2. Where this is not possible all interfaces must be implemented through published APIs.

  3. Using industry standards provides a large pool of IT professionals qualified to support the solutions.

Obstacles
  1. Compliance of existing systems and services.

  2. Visibility – it may be difficult to establish which existing systems and services are compliant.

Key Actions
  1. Create integration standards.

  2. Develop a roadmap for compliance.

Technology Principles

Principle: Requirements-Based Change

Be Designed to Meet Business Requirements

Rationale

Solutions should be engineered appropriate to the business requirements to minimize cost and maximize value.

Implications
  1. Business owners must define expected levels of service for their applications and services from which the overall solution design can be created.

  2. Need to define levels of resilience, availability, performance, usability, manageability, etc.

Challenges
  1. Lack of understanding of criteria to be used when making business decisions.

  2. Dependencies on infrastructure and other systems which may not support desired goals.

  3. Business factions sharing solutions cannot often reach consensus on requirements definitions.

Key Actions
  1. Create guidelines for making business decisions.

  2. Define levels of resilience, availability, performance, usability, management, etc. and associated costs.

  3. Identify dependencies between systems and infrastructure and ensure they can support the desired service levels.

Principle: Responsive Change Management

Consider Scalability

Rationale

Solutions must be able to scale over time and increases in demand during their lifetimes, based on current understanding of business strategy and project requirements, in order to maximize return on investment.

Implications
  1. A formal capacity planning process need to be embedded within the development lifecycle of all applications and services.

  2. We need to use technical solution to provide flexibility.

  3. We should implement and manage IT solutions as services.

  4. Systems need remote monitoring capabilities.

Obstacles
  1. Existing systems may not be able to scale appropriately without major investments. In these cases, total costs and other options should be considered.

  2. Estimating future scale can be difficult.

Key Actions
  1. We need to implement ITIL capacity management process.

  2. Ensure all solutions are reviewed to ensure they meet scalability and performance requirements.

Principle: Control Technical Diversity

Balance Stability and Efficiency

Solutions should be appropriately engineered to meet business requirements to minimize cost and maximize value. When possible, the University should reuse existing resources to support business requirements. Stability, scalability, and efficiency must be at the foundation of the design and implementation of these solutions. These principles seek to maximize the performance and consistency of provided services in all circumstances, while allowing for innovation.

Preference toward utilizing existing resources.

Strive for Simplicity

The University prefers to buy services rather than develop solutions ourselves when the technology is well defined and/or mature. Using the existing product allows the University to focus effort on the mission rather than developing a custom solution. In­-house development should be reserved for emerging technology. The proposed architecture and constituent technologies must support industry standards. The University should use strategic suppliers and leverage existing relationships. The simplicity principles promote transparency in design and process that allows for supportable systems and services.

Leverage Existing Business Applications

Rationale

The University should use existing resources and solutions to support business requirements where they meet all mandatory requirements and are within the purchase lifecycle.

Implications
  1. The enterprise architecture team needs a good understanding of the capabilities of existing enterprise applications’ functionality and the capabilities of additional modules.

  2. The enterprise architecture team needs a good understanding of current enterprise applications’ technology roadmap to determine alignment to University’s future needs..

  3. To support this strategy the enterprise architecture team needs to develop an integration architecture to facilitate.

  4. Architecture governance needs to be involved in the decision making process because “mandatory requirements” is open to interpretation.

Challenges
  1. Existing system capacity must scale to meet business requirements.

  2. EA needs to provide a means to catalog and discover capabilities of the University’s existing enterprise applications.

Key Actions
  1. The functionality of the University enterprise systems need to be cataloged and communicated effectively in business terms.

  2. This principle needs to be communicated to all senior business managers.

  3. The enterprise architecture needs to develop integration architecture.

  4. Architecture governance needs to both inform and guide solution decisions to implement this principle.

Maximize Existing Infrastructure

Rationale

The University has invested in its enterprise infrastructure (including network, platform, collaboration, integration), and capabilities to support that infrastructure. Leveraging the infrastructure capabilities will help to maximize return on the University’s investment.

Implications
  1. Infrastructure design must consider requirements across the University System.

  2. Ensure that solutions make best use of capabilities provided by the enterprise infrastructure.

  3. Avoid “one-off” solutions which impose unnecessary new infrastructure expenditures.

Challenges
  1. Some legacy systems will continue to require non-standard infrastructure until they can be retired, tempting new applications to use the obsolete infrastructure.

  2. Business often views infrastructure as “free” and so often weights functionality much higher than infrastructure and support costs in choosing solutions.

Key Actions
  1. Review the infrastructure architecture to ensure that it has considered requirements across the University.

  2. Review all solutions to ensure that they make best use of capabilities provided by the enterprise infrastructure.

  3. Maintain infrastructure technology roadmaps for planning both retirement and new infrastructure investments. Use these to guide decisions.

Principle: Interoperability

Promote Common Functionality

Rationale

Committing to a culture of complementary, not competitive or duplicative technologies fosters consistent customer experiences across the University. At the same time, it contributes to ease of integration and increases the quality and effectiveness of solutions overall.

Implications
  1. Need to establish a University-wide portfolio and catalog of technology services, solutions, and underlying infrastructures. The catalog will provide a user-centric presentation of services, solutions and technologies for a variety of interested audiences, and with a focus on strategic re-use

  2. Need to establish standardized, documented business processes across the organization

  3. Pursue “modularized” solutions with standard interfaces and integration points

  4. Need careful change management and thoughtful communications

Challenges
  1. Integrating third party processes, such as stakeholders and other partners, with University processes

  2. Can be challenging to achieve widespread re-use and still accommodate specific requirements in distributed units

  3. Limited resources for consultative services around central solutions

Key Actions
  1. Work with IT teams across the University to identify technology services and solutions that could be considered “central,” or usable by anyone

  2. Understand the various user “personas” that would be looking for information about technologies available for use at the University

  3. Identify and publish a portfolio of all “central” services available for use across the University

Advocate Flexibility and Interoperability

Rationale

Using open protocols and interfaces increases options for integration with other components, systems, or platforms. Avoiding tight coupling decreases complexity and improves agility, as well as minimizing cost and risk. Applications and solutions should avoid dependency on components from a single vendor when possible.

Implications
  1. Architecture should be based on open standards.

  2. The architecture must not create interdependencies between layers (no tight­ coupling) the lack of inter­dependencies will allow layers of the architecture to be replaced independently of the other services.

Challenges

Vendor products may require particular components or vendor’s other products in order to be considered a supported configuration

Key Actions
  1. Ensure that the architecture (enterprise and solution level) is based on open standards.

  2. Ensure that the architecture and solutions does not introduce tight ­coupling between components.

  3. Provide enterprise wide middleware layer(s) to insulate major components from the impacts of change.