Lecture 1: INF 411Information Engineering Enterprise Architecture

Dr. Taysir Hassan Abdel Hamid Associate Professor,

Information Systems Department, Faculty of Computers & Information

Assiut University October 5, 2015

Course Outline

• Introduction to Information Engineering• Enterprise Architecture • Business Process Management • Ontologies

Book Used

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

Grading Scheme

• Final Exam: 70 points• Year Work: 30 points (Midterm Exam: 10,

Assignments & Discussions: 20)

Enterprise????

• The term enterprise is used because it is generally applicable in many circumstances, including:

1. Public or private sector organizations2. An entire business or corporation3. A part of a larger enterprise (such as a business unit)4. A conglomerate of several organizations, such as a

joint venture or partnership5. A multiply outsourced business operation6. Many collaborating public and/or private organizations

in multiple countries

• The term enterprise includes the whole complex, socio-technical system,[5] including:

1.people2.information3.technology4.business (e.g. operations)

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:

Examples in Egypt

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

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.

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

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

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.

• 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 aprecise meaning.

• Different fields speak their own languages, draw theirown models, and use their own techniques and tools

• This places a high demand for QUALITY on the architecture.

• QUALITY means that the architecture actually helps in achieving essential businessobjectives.

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

The Architecture Process

Architecture is a process as well as a product

The architecture description life cycle.

Drivers for Enterprise Architecture

• Enterprise architecture as a management instrument.

Enterprise architecture as a management instrument.

Why does it exist?

Image of the future?

Route to achieve the mission & Vision

Translated into Concrete goals

Soft part

What is happening inside Enterprise ??

• Enterprise architecture as a management instrument.

Enterprise architecture as a management instrument.

Why does it exist?

Image of the future?

Route to achieve the mission & Vision

Translated into Concrete goals

Soft part

Drivers for Enterprise Architecture

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

Management Areas relevant

• BSC• EFQM• Quality management • COBIT• ITIL• CMM & CMMI

Treatment of Enterprise Architecture with some well-

known management 1. strategic management: the Balanced

Scorecard;2. strategy execution: EFQM;3. quality management: ISO 9001;4. IT governance: COBIT;5. IT delivery and support: ITI;6. IT implementation: CMM and CMMI.

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.

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

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.

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.

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.

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 and software development

Software developmentprocess

Quality managementprocess

D1 D2 D3 D4 D5

Standards andprocedures

Qualityplan

Quality review reports

• 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

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.

The process improvement cycle

Analyse

Measure

Change

• 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

• 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

Process-based quality

Define processDevelopproduct

Assess productquality

Standardiseprocess

Improveprocess

QualityOK

No Yes

Principal product quality factors

Productquality

Developmenttechnology

Cost, time andschedule

Processquality

Peoplequality

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.

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.

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.

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.

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

CMMI Model Representations

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.

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 measuredand controlled

Focus on continuous process improvement

Optimizing

QuantitativelyManaged

Defined

Initial

Managed

Optimizing

Defined

The Capability Levels

5 Optimizing

4 Quantitatively Managed

3 Defined

2 Managed

1 Performed

0 Incomplete

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

Requirements ManagementRequirements DevelopmentTechnical SolutionProduct IntegrationVerificationValidation

Engineering

ProjectManagement

Project PlanningProject Monitoring and ControlSupplier Agreement ManagementIntegrated Project Management(IPPD)Integrated Supplier Management (SS)Integrated Teaming (IPPD)Risk ManagementQuantitative Project Management

Organizational Process FocusOrganizational Process DefinitionOrganizational TrainingOrganizational Process PerformanceOrganizational Innovation and Deployment

ProcessManagement

Configuration ManagementProcess and Product Quality AssuranceMeasurement and AnalysisCausal Analysis and ResolutionDecision Analysis and ResolutionOrganizational Environment for Integration (IPPD)

Support

Continuous Representation: Organization of Process Areas

Category Process Area

Process Areas Organized by Category

Process Management

Organizational Process FocusOrganizational Process Definition

Organizational TrainingOrganizational Process Performance

Organizational Innovation and Deployment

Project Management

Project PlanningProject Monitoring and Control

Supplier Agreement ManagementIntegrated Project Management (for IPPD*)

Risk ManagementIntegrated Teaming

Integrated Supplier Management**Quantitative Project Management

Engineering

Requirements DevelopmentRequirements Management

Technical SolutionProduct Integration

VerificationValidation

Support

Configuration ManagementProcess and Product Quality Assurance

Measurement and AnalysisOrganizational Environment for Integration*

Decision Analysis and ResolutionCausal Analysis and Resolution

analyze

empower analyze

employ measure & assist

standardizeprocesses

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.

Thank You