MIT continues to operate in a federated IT deployment model that creates the appropriate balance in the integration of differentiating and commoditized services, and facilitates the collaborative deployment of shared infrastructure and services.

a. Rationale:

The federated model leverages an organizational structure in which staff reporting lines and service provisioning are independent and distributed but operate in concert to form institutional capability.

The federated approach allows for the appropriate balancing of centralized and decentralized approaches with joint accountability for delivery of core IT infrastructure services.

b. Policy & Culture Considerations:

1. Whether sourced internally or externally, centralized IT services are designed to reduce the IT overhead needed within local units, and to provide access from anywhere, at any time, and from any device.
2. Local autonomy, especially at the research and education front lines, is highly valuable and remains explicitly embraced at MIT. The federated model respects and enables this key operating principle while also enabling local units to leverage institutional capabilities.

c. Investment Considerations:

1. Shared IT infrastructure services render better economies of scale while assuring appropriate institute-wide baseline levels of service; allow local IT services to be built more rapidly and cost effectively upon shared infrastructure; and help preserve capacity for strategic initiatives.
2. Reviews of potentially duplicative efforts and multiple provisioning models for broadly prevalent technologies and services across the institute are conducted by the IT Leaders Group and established IT sub-committees, and are reported on annually to the IT Governance Committee (ITGC).
3. The cost structure for provisioning and support of core institutional IT infrastructure services, whether provided centrally or locally, is incorporated into the institute-level IT funding strategy.

To ensure and improve the synergy of federated IT solutions and core infrastructure services and platforms, local and central IT deployments adhere to commonly accepted and emerging application and integration IT architectures, open-interfaces, and usability and accessibility standards whenever possible.

a. Rationale:

Proliferation of servers, platforms, operating systems, applications, and interfaces can waste valuable resources, as does the creation of redundant IT solutions for shared, interconnected, or integrated services. Whereas, embracing commonly accepted and emerging application and integration platform-based IT architecture standards enables better institute-wide planning and coordination for developing robust IT capabilities; avoids the development of piecemeal, redundant, and outdated IT solutions; and promotes MIT as an inclusive community in which all faculty, students, and staff can effectively, efficiently, and equitably complete their respective tasks.

b. Policy & Culture Considerations:

1. This principle is primarily aimed at shared processes and infrastructure. However, even research and education often benefit from embracing commonly accepted and emerging application and integration platform-based architectural standards. Doing so enables one to be more agile because it is usually easier to build “on top” of an API-enabled institutional architecture. That said, this principle recognizes that standardization and technical diversity need to coexist, especially in the research and education functions.
2. To the extent possible, application and integration platform-based IT architectures are used as the blueprint for building and/or acquiring, maintaining, enhancing, integrating, and sharing of solutions to create robust, rapidly-deployable, and agile local and institutional IT capabilities – capabilities that are recognized both internally and externally as worthy of MIT.
3. Application and integration platform-based models enable central and local service providers and users to directly leverage MIT’s core infrastructures and services in ways that scale in support of the diverse needs of MIT’s complex ecosystem of producers and consumers of IT services.

c. Design Considerations:

1. The architecture is device-agnostic and designed to enable our services to interoperate not only across MIT, but also within a world where MIT is not the only supplier.
2. The architecture is designed to accommodate the use of software development tools that reduce the maintenance (“keeping-the-lights-on”) burden for local and central IT service providers.
3. The architecture is designed to enable local and central IT service providers to buy (or scribe to) new software systems without customizing them – deploying them “as is” with locally- or centrally-developed differentiating web and mobile apps built and delivered “on top” of the packaged software (or software-as-a-service) products.
4. The architecture is also designed to enable local and central IT service providers to avoid additional costly customizations of legacy systems – enabling them to add new functionality “on top” of stabilized (or frozen “as is”) legacy environments.
5. Device agnostic standards are embraced for all mobile and web-based solutions to guide the creation of a consistent user experience for broadly used institutional processes, applications, and services, while permitting local interpretation when required to address a more focused audience or need.
6. To the extent possible, all services have published APIs.

d. Investment Considerations:

