IT Architecture Home || Provost Home || Emory Home | Search | Index | Help

IT Architecture Documents

Presentations and Articles

Old IT at Emory pages

Give Feedback (closed)

IT-ARCH Discussion List (closed)

Other Sites on IT Architecture

Get a free copy of Acrobat® Reader

 

Changes to Document 2: Designing Emory's IT Architecture

Leading to version 2.6.1, March 6, 2002
  • Changed status to "Adopted by CIRT February 20, 2002".

Leading to version 2.6, September 19, 2001
  • Changed status to "Ready for Adoption".

Leading to version 2.5.9, May 11, 2001
  • Numbered implications in B-7 & C-4.
  • Table of Contents and Revisions no longer fit together on one page, so put them on separate pages.

Leading to version 2.5.8, April 13, 2001
  • Removed the footnote from the Preface. Updated the Preface and Next Steps to reflect the current situation.
  • In Domains:
    • Collaboration: Moved "document management" and "imaging" to the Data and information management domain.
    • Platform: Removed the word "platform" from its definition.
    • Application: Expanded the acronyms, changed "office automation" to "office productivity applications," deleted "repositories," and moved "report writers" to the Data and information management domain.
  • Appendix 1: Many edits and wording changes to improve clarity and ease of reading.

Leading to version 2.5.7, February 14, 2001
  • Added Configuration and Implementation Principles as section 5, continuing the numbering of the other principles. The Configuration and Implementation Principles follow the table showing how the principles support the requirements, because they are not included in that table.
  • Added the word "design" to the header of sections 3 and 4 to distinguish the section 3 principles from those in section 5, and indicate that the table only applies to the principles in section 3 (the "design" principles).
  • Changed a domain name from "Applications" to "Application".

Leading to version 2.5.6, Jan. 18, 2001
  • Incorporated feedback from Harriet King.
  • Updated next steps to incorporate feedback concerning the need to know the budgetary implications by year for planning purposes, plus revisions to B.6 and other principles.
  • Addressed feedback from the Domain Task Forces that B.6 covered two subjects, and that making data "freely available" was counter to the security architecture. B.6 was changed to address the ability to find out about the existence of resources and who to ask for access to them. B.8 was added to address making data accessible within the security architecture.
  • Copy-edited the entire document to improve clarity and fix formatting problems.
  • Page 8, tables: Redid B.6 and added B.8. Adjusted the spacing to make the tables fit on one page. Added a descriptor to each table.
  • Page 9, Domain Descriptions:
    • Added a reason the domains might change.
    • Moved firewalls out of domains other than Security. Although the domains interact, each technology should be governed by one and only one domain.
    • Data and Information Management: Added "databases", "data marts" and "extract, movement and cleansing tools." Moved ftp server to Intranet & e-Commerce domain.
    • Network: Added video, wireless, and Internet.
    • Distributed environment management: Added "business recovery."
    • Security: Added technologies that are mentioned in the security architecture. Added "identification" and moved "firewalls" to later in the description.
    • Applications: Added procurement.
    • Intranet: Changed the name of this domain to include e-Commerce. The purpose is to reflect wider applicability than simply "intra-enterprise." Moved "portals" here and qualified them as "web-based". Added e-commerce and ftp server. Made clear that "authoring" is "web authoring."
    • On-line learning: Fixed redundant wording. Removed "portals." The purpose of a portal in this context is already included in the description of this domain, and a portal is simply a technology to implement that capability.
  • Page 15, A.2: Adjusted last justification to recognize that the highest security level might not allow remote access or remote management.
  • Page 24, B.6: Added two more examples to illustrate how this principle is applied to scheduled transactions and workflow. Changed the size of the text to make it all fit on one page.
  • Added a glossary as Appendix 3.

Leading to version 2.5.1, Aug. 4, 2000
  • Corrected some typographical errors.
  • P.15, Corollary a: Made "organization" plural to reflect role of Network Communications Division.
  • P.16, Implication 2: Added "products" to the list in in the second sentence.
  • P.16, Implications: Inserted new item 5.

Leading to version 2.5, July 26, 2000
  • Page 4: Described linkage of the conceptual architecture principles to the mission by way of the architectural requirements. Expanded the bullet list to make it easier to comprehend. Other changes added word variety.
  • Page 5: Added an example to show how the architecture can help make a decision.
  • Pages 6 & 16: Added budget cycle to review timing.
  • Pages 6 & 22: Added mission-driven complexity.
  • Pages 7 & 24: Emphasized move away from batch.
  • Page 8: Moved Appendix 3 (table) to a Section 4 in the body following Section 3.
  • Pages 9-10: Changed the list of domains and provided definitions for them. Added "management" to Data domain name; made Management a separate domain; moved Integration to a separate domain; changed web to Intranet; added Directory domain; defined the domains. Noted that trends also help choose the domains.
  • Page 11: Clarified phase terminology; defined the phrase "domain principles"; noted that task forces disband; mentioned resource constraints.
  • Page 12: Linked principles back to requirements; renamed Scope "Organizational Scope"; added Level of Applicability.
  • Page 17: B.1 -- Added phrase about engineering in the ability to change and out inhibitors to change; added implication of design reviews and use of hooks.
  • Page 21: Added implication of reuse librarian.
  • Page 22: Added example of how an increase in complexity might be justified by one's mission.
  • Page 30: C.3 -- Changed status to standards track; removed sentence about breaking contract; removed implication bullet about architecture internal to Emory (repetitive).

IT Architecture Home || Provost Home || Emory Home | Search | Index | Help

©2002 Emory University
Legacy Site for reference