Download File

sunfloweremryologistData Management

Oct 31, 2013 (3 years and 11 months ago)

86 views

Session 2

Enterprise Architecture



On the whole


well done



Strong emphasis on IT




Feedback


Is not to turn you into enterprise
ar
chitects


The field is enormous and the techniques can get quite complex


There are “languages” that need to be learnt, such as UML and ERDs
(
more on this later
)


To be
recognised

as an architect you have to complete courses and pass
exams


At best I would hope that you become

familiar with the
concepts and understand the role of EA within the
organisation


Perhaps at work you’ll
even be able to say something like
“…shouldn’t we be thinking of some form of EA? The
benefits could be…”

and really impress the CEO

Purpose of today’s session


With no architectural plans


With only general sketches as to how its
supposed to look, or with only detailed
diagrams for the plumbing and wiring


With each sub
-
contractor doing whatever
he/she feels like doing


Where the whole house has to be torn down in
order to remodel one room

Imagine building a house …

You may just get

Or …

It is often the case that:



there is no considered corporate strategy


there is no considered IT strategy


no thought has been given to business models


business processes are not aligned to the corporate strategy



names and addresses are stored in more than one place?


systems from different suppliers don’t talk to each other?


different operating platforms or versions of operating systems are
installed on a company’s PCs?


different standards exist to interface with a range of back and front
office systems?

Status quo

The consequences of these simple examples are
significant


systems do not deliver against the strategy


systems do not communicate with each other


multiple skill sets are required to manage the
problems


maintenance of the data is a huge problem


it is
rarely in sync


drain on resources which means that other,
important things don’t get done


and much more …


Consequences …

An Enterprise Architecture (EA) is a
[conceptual]
blueprint

that defines the function,
structure and operation of an organization.


It establishes
order
,
structure

and
standards
,
which if adhered to can greatly enhance the
efficacy of an organization.

Definition

Think large
organisations
. Think of these examples:


Hardware

: mainframes, mini computers, PCs, Apple


Operating systems
: mainframe, mini, Windows, Linux, IOS


Development environment
:
Druple
, Python, Ruby, Visual
Studio,
.Net
, VB, C#, Java, HTML 5, ….


Programs and versions
: Office 97, 2003, 2007, 2010, 2013


Databases

: Oracle, SQL,
MySQL
,
ProgreSQL
, IBM DB2, …


Interfaces :
User, APIs, protocols

Standards

GOVERNANCE

ENTERPRISE
ARCHITECTURE

The chicken and the egg

GOVERNANCE

Structure

Risk

Standards

Business processes
-

rationalized

Procurement


Disparate,

non integrated, systems:


Compartmentalize knowledge


Think of key spread
-
sheets that are “privately” owned


Are prone to error


we expect rigorous testing of
our IT systems


what about financial
spreadsheets?


Result in duplication of effort


What happens when the owner leaves?

Knowledge must be institutionalized

Michael Platt (Microsoft) suggests an EA contains four views:


business

perspective defines the processes and standards by
which the business operates on a day
-
to
-
day basis.


application

perspective defines the interactions among the
processes and standards.


information

perspective defines and classifies the
organization’s raw data (such as document files, databases,
images, presentations, and spreadsheets).


technology

perspective defines the hardware, operating systems,
programming, and networking solutions used by the
organization.

Simple perspective

We have seen that EA, according to Michael Platt, contains four
views


business, application, information, technology.


Who should own the process & what are the implications?


business?


IT?


governance?


if none of the above, then who?



Who owns the process?

There are a number of formal EA models, including inter alia:


ZIFA

(
Zachman

Institute Architecture Framework
-

http://www.zifa.com
)


TOGAF

(The Open Group Architecture Framework
-

http://www.togaf.com
)


PEAF

(Pragmatic Enterprise Architecture Framework
-

http://www.pragmaticea.com
)


GWEA

(Government Wide Enterprise Architecture
-

http://opengroup.co.za/overview
-
gwea
-
framework

-

TOGAF® 9
)



… and many more

Formal models


There are differences in emphasis and focus


e.g. IT versus business architecture.


Each framework has its proponents and
detractors.


They all attempt to present an organizational
blueprint.

Differences

In most instances, the EA involves mapping the “as
-
is” and “target“ systems

TARGET

AS
-

IS

Enterprise Architecture

By doing this, the gaps become obvious !

GAPS

From here to there

WHAT

HOW

WHERE

WHO

WHEN

WHY

List of things

Important to the

business

List of processes
the business
performs

PLANNER

List of locations
in which the
business
operates

List of
organizations &
roles important
to the business

List of
events/cycles
important to the
business

List of business
goals and
strategies

SCOPE &

VISION

Entity
relationship
model

Business

process

model

OWNER