1. Application and integration platform-based IT architectural standards can be powerful tools for enabling the Institute to increase its return on IT investments and IT assets. Economies of scale can be leveraged more efficiently, technical administration and support costs can be better controlled, and security and other regulatory requirements can be addressed more effectively.
2. When there is potential for solutions with Institute-wide impact, these solutions are aligned with commonly accepted and emerging application and integration platform-based IT architectural standards. Such solutions are designed to be scalable and it is considered that they may be used outside the originating unit.
3. Application and integration IT architectural standards are designed to facilitate reuse of IT solutions – further reducing costs and increasing the Institute’s return on its IT investments regardless of funding sources. Local and central IT funding processes support and encourage such reuse of IT solutions.
4. It is generally more advantageous to “buy” when you need to automate commodity business practices, and to “build” when you are dealing with core processes that differentiate the Institute – buy to standardize or automate, and build to differentiate. Buying applications to the maximum extent possible also helps to cut costs – freeing up resources for what really needs to be built in-house. Additionally, the use of open source products often creates the best of both worlds – combining low-cost tools with access to source code.
5. When none of the packaged software solutions will do, then consideration will be given to collaborations with other members of the higher education community to build software that could eventually be licensed or contributed as open source.

Our need for widely varying, rapid, and responsive deployment of IT in support of innovation and discovery is carefully balanced with strategic investment in institutionally-managed common use, standards-based, collaboration-oriented information technology infrastructure and IT-enabled processes.

a. Rationale:

Intra- and inter-institute connectedness, collaboration, shared infrastructure, and well-coordinated end-to-end processes are as critically important to innovation and the success of MIT's mission, especially in research and education, as local variation, rapid experimentation, and responsiveness.

b. Policy & Culture Considerations:

1. To appropriately plan, invest, and ensure alignment locally and centrally, IT plans with impacts or implications beyond a strictly local implementation are broadly shared and developed in consideration of these principles.
2. Local and institutional IT planning is done together – local IT decisions are not made to the detriment of institutional goals and likewise institutional decisions are not made to the detriment of local goals.
3. Planning and budgeting for IT in any shared-use infrastructure, common application, or multi-user enabled process is integrated with the institution’s overall planning and budgeting processes.
4. Institution-level IT projects, regardless of funding source, are justified on the basis of the value they generate for the institution, and project sponsors affirm their commitment to participate in post-implementation reviews of the benefits realized.
5. This principle requires an institutional commitment to the IT governance structure, along with transparent and well-understood processes for setting and reviewing priorities for funding.

c. Investment Considerations:

1. IT funding addresses the total cost of ownership and operation over the life of the IT solution, including: initial capital investments, implementation support, operational funding, and depreciation. Implicit in this total cost approach is the consideration of the “domino effect” where cost impacts across all affected units are appropriately addressed.
2. Costing is end-to-end, and comparisons of costs between alternative options include all hidden subsidies.
3. Replacement cycles are established for each of the different components of the technology infrastructure, and a depreciation reserve is incorporated into IT budgets.

MIT’s communications and data network infrastructure are planned and developed to create a robust shared institutional connectivity capability.

a. Rationale:

Connectivity is an essential IT contribution to the MIT mission. Networking provides a wide array of critical services, the selection and operation of which can have a dramatic impact on shared and collaborative activities. The provisioning of connectivity is therefore an institution-wide exercise.

b. Policy & Culture Considerations:

1. The institution strives to facilitate and maximize self-directed innovation, discovery, scholarly activity, and sharing among global communities and prevent barriers to institutional effectiveness in the form of unnecessarily restrictive connectivity.
2. Network security has become an institutional consideration. Security and risk avoidance are balanced against the need for appropriate access and capability at the institutional level.

c. Design Considerations:

1. The communications and data network infrastructure act as a “central nervous system” and enable individual units to take advantage of a robust shared capability when building more specialized local IT solutions.
2. The shared network infrastructure is built on modern Internet-era IT architectural standards.
3. The design of the network infrastructure enables it to be managed to consistently reflect MIT’s policies on privacy, electronic communications, and security.
4. MIT’s network is part of a global fabric, and is designed to ensure compatibility and interoperability in order to maximize scholarly activity.

d. Investment Considerations:

1. It is expected that local and central units collaborate on the purchase of network and communications infrastructure hardware and software whenever feasible, enabling cost efficient purchasing practices and support for ongoing maintenance.

There is a consistent Institute-wide policy and behavior addressing the requirement for appropriately provisioning, accessing, storing, securing, and preserving institutional information, regardless of where it is collected or stored.

a. Rationale:

MIT is in the data and knowledge business. Data is an asset that has to be managed, and made available and accessible as an institutional mission-enabling strategic resource.

Lack of appropriate data integrity, quality, and security can compromise the institution’s reputation and impede operational efficiency. Similarly, lack of accessibility to data and/or excessive barriers to making data available can impede the objectives of the Institute.

When exploited constructively, data is a strategic asset that can build and enhance the reputation of the Institute in terms of the impact of intellectual content, the ability for new discovery, better decisions, improved business processes, and the relationship each individual has with the Institute.

