Modeling in IBM A practitioners vie 02341...Architectural Thinking involves inputs, process, and...

© 2009 IBM Corporation

Modeling in IBMA practitioners view

Ole [email protected]+45 2880 9572

Ole Rasmussen, Senior IT Architect, IBM Global Business Services

11. May 2010

© 2009 IBM Corporation2 Ole Rasmussen11. May 2010

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)

ProjectDefinition

Analysis

Design

Construction

Test Maintenance

Production

“Our” model driven approach

ProjectDefinition

Modelling

Construction

Test Maintenance

Production

Design

Analysis



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

ProjectDefinition

Modelling

Construction

Test Maintenance

Production

Design

Analysis

IT Architecture scope (approx)



� 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



Introduction

What is architecture?

Requirements aspect

Functional aspect

Operational aspect

Using patterns

Validation aspect

Architect career in IBM

Closing

Introduction


Requirements aspect

Functional aspect

Operational aspect

Using patterns

Validation aspect


Closing

AgendaAgenda



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



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

ApplicationMaintenance

ApplicationBuild

Application Design

OngoingBusiness

Run

Business Transformation

Delivery

Business Transformation

Design

InfrastructureRun

Infrastructure Build

InfrastructureDesign

ProposalAnd

ContractNegotiation

Notice the gaps...

Introduction



Introduction


Requirements aspect

Functional aspect

Operational aspect

Using patterns

Validation aspect


Closing

AgendaAgenda



”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)

BusinessStrategy

InformationTechnology

Strategy

BusinessOpportunity

TechnologyAvailability

BusinessArchitecture

ITArchitecture

- Processes- Information- People- Locations

- Applications- Data- Technology

Planning

Design andDelivery

En

terp

rise

wid

e fo

cus

Pro

ject

fo

cus

Strategy

Business Operating Environmentand IT Infrastructure

IT Solutions

Enterprise Architecture

Transition Plan

Enterprise Architecture“the city plan”

System Architecture• functional aspects• operational aspects“the infrastructure and singlebuilding design”

Strategy and vision“Which city do we want to build?”

TheGap

The Great Divide




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”)




Architecture versus designSystem 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 System Architecture.




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




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.




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




Architectural Thinking involves inputs, process, and outputs

� Analyzing the requirements (and resolving conflicts between them)

� Applying principles (possibly defined at the Enterprise Architecture level)

� Creating models at the right level of abstraction (that is, hiding details that are not relevant)

� Creating views that satisfy the concerns of different stakeholders

� Providing a decision trail




Architectural Thinking involves analyzing requirements by addressing a number of concerns




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




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




The dimensions of architectureWhat is architecture?



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




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?




Introduction


Requirements aspect

Functional aspect

Operational aspect

Using patterns

Validation aspect


Closing

AgendaAgenda



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 businessrequirements to architectural designs, which is validated during the review process



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



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

Runtime Non-Runtime

Cap

acity

& P

erfo

rman

ce

Ava

ilabi

lity

Sec

urity

Sys

tem

s M

anag

emen

t

Usa

bilit

y

Por

tabi

lity

Mai

ntai

nabi

lity

Sca

labi

lity

Dat

a In

tegr

ity

Saf

ety

Qualities

Business Technical

Reg

ulat

ory

Org

anis

atio

nal

Ris

k W

illin

gnes

s

Mar

ketp

lace

Fac

tors

Sch

edul

e an

d B

udge

t

Lega

cy In

tegr

atio

n

Dev

elop

men

t Ski

lls

Exi

stin

g In

fras

truc

ture

Tec

hnol

ogy

Sta

te o

f the

Art

IT S

tand

ards

Constraints

Non-functional Requirements

AccessibilitySee more here: http://en.wikipedia.org/wiki/List_of_system_quality_attributes



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)



Most important artifact (1): The Architecture Overview setting the scene for the solution (to be slept with under the pillow)



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