Business

logistics

System /
locations model

Organizational
unit & role
relationship
model

Event model

Business

Plan / goal
relationship
model

BUSINESS
MODEL

Logical data

model diagram

Process diagram

Distributed

system

architecture /
location diagram

Role relationship
diagram

Event diagram

Business

Rule

Model / diagram

SYSTEM

MODEL

(LOGICAL)

DESIGNER

Physical

data

model

System

design / function
specification

BUILDER

Location /
network
specification

Role
specification

Event

specification

Rule

design

TECHNOLOGY

MODEL

(PHYSICAL)

Data

definition

Program /
process
definition

SUB
-
CONTRACTOR

Network

Architecture /
location details

Role

definition

Timing / event

definition

Rule

definition

DETAILED

REP
-
RESENTATION

DATA

FUNCTION

NETWORK

PEOPLE

TIME

MOTIVATION

FUNCTIONING

ENTERPRISE

FUNCTIONING

ENTERPRISE

A taxonomy rather than a framework


describes the artifacts, not the process

TOOLS

Zachman

Framework

business model

business processes

agnostic

detailed

Zachman

Framework
(another view)

Five ways in which the
Zachman

grid can help in the
development of an EA
-

it can help:


ensure that every stakeholder's perspective has been
considered for every descriptive focal point


improve the information by sharpening each focus
points to one particular concern for one particular
audience


ensure that all of the business requirements can be
traced down to some technical implementation


convince stakeholders at the upper levels that the
technical team isn't planning on building a bunch of
useless functionality


convince the technical team that business is including
IT in its planning.


Roger Sessions

How can
Zachman

help?


Business architecture
-

describes the processes the business uses
to meet its goals


Application architecture
-

describes how applications are
designed and how they interact with each other


Data architecture
-

describes how the data stores are organized
and accessed


Technical architecture
-

describes the hardware and software
infrastructure that supports applications and their interactions






Roger Sessions

Is about

Process !

TOGAF
(in a nutshell)

Zachman

tells you how to categorize your artifacts




TOGAF gives you a process for creating them



They complement each other !

“Architecture is a verb, not a noun


… it is the ongoing process of creating, maintaining, and, especially, leveraging an enterprise

architecture that gives an enterprise architecture its vitality


“An architecture that is just a bunch of stiff artifacts that sit in a corner gathering dust is

useless, regardless of how sophisticated your taxonomy is for categorizing those artifacts or

how brilliant your process is that guided their development


“Gartner believes that enterprise architecture is about bringing together three constituents:

business owners, information specialists, the technology implementers. If you can bring
these three groups together and unify them behind a common vision that drives business
value, you have succeeded



“Success is measured in pragmatic terms, such as driving profitability, not by checking off
items on a process matrix.


Gartner

Reference:
http://www.ibm.com/developerworks/webservices/library/ws
-
soa
-
enterprise2/

An IBM perspective


Large organizations tend to be complex entities, and
producing a comprehensive EA can be a daunting and
expensive task.


The more complex the EA, the greater chance it will:


Be ignored


Not be updated on an ongoing basis


Producing and EA is not a once
-
off task. It requires an
ongoing commitment and has to be kept up to date. The
minute it falls behind, it becomes worthless.

So, where’s the problem?

Is to develop a manageable and “agile” EA that
can be used as a reference and that can be easily
kept up to date.


This is a big challenge


the literature suggests
that the agile architectures are not significantly
simpler that the bigger, more complex ones.

The challenge …

Now perhaps at work you’ll even be able to say something like:



“ Shouldn’t we be thinking of implementing some form of EA? Some of the obvious
benefits to the organisation could be:


a realignment of business models and processes to
support

our corporate
strategy


a better
alignment of business and IT


improved
governance


a set of
standards

for users, APIs and data communication between applications


reduced IT costs
because we can


standardise our hardware, operating systems and software


reduce the skill
-
set needed to develop, implement and maintain our
systems


reduce our training costs because everyone would be running the same
software on the same platforms


reduce the duplication of effort because we will have rationalised our
business processes and will be able to reuse the algorithms better ”

… then casually turn on your heel and leave the now
-
deathly
-
silent room

… and that’s it for today

UML Use Case diagrams

Use Case

Association

Actor

NEXT

UML = Unified Modeling Language

UML Activity diagram

Activity

Final node

Initial node

Flow

Fork

Join

Condition

Decision

Merge

NEXT

Entity Relationship Diagram (ERD)

at least zero



Name

Address

Student_Number

Email_Address

Cell_Number

Date_of_Birth

STUDENT



Name

Address

Telephone_Number




SCHOOL

Each school enrolls

and
at most many

students

at least one

Each student attends

and
at most one

school

NEXT

Simple ERD

BACK