modeling in ibm a practitioners vie 02341...architectural thinking involves inputs, process, and...
TRANSCRIPT
© 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
© 2009 IBM Corporation3 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
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)
© 2009 IBM Corporation4 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
� 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
© 2009 IBM Corporation5 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
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
AgendaAgenda
© 2009 IBM Corporation6 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
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
© 2009 IBM Corporation7 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
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
© 2009 IBM Corporation8 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
Introduction
What is architecture?
Requirements aspect
Functional aspect
Operational aspect
Using patterns
Validation aspect
Architect career in IBM
Closing
AgendaAgenda
© 2009 IBM Corporation9 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
”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
What is architecture?
© 2009 IBM Corporation10 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
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”)
What is architecture?
© 2009 IBM Corporation11 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
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.
What is architecture?
© 2009 IBM Corporation12 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
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
What is architecture?
© 2009 IBM Corporation13 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
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 is architecture?
© 2009 IBM Corporation14 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
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
What is architecture?
© 2009 IBM Corporation15 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
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
What is architecture?
© 2009 IBM Corporation16 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
Architectural Thinking involves analyzing requirements by addressing a number of concerns
What is architecture?
© 2009 IBM Corporation17 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
Architectural Thinking involves creating views to satisfy the concerns of different stakeholders
What is architecture?
© 2009 IBM Corporation18 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
Our method (“Unified Method Framework”) is the “repository” of best practice and experience representing a number of “basic” and “cross-cutting” viewpoints.
What is architecture?
© 2009 IBM Corporation19 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
The dimensions of architectureWhat is architecture?
© 2009 IBM Corporation20 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
The System Description Standard (SDS) describes the fundamental concepts that can be used to describe systems
What is architecture?
© 2009 IBM Corporation21 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
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?
What is architecture?
© 2009 IBM Corporation22 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
Introduction
What is architecture?
Requirements aspect
Functional aspect
Operational aspect
Using patterns
Validation aspect
Architect career in IBM
Closing
AgendaAgenda
© 2009 IBM Corporation23 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
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
© 2009 IBM Corporation24 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
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
© 2009 IBM Corporation25 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
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
© 2009 IBM Corporation26 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
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)
© 2009 IBM Corporation27 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
Most important artifact (1): The Architecture Overview setting the scene for the solution (to be slept with under the pillow)
© 2009 IBM Corporation28 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
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
© 2009 IBM Corporation29 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
Architecture Overview example: Non-technical Audiences
© 2009 IBM Corporation30 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
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
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
3rd party Specific service
CC&B
NetworkElement(s)
PLMN3rd Parties
Service layer
OIF adaptations
3rd party Specific service
3rd party specificservice
3rd party Specific service
XXX Integration Framework
MMS
Closing
© 2009 IBM Corporation31 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
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
© 2009 IBM Corporation32 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
Introduction
What is architecture?
Requirements aspect
Functional aspect
Operational aspect
Using patterns
Validation aspect
Architect career in IBM
Closing
AgendaAgenda
© 2009 IBM Corporation33 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
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!
© 2009 IBM Corporation34 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
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
© 2009 IBM Corporation35 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
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
© 2009 IBM Corporation36 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
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
© 2009 IBM Corporation37 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
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
© 2009 IBM Corporation38 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
… 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
© 2009 IBM Corporation39 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
… 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?
© 2009 IBM Corporation40 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
Introduction
What is architecture?
Requirements aspect
Functional aspect
Operational aspect
Using patterns
Validation aspect
Architect career in IBM
Closing
AgendaAgenda
© 2009 IBM Corporation41 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
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
© 2009 IBM Corporation42 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
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
© 2009 IBM Corporation43 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
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
© 2009 IBM Corporation44 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
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
© 2009 IBM Corporation45 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
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
© 2009 IBM Corporation46 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
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
© 2009 IBM Corporation47 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
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
© 2009 IBM Corporation48 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
…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
© 2009 IBM Corporation49 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
… 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
© 2009 IBM Corporation50 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
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
© 2009 IBM Corporation51 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
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_PersonalizationSvcs
LN_Online Cus Pres
Svcs
L2, Private Customer
A_Online_Customer
LN_OnlineCust App Srvs
LN_OnlineCust Data Srvs
LN_Offline Corp Customer
Svcs
LN_Online StoreSvcs
L4, Central Site Runtime Services
L1, Corporate Customer
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
© 2009 IBM Corporation52 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
At some point in time products may be selected
L4, Central Site Runtime Services(1)
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
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
© 2009 IBM Corporation53 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
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
© 2009 IBM Corporation54 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
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ø segmentFunk. kravtest
Miljø segmentIntegr. test
Miljø segmentFunk. kravtest
Miljø segmentVedligehold
Miljø segmentFunk. kravtest
Miljø segmentUdvikling
Caching
FællesServices
Miljø segmentKonfig
Database DatabaseDatabase
Login
Sikkerhed
Closing
© 2009 IBM Corporation55 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
Introduction
What is architecture?
Requirements aspect
Functional aspect
Operational aspect
Using patterns
Validation aspect
Architect career in IBM
Closing
AgendaAgenda
© 2009 IBM Corporation56 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
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
© 2009 IBM Corporation57 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
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
© 2009 IBM Corporation58 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
Examples of how assets are classified
Reference Architectures
Architectural Patterns /
Styles
Granularity
Variability
Articulation
Granularity
Variability
Articulation
Desig
n P
atterns
Using patterns
© 2009 IBM Corporation59 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
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
© 2009 IBM Corporation60 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
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
© 2009 IBM Corporation61 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
Introduction
What is architecture?
Requirements aspect
Functional aspect
Operational aspect
Using patterns
Validation aspect
Architect career in IBM
AgendaAgenda
© 2009 IBM Corporation62 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
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
© 2009 IBM Corporation63 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
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
© 2009 IBM Corporation64 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
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
© 2009 IBM Corporation65 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
The testing ‘V’ model and System Engineering baseline reviews are a good starting point for planning validation & verificationactivities
Validation aspect
© 2009 IBM Corporation66 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
Introduction
What is architecture?
Requirements aspect
Functional aspect
Operational aspect
Using patterns
Validation aspect
Architect career in IBM
AgendaAgenda
© 2009 IBM Corporation67 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
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
© 2009 IBM Corporation68 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
What does an IT Architect do;We have can have the same context but different focus
Subway
Buildings
Roads
Architect career in IBM
© 2009 IBM Corporation69 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
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
Architect career in IBM
© 2009 IBM Corporation70 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
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
Architect career in IBM
© 2009 IBM Corporation71 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
Introduction
What is architecture?
Requirements aspect
Functional aspect
Operational aspect
Using patterns
Validation aspect
Architect career in IBM
Closing
AgendaAgenda
© 2009 IBM Corporation72 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
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
© 2009 IBM Corporation74 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
� 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
© 2009 IBM Corporation75 Ole Rasmussen11. May 2010
Modeling @ IBM – presentation at DTU, Denmark –
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