Contact CIS
Georgia State

  About CIS

  Academic Programs

        Minor in CIS
        BBA CIS
        MBA CIS
        MS ISAC
        MS IS
        MS IS MIT (1 year)
        PhD CIS
        Executive Education
        Health Informatics


  Business Corner

  Faculty & Research


  Student Information

  CIS Alumni

  CIS Internship


Employ an Intern

Give to CIS

 Driving Directions


CIS 8090:
Enterprise Architecture


CSP 1-8, CIS 8030


Textbook: Len Bass, Paul Clements, Rick Kazman, Software architecture in Practice, 2nd Edition,  Addison Wesley Professional, 2003.

Required case packet: IMPORTANT SO PLEASE READ THIS! ===> The packet of cases is available exclusively from The Print Shop, #6 Decatur Street, downtown near Five Points. The cost is largely that of royalties charged on the cases from Harvard and other sources.


 This course will explore the concepts, principles, and state-of- the-art methods in enterprise architectures, including architectural styles, architecture description languages (ADL), software connectors, dynamism in architectures, and architecture-based testing and analysis. The course will help understand the role of architecture in software engineering, specifically during requirements analysis, design (including object-oriented design and related notations, such as UML), and implementation. The course will also cover practical applicability of architectures in software reuse and component interoperability platforms (such as CORBA, Enterprise JavaBeans, COM/DCOM, and .NET).


A enterprise architecture is an abstract view of a system which is distinct from the details of implementation, algorithms, and data. Enterprise architecture has become an area of major interest in the software development community. A number of architecture modeling notations and support tools, as well as new architectural styles, have emerged in the recent years. Architecture-based software development helps shift focus to coarser-grained building blocks and their interconnections rather than focusing on the code level. In short it is an Enterprise-level view of the portfolio of systems elements with a goal toward greater integration and more efficient deployment and exploitation of those elements.

Another objective of this course is participants to understand the issues and decisions that must be made when managing an ERP project. Every project is different; there are different organizational contexts, infrastructures and strategies. Even so systematic approaches are believed to improve the likelihood of ERP project implementation success. This is because methods draw on standards and previous learning and require the reuse of resources and competencies. The problem is that no single method is universal; no method fits all settings. A methods engineering approach is one where using high-level analysis and assessment modeling techniques a development team in which the knowledge management development team analyzes the business situation and, drawing from an inventory of method pieces, assembles methods technique fragments that together comprise a customer/engagement specific methodology. This course describes general lifecycle and project management models for ERP systems. The issues are discussed and illustrated via academic and industry cases.

Accordingly, this course gives explicit consideration to the notion of enterprise architecture in general terms and though examination of an instance of well developed architectures in the form of ERP systems. The course will provide a generalized understanding of the fundamentals of software architectural themes and concepts. Also, methods, formalisms and tools necessary for transferring architectural decisions to designs and implementations will be covered.


    At the end of the semester, the student will:

·         differentiate the relationships between system qualities and enterprise architectures

·         recognize software architectural patterns and their relationship to system qualities

·         analyze enterprise architecture evaluation

·         assess attribute-driven design within the organization

·         understand and recognize when/where architectural reuse may be employed

·         postulate the future of enterprise architectures

·         understand and differentiate between a stakeholder- and view-based approach to documenting enterprise architectures

