1. Lecture 1: INF 411 Information Engineering Enterprise Architecture Dr. Taysir Hassan Abdel Hamid September 28, 2015

2. Course Outline Introduction to Information Engineering Enterprise computing Different models of the Enterprise Ontologies

3. Book Used Marc Lankhorst et al. Enterprise Information Architecture at Work: Modeling, Communication, and Analysis. Springer-Verlag Berlin Heidelberg, 2005.

4. Grading Scheme Final Exam: 70 points Year Work: 30 points (Midterm Exam: 10, Assignments & Discussions: 20)

5. Many stakeholders within and outside the company can be identified, ranging from top- level management to software engineers.

6. Enterprise???? The term enterprise is used because it is generally applicable in many circumstances, including: 1.Public or private sector organizations 2.An entire business or corporation 3.A part of a larger enterprise (such as a business unit) 4.A conglomerate of several organizations, such as a joint venture or partnership 5.A multiply outsourced business operation 6.Many collaborating public and/or private organizations in multiple countries

7. The term enterprise includes the whole complex, socio-technical system, [5] including: [5] 1.people 2.information 3.technology 4.business (e.g. operations)

8. Socio-technical system Let’s take as an example a relatively simple technology: a set of 10 microcomputers connected to by a network. The social and ethical issues associated with these networked computers will change dramatically depending upon the socio-technical system in which they are embedded. For instance, are the networked computers:

9. Our focus enterprise architecture, the practice that tries to describe and control an organisation’s structure, processes, applications, systems, and technology in such an integrated way. we focus on methods and techniques for making and using integrated descriptions by means of architecture models, visualisation of these models for various stakeholders, and analysis of the impact of changes.

10. An architecture model is not just useful to provide insight into the current or future situation; it can also be used to evaluate the transition from ‘as is’ to ‘to be’.

11. More definitions An enterprise architecture framework handle:enterprise architecture framework Tools, techniques, artifact descriptions, process models, reference models and guidance used by architects in the production of enterprise-specific architectural description.

12. More definitions Enterprise architects work with stakeholders, both leadership and subject matter experts, to build a holistic view of the organization's strategy, processes, information, and information technology assets. The systems architect establishes the basic structure of the system, defining the essential core design features and elements that provide the framework for all that follows, and are the hardest to change later.

13. Enterprise Life Cycle Enterprise Life Cycle (ELC) in enterprise architecture is the dynamic, iterative process of changing the enterprise over time by incorporating new business processes, new technology, and new capabilities, as well as maintenance, disposition and disposal of existing elements of the enterprise.enterprise architectureprocessenterprisebusiness processes technology maintenancedispositiondisposal

15. This concept aids in the implementation of an Enterprise Architecture, and the Capital Planning and Investment Control (CPIC) process that selects, controls, and evaluates investments. Overlying these processes are human capital management and information security management.human capital managementinformation security management

16. When these processes work together effectively, the enterprise can effectively manage information technology as a strategic resource and business process enabler.information technology

17. Quality management: ISO 9001 The ISO 9001:2000 standard (ISO 2000) of the International Organization for Standardization (ISO) outlines criteria for a good quality management system (QMS). Starting from general, overall requirements, the standard states the responsibilities of management for the QMS. It then gives requirements for resources, including personnel, training, the facility, and work environment.

18. Quality management and enterprise architecture form a natural combination: QM is concerned with what needs to be designed, documented, controlled, measured, and improved, and the EA determines how these high-quality processes and resources are organized and realized.

19. What is quality? Quality, simplistically, means that a product should meet its specification. This is problematical for software systems – There is a tension between customer quality requirements (efficiency, reliability, etc.) and developer quality requirements (maintainability, reusability, etc.); – Some quality requirements are difficult to specify in an unambiguous way; – Software specifications are usually incomplete and often inconsistent.

20. The quality compromise We cannot wait for specifications to improve before paying attention to quality management. We must put quality management procedures into place to improve quality in spite of imperfect specification.

21. Scope of quality management Quality management is particularly important for large, complex systems. For smaller systems, quality management needs less documentation and should focus on establishing a quality culture.

22. Quality management activities Quality assurance – Establish organisational procedures and standards for quality. Quality planning – Select applicable procedures and standards for a particular project and modify these as required. Quality control – Ensure that procedures and standards are followed by the software development team. Quality management should be separate from project management to ensure independence.

23. Quality management and software development

24. The quality of a developed product is influenced by the quality of the production process. This is important in software development as some product quality attributes are hard to assess. However, there is a very complex and poorly understood relationship between software processes and product quality. Process and product quality

