The Role of a Systems

Architect

Paul Booth, Senior Consultant

IT Architecture & Strategy
paul_booth@uk.ibm.com
01256 344774
What is a Systems
Architect?
 The holistic approach
End-to-end (holistic)
Viability - Non-functional Requirements
Performance (response times, etc.)
Availability (# breaks per year, etc.)
Operability / Systems Management
Security
Etc.
Requirements-driven
Requirements Analysis
End-to-End Systems
Architecture
Structured Method
Global Services Method
Enterprise Architecture Method
End-to-End Design Method
SMFD (Systems Management)
Availability Method
Performance Engineering method
The T-shaped skills profile

Breadth of understanding & skill across IT

Depth of
technical
expertise
 Enterprise Architecture (EA) relative to
End-to-End Systems Architecture (E2E)

Enterprise
Strategy
Data Process
IT Strategy
Architecture Architecture

Enterprise Architecture EA

2E 2E 2E 2E
E E E E
Current ABC DEF GHI
etc..
Systems system system system
An Enterprise Architecture (EA) is much like a city plan in that it defines an
infrastructure that will meet the current and future needs of a diverse user
population and will adapt to changing business requirements and technology.

Architecture Components Usage City Planning Analogy

Vision 
Strategy for I/T use across 
City vision based on anticipated needs of
the enterprise residents
Principles 
Guidance for investment and 
Zoning and building codes to ensure
design decisions quality & consistency in construction
Models 
Overall context and views for 
Maps and diagrams for infrastructure
systems and users systems like water, sewer & electric
Arch. Building Blocks 
Standard Components for 
Prefabricated building component
high level design specifications for off-site construction
Criteria 
Considerations for standards 
Considerations for component selection
and product selection such as durability, cost, etc.
Standards Guidelines to which systems
 
Electrical wiring and plumbing standards
must conform
Arch. Mgmt. Process 
Process to allow additions & 
Process to change the city plan and allow
variances to Architecture for variances
Transition Initiatives & 
Prioritized infrastructure 
City improvement plan
Plan projects & costs
 Dealing with Fuzzy problems

The Systems
Architect

Management:
"I know I have a Problem
Qualify the situation
problem - it's Analyse background & context Statement or
impacting my Define problem Analysis
business. But
technically I don't
really know where to
begin."

Recommend and plan project to handle problem

Resource team with appropriate skills Solution
Carry out research Recommendations
Make recommendations
 Systems Architecture situations (1)

The client has.. The client needs.. System Architect.. System Architect produces..

Defines problem Problem Analysis Report

A solution
IT-related problem Recommends actions Problem Recommendations

Analyses & completes

Business requirements
Outline of system Requirements Analysis
requirements Creates first-cut IT
solution & its System Feasibility Report
(possibly solution
feasibility System Proposal
incomplete) Reviews technical
feasibility

Establishes business &

Existing
technical context
infrastructure Technical direction Technical Strategy Report
Creates a
needs evolution
recommended strategy
 Systems Architecture situations (2)

The client has.. The client needs.. System Architect.. System Architect produces..

Fundamental change
or increase in scale New technical Uses structured approach toEnterprise Technical Architecture
to existing architecture or system create an architecture or Report,
infrastructure model design Technical Infrastructure Design
coming up

Project with many

disparate elements, Uses structured method to Technical Audit Report,
or application but not Overall system design review design elements and System Architecture Report,
technical create cohesive design Technical Infrastructure Design
infrastructure

Reviews technical design in

Technical Audit / Assurance
Project under way or Assurance of technical structured way.
Report,
in plan viability Creates systems
System or Technical Architecture
architecture if necessary.
 Systems Architecture situations (3)

The client has..

The client needs.. System Architect.. System Architect produces..

Establishes where in end-to-

Under-performing Performance Analysis,
Recommended way end system the problem
system (availability Availability Analysis,
forward lies.
or response) Scalability Analysis
Recommends actions.

To know what tasks Works with PM to create Work Breakdown Structure,

Project starting
required, in what order work breakdown structure Plan
Benefits to the client


IT 
Business

Raises technical integrity of 
Spur to creativity,
solution (i.e. it works better innovation
& offers better service to 
Reduces & manages risk
business) 
Lowers cost and raises

Increases flexibility, quality overall
scalability, adaptability 
Ties IT actions more
(etc., etc.) of system closely to business

Positions IT better for
business change
What skills do you need to
do this?
Understand the business requirements


What does the business need?

What business processes will be
supported?

What system components are needed to
do this?

Where are the business rules?

Who are the key users?

Who is really behind this?
Understand the technology


Disk (local, shared, NAS, SAN...)

Windows, Unix, Linux, Solaris, z/OS,
OS/400, ...

DB2, Oracle, SQL Server...

Java, ActiveX

LANs, WANs, Routers, Firewalls

RSA, SSL, Intrusion Detection

-business
 The data


Underlying data structures CLTROLE COMPANY CLTDET


Tailored data groups
NAME CLTLOG

Business Manager Tables

Referential Integrity
FONREF CLIENT CLTTH

Interfacing requirements

MIS requirements
ADDRREF CLIENTAS

Imaging
BILACT
ADDRESS
POLICY

CLTACT CLTREF CLAIM

PAYMNT
Architectural Alternatives


Client/Server or Web-
model

Operational or
Informational

Flexibility vs.
Performance
Performance


MVS tuning

CICS tuning

DB2 tuning

Efficient SQL

Diagnostic tools:

STROBE

DB2PM

EPDM

OMEGAMON
The operational environment


The overnight schedule

The data centre view of life

Interfacing requirements

Disaster recovery
Human factors


Business scripts

Dialog structure

Number of screens

Layout of screens

Drag and Drop

CUA look and feel

Sequence of fields

Use of help

Menemonics
The development process


Overall Development
approach

Tools

Library management

Debuggers

Table data vs. code

Standards and Guidelines

Work activities
Management systems


Risk management

Project deliverables

Escalation procedures

Roles and Responsibilities

Right of Veto

Sign-off criteria
Testing

DEVELOPMENT

What to test
UNIT TEST

Types of test
INTEGRATION TEST

Entry criteria
SYSTEM TEST

Exit criteria
SINGLE THREAD

When to stop testing
VOLUME
STRES
SACCEPTANCE
The Compleat architect


A brain the size of a planet

Eyes in the back of the head

The memory of an elephant

The armament of a tank

The creativity of Salvador Dali

An understanding spouse
Questions ?