b. Policy & Culture Considerations:

1. Data appraisal processes and policies determine what data is worth collecting and keeping and what data can be or should be discarded.
2. Researchers and institutional data owners and stewards have assurance that they can put their data into a trusted system and at the same time understand how to provision data at varying levels of verification and validation.
3. The Institute strives to achieve an appropriate balance among privacy, openness, transparency, and safeguarding confidential information.

c. Design Considerations:

1. Institutional data management platforms are designed to meet the common needs of local and central units, as well as by principal investigators, administrators, and other users of local and institutional data.
2. Institutional data management tools support the common reporting, analytics, decision-making, and visualization needs of local and central units.
3. Institutional data management has moved towards data-centric architectures, where to the extent possible data are made available in forms that are easy to ingest with standard software, in a form that can be flexibly manipulated, as opposed to being locked up behind business logic applications.

Innovation is encouraged and supported locally and institutionally with an appropriate tolerance for risk, and agile project management methodologies and approaches are employed to help mitigate risk.

a. Rationale:

MIT is in the business of innovation and represents a dynamic marketplace of ideas. Correspondingly, MIT aspires to be externally and internally viewed as innovative in the application of IT to enhance the experiences of its faculty, staff, and students, and to further the institution’s academic, research, and service mission.

b. Policy & Culture Considerations:

1. MIT is in the business of innovation and represents a dynamic marketplace of ideas. Correspondingly, MIT aspires to be externally and internally viewed as innovative in the application of IT to enhance the experiences of its faculty, staff, and students, and to further the institution’s academic, research, and service mission.

c. Investment Considerations:

1. Agile institutions share and reuse application and integration components in a centrally supported and secure repository – ensuring that time spent building and integrating new applications is time spent creating new value.

The purpose for IT oversight and governance at MIT is to provide clear processes for IT decision making, foster IT excellence across the Institute, and facilitate Institute-wide IT planning in support of the vision and mission of MIT.  

a. Rationale:

Successful achievement of the strategic IT vision requires the orchestration and integration of governance structures and processes with many different stakeholders’ needs and initiatives to create appropriate synergy and forward momentum toward the vision.

The distinction between IT governance and IS&T management responsibilities for IT investments in expanding or enhancing existing infrastructure systems and services is clearly defined in order to avoid conflict and enable organization agility.

b. Policy & Culture Considerations:

1. The IT Governance Committee (ITGC) continues to guide, direct, and approve the establishment and implementation of policies, guidelines, and standards pertaining to the use of IT at MIT.
2. The ITGC provides oversight for the development and maintenance of Institute-level strategic IT plans in support of the vision and mission of MIT.
3. The ITGC ensures the proper sharing of responsibility and setting of priorities for Institute-level IT investments, approves the deployment of Institute-level resources by reviewing and making decisions on Institute-level IT initiatives, and ensures proper sponsorship and accountability for Institute-level projects – whether provided centrally, locally, or outsourced to a third party.
4. The ITGC identifies and charges sub-committees, steering committees, or working groups as appropriate to complete the committee charge, and provides funding and review of progress as needed.
5. Information Systems & Technology (IS&T) partners with ITGC-designated sub-committees, steering committees, and working groups to develop and maintain Institute-level roadmaps for Administrative Systems, Education Systems, Research Computing, Data Management, Mobile Computing, Infrastructure, and Customer Support. These roadmaps are reviewed, approved, and monitored by the ITGC. Supplementary guiding principles for the development of each of these roadmaps are attached at Appendices A through G.

c. Investment Considerations:

1. The ITGC and sub-committees charged with overseeing institute-level roadmaps requires sponsors of Institute-level projects to affirm their commitment to participate in post-implementation benefits-review processes for projects requiring resources of $250K or more.

Appendix A - Administrative Systems (Supplementary Guiding Principles)

(Developed collaboratively with the Administrative Systems and Policies Coordinating Council (ASPCC))

1. Transforming community experiences – administrative systems enable process simplification with intuitive interfaces and user-centric approaches that meet community needs.
2. Supporting Institute initiatives – systems meet the needs of emerging Institute directions and support international engagements.
3. Cross-functional and holistic approaches – technology systems are approached holistically, crossing functional areas, with development of scalable components that fit into an overall plan for the future.
4. Laying the foundation for the future – foundational work that impacts multiple systems, enables future technology approaches, and promotes integration is critical to maximizing future success.
5. Stewarding Institute resources – systems fulfill MIT’s needs for maintaining a sound control environment, meeting compliance requirements, and responding to mandated changes.

Appendix B - Education Systems (Supplementary Guiding Principles)