Architecture Overview example: Non-technical Audiences



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-accessfunctionality

Syncron-isation

Caching Contentfiltering

Personal-isation

Contentmanagement

Commerce Security

Access rightmanagement

CRM Location Pushnotifications

Streaming

SP Core

ASP

Service layer

Chat Instantmessaging

PIM(calendar,

Addresses)

Unifiedmessaging

Play Arcade Self-serviceMusic

SP Non-Core

E-mail

SMS/EMS

MCO PresentationPresentation layer

LanguageCurrency

conversionCaching Content

filtering

Service layer

MCOSpecificservice

MCO Services

MCOSpecificservice

MCOSpecificservice

MCOSpecificservice

XXXWorld Central MCO Local (Country)

Presentation layer

Service layer

Application layer

Back-end

Application layer

Settlement Data

WarehouseReportingCharging

3rd Parties

Service layer

OIF adaptations

3rd party Specific service

3rd party specificservice


CC&B

NetworkElement(s)

PLMN3rd Parties

Service layer

OIF adaptations


3rd party specificservice


XXX Integration Framework

MMS

Closing



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

OSP Foundation Release 0.2

FIS

ContentMgmt

M CO BSS

ContentProvider

LDAP

Parlay GWAccess

SMS-C

CIM

D2.

0

FTPContentStorage

&Loader

Application Server

Java

Java

Portal ServerPAP

SSMFImplemen

tation

SSM FPortlet

Java

ServiceConnector

Portlet

W PSDB

Log-InPortlet

OSP API

FIS API

ContentAPI

SMSAPI

LogDB

W ebSEAL

HTTP

CDAS

Sync

ChargingAPI

SMScomm and

access

Services

Pro

visi

onin

g

BMRDBBMRDB

BMR

SO

AP

J a v a

ContentAdministartor

Access HTTP

Outgoing SMSm essages

HTTP

Parlay/CORBA

BSSI

Aep

ona

RA

FT

P

Cust.Mngt.

Content Server

Closing



Introduction


Requirements aspect

Functional aspect

Operational aspect

Using patterns

Validation aspect


Closing

AgendaAgenda



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 EJB or .NET component!



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



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



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



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



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

2

1

3

3

2

1

1

1

1

1

1

1

1



… 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:– How can long- versus short-running transactions be handled?



Introduction


Requirements aspect

Functional aspect

Operational aspect

Using patterns

Validation aspect


Closing

AgendaAgenda



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

The functional aspect is not always sufficient for these "systems engineering“ concerns - its prime purpose is "software engineering"

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

????????

Operational aspect



Functional Aspect

Operational

Aspect

Applicationlevel

Physical view

Technicallevel

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 componentsare 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



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

How can we make it work? (Operational Model)

How do we configure it?How do we manage it?

(Detailed Design)

Operational aspect



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

Word, running on XP,stand-alone

PresentationExecutionDataInstallation

Option 1Everything

on the PC…

Word, running on XP, with remote file serving

PresentationExecution

DataInstallation

Option 2

Word, running on Citrix, with remote file serving

Presentation ExecutionDataInstallation

Option 4

Word, running on Citrix, with local data

Presentation ExecutionData Installation

Option 3

…Or not!

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

Operational modelling!

Operational aspect



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



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 CurrencyNumber

records

Unit/

record Size

Data

Type

Concurrent

Active

Nature of

Access Point

Actor using

Access Point

Location Required

Hours

Users

Systems

Actors

Release FrequencySize

Presentation

Execution

Installation

Data

95% response timeNumber per

user

Usage

‘Window’

Txn

Type

Presentation Deployment Unit:

Execution Deployment Unit:

InstallationDeployment Unit:

Data Deployment Unit:

Component

Operational aspect



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

Non-IBMOffice

IBMOffice

InternetServices Corporate

Services

KEY for comments

Method commentary

