Enterprise

IT strategy and architecture

Introduction

Aare Lapõnin

27.04.2006

The scope

• Questions:

– Who is deciding what programmer is going to do?

– How it is being decided?

Context

Software industry today

• Software expresses and represents an information-based business process, along with a human organisation and its participants.

• Most of the desirable properties that make software successful are not a result of technical prowess but a deep understanding of what the users need.

• Good software cannot be created without a strong connection to all stakeholders, which includes not only users but also managers, administrators, operators, and others.

Extracts from “Software ecosystem”

David G. Messerschmitt and Clemens Szyperski

2003 Massachusetts Institute of Technology

Related labour market

• Major part of the salary fund for developers is paid by the person with following profile:

– Big enough organisation

• at least more than 150 employees

• In Europe it more like more than 1000

– IT is supporting actively business-critical processes

– Industries:

• Financial sector

• Telecommunication

• Public sector (central, regional, local)

• Logistic

• etc.

Market share, 2004

Business needs in IT context

• Increase revenues

• Decrease internal costs (and thus profitability)

• Improve quality of services (retain customers)

Problems

• Competitors make better

• You have far less resources then you need

• You have a lot of old and inefficient systems – (Cobol, business rules from 70-ies)

• Systems are far too complex– Real life example: you new field to the Loan application and your

ATM are out of work for half a hour

• ROI is very small– Tens of people analyse something during two years and nobody

knows would it be useful

Enterprise IT

Simplified IT service life-cycle

IT service and Customer

Typical simplified IT organisation

Typical simplified IT process model

IT development processes

IT operations processes

How to keep all those things

together?

We need IT strategy!

IT strategy development project

We need to have Enterprise IT Architecture!

What is IT architecture?

• Formal definition

– Architecture is

• a fundamental organization of a system embodied in

– its components, their relationships to each other, and

– to the environment, and

– the principles guiding its design and evolution.

• provides the necessary technical foundation for an effective IT strategy, which is the core of any successful modern business

strategy.

• defines the components or building blocks that make up the overall information system.

Enterprise Architecture is About Integrating Business and IT Planning

Processes

EA as planning process

Why IT architecture?

• IT architecture enables to achieve the right balance between IT efficiency and innovation of different units

• It enables managed innovation within the enterprise:

– Individual units can innovate and develop IT systems safely in order

to improve efficiency of processes.

– At the same time, the needs for an integrated IT strategy are

assured, permitting the closest possible synergy across the overall

organisational domain.

• IT architecture itself is a complex set of guidelines for IT development and operations.

IEEE Std 1471-2000

Architecture description (AD)

• AD is a formal description of an information system, organized in a way that supports reasoning about the structural properties of the system.

• It defines the components or building blocks that make up the overall information system, and

• provides a plan from which products can be procured, and systems developed, that will work together to implement the overall system.

Stakeholder

• System stakeholder is an individual, team, or organization (or classes thereof) with interests in, or concerns relative to, a system.

• Each stakeholder typically has interests in, or concerns relative to, that system.

• Concerns are:

– those interests which pertain to the system’s development, its

operation or any other aspects that are critical to stakeholders

– include system considerations such as performance, reliability,

security, distribution etc.

AD view

• View is a representation of a whole system from the perspective of a related set of concerns.

• Each view addresses one or more of the concerns of the system stakeholders.

• The term view is used to refer to the expression of a system’s architecture with respect to a particular viewpoint.

Viewpoint is :

• a specification of the conventions for constructing and using a view

• It is a pattern or template from which to develop individual views by establishing the purposes and audience for a view and the techniques for its creation and analysis.

Examples of concerns

IT operation

• Lower software development, support, and maintenance costs

• More application portability

• Improved interoperability and easier system and network management

• Better ability to address critical enterprise-wide issues, such as security

• Easier upgrade and exchange of system components

• Reduced complexity in IT infrastructure

• Managed process to make buy or out-source IT solutions

IT development

• Systematized top-down approach for data processing development can bring better data quality through streamlining data capture processes and semantic compatibility

• Managed process of prioritisation of IT development initiatives can assure better alignment of IT initiatives with the Ministry overall strategy

• Buying decisions are simpler, because the information governing procurement is readily available in a coherent plan

• Top-down approach for planning of functionality of the information systems can bring possibility to reuse implementation software components

How we can prepare a Good

Enterprise IT Architecture?

Positioning

• Software engineers do not like IT architecture management

• Architecture management is not part of software engineering (it is not just design, it not just requirements management)

• Architecture management is addressing long-term objectives

• IEEE standard IEEE Std 1471-2000 as a conceptual baseline for development of architectural view and models

• Unified Modelling Language (UML) for modelling and description of different architectural views

Enterprise architecture generic

classification

e.g. DATA

ENTERPRISE ARCHITECTURE - A FRAMEWORK

Builder

SCOPE(CONTEXTUAL)

MODEL(CONCEPTUAL)

ENTERPRISE

Designer

SYSTEM

MODEL(LOGICAL)

TECHNOLOGY

MODEL(PHYSICAL)

DETAILEDREPRESEN- TATIONS(OUT-OF- CONTEXT)

Sub-

Contractor

FUNCTIONING

ENTERPRISE

DATA FUNCTION NETWORK

e.g. Data Definition

Ent = FieldReln = Address

e.g. Physical Data Model

Ent = Segment/Table/etc.

Reln = Pointer/Key/etc.

e.g. Logical Data Model

Ent = Data Entity

Reln = Data Relationship