25. Process-based quality There is a straightforward link between process and product in manufactured goods. More complex for software because: – The application of individual skills and experience is particularly imporant in software development; – External factors such as the novelty of an application or the need for an accelerated development schedule may impair product quality. Care must be taken not to impose inappropriate process standards - these could reduce rather than improve the product quality.

26. The process improvement cycle

27. Process measurement – Attributes of the current process are measured. These are a baseline for assessing improvements. Process analysis – The current process is assessed and bottlenecks and weaknesses are identified. Process change – Changes to the process that have been identified during the analysis are introduced. Process improvement stages

28. Process quality and product quality are closely related and process improvement benefits arise because the quality of the product depends on its development process. A good process is usually required to produce a good product. For manufactured goods, process is the principal quality determinant. For design-based activity, other factors are also involved especially the capabilities of the designers. Process and product quality

29. Process-based quality

30. Principal product quality factors

31. Quality factors For large projects with ‘average’ capabilities, the development process determines product quality. For small projects, the capabilities of the developers is the main determinant. The development technology is particularly significant for small projects. In all cases, if an unrealistic schedule is imposed then product quality will suffer.

32. Service Delivery, comprising service-level management, availability management, financial management for IT services, IT service contingency management, and capacity management; Service Support, covering problem management, service desk, change management, release management

33. IT implementation: CMM and CMMI (Cont…) CMMI addresses the integration of software development with other engineering activities and expands the scope to encompass the entire product life cycle, including systems engineering, integrated product and process development, and supplier sourcing.

34. Understanding CMMI Representations There are two types of representations in the CMMI models: – staged – continuous A representation allows an organization to pursue different improvement objectives The organization and presentation of the data are different in each representation. However, the content is the same.

35. Staged Representation Provides a proven sequence of improvements, each serving as a foundation for the next Permits comparisons across and among organizations by the use of maturity levels Provides an easy migration from the SW- CMM to CMMI Provides a single rating that summarizes appraisal results and allows comparisons among organizations

36. CMMI Model Representations

37. Maturity Levels A maturity level is a well-defined evolutionary plateau of process improvement. There are five maturity levels. Each level is a layer in the foundation for continuous process improvement using a proven sequence of improvements, beginning with basic management practices and progressing through a predefined and proven path of successive levels.

38. The Maturity Levels 1 2 3 4 5 Process unpredictable, poorly controlled, and reactive Process characterized for projects and is often reactive Process characterized for the organization and is proactive Process measured and controlled Focus on continuous process improvement Optimizing Quantitatively Managed Defined Initial Managed Optimizing Defined

39. The Capability Levels 5 Optimizing 4 Quantitatively Managed 3 Defined 2 Managed 1 Performed 0 Incomplete

40. Model Components Process Areas (PA) – Specific Goals(SG)Required Specific Practices (SP)Expected – Typical Work ProductsInformative – Sub-practicesInformative – Notes Informative – Discipline AmplificationsInformative – ReferencesInformative – Generic Goals(GG)Required Generic Practices (GP)Expected – Generic Practice ElaborationsInformative

41. Requirements Management Requirements Development Technical Solution Product Integration Verification Validation Engineering Project Management Project Planning Project Monitoring and Control Supplier Agreement Management Integrated Project Management(IPPD) Integrated Supplier Management (SS) Integrated Teaming (IPPD) Risk Management Quantitative Project Management Organizational Process Focus Organizational Process Definition Organizational Training Organizational Process Performance Organizational Innovation and Deployment Process Management Configuration Management Process and Product Quality Assurance Measurement and Analysis Causal Analysis and Resolution Decision Analysis and Resolution Organizational Environment for Integration (IPPD) Support Continuous Representation: Organization of Process Areas Category Process Area

42. Process Areas Organized by Category Process Management Organizational Process Focus Organizational Process Definition Organizational Training Organizational Process Performance Organizational Innovation and Deployment Project Management Project Planning Project Monitoring and Control Supplier Agreement Management Integrated Project Management (for IPPD*) Risk Management Integrated Teaming Integrated Supplier Management** Quantitative Project Management Engineering Requirements Development Requirements Management Technical Solution Product Integration Verification Validation Support Configuration Management Process and Product Quality Assurance Measurement and Analysis Organizational Environment for Integration* Decision Analysis and Resolution Causal Analysis and Resolution analyze empoweranalyze employmeasure & assist standardize processes

43.  The context of this software architecture may be given by an enterprise architecture, which provides constraints and guidelines for individual software projects.  As such, enterprise architecture is something that becomes especially useful (or even necessary) at CMMI Level 3 and beyond, where projects have to conform to organization-wide standards and guidelines.