1. Lecture 1: INF 411 Information Engineering Enterprise Architecture
Dr. Taysir Hassan Abdel Hamid
Associate Professor,
Information Systems Department,
Faculty of Computers & Information
Assiut University
October 5, 2015

2. Course Outline Introduction to Information Engineering
Enterprise Architecture
Business Process Management
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. Enterprise????
The term enterprise is used because it is generally applicable in many circumstances, including:
Public or private sector organizations
An entire business or corporation
A part of a larger enterprise (such as a business unit)
A conglomerate of several organizations, such as a joint venture or partnership
A multiply outsourced business operation
Many collaborating public and/or private organizations in multiple countries

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

7. 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:

8. Examples in Egypt Telecom: Mobinil, Etisalat, vodafone, TEDATA
Technology: Microsoft Egypt, IBM Egypt
Oil & Gas: Enppi
Hypermarket: Carefour
Travel: EgyptAir
Retail: Cook Door, GAD

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. Stakeholder: an individual, team, or organization (or classes thereof) with interests in, or concerns relative to, a system.
Many stakeholders within and outside the company can be identified, ranging from top-level management to software engineers.

11. An enterprise architecture framework handle:
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. 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’.
In current practice, architecture descriptions are heterogeneous in nature: each domain has its own description techniques, either textual or graphical, either informal or with a precise meaning.
Different fields speak their own languages, draw their own models, and use their own techniques and tools

14. This places a high demand for QUALITY on the architecture.
QUALITY means that the architecture actually helps in achieving essential business objectives.

15. Needed Techniques for describing architectures in a coherent way
Methods to analyze the effects of architectural changes
Architecture models, views, presentations, and analyses all help to bridge the ‘communication gap’ between architects and stakeholders

17. The Architecture Process
Architecture is a process as well as a product
The architecture description life cycle.

18. Drivers for Enterprise Architecture

19. Enterprise architecture as a management instrument.
Why does it exist?
Image of the future?
Enterprise architecture as a management instrument.
Route to achieve the mission & Vision
Translated into
Concrete goals
Soft part
Enterprise architecture as a management instrument.
What is happening inside Enterprise ??

20. Enterprise architecture as a management instrument.
Why does it exist?
Image of the future?
Route to achieve the mission & Vision
Enterprise architecture as a management instrument.
Translated into
Concrete goals
Soft part
Enterprise architecture as a management instrument.
Should this be static?

21. Drivers for Enterprise Architecture
Example of External Drivers : The Government Act & for enforcing IT infrastructure.

23. Management Areas relevant
BSC
EFQM
Quality management
COBIT
ITIL
CMM & CMMI

24. Treatment of Enterprise Architecture with some well-known management
strategic management: the Balanced Scorecard;
strategy execution: EFQM;
quality management: ISO 9001;
IT governance: COBIT;
IT delivery and support: ITI;
IT implementation: CMM and CMMI.

25. 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.

26. 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.

27. 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.

28. 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.

29. 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.

30. 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.

31. Quality management and software development

32. Process and product quality
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.

33. 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.

34. The process improvement cycle

35. Process improvement stages
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.

36. Process and product quality
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.

37. Process-based quality

38. Principal product quality factors

39. 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.

40. IT implementation: CMM and CMMI
The Capability Maturity Model for Software (Paulk et al. 1993), also known as the CMM and SW-CMM, is a model for judging the maturity of an organization's software engineering processes, and provides organizations with key practices required to help them increase the maturity of these processes.

41. 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.

42. 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.

43. 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

44. CMMI Model Representations

45. 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.

46. The Maturity Levels Optimizing 5 Quantitatively Managed 4 Defined 3 21 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

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

48. Model Components Process Areas (PA) Specific Goals (SG) Required
Specific Practices (SP) Expected
Typical Work Products Informative
Sub-practices Informative
Notes Informative
Discipline Amplifications Informative
References Informative
Generic Goals (GG) Required
Generic Practices (GP) Expected
Generic Practice Elaborations Informative

49. Continuous Representation: Organization of Process Areas
Category
Process Area
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
Project
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
Requirements Management
Requirements Development
Technical Solution
Product Integration
Verification
Validation
Engineering
Organizational Process Focus
Organizational Process Definition
Organizational Training
Organizational Process Performance
Organizational Innovation and Deployment
Process
Management

50. Process Areas Organized by Category
Process Management
Organizational Process Focus
Organizational Process Definition
Organizational Training
Organizational Process Performance
Organizational Innovation and Deployment
empower
analyze
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
standardize
processes
Support
Configuration Management
Process and Product Quality Assurance
Measurement and Analysis
Organizational Environment for Integration*
Decision Analysis and Resolution
Causal Analysis and Resolution
analyze
Engineering
Requirements Development
Requirements Management
Technical Solution
Product Integration
Verification
Validation
employ
measure & assist

51. 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.

52. This will lead us into
Methods & Frameworks

53. Thank You