| Anchor |
|---|
| _5u18gi4tf1pg |
|---|
| _5u18gi4tf1pg |
|---|
|
Enterprise Architecture Principles v 1.0
Columbia University Enterprise Architecture - version 1.0 .1 - 2014-12-04| Anchor |
|---|
| _53jeu5c07984 |
|---|
| _53jeu5c07984 |
|---|
|
Architecture Principles
...
| Anchor |
|---|
| _cnwdlusnzk6g |
|---|
| _cnwdlusnzk6g |
|---|
|
CU-PRIN-BUSI-001:
Primacy of Principles| Anchor |
|---|
| _mb3mj8bmmcn1 |
|---|
| _mb3mj8bmmcn1 |
|---|
|
Statement
...
| Anchor |
|---|
| _dgd3bi3x5fey |
|---|
| _dgd3bi3x5fey |
|---|
|
Implications
Without this principle, exclusions, favoritism, and inconsistency would rapidly undermine the management of information. This concept was best stated by John Adams as, "a government of laws and not of men." Massachusetts Constitution, Part The First, art. XXX (1780).
Information management initiatives will not begin until they are examined for compliance with the principles.
The Project Review Board (PRB) enforces architecture signoff as part of the Project Management Methodology.
A conflict with a principle will be resolved by changing the framework of the initiative.
An annual review will re-validate these principles and adjust as required.
A formal dispensation process exists to allow and track necessary exceptions.
| Anchor |
|---|
| _sqgjes27fhzg |
|---|
| _sqgjes27fhzg |
|---|
|
CU-PRIN-BUSI-002:
Protection of Intellectual Property, Individual Privacy and Academic Freedom
...
| Anchor |
|---|
| _ci2ycu5a4dov |
|---|
| _ci2ycu5a4dov |
|---|
|
Implications
While protection of IP assets is everybody's business, much of the actual protection is implemented in the IT domain. Even trust in non-IT processes can be managed by IT processes (email, mandatory notes, etc.).
A security policy, governing human and IT actors, will be enforced that can substantially improve protection of IP. This must be capable of both avoiding compromises and reducing liabilities.
Use of technology to implement data integrity and confidentiality will explicitly be architected to protect individual privacy and academic freedom.
Resources on such policies can be found at the Administrative Policy Library ({+}http://policylibrary.columbia.edu+).
This principle applies to all people that the University serves, including, for example, applicants, clients, patients, and other individuals that the institution serves.
| Anchor |
|---|
| _yy5ea2p6xwx3 |
|---|
| _yy5ea2p6xwx3 |
|---|
|
CU-PRIN-BUSI-003:
Business Continuity| Anchor |
|---|
| _wqcsgtg7znvc |
|---|
| _wqcsgtg7znvc |
|---|
|
Statement
...
| Anchor |
|---|
| _4as9kcf5rupy |
|---|
| _4as9kcf5rupy |
|---|
|
Implications
Dependency on shared system applications mandates that the risks of business interruption must be established in advance and managed. Management includes but is not limited to periodic reviews, testing for vulnerability and exposure, or designing mission-critical services to ensure business function continuity through redundant or alternative capabilities.
Recoverability, redundancy, and maintainability should be addressed at the time of design.
Applications must be assessed for criticality and impact on the enterprise mission, in order to determine what level of continuity is required and what corresponding recovery plan is necessary.
Refer to the University Business Continuity and Disaster Recovery Policy at http://cuit.columbia.edu/it-policy-summaries.
Service Level Agreements (SLA) and Operating Level Agreements (OLA) will be established to ensure agreed requirements for service availability are met.
| Anchor |
|---|
| _657f08j48ua7 |
|---|
| _657f08j48ua7 |
|---|
|
CU-PRIN-BUSI-004:
Common Use Services/
Applications...
| Anchor |
|---|
| _1v5nfm63054r |
|---|
| _1v5nfm63054r |
|---|
|
Implications
Organizations which depend on a capability which does not serve the entire enterprise must change over to the replacement enterprise-wide capability. This will require establishment of and adherence to a policy requiring this.
Organizations will not be allowed to develop capabilities for their own use which are similar/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.
Data and information used to support enterprise decision-making will be standardized to a much greater extent than previously. This is because the smaller, organizational capabilities which produced different data (which was not shared among other organizations) will be replaced by enterprise-wide capabilities. The impetus for adding to the set of enterprise-wide capabilities may well come from an organization making a convincing case for the value of the data/information previously produced by its organizational capability, but the resulting capability will become part of the enterprise-wide system, and the data it produces will be shared across the enterprise.
| Anchor |
|---|
| _uzlxgbtz9xmn |
|---|
| _uzlxgbtz9xmn |
|---|
|
CU-PRIN-BUSI-005: Self Service 7x24
| Anchor |
|---|
| _coa0c3hknjqt |
|---|
| _coa0c3hknjqt |
|---|
|
Statement
...
| Anchor |
|---|
| _5kxyd1nra9re |
|---|
| _5kxyd1nra9re |
|---|
|
Implications
Services shall be designed with automated request and fulfillment processes.
Services that require user authentication and authorization follow University identity management standards, thereby leveraging automated on- and off-boarding.
This principle has implications related to Principle 3: Business Continuity with respect to evaluating criticality and impact.
| Anchor |
|---|
| _d0q29yyaof6z |
|---|
| _d0q29yyaof6z |
|---|
|
...
| Anchor |
|---|
| _ekjb1n47fl7f |
|---|
| _ekjb1n47fl7f |
|---|
|
CU-PRIN-DATA-001:
Data is an Asset| Anchor |
|---|
| _vcy2pmm9zeru |
|---|
| _vcy2pmm9zeru |
|---|
|
Statement
...
| Anchor |
|---|
| _rcjldxboaz1q |
|---|
| _rcjldxboaz1q |
|---|
|
Implications
This is one of three closely-related principles regarding data: data is an asset; data is shared; and data is easily accessible. The implication is that there is an education task to ensure that all organizations within the enterprise understand the relationship between value of data, sharing of data, and accessibility to data.
Stewards must have the authority and means to manage the data for which they are accountable.
We must make the cultural transition from "data ownership" thinking to "data stewardship" thinking.
The role of data steward is critical because obsolete, incorrect, or inconsistent data could be passed to enterprise personnel and adversely affect decisions across the enterprise.
Part of the role of data steward, who manages the data, is to ensure data quality. Procedures must be developed and used to prevent and correct errors in the information and to improve those processes that produce flawed information. Data quality will need to be measured and steps taken to improve data quality - it is probable that policy and procedures will need to be developed for this as well.
A forum with comprehensive enterprise-wide representation should decide on process changes suggested by the steward.
Since data is an asset of value to the entire enterprise, data stewards accountable for properly managing the data must be assigned at the enterprise level.
| Anchor |
|---|
| _kad6wzmhkzd9 |
|---|
| _kad6wzmhkzd9 |
|---|
|
CU-PRIN-DATA-002:
Data is Shared| Anchor |
|---|
| _e651gzsgnsu7 |
|---|
| _e651gzsgnsu7 |
|---|
|
Statement
...
| Anchor |
|---|
| _jxpu2pei9l6w |
|---|
| _jxpu2pei9l6w |
|---|
|
Implications
This is one of three closely-related principles regarding data: data is an asset; data is shared; and data is easily accessible. The implication is that there is an education task to ensure that all organizations within the enterprise understand the relationship between value of data, sharing of data, and accessibility to data.
To enable data sharing we must develop and abide by a common set of policies, procedures, and standards governing data management and access for both the short and the long term.
For the short term, to preserve our significant investment in legacy systems, we must invest in software capable of migrating legacy system data into a shared data environment.
We will also need to develop standard data models, data elements, and other metadata that defines this shared environment and develop a repository system for storing this metadata to make it accessible. Where available, we strongly prefer open data formats and protocols as we should always endeavor to reuse existing building blocks.
For the long term, as legacy systems are replaced, we must adopt and enforce common data access policies and guidelines for new application developers to ensure that data in new applications remains available to the shared environment and that data in the shared environment can continue to be used by the new applications.
For both the short term and the long term we must adopt common methods and tools for creating, maintaining, and accessing the data shared across the enterprise.
Data sharing will require a significant cultural change.
This principle of data sharing will continually "bump up against" the principle of data security. Under no circumstances will the data sharing principle cause confidential data to be compromised.
Data made available for sharing will have to be relied upon by all users to execute their respective tasks. This will ensure that only the most accurate and timely data is relied upon for decision-making. Shared data will become the enterprise-wide "virtual single source" of data. "Link, don't duplicate."
| Anchor |
|---|
| _5ishpzm09ct0 |
|---|
| _5ishpzm09ct0 |
|---|
|
CU-PRIN-DATA-003:
Data is Accessible| Anchor |
|---|
| _33x1u2ljljyv |
|---|
| _33x1u2ljljyv |
|---|
|
Statement
...
| Anchor |
|---|
| _fiipbd610fc3 |
|---|
| _fiipbd610fc3 |
|---|
|
Implications
This is one of three closely-related principles regarding data: data is an asset; data is shared; and data is easily accessible. The implication is that there is an education task to ensure that all organizations within the enterprise understand the relationship between value of data, sharing of data, and accessibility to data.
Accessibility involves the ease with which users obtain information.
The way information is accessed and displayed must be sufficiently adaptable to meet a wide range of enterprise users and their corresponding methods of access.
Access to data does not constitute understanding of the data. Personnel should take caution not to misinterpret information.
Access to data does not necessarily grant the user access rights to modify or disclose the data. This will require an education process and a change in the organizational culture, which currently supports a belief in "ownership" of data by functional units.
| Anchor |
|---|
| _8gsyiev2svyv |
|---|
| _8gsyiev2svyv |
|---|
|
CU-PRIN-DATA-004:
Common Vocabulary and Data Definitions...
| Anchor |
|---|
| _q0lw26rmqljj |
|---|
| _q0lw26rmqljj |
|---|
|
Implications
We are lulled into thinking that this issue is adequately addressed because there are people with "data administration" job titles and forums with charters implying responsibility. Significant additional energy and resources must be committed to this task. It is key to the success of efforts to improve the information environment. This is separate from but related to the issue of data element definition, which is addressed by a broad community - this is more like a common vocabulary and definition.
The enterprise must establish the initial common vocabulary for the business. The definitions will be used uniformly throughout the enterprise.
Whenever a new data definition is required, the definition effort will be co-ordinated and reconciled with the corporate "glossary" of data descriptions. The enterprise data administrator will provide this coordination.
Ambiguities resulting from multiple parochial definitions of data must give way to accepted enterprise-wide definitions and understanding.
Multiple data standardization initiatives need to be co-ordinated.
Functional data administration responsibilities must be assigned.
| Anchor |
|---|
| _zccpv99ip38y |
|---|
| _zccpv99ip38y |
|---|
|
CU-PRIN-DATA-005:
Data Security| Anchor |
|---|
| _2doo2ou960jf |
|---|
| _2doo2ou960jf |
|---|
|
Statement
...
Appropriate sharing of information and the release of information via relevant legislation must be balanced against the need to restrict the availability of sensitive, confidential and internal information and the protection of individuals' expectations of privacy and protection of their academic freedom.
Existing laws and regulations require the safeguarding of the privacy of data, while permitting appropriate access.
| Anchor |
|---|
| _yz9ox8e3bb5d |
|---|
| _yz9ox8e3bb5d |
|---|
|
Implications
In order to adequately provide access to information while maintaining secure information, security needs must be identified and developed at the data level, not the application level.
All data shall be classified as Sensitive, Confidential, Internal or Public, as defined in the University Data Classification Policy, and protected appropriately.
Security must be designed into data elements from the beginning; it cannot be added later. Systems, data, and technologies must be protected from unauthorized access and manipulation. Data security must be designed "on the left side" of the development lifecycle flow, not added "on the right" (at the end).
Endpoints, systems and applications must be classified by the types of data they use, registered and protected to the level appropriate for that data classification, per the University Registration and Protection of Systems and Endpoints Policies.
Complete information regarding University data security policies may be found in the Administrative Policy Library: {+}http://cuit.columbia.edu/it-policy-summaries+
| Anchor |
|---|
| _nsylu1hqntql |
|---|
| _nsylu1hqntql |
|---|
|
...
| Anchor |
|---|
| _6zj0k255y8jv |
|---|
| _6zj0k255y8jv |
|---|
|
CU-PRIN-APPL-001:
Technology Independence| Anchor |
|---|
| _ergw99qb8gjm |
|---|
| _ergw99qb8gjm |
|---|
|
Statement
...
| Anchor |
|---|
| _8q6t5ecg3s4n |
|---|
| _8q6t5ecg3s4n |
|---|
|
Implications
This principle will require standards which support portability.
For Commercial Off-The-Shelf (COTS) applications, there may be limited current choices, as many of these applications are technology and platform-dependent.
Subsystem interfaces will need to be developed to enable legacy applications to interoperate with applications and operating environments developed under the enterprise architecture.
Middleware should be used to decouple applications from specific software solutions.
As an example, this principle is supported by the use of Java, and future Java-like protocols, which give a high degree of priority to platform-independence.
This principle may lead to conflict with Cloud SaaS or PaaS which frequently derive their benefit from vendor-proprietary approaches.
| Anchor |
|---|
| _bl72pchlnwxj |
|---|
| _bl72pchlnwxj |
|---|
|
| Anchor |
|---|
| _idubhtlsuqtp |
|---|
| _idubhtlsuqtp |
|---|
|
CU-PRIN-APPL-002: Buy Before Build: Cloud First
...
| Anchor |
|---|
| _jx50fx8gsknm |
|---|
| _jx50fx8gsknm |
|---|
|
Implications
Business process re-engineering may be required in order to align our processes to leading practices.
Every effort should be made to avoid application customization as such customization has the analogous downside of requiring ongoing maintenance and support and lacks the benefit of development cost that is shared across a wider customer base.
Consider a common platform service (e.g. workflow tool) as the basis for application development where a direct application is not available.
When investigating cloud options, prefer SaaS over Platform as a Service (PaaS) over Infrastructure as a Service (IaaS), moving lower in the stack only if a higher-stack service is not available.
When using open source, contribute improvements made back to the open source product. The extra effort will benefit the community and the institution in the long run.
| Anchor |
|---|
| _jwctj4z76l9u |
|---|
| _jwctj4z76l9u |
|---|
|
| Anchor |
|---|
| _hhv4r9vvbp7w |
|---|
| _hhv4r9vvbp7w |
|---|
|
CU-PRIN-APPL-003: Service Oriented Architecture (SOA)
...
| Anchor |
|---|
| _mf3nhxz7300e |
|---|
| _mf3nhxz7300e |
|---|
|
Implications
RESTful APIs are prefered over SOAP when both are available.
Integration with legacy monolithic applications and their data can be difficult and may require acquiring/developing middleware that makes legacy data available.
Open authentication/authorization protocols such as OAUTH should be used to meet security and interoperability goals. Web browser-centric protocols are acceptable but may limit applicability to mobile and other non-web applications.
Prefer SOA web services calls over batch interface files as the means of sharing data. (See "Link, don't duplicate," above).
| Anchor |
|---|
| _23a2hsmx0s64 |
|---|
| _23a2hsmx0s64 |
|---|
|
CU-PRIN-APPL-004: Reuse
| Anchor |
|---|
| _bopk7tt5in2i |
|---|
| _bopk7tt5in2i |
|---|
|
Statement
...
| Anchor |
|---|
| _3zjwf5q6nh3t |
|---|
| _3zjwf5q6nh3t |
|---|
|
Implications
Use established technology standards such as operating systems, app server, database, identity management infrastructure, common application platform services, common software, and common performance and capacity monitoring tools.
Use the standard application development tool chain of source code version control, provisioning, continuous integration, automated testing, etc.
Common architecture and solution building blocks will be maintained in the Enterprise Repository.
| Anchor |
|---|
| _6zce4e6wwwk2 |
|---|
| _6zce4e6wwwk2 |
|---|
|
Technology Principles
...
| Anchor |
|---|
| _eeie927o2zlj |
|---|
| _eeie927o2zlj |
|---|
|
CU-PRIN-TECH-001:
Control Technical Diversity...
There is a real, non-trivial cost of infrastructure required to support alternative technologies for processing environments. There are further infrastructure costs incurred to keep multiple processor constructs interconnected and maintained.
Limiting the number of supported components will simplify maintainability and reduce costs.
The business advantages of minimum technical diversity include: standard packaging of components; predictable implementation impact; predictable valuations and returns; redefined testing; utility status; and increased flexibility to accommodate technological advancements. Common technology across the enterprise brings the benefits of economies of scale to the enterprise. Technical administration and support costs are better controlled when limited resources can focus on this shared set of technology.
| Anchor |
|---|
| _4xdwum5i8g0c |
|---|
| _4xdwum5i8g0c |
|---|
|
Implications
Policies, standards, and procedures that govern acquisition of technology must be tied directly to this principle.
Technology choices will be constrained by the choices available within the technology blueprint. Procedures for augmenting the acceptable technology set to meet evolving requirements will have to be developed and put in place.
We are not freezing our technology baseline. We welcome technology advances and will change the technology blueprint when compatibility with the current infrastructure, improvement in operational efficiency, or a required capability has been demonstrated.
| Anchor |
|---|
| _dpxblvji53ak |
|---|
| _dpxblvji53ak |
|---|
|
CU-PRIN-TECH-002:
Interoperability| Anchor |
|---|
| _ltrjzuydxovm |
|---|
| _ltrjzuydxovm |
|---|
|
Statement
...
| Anchor |
|---|
| _7wsoroe6uz3z |
|---|
| _7wsoroe6uz3z |
|---|
|
Implications
Interoperability standards and industry standards will be followed unless there is a compelling business reason to implement a non-standard solution.
A process for setting standards, reviewing and revising them periodically, and granting exceptions must be established.
The existing IT platforms must be identified and documented.