Design decisions

Operational aspect



…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_ServicesUntrusted zone

Trusted zone

Logical LocationLL_x

Operational aspect



… 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)

(10) (3)

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)

(25)(1)

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

LL_Internet_Services LLCorporate_Services

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 online user’s

documents and all of their templates

The offline user’s documents, and a

copy of the document templates

Some of the online user’s documents

U_Off-line

KEYD_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



Working through this rationale produces the final Application level OM

ALN_Personalisation_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)

(1m)(1k)

(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_OMSU_SMS

U_Offline

U_PrivBrowser

D_Inventory_Upd(s)D_Opn_Order(s)d_catd_imaged_price

D_Opn_Order(s)d_catd_priced_image

E_Submit_Inv_Update

E_Update_CRM_DataE_Consult_CRM_Data

E_Consolidate_Inv_UpdateE_Consolidate_Order

E_Submit_OrderE_Create_Order

E_Submit_OrderE_Create_Order

E_Consult_Cat

D_Cust_ProfD_Cust_Visit

d_inventory_updD_Sub_OrderD_CatD_PriceD_Image

A_Online_Customer

A_Online_CRM_User

A_Catalog_Management

U_CRMU_Cat

Operational aspect



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


L3, Internet Enabled Services

LN_PersonalizationSvcs

LN_Online Cus Pres

Svcs


A_Online_Customer

LN_OnlineCust App Srvs

LN_OnlineCust Data Srvs

LN_Offline Corp Customer

Svcs

LN_Online StoreSvcs

L4, Central Site Runtime Services


LN_L3Sys Mgmt

LN_L4Sys Mgmt

LN_L5Sys Mgmt

LN_L10SysMgmt

LN_L7SysMgmt

System Mgmt ConsiderationsAdditional SN(s) and DU

System Mgmt ConsiderationsAdditional SN(s) and DU

LN_ContentMgmt

LN_BackendSvcs

L10, AMS

L5, CorpSvcs

Meet scalability requirements

Meet scalability requirements

Operational aspect



At some point in time products may be selected

L4, Central Site Runtime Services(1)


L8, Country Office

L5, Corporate Services


L7, Store

L9, Head Office


L10, App Mgt Svcs

Internet

A_Browser

WAN

InternetL3, Internet Services(1 to n)

App Server:WebSphereAppn 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 FirewallCisco PIX

Protocol FirewallCisco PIX

PN_Router:Cisco Router

Select firewall for controlling access in the DMZ

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



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

Login Caching

Sikkerhed Database

FællesServices

&Interfaces

Teknisk kravtest

Kvalitetssikring

Pilotdrift

Drift

Undervisning

Environmentsestablished ”on-the-

fly”

Minimize HW and SW cost

Load

Tid2006 2007

Closing



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ø segmentFunk. kravtest

Sikkerhed

FællesServices

Miljø segmentPilotdrift

Caching

Miljø segmentDrift

Miljø segmentUndervisning

Miljø segmentKvalitetssikring

Miljø segmentTeknisk kravtest

Login

Konfigurationssektor Testsektor Driftsektor

FællesServices

Caching

Miljø segmentBrugervenl. test


Miljø segmentIntegr. test


Miljø segmentVedligehold


Miljø segmentUdvikling

Caching

FællesServices

Miljø segmentKonfig

Database DatabaseDatabase

Login

Sikkerhed

Closing



Introduction


Requirements aspect

Functional aspect

Operational aspect

Using patterns

Validation aspect


Closing

AgendaAgenda



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



How are assets classified?

* From OMG’s Reusable Asset Specification document

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



Examples of how assets are classified

Reference Architectures

Architectural Patterns /

Styles

Granularity

Variability

Articulation

Granularity

Variability

Articulation

Desig

n P

atterns

Using patterns



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 best practice behaviors across the organization



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



Introduction


Requirements aspect

Functional aspect

Operational aspect

Using patterns

Validation aspect


AgendaAgenda



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



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



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



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

Validation aspect



Introduction


Requirements aspect

Functional aspect

Operational aspect

Using patterns

Validation aspect


AgendaAgenda



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




What does an IT Architect do;We have can have the same context but different focus

Subway

Buildings

Roads




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

– Lead strategy, design, and implementation of solution

– Use existing work products– Develop project output for future reuse

Project Management Skills

– Manage architectural elements of project plan

– Plan projectsConsulting skills

– Use consulting techniques

– Perform negotiations

– Manage client relationships

Leadership Skills – Apply communication skills

– Lead individuals and teams

Industry knowledge




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

AlignmentWith Qualification Status

At these levels The IT Architect

develops these skills

The IT Architect

demonstrates these skills in these levels

Senior Certified

IT Architect

CertifiedIT Architect

Accredited IT Architect

Unaccredited IT Architect

Technical Skills

Fundamental Skills

DisciplineSkills

Leadership Skills

Executive Skills

Fundamental Skills

DisciplineSkills

Leadership Skills

SE

NIO

R C

ER

TIF

ICA

TIO

N

CE

RT

IFIC

AT

ION

AC

CR

ED

ITA

TIO

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

ExecutiveIT Architect

SeniorIT Architect

AdvisoryIT Architect

Associate IT Architect

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




Introduction


Requirements aspect

Functional aspect

Operational aspect

Using patterns

Validation aspect


Closing

AgendaAgenda



ARC318 ParametricCosts

ARC320 TechnicalTransaction Map

The modeling and tooling problem

ARC108 ComponentModel

APP130 UseCase Model

ARC310 Standards

ARC111 DeploymentUnits

APP110 LogicalData Model

APP011 SystemContext

APP146 UIConceptual Model

APP147 UIDesign Guidelines

ARC119 NonFunctional RequirementsARC108 Architecture

Overview Diagram

ARC102 Ref. ArchitectureFit/Gap Analysis

ARC107 ArchitecturalTemplate

ARC100 ArchitecturalDecision

ARC113 OperationalModel

ARC115 SoftwareDist. Plan

ARC319 PerformanceModel

ARC118 ChangeCases

ARC117 ViabilityAssessment

ARC103 TechnicalPrototype

ARC114 Service LevelChar. Analysis

ARC301 CurrentIT Envionment

OPS308 ITServices Strategy

Dependencies to/from most other work products

MS Visio MS Word

MS Visio

MS PowerPoint

Rational

Rose

MS Excel

MS Word

MS WordMS Excel

MS Word

CA ERwinMS Word

Word of

mouth

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”

Ole Rasmussen 02341 Modelbaseret softwareudvikling73 Ole Rasmussen11. May 2010

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 canplay a part in the software development process in manyways.

Gary Cernosek: ”The Value of Modeling”ftp://ftp.software.ibm.com/software/rational/web/whitepapers/ValueOfModeling.pdf

Vigtigheden afat modellere

Mere

Mindre



� 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



My work is about communication; communicating and discussingrequirements, solutions and processes.I’m building bridges balancing opposing forces

Customer User

Operator

Maintainer

SupplierProject ManagerIBM Management

Consultant

Architect

Developer

Sales Rep

Closing

Ole Rasmussen 02341 Modelbaseret softwareudvikling76 Ole Rasmussen11. May 2010

Do we ever reach ”Model only”?

Code Code Code Code

Model Model Model Model

“What’s aModel?”

“The code isthe model”

“Code and model coexist”

“The model is the code”

“Let’s talkmodels”

Code onlyCode

visualizationRoundtrip

engineering Model-centric Model only

Modeling in IBM A practitioners vie 02341...Architectural Thinking involves inputs, process, and...

Documents

Transcript of Modeling in IBM A practitioners vie 02341...Architectural Thinking involves inputs, process, and...