e.g. Semantic Model

Ent = Business Entity

Reln = Business Relationship

List of Things Important

to the Business

ENTITY = Class ofBusiness Thing

List of Processes the

Business Performs

Function = Class of

Business Process

e.g. Application Architecture

I/O = User ViewsProc .= Application Function

e.g. System Design

I/O = Data Elements/Sets

Proc.= Computer Function

e.g. Program

I/O = Control BlockProc.= Language Stmt

e.g. FUNCTION

e.g. Business Process Model

Proc. = Business Process

I/O = Business Resources

List of Locations in which the Business Operates

Node = Major BusinessLocation

e.g. Business Logistics System

Node = Business Location

Link = Business Linkage

e.g. Distributed System

Node = I/S Function(Processor, Storage, etc)Link = Line Characteristics

e.g. Technology Architecture

Node = Hardware/SystemSoftware

Link = Line Specifications

e.g. Network Architecture

Node = AddressesLink = Protocols

e.g. NETWORK

Architecture

Planner

Owner

Builder

ENTERPRISEMODEL

(CONCEPTUAL)

Designer

SYSTEMMODEL

(LOGICAL)

TECHNOLOGYMODEL

(PHYSICAL)

DETAILEDREPRESEN-

TATIONS (OUT-OF

CONTEXT)

Sub-Contractor

FUNCTIONING

MOTIVATIONTIMEPEOPLE

e.g. Rule Specification

End = Sub-condition

Means = Step

e.g. Rule Design

End = Condition

Means = Action

e.g., Business Rule Model

End = Structural AssertionMeans =Action Assertion

End = Business Objective

Means = Business Strategy

List of Business Goals/Strat

Ends/Means=Major Bus. Goal/Critical Success Factor

List of Events Significant

Time = Major Business Event

e.g. Processing Structure

Cycle = Processing CycleTime = System Event

e.g. Control Structure

Cycle = Component Cycle

Time = Execute

e.g. Timing Definition

Cycle = Machine CycleTime = Interrupt

e.g. SCHEDULE

e.g. Master Schedule

Time = Business Event

Cycle = Business Cycle

List of Organizations

People = Major Organizations

e.g. Work Flow Model

People = Organization Unit

Work = Work Product

e.g. Human Interface

People = Role

Work = Deliverable

e.g. Presentation Architecture

People = User

Work = Screen Format

e.g. Security Architecture

People = IdentityWork = Job

e.g. ORGANIZATION

Planner

Owner

to the BusinessImportant to the Business

What How Where Who When Why

John A. Zachman, Zachman International (810) 231-0531

SCOPE(CONTEXTUAL)

Architecture

e.g. STRATEGYENTERPRISE

e.g. Business Plan

TM

Models

• No perfect models – should be just Good Enough

• Requirements: Validity-Consistency-Correctness

• Guidelines:

– Model purposefully

– Address and audience

– Abstract carefully

– Descriptive names

– Define terms

– Simplicity

– Validate models

– Keep models Alive

Example of viewpoint definition

The Information Viewpoint

• Definition: describes the way that the architecture stores, manipulates, manages, and distributes information

• Concern:

– Information structure and content

– Information flow

– Data ownership

– Timeliness, latency and age

– References and mappings

– Transaction management and recovery

– Data quality

– Data volumes

– Archives and data retention

The Information Viewpoint (2)

• Models:

– Static data structure models

– Information flow models

– Information lifecycle models

– Data quality analysis

– Metadata models

• Problems

– Data incompatibility

– Poor data quality

– Unavoidable multiply updaters

– Key matching deficiencies

– Interface complexity etc.

The Information Viewpoint (3)

• Stakeholders

– Primarily users, acquirers, developers and maintainers

• Applicability

– Any system that has more than trivial information management

needs

Typical catalogue of viewpoints

• Functional view

• Information view

• Concurrency view

• Development view

• Deployment view

• Operational view

Important perspectives

• Security

• Performance

• Availability

• Usability

• Regulations (compliance)

Architect responsibilities

• ensure that the scope, context, and constraints are documented and accepted by key stakeholders;

• identify and engage stakeholders;

• facilitate the making of system-level decisions;

• capture and interpret input from technical and business domain specialist;

• define and document the system structure and form;

• define and document strategies, standards, and guidelines to direct the build and deployment of the system;

• ensure that the architecture meets the system quality attributes (and document those attributes into quality perspectives);

• ensure that AD is applied into products;

Urbanisation paradigm

• Exchange zone – means through what all different users communicate with an information

system

• Operations zone – implementation of all important of the organisation automated business

processes; this is the place where to locate workflows of processes and related to that business rules.

• Data silo – all important data assets of the information system which are visible for

users.

• Reference zone – the data what are used to assure interoperability within the system between

different part as well as between the system and external to that systems

• Decision support zone – support for decision-making processes through analysis and related

reporting

• Resource zone – internal resources management applications, like HR management,

General Ledger etc.

As result you should have

• Roadmap:– better support for the business units

– decrease TCO of the information system

• Guidelines:– What to develop

– How to develop

– When to develop

• Tool to keep consistency within federated development

• Common understanding between Business, ITO and ITD

Resources

• USA CIO office has the practical guide to the architecture:

– http://www.cio.gov/archive/bpeaguide.pdf

• USA CIO office documents regarding the architecturedevelopment:

– http://www.cio.gov/index.cfm?function=showdocs&category=Archite

cture

• Vendor of the Enterprise Architect:

– www.sparxsystems.com

Thank you!