(Developed collaboratively with the Student Systems Steering Committee (SSSC))

1. Support for changing academic paradigms and innovations.
2. Lowering barriers to student success.
3. Refreshing signature gateways.
4. Sustaining technology.

Appendix C - Research Computing (Supplementary Guiding Principles)

(Developed collaboratively with the Committee on Research Computing (CRC))

1. An environment that ensures high reliability and security as appropriate to the needs of users.
2. Recognition of the diversity of needs of the research computing community at MIT, and a mixture of services (such as co-location and shared use capabilities) that has the flexibility to evolve as needs change.
3. Power and cooling density and capacity sufficient for research computing workloads.
4. Sufficient network bandwidth for research computing workloads.
5. Fault-tolerant geographically dispersed infrastructure designed to insulate from failures at other locations.
6. Connection and coordination with other national and international cyber-infrastructure resources. 
7. A system of communication with users and potential users of research computing at MIT that is able to inform such users of capabilities and changes and to provide users an avenue for input. 

Appendix D - Data Management (Supplementary Guiding Principles)

1. Information in a single place
   • Access any information in the same manner
   • Integrated information
2. Join information from several sources
3. Structures should support the needs of all types of users
   • Central, DLC, Institutional
4. Open access via SQL
   • Not proprietary only access
   • Uncommon in education and industry
   • Can be accessed programmatically
5. Warehouse is the data distribution hub
   • Easy to verify when feeds and reports are from a single source
6. Data should be stable
   • Consistency between reports generated on the same day
   • Ability to generate the same report at any point in time
7. Data has to be accurate
   • Stale data is better than inaccurate data
8. Structures should make it easy to report
9. Data is not corrected or modified in the Warehouse
10. Access rules are shared by the Warehouse and transactional systems
    • Access managed by Business Owners
11. Data always comes from a system of record
12. Users should be able to generate and share reports
13. Metadata is available for all information
14. Access control done at the database level
    • Enables direct access via any means
15. Metadata driven transformations and loads
    • To know how data was arrived at
    • Same code called thousands of times

Appendix E - Mobile Computing (Supplementary Guiding Principles)

1. Promote “mobile first” as the default application development priority.
2. Promote the creation of web APIs – recognizing the importance of facilitating local and student-developed solutions.
3. Give priority consideration to projects that positively impact the MIT community most broadly – students first.
4. Give priority consideration to projects that enable IT innovation at a multiplicity of end points.
5. Give priority consideration to projects that are able to scale at minimal incremental cost.
6. Be developer centric — provide industry standard well-documented interfaces.
7. Give priority consideration to projects that unlock MIT’s data, and make it actionable.
8. Drive adoption by providing an intuitive user experience, training on demand, and high quality code.
9. Experiment with faculty and students to model, prototype, and adopt new technologies and practices that might serve as a model to the world.

Appendix F - Infrastructure (Supplementary Guiding Principles)

1. Provide sufficient computational capacity to support the research and enterprise computing that MIT needs.
2. Storage capacity / performance options to meet these needs with appropriate economics for research and enterprise computing.
3. Security and segmentation to ensure a safe computing environment for hosted computational resources.
4. Redundancy options with appropriate economics for research and enterprise computing workloads.
5. Self-service flexibility that provides sufficient management tools and interfaces in an environment that can be managed by the community in a way that best fits their needs.
6. Networking services that provide both security (firewalls) and performance (load balancers) services to meet the needs of the MIT community.
7. Network management and flexibility that allows the networking environment for enterprise and research computing resources to be managed in a self-service fashion that best fits their needs.
8. Backup and data recovery services with appropriate economics and options for enterprise and research computing resources.
9. Support and consultative resources by IS&T staff that are available as needed to ensure the setup, operation, and evolution of enterprise and research computing environments and their customers.

Appendix G - Customer Support (Supplementary Guiding Principles)

1. Be helpful - whether collaborating with business partners, customers, or end users of IT, the focus is on being helpful and facilitating positive relationships.  IT support should be easy to engage, available whenever needed, and flexibly delivered. It is about supporting individuals in their use of technology, not about supporting a particular technology.
2. Act as stewards of customer and user feedback – the feedback of customers and end-users (their needs, pain-points, and ideas) creates potential paths to innovation, improvement, and community engagement.
3. Leverage knowledge to foster collaboration – knowledge-based solutions that encourage broad participation represent a valued resource that is transparent and available to all users at all times.
4. Improve the user experience – by understanding the needs and goals of users (end-users, faculty producers, or student consumers) we can proactively guide the development of our platforms and services to improve the user experience and facilitate the achievement of innovative goals.