·         know how to implement formal and informal notations (including the Unified Modeling Language [UML]  in  representing elements and relations in a view

·         develop a service-oriented architecture

·         understand how to utilize the role of architecture in achieving agility




Mid Term 

Assesses the understanding of fundamental enterprise architecture themes and concepts. 

Final Exam

Tests understanding of issues in transferring architectural decisions to designs and implementations. The focus is on research and commercial off-the-shelf (OTS) tools, techniques, and interoperability platforms covered in the latter part of the course.

Class project

In-depth treatment of a topic in enterprise architectures. The project will be conducted by teams of four students. Smaller or larger teams, as well as individual projects will be allowed under special circumstances Depending on the nature of the project, it may involve implementation. Possible project ideas will be discussed in class in Week 5.

  • Proposal  3%

  • Progress report  6%

  • Presentation 8%

  • Final report  8%

Assignment 1: Definitions of basic concepts

Assess the student’s understanding of the basic software engineering concepts and your perception of several enterprise architecture terms and concepts. 

Assignment 2: Case study system architecture

Develop and analyze an architectural breakdown for the system described in the case study discussed in class.

Assignment 3: Example system architecture and implementation

Development of a partial architectural description of the software system from Assignment 2.

Assignment 4: Example system implementation

Development of a partial implementation of the architecture from Assignment 3 using the supplied architecture implementation infrastructure.

All work must be your own.  Duplicate lab assignments will be given a grade of "zero".  Both the person copying the assignment and the person supplying the copy will be penalized equally!

CONDUCT OF COURSE: Lecture/Discussions, Demos, and Labs:

    Class sessions will be divided between: (1) lecture/discussion of certain software concepts and features, (2) instructor demonstrations of these same software concepts and features, and (3) student laboratory sessions working with these same software concepts and features.

The purpose of this pedagogical approach is to introduce and reinforce ideas and skill sets so that students can master these on their own after class hours. To bring this knowledge to a highly proficient, professional level, students will have to spend time and effort outside of class working in the GSU computer labs or on their own micros.

To ensure that you have the basic knowledge that will allow you to function on your own after class, be sure to ask the instructor questions during class, either during the lecture/discussion, demo, or lab.


Grading Policy

Mid Term 


Class project


Assignment 1


Assignment 2


Assignment 3:


Assignment 4:


Class Participation





    A 'W' grade will be assigned if a student withdraws before the middle of the semester while maintaining a passing grade.  A 'WF' will be assigned if a student withdraws before the middle of the semester while doing failing work OR after the middle of the semester.  Missing more than two consecutive classes without the instructor's permission will be considered a voluntary withdrawal.  The grade of 'W' or 'WF' will depend upon whether the student stopped actively attending prior to the mid-point of the semester.

Class participation
Expectations regarding attendance and class participation:

Since this is a case-based and discussion-oriented course, regular attendance and participation is required. In evaluating your class participation in discussions of cases and articles, both the quantity and quality of participation is taken into account. As a wise professor once said: "You can't have any quality if you don't have any quantity and you can't have any quantity if you aren't in class."

Absences will have an adverse effect on your participation score for the course. Students are therefore expected to attend all classes, except when precluded by emergencies, religious holidays, or other extenuating circumstances. If you will be absent from class for any reason, please notify me in advance if possible.

It is reasonable to expect on time start for each course session. This is true in our work lives so it is true in the conduct of this class. Classes will begin on time. Material missed due to late arrival should be acquired from classmates or project team members. Quizzes or presentations missed due to late arrival will be graded at a zero.

Simply showing up for class, important as it may be, is not to be equated with participation. Students should make an effort to contribute to each and every class discussion. Before coming to class, thorough preparation of each case (and associated articles) is essential. The case method of teaching is only effective when participants have extensively analyzed each case and are prepared to contribute to the case discussion. Students should expect to be "cold called" throughout the course and should be prepared accordingly. This is a normal part of case method teaching. The quality of your contributions to case discussions will be evaluated using the following criteria:

Things I view positively in marking discussion participation include:

·         Does the contribution represent a solid analysis and some insight into the case or is it just a reiteration of case facts?

·         Does the contribution demonstrate an ability to listen to and build from what others have said?

·         Does the contribution demonstrate useful ideas, coherently and succinctly expressed

·         Does the contributor regard, respect and acknowledge other's contributions If the contributor disagrees with other's positions or analysis does s/he offer constructive disagreement

·         Does the contributor demonstrate a good sense of humor'

·         Does the contribution move the discussion to an important area or does it just rephrase what has already been said?

·         If "cold called," was the student prepared?

Things I view negatively in marking discussion participation include:

·         ∑lack of involvement - silence, detachment or disinterest

·         ∑leading our discussion into unrelated topics

·         ∑spending undue amount of time on minor points

·         ∑long, rambling comments.

·         ∑being absent or unprepared, or passing on a cold call

Expectations for Written assignments and presentations

I expect professional looking documents which give proper credit to all sources of intellectual material. Deliverable documents must be:

·         Typed, (word processed) spell checked and paginated, with suitable.

·         All authors must be identified. Generally a title page is required except on executive memoranda.

·         All citations must be identified in the text (in short form) and in an attached bibliography. Use any standard format as long as it is used consistently.

See the Turabian Manual of Style, Chicago Manual of Style, Harvard Manual or other suitable reference guide to writers if you are not familiar with this requirement. Papers which do not properly cite sources will be returned upgraded. I also recommend that you acquire a copy of the software EndNote to assist in citations and bibliography preparation if you will be doing any academic or professional writing. C.f., www.Endnote.com for more information.

In addition to paper copies of assignments, electronic (and certifiably virus free) copies should be emailed to me on the day they are due.

·         File names should clearly identify you by last name followed by the assignment number. E.g., cis8660 Truex case#1-Amazon


  • Prerequisites are strictly enforced. Students failing to complete a prerequisites with a grade of “C” or higher will be administratively withdrawn from the course in which they are in violation with a loss of tuition fees. There are no exceptions.

  • Students are expected to attend all classes and group meetings, except when precluded by emergencies, religious holidays or bona fide extenuating circumstances.

  • Make-up exams will not be given.  However, if a student has a planned absence, he or she may take the exam earlier with the permission of the instructor.

  • Students who, for non-academic reasons beyond their control, are unable to meet the full requirements of the course should notify the instructor. Incompletes may be given if a student has ONE AND ONLY ONE outstanding assignment.

  • A “W” grade will be assigned if a student withdraws before mid-semester while maintaining a passing grade. Withdrawals after the mid-semester date will result in a grade of “WF”. Refer to GSU catalog or Registrar’s office for details.

  • Spirited class participation is encouraged and informed discussion in class is expected. This requires completing readings and assignments before class.

  • Unless specifically stated by the instructor, all exams and lab assignments are to be completed by the student alone.

  • Within group collaboration is allowed on project work. Collaboration between project groups will be considered cheating unless specifically allowed by an instructor.

  • Copy work from the Internet without a proper reference will be considered plagiarism and subject to disciplinary action as delineated in the Student Handbook.

  • Any non-authorized collaboration will be considered cheating and the student(s) involved will have an Academic Dishonesty charge completed by the instructor and placed on file in the Dean’s office and the CIS Department. All instructors regardless of the type of assignment will apply this Academic Dishonesty policy equally to all students. See excerpt from the Student Handbook below:


(Abstracted from GSU’s Student Handbook Student Code of Conduct “Policy on Academic Honesty and Procedures for Resolving Matters of Academic Honesty” - http://www.gsu.edu/~wwwcam/academichonesty.html) Students are responsible for the information contained in this website.

      As members of the academic community, students are expected to recognize and uphold
standards of intellectual and academic integrity. The University assumes as a basic and minimum standard of conduct in academic matters that students be honest and that they submit for credit only the products of their own efforts. Both the ideals of scholarship and the need for fairness require that all dishonest work be rejected as a basis for academic credit. They also require that students refrain from any and all forms of dishonorable or unethical conduct related to their academic work.

Students are expected to discuss with faculty the expectations regarding course assignments and standards of conduct. Here are some examples and definitions that clarify the standards by which academic honesty and academically honorable conduct are judged at GSU.

Plagiarism. Plagiarism is presenting another person’s work as one’s own. Plagiarism includes any paraphrasing or summarizing of the works of another person without acknowledgment, including the submitting of another student’s work as one’s own. Plagiarism frequently involves a failure to acknowledge in the text, notes, or footnotes the quotation of the paragraphs, sentences, or even a few phrases written or spoken by someone else. The submission of research or completed papers or projects by someone else is plagiarism, as is the unacknowledged use of research sources gathered by someone else when that use is specifically forbidden by the faculty member. Failure to indicate the extent and nature of one’s reliance on other sources is also a form of plagiarism. Failure to indicate the extent and nature of one’s reliance on other sources is also a form of plagiarism. Any work, in whole or part, taken from the internet or other computer based resource without properly referencing the source (for example, the URL) is considered plagiarism. A complete reference is required in order that all parties may locate and view the original source. Finally, there may be forms of plagiarism that are unique to an individual discipline or course, examples of which should be provided in advance by the faculty member. The student is responsible for understanding the legitimate use of sources, the appropriate ways of acknowledging academic, scholarly or creative indebtedness, and the consequences of violating this responsibility.

Cheating on Examinations. Cheating on examinations involves giving or receiving unauthorized help before, during, or after an examination. Examples of unauthorized help include the use of notes, texts, or “crib sheets” during an examination (unless specifically approved by the faculty member), or sharing information with another student during an examination (unless specifically approved by the faculty member). Other examples include intentionally allowing another student to view one’s own examination and collaboration before or after an examination if such collaboration is specifically forbidden by the faculty member.

Unauthorized Collaboration. Submission for academic credit of a work product, or a part thereof, represented as its being one’s own effort, which has been developed in substantial collaboration with assistance from another person or source, or computer honesty. It is also a violation of academic honesty knowingly to provide such assistance. Collaborative work specifically authorized by a faculty member is allowed. \

Tentative Schedule

The course syllabus provides a general plan for the course; deviations may be necessary.




Assignments and Exams


Course introduction




Origins of enterprise architectures

  • F. P. Brooks, Jr. No Silver Bullet: Essence and Accidents of Software Engineering. IEEE Computer, April 1987.

  • B. W. Boehm and W. L. Scherlis. Megaprogramming. Software Technology Conference 1992, Los Angeles, April 1992.



Introduction to enterprise architectures

  • Chapter 1-2



Scope of enterprise architectures:
Canonical case studies

  • Chapter 3



Scope of enterprise architectures:
C4 case study analysis

  • Case Study: Call Center Customer Care (C4) System.


Scope of enterprise architectures:
Distributed flight simulation case study analysis

  • R. Kazman. Distributed Flight Simulation: A Challenge for Software architecture. Technical Report, University of Waterloo.

  • Assignment 1 due


Software architects: People and teams

  • P. Kruchten. The Software Architect and the Software architecture Team. 1st Working IFIP Conference on Software architectures, San Antonio, TX, February 1999.


Project suggestions




Arriving at an architecture

  • Chapter  4-5

  • D. L. Parnas. On the Criteria To Be Used in Decomposing Systems into Modules. Communications of the ACM, December 1972.

  • P. Kruchten. Mommy, Where Do Software architectures Come from? 1st International Workshop on Architectures for Software Systems, Seattle, WA, April 1995.

  • P. Gruenbacher et al. Reconciling Software Requirements and Architectures with Intermediate Models. Journal on Software and System Modeling, December 2003.


Project discussion




Architecture description languages (ADLs)

  • Chapter 6

  • Chapter 7:

  • N. Medvidovic and R. N. Taylor. A Classification and Comparison Framework for Software architecture Description Languages. IEEE Transactions on Software Engineering, January 2000.


ADL Examples

  • Chapter 8, 11

  • D. C. Luckham and J. Vera. An Event-Based Architecture Definition Language. IEEE Transactions on Software Engineering, September 1995.

  • Assignment 2 due


Domain-specific software architectures (DSSA)

  • Chapter 14

  • W. Tracz. DSSA (Domain-Specific Software architecture) Pedagogical Example. ACM SIGSOFT Software Engineering Notes, July 1995.

  • D. E. Perry. Generic Descriptions for Product Line Architectures. 2nd International Workshop on Development and Evolution of Software architectures for Product Families (ARES II), Las Palmas de Gran Canaria, Spain, February 1998. 

  • Project proposals due

Architectural styles

  • Chapter 9,10




 Mid term exam review



Mid Term Exam


Service Oriented Architecture

Channabasavaiah,  Holley, and Tuggle, Migrating to Service Oriented Architecture, http://www-106.ibm.com/developerworks/webservices/library/ws-migratesoa/

 Assignment 3 due


Software connectors

  • Chapter 9.

  • N. R. Mehta et al. Towards a Taxonomy of Software Connectors. 22nd International Conference on Software Engineering, Limerick, Ireland, June 2000. 

  • Project progress reports due

Dynamism in enterprise architectures

  • J. Magee and J. Kramer. Dynamic Structure in Software architectures. 4th ACM SIGSOFT Symposium on the Foundations of Software Engineering, San Francisco, CA, October 1996. 



Architecture-based testing and analysis

  • Chapter 12

  • M. Moriconi et al. Correct Architecture Refinement. IEEE Transactions on Software Engineering, April 1995.



Agile systems development

·        Service-Oriented Architecture: Considerations for Agile Systems,





From architecture to design:
Overview of UML

Role of UML in enterprise architectures

  • Chapter 13

  • N. Medvidovic et al. Modeling Software architectures in the Unified Modeling Language. ACM Transactions on Software Engineering and Methodology, January 2002.


From architecture to implementation

  • D. Krieger and R.M. Adler. The Emergence of Distributed Component Platforms. IEEE Computer, March 1998.

  • Assignment 4 due


Software interconnection technologies

  • Chapter 14

  • S. P. Reiss. Connecting Tools Using Message Passing in the Field Environment. IEEE Software, July 1990.

  • M. J. Maybee et al. Multilanguage Interoperability in Distributed Systems: Experience Report. 18th International Conference on Software Engineering, Berlin, Germany, March 1996.


Middleware CORBA

  • S. Vinoski. CORBA: Integrating Diverse Applications within Distributed Heterogeneous Environments. IEEE Communications Magazine, February 1997.



Middleware COM / DCOM / .NET

  • On-Line Documentation: COM, DCOM, .NET


Middleware – JavaBeans and Enterprise JavaBeans


  • Chapter 16, 19

  • R. Natarajan and D. S. Rosenblum. Supporting Architectural Concerns in Component Interoperability Standards. IEE Proceedings – Software, December 2000. 

  • Project presentations and demonstrations

  • Assignment 5 due


Final Exam Week




  • Final Exam



Computer Information Systems Department

35 Broad Street | Robinson College of Business | 9th Floor | Atlanta | Georgia 30302

 404 - 413 - 7360


Prospective Students | Current Students | Events | Directory



  Quick Links
   Graduate Advisers
   Average Scores
   Class Schedule
  Health Informatics

Syllabus List


Apply Online: