Enterprise wide focusProject focus

(1)

Modeling in IBM

A practitioners view

Ole Rasmussen ora@dk.ibm.com +45 2880 9572

Ole Rasmussen, Senior IT Architect, IBM Global Business Services

11. May 2010

(2)

Modeling @ IBM – presentation at DTU, Denmark –

In our model based development approach we have been trying to combine analysis, design and construction (to a very[?] far extend)

Project Definition

Analysis

Design

Construction

Test Maintenance

Production

“Our” model driven approach

Project Definition

Modelling

Construction

Test Maintenance

Production Design

Analysis

(3)

My world (most of it) is the basis for analysis, design and construction – IT architecture

Project Definition

Modelling

Construction

Test Maintenance

Production Design

Analysis

(4)

What is your definition of IT architecture?

What is the difference between architecture and design?

Why is IT architecture important and why do projects need it?

What is the role of the IT Architect?

What diagrams and models do you currently use to represent architectures?

Preamble

(5)

Introduction

What is architecture?

Requirements aspect Functional aspect Operational aspect Using patterns Validation aspect

Architect career in IBM Closing

Introduction

What is architecture?

Requirements aspect Functional aspect Operational aspect Using patterns Validation aspect

Architect career in IBM Closing

Agenda

(6)

My IBM Career

97-99: Developer – Lufthavne – TKE

98-…: Method Consultant

99-00: ”Architect” - e-Commerce – Several proposals

– ToyCity, GiftAhoy

98-…: Teacher – SI-/ GSMethod – OTU2

– Commerce Suite – Component Modeling – Architectural Thinking – SOA Bootcamp

– SOMA Workshop

01-..: Architect – 4PL vision

– eCommerce at major shipping firm – Telco Service Platform

– VIRK

– Banking SOA Method Framework – Review: IKEA, MSL, PFA, YouSee,

many IBM TDA’s, …

– Proposal and pre-sale: Skat, Domstolsstyrelsen, TDC …

– Leader of Nordic SOA Center of Excellence – Service delivery for Novartis

– Application strategy @ Ministry of Finance – Several large proposals

– Currently: Large complex system integration project at central government agency

03/12: Certified IT Architect – Application Architecture

– Started the formal process in December 2002!

– Submitted package ultimo Oktober 2003 – Recertified in 2006 and 2009

Introduction

(7)

What we deliver in my part of IBM (the “services” part) – an where I usually fit in…

Application Maintenance Application

Build Application

Design

Ongoing Business

Run Business

Transformation Delivery Business

Transformation Design

Infrastructure Run Infrastructure

Build Infrastructure

Design Proposal

And Contract Negotiation

Notice the gaps...

Introduction

(8)

Introduction

What is architecture?

Requirements aspect Functional aspect Operational aspect Using patterns Validation aspect

Architect career in IBM Closing

Agenda

(9)

”a shift toward integrated solutions and quantifiable business value”

mandates for business and IT alignment – Enterprise Architecture is key (but that is not my story today)

Business Strategy

Information Technology Strategy Business

Opportunity

Technology Availability

Business Architecture

IT Architecture - Processes

- Information - People - Locations

- Applications - Data - Technology

Planning

Design and Delivery

E n te rp ri s e w id e f o c u s c t fo c u s

Strategy

Business Operating Environment and IT Infrastructure

Enterprise Architecture

Transition Plan

Enterprise Architecture

“the city plan”

System Architecture

• functional aspects Strategy and vision

“Which city do we want to build?”

The Gap

The Great Divide

What is architecture?

(10)

Architecture defined

Definition: The architecture of an IT system is the structure or structures of the system, which comprise software and hardware elements, the externally manifested properties of those

elements, and the relationships among them.

(I’m not considering “Enterprise Architecture”)

(11)

Architecture versus design

System Architecture is about creating the logical and physical level, technology independent and dependent structures that define the major static and dynamic elements of a solution using guidelines that influence their

development. It sets the context for

Solution Design.

System Design is about creating the internal

behavior of the structural elements plus additional detail towards realizing the

(12)

Some popular misconceptions about architecture…

• Architecture is just paper

• Architecture and design are the same things

• Architecture and infrastructure are the same things

• <my favorite technology> is the architecture

• A good architecture is the work of a single architect

• Architecture is simply structure

• Architecture can be represented in a single blueprint

• System architecture precedes software architecture

• Architecture cannot be measured or validated

• Architecture is a science

• Architecture is an art

(13)

Architect defined

Definition: The IT Architect defines (architects) solutions to business problems through the

reasoned application of information technology.

Those solutions are manifested as

architectures and can include systems, applications and process components.

(14)

What do these definitions mean in practical terms?

An IT Architect should be:

• A practitioner

• A consensus builder

• Results-oriented

• A generalist

An IT Architect should not be:

• A “top-level” software designer

• The project manager

• A technology expert

• A product expert

• A lone scientist

(15)

Architectural Thinking involves inputs, process, and outputs

Analyzing the requirements (and resolving conflicts between them)

Applying principles (possibly defined at the Enterprise Architecture level)

(16)

Architectural Thinking involves analyzing requirements by addressing a number of concerns

(17)

Architectural Thinking involves creating views to satisfy the concerns of different stakeholders

(18)

Our method (“Unified Method Framework”) is the “repository” of best practice and experience representing a number of “basic” and

“cross-cutting” viewpoints.

(19)

The dimensions of architecture

(20)

The System Description Standard (SDS) describes the fundamental concepts that can be used to describe systems

(21)

The System Description Standard (SDS) provides a standard language with the functional and operational aspects being very important

Functional Aspect

IT Component: A modular unit of IT functionality, which makes this functionality available through an interface

Interface: A set of operations offered by a component

Collaboration: Captures the exchange of messages between components in the context of a particular scenario

Interaction: The messages exchanged between one or two components in the context of a collaboration, and the sequencing of these messages via their associated send/receive events

Operational Aspect

IT Node: A collection of hardware and software components fulfilling a specific responsibility with a certain quality of service within the overall system

Connection: The required connectivity between IT nodes

Deployment Unit: An abstraction of an IT component created to simplify the placement process

Location: A geographical area or position Software

Architecture?

(22)

Introduction

What is architecture?

Requirements aspect

Functional aspect Operational aspect Using patterns Validation aspect

Architect career in IBM Closing

Agenda

(23)

What are requirements? They are fundamental to system architecture

Functional Requirements:

– Are capabilities needed by users to fulfill their job

– Answers the question of "what" the customer needs (but often not "how" it is achieved) Qualities:

– Define the expectations and characteristics that the system should support

– Might be runtime (for example, performance or availability) or non-runtime (for example,

scalability or maintainability) Constraints:

– Givens, those things that cannot be changed within the scope and lifetime of the project – Other factors, such as mandated technologies,

available skills, and budget

(Qualities and constraints are sometimes referred to as “non-functional requirements”)

Requirements determine the architecture of a system in terms of:

– Structuring and placement decisions – Solution sizing and costing

– Product selection, deployment, and configuration framework

Requirements are of a direct concern to an IT Architect:

– Assists with the collection and definition of a system's architectural qualities and constraints (non-functional requirements)

– Participates in the review and gathering of business and functional requirements – Assesses feasibility of requirements in the

context of the proposed technical solution – Form the basis of traceability of business

requirements to architectural designs,

which is validated during the review process

(24)

What does the requirements space look like?

Identifies business functions the system supports

Identifies potential enhancement based on both business and

technology opportunities

Primarily related to the system

service levels

(25)

A sample taxonomy for Qualities and Constraints (also knows as Non-functional Requirements)

Runtime Non-Runtime

a c it y & P e rf o rm a n c e A v a ila b ili ty S e c u ri ty te m s M a n a g e m e n t U s a b ili ty P o rt a b ili ty M a in ta in a b ili ty S c a la b ili ty D a ta I n te g ri ty S a fe ty

Qualities

Business Technical

R e g u la to ry O rg a n is a ti o n a l R is k W ill in g n e s s a rk e tp la c e F a c to rs h e d u le a n d B u d g e t e g a c y I n te g ra ti o n e v e lo p m e n t S k ill s is ti n g I n fr a s tr u c tu re n o lo g y S ta te o f th e A rt IT S ta n d a rd s

Constraints

Non-functional Requirements

(26)

Most important artifact (1): The System Context is essential to capturing the scope of the project

The System Context helps to:

– Clarify the environment in which the system has to operate – Put bounds on the system

– Identify external interfaces (users or systems)

(27)

Most important artifact (1): The Architecture Overview setting the scene for

the solution (to be slept with under the pillow)

(28)

Architecture Overview example: Retail Customer Access Points—The Retail Customer can

choose from a variety of ways to interact with the company. The supporting infrastructure

should be common whenever possible

(29)

Architecture Overview example: Non-technical Audiences

(30)

Example – I lead a team of architects in a complex environment with unclear requirements and several stakeholders:

XXXWorld Service Platform – an architecture overview

Application layer Presentation layer

Multi-access functionality

Syncron-

isation Caching Content

filtering

Personal- isation

Content

management Commerce Security

Access right

management CRM Location Push

notifications

Streaming

SP Core

ASP

Service layer

Chat Instant

messaging PIM (calendar, Addresses)

Unified messaging

Play Arcade Self-service Music

SP Non-Core

E-mail

SMS/EMS

MCO Presentation

Presentation layer

Language Currency

conversion Caching Content filtering

Service layer

MCO Specific service

MCO Services

MCO Specific

service MCO

Specific service

MCO Specific

service

XXXWorld Central MCO Local (Country)

Presentation layer

Back-end

Application layer

Settlement Data

Warehouse Reporting

Charging

3

^rd

Parties

Service layer

OIF adaptations

3rd party Specific service 3rd party

specific service

3rd party Specific service

CC&B

Network Element(s)

3

^rd

Parties

PLMN

Service layer

OIF adaptations

3rd party Specific service 3rd party

specific service

3rd party Specific service

XXX Integration Framework

MMS

Closing

(31)

Same example – Unclear requirements and several stakeholders and

several very large “pre-selected” components with overlapping capabilities and being in development by vendor – another architecture overview

O S P F o u n d atio n R elea se 0.2

F IS

C o n ten t

M g m t C o nten t

P rovid er

L D A P

P a rla y G W A cc es s

S M S -C

CIMD 2.0

F T P C on ten t S torag e

&

L oa de r A pp lic atio n S erv er

Java

Ja va P o rtal S e rv er

P A P

S S M F Im ple m en

tation S S M F

P o rtle t

Java S e rvice C o nn ecto r

P ortle t

W P S D B

Lo g-In P o rtle t

O S P A P I

FIS A P I

C on ten t A P I S M S

A P I

Lo g D B W eb S E

A L

H T TP

C D A S

Sync

C ha rg in g A P I

S M S com m an d

access S ervice s

Provisioning

B M R

D B B M R

D B

AP

J a v a

C o nten t A d m inistarto r A cc es s H T T P

O u tgo in g S M S m essag es H T T P

P arlay/C O R B A

B S S I

Aepona RAFTP

C on te nt S erve r

Closing

(32)

Introduction

What is architecture?

Requirements aspect Functional aspect

Operational aspect Using patterns Validation aspect

Architect career in IBM Closing

Agenda

(33)

The functional aspect of IT architecture capture the system’s functional behaviour and is described using components, their responsibilities, dependencies and interactions

A component is a modular unit of functionality.

A component makes its functionality and state available through one or more interfaces.

Examples of components are:

– Business processing components (such as the Customer Processing component)

– Business service components (such as the Account Manager component)

– Technical components (middleware such as messaging or transaction software)

– System software components (such as an operating system) – Hardware components (such as an encryption device)

A component is not just a programming level concept such as an

(34)

The functional aspect of IT architecture is primarily focused on…

its structure, as described in a Component Relationship

Diagram, as well as…

…its behavior, as shown in a Component Interaction

Diagram

(35)

Most important artifact (2): The Component Model which is established using the Component Modeling technique

Partition into subsystems and components and assign responsibilities

Review architectural patterns, reference architectures, and reusable assets

Structure ensuring loose coupling, high cohesion, and so on

Specify interfaces

Specify operations and signatures

Specify pre- and post-conditions

Identify products and packages

Define implementation approach

(36)

The Component Model is used as input into a number of activities

Work Allocation

Version Control

Design Strategy

Reuse

Testing

Project Management

Product/Package Selection

(37)

The components arise from the functional requirements

The actor requests a stock query.

The system prompts for the actor to select a store name and enter an article or product name/number.

The actor selects a store name and enters an article or product name. If a product name is entered, the user may also be required to specify further selection criteria (such as selecting color and so on) for that product.

The system searches for the selected article or product in the named store and checks its availability.

The system determines that the article or product is available.

The system returns the availability information for the article or product.

The use case ends successfully.

Use Case: Check Stock Availability

(38)

… and from data

1. Produce a logical data model showing

business entities.

2. Identify core business entities.

3. Create components to

‘manage’ core

business entities. ²

1 3

3

2

1

(39)

… and the operational aspect influences the Component Model from multiple sources like

Placement Considerations:

– Adding components that allow existing components to collaborate between nodes, e.g. asynchronous messaging

– Adding responsibilities to handle different presentation types, e.g. thin versus thick client

– Adding components that handle data and software distribution Achieving Observable Qualities:

– Aggregating components, e.g. to achieve better performance

– Segregating components, e.g. if responsibilities have different runtime qualities

Availability:

– What if individual components must be failure-resilient?

– What if the system is used by subsidiaries in other time zones?

Scalability:

– What components are needed to support planned or unplanned growth?

Performance:

(40)

Introduction

What is architecture?

Requirements aspect Functional aspect Operational aspect

Using patterns Validation aspect

Architect career in IBM Closing

Agenda

(41)

The design of operational system aspect may be challenging to develop or understand – Many competing concerns must be resolved:

• Qualities: for example, Performance, Availability, Manageability, Security

• Constraints: for example, Affordability, Standards compliance, Existing Infrastructure – Multiple activities must be co-ordinated:

• Detailed design: Network, Hardware, Systems management

• Commercial: Planning, Pricing, Procurement

Systems must be deployed - either using new or onto existing infrastructure

???? ????

Operational aspect

(42)

Functional Aspect

Operational Aspect Application

level

Physical view Technical

level

Logical view

How systems are deployed is the primary concern of the Operational Aspect of IT System Architecture

The Operational Aspect:

– Is part of a dimension of an IT system’s architecture

– Represents how the application’s components are deployed across the geographical structure of the IT System

– Describes how the system’s Service Level Requirements (SLRs) are satisfied

– Serves as a blueprint for detailed infrastructure design, such as network design, platform design, systems management design

The key artifact is the Operational Model, which shows how we implement the IT system’s functional and non-functional requirements within the constraints of technology, skills and budget

We have to get from

here…

…to here Operational aspect

(43)

Most important artifact (2): Operational Model helps ensure the system’s non- functional requirements are delivered, within all constraints by providing the architectural context for detailed design across a myriad of themes

Systems Management

Capacity Planning

Availability & Performance Engineering

Defining Organizational Responsibilities Software & Data Distribution

Service Level Characteristic Analysis System Monitoring

Package & Product Selection Procurement

Operational aspect

(44)

There are many ways of deploying a single component into a simple system…

Word, running on XP, stand-alone

Presentation Execution Data

Installation

Option 1

Everything on the PC…

Word, running on XP, with remote file serving

Presentation

Execution Data

Installation Option 2

Word, running on Citrix, with remote file serving

Presentation Execution Data

Installation Option 4

Word, running on Citrix, with local data

Presentation Execution

Data Installation

Option 3

…Or not!

How do we do this, for complex systems, in a structured manner?

Operational modelling!

Operational aspect

(45)

To achieve this goal, we need a structured, formal language to describe the elements featured on the Operational Model

To achieve this goal, the Operational Model represents the system’s “infrastructure architecture”, using a variety of model elements, including:

– The geographic structure of the locations and their borders, over which the IT system will be deployed and operated

– The placement of the system’s nodes into these locations

– The deployment of the system’s components across these nodes, using deployment units – The connections between nodes

– The organisation of the system’s elements into zones

As well as this description of the deployed system, the OM also documents:

– The usage of logical structures to deliver the non functional requirements – The patterns which are use for logical and physical configuration

– The overall physical configuration of the technologies and products necessary to deliver the functional and non-functional requirements of the IT system

– Sizing and other hardware specifications for all the computers, storage devices and network technologies

Operational aspect

(46)

What’s Word?

We have to understand what it is we need to deploy, via the DEPLOYMENT UNIT Model

DUs give us a mechanism for

– Understanding the non-functional requirements placed on the system’s components

– Deciding where best to place the various aspects of the system’s components

– Tracing the system’s requirements to its design

Volatility Currency Number

records Unit/

record Size Data

Type

Concurrent Active Nature of

Access Point

Actor using Access Point

Location Required Hours

Users

Systems Actors

Release Frequency Size

Presentation

Execution

Installation

Data

95% response time Number per

user Usage

‘Window’

Txn Type

Presentation Deployment Unit:

Execution Deployment Unit:

Installation Deployment Unit:

Data Deployment Unit:

Component

Operational aspect

(47)

The Operational Model is developed across a “ backdrop ” of the system ’ s geographic landscape …

Non-IBM Office

IBM Office

Internet

Services Corporate

Services KEY for comments

Method commentary

Design decisions

Operational aspect

(48)

… based on an understanding of the locations and their relationships (borders) over which the DUs, nodes and connections will be placed

KEY

Border, internal connection, medium speed Border, external intermittent connection Border, no permitted connection

Border, internal connection, high speed

(10s) Cardinality

(1000) (100)

(10) (3)

Borders can provide visual

clues on the inter-location

networking capabilities

LL_Non-IBM_Office LL_IBM_Office

LL_Internet_Services LLCorporate_Services

Untrusted zone

Trusted zone

Logical Location

LL_x

Operational aspect

(49)

… and the applications ’ data DUs can now be placed, based on actor access requirements ( “ data sharing ” and other factors) …

ALN_mobile_

workstation

ALN_data_server

(1000) (100)

A_work- station_A

P_Off-line

ALN_presentation_

server

U_On-line

D_documents(s) D_templates

D_documents(s) d_templates

ALN_department_

fileserver

D_documents(s)

(1) (25)

ALN_ work- station_B

U_Remote A_Offline_

author

(25)

A_Remote_

author

Application level DU to

DU interactions

LL_Non-IBM_Office LL_IBM_Office

Normal notation shows DUs adjacent to Nodes

– we’re “building”

the nodes by placing the DUs

“in” the nodes

Data transfer from master to copy templates

Some of the The offline user’s documents, and a

copy of the document templates

Some of the online user’s

documents

U_Off-line

KEY

D_x Data DU (master) d_x Data DU (copy) D_x(s) Segmented data

Construction line – the actor interacting with this PDU needs access to this

data

Operational aspect

(50)

Working through this rationale produces the final Application level OM

ALN_Personalisatio n_Services

ALN_Online_

Customer_Services

L8, Country Office

L5, Corporate Services L6, Other Internet

Services

L2, Private Customer

L3, Internet Services

L4, Central Site Runtime Services

L7, Store

L9, Head Office L1, Corporate Customer

(1, 3...) (0 - n)

(100)

(20)

(n)

(1k) (1m)

(1)

L10, App

Mgt Svcs

(1) (1)

ALN_Application_

Services A_Offline_

customer

A_Inventory _Checker

ALN_Online_

Store_Services ALN_Offline_

Customer_

Services

ALN_Backend _

Services A_OMS

A_SMS U_Inventory

U_OMS U_SMS U_Offline

U_PrivBrowser

D_Inventory_Upd(s) D_Opn_Order(s)

d_cat d_image d_price

D_Opn_Order(s) d_cat

d_price d_image

E_Submit_Inv_Update

E_Update_CRM_Data E_Consult_CRM_Data

E_Consolidate_Inv_Update E_Consolidate_Order E_Submit_Order

E_Create_Order

E_Submit_Order E_Create_Order

E_Consult_Cat D_Cust_Prof

D_Cust_Visit

d_inventory_upd D_Sub_Order D_Cat D_Price D_Image A_Online_

Customer

A_Online_

CRM_User A_Catalog_

Management U_CRM

U_Cat

Operational aspect

(51)

Now we can “debate” non-functional requirements and other considerations, and hereby identify any additional node …

L6, Other Internet Services

L3, Internet Enabled Services

LN_Personalization Svcs

LN_Online Cus Pres

Svcs

L2, Private Customer A_Online_

Customer

LN_Online Cust App Srvs

LN_Online Cust Data Srvs LN_Offline

Corp Customer Svcs

LN_Online Store Svcs L1, Corporate Customer

LN_L3Sys Mgmt

LN_L4Sys Mgmt

LN_L10Sys Mgmt LN_L7Sys

Mgmt

System Mgmt Considerations Additional SN(s) System Mgmt Considerations Additional SN(s)

LN_Content Mgmt L10, AMS

L5, CorpSvcs

Meet scalability requirements Meet scalability requirements

Operational aspect

(52)

At some point in time products may be selected

L4, Central Site Runtime Services

L2, Private Customer

L8, Country Office

L5, Corporate Services L6, Other

Internet Services

L7, Store

L9, Head Office L1, Corporate Customer

L10, App Mgt Svcs Internet

A_Browser

WAN Internet L3, Internet Services

(1 to n)

App Server:

WebSphere Appn Server Web Server:

IBM HTTP Server

Auth’n Server:

Tivoli Access Manager Credential Registry:

IBM Directory Server Edge Server:

WebSphere Edge Server + Tivoli Access Manager Plug-In

Data Server:

IBM DB2 Domain Firewall

Cisco PIX Protocol Firewall

Cisco PIX

PN_Router:

Cisco Router

Select firewall for controlling access in the DMZ

Select software to host customer data (adjacent choice) Select software to host customer data (adjacent choice) Given and obvious

product choices Given and obvious product choices

Operational aspect

(53)

Another example – huge (innovative) operational model designed for extreme flexibility and optimized ressource usage

Login Caching

Sikkerhed Database

Fælles Services

&

Interfaces

Teknisk kravtest

Kvalitetssikring

Pilotdrift

Drift Undervisning

Environments established ”on-the-

fly”

Minimize HW and SW cost

Load

Closing

(54)

Same example – an underlying concept of environments delivered as a composition of ”segments” within “sectors” (depending on SLAs). All based on 4 very large

virtualized p590 32way and a truck-load of Wintel servers.

Miljø segment Funk. kravtest

Sikkerhed

Fælles Services Miljø segment

Pilotdrift Caching

Miljø segment Drift Miljø segment

Undervisning Miljø segment Kvalitetssikring

Miljø segment Teknisk kravtest

Login

Konfigurationssektor Testsektor Driftsektor

Fælles Services

Caching

Miljø segment Brugervenl. test

Miljø segment Funk. kravtest Miljø segment

Integr. test Miljø segment Funk. kravtest Miljø segment

Vedligehold Miljø segment Funk. kravtest Miljø segment

Udvikling

Caching

Fælles Services Miljø segment

Konfig

Database Database

Database Login Sikkerhed

Closing

(55)

Introduction

What is architecture?

Requirements aspect Functional aspect Operational aspect Using patterns

Validation aspect

Architect career in IBM Closing

Agenda

(56)

What is a reusable asset?

Assets may have variability points, which are defined as a section that can/should be

customized by the user of the asset.

Assets include rules and instructions for use or customization.

Assets contain artifacts that are work products from the software development lifecycle.

* From OMG’s Reusable Asset Specification document

Using patterns

(57)

How are assets classified?

Describes how many particular problems or solution alternatives an asset addresses

Describes the degree of completeness of the artifacts in providing the solution

Describes how easily or

readily the asset can be

modified or altered

Using patterns

(58)

Examples of how assets are classified

Reference Architectures Architectural Patterns /

Styles Granularity

Variability

Articulation

Granularity

Variability

Articulation

D es ig n P at te rn s

Using patterns

(59)

Sample Reference Architecture: IBM Information Framework (IFW)

A set of banking specific business models that represent good practice in banking

The IFW business models enable an enterprise to:

– Be more adaptive and to respond quickly to changing customer needs

– Focus on achieving competitive

differentiation

– Identify and leverage

(60)

Anti-pattern: Golden Hammer

Anti-Pattern Name: Golden Hammer

General Form: A software development team is very skilled in a particular solution (Golden Hammer) and every development effort is viewed as something that is best solved with it.

Symptoms and Consequences:

–

Misapplication of a favored concept or tool; identical solutions for varying types of requirements and scope

–

Solutions have inferior performance, scalability, etc., compared to others

–

Requirements are not fully met in an attempt to leverage existing investments

–

Existing solution dictates architecture and design

–

Heavily dependent on a particular set of technologies

Refactored Solution:

–

Expand the knowledge of developers through education, training, and book study groups to expose developers to new solutions

Using patterns

(61)

Introduction

What is architecture?

Requirements aspect Functional aspect Operational aspect Using patterns

Validation aspect

Architect career in IBM

Agenda

(62)

The architectural process

Definition of the architectural process and how it fits in the IBM Unified Method Framework (UMF)

The iterative approach of the UMF and how architectural work is structured to produce architectural work products

Pitfalls to avoid

Dangers inherent to the architectural process

An organizational approach to the architectural process

Assessments of the architecture

Validation aspect

(63)

What is a Viability Assessment?

Most dictionaries define viability as the ability for something to grow or develop When examining viability in terms of a development project or architecture, consider:

– Is it suitable?

• Is it an appropriate solution in terms of customer requirements?

– Is it doable?

• Is it in the "realm of the possible"?

– Is it practical?

• Can it be done with the available means?

A Viability Assessment is used by the architect to:

– Verify that the solution meets customer requirements – Ensure that the proposed solution is possible

– Assess client acceptance of the technical elements of the design – Confirm development approach and environment

– Identify project risks

Validation aspect

(64)

Rules of Thumb - Defect Removal, Testing and Function Points

RofT 23: The number of potential defects in a new development is given by raising the FP count to the power of 1.25. [14]

Potential Defects (New Developments) = FP Count ^ 1.25

Typical US removal rates are around 85% efficiency, i.e. Delivered Defects = Potential defects * 0.15.

RofT 24: For a CMM level 3 organisation, the number of potential defects in a new development is given by raising the FP count to the power of 1.1 and the defect removal efficiency is about 95%.

[14]

RofT 26: Each formal design inspection will remove 65% of the bugs present. [14]

RofT 27: Each formal code inspection will remove 60% of bugs present. [14]

RofT 28: Each software test will remove 30% of the bugs that are present. [14]

Validation aspect

(65)

The testing ‘V’ model and System Engineering baseline reviews are a good starting point for planning validation & verification

activities

Validation aspect

(66)

Introduction

What is architecture?

Requirements aspect Functional aspect Operational aspect Using patterns

Validation aspect

Architect career in IBM

Agenda

(67)

Within IBM there are several IT Architect disciplines covering different aspects of architecture, representing best practices, advises on skill development and each is represented by a world-wide advisory body

Architect career in IBM

(68)

What does an IT Architect do;

We have can have the same context but different focus

Subway

Buildings

Roads

(69)

Characteristics of an IT Architect

Skills and experience producing architectures

Appropriate technical skills and experience, including technical breadth

Disciplined, method-driven execution

Full life-cycle experience

Leadership

Strong personal and professional skills

The effective IT Architect brings a broad base of fundamental skills across many professional and technical disciplines to their work

– A common set of fundamental skills

Architectural Skills

– Perform Technical Solution Assessments – Develop client requirements and architectural

decisions

– Lead in setting technical direction – Use modeling techniques

– Apply IT standards in creation of solutions – Architect solution for security

– Develop test strategies and plans – Develop solutions architecture – Apply methodologies

Project Management Skills

– Manage architectural elements of project plan – Plan projects

Consulting skills

– Use consulting techniques – Perform negotiations – Manage client relationships Leadership Skills

– Apply communication skills – Lead individuals and teams Architect career in IBM

(70)

The IT Architect Career Model Focus is on Skills Development, and I can become Sam’s right hand….

The IT Architect Career Model

HR Position

Alignment

With Qualification Status At these levels

The IT Architect

develops

these skills The IT Architect

demonstrates

these skills in these levels

Senior Certified IT Architect Certified

IT Architect Accredited

IT Architect Unaccredited

IT Architect Technical

Skills

Fundamental Skills

Discipline Skills

Leadership Skills

Executive Skills Fundamental

Skills

Discipline Skills

Leadership Skills

SENIOR CERTIFICATION

CERTIFICATION

ACCREDITATION

The Three Development Checkpoints validate entry level skills for the next level

Executive IT Architect Senior

IT Architect Advisory

IT Architect Associate

IT Architect

Qualification levels build upon previous levels as part of the career development process

(71)

Introduction

What is architecture?

Requirements aspect Functional aspect Operational aspect Using patterns

Validation aspect

Architect career in IBM Closing

Agenda

(72)

ARC318 Parametric Costs ARC320 Technical

Transaction Map

The modeling and tooling problem

ARC108 Component Model APP130 Use

Case Model

ARC310 Standards

ARC111 Deployment Units

APP110 Logical Data Model

APP011 System Context

APP146 UI Conceptual Model

APP147 UI Design Guidelines

ARC119 Non Functional Requirements ARC108 Architecture

Overview Diagram ARC102 Ref. Architecture

Fit/Gap Analysis

ARC107 Architectural Template

ARC100 Architectural Decision ARC113 Operational

Model

ARC115 Software Dist. Plan ARC319 Performance

Model

ARC118 Change Cases

ARC117 Viability Assessment ARC103 Technical

Prototype ARC114 Service Level

Char. Analysis ARC301 Current

IT Envionment

OPS308 IT Services Strategy

Dependencies to/from most other work products

MS Vi sio MS W ord

MS Vi sio

MS Po we rP oin t Ra tio na l

Ro se

MS Ex ce l

MS W ord

MS W ord MS Ex ce l

MS W ord CA ER wi n

MS W ord Wo rd of

mo uth

IBM Academy of Technology Report: Analysis of Resources for Architectural Work

“Most architects use tools that are no

better than those their kids use for doing

their homework”

(73)

Hvorfor laver vi modeller?

For at Tænke Forstå

Lære

Beskrive Dokumentere Kommunikere Visualisere Abstrahere

Håndtere kompleksitet ved at separere

aspekter i forskellige ”views” (separation of concerns)

Modeling is not an all-or-nothing proposition. Models can play a part in the software development process in many

Vigtigheden af at modellere

Mere

Mindre

(74)

Define/understand requirements

Define architecture and technical solution Define method

Define work breakdown Establish estimates Assemble team

Lead technical delivery team Maintain requirements

Maintain architecture

Redefine architecture and technical solution Redefine method

Redefine work breakdown Establish estimates

…

Basically my work is about requirements, solutions, processes and people

Review – proposal and deliver Pre-sale

Participate in communities Teach

Mentorship

…

Get out of the project…

Closing

(75)