Front cover
Strategic Reuse with
Asset-Based
Development
Implement strategic reuse with
Rational Asset Manager
Improve quality and time to
market
Learn the best practices for
Service and Pattern assets
Lee Ackerman
Paul Elder
Chris Busch
Ana Lopez-Mancisidor
Jin Kimura
Rishi S. Balaji
ibm.com/redbooks
International Technical Support Organization
Strategic Reuse with Asset-Based Development
May 2008
SG24-7529-00
Note: Before using this information and the product it supports, read the information in “Notices” on
“Notices” on page xv.
First Edition (May 2008)
This edition applies to Version 7.0.0.1 of Rational Asset Manager.
© Copyright International Business Machines Corporation 2008. All rights reserved.
Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule
Contract with IBM Corp.
Contents
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
The team that wrote this book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii
Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi
Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi
Part 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Chapter 1. Introduction to Asset-Based Development . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Software delivery challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 The reuse challenge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Value of using assets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Asset-Based Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4.1 Asset management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4.2 Artifacts within reusable assets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4.3 Styles of reuse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4.4 Packaging assets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.5 Asset life cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.6 Asset repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.7 Reuse success factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.8 Guide to the remaining chapters of this book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Chapter 2. ZYX Electronics case study. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Overview of ZYX Electronics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.1 Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.2 CEO interview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.3 CIO interview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.4 Business composition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.1 The business. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.2 Information technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4 Scope and approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.2 Approach. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.3 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
18
18
18
20
22
23
25
26
26
28
28
29
30
31
Chapter 3. Tools in support of Asset-Based Development . . . . . . . . . . . . . . . . . . . . . .
3.1 Overview of IBM tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Eclipse. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3 Rational Modeling Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.1 Rational Application Developer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
33
35
35
36
© Copyright IBM Corp. 2008. All rights reserved.
iii
3.4
3.5
3.6
3.7
3.8
WebSphere Business Modeler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
WebSphere Integration Developer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Rational RequisitePro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Rational ClearCase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Rational ClearQuest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.8.1 WebSphere Studio Asset Analyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.9 Asset repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.9.1 Rational Asset Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.9.2 WebSphere Service Registry and Repository. . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.9.3 Rational Asset Manager compared with other products . . . . . . . . . . . . . . . . . . . .
3.9.4 IBM Asset Repository strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.10 Process and methodology support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.10.1 Rational Method Composer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.10.2 Rational Portfolio Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.10.3 Rational ProjectConsole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.11 Bringing it all together . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
36
37
37
38
38
39
39
39
40
44
45
45
46
46
47
Chapter 4. Introduction to the IBM Rational Unified Process . . . . . . . . . . . . . . . . . . . .
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.1 How much of this guidance needs to be used . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 IBM Rational Unified Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.1 The heart of RUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.2 The IBM Rational Method Composer platform . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.3 Core principles of RUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.4 Key concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
49
49
50
52
52
53
56
59
Chapter 5. Asset-Based Development and Asset Governance Rational Method
Composer plug-ins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.1 Introduction to the asset plug-ins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.2 Adoption guidance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.2.1 How adoption guidance fit into a process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.2.2 How much of this guidance do you use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.3 Governance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.3.1 Asset governance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.4 Asset governance plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.4.1 Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.4.2 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.4.3 Enablement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5.4.4 Measurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.5 Asset-Based Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.5.1 Manufacturing and usage cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.6 Asset-Based Development plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.6.1 Produce reusable asset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.6.2 Manage reusable assets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.6.3 Consume Reusable Asset Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.7 When to use these processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
5.8 Asset process views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
5.9 Creating extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
5.10 ZYX Electronics development case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
5.10.1 What is a development case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
5.10.2 Content sources for the ZYX Electronics development case . . . . . . . . . . . . . . . 99
5.10.3 More information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
iv
Strategic Reuse with Asset-Based Development
Chapter 6. Value, impact, and return on investment . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1 Impact and ROI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.1 Avoid over-measuring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2 Not all assets are equal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3 Gathering data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3.1 Startup data sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3.2 Ongoing data sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.4 Asset Reuse Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.4.1 Tooling and methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.4.2 Asset creation and acquisition approaches. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.4.3 Asset type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.4.4 Reuse scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5 Calculations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.6 Cost of reuse failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.7 Additional calculations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
103
103
104
105
111
114
115
117
117
117
117
117
118
120
120
Part 2. Reusable Assets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Chapter 7. Adopting Asset-Based Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
7.1 Pilot projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
7.2 Reuse maturity model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
7.3 Organization templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
7.3.1 Ad-Hoc organization template. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
7.3.2 Self-Governed organization template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
7.3.3 Governed organization template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
7.3.4 Enterprise Partial organization template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
7.3.5 Enterprise Full organization template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
7.4 Reuse adoption strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
7.5 ZYX’s Asset Governance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
7.6 Getting started at ZYX Electronics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
7.7 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
7.8 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
7.9 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
7.10 Maturity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
7.11 Areas of assessment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
7.12 Management support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
7.12.1 Does management specify policies and support asset reuse . . . . . . . . . . . . . . 147
7.12.2 Does management provide top-down support for investing with bottom-up
implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
7.13 Software process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
7.13.1 Do the project teams follow a repeatable software process . . . . . . . . . . . . . . . 150
7.13.2 Are there management artifacts produced from the process and does management
use them . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
7.14 Business domain understanding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
7.14.1 Is the business problem space understood by the software organization. . . . . 150
7.15 Architecture to support reuse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
7.15.1 Does the software architecture permit assets to be harvested and plugged in for
reuse. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
7.16 Versioning and configuration management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
7.16.1 Does the software team practice source code versioning and configuration
management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
7.17 Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
7.17.1 Maturity model alignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Contents
v
7.17.2 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.18 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.19 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.20 Key concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.21 Asset-Based Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.22 Motivations for Asset-Based Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.23 Assets and artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.24 Asset standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.25 Reuse vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.26 Vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.26.1 Realizing the vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.27 Identified risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.27.1 Asset misidentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.27.2 Asset Consumer mis-targeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.27.3 Volume-centric Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.27.4 Asset governance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.27.5 Over-engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.27.6 Do It Yourself (DIY) equals innovation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.27.7 Budget and resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.28 Reuse environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.29 Reuse environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.30 Asset-Based Development process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.31 Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.32 Asset production strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.33 Reuse infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.34 Reuse implementation strategy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.34.1 Reuse adoption strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.35 Maturity model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.36 Organizational templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.37 How it all fits together . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.38 Reuse implementation plan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.39 Phase one: Existing assets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.39.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.39.2 Goals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.40 Phase two: Pattern-based engineering rollout . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.40.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.40.2 Goals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.41 Phase three: Services as assets rollout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.41.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.41.2 Goals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.42 Phase four: Post-pilot review and analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.42.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.42.2 Goals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
vi
Strategic Reuse with Asset-Based Development
154
155
156
157
157
158
158
159
160
162
164
166
166
166
167
167
167
168
168
168
168
168
169
171
172
173
173
175
180
183
184
184
184
185
185
185
185
185
185
186
186
186
186
7.43
7.44
7.45
7.46
7.47
7.48
7.49
7.50
7.51
7.52
7.53
7.54
Metrics for measuring progress. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Economic metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Primary metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Asset Consumer feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Library metrics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Additional considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Reuse incentives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Internal communication model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Training model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Funding model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Looking ahead. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
187
188
190
190
190
191
191
192
192
193
193
194
Chapter 8. Configure your Asset Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.1 Rational Asset Manager information metamodel . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.1.1 Community Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.1.2 Asset workflow specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.1.3 Asset type specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.1.4 Administration roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.1.5 Best practices to customize your Repository . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2 Repository configuration for ZYX Electronics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2.1 Creating communities and Community Administrators . . . . . . . . . . . . . . . . . . . .
8.2.2 Creating asset types, category schemas, relationship types, and attributes . . .
8.2.3 Managing users and assigning roles in communities . . . . . . . . . . . . . . . . . . . . .
8.2.4 Defining default review processes in communities . . . . . . . . . . . . . . . . . . . . . . .
8.3 What comes next . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
195
196
197
203
205
209
211
214
217
218
228
232
235
Chapter 9. Produce reusable assets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.2 Asset manufacturing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.2.1 Asset manufacturing roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.2.2 Conduct recurring problem analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.2.3 Develop asset specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.2.4 Create asset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.2.5 Review and test asset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.2.6 Update asset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.2.7 Publish or deploy asset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.3 ZYX Electronics: Produce reusable assets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.3.1 Recurring problem analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.3.2 Develop asset specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.3.3 Create asset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.3.4 Review and test asset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.3.5 Update Asset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.3.6 Publish or deploy asset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
237
237
238
239
240
242
245
248
249
251
252
253
257
261
270
272
279
Chapter 10. Consume reusable assets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.2 Asset usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.2.1 Asset consumption roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.2.2 Search asset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.2.3 Use asset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.2.4 Provide asset feedback. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.2.5 Develop asset specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
281
282
283
283
284
286
288
289
Contents
vii
10.3 ZYX Electronics: Consume reusable assets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.3.1 Search asset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.3.2 Use asset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.3.3 Provide asset feedback. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
290
290
295
297
Chapter 11. Manage reusable assets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.2 Asset management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.2.1 Asset management roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.2.2 Search asset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.2.3 Review and test asset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.2.4 Publish or deploy asset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.2.5 Configure Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.2.6 Remove asset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.2.7 Report on asset. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.3 Migration of existing assets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.3.1 Migration strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.3.2 Asset cleansing, defining, and mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.3.3 Mapping and uploading. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.4 ZYX Electronics: Manage reusable assets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.4.1 Search asset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.4.2 Review and test asset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.4.3 Publish or deploy asset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.4.4 Configure Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.4.5 Remove asset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.4.6 Report on asset. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.4.7 Conclusions and future plans at ZYX Electronics . . . . . . . . . . . . . . . . . . . . . . .
303
304
305
306
307
307
309
310
311
313
314
314
315
316
317
318
318
324
324
324
326
331
Part 3. Service Assets in an SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
Chapter 12. Introduction to service assets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.1 Setting the context for Part 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.1.1 How does Part 3 relate to the rest of the book . . . . . . . . . . . . . . . . . . . . . . . . .
12.1.2 How does this part relate to SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.1.3 How does this part relate to RUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.2 SOA, services, and assets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.3 What is a service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.3.1 Reusable business functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.3.2 Explicit implementation-independent interfaces . . . . . . . . . . . . . . . . . . . . . . . .
12.3.3 Communication protocols that stress location transparency. . . . . . . . . . . . . . .
12.4 Web services and SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.5 SOA Governance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.5.1 SOA life cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.5.2 SOA Governance defined . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.5.3 The governance life cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.5.4 Relationship between Asset Governance and SOA Governance . . . . . . . . . . .
12.6 Types of service-based assets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.7 Service-oriented modeling and architecture (SOMA) . . . . . . . . . . . . . . . . . . . . . . . .
12.7.1 Rational Method Composer plug-in for SOMA . . . . . . . . . . . . . . . . . . . . . . . . .
12.8 IBM products for implementing service assets . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.8.1 Rational Method Composer plug-in for SOA Governance . . . . . . . . . . . . . . . .
12.8.2 Rational Software Architect and Rational Software Modeler . . . . . . . . . . . . . .
12.8.3 WebSphere Integration Developer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.8.4 WebSphere Process Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
viii
Strategic Reuse with Asset-Based Development
335
336
336
336
336
338
339
339
340
340
341
341
341
343
343
345
346
349
349
349
350
350
351
352
12.8.5 WebSphere Business Services Fabric . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.8.6 WebSphere Business Modeler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.8.7 WebSphere Business Monitor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.8.8 WebSphere Service Registry and Repository. . . . . . . . . . . . . . . . . . . . . . . . . .
12.8.9 Rational Asset Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.8.10 WebSphere Studio Asset Analyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
353
354
355
355
355
356
Chapter 13. Producing service assets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.1 Creating service assets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.2 SOMA insights for asset development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.2.1 Service identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.2.2 Service specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.2.3 Service realization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.3 Creating a composite business service asset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.3.1 Modeling a composite business service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.3.2 Assembling a composite business service . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.3.3 Deploying a composite business service . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.4 Testing service assets in an SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.4.1 IBM products for SOA testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.5 Publishing service assets to the Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.5.1 Repositories in the life of a service asset . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.5.2 Governance options for publishing services . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.5.3 Publishing assets to Rational Asset Manager. . . . . . . . . . . . . . . . . . . . . . . . . .
13.6 Case study: SOA service reuse at ZYX Electronics . . . . . . . . . . . . . . . . . . . . . . . . .
13.6.1 Current state of service reuse at ZYX Electronics . . . . . . . . . . . . . . . . . . . . . .
13.6.2 Rational Asset Manager configuration for ZYX Electronics . . . . . . . . . . . . . . .
13.6.3 Produce and Publish service assets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
359
360
360
362
366
371
373
374
375
380
380
382
383
383
386
387
392
392
393
394
Chapter 14. Consuming service assets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14.1 Locating services for consumption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14.1.1 Locating services in WebSphere Service Registry and Repository . . . . . . . . .
14.1.2 Locating services in WebSphere Business Services Fabric . . . . . . . . . . . . . . .
14.2 Consuming service metadata from WSRR for CBS assembly . . . . . . . . . . . . . . . . .
14.2.1 WebSphere Business Services Fabric and the WSRR integration . . . . . . . . . .
14.3 Points of variability of service-based assets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14.4 Customizing Composite Business Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14.5 Reusing assets from the Industry Content Packs . . . . . . . . . . . . . . . . . . . . . . . . . . .
14.6 Providing service reuse feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14.7 Case study: SOA service reuse at ZYX Electronics . . . . . . . . . . . . . . . . . . . . . . . . .
399
400
400
402
403
403
406
410
411
414
415
Chapter 15. Managing service assets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425
15.1 Configuring the repositories for effective service management . . . . . . . . . . . . . . . . 426
15.1.1 Integrating Rational Asset Manager and WebSphere Service Registry and
Repository. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
15.1.2 Configuring WebSphere Business Services Fabric for sourcing metadata from
WebSphere Service Registry and Repository . . . . . . . . . . . . . . . . . . . . . . . . . . 430
15.2 Review and approve services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430
15.2.1 Security features in WebSphere Service Registry and Repository . . . . . . . . . . 431
15.2.2 WebSphere Business Services Fabric Governance Manager . . . . . . . . . . . . . 434
15.3 Reporting on service reuse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436
15.3.1 Assessing service reuse with WSRR and IBM Tivoli . . . . . . . . . . . . . . . . . . . . 436
15.3.2 Using WebSphere Business Services Fabric Performance Manager for asset
management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441
Contents
ix
15.4 Retiring service assets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15.5 Service Integration Maturity Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15.6 Case study: SOA service reuse at ZYX Electronics . . . . . . . . . . . . . . . . . . . . . . . . .
15.6.1 Publish developed service to WebSphere Service Registry and Repository . .
15.6.2 Conclusions and benefits for ZYX Electronics . . . . . . . . . . . . . . . . . . . . . . . . .
445
445
447
447
453
Part 4. Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
x
Chapter 16. Introduction to patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16.1 Improving productivity in software development . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16.1.1 How to use this part of the book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16.2 Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16.3 Developing a pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16.3.1 Roles in developing pattern implementations . . . . . . . . . . . . . . . . . . . . . . . . . .
16.4 Pattern-based engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16.5 A process for pattern-based engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16.5.1 Establish project constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16.5.2 Identify representative use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16.5.3 Develop candidate architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16.5.4 Customize the development process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16.5.5 Pattern harvesting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16.6 Reality check: Does pattern-based engineering really work . . . . . . . . . . . . . . . . . . .
16.6.1 Case study one: A large banking application . . . . . . . . . . . . . . . . . . . . . . . . . .
16.6.2 Case study two: An IBM product development team . . . . . . . . . . . . . . . . . . . .
16.6.3 Critical success factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16.7 The next steps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
457
458
458
459
460
460
461
462
463
464
464
465
466
466
466
467
468
468
Chapter 17. Produce: Model-to-text pattern implementations . . . . . . . . . . . . . . . . . .
17.1 Case study: Identifying a recurring problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17.2 Model-to-text pattern tooling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17.2.1 What is JET. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17.2.2 IBM tools for creating JET-based solutions. . . . . . . . . . . . . . . . . . . . . . . . . . . .
17.3 Developing a pattern implementation for Java beans . . . . . . . . . . . . . . . . . . . . . . . .
17.3.1 Create a JET authoring project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17.3.2 Identify an abstraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17.3.3 Create a model element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17.3.4 Identify exemplar artifacts arising directly from the abstraction . . . . . . . . . . . .
17.3.5 Create actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17.3.6 Parameterize actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17.3.7 Update templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17.3.8 Parameterize templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17.3.9 Running the JET transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17.4 Enabling iterative development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17.4.1 Case study: Adding derived properties to beans . . . . . . . . . . . . . . . . . . . . . . .
17.4.2 Reapply strategies: Handling incomplete abstractions . . . . . . . . . . . . . . . . . . .
17.4.3 Reapply strategies: Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17.5 An XPath primer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17.5.1 What is a path language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17.5.2 XPath basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17.5.3 Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17.5.4 Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17.5.5 Following a reference to another model element . . . . . . . . . . . . . . . . . . . . . . .
17.6 Useful JET techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17.6.1 Dumping the input model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
469
470
473
473
475
479
479
481
482
483
485
488
495
495
503
506
506
507
511
518
518
518
521
521
522
523
523
Strategic Reuse with Asset-Based Development
17.6.2 The org.eclipse.jet.resource family of JET variables. . . . . . . . . . . . . . . . . . . . .
17.6.3 Load additional models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17.6.4 JET support for different types of models . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17.6.5 Accessing EMF-based models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17.6.6 Access the Eclipse workspace with JET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17.7 The next steps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
523
524
525
526
527
528
Chapter 18. Produce: Model-to-model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.2 Case study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.2.1 Solution design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.3 Technology review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.3.1 Eclipse plug-ins and the Plug-in Development Environment (PDE) . . . . . . . . .
18.3.2 The Eclipse Modeling Framework (EMF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.3.3 UML and UML Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.3.4 Model-to-model mapping transformations. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.3.5 UML patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.3.6 UML template models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.4 Build an EMF model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.4.1 Enable the EMF capability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.4.2 Create an EMF project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.4.3 Control the EMF code generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.4.4 Generate model code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.5 Build a UML profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.5.1 Create a profile project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.5.2 Create stereotypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.5.3 Release the profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.5.4 Publish the profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.6 Build a model-to-model mapping transformation . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.6.1 Create model mapping project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.6.2 Create mappings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.6.3 Generate transformation source code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.6.4 Customize to invoke a JET transformation back end . . . . . . . . . . . . . . . . . . . .
18.6.5 Debug and test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.6.6 Finding your way around the UML API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.7 Build a UML pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.7.1 Create the UML Pattern project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.7.2 Define the bean package UML pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.7.3 Complete the parameter implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.7.4 Test the UML pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.8 Build a template model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.8.1 Create a UML template model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.8.2 Test the template model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18.9 Comments regarding the patterns that we have described. . . . . . . . . . . . . . . . . . . .
18.10 The next steps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
529
530
530
530
531
531
531
531
532
532
532
532
532
534
535
536
536
536
538
540
541
545
545
547
557
558
559
569
571
572
572
574
578
580
581
583
584
586
Chapter 19. Produce: Packaging for deployment. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19.1.1 Distribution options overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19.2 Sharing JET projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19.2.1 Case study: Packaging a JET-only solution . . . . . . . . . . . . . . . . . . . . . . . . . . .
19.2.2 Deployment solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19.2.3 Entering assets into repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
587
588
588
588
589
589
590
Contents
xi
xii
19.2.4 Retrieving assets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19.3 Exporting JET projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19.3.1 Case study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19.3.2 Deployment solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19.3.3 Deployment preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19.3.4 Pattern selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19.3.5 Developer installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19.4 Exporting Eclipse features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19.4.1 Case study: Packaging the complete bean pattern solution . . . . . . . . . . . . . . .
19.4.2 Installing software in Eclipse-based products . . . . . . . . . . . . . . . . . . . . . . . . . .
19.4.3 Create a feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19.4.4 Create an update site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19.4.5 Using an update site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19.4.6 Using features and update sites with IBM Rational Asset Manager . . . . . . . . .
19.5 Exporting Eclipse features using RAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19.5.1 Create a RAS asset from a feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19.5.2 Importing a feature from a RAS asset. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19.5.3 Notes on deploying features with RAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19.6 The next steps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
593
594
594
594
594
598
598
600
600
600
601
603
604
606
608
608
610
611
611
Chapter 20. Consuming pattern implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20.1.1 Types of pattern usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20.2 Management of input models and transformation configurations . . . . . . . . . . . . . . .
20.2.1 Saving JET launch configurations in the workspace. . . . . . . . . . . . . . . . . . . . .
20.2.2 Supporting parallel development on input models . . . . . . . . . . . . . . . . . . . . . .
20.3 Management of transformation outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20.4 Integrating transformations with automated builds . . . . . . . . . . . . . . . . . . . . . . . . . .
20.4.1 The jet.transform Ant task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20.4.2 Launching JET transformations as part of a workspace build. . . . . . . . . . . . . .
20.5 Running transformations with integration builds . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20.5.1 Using the jet.transform Ant task with headless builds. . . . . . . . . . . . . . . . . . . .
20.5.2 Fine-tuning pattern implementations for integration builds . . . . . . . . . . . . . . . .
20.6 Extending existing JET transformations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20.6.1 Common reasons for overriding a pattern. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20.6.2 Case study revisited . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20.6.3 Create a JET transformation that overrides another JET transformation . . . . .
20.6.4 Overriding templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20.6.5 Executing the overriding JET transformation . . . . . . . . . . . . . . . . . . . . . . . . . .
613
614
614
615
615
616
618
619
619
621
623
623
624
625
626
626
626
627
629
Strategic Reuse with Asset-Based Development
20.7 The next steps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 629
Chapter 21. Managing pattern implementation assets . . . . . . . . . . . . . . . . . . . . . . . .
21.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21.2 Encouraging asset creation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21.3 Enabling multiple versions of an asset to coexist in a single workbench . . . . . . . . .
631
632
632
632
Part 5. Appendixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635
Appendix A. Rational Asset Manager: Installation and administration . . . . . . . . . . .
Rational Asset Manager architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.1 Administrator roles and tasks in Rational Asset Manager . . . . . . . . . . . . . . . . . . . . .
A.2 Rational Asset Manager installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.2.1 Planning the installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.2.2 Installing Rational Asset Manager Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.2.3 Installing Rational Asset Manager clients (Web and Eclipse). . . . . . . . . . . . . . .
A.2.4 User authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.3 Rational Asset Manager integrations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.3.1 Integrating Rational Asset Manager with WSRR . . . . . . . . . . . . . . . . . . . . . . . .
A.3.2 Integrating Rational Asset Manager with Rational ClearQuest. . . . . . . . . . . . . .
A.3.3 Integrating Rational Asset Manager with Rational ClearCase . . . . . . . . . . . . . .
A.4 Rational Asset Manager Administrator tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.4.1 How to import and export data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.4.2 How to import and export a Repository model . . . . . . . . . . . . . . . . . . . . . . . . . .
A.4.3 How to perform a backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.4.4 Adding MIME types for a WebSphere Application Server installation . . . . . . . .
A.4.5 How to customize the home layout. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.4.6 How to create a graphical navigation search navigation model . . . . . . . . . . . . .
A.4.7 Start the RAM service automatically at startup on Windows . . . . . . . . . . . . . . .
A.4.8 Performance considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.4.9 Application programming interface (API) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.5 Rational Asset Manager add-ins. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.5.1 Rational Asset Manager configurator tool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
637
638
642
643
644
648
655
657
661
661
665
688
702
702
702
703
703
704
705
707
708
710
711
711
Appendix B. Integrating Asset-Based Development into a process . . . . . . . . . . . . .
B.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.2 Rational Unified Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.3 Rational Method Composer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.4 How to customize the RUP using RMC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.4.1 Method development work products. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.4.2 Method development tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.5 How to create a project plan specific to your project . . . . . . . . . . . . . . . . . . . . . . . . .
B.5.1 Identify the phase iterations, activities, and tasks to execute . . . . . . . . . . . . . . .
B.5.2 Creating a project plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
713
714
715
717
718
719
722
723
724
724
Appendix C. Additional material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Locating the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
System requirements for downloading the Web material . . . . . . . . . . . . . . . . . . . . . . .
How to use the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
725
725
725
725
726
Contents
xiii
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 727
Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IBM Redbooks publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
How to get IBM Redbooks publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
729
729
729
729
730
730
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 733
xiv
Strategic Reuse with Asset-Based Development
Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in other countries. Consult
your local IBM representative for information on the products and services currently available in your area. Any
reference to an IBM product, program, or service is not intended to state or imply that only that IBM product,
program, or service may be used. Any functionally equivalent product, program, or service that does not
infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to
evaluate and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in this document. The
furnishing of this document does not give you any license to these patents. You can send license inquiries, in
writing, to:
IBM Director of Licensing, IBM Corporation, North Castle Drive, Armonk, NY 10504-1785 U.S.A.
The following paragraph does not apply to the United Kingdom or any other country where such
provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION
PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR
IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of
express or implied warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made
to the information herein; these changes will be incorporated in new editions of the publication. IBM may make
improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time
without notice.
Any references in this information to non-IBM Web sites are provided for convenience only and do not in any
manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the
materials for this IBM product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring
any obligation to you.
Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products and cannot confirm the
accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the
capabilities of non-IBM products should be addressed to the suppliers of those products.
This information contains examples of data and reports used in daily business operations. To illustrate them
as completely as possible, the examples include the names of individuals, companies, brands, and products.
All of these names are fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrate programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs in
any form without payment to IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating platform for which the sample
programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore,
cannot guarantee or imply reliability, serviceability, or function of these programs.
© Copyright IBM Corp. 2008. All rights reserved.
xv
Trademarks
IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines
Corporation in the United States, other countries, or both. If these and other IBM trademarked terms are
marked on their first occurrence in this information with a trademark symbol (® or ™), these symbols indicate
U.S. registered or common law trademarks owned by IBM at the time this information was published. Such
trademarks may also be registered or common law trademarks in other countries. A current list of IBM
trademarks is available on the Web at “Copyright and trademark information” at:
http://www.ibm.com/legal/copytrade.shtml
The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:
Redbooks (logo)
®
alphaWorks®
developerWorks®
i5/OS®
z/OS®
Ascendant®
AIX®
ClearCase®
ClearQuest®
Component Business Model™
CICS®
DB2®
IBM®
ProjectConsole™
PureCoverage®
PurifyPlus™
Rational Rose®
Rational Summit®
Rational Unified Process®
Rational®
Redbooks®
Requisite®
RequisitePro®
RUP®
Summit Ascendant™
Summit®
System z™
Team Unifying Platform™
Tivoli®
WebSphere®
XDE™
The following terms are trademarks of other companies:
SAP, and SAP logos are trademarks or registered trademarks of SAP AG in Germany and in several other
countries.
Oracle, JD Edwards, PeopleSoft, Siebel, and TopLink are registered trademarks of Oracle Corporation and/or
its affiliates.
Flex, and Portable Document Format (PDF) are either registered trademarks or trademarks of Adobe
Systems Incorporated in the United States, other countries, or both.
EJB, Java, Javadoc, JavaBeans, JavaScript, JavaServer, JDBC, JMX, JRE, JSP, JVM, J2EE, J2SE, RSM,
Sun, and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other
countries, or both.
Access, Active Directory, Internet Explorer, Microsoft, SQL Server, Visual Studio, Windows, and the Windows
logo are trademarks of Microsoft Corporation in the United States, other countries, or both.
Pentium, Intel logo, Intel Inside logo, and Intel Centrino logo are trademarks or registered trademarks of Intel
Corporation or its subsidiaries in the United States, other countries, or both.
UNIX is a registered trademark of The Open Group in the United States and other countries.
Linux is a trademark of Linus Torvalds in the United States, other countries, or both.
Other company, product, or service names may be trademarks or service marks of others.
xvi
Strategic Reuse with Asset-Based Development
Preface
Reuse has often been touted as an approach to solving issues, such as time to market and
solution quality. Reuse over the years has taken on a number of forms, ranging from copy and
paste of code, reuse of objects, reuse of components, to more recently the reuse of services.
However, we still find ourselves running late on our projects (when we do deliver) and having
poor quality.
Unfortunately, we often underestimate the effort and forethought needed in creating a
successful reuse program within an organization. Successful reuse does not happen by
accident or by just wishing it to be true.
This IBM Redbooks publication is focused on a best practice-based approach to strategic
reuse within software delivery, known as Asset-Based Development, that will assist in
addressing these issues. We do not contend that this is the “silver bullet” that will fix all of the
issues that ail software delivery. However, Asset-Based Development is a key tool that needs
to be found within the tool chest of all software development organizations (or at least those
that want to succeed).
This book, as shown in Figure 1, is comprised of four major parts and a set of appendixes.
Part 1:
Introduction
Part 2:
Reusable Assets
•Introduction to
Asset-Based
Development
•Adopting
Asset-Based
Development
•Process and
Tooling
•Configuring
Asset
Management
•Case Study
Overview
•Produce,
Consume, and
Manage Assets
•Impact and ROI
Part 3:
Services
•Services as Assets
•Produce, Consume,
and Manage Service
Assets
Appendixes
•Rational Asset
Manager
Installation and
Administration
•Process
Integration
Part 4:
Patterns
•Patterns as Assets
•Produce, Consume,
and Manage Pattern
Assets
Figure 1 An overview of the structure of the book
Although we encourage you to read the entire book, we also recognize that different
audiences have more interest in certain areas than other areas. Therefore, we have a short
guide to the contents found within this book:
For an overview of Asset-Based Development, including process, roles, tooling, and types
of assets, read Part 1, “Introduction” on page 1.
For a detailed look at effective asset management, read Part 2, “Reusable Assets” on
page 123.
If you want to build reusable service-oriented architecture (SOA) service-based assets,
read Part 1, “Introduction” on page 1, Part 2, “Reusable Assets” on page 123, and Part 3,
“Service Assets in an SOA” on page 333.
© Copyright IBM Corp. 2008. All rights reserved.
xvii
If you want to build pattern-based engineering reusable assets, we have had excellent
results in groups adopting pattern-based engineering as a starting point into an asset
program. This starting point has proven to provide a quick time to market, significant ROI,
and high quality. Detailed guidance covering pattern-based engineering is provided in
Part 4, “Patterns” on page 455:
– After you have succeeded with pattern-based engineering, it becomes easier to invest
in and launch a larger reuse initiative. As your skills in reuse mature and you build
further competency, we encourage you to follow up your patterns experience by
reading Part 1, “Introduction” on page 1 and Part 2, “Reusable Assets” on page 123.
– If you are going to use patterns to build services, read Part 3, “Service Assets in an
SOA” on page 333 as well.
For those people, who want to deploy and administer Rational® Asset Manager, then refer
to Part 1, “Introduction” on page 1, Part 2, “Reusable Assets” on page 123, and
Appendix A, “Rational Asset Manager: Installation and administration” on page 637.
Note that a number of sections in the book discuss topics that in real life happen
concurrently. Unfortunately, it is difficult to present topics in a book concurrently.
The team that wrote this book
This book was produced by a team of specialists from around the world working at the
International Technical Support Organization, San Jose Center.
Figure 2 From left: Lee Ackerman, Paul Elder, Rishi S. Balaji, Ana Lopez-Mancisidor, and Jin Kimura
xviii
Strategic Reuse with Asset-Based Development
Figure 3 Chris Busch
Lee Ackerman is a Senior Product Manager with the Rational Learning Services and
Solutions team in Canada. He has 12 years of experience in the software development field,
the last seven of which have been spent IBM®. He holds a Bachelor’s degree in Business
Administration from the University of Regina. His areas of expertise include model-driven
development, pattern-based engineering, and service-oriented architecture. He has written
extensively about these topics and often presents at conferences, workshops, and training
events.
Paul Elder is a a Senior Software Developer in the IBM Ottawa Lab (Canada). He is the
Project Lead on the Eclipse Model-to-Text (M2T) project and the development lead for the
IBM Rational model-to-text development tools. He has 23 years experience in the software
development field and has worked with IBM Rational for the past seven years. He holds a
Bachelor’s degree in Mathematics from the University of Waterloo and a Masters of Business
Administration from the University of Ottawa. His areas of expertise include model-driven
development, pattern-based engineering, and Java™ and Eclipse development.
Chris Busch is a Business Flexibility (SOA) Practice Lead with the IBM Rational TechWorks
team in the United States. He has 19 years experience in the software development field and
13 years using Rational Software processes and tools. He has been part of the Rational
Software Technical Sales team since 1999 with a focus on software development best
practices, requirements and change management, modeling, SOA, and governance. He
writes extensive proof-of-technology material and develops implementation solutions to
provide internal training and client awareness of Business Driven Development, SOA, SOA
Governance, Service Life Cycle Management, and Asset-Based Development and
management. He often presents at conferences and user groups and delivers workshops and
training to IBM clients and IBM Business Partners.
Ana Lopez-Mancisidor is a Certified IT Specialist in Software Application Development for
IBM Rational Technical Sales in Spain. She has 14 years of experience in the software
development field and nine years of experience using IBM Rational tools. She holds a
Bachelor’s degree in Telecommunications Engineering from the Polytechnic University of
Madrid. Her areas of expertise include the software development process, Asset-Based
Development, requirements and change management, UML modeling, and testing. As part of
the Rational Technical Sales Team, she provides consultancy to clients helping them to
deploy and customize the Rational Unified Process and Rational tools to meet their needs.
Jin Kimura is an Advisory IT Specialist for IBM Global Technology Services in Japan. He has
six years of experience in the software development field. He holds a Masters of Science in
Chemistry from Tohoku University, Japan. His areas of expertise include the design and
development of J2EE™ applications with various assets and the management of their
complete end-to-end life cycle.
Preface
xix
Rishi S. Balaji is an Associate Architect at the Global Business Solutions Centre in IBM
India. He has six and a half years of experience in software development. He has been with
IBM for four and a half years, with three years in WebSphere® development at India Software
Labs and the rest in asset development for the Global Business Solutions Center.His
expertise is in design and development of J2EE applications and reusable assets for
service-oriented architectures.
Special thanks to Grant Larsen, STSM, Chief Architect - Asset Management, IBM Denver, for
creating and providing access to many materials including articles, presentations, and white
papers. Also, we appreciate the time, guidance, and reviews that he provided.
Along the way, many people have contributed feedback and reference materials. We also
want to thank the following people for their contributions to this project:
Dan Popescu, IBM Vancouver
Scott Ambler, IBM Toronto
Grady Booch, IBM Boulder
Bruce Besch, IBM Atlanta
Kelli Houston, IBM Orlando
Gili Mendel, IBM Raleigh
Carlos Ferreira, IBM Lexington
Thierry Matusiak, IBM France
Ralph Schoon, IBM Germany
Bertrand Portier, IBM Toronto
Brian Paulsen, IBM Kansas
Dino D’agostino, IBM Toronto
Manprit Singh, IBM India
Darrell Schrag, IBM Chicago
Cindy VanEpps, IBM Houston
Derek Holt, IBM Raleigh
Chris Gerken, IBM Austin
Geoff Hambrick, IBM Austin
Jim Amsden, IBM Raleigh
Greg Rader, IBM Oklahoma
Franco Potepan, IBM Lexington
Germán Goldszmidt, IBM Watson
Carl Osipov, IBM Watson
xx
Strategic Reuse with Asset-Based Development
and
Joe DeCarlo, Manager - Special Projects, ITSO San Jose, California
And we also want to thank the authors of previous IBM Redbooks publications from which we
have reused content, including:
The IBM Rational Unified Process for System z, SG24-7362-00, by Enrico Mancin, Cecile
Peraire, Angelo Fernandes, Mike Edwards, and Kathy Carroll
Building SOA Solutions with the Rational SDP, SG24-7356-00, by Ueli Wahli, Lee Ackerman,
Alessandro Di Bari, Gregory Hodgkinson, Anthony Kesterton, Laura Olson, and Bertrand
Portier
Become a published author
Join us for a two- to six-week residency program! Help write a book dealing with specific
products or solutions, while getting hands-on experience with leading-edge technologies. You
will have the opportunity to team with IBM technical professionals, IBM Business Partners,
and Clients.
Your efforts will help increase product acceptance and client satisfaction. As a bonus, you will
develop a network of contacts in IBM development labs, and increase your productivity and
marketability.
Find out more about the residency program, browse the residency index, and apply online at:
ibm.com/redbooks/residencies.html
Comments welcome
Your comments are important to us!
We want our books to be as helpful as possible. Send us your comments about this book or
other IBM Redbooks® publications in one of the following ways:
Use the online Contact us review IBM Redbooks publications form found at:
ibm.com/redbooks
Send your comments in an e-mail to:
[email protected]
Mail your comments to:
IBM Corporation, International Technical Support Organization
Dept. HYTD Mail Station P099
2455 South Road
Poughkeepsie, NY 12601-5400
Preface
xxi
xxii
Strategic Reuse with Asset-Based Development
Part 1
Part
1
Introduction
In this part, we introduce you to Asset-Based Development. As shown in Figure P-1, this will
also include a discussion of the business drivers, methodology, and associated tooling.
Part 1:
Introduction
Part 2:
Reusable Assets
•Introduction to
Asset-Based
Development
•Adopting
Asset-Based
Development
•Process and
Tooling
•Configuring
Asset
Management
•Case Study
Overview
•Produce,
Consume, and
Manage Assets
•Impact and ROI
Part 3:
Services
•Services as Assets
•Produce, Consume,
and Manage Service
Assets
Appendixes
•Rational Asset
Manager
Installation and
Administration
•Process
Integration
Part 4:
Patterns
•Patterns as Assets
•Produce, Consume,
and Manage Pattern
Assets
Figure P-1 An overview of the structure of the book
© Copyright IBM Corp. 2008. All rights reserved.
1
2
Strategic Reuse with Asset-Based Development
1
Chapter 1.
Introduction to Asset-Based
Development
Software delivery has traditionally faced challenges regarding quality and time to market. As
software becomes increasingly intertwined with business success, expectations on the
software organization magnify these challenges. In this chapter, we introduce Asset-Based
Development as a key mechanism for addressing these challenges.
© Copyright IBM Corp. 2008. All rights reserved.
3
1.1 Software delivery challenges
Traditionally, software projects have faced challenges regarding time to market and the
quality of the resulting solution.
Not so long ago, it was taken for granted that investing in a software project provided a
business with a positive impact. This line of thinking disregarded the poor track record of
software delivery in terms of quality and time to market. However, the assumption of
automatic improvement and a willingness to accept failure and unpredictably is no longer the
reality of the business world. Much effort goes into ensuring that the software team is in
alignment with the overall business - recognizing that these projects need to be driven by and
propel the business. More and more pressure is being exerted on the software delivery
organization to ensure that projects deliver on time, at expected quality levels, and with a
predictable and repeatable schedule.
Figure 1-1 provides a view of Business Driven Development - bringing together Business,
Development, and Operations. To provide true value to an organization, these three groups
must work together and have tools and processes in place to support this collaboration.
Business
Senior Executive
Define
Requirements
Model the
Business
Protect
IT Operations
Manager
Architect the
Solution
Analyst
Project Manager
Manage
Application
Support
Manage
Change
& Assets
Deploy
Implement
Architect
Test
Developer
Operations Deployment Manager
Tester
Development
Figure 1-1 Business Driven Development
The software organization must be aware of the issues and concerns that face the business.
For example, Figure 1-2 on page 5 shows results from a CEO survey conducted by IBM. A
key outcome from the survey was that CEOs see innovation as a key to profitable growth.
Software plays a key role in supporting business innovation - ideally, allowing the business to
be agile and flexible. However, a number of external forces are bearing down on the business
and have implications across the organization. So in addition to figuring out how to improve
time to market and the quality of our deliverables, we also have to deal with skill shortages,
regulatory concerns, increasing expectations from clients, and so forth.
Clearly, we need to find better ways to deliver software.
4
Strategic Reuse with Asset-Based Development
Figure 1-2 CEO survey results
1.2 The reuse challenge
Reuse has often been touted as an approach to solving these issues - ranging from copy and
paste of code, reuse of objects, reuse of components, to more recently the reuse of services.
However, we still find ourselves running late on our projects (when we do deliver) and having
poor quality. So while reuse has been seen as an attractive idea, putting reuse into practice
successfully and in a consistent and repeatable fashion has been a challenge. Moving
forward, we have options for how we proceed, including:
Disregard reuse, because it does not deliver success as consistently and repeatedly as
needed.
Reevaluate our approach to reuse and discover a better way to leverage this concept.
Do nothing. Accept that our current approaches to reuse will eventually work.
We need to make sure that we do not dismiss a valuable idea, just because we have not yet
reached a point where it can be applied successfully in a predictable and repeatable manner.
And although doing nothing is a strategy that has its moments, most times that is not the
route to take. Therefore, in this book, we will reevaluate how reuse is approached when
planning to develop a strategic reuse program.
Over the years, we have taken steps forward in regard to reuse. From the previous brief list, it
is clear that creating a service or a component is much better than copying and pasting code.
In addition, it is common to see the use of frameworks, such as Java 2 Platform, Enterprise
Edition (J2EE) and .NET. Unfortunately, this is not enough to provide shorter project time
lines and fewer defects.
Chapter 1. Introduction to Asset-Based Development
5
Unfortunately, we often underestimate the effort and forethought needed in creating a
successful reuse program within an organization. Successful reuse is not something that
happens by accident or by just wishing it to be true. Several aspects that need to be
considered include:
How do we make reusable assets consumable?
How does someone find the reusable asset?
When found, how do you use the asset?
How can an asset be customized for reuse?
Who pays for the creation of an asset?
Who pays to maintain and update the asset?
What reusable assets do we need to build?
Issues, such as those in the previous list, can be thought of as “asset friction”. The higher the
friction level, the less likely we are to succeed in asset reuse. Why does someone spend the
time in figuring out how to reuse an asset if there is no documentation (or the documentation
is of poor quality)? How long can we expect someone to search for an asset before giving up
and deciding that it is quicker to build something from scratch? Our goal needs to be to
create, use, and manage assets with as little friction as possible.
Systematic reuse is defined as: “Systematic reuse is the reuse of assets within a structured
plan with well-defined processes and life cycles and commitments for funding, staffing, and
incentives for production and use of the reusable assets.”1
Strategic reuse builds on the idea of systematic reuse and sees an organization tie its reuse
program to the strategy of the business. Therefore, the strategic reuse program must
implement a systematic approach to reuse that enables the organization to deal with
expertise shortages, globalization, regulatory concerns, rising client expectations, and so
forth.
This book is focused on a best practice-based approach to reuse within software delivery,
known as Asset-Based Development, that will assist in addressing these issues. We do not
contend that this is the “silver bullet” that will fix all of the issues that ail software delivery.
However, Asset-Based Development is a key tool that needs to be found within the tool chest
of all software development organizations (or at least those that want to succeed).
1.3 Value of using assets
In this book, we will look at a wide ranging set of assets. The benefit derived from using a
particular asset depends on a range of factors, including the scope of the asset, the number
of times that the asset is used, the complexity of the target system with which the asset is
associated, the business value associated with the projects that leverage the asset, and a
number of other factors. Therefore, it is difficult to provide a answer to the question “What is
the value of using assets?” In Chapter 6, “Value, impact, and return on investment” on
page 103, we look at the metrics and calculations that you can use to help determine the
costs and benefits associated with assets.
1
6
The definition for systematic reuse comes from Lim, Wayne C., MANAGING SOFTWARE RE-USE, 1st, ©1998.
Electronically reproduced by permission of Pearson Education, Inc., Saddle River, NJ., which references M.
Ogush, “Terms in transition: a software reuse lexicon,” Crosstalk: The Journal of Defense software Engineering,
pages 41-45, Dec. 1992.
Strategic Reuse with Asset-Based Development
In the meantime, rather than just provide an answer of “It depends”, let us take a moment to
review examples that we have come across that highlight the impact that reusable assets can
have within an organization. These results come from a collection of sources, including IBM
internal reuse, IBM client engagements, and experiences from the wider industry.
First, let us look at several results reported from the wider industry:
In Software Reuse: Architecture, Process, and Organization for Business Success2,
Jacobsen et al estimate the following benefits of systematic reuse:
– Time to market: 2 to 5 times reduction
– Defect density: 5 to 10 times reduction
– Maintenance cost: 5 to 10 times reduction
Jeffrey Poulin, in Measuring Software Reuse3, proposes that the Relative Cost of Writing
for Reuse is 1.5. This means that there is an additional 50% cost when building reusable
software. He also proposes that the Relative Cost of Reuse is 0.2. This means that the
relative cost to use the asset is 20% of what it cost compared to having to rebuild the
solution.
In terms of IBM experiences, we can look at a few examples:
Leveraging pattern-based engineering, which is covered in Part 4, “Patterns” on page 455
of this book, a client was able to generate over 50% of the code necessary for a J2EE
solution.
In another case, a composite business service, which is covered in Part 3, “Service Assets
in an SOA” on page 333 of this book, was created for handling New Quotes for Home and
Auto Insurance. A client was able to reuse this Composite Business Service to achieve the
following results:
– Increased top-line growth: Number of personal property quotes increased by a factor of
ten in one year, without adding staff
– Increased asset reuse: 52 percent reuse across initiatives
– Reduced operating costs: Experienced reduction in call center traffic with the reduction
in phone calls, faxes, and paper-based processes benefiting not just the client, but also
reducing costs, improving margins, and enhancing loyalty for partners
In terms of internal IBM experiences, we can look at an example of how an internal
development team leveraged pattern-based engineering. The development team needed to
re-architect a set of servlet-based commands into a set of Web services to support a
separation of application logic from presentation. There were over 100 services that needed
to be created in this manner. An initial attempt at detailing the steps needed to perform the
conversion ended up in a 100 page document. The steps needed to be followed in sequence
and required an individual developer four days to follow. A two day effort was put forth in
creating a pattern implementation that generated in minutes the service infrastructure and
associated test cases. The developers were then able to focus their efforts on adding in the
required business logic.
2
3
Software Reuse - Architecture, Process, and Organization for Business Success. Ivar Jacobson, Martin Griss, and
Patrik Jonsson, page 7.
Measuring Software Reuse. Jeffrey Poulin, pages 25-29.
Chapter 1. Introduction to Asset-Based Development
7
1.4 Asset-Based Development
Asset-Based Development is defined as:
“Asset-Based Development is developing software solutions reusing cohesive, documented
software artifacts. It is organizing software development in a way that leverages previous
investments, and influences the nature of future investments. It is speeding up development,
and reducing cost and risk by reusing assets and artifacts to solve recurring problems.”
Which leads to the next question, what is an asset? An asset is defined as:
“An asset is a collection of related artifacts that provides a solution to a problem. The asset is
customizable through its variability points, meaning those locations within the asset (or more
specifically, within the asset’s artifacts) that can be customized.”
Figure 1-3 provides a visual depiction of an asset. In Figure 1-3, we can see that we have a
number of artifacts with the asset. One or more of the artifacts within the asset might have
variability points. In addition, you will find that the asset provides a solution for a specific
problem within a given content. Also, the asset will have rules that guide how you can use the
asset.
Figure 1-3 An asset as a collection of artifacts
There are several key ideas on which we need to focus:
The artifacts within the asset work together to provide a solution to a problem.
Variability points provide us with ways to customize how an asset is applied. More formally,
a variability point is defined as:
“a location in an asset, specifically an artifact that can be modified or extended as part
of being reused. It is a planned for, controlled extension point of the asset.”
Building on the idea that we often build rather than reuse, a root cause is that we often
overestimate the uniqueness that a problem presents. Having points of variability guides
us to start thinking in terms of separating those elements that are static and those that are
dynamic when we build a reusable version of a solution.
The context in which we reuse a solution is important. Examples of context include:
– Development environment
– Runtime environment
– Reuse scope
– Target Asset Consumer
8
Strategic Reuse with Asset-Based Development
– Business domain
– When in the process the asset is to be used
– Where in the architecture the asset is to be used
– Dependencies: relationships to other assets
– Interfaces provided and consumed
– Services provided and consumed
– Policies compliant and ignored
1.4.1 Asset management
Even if we decide that assets are the right approach, and assuming that we successfully build
the assets, we still have to manage the assets. Associated with the management of assets we
face a number of issues:
Software reuse:
– How are my software assets being used?
– What cost savings are there?
– How can I make sure that my developers have the right, high quality asset easily
available?
Open source management:
– What open source is in use across my company?
– Are the legal approvals in place for all use of it? Is my exposure managed?
IT Governance:
– How do I prescribe and enforce the use of certain architectural standards?
– How do I link my project portfolio to my software assets and architecture?
Web services/service-oriented architecture (SOA) transformation:
– How do I control what projects can create new or access existing service assets?
– What assets in my environment use this service?
– How do I ensure alignment with architecture, standards, and business goals?
1.4.2 Artifacts within reusable assets
At this point, you are likely wondering what sorts of things can be included within a reusable
asset. The short answer is that most anything can be used as an artifact within a reusable
asset. Several examples of the artifacts that can be packaged and used as reusable assets
include:
Models
Design documents
Patterns
Web services
Frameworks
Components
Requirements documents
Chapter 1. Introduction to Asset-Based Development
9
Test plans
Test scripts
Deployment descriptors
Model templates
UML profiles
Domain specific languages
This is a quite a wide ranging, although not exhaustive, list of artifacts - which makes sense
when we think about all of the roles and elements that come together during the delivery of a
software project.
In addition to the artifacts that form the core of the reusable asset, you will find a selection of
additional, supporting artifacts within the asset, such as:
Documentation explanations:
– How to use the asset
– How to customize the asset
– The goals, motivation, and purpose of the asset
Models that provide a visual representation of the elements involved in using the asset
Test artifacts
Build artifacts
These assets are needed to improve the consumability of the asset. If we do not take the step
to make the asset consumable, all of the effort that went into building the asset is for naught.
Remember that the value of an asset will vary depending on a number of factors. Later in
Chapter 6, “Value, impact, and return on investment” on page 103, we will look at metrics,
ROI, and scorecards to help assess the value of an asset. In many cases, the roles, activities,
and deliverables associated with Asset-Based Development can be applied generically
across reusable assets. However, we do find that Service-based assets and Pattern-based
assets stand higher than the other types of assets and require a more detailed examination.
1.4.3 Styles of reuse
We have seen that there can be a wide range of artifacts within an asset and that assets can
be applied to a range of contexts. Taking a more abstract look at how assets are consumed
and used, we have found that there are four major styles of reuse:
Black Box: An asset that is not altered by the Asset Consumer
Gray Box: An asset that is modified using parameters
White Box: An asset whose internals are modified by the Asset Consumer
Glass Box: An asset that exposes internals for evaluation and browsing purposes
As we build assets for reuse, we will want to keep these reuse styles in mind and use them as
guides as we design the asset and as we build the supporting artifacts for consuming the
asset.
10
Strategic Reuse with Asset-Based Development
1.4.4 Packaging assets
To aid in the storing, finding, and consuming of assets, a mechanism is needed for packaging
the asset. The mechanism must allow for the capturing of metadata related to the asset. As
depicted in Figure 1-4, the metadata must capture details, such as the solution that the asset
provides, guidance about how to use the asset, pointers to related assets, and information
that can be used to classify the asset.
Figure 1-4 Metadata to be captured for an asset
In support of packaging assets, we are able to leverage the Reusable Asset Specification - a
standard supported by IBM within the Object Management Group (OMG).
1.5 Asset life cycle
Figure 1-5 on page 12 depicts the asset life cycle, including:
Asset production: Includes the developing and harvesting of project artifacts to be
included in the asset, as well as the packaging of the asset.
Asset consumption: Consuming a reusable asset, which includes locating, evaluating,
applying the asset, and providing feedback.
Asset management: Includes the activity around reviewing and approving an asset, as
well as the supporting workflows focused on Repository configuration, reporting, and
removing the assets.
Asset specification: Describes the content and metadata of an asset to be created and
submitted to the Repository.
Supporting this lifecyle is Asset Governance, whereby governance is the establishment of:
Chains of responsibility to empower people
Measurement to gauge effectiveness
Policies to guide the enterprise to meet its goals
Control mechanisms to ensure compliance
Communication to keep all required parties informed
Chapter 1. Introduction to Asset-Based Development
11
Figure 1-5 High-level view of the asset life cycle
Again, we come back to the idea that successful reuse does not happen by accident. We do
not just happen upon reuse and reap the rewards. To succeed, an investment is made in
enablement, tooling, process, and governance.
1.6 Asset repositories
At this point, we have a basic understanding of what a reusable asset is, what artifacts can be
within a reusable asset, and how to describe and package the asset, as well as the asset life
cycle. A final piece of the puzzle is the use of a Repository to manage working with the
assets.
At a high level, an Asset Repository is used to store and manage access to a set of reusable
assets in support of the asset life cycle mentioned earlier. An Asset Producer will publish an
asset to the Repository when it is ready for review by other people in an organization. After it
is published, one or more people will review the asset and will either approve it or request that
changes be made. When the asset has been approved, the asset will be made available to
other people within the organization who consume assets. The Asset Consumers will be able
to download the asset, provide feedback on the asset, or discuss the asset. At a later point,
the asset might need to be updated or be retired.
Asset Repositories can be specialized to support certain contexts, for example:
A Repository can be used to hold just design and development time-related artifacts.
A Repository can be used to hold just runtime-based artifacts.
A Repository can be specialized to hold assets related to just a certain domain.
A Repository can be specialized to hold assets particular to a certain phase within the
software development life cycle.
12
Strategic Reuse with Asset-Based Development
A Repository can be specialized to hold and manage the assets that define the enterprise
architecture for an organization.
Figure 1-6 highlights the benefits that are expected when we use an asset Repository, such
as Rational Asset Manager.
Improve quality and
reduce cost and time
Promote cross project
reuse of assets
Manage compliance by
governing multi-platform
development assets
Manage and facilitate reuse of
software assets, including
Services used in serviceoriented architecture (SOA)
development
Promote reusable asset
communication and sharing
across disparate multi-platform
projects implementing a
workflow to manage the
usage, updates, and delivery
of assets, avoiding duplication
Enforce and monitor integrity
of development assets with a
definable, enforceable, and
auditable process
Accelerate delivery of
increased quality and
reliability applications
Unify disparate
development teams to
enable reuse and eliminate
unnecessary rework
Enforce and govern
architectural standards,
access, and utilization of the
software assets
Figure 1-6 Reuse trusted assets with Rational Asset Manager
1.7 Reuse success factors
Adopting Asset-Based Development does require change within an organization. The change
includes learning new skills, changes to process, and promoting and living by a new culture
within the organization. As discussed earlier, there are a number of strong and compelling
reasons why you want to switch to using Asset-Based Development.
Having the right process, tooling, and people in place is usually the high-level elements that
are referenced in making change successful. However, that is still somewhat ambiguous. A
more concrete list of the things that you need to consider to help make reuse adoption
successful includes:
Management support: As with most initiatives, it is important to have executive support.
In the case of reuse, this is critical. However, we also find that the development of
reusable assets is most often bottom-up. Therefore, it is important to have top-down
support while implementing assets bottom-up.
Identifying the right asset to build: Next to management support, this is the next most
important factor to consider. In this case, we need to decide what assets must be built. A
strategy that only looks at measuring success based on the number of assets in the
Repository is unlikely to succeed. The correct approach is to measure success based on
the value that assets bring to your organization. When selecting what assets to build, look
for recurring problems and best practices that need to be captured and ensure that there
is indeed a need and a consumer for the solution. An asset that does not get used
provides little value to the organization.
Versioning and configuration management: Typically an asset is composed of multiple
artifacts. As we build, maintain, and then support assets, it is expected that there will need
to be new versions created. We end up seeing that there are two types of versioning that
are needed - one to keep track of the versions of the artifacts, and then as we build and
create the asset that contains the artifact, we will specify versions for the asset.
Chapter 1. Introduction to Asset-Based Development
13
Training for producers and consumers: For reuse to be successful, those people
producing assets must have skills in producing assets that are reusable. The Asset
Consumers need to understand how to find assets, use them in the environments, and if
appropriate, customize the assets for a particular situation.
Measuring productivity and quality: Understanding asset usage, asset quality, and the
cost and impact of assets is key to the program.
Sponsorship and maintenance of assets: Much like a software application, the cost to
maintain and support an asset does not end at the first release. There needs to be a plan
and support for the continued maintenance of the asset.
Communication of asset status to Asset Consumers: The Asset Producer needs to
understand where and how the asset is being used. This will assist the producer in
prioritizing the repair of defects and how to introduce and manage changes to the asset.
Commitment to high quality assets: Without a focus on high quality assets, a
Repository will become a junkyard, a dumping ground for any old thing that might be
reusable. This environment is unlikely to find success as the consumers of assets quickly
learn that it is quicker, easier, and less risky to proceed on their own.
Well-understood domains: Assets are meant to contain and represent best practice
solutions. To be able to build and support such assets, the Asset Producer needs to
understand the domain for the asset.
Customizable, coarse-grained reuse: Successful assets tend to have built-in support for
customization. In cases where there is unlimited access to changing and customizing the
asset, the consumer will find the asset’s flexibility overwhelming and lacking in guidance.
Architectures established to create and use assets: Related to understanding the
domain, we also need to understand the architectures that are targeted by the assets
being built.
Process and organizational structure to support reuse: In order for reuse to succeed
within the organization, there generally must be a team that focuses on manufacturing
assets. The challenge of this is that there are many technology domains for which
reusable assets can be created, and it is difficult if not impossible to have one team that
has all of the experts needed. Therefore, you generally have a core team that understands
the principles of asset manufacturing, and you have visiting experts that join for a time to
give guidance on the development of specific asset types. The enterprise needs to
support this activity of harvesting expert knowledge into reusable assets, when and where
it makes sense to the business.
You will see these factors discussed further as we make our way through this book. In
addition, these factors are built into the development process supported via tooling and
standards.
1.8 Guide to the remaining chapters of this book
This book, as shown in Figure 1-7 on page 15, is comprised of four major parts and a set of
appendixes.
14
Strategic Reuse with Asset-Based Development
Part 1:
Introduction
Part 2:
Reusable Assets
•Introduction to
Asset-Based
Development
•Adopting AssetBased
Development
•Process and
Tooling
•Configuring
Asset
Management
•Case Study
Overview
•Produce,
Consume, and
Manage Assets
•Impact and ROI
Part 3:
Services
•Services as Assets
•Produce, Consume,
and Manage Service
Assets
Appendixes
•Rational Asset
Manager
Installation and
Administration
•Process
Integration
Part 4:
Patterns
•Patterns as Assets
•Produce, Consume,
and Manage Pattern
Assets
Figure 1-7 An overview of the structure of the book
Although we encourage you to read the entire book, we also recognize that different
audiences have more interest in certain areas than other areas. Therefore, we have a short
guide to the contents found within this book:
For an overview of Asset-Based Development, including process, roles, tooling, and types
of assets, read Part 1, “Introduction” on page 1.
For a detailed look at effective asset management, read Part 2, “Reusable Assets” on
page 123.
If you want to build reusable service-oriented architecture (SOA) service-based assets,
read Part 1, “Introduction” on page 1, Part 2, “Reusable Assets” on page 123, and Part 3,
“Service Assets in an SOA” on page 333.
If you want to build pattern-based engineering reusable assets, we have had excellent
results in groups adopting pattern-based engineering as a starting point into an asset
program. This starting point has proven to provide a quick time to market, significant ROI,
and high quality. Detailed guidance covering pattern-based engineering is provided in
Part 4, “Patterns” on page 455:
– After you have succeeded with pattern-based engineering, it becomes easier to invest
in and launch a larger reuse initiative. As your skills in reuse mature and you build
further competency, we encourage you to follow up your patterns experience by
reading Part 1, “Introduction” on page 1 and Part 2, “Reusable Assets” on page 123.
– If you are going to use patterns to build services, read Part 3, “Service Assets in an
SOA” on page 333 as well.
For those people, who want to deploy and administer Rational® Asset Manager, then refer
to Part 1, “Introduction” on page 1, Part 2, “Reusable Assets” on page 123, and
Appendix A, “Rational Asset Manager: Installation and administration” on page 637.
Note that a number of sections in the book discuss topics that in real life happen
concurrently. Unfortunately, it is difficult to present topics in a book concurrently.
Chapter 1. Introduction to Asset-Based Development
15
16
Strategic Reuse with Asset-Based Development
2
Chapter 2.
ZYX Electronics case study
This chapter introduces the case study that is used throughout this book. This chapter
contains these topics:
An overview of ZYX Electronics, the company
ZYX Electronics business capabilities and challenges
Analysis and proposed solution
Assumptions
© Copyright IBM Corp. 2008. All rights reserved.
17
2.1 Introduction
This book uses a single example throughout the book to illustrate the use of IBM tooling and
processes to build and manage reusable software assets. ZYX Electronics (ZYX) will be
reviewed from an outsider’s perspective, analyzed, and provided with a solution direction to
help it achieve higher returns on its software investments through software asset reuse.
ZYX Electronics is a fictitious supplier to retail, small business, and corporate customers. ZYX
has specific goals and constraints that provide a typical set of challenges for the team
implementing an asset reuse approach for software development.
2.2 Overview of ZYX Electronics
ZYX Electronics has approached us to assist in building a reusable software asset
infrastructure solution to meet specific business and IT goals. As part of our initial discussions
with the company, we will interview with the chief officers, CEO and CIO, of the company.
The ZYX Electronics organization will be outlined with the interview results to follow.
2.2.1 Organization
Figure 2-1 illustrates the Chief Executive Officer’s (CEO’s) organizational chart focusing on
Information Technology (IT). Chris, the CEO, has assembled a great executive staff over the
years to run the global operations and IT. Chris hopes this team will help ZYX Electronics
surpass its competition in value, service, and support for many years to come.
Figure 2-1 ZYX Electronics CEO’s organizational chart
Cid Oreo, the Chief Information Officer (CIO) of ZYX Electronics, thinks that he has also
assembled a great team to evolve the technology department past the deep vertically focused
and autonomous development culture currently ingrained within ZYX Electronics into a
18
Strategic Reuse with Asset-Based Development
shared and reusable software development environment. Cid wants to reduce software
redundancy, to reduce the need for software rework, and to help make IT more agile to the
changes in the business environment. Figure 2-2 is Cid’s organizational structure, notably
focused on development.
Figure 2-2 ZYX Electronics CIO’s organizational chart
Within Cid’s department, as outlined in Figure 2-2, a number of team members are involved
by the role in which they align. In our example reference application, the ZYX Electronics
team members who are most pertinent to the development are listed in Table 2-1. This is not
an all inclusive list, but it reflects those who might be referenced in our examples.
Table 2-1 ZYX Electronics development team roles
ZYX employee
Role
Description
Chris E. Oshman
Executive - CEO
Chief Executive Officer for ZYX
Cid I. Oreo
Executive - CIO
Chief Information Officer for ZYX
Chuck T. Offilgy
Executive - CTO
Chief Technology Officer for ZYX
Victoria Prezzio
VP of Development
Directs all development functions at ZYX
Richard Compliton
Director or Risk, Security,
Audit, and Compliance
Directs all activities within ZYX IT related to
risk, security, auditing, and compliance
Patricia Moon
Portfolio/Project Manager
Manages development portfolios and projects
across IT
Duncan Munchkin
Development Manager
Manages the development of a software
application or component
Chapter 2. ZYX Electronics case study
19
ZYX employee
Role
Description
Greg Muldoon
GSI Manager
Manages global system integration for ZYX
Bob Analyn
Business (Service) Analyst
Analyzes and documents the business
processes and functions. Can also help to
identify and reuse assets, such as business
requirements, processes, components,
services, data, and business rules.
Al Aarkashan
(SOA) Architect
Analyzes business needs and goals to create
software architectures capable of supporting
the business. Key identifier of software
development reuse opportunities, both Asset
Consumer and producer.
Deb Devak
(Service) Developer
Implement software and service designs into
executable code constructs. Identifies
software reuse opportunities, both Asset
Consumer and producer.
Donna Archin
Data Architect
Designs and implements data storage.
Identifies reuse opportunities related to
corporate data.
Pam Edison
Process Engineer
Responsible for all aspects of
method/process composition and guidance.
Irene Devin
Service Assembler/Integration
Developer
Integrates components, services, business
rules, and data into executable business
processes. Asset Consumer
Tammy Archin
Test Architect/Manager
Designs and manages testing of software
assets. Identifies reuse opportunities
concerning test plans and test cases, both
Asset Consumer and producer.
Terry Implemian
Service and Process Tester
Creates and executes automated and manual
software test suites.
Rebecca Englo
Release/Build Engineer
Designs, develops, and manages software
releases and automated/manual software
builds across IT.
Deon Adminio
Development Tools
Administrator and Source
Configuration Management
(SCM) Configuration Manager
Configures development tools throughout IT;
administers the source control systems
2.2.2 CEO interview
The CEO of ZYX Electronics, Chris, turns out to have an extremely positive outlook on the
company’s future and has told us this about the company:
ZYX Electronics is a premier supplier to retail, small business, and corporate customers.
The company started in 1935 and has established a well recognized brand and solid
brand image.
Currently, ZYX Electronics employs 11000 people in 900 offices in six countries.
20
Strategic Reuse with Asset-Based Development
Our success is based on a high-touch interaction with customers. Part of this high-touch
approach is that customers can use multiple channels to interact with the company. The
company wants to offer the best customer service at the lowest cost.
ZYX Electronics already has an e-business site with the lowest cost per order in the
industry. We recently acquired Jensen, Inc., and this has allowed us to strengthen our
corporate customer base. We treat our corporate customers as true business partners.
Our goal is to become the most profitable, high-touch company in the industry. Our plans
are to:
– Pursue aggressive growth while minimizing risk
– Optimize our corporate organization to maximize company responsiveness
– Maximize our strategic investments in the best Web site in the industry
– Establish the best sales force in the industry with global Customer Relationship
Management (CRM) and sales-focused call centers
Although Chris has a positive outlook about the direction of the company in general, ZYX
Electronics faces many of the same pressures exerted upon others in the industry (see
Figure 2-3). He expressed concern over the rising customer demands. “Our customers are
very satisfied with our efforts as a supplier, but their expectations for better service and
delivery continue to rise. Our customers aren’t complacent, and nor can we be.”
As noted in Chapter 1, “Introduction to Asset-Based Development” on page 3, CEOs are
experiencing pressures, such as rising customer expectations, commoditization of products
and services, and a “shrinking world”, which means that they have customers everywhere
around the globe, which brings in additional regulatory concerns internationally and which
has intensified the competition. ZYX Electronics is no exception to these pressures.
Figure 2-3 CEO survey
Chapter 2. ZYX Electronics case study
21
Internally, ZYX is also experiencing the pressures of industry technology advances. Chris is
concerned whether they can surpass, can keep up with, or will be passed by the competition.
As you can see in Figure 2-4, over the last three generations of basic technology
advancements in tools, components, and processes, software development organizations are
adopting the processes and tools that gain them efficiencies in project performance and
success. Projects are creating more reusable assets and involve writing less custom code
with more skilled labor.
Figure 2-4 Software governance: generations of basic technology advancements1
Chris needs ZYX Electronics to mature out of the 90s by encouraging the organization to
adopt these sought after software practices and governance techniques. Keeping the
competitive edge through business and IT is foremost to Chris.
2.2.3 CIO interview
The CIO of ZYX Electronics, Cid, is slightly less optimistic and clearly has had a difficult time
in the last few years. Cid plans to address many of the issues head-on and we are part of that
plan. Cid’s view on the company is:
We cover multiple market segments through multiple channels. The integration with
Jensen, which we started in 2000, is still in progress.
We have six call centers, eight data centers, and about 2000 IT staff.
We have a mixture of:
– “Build versus buy” applications in SAP®, Siebel®, CICS®, and batch applications
– Existing applications for core accounting and order entry written in multiple languages,
such as Java/J2EE and C++
– Applications that we acquired as part of the Jensen purchase have yet to be integrated
– A new CRM system is still being implemented and we must add analytics
– Multiple platforms and a heterogeneous topology
1
22
Figure 2-4 data is taken from the presentation “IBM Software Group Executive Forum” used with permission by Dr.
Daniel Sabbah, Rational Software.
Strategic Reuse with Asset-Based Development
We use both our employees and outsourced resources across multiple development
locations in several countries, with the US and Europe as core development centers
To be frank, we have very little reuse of components and skills across the company. This
is something I need to address:
– Components are created to address specific application needs, but no one wants to
spend the time to harvest what we have or make the effort to understand how to reuse
what is available.
– We have a tendency to rewrite common componentry over and over again.
– We are not using common approaches to common software constructs.
As we transition to a service-oriented architecture (SOA), where service reuse is key, we
have a series of challenges ahead:
– We set up a department to support shared services. HR was first, and SAP Enterprise
Resource Planning (ERP) was next, but it took a long time to complete (it came from
Jensen). CRM is the current project.
– We have a single database, but we still keep information in different schemas
according to the area of business to which they relate. There is a resistance to sharing
customer information across the lines of business (LoBs).
– We have no common terminology and cannot get the LoBs to agree. Before we can
implement SOA or make much use of reuse on a large scale, we have to get the LoBs
aligned, normalizing their requirements and designing services with the right level of
granularity.
Of our 2000 IT staff, over 1000 are developers using more than 40 various development
tools and environments.
We have no end-to-end development methodology. And, governance is a huge issue that
we have to address. You have heard about our business technology optimization
program. This will support a major development based on SOA, and without proper
governance, we will not know what services we have developed, who is responsible for
each one, or which applications are using them.
Thankfully, we have identified the key business processes that need optimization. We do
have a good idea of the current processes in this area and how they have to look. Fixing
these key business processes will help us achieve our business goals.
As you can see here, Cid understands the internal and external pressures on the ZYX
Electronics information technology department to stay current with the demands of the
business and to be flexible to respond quickly to its requests. Chris and Cid have discussed
the statistics related to corporate technology advances (see Figure 2-4 on page 22). Lagging
behind the technology adoption curve is a concern that must be addressed.
2.2.4 Business composition
It is important for ZYX Electronics to understand its business structure in a prescribed
manner. A well-documented business structure aids in the understanding of business
competencies and capabilities and how they are used and reused across the organization.
We are not just describing the business as seen by the customer community and how the
customer interacts with the organization, but also the structure within the ZYX Electronics
organization itself and how the business is executed.
Being able to understand the way in which ZYX approaches the execution of its business
practices and functions helps ZYX to organize its IT department and to build development
practices which align with the true nature of the business. Through service engagements at
Chapter 2. ZYX Electronics case study
23
IBM, Global Business Systems specialists help organizations to decompose themselves into
an organized view of the business, segmented by business competencies, accountability,
and business components. The outcome is called a Component Business Model™.
In reviewing Figure 2-5, the Component Business Model Heat Map (the highlighted items are
the “hot” areas to be addressed by the business) for ZYX Electronics, you can get a grasp for
the company’s key Business Competencies, which are those items listed on the top edge of
the diagram as the column headers, that is, Business Administration, Product Management,
Customer Acquisition, and so forth. Business competencies are defined as large business
areas with characteristic skills and capabilities.
Figure 2-5 ZYX component business model heat map
In further examination of ZYX’s Component Business Model2, the row headings in the left
edge column of the diagram enumerate the scope and intent of activity and decision-making
using Directing, Controlling, and Executing. Directing is about strategy and overall direction
and policy. Controlling is about monitoring, managing exceptions, and tactical decision
making. And Executing is about doing the work.
The remaining area within the Component Business Model accounts for ZYX Electronics
business components related to business competencies and accountability. Business
components are the parts of ZYX Electronics that have the potential to operate independently
or as part of the company as a whole.
2
24
Component Business Model information was gathered through Franco Potepan of the IBM World wide SOA
Technical Sales team from a presentation developed by Mark Sower and Mary Etta Cope in 2006.
Strategic Reuse with Asset-Based Development
Looking back at Figure 2-5 on page 24, let us point out a few of the business components that
are highlighted as core to ZYX Electronics’s business optimization effort. As a “heat map”, the
highlighted items are the “hot” areas to be addressed by the business:
Account Administration:
– Automating the manual tasks for creating and administering accounts will:
•
Decrease the cost of account activation by 50%
Credit Administration:
– Centralizing “siloed” departments and building optimized services to support the
converged organization and then negotiating better prices with our vendors while
taking advantage of our combined size will help us:
•
Decrease the negotiated cost (vendor volume discounts) of credit report retrieval by
20%
•
Automate 75% of all credit report retrievals
– Implementing consistent business rules to manage risk will:
•
Decrease the number of credit report retrievals by 10%
Sales:
– Converging an optimized cross channel account application process will:
•
Increase the cross sell ratio to 2.0
•
Add 500 new corporate customers
•
Improve the straight through processing (STP) of applications by 35%
•
Reduce number of call center calls by the sales force and offices by 30% (account
inquiry)
Document Management:
– Decreasing the number of paper documents processed by task automation will:
•
Increase electronic applications by 25%
Understanding ZYX Electronics in this manner will help the CIO and the development
department structure themselves to support the CEO’s goals. In addition, structuring
development in this fashion will provide ZYX Electronics a head start in defining reusable
business functions.
2.3 Challenges
ZYX Electronics, such as many companies, faces challenges with its current organizational
capabilities pertaining to software delivery and the reuse of its software and assets. In this
section, we will look at the challenges of ZYX Electronics’s business processes as pointed
out by its Component Business Model. We will also review IT’s challenges and have Cid’s
management team formulate a few thoughts about what will need to be addressed pertaining
to the company’s Reuse Strategy.
Lastly, we will elaborate on reuse challenges in the software industry. ZYX is not alone in
their lack of a Reuse Strategy. Software reuse incurs greater costs than traditional software
development. Reuse is not free. It must be planned for and does not occur automatically
during normal software development practices. Reuse takes additional time and resources to
identify, document, and govern.
Chapter 2. ZYX Electronics case study
25
2.3.1 The business
As a team, we need to be quite cognizant that the investment in IT is based on providing
value to the organization. In addition to ensuring that we are improving the capability and
capacity of the IT department, we also need to ensure that we are building solutions that
support the business. To this end, let us first look at several of the problems facing the
consumer business applications.
Opening an account is one of the key business processes targeted for improvement and
automation. This process covers four functions in the business: Account sales, account
application, account verification, and account activation.
We capture the key issues for each business function:
Account sales issues are:
– Account application processing delays: Customers want to use their accounts as soon
as possible.
– Account status is unavailable while the account is being set up: The business cannot
answer customer queries about how the account application is progressing.
Account application issues are:
– Complex application forms
– Different formats and information required for applications for different products, when
the applications can use the same format
– Errors due to re-keying of information. Information is re-keyed from paper applications
as well as between various, disconnected systems.
– Lack of single customer view. There are multiple systems that include customer and
account information at the company. The primary system is an operational CRM, which
is considered to be the master source of data for customer name, address, and
relationship information.
Account verification issues are:
– No single, consistent view of the customer
– Too many customer applications are declined because of different regional credit
scoring policies.
– Credit checks are faxed or called in to the credit checking agency. This takes too long
and is too expensive.
– Too many applications are referred for credit checks.
Account activation issues are:
– Manual updates to multiple systems are required to activate the account. The data is
re-keyed into the ERP system, a data warehouse, and a billing system.
2.3.2 Information technology
With the business focusing on the “right” competencies and components that add the most
value for growth, IT has to address its particular software development and delivery capability
shortcomings. Over the years, ZYX Electronics has been focused on monolithic applications,
each department autonomous in its development and delivery efforts. Communication across
departments has been shaky at best and usually brought about by the business units forcing
software application team interaction.
26
Strategic Reuse with Asset-Based Development
Let us recap several of the major issues Cid told us in the CIO interview related to software
reuse:
“To be frank, we have very little reuse of components and skills across the company and
this is something that I want to address.”
“We have a tendency to rewrite common componentry over and over again.”
“As we transition to a service-oriented architecture (SOA), where service reuse is key, we
have a series of challenges ahead...(support for shared services)...(shared data)...(LoBs
aligned)”
“...(for) reuse on a large scale, we have to get the LoBs aligned.”
“We have no end-to-end development methodology. And governance is a huge issue that
we must address...”
ZYX uses 40 plus development tools
Cid is deeply concerned about IT’s ability to implement software reuse. Because ZYX has no
Asset-Based Development methodology, education on reuse is unavailable. This means
skills to identify, create, or reuse assets are lacking. And when reusable software assets are
identified, no governance mechanisms are available to determine and document who will be
responsible for maintenance, funding, quality of service, monitoring, and so forth.
Development staff are not motivated to identify and reuse software assets, either. Most
developers instead want to copy a chunk of code to customize as necessary for the
application situation. Copying code can cause maintenance nightmares if the code logic was
incorrect from the beginning.
Cid has serious work ahead of him in order to address these challenges. As we work with Cid
to identify the most pressing concerns, we can help Cid develop and focus on a number of
key IT objectives:
Speed up the delivery of software systems and yet:
– Meet or beat the agreed upon delivery dates
– Reduce development costs and stay within the agreed upon budget
– Deliver high-quality products
– Meet business goals and objectives
Provide IT assets that are more flexible to the constantly changing needs of business and
reusable across application boundaries
Restructure IT to achieve the component sharing that we need to add business flexibility,
value, and reuse of software assets
Integrate development efforts across application boundaries to help eliminate or to reduce
writing the same business functions multiple times
Determine what Asset-Based Development methodology, governance practices, skills,
and expertise that we can acquire, create, or educate to develop a software infrastructure
capable of aligning IT with the business and getting the most use and quality of each
software asset that we create
Cid is determined to upgrade the IT department practices and capabilities in order to
positively impact business value in turn helping to drive an increased revenue stream for
ZYX. Through these efforts, Cid wants to shorten application time-to-market and improve the
quality of all applications. And lastly, Cid wants these applications to incorporate the business
functionality necessitated by our customers. Cid wants true IT alignment with the business
and with our customers.
Chapter 2. ZYX Electronics case study
27
2.4 Scope and approach
Chapter 1, “Introduction to Asset-Based Development” on page 3 provided a vision into the
challenges behind software reuse, such as making reusable assets consumable and finding
the right asset to reuse. The chapter further introduced Asset-Based Development and
concepts behind asset management and the life cycle of assets.
So far, this chapter has explored the ZYX Electronics organization, provided CEO and CIO
interview feedback, decomposed their business structure, and reviewed both the business
challenges and IT’s software asset reuse challenges.
Now, it is time to bring these two chapters together into something meaning to ZYX
Electronics. It is time to scope out the ZYX Electronics asset reuse plans and begin to
formulate an approach to resolve their asset reuse challenges.
2.4.1 Scope
As described by the CEO earlier in this chapter, the goals are to pursue aggressive growth,
provide quick response to changing business needs, and to maximize our strategic
investments. The customers expect better service from ZYX. Better service means better
software systems delivered on time, in high quality, and functioning as needed.
The ZYX Electronics IT department now has to step up its capabilities to respond to the
business. Implementing an asset Reuse Strategy is a start, but the employees must be
committed in order to make it work. Producing software assets identified for reuse and then
reusing them requires dedication, resources, time, and money for it to succeed.
In the CIO interview, Cid articulates the need for an end-to-end methodology, software asset
reuse and governance, shared services, LoB alignment, and streamlined toolset. Cid is fully
aware the challenges ahead and is ready to scope the initiative. First of all, it is not just an IT
problem. This is a business problem, too. Introducing the ZYX Electronics organization and
Component Business Model was to provide an outline of the business functions or
components. Business components can be stand-alone or work together to accomplish a
greater need.
Components become candidates to be broken down into finer grained functionality that we
will call tasks, for simplicity. Tasks perform very specific duties within a software system. At
this level, we begin to see greater reuse opportunities where a task can be reused across
different components in order to provide identical duty without rewrite.
Seen in this way, components and tasks are the more obvious reusable software assets, but
they are identified by aligning IT architecture and design with business competencies. At IBM,
we call this a Business Driven Development approach. Again, first of all, the business is in the
scope of our asset reuse vision.
The other side of this scope is, of course, the IT department. IT develops the systems that the
business uses to manage its business and the systems that its customers, partners, system
integrators, and so forth use to interact with the business. These systems are at the center of
the microscope with respect to reuse.
And in the midst of both the business and IT, we insert an Asset-Based Development
methodology, which guides the organization through asset identification, specification,
production, consumption, and management. Asset-Based Development is a work product or
instantiation of the Asset Governance processes that are defined by ZYX Electronics.
Governance is the critical success factor in Asset-Based Development.
28
Strategic Reuse with Asset-Based Development
Reuse can be approached in a number of ways, which we will describe later. At this point, Cid
will ask the IT team to look at existing system implementations, as well as at new applications
for reuse opportunities.
ZYX Electronics is limiting the initial scope of their Reuse Strategy and efforts to:
Software requirements: functional and non-functional
Architectures and designs, including models, transformations, and patterns
Interface specifications and other documentation
Specific code constructs and patterns
SOA-based services
Test plans and test cases
The book might not address all of these reuse opportunities, but it is a good list for ZYX to
start with and to be aware of in their development efforts.
2.4.2 Approach
Cid has scoped the asset reuse effort; now, he must lay out how he intends to approach
resolving the asset reuse challenges. From all that we have learned thus far in this book,
implementing and enforcing an entire methodology and the tools to automate and measure
results in a single sweep across the organization are a guaranteed way not to succeed.
People instinctively do not accept change gracefully, especially a lot of change at one time.
Approaching this initiative with an incremental and iterative approach, slowly implementing
the methods and tools, will provide a much higher chance of success. The ROI will come at a
slower pace, but it will increase as the number of reusable assets are identified, developed,
and consumable.
Before we take on outlining an iterative approach, consider that to meet our objectives and
stay within scope, the following points must be kept in mind while developing the approach:
Software development methodology
End-to-end method for guiding software and systems development
Asset-Based Development methodology
Guidance in producing, consuming, and managing reusable assets
Asset governance to:
– Create initial governance plans and document decisions, roles, and responsibilities
– Determine how we will implement the plans and decision rights
– Implement the plan through process education, mentoring, and automation
– Measure reuse activity, assess cost, and ROI
Streamlined tools:
– Store, search, and retrieve reusable assets
– Enforce review processes and asset life cycle
– Reports to measure statistics, such as usage, searches, and reviews
– Reports for auditing assets
– Make it easy to produce and consume reusable assets
Skill growth through education: both methodology and tools
Chapter 2. ZYX Electronics case study
29
Each item in the list aligns with the key challenges that Cid revealed during the original CIO
interview, which we described earlier in the chapter. And, each item impacts the staff. As Cid
is planning the approach, Cid must be sensitive to the changes that the department will be
experiencing. Process and tool adoption taken slowly and methodically from project to project
can have a significant positive impact on software results and quality. Conversely, both
process and tool adoption can be productivity inhibitors if no education and mentoring are
provided to advance individual skills.
Cid can now have the management team begin to lay out a Reuse Strategy implementation
plan. He reminds the team that the company has budget constraints within which to work and
that he is a little sceptical whether reuse will work well for ZYX given the currently ingrained
culture.
Chuck, ZYX CTO, and Victoria, VP of Development, direct a team from the project
management office to create an iterative and incremental (phased) asset reuse approach.
They will need to report back to Cid on the perceived benefits and ROI that ZYX will receive
from this effort.
The approach that they develop will be iterative in that it will build the team’s skills and
capabilities slowly at a satisfactory maturation rate within increments (phases) over several
phases until the entire defined solution is deployed. The outline of the plan is:
Establish a methodology team to establish a ZYX software development (SD) approach
using the Rational Unified Process (RUP). This “virtual” team will be made up of existing
personnel, who are the most skilled in process. These employees will establish process
requirements for ZYX, customize a software development process to meet their
requirements, provide process education, and mentor project teams along the way to
reduce the risk of failure.
Establish an Asset-Based Development and governance (ABD/G) team to establish the
ZYX approach. This “virtual” team will be made up of existing personnel, who are skilled
software architects from around IT. The team will establish ABD and governance
requirements for ZYX using the Rational ABD and Asset Governance method, provide
education, and mentor project teams to reduce the risk of failure.
Implement streamlined tooling to support our methodology, governance, SOA, and asset
reuse efforts.
Continue building out our development capabilities to support the adoption of SOA with a
business fabric that can support our Component Business Model and the dynamic nature
of our business, while reusing our existing software assets to help reduce the cost of new
applications.
Pilot a project to focus on process usage and refinement, tool selection, automated
metrics gathering, and building the skills of our development team at producing,
consuming, and managing reusable assets.
Using this level of plan, the management team is able to build out a detailed phased plan over
several years. Before presenting the details, though, the team wants to ensure that Cid is
aware of the benefits that he will receive by implementing the team’s plan.
2.4.3 Benefits
Cid and the management team will be moving forward on their plans. He has met with the
CEO and CTO to discuss the plans, and they agree that a reuse initiative will be a lot for the
business to consume, but it will have significant ROI in the long term.
30
Strategic Reuse with Asset-Based Development
As the development team becomes skilled in asset production and consumption, ZYX will:
Reduce the costs of new application development and existing application maintenance
significantly through reuse instead of rewrite
Develop repositories of searchable software assets reducing the time to locate and reuse
the asset, in turn helping to reduce the cost of implementing that piece of application
functionality
Increase the standardization of application “look and feel”, providing a more consistent
experience to our users
Increase application dependability and quality, because the software components,
services, models, and frameworks will have been proven and tested already in working
systems
Focus on leveraging individual expertise by bringing the employees together to build or
harvest the reusable assets in their realm of knowledge
Bring our applications to market earlier, therefore, capitalizing on early entry in the market
to bring more sales and revenue to the company
Reduce the time necessary to reuse a software asset as we refine how to reuse the asset
from project to project, therefore, estimating projects with greater accuracy
Our continued efforts to develop our SOA capabilities will play a larger and larger part in our
Reuse Strategy and deliver even more benefits than we have described. Our increased
capabilities will allow us to:
Change business systems, which dynamically decreases the time to application
availability
Decrease the time-to-market by deploying applications quicker
Choreograph multiple deployed business services and Composite Business Services
together to produce the “right” business solutions more efficiently
Preserve existing IT assets by encapsulating them into dynamic business services
Enforce consistency of business and IT behavior across the company
Control IT costs and help make IT more efficient
As Cid can see, enabling ZYX Electronics software reuse capabilities can yield multiple
benefits to the company. The remainder of this book will focus on many of the ways that you
can make use of processes and tools to enable your software reuse capabilities.
2.5 Assumptions
In the following chapters of Part 1, we will discuss tool selection, the Asset-Based
Development method, Asset Governance, and metrics and ROI.
In an effort to limit the scope of this book, we have made the following assumptions about our
work at ZYX Electronics:
ZYX Electronics is not undergoing a complete organizational business transformation. We
undertake what RUP® calls business improvement - the techniques that a company uses
to design its business according to specific goals involving trimming costs and lead times
and monitoring service and quality.
We do not assess the organizational structure; although, we have discussed it in detail,
and we do not make changes to that structure.
Chapter 2. ZYX Electronics case study
31
We do not assess the business structure; although we have discussed it in detail, and we
do not make changes to that structure.
We limit ourselves to analyzing a subset of the ZYX Electronics business problems but
only in respect to the topic of the book, Asset-Based Development.
Lastly, we do not offer or provide a full process and tools implementation. The purpose is
to provide guidance in helping you understand and begin to plan your implementation.
32
Strategic Reuse with Asset-Based Development
3
Chapter 3.
Tools in support of Asset-Based
Development
When applying reuse within an organization, we want to leverage automation, tooling, and
best practice guidance. IBM creates a number of tools that can be used to fill these needs. In
this chapter, we will look at these tools, providing an overview of the tool and the role that it
plays in a strategic reuse program.
If you are already familiar with these tools, you can safely skip ahead to the next chapter. For
those unfamiliar with the tools and the roles that they play, this chapter is a quick read and will
help you understand how the tools come together in Asset-Based Development.
3.1 Overview of IBM tools
When looking at the tools involved in Asset-Based Development, we quickly find that there
are a great number of tools. As you might recall from our earlier discussion, the artifacts that
can be contained within an asset are both numerous and wide-ranging. Although not listed,
there is an equally long list of tools that can both produce and consume artifacts associated
with reusable assets. In this chapter, we will focus on a subset of the available products from
IBM.
Figure 3-1 on page 34 provides an overview of the subset of tools we will discuss, as well as
several relevant roles. At the center of this discussion is the Rational Asset Manager, a key
product that assists us with consuming, managing, and governing the use of assets in the
enterprise.
We can look at the tools from a number of perspectives, including the scope and capabilities
of the tool or the role using the tool. Regardless of the perspective that we choose, it is
important to note that the tools, even when supporting a number of roles, do not live and
operate in isolation.
© Copyright IBM Corp. 2008. All rights reserved.
33
Figure 3-1 Tools, tasks, and roles
Process
management
FOCUS
Tooling selection to support software innovation and IT and Business alignment is a critical
success factor. As shown in Figure 3-2, we can look at the tooling and process needs of the
organization from both a scope and focus perspective. If the selected tooling does not provide
alignment, control, and efficiency, we end up with barriers to innovation and an inability to
align with the business.
ƒ Manual, error-prone
processes with poor
coordination and
automation
ƒ Brittle, inflexible
architectures with
unreliable integrations
Project
management
Software
delivery
Resource
availability
ƒ Lack of alignment
between business
needs and
software results
ƒ Lack of traceability
between requirements ƒ Lack of visibility
and deployed solutions and accountability
ƒ Chronic project
management problems
ƒ Poor software
quality
ƒ Development
productivity/turnover
SCOPE
Individual
Team
Figure 3-2 Barriers to innovation
34
Strategic Reuse with Asset-Based Development
Organization
Business
3.2 Eclipse
Eclipse is a platform engineered to build integrated Web and application tools for
development. The platform encourages rapid development of integrated features based on a
plug-in model. Eclipse is more than a foundation for development, it is:
A Java development environment:
– The Java development environment in Eclipse makes you productive by automating
mundane and time-consuming operations. It integrates with advanced tools to help you
generate, edit, and navigate your Java code.
– The platform handles the logistics of finding and running the right code. The platform
user interface (UI) provides a standard user navigation model. Each plug-in can then
focus on doing a small number of tasks well.
A tool integration platform
Eclipse is a foundation or technology platform for tool integration. Think of it as a home for
tools. It brings together designing, programming, testing, and drawing tools. As you work
your way through this chapter, note that a number of the tools leverage Eclipse as their
underlying platform. As a result, the user interface is consistent across the tools; the tools
support multiple platforms; and, it is possible to integrate other components into the
products.
An open source community
Eclipse.org is a group of technical professionals who use and produce not only the basis
for tool integration, but also a set of tools integrated on that base or platform. Eclipse is an
open source project that delivers a tool integration platform and tools in a package called
the Eclipse SDK.
More information regarding Eclipse can be found on the Web site:
http://www.eclipse.org
3.3 Rational Modeling Platform
The Rational Modeling Platform contains a set of related Model Driven Development tools.
The tools share a common set of features, as well as specializations depending on role and
target applications. The three products that comprise the platform include:
Rational Software Architect: IBM Rational Software Architect is an advanced model-driven
development tool. It leverages model-driven development with the Uniform Modelling
Language (UML) for creating well-architected applications and services. It includes all of
the features of IBM Rational Application Developer for integrated design and development
experience and exploits the latest in modeling language technology, enabling flexible
modeling across a variety of domains, including UML 2, UML-like notation for Java, and
more.
Rational Software Architect extends the Eclipse 3.2 open and extensible software
development environment and enables flexible model management for parallel
development and architectural refactoring, for example, split, combine, compare, and
merge models and model fragments.
Rational Software Architect eases the transition between the architecture and code with
model-to-model and model-to-code transformations, including reverse transformations,
along with design-to-code experience for Java/J2EE, Web Services, service-oriented
Chapter 3. Tools in support of Asset-Based Development
35
architecture (SOA), and C/C++ applications. It includes transformations to support the
development of SOA solutions and more.
Rational Software Modeler: Rational Software Modeler provides a subset of the
capabilities of Rational Software Architect, the most notable of which is the exclusion of
the features provided via Rational Application Developer. In addition, the pattern
implementations provided in Rational Software Architect are not found in Rational
Software Modeler; however, the tooling to build your own pattern implementations is
provided.
Rational Systems Developer: Similar to Rational Software Modeler, Rational Systems
Developer provides a subset of the capabilities of Rational Software Architect. It also does
not include any features provided by Rational Application Developer. However, it does
include a number of pattern implementations that you can leverage in working with Java
and C/C++ development.
3.3.1 Rational Application Developer
Rational Application Developer is the tool for developers; it includes all of the development
features, such as Web development, J2EE development with EJBs, Web services
development, JavaServer™ Faces (JSF) development, UML visualization, component
automated test, and runtime test environments, such as WebSphere Application Server.
3.4 WebSphere Business Modeler
IBM WebSphere Business Modeler Version 6.0 provides business professionals with
easy-to-use tools to design, improve, and communicate complex business processes.
Tailored for individual user requirements, IBM WebSphere Business Modeler Basic offers
entry-level modeling capabilities that allow companies to capture processes at a lower cost
per user. IBM WebSphere Business Modeler Advanced provides advanced modeling
capabilities for advanced users and delivers sophisticated simulation and optimization
capabilities that enable you to analyze the operational efficiency of business processes and
potential business results - all before committing resources to development and deployment.
Through WebSphere Business Modeler Advanced and WebSphere Business Modeler Basic,
you can model the processes that can help you reap the full benefits of on demand business
and the flexibility that you need to support and enable the world of integrated business
processes.
IBM WebSphere Business Modeler Publishing Server Version 6.0 enhances WebSphere
Business Modeler by providing a way to publish business processes and related business
information, such as organization diagrams, to a secure Web site. This capability supports the
development, documentation, and dissemination of business process models on an
enterprise and worldwide scale.
3.5 WebSphere Integration Developer
WebSphere Integration Developer is a common tool for building SOA-based integration
solutions across WebSphere Process Server, WebSphere Enterprise Service Bus (ESB), and
WebSphere Adapters. It simplifies integration with rich features that accelerate the adoption
of SOA by rendering existing IT assets as service components and encouraging reuse and
efficiency.
36
Strategic Reuse with Asset-Based Development
WebSphere Integration Developer enables integration developers to assemble complex
business solutions - processes, mediations, adapters, or code components - requiring
minimal skills. It enables the construction of process and integration solutions using
drag-and-drop technology without requiring a working knowledge of Java.
The rapid assembly of business solutions is possible by wiring reusable service components
into an executable business process and enabling Business-Driven Development through
integration with WebSphere Business Modeler to import models for rapid implementation.
3.6 Rational RequisitePro
RequisitePro® is a requirements management tool. It stores requirements (and related
information) in an underlying database and provides an easy-to-use (client or Web) interface
to sort, search, filter, and track dependencies between those requirements. RequisitePro
allows for the description of requirements in Microsoft® Word, which can then be stored in the
RequisitePro database (using RequisitePro menus from under Microsoft Word). The
database stores requirement details (attributes, links to other requirements, discussions, and
revision history) while documents display the requirement text and context.
Rational Software Architect allows for RequisitePro requirements to be browsed, modified, or
created (from within Software Architect, under the Requirement perspective). More
importantly, design elements can be created from requirements, or existing design elements
can be linked (traced) to requirements.
RequisitePro allows you to record how design decisions address requirements and then to
analyze a requirements trace, including assessing the impact on the design of a change in
the requirements.
In addition, RequisitePro can be used in combination with WebSphere Business Modeler to
ensure that the needs of the business are being captured and understood. When starting a
project, the business, including executives, analysts, and architects, can use RequisitePro to
record the high-level business needs.
The high-level business needs can take the form of goals, including objectives and strategy,
as well as business rules. As the project moves forward, you can use WebSphere Business
Modeler to add details to the business goals, modeling them as processes, and then use
simulation and cost comparison reporting to help the business understand the return on
investment (ROI). RequisitePro can be used to add business operational details, capturing
both functional and non-functional requirements. A key aspect of capturing these additional
details within RequisitePro is to find a balance between the needs of the business and the
architecture.
3.7 Rational ClearCase
IBM Rational ClearCase® provides management and control of software development
assets. It provides controlled access to software development assets across the full life cycle.
Sophisticated version control, automated workspace management, parallel development
support, baseline management, and build and release management improve productivity and
operational efficiency.
Heterogeneous, cross-platform support for distributed, mainframe (IBM z/OS®) and midrange
(IBM i5/OS®) development enables platform flexibility and enterprise-wide application
Chapter 3. Tools in support of Asset-Based Development
37
development. Security features, such as user authentication and audit support, help meet
internal and external compliance requirements.
ClearCase scales from small workgroups to geographically distributed enterprises. It is
accessible through local, remote, and Web interfaces, and leading integrated development
environments (IDEs), including IBM Rational Application Developer, IBM WebSphere Studio,
Microsoft Visual Studio® 2005, and the Eclipse framework.
ClearCase integrates seamlessly with IBM Rational ClearQuest® for a comprehensive
software change and configuration management solution and contains in-depth integration
with requirements, development, and build, test, and deployment tools to provide a complete
end-to-end solution to meet current and future needs.
3.8 Rational ClearQuest
IBM Rational ClearQuest automates and enforces development processes for improved
effectiveness. ClearQuest offers process automation, reporting, defect and change tracking,
and life cycle traceability for better insight, predictability, and control of the software life cycle.
Predefined workflows ship with ClearQuest and can be easily customized to meet specific
needs. Real-time status and reporting improve visibility, and defect and change tracking
manage issues throughout the project life cycle.
ClearQuest manages all development and test assets in a single integrated solution that
improves communication and coordination between development and testing teams. The
product is accessible through local and Web interfaces and leading IDEs, including IBM
Rational Application Developer, IBM WebSphere Studio, Microsoft Visual Studio 2005, and
the Eclipse framework.
3.8.1 WebSphere Studio Asset Analyzer
IBM WebSphere Studio Asset Analyzer for Multiplatforms, Version 5.1 helps you maintain,
extend, and transform existing applications through rapid application understanding and
impact analysis and provides management information for making informed decisions about
application projects. You can use the information provided by this product to modernize your
existing enterprise assets.
WebSphere Studio Asset Analyzer scans mainframe and distributed software assets, storing
related application information in a DB2® Repository that resides on the mainframe. You do
not have to download your mainframe application inventory to a workstation, nor do you have
to upload your distributed application inventory to a mainframe.
WebSphere Studio Asset Analyzer scans the source where it resides, whether in partitioned
data sets (PDSs) or partitioned data sets extended (PDSEs) on the mainframe, directories on
Windows® or AIX® systems, or in one of a number of Source Configuration Management
(SCM) systems.
WebSphere Studio Asset Analyzer also includes metrics for mainframe assets, such as
Halstead and McCabe’s Cyclomatic Complexity and Essential Complexity, as well as more
application-level reports. Together, these metrics provide the information that you need to
help you understand the relative complexity of applications and to estimate the effort required
for a given project. Also, with Version 5.1, you now have the ability to use the open-metrics
framework of WebSphere Studio Asset Analyzer to programmatically calculate and store your
own metrics with the inventory.
38
Strategic Reuse with Asset-Based Development
3.9 Asset repositories
Next, we discuss asset Repository products.
3.9.1 Rational Asset Manager
Rational Asset Manager is a collaborative software development asset management solution
that helps organizations to create, modify, govern, find, and reuse any type of development
assets, including services as part of a service-oriented architecture (SOA) initiative and
systems development assets. It reduces software development costs and improves quality by
facilitating the reuse of all types of software development-related assets.
Rational Asset Manager reduces development time and cost and enhances architectural
integrity through the reuse of software assets. It unifies disparate teams and eliminates
rework by providing secure asset tracking and by managing asset and artifact
interdependencies and relationships. The software also helps you to monitor asset integrity
and utilization through a defined, enforceable, and auditable process that includes
fine-grained permissions and review approval workflows.
Secure intellectual property sharing in Rational Asset Manager helps lower costs and
decrease the complexity of compliance. Rational Asset Manager improves governance with
easy discovery and federated search across the SOA life cycle and stores information that is
useful for collaborating on the software development of assets.
To support asset management scenarios, Rational Asset Manager manages asset metadata,
such as the asset’s name, description, version, and state, as well as the name, description,
version, and reference (or location) of contained artifacts. To help you reduce development
costs and time while improving software quality, Rational Asset Manager supports the
Reusable Asset Specification, an industry standard from the Object Management Group.
Rational Asset Manager integrates with other Rational and IBM software tools, including IBM
Rational ClearCase, IBM Rational ClearQuest for change management, and IBM Rational
architecture management software for asset development. To help you manage SOA assets
at run time, Rational Asset Manager closely integrates with IBM WebSphere Service Registry
and Repository software.
Rational Asset Manager is focused on managing software development assets, but because
the Reusable Asset Specification can support any type of metadata artifact, relationship, or
attributes, Rational Asset Manager can also be used to manage more generic asset types
that are related to software development. Therefore, Rational Asset Manager can also be
used to manage both Enterprise Architecture business and technical assets.
3.9.2 WebSphere Service Registry and Repository
WebSphere Service Registry and Repository is an industrial-strength tool that helps you
achieve more business value from your SOA by enabling better management and
governance of your services. Through its robust registry and Repository capabilities and its
tight integration with IBM SOA Foundation, WebSphere Service Registry and Repository can
be an essential foundational component of your SOA implementation.
WebSphere Service Registry and Repository enables you to store, access, and manage
information about services and service interaction endpoint descriptions (referred to as
service metadata) in an SOA. This information is used to select, invoke, govern, and reuse
services as part of a successful SOA. This service information includes traditional Web
Chapter 3. Tools in support of Asset-Based Development
39
services that implement Web Services Description Language (WSDL) interfaces with
SOAP/HTTP bindings as well as a broad range of SOA services that can be described using
WSDL, XML Schema Definition (XSD), and policy decorations, but might use a range of
protocols and be implemented according to a variety of programming models.
You can use WebSphere Service Registry and Repository (WSRR) to store information about
services in your systems, or in other organizations’ systems, that you already use, that you
plan to use, or that you want to be aware of. For example, an application can check with
WSRR just before it invokes a service to locate the most appropriate service that satisfies its
functional and performance needs.
This capability helps make an SOA deployment more dynamic and more adaptable to
changing business conditions.
WebSphere Service Registry and Repository includes:
A service registry that contains information about services, such as the service interfaces,
its operations, and parameters
A metadata Repository that has the robust framework and extensibility to suit the diverse
nature of service usage
WebSphere Service Registry and Repository does not manage all service metadata, and it
does not manage service metadata across the whole SOA life cycle. It focuses on a
minimalist set of metadata that describes capabilities, requirements, and the semantics of
deployed service endpoints. It interacts and federates with other metadata stores that play a
role in managing the overall life cycle of a service.
3.9.3 Rational Asset Manager compared with other products
Next, we discuss Rational Asset Manager compared to other asset management frameworks.
Homegrown asset management frameworks as spreadsheets
Today’s companies are already trying to share components and assets within their
organizations; many companies have reusable assets but lack effective strategies to reuse
them.
Most companies use spreadsheets to track these assets or have homegrown asset
management frameworks that are based on asset storage on local or shared drives, all of
which can lead to compliance issues.
These spreadsheets are mostly oriented to maintain just a catalog of the assets developed by
certain departments and the changes made to the assets, but are not oriented to implement
an Asset-Based Development process at the enterprise level. Spreadsheets are usually
managed by an individual, who has manual control of the assets developed, but the individual
does not have any control over the asset development (permissions, approvals, restrictions,
and so forth).
Spreadsheets simply do not scale as the number of assets and asset versions increases, or if
teams are globally distributed. Plus, custom-built solutions are expensive to maintain and
enhance. Rational Asset Manager provides a scalable and cost-effective solution for reusing
software by providing a framework that allows you to define, create, share, and manage
assets across your organization, either locally or globally, while helping to secure your
intellectual property.
40
Strategic Reuse with Asset-Based Development
Project collaboration solutions as Wiki pages
Project collaboration solutions as wiki pages are starting to be quite popular these days. They
allow users to create and update Web page content without having to use an external Web
editor tool and requesting specific permissions. Users just need to perform simple operations
and introduce text syntax to create new pages dynamically.
Wikipedia is an example of a free encyclopedia that is built collaboratively using wiki pages.
Wiki pages are a good option to encourage the democratic use of the Web and promote user
participation and group communication, but they are not oriented to be used as a multi-user
asset Repository across the enterprise. Generally, there are no review processes in place
before modifications are accepted, and the Web pages are usually opened to a lot of users
without specific security restrictions.
Wiki pages do not provide extended capabilities around information capturing, security,
indexing, or archiving information, and the search depends on whether the wiki engine is
using a database.
Compared to Rational Asset Manager, which is a tool that is oriented to produce, consume,
and manage asset reuse, wiki pages are oriented just to publish exchange information
between communities but without following a standard way to organize this information,
without implementing complex security restrictions and constraints, and without following a
formal approval life cycle to validate how the information is entered and its quality.
WebSphere Server Registry and Repository
The user communities and content managed by Rational Asset Manager software and the
WebSphere Service Registry and Repository system are rather different. Rational Asset
Manager is a Repository that is oriented to develop any kind of assets, and WebSphere
Service Registry and Repository is a Repository that is oriented to manage information that is
useful for the runtime operation of the services as Figure 3-3 on page 42 shows.
Chapter 3. Tools in support of Asset-Based Development
41
Figure 3-3 Comparing Rational Asset Manager to WebSphere Service Registry and Repository
Many assets managed by Rational Asset Manager have nothing to do with deployed
services. And not every deployed service automatically is an asset that an enterprise might
want to reuse and load into Rational Asset Manager.
However, there are a number of artifacts that can be of interest to both user communities:
basically any document (for example, WSDL, XSD, and WS-Policy) stored in WebSphere
Service Registry and Repository software can be of interest as part of a reusable asset;
WebSphere Service Registry and Repository users might be interested in understanding the
design specifications, implementation, or documentation about a specific service.
Having two repositories for development and run time is the right strategy for not penalizing
the performance of the runtime environment. The users of both repositories are different, and
service runtime information must not be penalized by searches or any other activity that is
performed by users accessing the development information of services.
Both tools are integrated so that assets managed by Rational Asset Manager that contain
Web service definitions can be published to the WebSphere Service Registry and Repository,
and WebSphere Service Registry and Repository information can be replicated into the
Rational Asset Manager Repository.
For a detailed discussion about the differences and relationship between both products, refer
to Chapter 12, “Introduction to service assets” on page 335.
Rational ClearCase: A software configuration management Repository
Software configuration management repositories, such as Rational ClearCase, provide
management and control of software development artifacts. These repositories are used by
the software development team to control the parallel development and deployment of
individual artifacts that will be later integrated to build software applications.
42
Strategic Reuse with Asset-Based Development
Both Rational Asset Manager and Rational ClearCase have the concept of “version”, but it
represents different things for each tool:
Rational ClearCase controls and manage versions of individual artifacts or files (file
elements for Rational ClearCase).
Rational Asset Manager controls and manages versions of individual assets. Assets will
be composed of individual artifacts (that can be under the control of Rational ClearCase or
not) and additional metadata information to complete the asset information, such as
name, description, asset type, to which category the assets belong, and so forth. All of this
information will be packaged following the Reusable Asset Specification (RAS) standard.
So, there are generally two major levels for versioning with assets: the asset version and the
artifact version. The artifact version is typically managed and dictated by the source control
management system (Rational ClearCase), whereas the asset version is generally dictated
by the policies of the enterprise and managed by the Repository. Figure 3-4 illustrates the two
major levels for versioning.
Figure 3-4 Versioning levels across repositories
Because the asset has information in addition to the individual artifact versions, although the
artifact versions remain the same, a structural change in the metadata information in the
asset can force the creation of a new version in the asset. For example, although the
spring.jar and license.txt files in Figure 3-4 do not change their versions in Rational
ClearCase, if the Spring asset has a new relationship with other assets, this will require a new
version of the asset although the artifact versions remain the same.
In addition to the two types of version concepts that managed by both types of tools
(individual artifacts compared to assets), SCM repositories compared to Rational Asset
Manager are not oriented to:
Facilitate searches to the user.
Extend artifact metadata with additional information. The artifact is just the file with
information that is just oriented to controlling changes.
Establish relationships to facilitate impact analysis.
Chapter 3. Tools in support of Asset-Based Development
43
And Rational Asset Manager compared to SCM repositories is not oriented to:
Create detailed reports comparing different versions of assets. Rational Asset Manager
logs the history of the changes made to the asset, but it is not oriented to compare
changes between different versions.
Manage individual files without a real value to the user.
But Rational Asset Manager and Rational ClearCase are integrated, and clients using both
tools can benefit from this integration. This integration recognizes when artifacts that are
submitted to Rational Asset Manager as part of the asset content are checked into Rational
ClearCase, and it maintains a reference. When a user wants to download a version of the
asset, Rational Asset Manager will use this information in providing the user the option of
reconnecting the artifacts to Rational ClearCase.
3.9.4 IBM Asset Repository strategy
IBM offers a number of metadata repositories, each targeted toward a specific user
community, each supporting the tasks and processes that are important to that community,
and each offering the content relevant to those tasks and communities. Examples are:
Rational Asset Manager: This Repository is used in the development space that helps to
create, modify, find, govern, and reuse any type of development assets, including services
and business assets.
Rational ClearCase: This software configuration management Repository provides
management and control of individual software development artifacts. It provides
sophisticated version control, workspace management, and parallel development support.
WebSphere Service Registry and Repository: This Repository is used in the run-time
space for managing SOA run-time-relevant metadata.
WebSphere Metadata Server: This Repository is oriented for users who are concerned
with the metadata related to “data”, for example, data architecture, data warehousing, and
enterprise information integration.
Configuration Management Database (CMDB): This Repository is for managing system
and service management metadata.
IBM strategy is to focus each type of Repository to one specific community of users,
automate the exchange of information among them, and have the capability to conduct
federated queries across them. As we discussed earlier in this chapter, these repositories can
also, and will likely, be used in combination.
Note: Additional details about the integrations and workflow between the repositories can
be found in Appendix A, “Rational Asset Manager: Installation and administration” on
page 637, Chapter 9, “Produce reusable assets” on page 237, and Chapter 15, “Managing
service assets” on page 425.
44
Strategic Reuse with Asset-Based Development
3.10 Process and methodology support
Next, we discuss process and methodology support products.
3.10.1 Rational Method Composer
Rational Method Composer is an Eclipse-based framework for process and method
authoring, targeting primarily process engineers who want to tailor or create method contents
and processes. For example, Rational Unified Process (RUP) for SOA has been codified
using Method Composer.
Method Composer is the product that replaces RUP and RUP authoring products, such as
RUP Process Builder.
Method Composer ships with process plug-ins, including:
Classic RUP
RUP for Business Modeling
RUP for Service-Oriented Modeling and Architecture (SOMA)
Method Composer is based on the open source Eclipse Process Framework (EPF). The main
difference between Method Composer and Process Framework is around process contents,
such as the ones just listed. Process Framework only contains limited contents whereas
Method Composer has a lot. Also, Method Composer provides additional integration
capabilities with other Rational products, such as Rational Portfolio Manager.
Method Composer implements the Unified Method Architecture (UMA) standard, submitted to
the Object Management Group (OMG) as Software Process Engineering (SPEM) V2.0. With
this standard, everyone uses the same terminology around methods and processes. For
example, SPEM defines what tasks, activities, roles, and guidance are.
Method Composer contents are packaged as plug-ins. A new plug-in can be based on an
existing one. For example, RUP for SOMA is based on RUP and provides variations
(contributions, extensions, or replacements) for service orientation.
The main output of Method Composer is an HTML site (formerly RUP site) with method and
process contents that is accessible from a Web browser and from within tools of the Software
Development Platform (SDP), such as Rational Software Architect.
Also, Method Composer bridges the gap between process engineering and project
management by providing the capability to export processes as Rational Portfolio Manager or
Microsoft Project templates.
Important: Throughout the course of this book, we leverage content from the Asset-Based
Development V3.0 and Asset-Based Development Governance V1.0 Rational Method
Composer plug-ins. You can download these plug-ins using the following links:
For use with Rational Method Composer V7.1:
http://www.ibm.com/developerworks/rational/downloads/06/rmc_plugin7_1/#16
For use with Rational Method Composer V7.2:
http://www.ibm.com/developerworks/rational/downloads/07/rmc_v7.2/#15
Chapter 3. Tools in support of Asset-Based Development
45
3.10.2 Rational Portfolio Manager
Rational Portfolio Manager is a project portfolio management tool that is targeted at business
executives to support them in making decisions. Portfolio Manager helps make business
decisions in the areas of (sorted in chronological order):
Business priorities, alignment, and trade-off: These activities involve evaluating initiatives
based on internal performance and external demand. Then, trade-off decisions are made
regarding what to pursue and when. Business alignment is key for SOA, and Portfolio
Manager helps select the right initiatives. For example, Portfolio Manager provides a
consistent way to look at demands with work and proposal templates. It also provides
analytical tools (for example, investment maps and scorecards) to help decide what mix of
initiatives makes the best aligned portfolio. Also, initiative approvals are auditable, which
supports compliance.
Source or resource: Following the prioritization of initiatives, the next decision is about
identifying the solution needed to meet the initiative’s goal. Typically, a particular initiative
can involve multiple projects. Decisions are made about using internal resources or
outside vendors. Portfolio Manager helps improve resource utilization in geographically
distributed teams. Also, it helps you understand forecasted resource capacity (for
example, supply and demand analysis, what-if analysis, demand scheduling, and
real-time resource assignment).
Build or buy and deployment-ready: Knowing what resources are available, a decision
maker can then decide whether to build from scratch, evolve an existing application, or
buy a packaged application. Also, because multiple projects are running, there is always
the need to integrate (projects, people, and so forth), so that, at the end, a solution can be
delivered to support the identified initiatives. Portfolio Manager supports this execution
through its integration with Method Composer, which allows project teams to follow
consistent methods and processes. Portfolio Manager also provides access to all project
information (including historical data from past projects) through its centralized
Repository. Finally, Portfolio Manager provides an integrated way of assessing risks,
issues, and changes.
Value analysis: It is then critical to know whether the selected initiative brings the intended
value to the business. Portfolio Manager provides constant access to measurements and
control throughout development. Using Portfolio Manager, IT can prove to the business
how much value it delivers (for example, calculating earned value to predict project
performance, providing warnings through trends, and so forth).
Regulatory compliance: Last but not least, businesses have to ensure regulatory
compliance, and Portfolio Manager helps by providing graphical workflows that enforce
and automate decision rights and responsibilities, as well as scorecards that show project
compliance.
Portfolio Manager is important for governance, because it helps executives make business
decisions so that an organization’s portfolio is best aligned to business priorities. Also, it helps
define and enforce decisions correctly, which is a central part of governance.
3.10.3 Rational ProjectConsole
IBM Rational ProjectConsole™, part of IBM Rational Team Unifying Platform™, automates
reporting on project status by dynamically creating a project Web site with a graphical
dashboard based on data that you collect. This saves you the time of having to build, update,
and maintain a team Web site, plus the time and effort of manually gathering status updates.
Rational ProjectConsole collects both standard and custom metrics from your Rational Team
Unifying Platform and third-party products, presenting the results graphically so that you can
46
Strategic Reuse with Asset-Based Development
easily assess project progress and quality. This allows you to better predict which areas will
require special attention and where to focus scarce resources to stay on schedule. More
importantly, ProjectConsole enables you to make decisions based on quantitative analysis,
rather than subjective status reports.
As discussed in Chapter 6, “Value, impact, and return on investment” on page 103, it is
important to be able to capture and track metrics to support a reuse program. Going into the
program, you will need a baseline in regard to the time that it takes to deliver software, the
cost of building the solution, and the overall quality of the solution.
3.11 Bringing it all together
Rational Asset Manager can integrate with external tools to help development teams to
produce, consume, and govern any kind of asset. Figure 3-5 represents an overview of the
tools with which Rational Asset Manager can be integrated.
Figure 3-5 Tools, tasks, and roles
We can examine this diagram from a number of perspectives, including:
Asset Management: RUP helps teams to implement and deploy an asset-development
process, giving organizations the ability to manage and govern the production and
consumption of reusable assets. The Rational Method Composer Asset-Based
Development Plug-in (ABD) referenced during this book includes specific sections (called
Tool Mentors) that give guidance explaining how to perform specific tasks or steps using
Rational Asset Manager. For more information about how to configure and create a
customized asset-development process, go to Appendix B, “Integrating Asset-Based
Development into a process” on page 713.
Note: The content from the Asset-Based Development Rational Method Composer
plug-in can be inserted into any process, not just the Rational Unified Process.
Rational Asset Manager Administrators can create connections to a change management
solution, such as Rational ClearQuest, to discussion forums and customize the default
Chapter 3. Tools in support of Asset-Based Development
47
review process defined in Rational Asset Manager to adapt it to the specific organization’s
needs. For more information about how to set up and customize this integration, review
A.4.2, “Integrating Rational Asset Manager with Rational ClearQuest”.
Assets that contain Web service definitions can be published to the WebSphere Service
Registry and Repository using the integration already provided in Rational Asset Manager.
The integration between both tools also allows you to synchronize information from
WebSphere Service Registry and Repository into Rational Asset Manager, helping
developers to search for already published service assets and their supporting
development assets. In Part 3, “Service Assets in an SOA” on page 333, you have a
detailed explanation of how this integration works. A.4.1, “Integrating Rational Asset
Manager with WebSphere Service Registry and Repository” gives more detailed
information about how to configure the integration.
Rational Asset Manager server can use Rational ClearCase to store assets as an
alternative to using the file system. Rational Asset Manager also recognizes when
artifacts that are going to be submitted to its control are under control of a version control
system, such as Rational ClearCase or Concurrent Versions Systems (CVS), and records
this information, which will be used later when the user wants to download or import the
asset. A.4.3, “Integrating Rational Asset Manager with Rational ClearCase” describes the
details of the integration with Rational Clearcase.
The “Asset Management” Eclipse perspective of Rational Asset Manager allows users of
Eclipse-based tools, such as Rational Software Architect, to use a flexible user interface to
quickly find and package assets without having to leave the development environment.
A specific integration exists between Rational Asset Manager and Rational Software
Architect through the “Rational Asset Manager Configurator Plug-in”. This plug-in allows
the user to export as XMI models the Rational Asset Manager configuration data, such as
communities, asset types, categories, attributes, and relationships, using Rational
Software Architect and import them into Rational Asset Manager.
Asset Production: If we look at Asset-Based Development from the perspective of an
Asset Producer, we notice that there is a collection of tools related to modeling,
development, and testing. Each of these tools, and many more, can be used to produce
assets that we want to use within the organization. In later chapters, we look at several of
these tools in-depth, as well as best practices associated with the tools in building certain
types of assets.
Asset Consumption: When looking at Figure 3-5 on page 47 from an Asset Consumer
point of view, again we see quite a few tools that can consume a reusable asset. For
instance, there can be a set of models that need to be reused, a set of test plans, or a
code component. Those people using consumer assets can interact with the Repository,
searching for assets, downloading assets, and providing feedback on the assets.
48
Strategic Reuse with Asset-Based Development
4
Chapter 4.
Introduction to the IBM Rational
Unified Process
This chapter discusses the IBM Rational software development process by describing the
basics of Rational Unified Process (RUP) and the Rational Method Composer. The following
chapter takes a more in-depth look at the Asset-Based Development and Asset Governance
Rational Method Composer plug-ins. Jump ahead to the next chapter if you are already
familiar with the basics of the Rational Unified Process.
Note: The Asset Based-Development and Asset Governance plug-ins can be worked into
any process. A good choice is to leverage content from the Rational Unified Process.
However, if you prefer another process or already use another process, you can leverage
these plug-ins and the guidance contained within the plug-ins in another process.
4.1 Introduction
Every company, project, or team has a method. It can get invented every morning when the
team walks through the door, but the team has a method, a way of working together. The
question is, “Is this the appropriate method for the team?” This chapter introduces the IBM
Rational Unified Process and the tooling that supports the use and consumption of the
process.
4.1.1 How much of this guidance needs to be used
As we work our way through this chapter, remember that this is a set of best practices and
process guidance to help you on your way - there is no one-size-fits-all solution. As you
review this material, remember the goals that you and your organization are trying to achieve.
Figure 4-1 on page 50 presents a view that there is a range that represents the strength that
is possible within a process implementation. In addition, there are a number of factors that
help you to decide where on that range of strength your process implementation needs to
reside. Keep these factors in mind as you consider how your process and governance must
be set up and work to keep your process as agile and efficient as possible.
© Copyright IBM Corp. 2008. All rights reserved.
49
Figure 4-1 Spectrum of process strength
4.2 IBM Rational Unified Process
The IBM Rational Unified Process (RUP) is a software engineering process framework. It
provides best practices and guidance for successful software development and a disciplined
approach to assigning tasks and responsibilities within a development organization. Its goal is
to ensure the production of high-quality software that meets the needs of its users within a
predictable schedule and budget.
The process has been developed over the last 26 years as a collection of IBM Rational field
experience helping clients develop software and IBM Rational’s experience building their own
products. This work has led to the Object Management Group (OMG) standard Software
Process Engineering Metamodel (SPEM) and the Eclipse Process Framework project:
SPEM is a standard way of describing a process1 and was originally developed by
Rational Software, IBM, and other companies.
The Eclipse Process Framework project is an open source project that provides tooling to
build development and other processes and provide basic content. IBM and other
companies initiated this project. IBM provided both the initial tooling and content and now
uses this open source project as the basis for its commercial IBM Rational Method
Composer product. The Web site for the Eclipse Process Framework is at:
http://www.eclipse.org/epf
Figure 4-2 on page 51 shows a few key definitions that we have to understand before we can
effectively understand RUP.
1
50
The more recent versions of RUP and the Eclipse Process Framework project use an updated version of the
original SPEM specification. This new version is currently being proposed by IBM and others as SPEM V2.
Strategic Reuse with Asset-Based Development
Figure 4-2 Key concepts in RUP (from RUP V7.1)
These concepts are:
Method is the combination of method content along with process (the way we combine
the method content to create an approach that we can follow in a project).
Method content is the information in the process: the words and pictures.
Work product is something meaningful resulting from a process (from RUP).
Role is a set of related skills, competencies, and responsibilities (RUP).
Task describes a unit of work assigned to a Role that provides a meaningful result (RUP).
Guidance is an abstract concept that generalizes all forms of content whose primary
purpose is to provide additional explanations and illustrations to elements, such as Roles,
Tasks, Work Products, Activities, or Processes (RUP).
Process defines the structured work definitions that need to be performed to develop a
system (RUP).
Capability pattern describes a reusable cluster of Activities in common process areas
that produces a result of observable value (RUP).
Delivery process describes a complete and integrated approach for performing a specific
type of project (RUP).
Activity defines the breakdown as well as the flow of work (RUP).
We tend to select a specific delivery process when we start looking for a process for our team
or project (for example, RUP for small projects) and then adapt it for our local needs. This
local version is called a development case. If we like our adapted process and want to use it
elsewhere, we can use the Rational Method Composer to create our own delivery process.
RUP is delivered as a large set of HTML pages that we use as a library of information. We
select the parts of the library that we need for our project as a development case.
RUP follows a set of core principles that are worth understanding as we use RUP. This forms
the motivation for using a process and specifically for using RUP.
Chapter 4. Introduction to the IBM Rational Unified Process
51
4.2.1 The heart of RUP
At its heart, the IBM Rational Unified Process (RUP) is about successful software
development. There are three central elements that define RUP:
An underlying set of philosophies and principles for successful software
development
These philosophies and principles are the foundation on which RUP has been developed.
See “Core principles of RUP” on page 53 for more on the topic.
A framework of reusable method content and process building blocks
Defined and improved on an ongoing basis by Rational Software, the RUP family of
method plug-ins defines a method framework from which you create your own method
configurations and tailored processes.
The underlying method and process definition language
Underlying it all is a unified method architecture meta-model. This model provides a
language for describing method content and processes. This new language is a unification
of different method and process engineering languages, such as the SPEM extension to
the Unified Modeling Language (UML) for software process engineering, the languages
used for RUP V2003, Unified Process, and IBM Global Services Method, as well as IBM
Rational Summit® Ascendant®.
One of the core practices behind RUP is iterative and incremental development. This practice
is also good to remember as you start with RUP: Do not try to “do” all of RUP at once. Adopt
an approach to implementing, learning, and using RUP that is itself iterative and incremental.
Start by assessing your existing process and selecting one or two key areas that you want to
improve. Begin using RUP to improve these areas first, and then, in later iterations or
development cycles, make incremental improvements in other areas. We use both iterative
and incremental methods in terms of process adoption and in terms of how we roll out
Asset-Based Development and the associated tooling.
4.2.2 The IBM Rational Method Composer platform
Over many years of development effort, RUP has evolved into a rich process engineering
platform called IBM Rational Method Composer. Method Composer enables teams to define,
configure, tailor, and practice a consistent process.
The key elements of the platform are:
Method delivery tool
RUP is delivered to practitioners as an interactive Web site using industry-standard
browser technology. A RUP Web site is a Rational Method Composer-published process
presentation configured for your project and tailored to your specific needs. The Web site
is created using dynamically generated HTML pages, which Method Composer enables
you to publish in the form of multiple RUP Web sites, each representing a configured and
tailored process definition.
Method configuration tool
Method Composer supports the fine-grained publish-time configuration of method content
and processes to meet the varied needs of different projects and users. Method Composer
allows the optional inclusion of method and process extensions using Method Composer’s
plug-in technology. It also allows you to configure variants on processes, which are
published differently depending on user-specific selections.
Method authoring tool
Method Composer is specifically designed for method content management and process
authoring with functions, such as form-based authoring, breakdown structure-based
authoring, content browsing, content search, and import and export of method content.
52
Strategic Reuse with Asset-Based Development
Method Composer also provides mechanisms for rapid process assembly using process
patterns and reusable method elements. It supports the creation of method plug-ins that
provide powerful ways of extending and modifying existing content, simplifying method
content, process management, and maintenance.
A marketplace for process extensions
The Method Composer/RUP section of the developerWorks® Rational Web site provides
a place for process engineers in the software development community to share their
method extensions as consumable plug-ins and provides a rich source of method
extensions for the project manager. You can access the Method Composer/RUP section
of the developerWorks Rational Web site at:
http://www.ibm.com/developerworks/rational/products/rup/
You can read more information about Rational Method Composer at:
http://www.ibm.com/software/awdtools/rmc/
4.2.3 Core principles of RUP
RUP has six core principles that provide the rationale for the process:
Adapt the process
Balance competing stakeholder priorities
Collaborate across teams
Demonstrate value iteratively
Elevate the level of abstraction
Focus continuously on quality
Each principle is presented through:
The benefits derived from applying the principle
The pattern of behavior that best embodies the principle
The most recognizable “anti-patterns” or behaviors contrary to the principle that can harm
software development projects
Adapting the process
Adapting the process means to use the right amount of process for a particular project. Too
much process kills projects, too little process can lead to unconstrained chaos. An interesting
side effect of having a role-based process is that the process can be scaled from very small
teams to very large teams without changing the core principles. The work products, tasks,
and other aspects of the process can vary, but we must still be able to recognize a
RUP-based process.
The benefits are:
Life cycle efficiency
Increased project agility
Realistic plans and estimates
Patterns:
Right-size the process to project needs, including:
– The size and distribution of the project team
– The complexity of the application
– The need for compliance
Chapter 4. Introduction to the IBM Rational Unified Process
53
Adapt the process ceremony to the life cycle phase (allow the formality to evolve from less
to more as uncertainties are resolved)
Improve the process continuously
Balance plans and estimates with the level of uncertainty
Anti-patterns:
Always see more process and more detailed up-front planning as better:
– Force early estimates and stick to those estimates.
– Develop precise plans, and manage the project by tracking against a static plan.
Balancing competing stakeholder priorities
Balancing competing stakeholder priorities recognizes the need to constantly balance
priorities on a project. Creating a clear set of requirements based on the real needs of the
business and then regularly checking that these needs and requirements have not changed
are examples of this balancing act. Build, buy, or reuse of services is another example. There
are cost compared to time compared to functionality balancing acts in this case.
The benefits are:
Align applications with business and user needs.
Reduce custom development.
Optimize business value.
Patterns:
Define, understand, and prioritize business and user needs.
Prioritize projects and requirements and couple the needs with the software capabilities.
Understand what assets we can leverage.
Balance asset reuse with user needs.
Anti-patterns:
Thoroughly document precise requirements at the outset of the project and force
stakeholder acceptance of requirements:
– Negotiate any changes to the requirements where each change can increase the cost
or duration of the project.
– Lock down requirements up front, thereby reducing the ability to leverage existing
assets.
– Primarily perform custom development.
Architect a system only to meet the needs of the most vocal stakeholders.
Collaborating across teams
Collaborating across teams refers to the need to motivate the individuals on the team, break
down the barriers between different teams or parts of the team, and ultimately extend this
collaboration to the business, development, and operations. SOA-enabled solutions extend
this collaboration outside the enterprise.
The benefits are:
Team productivity
Better coupling between business needs, the development, and the operations of the
software systems
54
Strategic Reuse with Asset-Based Development
Patterns:
Motivate people to perform at their best.
Create self-managed teams.
Encourage cross-functional collaboration (for example, analysts, developers, and testers).
Provide effective collaborative environments.
Manage evolving artifacts and tasks to enhance collaboration, progress, and quality
insight with integrated environments.
Integrate business, software, and operation teams.
Anti-patterns:
Nurturing heroic developers willing to work extremely long hours, including weekends
Having highly specialized people equipped with powerful tools for performing their jobs,
limited collaboration among team members, and limited integration between tools. The
assumption is if everyone just does their job, the end result will be good.
Demonstrating the value iteratively
Demonstrating the value iteratively has several aspects. The first aspect is that we need to
deliver real code regularly, starting right at the beginning of the project. It gives the
stakeholders a chance to see what we are doing and to provide feedback. The second aspect
is that iterations allow the plan to be adapted as the project proceeds. The third aspect is the
chance to accept and manage change with changing business priorities and stakeholder
expectations. The last aspect is that we drive out risk continuously from the project by
demonstrating working software. We also constantly reassess the key risks and adapt the
plans accordingly2.
Benefits:
Early risk reduction
Higher predictability throughout the project
Trust among stakeholders
Pattern:
Enable feedback by delivering incremental user value in each iteration.
Adapt your plans using an iterative process.
Embrace and manage change.
Attack major technical, business, and programmatic risks early.
Anti-patterns:
Plan the whole life cycle in detail and track variances against plan (can actually contribute
to project failure).
Assess status in the first two-thirds of the project by relying on reviews of specifications,
rather than assessing the status of test results and demonstrations of working software.
Elevating the level of abstraction
Elevating the level of abstraction is a principle aimed at simplifying how we work and
communicate. We achieve this principle by the reuse of existing assets, the use of modeling
tools, and the use of architecture. A significant benefit of SOA-based solutions relies on this
2
Moving a development team and its stakeholders to an iterative process is hard. An iterative process introduces
perceived uncertainties, such as a lack of a stable set of requirements, difficulty in planning and costing work,
regular rework, and challenges scheduling staff requirements. RUP, the supporting material, and training address
all of these issues directly.
Chapter 4. Introduction to the IBM Rational Unified Process
55
elevation of the level of abstraction: services being reused, modeling and transformations to
translate business requirements to code as quickly as possible, and the use of SOA as an
architectural style.
The benefits are:
Productivity
Reduced complexity
Patterns:
Reuse existing assets.
Use higher-level tools and languages to reduce the amount of documentation produced.
Focus on architecture first.
Architect for resilience, quality, understandability, and complexity control.
Anti-patterns:
To go directly from vague, high-level requirements to custom-crafted code:
– Because few abstractions are used, a lot of the discussions are made at the code level
compared to a more conceptual level, which misses many opportunities for reuse,
among other things.
– Informally captured requirements and other information require decisions and
specifications to be revisited repeatedly.
– Limited emphasis on architecture causes major rework late in the project.
Focusing continuously on quality
Focusing continuously on quality emphasizes the need to have quality as a priority
throughout the life cycle. Testing is not the discipline that introduces quality into our solution it can only catch the lack of quality in what has gone before. Because each iteration involves
testing, we have a regular monitor on quality throughout the project.
The benefits are:
Higher quality
Earlier insight into progress and quality
Patterns:
Ensure team ownership of quality for the product.
Test early and continuously in step with the integration of demonstrable capabilities.
Incrementally build test automation.
Anti-patterns:
To peer review all artifacts and complete all unit testing before integration testing
To conduct in-depth peer review of all intermediate artifacts, which is counterproductive
because it delays application testing and hence identification of major issues
To complete all unit testing before doing integration testing, again delaying identification of
major issues
4.2.4 Key concepts
The key concepts of RUP include:
RUP summary chart
Iterative development
56
Strategic Reuse with Asset-Based Development
Phases (inception, elaboration, construction, and transition)
Architecture driven
Use case driven
RUP summary chart
The RUP summary chart is shown in Figure 4-3.
Figure 4-3 RUP summary chart
The RUP summary chart captures many of the concepts of RUP in one diagram. The chart
shows a project with time on the x-axis and the disciplines on the y-axis. Each RUP project is
divided into four phases (Inception, Elaboration, Construction, and Transition). Each phase is
broken down into zero or more iterations. An iteration is a vertical slice through the
disciplines as shown in Figure 4-3. This iteration is the first iteration in the Construction
phase.
The bumps on the chart indicate the level of effort required for each discipline. Notice, for
example, how the business modeling and requirements disciplines are biased toward the
beginning of the project but still continue into the Transition phase. One of our favorite
questions about this chart is based around testing, “Why do the bumps on the testing
discipline line get bigger and bigger over time?”3
We now look at several of these terms and ideas in more detail.
Iterative development
Iterative development is the concept of breaking a project into a set of iterations:
“An iteration encompasses the development activities that lead to a product release a stable, executable version of the product, together with any other peripheral elements
necessary to use this release.”
3
This is because as we build more and more code, we write more and more tests. Each iteration runs the tests of the
new code and the tests from the previous iteration. If we managed to identify the really high-risk areas of the project
correctly, we will have regression tested these areas to the full extent by the end of the project.
Chapter 4. Introduction to the IBM Rational Unified Process
57
The project effectively becomes a set of smaller projects. The traditional software
development project life cycle of gathering requirements, designing, implementing, and
testing the solution is discarded. However, an iteration contains these traditional disciplines,
hence, the idea of an iteration as a mini-project. A project consists of a number of iterations.
This approach has many advantages, including:
Faster feedback on all aspects of the project
Faster exposure (and consequently faster mitigation) of risk
Ability to validate any estimation techniques within the project
Capability to build archetypes and derive reusable assets from them within one iteration
and then leverage the assets in later iterations within the same project
The focus of each iteration is to produce a form of working, tested code. In earlier iterations,
this code might be a prototype of a certain aspect of the service or composite services. In
later iterations, the working code will be complete builds of the services or composite services
but with reduced functionality. This reduced functionality can be stubbed out code, no or
reduced handling, or simulation of an intended function (for example, a database access and
retrieval might be simulated).
Project managers are concentrating on using the iterations to mitigate or expose risk.
Contrary to natural inclinations, we encourage projects to attempt the highest risk aspects up
front. This in turn allows us to spend most of the time addressing the risks. Each iteration
must start with an assessment of what has changed since the start of the last iteration.
Changes in risks and priorities can steer us to change the plan for this iteration, bringing part
of the work forward and pushing part of the work back.
Phases
Each RUP project is broken into four phases. The phases in order of execution are:
Inception
Elaboration
Construction
Transition
Inception is the phase where we scope out the project. During the iterations in this phase, we
define business use cases (or revise them if several use cases already exist). We define our
business goals, key performance indicators, and metrics. We create initial “as is” and “to-be”
business process models.
Elaboration is the phase where we make sure that we can have a working end-to-end
automated business process or processes. Updates are made to all of the work products that
were created in the Inception phase. Part of the code that was previously stubbed out is filled
in. Tests from the previous phase are rerun and expanded to include the new functionality.
Construction is where we complete the coding and testing. Many of the work products, such
as the business process models, requirements, service model, and other work products, are
further refined as appropriate and locked down as completed. At the end of the phase, the
software is ready to be released to alpha and beta testing. Further changes to requirements
based on feedback will be scheduled for future releases, or we might remain in Construction.
Because the stakeholders have already seen running code during the preceding two phases,
and we have been tracking changes in business processes and business goals, it is less
likely that major changes will surprise us at this point.
Transition is the phase that can vary the most. It entirely depends on what kind of software
you are building. For a product release (such as a release of IBM Rational tools), transition is
focused on alpha and beta testing. We are finishing training materials, marketing materials,
58
Strategic Reuse with Asset-Based Development
deciding on the color of the box or CD, and checking that the copyright notices appear on the
accompanying literature4. We are fixing any critical defects found in the alpha and beta
releases. An internal project for the business will be working with operations to get system
and user acceptance testing completed and planning for deployment. When the Transition
phase is complete, further changes to the software require a new project (run iteratively, of
course). Maintenance has a slightly different type of project.
Each phase has strict entry and exit criteria or gates. By the end of each phase, we require
that:
Inception: We have agreed upon the scope of the project.
Elaboration: Architecturally significant aspects of the project are up and running as tested
code.
Construction: The coding is complete.
Transition: The project is “live”.
It is very important that a project does not proceed to the next phase if these high-level goals
have not been achieved. We can add iterations to the phase to enable us to achieve the goals
of the phase. This has an obvious impact on schedule, but we can catch up later by
accomplishing more in future iterations or we decrease the scope of the functionality that we
plan to deliver. Iterative development makes this easier, because at the end of each
successful iteration, we have a stable build of the code and the associated work products that
must be suitable for release.
Architecture-driven
RUP is an architecture-driven process. Defining and building an executable architecture is
the focus of the Elaboration phase of any RUP project. An executable architecture means
code that demonstrates and proves the effectiveness of our architectural decisions.
Use case-driven
Prior to the introduction of SOA concepts, RUP focused on aligning iterations to system use
cases. This is still true in that we expect to take system use cases through to implementation
during a iteration; there are higher level drivers of the goal of an iteration.
Automating a business process or task becomes the new goal of the iteration. We have to
implement system use cases as part of this goal, but now we focus on implementing a thread
of the business process from beginning to end. We might not handle all cases in the process,
and we might not cover all exceptions or branches in the process flow, but we have to
implement something useful end-to-end.
If we use business use case realizations as an alternative to business process flows, we are
implementing these business use case realizations. Either way, the focus of the iteration is to
deliver useful business functionality.
4.3 References
For more information:
Read the Rational Method Composer developerWorks article series at:
http://www-128.ibm.com/developerworks/rational/library/dec05/haumer/
4
These tasks can be surprisingly continuous, especially the box color.
Chapter 4. Introduction to the IBM Rational Unified Process
59
Refer to the Eclipse Process Framework site at:
http://www.eclipse.org/epf/
Refer to the IBM developerWorks Rational Unified Process (RUP) and Rational Method
Composer site at:
http://www-128.ibm.com/developerworks/rational/products/rup
60
Strategic Reuse with Asset-Based Development
5
Chapter 5.
Asset-Based Development and
Asset Governance Rational
Method Composer plug-ins
This chapter provides an introduction to the content provided in the Asset-Based
Development and Asset Governance plug-ins for Rational Method Composer. After
completing this chapter, you will have a good understanding of the content provided by these
plug-ins. In later chapters, we discuss how ZYX Electronics has leveraged this information, as
well as the deliverables that they have built while following this guidance.
Important: Throughout the course of this book, we leverage content from the Asset-Based
Development V3.0 and Asset-Based Development Governance V1.0 Rational Method
Composer plug-ins. You can download these plug-ins by using the following links:
For use with Rational Method Composer V7.1:
http://www.ibm.com/developerworks/rational/downloads/06/rmc_plugin7_1/#16
For use with Rational Method Composer V7.2:
http://www.ibm.com/developerworks/rational/downloads/07/rmc_v7.2/#15
© Copyright IBM Corp. 2008. All rights reserved.
61
5.1 Introduction to the asset plug-ins
To help you create a process for your organization that incorporates strategic reuse, IBM
Rational has released two Rational Method Composer plug-ins:
Asset-Based Development plug-in
Asset Governance plug-in
These plug-ins are packaged together as one download, because the plug-ins involve topics
that are strongly related. When building assets, it is important to know what roles are
involved, what steps to follow, and what work products to produce. But even more
importantly, we need to understand that the correct business decisions are being made,
investments are going into the right projects, proper metrics are captured, and that we are
doing so in a way that matches our risk expectations.
In the following sections, we describe the major characteristics of each plug-in. As part of this
examination, we also highlight the activities, tasks, roles, and deliverables.
5.2 Adoption guidance
Next, we discuss adoption guidance.
5.2.1 How adoption guidance fit into a process
The content within these plug-ins is provided as capability patterns. A capability pattern:
“describes a reusable cluster of Activities in common process areas that produces a result of
observable value.” Rational Unified Process (RUP)
The Asset-Based Development capability patterns and associated content are generally
inserted into the current enterprise processes. If the enterprise uses RUP, the Asset-Based
Development processes can be inserted in any phase, in any discipline, or within any
iteration, an example of which is illustrated in Figure 5-1 on page 63. Note that this is just one
possible example out of many possible and equally valid variations.
62
Strategic Reuse with Asset-Based Development
Figure 5-1 Integrating Asset guidance into a process based on the Rational Unified Process
The Asset-Based Development workflows can be inserted into other software development
processes, such as the one shown in Figure 5-2. In this example, the Asset-Based
Development workflows are inserted into each of the process phases. In certain cases, the
business-related assets are only used on the software project and are not produced on the
project, whereas each of the software-related phases produce and consume assets on the
project. This example does not address a situation in which there are more central or
cross-project asset manufacturing teams.
Figure 5-2 Integrating with a non-RUP-based process
Note: We provide more information regarding tailoring a process in Appendix B,
“Integrating Asset-Based Development into a process” on page 713.
Chapter 5. Asset-Based Development and Asset Governance Rational Method Composer plug-ins
63
5.2.2 How much of this guidance do you use
As we work our way through this chapter, remember that this is a set of best practices and
process guidance to help you on your way. There is no one-size-fits-all solution in regard to
how to govern asset development nor the steps that you take to produce and consume
assets. As you review this material, remember the goals that you and your organization are
trying to achieve. Figure 5-3 presents a view that there is a range that represents the strength
that is possible within a process implementation. In addition, there are a number of factors
that help you to decide where on that range of strength your process implementation needs to
reside. Keep these factors in mind as you consider how your asset process and governance
need to be set up, and work to keep your process as agile and efficient as possible.
Figure 5-3 Spectrum of process strength
5.3 Governance
Let us take a quick look at a couple of foundational definitions before getting into the details of
Asset Governance:
Governance:
– Establishing chains of responsibility, authority, and communication to empower people
(decision rights)
– Establishing measurement, policy, and control mechanisms to enable people to carry
out their roles and responsibilities
IT Governance:
– Decision making rights associated with IT
– Mechanisms and policies used to measure and control the way IT decisions are made
and carried out
Figure 5-4 on page 65 relates this definition of IT Governance to the goals for IT Governance.
64
Strategic Reuse with Asset-Based Development
(IT) GOVERNANCE DEFINED
Chains of responsibility, authority
and communications to empower people
Policy, control and measurement mechanisms to
enable people to carry out their roles and
responsibilities
(IT) GOVERNANCE GOALS
Strategic Alignment
Increase value realization
from business strategies and objectives
Risk Reduction
Understand and mitigate risks associated
with initiatives and operations
Figure 5-4 Goals of IT Governance
Asset Governance can be seen as a specialization of IT Governance. Therefore, we arrive at
the following definition of Asset Governance:
Asset Governance:
– Extension of IT Governance focused on the life cycle of assets to ensure the business
value of Asset-Based Development
– Asset Governance is a catalyst for improving overall IT Governance
Figure 5-5 provides a high-level view of the relationships among these levels of governance.
Note that Asset Governance fits primarily within IT Governance; however, we still need to
ensure that we are connected to the overall business via Business Governance.
Figure 5-5 Relationships among the levels of governance
Building on this understanding of the levels of governance, there are two more definitions of
which you need to be aware:
Governance Solution (n) is a work product of Governance, a set of governance decisions
applicable to a specific context and scope of activities.
Chapter 5. Asset-Based Development and Asset Governance Rational Method Composer plug-ins
65
Management (v) includes the activities of goal setting, decision making, oversight,
enablement, and guidance that implement a governance solution in pursuit of a set of
defined objectives.
As we discussed in 5.1, “Introduction to the asset plug-ins” on page 62, we want to build out a
strategic approach to leveraging reuse. This means that the resulting program must follow a
systematic approach and that the results of the effort are tied to and driven by the business.
Asset Governance is a key concept that helps us ensure that our reuse efforts are tied into
the goals of the larger organization.
5.3.1 Asset governance
As discussed in the previous section, Asset governance sits within the broader IT
Governance in an enterprise. Asset governance includes those activities for administering
Asset-Based Development. The focus is on preparing the organization to properly create,
use, measure, and plan the investments in assets.
The major focus areas include:
Planning: Capture the governance requirements; determine which processes to bring
under governance; and determine the measurements and targets of effectiveness of the
governance solutions. This area focuses on what predefined governance processes
(content areas) to deploy and what customizations are necessary to accommodate the
unique needs of the adopting organization.
Definition: Specify the decision rights, measures, and policies to be applied to those
processes under governance. Specify the automation and tool support. This area focuses
on performing a gap analysis between the predefined governance process and what is
needed.
Enablement: Roll out the governance solution to the organization in stages.
Measurement: Determine if the governance solution is meeting its effectiveness targets,
and make adjustments as necessary.
Describing the focus areas for Asset Governance is simplified when looking at it sequentially.
In practice, the activities in the focus areas generally overlap. This work requires iteration and
refinement. As policies and strategies are created, teams are being formed, and lessons are
being learned, refinement must be permitted, allowing the governance model to be updated.
Again, we come back to the theme of iterative and incremental. You can perform extensive
tooling, processes, and tasks as part of Asset-Based Development. We want to selectively
choose and work with those elements that best align with our own organization’s business
requirements. As we progress, we build out our capabilities and approach as necessary.
5.4 Asset governance plug-in
The focus areas within Asset Governance are illustrated in Figure 5-6 on page 67. In general,
these four focus areas can be investigated parallel, and the order in which the actions are
conducted is negotiable. Remember that as we work through these tasks a number of
deliverables, including, but not limited to Reuse Assessments, Classification Schemas, and
Process Documents, will be created. These artifacts will be built in an iterative and
incremental fashion that is reflective of the parallel nature of the work involved and the
relationships between the phases.
66
Strategic Reuse with Asset-Based Development
Figure 5-6 Focus areas within Asset Governance
The following sections take a more in-depth look at the focus areas and the roles, tasks, and
deliverables within each focus area.
5.4.1 Planning
Next, we discuss planning for governance.
Overview
In planning, we spend time determining what needs to be governed, the initial resource and
cost requirements, and who will fund this effort. This effort will also include a discussion and
decision about funding models.
The capability pattern for this focus area is shown in Figure 5-7 depicting two activities:
Preparation and Funding.
Figure 5-7 Capability Pattern for Planning
Activities and tasks
Next, we discuss the activities and tasks of planning.
Preparation
Figure 5-8 on page 68 depicts the tasks found within the Preparation activity. Certain key
planning tasks need to be performed first so that the estimates and funding discussions are
meaningful. Within the tasks associated with this activity, we spend time in assessing the
reuse capability of the organization and determine the Reuse Strategy for moving forward. As
the strategy solidifies, we are able to start to plan staffing, training, asset classification, and
reuse program adoption.
Chapter 5. Asset-Based Development and Asset Governance Rational Method Composer plug-ins
67
Figure 5-8 Tasks within the Preparation Activity
Funding
Figure 5-9 on page 69 depicts the tasks found within the Funding Activity. We are concerned
with determining the costs of the asset program, as well as the preferred funding model.
In regard to the funding model, we need to recognize that funding issues differ in a reuse
situation compared to a traditional development project. In typical funding situations, the
funds are allocated for the activities to deliver the artifacts for the project. This relationship
changes with the reuse model, where the funding for assets and their artifacts can provide
value for several projects. In addition, the project where the asset is built might need to incur
additional costs to build and package the reusable asset. However, other teams that then use
the asset get the benefits of using the asset and, therefore, appear to cost less to deliver.
There are several models for funding the reuse team and related reuse efforts:
Overhead funding: The costs for the reuse team are handled in the pool of overhead
expenses.
Tax funding: Each application development project pays a tax, which covers the cost of
the reuse team.
Payments for assets and services: The application development teams pay for the assets
and services that they use from the reuse team.
The organization needs to determine its funding model for conducting Asset-Based
Development. An initial recommendation is to start with overhead funding and then shift to
payments for assets and services. The purpose of this recommendation is to provide time for
startup costs and then move to another funding model, such as for services or assets, when
the initial value has been verified. For instance, you can use the overhead funding model
throughout the startup phases and then shift to an asset and services funding model
thereafter. Factors that will impact this decision include the decision to have an asset
manufacturing team and a governance board, to support tooling, and so forth.
As part of this work, we will find a sponsor for the program and ensure that the goals of the
program align of the needs of the sponsor and the organization.
68
Strategic Reuse with Asset-Based Development
Figure 5-9 Tasks within the Funding Activity
Roles, tasks, and deliverables
Note that the Asset-Based Development Manager and Administrator roles are key in these
efforts.
Tip: When reviewing the Roles and Deliverables diagrams in this chapter, remember that
artifacts that are entering into the task from the top are inputs into the task. The artifacts
that are displayed in the bottom of the graphic coming out of the task are outputs from the
task.
Preparation
The deliverables and roles associated with this activity are depicted in Figure 5-10 and
Figure 5-11 on page 70.
Figure 5-10 Administrator role and associated deliverable
Chapter 5. Asset-Based Development and Asset Governance Rational Method Composer plug-ins
69
Figure 5-11 Manager role and associated deliverables
Funding
The deliverables and roles associated with the Funding activity are depicted in Figure 5-12.
Figure 5-12 Manager role and associated deliverables
Key deliverables
There are six key deliverables associated with this focus area, including:
Reuse Assessment: A Reuse Assessment describes the opportunities and abilities of an
entity to conduct asset reuse work.
The scope of the Reuse Assessment must be selected first. In general, it is not a good
practice to attempt to apply reuse principles to the entire enterprise at one time. As input
70
Strategic Reuse with Asset-Based Development
to the Reuse Assessment, the business problem and priority need to be understood. This
provides the necessary context and scope for focusing the Reuse Assessment. Even in
cases where there is a significant business driver, we want to start the rollout with a
narrow focus.
The Reuse Assessment evaluates two major elements for the selected scope:
a. Reuse Capability: Reuse capability describes the organization’s ability to conduct
reuse activities. Reuse opportunity describes the extent to which recurring problems
and recurring solutions exist within the selected scope.
An organization’s reuse capabilities are increased when the following factors are in
place:
•
Management support
•
Mature software process in the organization
b. Reuse Opportunity: There are generally more reuse opportunities when the following
factors are in place:
•
Well-understood domains
•
Architecture to support reuse
•
Mature versioning and configuration management
When conducting the assessment, we can leverage the following perspectives:
– Governance: Is the enterprise willing and able to establish the policies and decisions
providing the context for asset reuse within a reuse scope
– Process: Where and when will the Asset Governance and Asset-Based Development
capability patterns be inserted into existing processes
– Opportunity: What are the opportunities for assets within a reuse scope
– Aptitude: What are the ability and willingness of teams and individuals to work with
assets
– Tools: What are the tools, repositories, and their configuration to support work with
assets
Notice that the perspectives are not just related to technology and tooling. We also focus
on business alignment and cultural willingness to create and use assets.
Reuse Adoption and Incentive Plan: You need to consult:
Incentive Compatibility and Systematic Software Reuse, Fichman and Kemererm, Journal
of Systems and Software, New York: April 27, 2001; Volume 57, Issue 1, page 45.
Reuse Strategy: The Reuse Strategy describes how the organization will conduct the
activities of a reuse program. Similar to the way in which we spend time creating a
Software Architecture document, we need to record the decisions that are made about the
reuse program, the vision for the program, the results that we want to achieve, and the
steps that we are going to take to realize the strategy.
Within a Reuse Strategy document, we usually capture details from four key perspectives,
including:
a. Process: In general, process leads us to conducting software development in a way
that leverages previous investments and preserves current investments. Specific to
software reuse, there are two process categories to consider: organizational-level
processes and project-level processes. Figure 5-13 on page 72 shows the relationship
between these two processes. Notice that the Organizational Level processes align
with Asset-based Governance and the Project Level processes align with Asset-Based
Development.
Chapter 5. Asset-Based Development and Asset Governance Rational Method Composer plug-ins
71
Figure 5-13 Process levels
b. Standards: WIthin this perspective, we describe the standards to which the reuse
initiative will adhere, as well as the standards that will be ignored.
c. Tools: Within this perspective, we describe the tools that will be leveraged to support
the reuse initiative. This perspective must include a discussion of the asset Repository
and process configuration, as well as the tools that will be used to produce and
consume assets. The expectation is that the organization will use a standard set of
tools based on the decisions and explanations detailed in this section.
d. Assets: This perspective is used to outline the major types of assets that the
organization plans to leverage. Up to this point, we have discussed assets quite
generically, because many artifacts can be packaged together to create assets. For an
organization to succeed in reuse, the organization needs to have a more narrow scope
and identify the types of issues that the organization will pursue.
Resources and Training Plan: Simply put, the Resources and Training Plan is used to
detail the roles, users, and the plans for training them. We have a number of resources at
our disposal to assist in building this plan including, but not limited to: Reuse Assessment,
Reuse Strategy, and the Reuse Adoption and Incentive Plan.
Asset Financial Estimate: There are three steps associated with generating this
deliverable, including:
a. Conduct Estimates: Determine the general asset program cost estimates. In order to
estimate this cost, the Reuse Strategy needs to be understood, as well as the
Resource Adoption and Incentive Plan and the Resources and Training Plan. These
artifacts provide the scope and timing for resources to work on asset manufacturing,
management, and use.
b. Determine Initial Funding Approach: With the initial cost estimates, the funding
approach needs to be determined. Often the overhead funding approach is used to
launch the initial asset activities. This overhead funding can be done at the enterprise
level, within the scope of a business unit, or on a project.
c. Determine Long-term Funding Approach: More mature asset programs can use a tax
approach on each project to fund the asset efforts in the long run. This funding
approach generally occurs when the asset efforts have proven viable to the enterprise.
72
Strategic Reuse with Asset-Based Development
Classification Schema: A classification schema is a structure of values used to classify
assets in the Repository. Models provide a good way to communicate and share the
classification schema. We want to ensure that we are setting up a Repository structure
that is logical for both those people submitting assets and for those people consuming
assets.
5.4.2 Definition
Next, we cover the Definition focus area.
Overview
There are multiple workflows that comprise the asset’s life cycle, for example, the activities of
submitting an asset to the Repository, the review and approval process, or the retirement and
archiving activities. The workflows need to be identified, and the key participants understood.
Often you must consider the type of asset or its categorization (for a specific business
domain), as well as which organizational unit owns the asset. All of these considerations are
factors in determining the workflows for assets.
Controlling the access to assets is a key element of governance. Determining who can do
what with an asset involves understanding the asset’s intended use and scope. Access™
control can be determined for assets of a given type, of a given classification, or of a given
owner. These factors must be considered, and the access control must be captured in the
Repository. Figure 5-14 depicts the capability pattern for the Definition focus area.
Figure 5-14 The activities within the Definition capability pattern
Activities and tasks
Next, we discuss activities and tasks.
Types and Rules Definition Activity
The Types and Rules Definition Activity contains the tasks shown in Figure 5-15 on page 74.
In this activity, we define our asset types, as well as the rules associated with those types.
Each type of asset will likely contain a unique set of artifacts. However, there must be a level
of commonality among assets of the same type. If there is too great a variation within an
asset type, we make it much more difficult for those people wanting to consume the asset.
Chapter 5. Asset-Based Development and Asset Governance Rational Method Composer plug-ins
73
Figure 5-15 The tasks within the Types and Rules Definition Activity
Workflow Definition Activity
The Workflow Definition Activity contains the tasks shown in Figure 5-16. In this activity, we
need to recognize that there are two levels of workflow for Asset-Based Development. There
are the workflows at the organizational level, which describe the structure of the organization
for supporting Asset-Based Development and the flow of activities in the organization. And
there are also asset-level workflows, which deal with asset submission, review, and
procurement. These are finer-grained workflows focusing on the asset-level activities and that
impact the state of the asset.
Figure 5-16 The tasks within the Workflow Definition Activity
Access Control Definition Activity
The Access Control Definition Activity contains the tasks shown in Figure 5-17 on page 75. In
this activity, we consider the classifications of our user community. Thought is given to the
types of assets to which these groups of users require access.
74
Strategic Reuse with Asset-Based Development
Figure 5-17 Tasks within the Access Control Definition Activity
Roles, tasks, and deliverables
Next, we discuss roles, tasks, and deliverables.
Types and Rules Definition Activity
Figure 5-18 depicts the Asset Governance Board role along with the tasks, deliverables, and
roles found within the Types and Rules Definition Activity.
Figure 5-18 Asset Governance Board role, associated tasks, and deliverables
Workflow Definition Activity
Figure 5-19 and Figure 5-20 on page 76 depict the Manager and Asset Governance Board
roles along with the tasks and deliverables found within the Workflow Definition Activity.
Figure 5-19 Manager, associated task, and deliverable
Chapter 5. Asset-Based Development and Asset Governance Rational Method Composer plug-ins
75
Figure 5-20 Asset Governance Board, associated tasks, and deliverables
Access Control Definition Activity
Figure 5-21 depicts the Administrator role, associated task, and deliverable found within the
Access Control Definition Activity.
Figure 5-21 Administrator role, associated task, and deliverable
Key deliverables
The five key deliverables associated with the Definition phase include:
Asset Rules and Policies: This deliverable is the rules and policies to which assets need to
comply to participate in the Repository.
This artifact is controlled by the Asset Governance Board and establishes the policies for
Administrators, asset manufacturing teams, and asset consumption teams.
The kinds of rules created include:
– Naming conventions for Asset Types, Assets, Artifacts, and Relationship Types
– Required support resources, length of support, and contact information for assets
– Asset classification requirements, including policies for tagging assets with
user-provided values and policies for classifying assets using category schema values
When creating these policy documents, be sure to include a version number on the
document.
Asset Type Specification: This deliverable describes the structure of asset types. Declare
one or more asset types to configure the Repository. Look for name collisions, as well as
similar asset types and artifacts with different names.
76
Strategic Reuse with Asset-Based Development
Each asset that is placed in the Repository will map to one of the types that we define.
Based on the asset type that is selected, the user submitting the asset will have to abide
by the constraints put into place by the asset type. The type definition will include
information, such as:
– Name: The type must have a unique and meaningful name.
– Purpose: Specify the purpose for the asset.
– Content: Define the artifacts that will comprise the asset.
– Relationships: Specify other asset types that are related to this asset type.
– Categories, schemas, and contexts, which are relevant, are included.
– Custom attributes or metadata elements on the asset type are included.
Asset Version Policy: A description of how assets must be versioned. Recall from earlier
that an asset will contain one or more artifacts. Therefore, there are generally two major
levels for versioning with assets: the asset version and the artifact version. The artifact
version is typically managed and dictated by the Source Configuration Management
(SCM) system, whereas the asset version is generally dictated by the policies of the
enterprise and managed by the Repository. As we define this policy, we will have to
ensure that we accommodate any distributed development requirements for both the
assets and the underlying artifacts.
Asset Workflow Specification: A description of the steps in an asset submission, review, or
procurement workflow. This artifact can be represented in various forms, such as a model,
text, or other format. The workflow must identify the steps, the participants, and the asset
states. Figure 5-22 shows how the different workflows relate to asset production,
consumption, and management.
Figure 5-22 Asset workflows
Community Map: A Community is an arbitrary collection of users, roles, and their assets.
A Community can be defined along several boundaries, including:
– Organizational unit
– Project
– Users with a common role, such as Business Analyst
Therefore, the Community Map describes the organization of the Repository in terms of its
Communities, user roles, and their permissions. The enterprise needs to determine
whether there will be one asset Repository or many asset repositories. In addition, for
each asset Repository, the organization of the assets, the teams, and the review
processes needs to be determined.
Chapter 5. Asset-Based Development and Asset Governance Rational Method Composer plug-ins
77
The Community becomes the primary element for organizing the Repository. An asset
lives in one Community. Roles and permissions are specified for a Community. Review
processes and other workflows are specified for a Community.
5.4.3 Enablement
Next, we discuss the Enablement focus area.
Overview
In the Enablement focus area, we define the teams needed to support the production,
consumption, and management of assets and identify the tools that they will use.
The tools for conducting Asset-Based Development must be selected and set up. Key to this
is understanding which roles will work with which tools throughout the Asset-Based
Development process.
Recall from earlier that the work in the focus areas often overlaps and occurs iteratively and
incrementally. Therefore, we start to see that there are dependencies between a number of
the activities, tasks, and deliverables. For example, work done in the Plan focus area will
have impact on the work done within the Enablement focus area, and the reverse is also true.
Figure 5-23 depicts the capability pattern for Enablement, which includes the following
activities:
Organization: This activity includes tasks, such as Create Asset Governance Board,
Create Asset Manufacturing Team, and Enable Asset Usage Teams.
Environment: This activity includes tasks, such as Determine Tools to Support
Asset-Based Development, Determine Topology, and Evaluate Cost of Ownership.
Figure 5-23 Capability pattern for Enablement
Activities and tasks
Next, we describe activities and tasks.
Organization Activity
The Organization Activity contains the tasks shown in Figure 5-24 on page 79. This set of
tasks is focused on defining the teams that will support the production, consumption, and
management of assets. When the teams are defined, we will then work to enable them on the
tools that have been identified as needed for supporting their work.
78
Strategic Reuse with Asset-Based Development
Figure 5-24 Tasks within the Organization Activity
Environment Activity
The Environment Activity contains the tasks shown in Figure 5-25. As mentioned previously,
in this activity, we focus on the tooling needed for supporting the reuse team.
The tooling for asset production and consumption activities needs to be similar to and easily
accessible to the way in which people perform their work today. Setting up an environment,
which naturally extends the way that people work today, will reduce the adoption and learning
curves required for Asset-Based Development.
We will also need tooling to support the management of assets, which is most likely a
Repository.
Figure 5-25 Tasks within the Environment Activity
Roles, tasks, and deliverables
Next, we discuss roles, tasks, and deliverables.
Organization Activity
Figure 5-26 on page 80 depicts the Manager role along with the tasks and deliverables found
within the Organization Activity.
Chapter 5. Asset-Based Development and Asset Governance Rational Method Composer plug-ins
79
Figure 5-26 Manager role and deliverables within the Organization Activity
Environment Activity
Figure 5-27 and Figure 5-28 on page 81 depicts the Administrator and Manager roles along
with the tasks and deliverables found within the Environment Activity.
Figure 5-27 Administrator role and deliverables in support of the Environment Activity
80
Strategic Reuse with Asset-Based Development
Figure 5-28 Manager role and deliverables in support of the Environment Activity
Key deliverables
The key deliverable associated with this phase is:
Asset Workflow Specification: As introduced earlier in the Planning focus area, this
deliverable provides a description of the steps in an asset submission, review, or
procurement workflow. In this focus area, we have defined the teams for asset production,
consumption, and management. In addition, we determined the tools that these groups
will use in order to fulfill their duties. This deliverable shows up as both an input and an
output within this focus area.
5.4.4 Measurement
Overview
Identifying the measurements important to your organization is key to the long-term and
sustainable use of assets. Measurement is often tracked at several levels, including:
Asset Owner and Producer measurements: Level of investment (hours, money, and time)
in an asset
Asset Consumer: Level of benefit and value delivered to the asset user
Repository: Level of activity on the Repository
Management: Value to the organization and return on investment (ROI)
Figure 5-29 on page 82 depicts the capability pattern for Measurement.
Chapter 5. Asset-Based Development and Asset Governance Rational Method Composer plug-ins
81
Figure 5-29 Capability pattern for Measurement
Tip: Notice that in this case the capability pattern contains tasks rather than activities.
Tasks
Next, we discuss the tasks.
Determine metrics to track
In this task, the Reuse Strategy must be evaluated regarding the metrics that the enterprise
wants to track.
There are several kinds of metrics to track, including metrics managed by the Repository,
metrics entered by Asset Owners or Producers, and metrics entered by Asset Consumers.
Because collecting metrics can be distributed among many roles and points in software
development, the asset rules, policies, and other governance documents must be updated
with the results of this task. A key value of defining metrics early in the effort is to establish a
common baseline for what a metric means, who creates the metrics, and where they are
captured. Without establishing this baseline, the metrics are too vague and left to individual
interpretation, which lacks clarity and does nothing to help the asset reuse work roll forward.
This task of defining how the asset program will be measured is a core requirement to the
success of the asset efforts to continue.
Report on asset
Reports can be generated graphically or textually. The metrics can be exported from the
Repository into reporting tools, or the Repository can render the reports.
Managers often requires reports on a periodic basis, which generally means Repositories
need a way to run reporting jobs and send them to the appropriate stakeholders.
Repositories must be integrated with portfolio and project management tools to aid the
generation of derived metrics.
Roles and deliverables
Next, we discuss roles and deliverables.
82
Strategic Reuse with Asset-Based Development
Determine metrics to track
Figure 5-30 depicts the Manager role along with the deliverables found within the Determine
Metrics to Track task.
Figure 5-30 Role and deliverable in support of Determine Metrics to Track
Report on asset
Figure 5-31 depicts the Asset Consumer role along with the deliverables found within the
Report on Asset task.
Figure 5-31 Role and deliverable in support of Report on Asset
Key deliverables
There are two deliverables associated with this phase:
Metrics Collection Plan: Describes what metrics will be captured, by whom, and how often.
When making these decisions, we need to remember the scope for the metrics: deciding
between project, community, or enterprise-wide metrics. Also, we need to recognize that
certain metrics are more easily captured than others.
Asset Report: A report of the asset activities in the Repository. Provide summaries of
asset and other Repository activities. The report must provide both qualitative and
quantitative information about the assets and related activities.
Chapter 5. Asset-Based Development and Asset Governance Rational Method Composer plug-ins
83
5.5 Asset-Based Development
As discussed earlier, Asset-Based Development is defined as:
“Asset-Based Development is developing software solutions (re)using cohesive, documented
software artifacts. It is organizing software development in a way that leverages previous
investments and influences the nature of future investments. It is speeding up development
and reducing cost and risk by reusing assets and artifacts to solve recurring problems.”
5.5.1 Manufacturing and usage cycle
The processes of Asset-Based Development can be described as two large cycles.
One of those cycles is the manufacturing cycle. As shown in Figure 5-32, in this cycle, the
producer creates an asset, the asset is reviewed and published to the asset Repository.
Figure 5-32 Manufacturing cycle
The other cycle is the Usage or Consumer cycle. As shown in Figure 5-33 on page 85, in this
cycle, the consumer finds, reuses, and provides feedback about the asset. This cycle repeats
each time that assets are reused.
84
Strategic Reuse with Asset-Based Development
Figure 5-33 Usage cycle
These cycles are connected and interact with each other. As shown in Figure 5-34, the usage
cycle receives assets from the manufacturing cycle and provides feedback (or requests) to
the manufacturing cycle. The manufacturing cycle receives feedback from the usage cycle
and updates and gives assets to the usage cycle.
Figure 5-34 Interaction between manufacturing and usage cycle
Chapter 5. Asset-Based Development and Asset Governance Rational Method Composer plug-ins
85
5.6 Asset-Based Development plug-in
As shown in Figure 5-35, the workproducts produced from Asset Governance will feed into
Asset-Based Development. As we work through the activities and tasks found in Asset-Based
Development, we will provide input back into our Asset Governance and will need to update
the associated governance workproducts.
Figure 5-35 Asset Governance workproducts shaping the Asset-Based Development process
Earlier, we discussed the fact that there are three major aspects to the asset life cycle,
namely produce, consume, and manage. These aspects play a prominent role in the
associated process guidance provided within the Asset-Based Development Rational Method
Composer plug-in.
Figure 5-36 on page 87 presents the capability pattern for Asset life cycle associated with
Asset-Based Development. The diagram provides a high-level view, showing the activities
found within the life cycle. Within each activity, you will find a number of tasks and steps that
will guide you in Asset-Based Development.
86
Strategic Reuse with Asset-Based Development
Figure 5-36 The asset life cycle capability pattern
Tip: In the remaining parts of the book, we leverage the asset life cycle as a framework for
the content. In Part 2, “Reusable Assets” on page 123, Part 3, “Service Assets in an SOA”
on page 333, and Part 4, “Patterns” on page 455, we use the life cycle as a basis for
chapters that discuss the creation, management, and use of assets. The discussion starts
with describing these topics in regard to assets in general and then delves into specific
types of assets, including patterns and services.
5.6.1 Produce reusable asset
Next, we discuss the Produce Reusable Asset Activity.
Overview
Let us take a more detailed look at the Produce Reusable Asset Activity.
This activity is described as:
“The production of a Reusable Asset really involves two steps: producing the Asset Artifacts
that comprise the asset and then packaging those artifacts into a reusable asset. Producing
asset artifacts can involve creating those artifacts from scratch, or it can involve harvesting
those artifacts from existing project artifacts.”
Chapter 5. Asset-Based Development and Asset Governance Rational Method Composer plug-ins
87
Activities and tasks
As seen in Figure 5-37, the Produce Reusable Asset Activity contains the following tasks:
Develop Asset Specification: Formal documentation that details the asset. This must
include a discussion of the artifacts found with the asset, variability points, the problem
that this asset will solve, as well as the context to which the asset applies.
Conduct Recurring Problem Analysis: For a specific problem, determine the scope to
which it recurs. Does the problem reoccur with a project, across projects, or across the
organization?
Create Asset: In this task, you create the asset implementation. This brings together the
artifacts with the asset and documentation and then packages and posts the asset.
Update Asset: You will see that an asset is often created in a iterative and incremental
fashion. Therefore, you must expect to spend time in updating, enhancing, and adjusting
assets that have already been built.
Review and Test Asset: The asset review processes are executed to evaluate and
approve an asset.
Publish or Deploy Asset: Make the asset visible to a target audience, either in the scope of
the Repository or in another tool.
Figure 5-37 Capability pattern for Produce Reusable Asset
88
Strategic Reuse with Asset-Based Development
Roles, tasks, and deliverables
Figure 5-38 depicts the Asset Producer role along with the tasks and deliverables that the
Asset Producer role participates in building.
Figure 5-38 Asset Producer role and associated deliverables
Figure 5-39 depicts the Asset Consumer role along with the tasks and deliverables that the
Asset Consumer role participates in building.
Figure 5-39 Asset Consumer role and associated deliverables
Figure 5-40 depicts the Asset Owner role along with the tasks and deliverables that the Asset
Owner role participates in building.
Figure 5-40 Asset Owner role and associated deliverables
Figure 5-41 on page 90 depicts the Asset Reviewer role along with the tasks and deliverables
that the Asset Reviewer role participates in building.
Chapter 5. Asset-Based Development and Asset Governance Rational Method Composer plug-ins
89
Figure 5-41 Asset Reviewer role and associated deliverables
Figure 5-42 depicts the Community Administrator role along with the tasks and deliverables
that the Community Administrator role participates in building.
Figure 5-42 Community Administrator role and associated deliverables
Key artifacts
Next, we discuss key artifacts.
Asset specification
The asset specification describes the asset being proposed. The specification must provide
technical justification for the asset. Not all assets require an asset specification. In general,
assets that require or are expected to require a meaningful investment for the organization or
assets that are of sufficient complexity or reuse scope as to require multiple teams will benefit
from creating an asset specification. The asset specification can go through several iterations
as greater understanding of the problem and the solution are gathered from stakeholders.
The need for this asset has generally been established, and sometimes sponsorship and
support for the asset has been secured. This specification can be used by the support teams
to understand the asset. The specification is also used by the Asset Owner or Producer to
create and update the asset.
This specification is largely intended for technical teams to use, although it can be shared
with sponsors and technical management as part of making decisions to fund and staff the
effort to build, maintain, and support the asset.
90
Strategic Reuse with Asset-Based Development
Identify items, such as:
Asset name
The problem that the asset is expected to solve
Description of the solution
Expected contexts
Expected artifacts in the asset
Asset relationships and dependencies
Possible categorization or classification:
– Business
– Technical
– Organizational
Expected Asset Consumer skills
How the expected Asset Consumer will use the asset
Asset Owner and maintainer: Sponsor and funding
Estimated asset development effort
Estimated Asset Consumer benefits
Reusable asset
Recall that we earlier defined an asset as:
“An asset is a collection of related artifacts that provides a solution to a problem. The asset is
customizable through its variability points, meaning those locations within the asset (or more
specifically, within the asset’s artifacts) that can be customized.”
You can consider an asset to be a candidate for reuse when it fits a cross section of:
Providing a solution to your problem
Fitting your technical context
Meeting your business objectives
Fitting within your delivery process
Integrating within your organizational structure
5.6.2 Manage reusable assets
Next, we describe managing reusable assets.
Overview
The purpose of asset management is to provide control and organization to the review and
approval workflow and to deliver assets to consumers in a managed, scalable manner. Asset
management is subject to and operates under the policies and guidance from Asset
Governance.
Note that Manage Reusable Assets is a capability pattern. Figure 5-43 on page 92 provides
an overview of the activities found within the Manage Reusable Assets capability pattern.
Chapter 5. Asset-Based Development and Asset Governance Rational Method Composer plug-ins
91
Figure 5-43 Capability pattern for Manage Reusable Assets
Activities and tasks
Next, we discuss activities and tasks.
Review and Approval Activity
The tasks within the Review and Approval Activity are depicted in Figure 5-44. Depending on
the role being played and its associated scope, the tasks performed within the Review and
Approval Activity will vary. For instance, in the case of an Asset Consumer, the Asset
Consumer is interested in searching the Repository and determining which are the right
assets for the Asset Consumer’s organization. The Asset Consumer looks at the scope of a
project (either current or future) and wants to find and evaluate assets within the Repository.
In the case of the Asset Reviewer role, the Asset Reviewer is part of the process of validating
that an asset belongs in a Repository. Therefore, this role executes one or more asset review
processes to evaluate and possibly approve an asset.
In the case of the Community Administrator role, this role’s focus is ensuring that approved
assets are published or deployed, making the asset visible within the Repository or another
tool.
Figure 5-44 Tasks within the Review and Approval Activity
92
Strategic Reuse with Asset-Based Development
Administration and Monitoring task
The Administration and Monitoring task is where we make sure that the asset Repository is
functioning as planned, has the correct set of assets, and that we understand how the
Repository is being used. Therefore, there are three key tasks within this activity:
Configure Repository: Plan and execute steps to administer the Repository in order to be
used.
Report on Asset: Provide summaries of asset and other Repository activities.
Remove Asset: Describes the conditions when an asset is removed from visibility in the
Repository and how the removal takes place.
The tasks within the Administration and Monitoring Activity are depicted in Figure 5-45.
Figure 5-45 Tasks within the Administration and Monitoring Activity
Roles, tasks, and deliverables
Next, we discuss roles, tasks, and deliverables.
Review and Approval Activity
Figure 5-46, Figure 5-47 on page 94, and Figure 5-48 on page 94 depict the Asset
Consumer, Asset Reviewer, and Community Administrator roles found within the Review and
Approval Activity along with their associated tasks and deliverables.
Figure 5-46 Asset Consumer role and deliverables
Chapter 5. Asset-Based Development and Asset Governance Rational Method Composer plug-ins
93
Figure 5-47 Asset Reviewer role and associated deliverables
Figure 5-48 Community Administrator role and associated deliverables
Administration and Monitoring Activity
Figure 5-49 and Figure 5-50 on page 95 depict the Community Administrator and Asset
Consumer roles found within the Administration and Monitoring Activity along with the
associated tasks and deliverables.
Figure 5-49 Community Administrator role and associated deliverables
94
Strategic Reuse with Asset-Based Development
Figure 5-50 Asset Consumer and key deliverables
Key deliverables
Next, we discuss key deliverables.
Review and Approval Activity
There are two key artifacts associated with the Review and Approval Activity:
Reusable Asset: The key thing to remember is that each of the roles wants to make sure
that the right assets are available. The perspectives of the roles bring a different focus on
the scope and intent of the asset. In the case of the Asset Consumers, they want to find an
asset that meets the need for a project. The Asset Reviewer is working to ensure that the
assets in the Repository are high quality assets and appropriate to the needs of the
organization. The Community Administrator is focused on making sure that assets that
have been approved are visible to the target audience.
Asset Review: This artifact provides the basis for the Reviewer’s vote. The Asset Review
is typically submitted to the Repository and attached to the asset. The Asset Review must
generally not be visible to Asset Consumers after the asset has been approved.
Administration and Monitoring Activity
There are three key artifacts associated with the Administration and Monitoring Activity:
Asset Repository: We expect that the asset Repository will be installed and configured in a
manner that is appropriate to the needs of the organization.
Asset Types: Within the asset Repository, each asset will have to map to one of the
provided asset types. The asset types describe what can be contained in the asset, what
relationships an asset can or must have, and so forth.
Asset Report: The asset report contains information regarding the assets in the
Repository, their usage, and associated feedback.
5.6.3 Consume Reusable Asset Activity
Next, we discuss the Consume Reusable Asset Activity.
Chapter 5. Asset-Based Development and Asset Governance Rational Method Composer plug-ins
95
Overview
Let us take a more detailed look at the Consume Reusable Asset Activity.
This capability pattern is focused primarily on:
Locating reusable assets
Evaluating the located assets
Applying the located assets to the project
Provide Asset Feedback on the applied assets, including identifying the need for assets
that cannot be located
The work is best done when the Asset Consumer has a well-defined problem that needs to be
resolved. The Asset Consumer’s understanding of the problem directly affects the activities of
searching and evaluating an asset for its relevance. A key aspect to an asset is that it is
targeted to a specific context. To successfully reuse assets, we need to understand our
current context before we evaluate and reuse.
Note that the consuming assets play a key role in the production of assets. This suffices in a
number of situations, such as:
Asset feedback: After using an asset, the feedback provided on the asset helps the Asset
Producers understand how their asset is used, areas for improvement, and aspects of the
asset that worked well.
Identification of needed assets: An Asset Consumer is one of the best sources for
identifying where an asset is needed. An Asset Consumer often has the domain specific
knowledge and can guide an Asset Producer both to where an asset is needed as well as
what the asset must do or contain.
Asset specialization: There are times when an asset is a close fit for a problem, but it is
not quite an exact fit. The Asset Consumer can take the asset and determine that it is in
the best interests of the team to customize the asset. The customized version of the asset
might represent a variation that other Asset Consumers want to reuse as well. Working
with the asset production team, the variation might end up as a new asset in the
Repository.
Figure 5-51 on page 97 depicts the tasks that are found within the Consume Reusable Asset
Activity.
96
Strategic Reuse with Asset-Based Development
Figure 5-51 Capability pattern for Consume Reusable Asset Activity
Activities and tasks
The tasks within the Consume Reusable Asset Activity include:
Search Asset: This task includes steps for searching, discovering, browsing, and
evaluating assets.
Use Asset: Use the asset in the context of a consumer. This task includes a task to
retrieve the asset and if necessary extend the asset.
Develop Asset Specification: The task of identifying and specifying an asset shows up
across each of the life cycle phases. This is an important task with which all team
members must have familiarity. Often, those team members who are the most skilled in
building asset implementations have the least domain-specific knowledge. Therefore, they
rely upon those team members in the domain to identify possible assets and to create the
associated asset specifications.
Roles, tasks, and deliverables
Figure 5-52 depicts the Asset Consumer role found within the Consume Reusable Asset
Activity along with the associated tasks and deliverables.
Figure 5-52 Asset Consumer role and associated deliverables
Chapter 5. Asset-Based Development and Asset Governance Rational Method Composer plug-ins
97
Key deliverables
There are three key artifacts associated with the Consume Reusable Asset Activity:
Reusable Asset: An Asset Consumer interacts with the asset Repository, searching to find
assets that are relevant to the current problem and context.
Reuse Feedback: As the Asset Consumer uses an asset, it is critical that the Asset
Consumer provides feedback on the asset, which is beneficial both to future Asset
Consumers, as well as those that produced the asset.
Asset Specification: In cases where an asset does not yet exist, the Asset Consumer can
create an Asset Specification that details the requested asset. The specification must
provide technical justification for the asset. Not all assets will require an asset
specification. In general, assets, which will require or are expected to require a meaningful
investment for the organization or are of sufficient complexity or reuse scope as to require
multiple teams, will benefit from creating an asset specification. The asset specification
can go through several iterations as greater understanding of the problem and the solution
are gathered from stakeholders.
5.7 When to use these processes
When you start Asset-Based Development and you are still figuring out an adoption model
and commitment level to this process, you might decide that you do not initially want to
leverage all of the content. As mentioned earlier, RUP and, in turn, these plug-ins, are meant
to provide you with a process framework. It is up to you and your organization to figure out
which content fits with what you want to do and accomplish.
With using Rational Method Composer and Rational Unified Process, you have tooling and a
set of content based on best practices to pull together a process and approach that is unique
to your organization.
Also, remember that although these plug-ins are packaged using Rational Method Composer,
they do not force you to follow or adopt the Rational Unified Process. You are able to
leverage this guidance and merge it into other processes.
5.8 Asset process views
There are five major views in a default configuration of the Asset-Based Development and
Asset Governance content. These views are driven by user profiles, usage scenarios, and
scope:
To get started, a novice uses the Asset-Based Development and Asset Governance
views.
For reference purposes, use the Asset-Based Development and Asset Governance views.
To understand what tasks are relevant to a particular role, use the Asset-Based
Development Roles view.
To understand the tasks that are relevant to a particular level of the organization, a
manager uses the Asset-Based Development Levels view.
To understand the organizational templates available to help roll out an Asset-Based
Development process, use the Organization Templates - Assets view.
98
Strategic Reuse with Asset-Based Development
When publishing a custom process configuration, you can choose which of these views to
leverage. In addition, you can add your own client views as determined by the needs and
preferences of your organization.
5.9 Creating extensions
The Asset-Based Development and Asset Governance content is generic in regard to the
type of context and process to which it can be applied. For instance, it can be applied to:
Business, software, and so forth
Software Development Process: RUP and so forth
Domain: SOA and so forth
The intent is that you can use this content and combine it with other plug-ins from the RUP
library. These plug-ins can be sourced from within your organization, from IBM, or from a
third-party organization. Possibilities to consider include:
Create your own configuration and include Asset-Based Development specific views
Create composite capability patterns and delivery processes
Write your own Rational Method Composer extension (plug-in)
Extend the current Asset-Based Development plug-ins (and other applicable RUP
plug-ins)
Write guidance for an Asset-Based Development solution to a specific domain (for
example, SOA)
5.10 ZYX Electronics development case
Next, we discuss the ZYX Electronics development case.
5.10.1 What is a development case
A development case, as defined by the RUP Environment discipline, consists of a description
of a software development process that is tailored for an organization or a project.
In our case, we are talking about the development case used to develop the contents of this
book, that is, the ZYX Electronics development case.
The role responsible for creating the development case is the process engineer, responsible
for providing teams with the organization’s development process.
5.10.2 Content sources for the ZYX Electronics development case
We create a simple development case centered around Asset-Based Development based on
the following processes:
Rational Unified Process
RUP for Asset-Based Development V3.0 and Asset-Based Development Governance
Plug-in V1.0
IBM RUP for Service-Oriented Modeling and Architecture V2.4 (RUP SOMA)
Chapter 5. Asset-Based Development and Asset Governance Rational Method Composer plug-ins
99
IBM Rational Method Composer plug-in for SOA Governance V1.0
ZYX Electronics best practices
In addition, content for the development case comes from proven best practices that we, as
the authoring team, have applied successfully in the field.
Looking at the list of content sources, you notice that we have two types of governance
shown: SOA Governance and Asset Governance. In addition, we have two life cycles
captured within the Asset-Based Development and RUP SOMA plug-ins. Figure 5-53 shows
that there is a mapping between these sets of assets. Part 3, “Service Assets in an SOA” on
page 333 of this book discusses this topic in more detail.
Figure 5-53 Mapping SOA life cycle and SOA Governance to Asset life cycle and Asset Governance
5.10.3 More information
For more information regarding the SOA plug-ins, refer to Part 3, “Service Assets in an SOA”
on page 333 and the following SOA-focused information:
Building SOA Solutions using the Rational SDP, SG24-7356-00:
http://www.redbooks.ibm.com/abstracts/sg247356.html?Open
For more details about how we built the development case, refer to Appendix B,
“Integrating Asset-Based Development into a process” on page 713.
To access and download the RMC plug-ins that are referenced in this chapter, use the
following links:
– IBM Rational Method Composer plug-in for SOA Governance V1.0:
http://www.ibm.com/developerworks/rational/downloads/06/plugins/rmc_soa_gov/
soa_plugin.html
– IBM RUP for Service-Oriented Modeling and Architecture V2.4:
http://www.ibm.com/developerworks/rational/downloads/06/rmc_soma/
100
Strategic Reuse with Asset-Based Development
– RUP for Asset-Based Development V3.0 and Asset-Based Development Governance
Plug-in V1.0:
http://www.ibm.com/developerworks/rational/downloads/07/rup_abd_gov/index.ht
ml
Chapter 5. Asset-Based Development and Asset Governance Rational Method Composer plug-ins
101
102
Strategic Reuse with Asset-Based Development
6
Chapter 6.
Value, impact, and return on
investment
In this chapter, we focus on the value, impact, and return on investment (ROI) that can be
achieved via assets and a reuse program. After reading this chapter, you will understand that
there are a number of sources for metrics, asset considerations that must be part of the value
discussions, and metrics that must go into return on investment calculations.
6.1 Impact and ROI
We cannot give you a simple, compact formula, such as E = mc2, to use in your work as you
track and manage your assets to help you calculate the return on investment and the impact
of an asset, or ideally, to allow you to calculate these figures in advance of developing the
asset. Unfortunately, we are not yet at the point where there is a simple formula. However,
with the importance of this topic, we cannot let the lack of a single, simple formula hold us
back.
When looking at moving to Asset-Based Development, there are a number of costs
associated with adopting this approach:
Purchase, customization, and rollout of a development process
Tooling to create assets
A Repository for the assets
Enablement and training for producing assets
Enablement and training for consuming assets
For certain organizations, business model evaluation and update as you migrate to an
asset-based approach
Creation of the asset (including spending time to make the asset both reusable and
consumable)
Consumption and usage of the asset
Maintenance and support of the asset
© Copyright IBM Corp. 2008. All rights reserved.
103
To justify these costs, both initially and ongoing, the organization needs to be able to see that
there is a positive impact from the assets and that a positive ROI is achieved in a specified
time frame. Therefore, we need to find ways to measure and calculate the value of the asset,
which are accurate and can be defended when placed under scrutiny.
And regardless of how strongly we believe in Asset-Based Development, we still need to be
able to provide metrics that support the decision to adopt Asset-Based Development. As
discussed in our opening chapter, those of us working in software delivery are now more than
ever integrated with the business. Therefore, the decision to adopt Asset-Based
Development is a business decision and requires information that allows the business to
choose how to make investments.
6.1.1 Avoid over-measuring
In this chapter, we will look at a large number of metric-generating aspects and measurement
points within a reuse program. The intent is not to get you to leverage all of these data
sources and collect as much data as possible. We do not want you to spend all of your time
locating data sources and tracking and compiling data. That is a project unto itself.
Jeffrey Poulin, in Measuring Software Reuse, proposes that the Relative Cost of Writing for
Reuse is 1.5, which means that there is an additional 50% cost when building reusable
software. He also proposes that the Relative Cost of Reuse is 0.2. This means that the
relative cost to use the asset is 20% of what it cost compared to having to rebuild the solution.
These relative cost figures were arrived at by conducting an analysis across a range of other
formulas and results achieved in reuse situations. In most cases, these relative cost numbers
were “close enough” to the result from other more complex efforts that it raises the question,
“Is it worth spending time gathering data and calculating more “accurately”?”.
Keeping this in mind, we do want you to be aware of the data sources and aspects of
development and reuse that are at your disposal. Based on the availability of data, your
project constraints and goals, and the needs of the organization, you will need to pick the
data and metrics that best fit your needs. Before starting to collect the data, spend time
figuring out what questions you will be answering with the information that is collected.
Many of the more common reasons why we measure include:
Communicate effectively: Measurement supports communication among stakeholders.
Objective measures reduce ambiguity.
Identify and correct problems early: Measurement facilitates proactive management.
Potential problems are identified early and managed. Problems discovered late are more
difficult to manage and can be more costly. Good project managers do not wait for
problems to arise; they anticipate problems.
Make informed trade-offs: Decisions in one area often impact other areas, but these
decisions are usually necessary. Measurement helps managers assess the impact.
Track specific project objectives: Measurements help track specific objectives, such as: “Is
the project on schedule?”, “Is the quality improving?”, or “Is the system ready to be
delivered?”
Manage risks: Rational Unified Process (RUP) describes a risk-focused approach to
software development. Why not use measurements to track risk areas and reduce risks on
projects?
Defend and justify decisions: Managers must effectively defend and justify project
performance decisions. Measurement provides the rationale for selecting the best
alternatives.
104
Strategic Reuse with Asset-Based Development
Remember this advice as you work your way through the remainder of this chapter. For your
organization and situation, which metrics will provide the most value? How will this
information be used to assist in rolling out and then managing your asset reuse program?
How can this information be used to improve an existing reuse program? How can this
information be used to help align a reuse program with the needs of the business?
6.2 Not all assets are equal
An asset can contain a large variety of artifact types. And, assets can be built from a large
number of tools. Thinking that all assets are equal in value and that anything can be an asset
leads us into situations where we have an asset Repository that is viewed as a scrap heap
and dumping ground rather than a vault containing valuable resources. Therefore, we need to
remember that not all assets provide the same value to the organization. Therefore, we want
to find ways to guide ourselves and our teams toward the assets that provide the most value
to the organization.
There are four major perspectives that we can leverage as we analyze the value of an asset.
These perspectives include:
Asset production: In this perspective, we want to see how much support is in place to build
a high quality and consumable reusable asset. The Asset Production scorecard is found in
Table 6-1. Questions to ask include:
– Is there associated tooling that supports points of variability? Support for testing the
asset? Packaging the asset? Composition of an asset from other assets? Support for
documenting the asset?
– What is the cost to produce the asset?
– Will the asset support and align with industry standards?
– In the case of a generative asset, is there support in place to update and customize the
content when it is generated?
Table 6-1 Asset Production scorecard
Category
Possible values
Guidance
Asset tooling support:
Points of variability
{Yes | No}
Does the asset production tooling
support points of variability?
Packaging
{Yes | No}
Does the asset production tooling
support the packaging of the asset?
Documenting
{Yes | No}
Does the asset production tooling
support and account for the creation
of documentation in support of the
asset?
Support for composition
{Yes | No}
Does the asset production tooling
support the creation of new assets via
the composition of existing assets?
Support for asset analysis
and methodology
{Yes | No}
Does the asset production tooling
support the process associated with
building this type of asset?
Asset testing
{Yes | No}
Does the asset production tooling
support the testing of the asset?
Chapter 6. Value, impact, and return on investment
105
Category
Possible values
Guidance
Asset dependencies
{Yes | No}
Does the asset have dependencies on
other assets?
Asset specification
{Yes | No}
Does an asset specification exist?
Reference solution
{Yes | No}
Does a reference solution exist?
Cost to produce
#
What is the cost to build the asset? If
using this scorecard in advance of
building the asset, enter an estimate.
If using the scorecard post-asset
construction, enter the actual cost.
Industry standard support
{Yes | No}
Does the asset leverage and adhere
to industry standards?
Customizability of the asset
{None | Low |
Medium | High}
Has the asset been built so as to
support customization via points of
variability?
Customizability of the output
{None | Low |
Medium | High}
In the case of a generative asset, Can
the output of the asset be
customized?
Time taken to build asset
{Low | Medium |
High}
N/A
Run time compared to design
time
{Run-time |
Design-time}
Is this a design time or a runtime
asset?
Asset production process
{Yes | No}
Will a process be followed in building
the asset? Examples of expected
processes to be leveraged include
SOMA, pattern-based engineering,
Exemplar Authoring, and so forth.
Asset consumption: In this perspective, we look at the support in place for those users
consuming a certain type of asset. The Asset Consumption scorecard is found in
Table 6-2 on page 107. Questions to ask include:
– Is there associated tooling that supports working with points of variability? Is the
documentation for the asset integrated with the working environment? Does the
environment support the composition of assets into a larger solution? Is there support
for customizing the output from the asset (in the case of a generative asset)?
– Is there expertise available to support the use of the asset?
– How much skill is needed to learn how to use the asset? How much skill is needed to
use the asset?
– Is there supporting documentation available? What is its quality?
106
Strategic Reuse with Asset-Based Development
Table 6-2 Asset Consumption scorecard
Category
Possible values
Guidance
Reuse style
{Black Box | Gray Box | Glass
Box | White Box}
Ideally, we want to have assets
that either can be reused as is
or assets that provide points of
variability that control and
manage how the asset can be
adjusted. White Box is the least
preferred, because it permits
unlimited changes.
Asset usage
{Compositional | Generative}
Another aspect to consider is
whether the asset is meant to
generate content, or if it is
meant to be part of a larger
composition.
Points of variability
{None | Low | Medium | High |
Unlimited}
Preferably, we have a limited
set of points of variability. A
high number of points of
variability can mean that it will
be difficult to learn and use the
asset. Unlimited, which is an
undesirable trait, is the choice
to use if the asset is considered
White Box. Unlimited is an
undesirable trait for an asset. If
the asset is Black Box or Gray
Box, the only option for this
selection is None. An asset that
has a high number of points of
variability is considered
Fine-grained. An asset that
has a low number of points of
variability is considered
Coarse-grained.
Tooling support:
N/A
An important aspect of working
with an asset is whether the
tooling that is meant to be used
in conjunction with the asset
actually supports reuse.
Support for reuse from the
tooling can make reuse easier,
more productive, and
enjoyable.
Import
{Yes | No}
Does the tooling used to
consume the asset support
importing the reusable asset?
Customize via points of
variability
{Yes | No}
Does the tooling used to
consume the asset support the
customization of the asset
through its points of variability?
Ease of asset consumption
{Low | Medium | High}
Is it easy to consume assets
within the tooling? Higher ease
of use is preferred.
Chapter 6. Value, impact, and return on investment
107
Category
108
Possible values
Guidance
Integrated documentation
{Yes | No}
Is the asset’s documentation
accessible from within the
tooling?
Leveraging compositional
features of asset
{Yes | No}
Does the tooling support the
compositional features and
aspects of the asset?
Leveraging generative
features of asset
{Yes | No}
Does the tooling support the
generative features and
aspects of the asset?
Customize output of asset
{Yes | No}
In the case of a generative
asset, does the tooling support
updating of the output from the
asset? Does this account for
support of reapplying the
asset? Is there support for
iterative development?
Cost to consume
#
Enter a dollar figure
representing the cost to
consume the asset. This must
include the cost to learn how to
use the asset, as well as the
cost to use and apply the asset.
Complexity
{Low | Medium | High}
From a consumption point of
view, how complex is the asset?
Ease of use
{Low | Medium | High}
From a consumption point of
view, how easy is it to use the
asset?
Ease of learning
{Low | Medium | High}
From a consumption point of
view, how easy is it to learn to
use the asset?
Expertise available to support
asset
{None | Low | Medium | High}
How much expertise is
available to support the use of
the asset?
Location of support
{Internal | External}
Is the expertise internal to the
organization or external?
Consumer’s required skill level
{None | Low | Medium | High}
What is the skill level required
to work with this asset?
Time taken to use asset
{None | Low | Medium | High}
How much time does it take to
successfully use the asset?
Expected time to modify and
reuse the asset
{None | Low | Medium | High}
Preferably leveraging the points
of variability, how long does it
take to modify the asset?
Expected time to modify and
reuse the output from the asset
{None | Low | Medium | High}
How much time does it take to
modify the output from the
asset?
Strategic Reuse with Asset-Based Development
Category
Possible values
Guidance
Presence and quality of
supporting documentation
{None | Low | Medium | High}
Is there documentation
supporting the asset? What is
the level of quality of the asset
documentation?
Asset’s alignment with iterative
development
{None | Low | Medium | High}
Does the asset support iterative
development? Especially
important for design-time,
generative assets.
Run time compared to design
time
{Run-time | Design-time}
Is this a design-time or a
run-time asset?
Asset management: In this perspective, we look at how well the asset can be managed.
Part of this information might not be available until after the assets have already been put
into use. The Asset Management scorecard is found in Table 6-3. Questions to ask
include:
– Does the asset align with the categorization and classification system in place?
– What feedback has been received about the asset?
– What is the change history for the asset? Is there a great deal of churn?
– How many times has the asset shown up in searches? How many times is the asset
reused?
Table 6-3 Asset Management scorecard
Category
Possible values
Guidance
Number of times that the asset
has been reused
#
Leveraging metrics from the
asset Repository, how many
times has the asset been used?
Number of times that the asset
has been considered for reuse
#
Leveraging metrics from the
asset Repository, how many
times has the asset been
considered for reuse?
Asset feedback and ranking
#
What is the user feedback on
the asset? Usually, this value is
captured as a number.
Alignment with categorization
and classification
{Yes | No}
Does this asset align with the
classification system used in
the Repository?
Change history
{Never | Infrequent | Frequent}
How often is the asset
updated?
Legal contracts in place
{Yes | No}
Are any necessary legal
contracts, licenses, and so forth
in place to allow the
organization to use the asset?
Asset defects
{None | Low | Medium | High}
How many defects are reported
against the asset?
Expected shelf life for the
asset?
{Short | Medium | Long}
How long do you expect that
this asset will be in use and
relevant?
Chapter 6. Value, impact, and return on investment
109
Alignment with business: In this perspective, we look at how well the asset aligns with and
supports the business. Part of this information might not be available until after the assets
have already been put into use. The Alignment with Business scorecard is found in
Table 6-4. Questions to ask include:
– Is this asset targeted to a business or technology domain?
– How often does the issue occur that the asset addresses?
– From where will funding for the asset come?
Table 6-4 Alignment with Business scorecard
Category
Possible values
Guidance
Domain
{Business | Technology}
Is this asset tied to a specific
business or technology
domain?
Domain specific
{Domain Specific | Domain
Independent | Application
Dependent}
Is this asset domain specific,
domain independent, or
application dependent?
Alignment with business
direction and strategy
{None | Low | Medium | High}
What is the alignment between
the asset and the business
strategy?
Frequency of underlying
recurring problem
{Never | Infrequent | Frequent}
How often does the underlying
problem that the asset
addresses occur?
Cost of addressing underlying
problem manually
#
What is the cost of manually
addressing the problem that the
asset handles?
Fund creation
{Yes | No}
Is the business willing to fund
the creation of the asset?
Support and maintenance
funding
{Yes | No}
Is the business willing to fund
the support and maintenance of
the asset?
The scorecard contains a collection of subjective and objective data points to consider as you
analyze an asset. Generally, we expect to limit building assets with the following
characteristics:
White Box: Providing the consumer of the asset with too much freedom is likely to greatly
diminish the impact of the asset.
Lack of an asset creation process: An asset creation process will often guide you to
successfully identify the necessary points of variability on an asset. Lack of a process
often leads to assets that overestimate the amount of required variability.
Lack of tooling support for reuse: Whether producing or consuming an asset, you want
tooling that supports the asset, points of variability, and asset import and export.
Limited automation in support of the asset: Although assets, such as best practice
documents, have value, they require each user of the asset to follow through with a
significant amount of manual work in leveraging the “asset”. Therefore, you will want to
move to leverage automation as much as possible.
110
Strategic Reuse with Asset-Based Development
You can use this scorecard at a number of times, including:
Pre-asset and post-asset creation: Before you build an asset, use the scorecard as a
guide in determining the value of the asset. In addition to providing you with an initial
indication of the value of the asset, it will remind you of key considerations to remember as
you build your asset. When the asset has been built, use the scorecard as a checklist to
ensure that attention has been paid to key details.
Pre-asset and post-asset consumption: Just as there is a cost to build a reusable asset,
there is a cost to consume the asset. Therefore, a consumer is looking for assets that add
value and that are easy to consume. There is little value to an Asset Consumer if the asset
that the Asset Consumer finds has limited consumability or poor quality. Also, a consumer
wants to figure out how customizable the asset is and whether it can be made to fit into
that specific consumer’s situation.
6.3 Gathering data
The value that is generated from the formulas that we use will be highly dependent on the
accuracy and quality of the input data. As the saying goes, “garbage in, garbage out”. We
want to make sure that we are capturing accurate and supportable data.
As mentioned earlier, there are startup costs associated with both adopting Asset-Based
Development and then ongoing costs as we produce, consume, and manage our assets. Let
us look at the data sources available both in support of starting up Asset-Based Development
and then in support of the ongoing funding needed.
When gathering data, try to leverage automated sources as much as possible. Leverage
tools, such as Rational Asset Manager, WebSphere Service Registry and Repository,
Rational Portfolio Manager, Rational Project Console, Rational ClearCase, and Rational
ClearQuest. Remember that it is highly unlikely that you will capture all of the metrics that you
require based on just one source or tool.
For example, a key aspect of reusable assets is that the asset is indeed reused. However, it is
often difficult to determine how an asset is being reused. This becomes even more difficult in
large and distributed organizations. When using an asset Repository, you are able to track
how many times an asset is downloaded, by whom, the types of assets, and so forth.
Figure 6-1 on page 112 shows one of the metrics windows from Rational Asset Manager.
Although this window provides us with useful information, it is insufficient to use for justifying
investment in assets. In addition, this information comes in after much of the development
cost has been incurred.
Chapter 6. Value, impact, and return on investment
111
Figure 6-1 Repository metrics
A Repository has additional metrics that can be added to the mix. As Figure 6-2 on page 113
shows, these metrics can be categorized by role.
112
Strategic Reuse with Asset-Based Development
Figure 6-2 Metrics by role
Successfully measuring the reuse program is based on the fundamental premise of a
consistent measurement and comparison framework. Crucial to this framework is the need to
come to agreement early about how reuse will be measured in the organization. There must
be agreement on the metrics and the definition of how those metrics are calculated and
captured for reasonable comparison and reporting.
Identifying the business needs and the measurements for meeting those needs ultimately
guides the organization to the set of behaviors for addressing the needs. The reuse program
must operate within the context of the business needs. Progress toward meeting those needs
must be measured on a regular basis. To do this, the following list identifies business
motivators for conducting reuse activities. The metrics for these motivators and the approach
for collecting them must be defined. In practice, there must be a minimal set of motivators that
are initially selected; when selected, the proper metrics and measurement techniques must
be put in place:
Reduce development costs.
Reduce maintenance costs.
Increase productivity.
Improve product quality.
Provide consistent look-and-feel.
Remove barriers to entry for new products.
The general framework for categorizing these metrics is illustrated in Table 6-3 on page 109.
Chapter 6. Value, impact, and return on investment
113
Figure 6-3 Reuse metrics framework1
6.3.1 Startup data sources
When starting an Asset-Based Development initiative, you will need to have data that
supports the investment. There are a number of data sources that can be leveraged to
support this decision, including:
Your own organization’s Software Delivery Metrics:
– How long does it take to deliver a project? Associated metrics to find include projects
on time, number of delays, length of delays as a percentage of overall delivery time,
and so forth.
– Success and failure rate for projects
– Amount of source code (Source Lines of Code (SLOC), Kilo Lines of Code (KLOC),
lines of code (LOC))?
– Function points?
Your own organization’s pressure points, including aspects, such as:
– Backlog of projects
– Skill shortages
– Resource constraints
Existing reuse within your organization: Discuss reuse occurrences that are already
happening with your Architects and Designers.
Industry metrics: Consult industry groups and analysts.
Case studies: Consult with software vendors and service providers asking for references
and case studies.
Research papers: Review papers from researchers both in academia, as well as in private
industry.
Books: Review literature on the topic:
– For example, in Software Reuse: Architecture, Process, and Organization for Business
Success, Jacobsen et al estimate the following benefits of systematic reuse:
1
114
•
Time to market: 2 to 5 times reduction
•
Defect density: 5 to 10 times reduction
•
Maintenance cost: 5 to 10 times reduction
Adapted from Lim, Wayne C., MANAGING SOFTWARE RE-USE, 1st, ©1998. Electronically reproduced by
permission of Pearson Education, Inc., Saddle River, NJ.
Strategic Reuse with Asset-Based Development
– Another excellent resource on the topic is Measuring Software Reuse, Jeffrey S.
Poulin.
Existing assets: Consult with industry sources to find existing assets. What benefits are
users told to expect from using these assets?
Pilot projects: If more data is needed, it might make sense to request partial funding to
support a pilot project. A real-world test drive of this approach within your organization will
provide additional metrics and guidance about what it takes to start up the program,
issues that might arise, and so forth.
6.3.2 Ongoing data sources
After an Asset-Based Development program is put into place, we will continue to need to
gather data to support the ongoing funding of the program.
Tip: In addition to using these data points to support investment, a positive side effect of
gathering this information is that it can also be used to guide you to areas where reuse
needs to be leveraged.
Pre-asset creation
In cases where an asset has not yet been built, we can consult the following sources:
Architecture and design documents: Do these documents specify elements in the solution
that have a great deal of commonality? Are there estimates in place as to how long each
instance will take to build?
Models: Are there subsystems, mechanisms, services, and so forth that have
commonality? Are there estimates in place regarding how long it will take to build these
elements?
Existing systems: Are there reference solutions in place that serve as a blueprint for how
future development will be done? How long did it take to build the existing systems? How
long will it take to recreate the reference solution in new systems?
Historical metrics: Based on past projects, are there areas that take significant effort? Are
there areas that have high defect rates?
Risk profiles: Are there aspects of the system that are more risky than other aspects?
Frameworks: Does the project team plan to use one or more frameworks in their
development? Are there recurring patterns of using the framework?
Business processes: Are there groups of services that often work together as part of a
business process? Are there groups of services that work together across a number of
business processes?
How many artifacts are needed within the asset? How many of these artifacts already
exist?
Repeating questions: Do the experts within your organization find that they continue to
see the same questions asked? What topics are covered by the question? How often do
they have to answer these questions?
Best practices documents. We often find that best practice documents exist, but are not
used. Are there important best practices that need to be codified? What areas do the best
practices cover? What is the anticipated impact?
Leverage past asset production data:
– How long did it take to build an asset?
Chapter 6. Value, impact, and return on investment
115
– How much is spent on maintaining an asset?
– You can look at individual assets that are thought to be similar and classes of assets,
as well as averages across all assets.
Leverage past asset management data:
– How long does it take to review an asset?
– Average number of downloads?
– Discussion entries
– Feedback levels
Leverage past asset consumption data:
– How long does it take to learn to use an asset?
– How long does it take to apply an asset?
Post-asset creation
In cases where the asset has already been built, we can consult the following sources:
User community surveys: Contact the people that have downloaded the asset and query
them on their use of the asset.
Defect rates: Are defects being filed against the asset?
Help requests: Are requests coming in for help on using the asset?
In the case of code generation assets, are defects that are generated from the asset
showing up across a number of targets?
Monitor discussion forums: Are there forums, mailing lists, or news groups related to asset
use? And if so, is the asset under scrutiny discussed?
Project plans: Are project plans referencing the use of assets?
Architecture and design documents: Do these documents specify the assets to be used?
Do they specify what is to be generated via these assets?
Asset specification: The asset specification must detail when and where the asset must be
used. This information will help to guide you in your effort to gather metrics.
Tooling associated with the asset: Evaluate the environment that is used with the asset.
What metrics does it provide? For instance, if the asset is a service, does the service
provider provide details about how much use the service receives?
Actual time required to build the asset
Actual time spent in updating and maintaining an asset
Actual time spent in learning how to use an asset
Actual time spent in applying and using an asset
Reuse compared to reapply
In the case of certain assets, such as design time and code generation assets, we also need
to differentiate between a use and reapply. For instance, we can use a Pattern to generate
code associated with a project. As we work through development on the project, we might
need to run the pattern multiple times - each time tweaking the input model to influence the
code that is generated. We reuse the pattern each time, but as far as metrics are concerned,
these are reapplies rather than reuse. A metric that summarizes reuse as opposed to reapply
can be useful as a guide into the consumability of an asset. But in terms of ROI and impact,
we are usually focused on reuse and not as interested in reapply.
116
Strategic Reuse with Asset-Based Development
6.4 Asset Reuse Strategy
The approach that we take in producing, managing, and consuming assets will also have
significant influence on our ROI and impact.
6.4.1 Tooling and methodology
It is extremely important that we have tooling and methodology that supports us in creating
our assets.
Automation and simplification lead to situations where asset quality is higher, quicker to
market, and, in many cases, easier to consume. The more that we can automate and simplify
the creation of assets, the easier it becomes to make the case that we must build the asset.
A common, proven process leads to predictability and repeatability. These processes are
valuable when you plan, budget, and manage investments.
6.4.2 Asset creation and acquisition approaches
We also need to consider what the correct model is for creating or acquiring an asset. An
initial decision that will need to be considered is how you will acquire an asset. Options
include:
Acquire from a third party. This can include:
– Purchase: This can include the acquisition of components, models, services, and so
forth.
– Acquire via Open Source: The Open Source community produces many useful assets.
Regardless of the source, we might find that additional expense is incurred in license
review, negotiations, and enablement.
Build the necessary asset. We can leverage resources within the organization, outsourced
resources, or a combination.
An asset can also require a mixture of assets and artifacts from a number of sources.
6.4.3 Asset type
The type of asset will also have an impact. Certain assets have characteristics and
requirements related to timing of creation, development process, approach to consumability,
consumption model, and so forth. A team must be aware of the best practices associated with
the type of asset with which they are working.
We will look at best practice approaches to building specific types of assets in later sections
of this book. For now, it is important to remember that the approach that you take will have an
impact on your estimates, metrics, and likelihood to get funding support.
6.4.4 Reuse scope
The scope of the reusable assets can also affect the cost. Generally, the higher the asset’s
scope for reuse, the higher the testing, packaging, communicating, and maintenance cost.
One strategy for this is to start with lower scoped assets and then grow the scope across the
phases over time as experience and lessons learned are gathered as shown in Figure 6-4 on
page 118.
Chapter 6. Value, impact, and return on investment
117
Figure 6-4 Reuse scope
6.5 Calculations
Now that we have ideas about where we can capture input data, let us start to look at how we
can leverage that data in calculations.
As seen in Figure 6-5, our first calculation is simple and obvious. The cost of producing and
using an asset must be less than the cost of just “business as usual”.
productivity cost
using an asset
approach
cost to implement
asset
productivity cost
of business as
usual
Figure 6-5 Basic ROI calculation
Let us take a more detailed look at the elements that comprise this formula, starting with the
user productivity cost. In this case, we are interested in the consumer of the asset, and we
need to figure out what the cost is for that person to use the asset. Questions that we want to
consider:
The amount of time that is spent in learning about the asset:
– What problems does the asset address?
– What is the solution that is provided? How can it be customized?
– What other assets can be used in conjunction with this asset?
– What constraints are placed on your project after you have used the asset?
When you have learned how to use the asset:
– How long does it take to actually apply and use the asset?
– How many times will the asset be used?
– How many people need to use the asset?
118
Strategic Reuse with Asset-Based Development
Figure 6-6 provides a view of how we calculate the user productivity cost, where:
L: Learn Asset, the average amount of time that it takes to learn to work with the asset
A: Apply Asset, the average amount of time that it takes to someone to use and apply the
asset
x: Number of asset users
y: Number of times that the asset will be applied
x(L + y(A)) = user productivity cost
Figure 6-6 User productivity cost calculation
Now, let us take a more detailed look at the factors that go into calculating the cost of building
the asset:
Reference solution: Depending on the type of asset that we build, we might want to take a
bottom-up approach when building our reusable assets. Therefore, we must have a
reference solution in place that we can use as the starting point for building the reusable
asset.
Asset specification: Even when we have a reference solution, we will still need to spend
time documenting how this reference solution really is reusable. Therefore, we need to
spend time creating a specification for the asset that details the problem that it addresses,
the solution that it provides, variability points, related assets, and so forth.
Asset implementation: At this point, most of the hard work is done, we just need to build
the asset itself. The hard work surfaces in creating the reference solution and figuring out
how it must present itself as a reusable asset. Creating the asset becomes a mechanical
task.
Figure 6-7 provides a view of how we can calculate the cost of building the asset, where:
DA: Describe the asset, whereby we create a reference solution and then document that
solution as an asset specification
AI: Asset implementation: Whereby we create an asset based on the specification
(DA + AI) = cost of asset implementation
Figure 6-7 Calculating the cost of the asset implementation
Although not a part of the high-level equation with which we started, we also need to think
about project risk. Figure 6-8 provides a view of how we can calculate project risk:
z: Probability of an incorrectly created solution; the contention is that by using an asset the
probability will be much lower
CD: Cost to discover a defect
CR: Cost of rework
z(CD + CR) = project risk
Figure 6-8 Calculating project risk
Chapter 6. Value, impact, and return on investment
119
The project risk factor can then be used to adjust estimates based on whether assets are
used in the project.
6.6 Cost of reuse failure
Just as important as knowing the cost of producing and using assets successfully, it is
important to recognize that there is a cost associated with reuse failure. You can obtain
information about reuse failure in Incentive Compatibility and Systematic Software Reuse,
Fichman and Kemererm, Journal of Systems and Software, New York: April 27, 2001;
Volume 57, Issue 1, page 45.
6.7 Additional calculations
The discussion regarding the calculation of asset financial estimates is more detailed than
those calculations discussed so far in this chapter. The discussion to this point is likely what
you expect all members of the team to be aware of. It provides sufficient insight without
overburdening them with details.
You can read additional content discussing calculations, metrics, and estimating in the Asset
Governance Rational Method Composer (RMC) Plug-in, as well as in a number of books.
A set of sample spreadsheets are provided in the Asset Governance RMC plug-in to help get
you started in creating your financial estimates. There are three calculators to assist you:
Asset ROI Calculator2: This sample calculator expects input on development costs and
expects assets that are not modified directly by the consumer. The calculator estimates
the ROI for a source code-based asset and uses lines of code (LOC) as the unit of
measure. These metrics are adapted from Jeff Poulin’s metrics in Measuring Software
Reuse, Addison Wesley. Figure 6-9 on page 121 shows an example of this calculator.
Project ROI Calculator: A representative ROI calculation is derived from an extensive
analysis performed by B. W. Boehm, “Economic Analysis of Software Technology
Investments”, originally published in Analytical Methods in Software Engineering
Economics, (Gulledge and Hutzler, editors, Springer-Verlag, 1993). The study was an
analysis of which productivity improvement strategies produced the highest payoffs. The
study covered software development from the 1950s into the 1990s.
Reuse Financing3: This tool determines the financing required to initiate and maintain the
reuse program. These metrics are adapted from Wayne Lim, Prentice-Hall, Managing
Software Reuse. Figure 6-10 on page 122 shows an example of this calculator in use.
2
3
120
Adapted from Poulin, Jeffrey C., MEASURING SOFTWARE REUSE, ©1997. Electronically reproduced by
permission of Pearson Education, Inc., Saddle River, NJ.
Adapted from Lim, Wayne C., MANAGING SOFTWARE RE-USE, 1st, ©1998. Electronically reproduced by
permission of Pearson Education, Inc., Saddle River, NJ.
Strategic Reuse with Asset-Based Development
Figure 6-9 Sample Asset ROI calculator
Chapter 6. Value, impact, and return on investment
121
Figure 6-10 Sample financial spreadsheet
122
Strategic Reuse with Asset-Based Development
Part 2
Part
2
Reusable Assets
In this part, we take a more in-depth look at how to implement a strategic reuse program. The
discussion will cover process, tooling, and governance. As shown in Figure P-2, we discuss
reusable assets in general. Part 3, “Service Assets in an SOA” on page 333 and Part 4,
“Patterns” on page 455 will build upon this content and will look at specific types of reusable
assets, including Services and Patterns.
Part 1:
Introduction
Part 2:
Reusable Assets
•Introduction to
Asset-Based
Development
•Adopting
Asset-Based
Development
•Process and
Tooling
•Configuring
Asset
Management
•Case Study
Overview
•Produce,
Consume, and
Manage Assets
•Impact and ROI
Part 3:
Services
•Services as Assets
•Produce, Consume,
and Manage Service
Assets
Appendixes
•Rational Asset
Manager
Installation and
Administration
•Process
Integration
Part 4:
Patterns
•Patterns as Assets
•Produce, Consume,
and Manage Pattern
Assets
Figure P-2 An overview of the structure of the book
© Copyright IBM Corp. 2008. All rights reserved.
123
124
Strategic Reuse with Asset-Based Development
7
Chapter 7.
Adopting Asset-Based
Development
This chapter provides a more in-depth look at how we can adopt a strategic reuse process.
When looking at adopting a strategic reuse program, there are changes in culture, process,
tooling, and skills. Introducing these changes into an organization needs to be planned and
will occur iteratively and incrementally.
In situations, such as this one, there are a number of things that we can do to help the
organization in both making a case to adopt a strategic reuse program, as well as set up a
foundation for the program’s implementation. Considerations include:
Pilot projects
Reuse maturity models
Organization templates
Reuse adoption strategy
Leverage Rational Method Composer plug-ins covering Asset Governance and
Asset-Based Development
ZYX: In the past, the CIO of ZYX Electronics has seen the concept of reuse promoted as a
cure-all for an organization. However, time and again, the approach did not live up to its
publicity and failed to deliver the promised benefits. Therefore, although the idea of reuse
and the promised benefits has appeal, the CIO is reluctant to move ahead quickly.
© Copyright IBM Corp. 2008. All rights reserved.
125
7.1 Pilot projects
When moving an organization forward in adopting a strategic reuse program, it might make
sense to set up a pilot project. When setting up a pilot project, we want to make sure that we
are going into the project with both a plan and a purpose. There are criteria to consider for
selecting a pilot project. These criteria include:
Choosing the emphasis for the pilot:
– Focus on process refinement
– Focus on tool selection validation
– Focus on metrics validation
– Focus on skill building
Choose the domain within the organization on which to focus
Consider the organization’s reuse and asset maturity
Evaluate the impact to the organization
Figure 7-1 is a sample outline of a reuse pilot and the major tasks for the pilot. The focus of
this sample is on process refinement.
Figure 7-1 Sample process for a pilot
The tasks within the Assess phase include:
Conduct reuse assessment:
– Evaluate reuse opportunities
– Evaluate target consumer team skills
– Evaluate architectures and code
– Determine target consumer projects
Install and configure products
Prepare productivity training
Conduct introductory training:
– Train asset manufacturing team
– Train Asset Reviewers and governance board
– Train project consumer team
Select asset manufacturing, consumer, and governance board teams
Evaluate as is development process
126
Strategic Reuse with Asset-Based Development
The deliverables that emerge from this phase, include:
Reuse assessment document
Selected target consumer projects
Installed products
Teams selected
Teams received introductory training
Existing process evaluated
The tasks within the Construct Process phase include:
Prepare Reuse Strategy:
– Determine candidate asset types
– Determine packaging strategy
– Determine asset versioning strategy
– Evaluate and select classification schemas
– Establish reuse marketing and communication plan
– Determine funding strategy
Customize the process and organization
Submit, approve, publish, consume, and retire assets
Prepare customized process training material
Conduct customized process training
Train teams
The deliverables include:
Reuse strategy document (Reuse vision, Asset types and packaging, Target development
flow, Reuse environment, Target metrics)
Customized process (Asset-Based Development (ABD) Process document)
Training material documents and teams trained
Governance boards in place
The Implement Process phase includes the following tasks:
Pilot asset manufacturing team executes
– Produce, package, and classify assets
– Manage assets
– Publish assets
Pilot Governance Board executes
Review and approve assets
Pilot Project Consumer Team executes:
– Consume assets
– Provide asset feedback
The deliverables associated with this phase include:
Reusable assets
Chapter 7. Adopting Asset-Based Development
127
Reused assets
The Measure phase includes the following tasks:
Measure:
– Prepare measurement report
– Communicate report
Plan for rolling out to other projects
Deliverables for this phase include:
Asset measurement report
Planning
To complete these tasks and build these deliverables, we leverage content from the Asset
Governance and Asset-Based Development Rational Method Composer plug-ins. In
particular, there are a number of templates that we can use as a starting point when creating
a Reuse Assessment and a Reuse Strategy.
After you have identified the focus of the pilot and the major tasks (as shown in Figure 7-1 on
page 126), create the estimate for the pilot.
7.2 Reuse maturity model
A number of models are available in the industry. Several of the models are quite generic and
apply to software development in general; several models get more specific to software
reuse; and other models get specific in support of specific types of reusable assets.
For software in general, look at the Capability Maturity Model Integration (CMMI), which is
described as, “Capability Maturity Model Integration (CMMI) is a process improvement
approach that provides organizations with the essential elements of effective processes. It
can be used to guide process improvement across a project, a division, or an entire
organization. CMMI helps integrate traditionally separate organizational functions, set
process improvement goals and priorities, provide guidance for quality processes, and
provide a point of reference for appraising current processes.”1
Information about how to leverage Rational Unified Process (RUP) to achieve CMMI
compliance can be found at:
Enhancing RUP for CMMI compliance: A methodological approach at:
http://www.ibm.com/developerworks/rational/library/5318.html
RUP with CMMI Compliance Support V1.0 Beta at:
http://www.ibm.com/developerworks/rational/downloads/07/rup_cmmi_v1/index.html
Reaching CMMI Levels 2 and 3 with the Rational Unified Process (white paper that ships
with RUP) at:
ftp://ftp.software.ibm.com/software/rational/web/whitepapers/2003/rupcmm.pdf
Looking more specifically at reuse, we can consider a framework, such as the Reuse Maturity
Framework\Five Stages of Reuse Maturity, from Wayne Lim2 as depicted in Figure 7-2 on
page 129, Figure 7-3 on page 130, and Figure 7-4 on page 131.
1
128
http://www.sei.cmu.edu/cmmi/general/index.html
Strategic Reuse with Asset-Based Development
Figure 7-2 Reuse Maturity Framework3
2
3
Lim, Wayne C., MANAGING SOFTWARE RE-USE, 1st, ©1998. Electronically reproduced by permission of
Pearson Education, Inc., Saddle River, NJ.
Lim, Wayne C., MANAGING SOFTWARE RE-USE, 1st, ©1998. Electronically reproduced by permission of Pearson Education, Inc.,
Saddle River, NJ.
Chapter 7. Adopting Asset-Based Development
129
Figure 7-3 Stages of Reuse Maturity4
4
Lim, Wayne C., MANAGING SOFTWARE RE-USE, 1st, ©1998. Electronically reproduced by permission of Pearson Education, Inc.,
Saddle River, NJ.
130
Strategic Reuse with Asset-Based Development
Figure 7-4 Progression across stages of Reuse Maturity5
When looking at specific types of reusable assets, such as patterns or services, you are likely
to find specialized maturity models. For an example of a maturity model that is specific to
services, look at Part 3, “Service Assets in an SOA” on page 333.
7.3 Organization templates
When setting up an organizational structure within which your asset reuse program will
operate, you can leverage organization templates to help plan your structure. These
templates provide guidance in terms of governance, repositories, and team and organization
structure. Therefore, they provide a starting point that you can leverage as you begin
adopting Asset-Based Development. The templates can be used “as is” or can be modified to
better fit within your organization. Our advice is to use the templates “as is” when getting
started and then modify them when you gain experience in asset reuse.
Although not a maturity model, you will find that there is a loose relationship between an
organization’s maturity and the template that the organization selects. As seen in the previous
section, there are a number of aspects that surface within a maturity model, such as:
Reuse culture
Process
Funding and sponsorship
5
Lim, Wayne C., MANAGING SOFTWARE RE-USE, 1st, ©1998. Electronically reproduced by permission of Pearson Education, Inc.,
Saddle River, NJ.
Chapter 7. Adopting Asset-Based Development
131
Each of the organization templates has a number of categories that are used to describe its
characteristics, including:
Reuse scope: The intended reuse visibility. As can be expected, more formality and
structure appear as the scope of the reuse increases.
Governance board: The number and kind of governance boards
Asset management: Location of the resources that manage the assets
Asset manufacturing: Location and resources producing the assets
Asset Use: The techniques and formality for asset reuse
Figure 7-5 provides a comparison of the characteristics for each of the organization
templates.
Figure 7-5 Characteristics of organization templates
We provide more detail regarding each template in the following sections. We present the
templates based on increasing order of formality.
7.3.1 Ad-Hoc organization template
Figure 7-6 on page 133 depicts the Ad-Hoc organization template. Unfortunately, many
organizations begin their asset work using a organization template similar to this one. This is
an unsatisfactory structure to adopt, because it introduces the following challenges:
Difficult to produce sufficient results and benefits to warrant migrating to a more formal
structure. Sometimes, a level of structure is needed to capture and report benefits.
Creates the potential for the Repository to become a junkyard of assets. With no
governance, the Asset Producers feel that their assets are reusable and the needs of the
consumers are not directly considered or are assumed. Soon, the Repository is rendered
useless.
132
Strategic Reuse with Asset-Based Development
These are significant challenges to overcome, and most likely, this approach will lead to a
failed reuse program.
The proper use of this template is to use it as a starting point on the path to a governed
Repository. If the enterprise uses this template for a period of time to gather lessons learned
and then move on, this template can fulfill that purpose quite well.
Figure 7-6 Ad-Hoc organization template
7.3.2 Self-Governed organization template
Figure 7-7 depicts the Self-Governed organization template. If the enterprise started with the
Ad-Hoc organization template, the Self-Governed organization template is often the next
template used. This template introduces governance for the reuse scope, which in this
template is a single group. Introducing governance represents growth in the Asset-Based
Development maturity for the group.
This template has many of the characteristics of the more formal templates, such as the
Enterprise Partial template or the Enterprise Full template. However, it varies in reuse scope,
in the size, and in the number of groups involved.
A key difference for this template compared to the Ad-Hoc template is that the Asset
Consumers can conduct planned reuse, as well as opportunistic reuse. Planned reuse means
that the governance policies establish the asset version policies, asset types, and
categorizations that the Repository will support. However, in this template, the group does not
fund the assets produced, or supported, for that matter, so the planned asset reuse is
mitigated by that fact.
Figure 7-7 Self-Governed organization template
Chapter 7. Adopting Asset-Based Development
133
7.3.3 Governed organization template
Figure 7-8 depicts the Governed organization template. A key differentiator between this
template and the Self-Governed template is that the asset production is funded, supporting
both the development and maintenance of key assets. This affects the Asset Consumer’s
ability to plan for reuse in the Asset Consumer’s projects, allowing the Asset Consumer to put
more trust in the asset’s availability and support.
Another key differentiator is that the use of the assets is supported by the Asset Producers.
This means that the Asset Producers help the Asset Consumers to be successful using the
asset. This support can be performed directly by the Asset Producers, or it can be performed
through an enablement team. This support has a direct benefit to the Asset Consumers and
their projects.
When assets are more complex and will be used multiple times, there is generally justification
for providing higher levels of support. The time to achieve a return on investment (ROI) for
assets can be decreased in this template and the remaining more formal templates
(Enterprise Partial and Enterprise Full) through the proper use of asset support, enabling the
success of the consumers.
A governed group can interoperate with self-governed groups as well. The governance board
for the governed group provides policies for the self-governed group.
Figure 7-8 Governed organization template
7.3.4 Enterprise Partial organization template
Figure 7-9 on page 135 depicts the Enterprise Partial organization template. A key
differentiator from this template and the Governed template is the separation of asset
production and asset management. The functions around asset management require
overhead, and the organization can achieve efficiency by centralizing them. Meanwhile, the
asset production activities benefit by staying within the community and, therefore, being close
to the domain experts.
134
Strategic Reuse with Asset-Based Development
Figure 7-9 Enterprise Partial organization template
7.3.5 Enterprise Full organization template
Figure 7-10 on page 136 depicts the Enterprise Full organization template. A key
differentiator between this template and the Enterprise Partial template is the asset
production activities are centralized as well. To make an asset reusable and to reduce the
friction in reuse transactions, often packaging and other overhead activities are required
across assets. For certain kinds of assets, such as coarse-grained solutions that are
comprised of many assets, it might be justified to centralize the production and packaging of
the assets.
A challenge with this template is that the asset production might be performed
organizationally too distant from the domain experts in the communities. This has to be
monitored closely, and communication must be constant. The majority of the Asset-Based
Development work, including the configuration of the repositories and the development of the
assets, must be done within the context and purpose of positively impacting the Asset
Consumers. Anything that causes a hurdle or a gap that the Asset Consumers do not
understand clearly must be removed.
Chapter 7. Adopting Asset-Based Development
135
Figure 7-10 Enterprise Full organization template
ZYX: ZYX Electronics has decided that they will adopt the Governed organization template
for the pilot. Depending on the success of the pilot and funding levels, they will consider
adopting one of the Enterprise Partial or Enterprise Full organization templates. Also,
based on the results of the pilot and their further analysis, they might customize the select
organization template.
7.4 Reuse adoption strategy
With many information sources provided, it can seem difficult to figure out where to start when
adopting a reuse-based approach in an organization. Although each organization is different,
a reuse adoption model has been proposed as depicted in Figure 7-11.
Figure 7-11 Reuse adoption model
The five phases of this adoption model6 are:
Initiate: In this phase, we acquire a commitment from the organization to investigate
adopting a reuse approach.
Investigate: In this phase, we determine the feasibility of leveraging reuse within an
organization. An important aspect of this work is to ensure that a clear understanding of
136
Strategic Reuse with Asset-Based Development
the business drivers exists and that a clear understanding of how reuse aligns with and
supports the business.
Plan: In this phase, we create a plan that details how we are going to leverage reuse
within the organization.
Implement: In this phase, we follow through on our plan and work to become a
reuse-based organization.
Improve: As we follow through on our plan, it will likely become apparent that we will learn
about reuse, our organization, and the need to make adjustments. In this phase, we
recognize the need to improve our approach and then roll those improvements back into
our plan.
The model is meant to be customized as needed for your organization. In addition, you will
want to leverage the artifacts that we have discussed, such as organization template, maturity
models, and pilot projects, as well as the Asset Governance and Asset-Based Development
Rational Method Composer plug-ins.
7.5 ZYX’s Asset Governance
Before starting to leverage Asset-Based Development, we need to figure out how we are
going to roll this process enhancement out to our organization. Building on the discussion
from the previous section, we can now start to plan out our governance strategy. Governance
plays a key role in helping us, because we need to figure how what the process will look like,
the roles, the levels of responsibility, the funding models, and so forth.
Governance is the establishment of:
Chains of responsibility to empower people
Measurement to gauge effectiveness
Policies to guide the enterprise to meet its goals
Control mechanisms to ensure compliance
Communication to keep all required parties informed
We can try to proceed without figuring these things out, but our odds for success will be
greatly diminished. There is no such thing as not having governance. There is only good and
bad governance.
As depicted in Figure 7-12 on page 138, Asset Governance is composed of four main
phases, with a number of activities and tasks performed within each phase, leading to the
creation of a number of deliverables. The tasks can be done in parallel, and the order in which
they are performed is negotiable. Remember that we want to leverage an iterative and
incremental effort; therefore, it is likely that we will revisit elements as necessary to update,
refine, and enhance.
6
Lim, Wayne C., MANAGING SOFTWARE RE-USE, 1st, ©1998. Electronically reproduced by permission of
Pearson Education, Inc., Saddle River, NJ.
Chapter 7. Adopting Asset-Based Development
137
Figure 7-12 ZYX’s Asset Governance deliverables
7.6 Getting started at ZYX Electronics
To this point, we have discussed a number of different artifacts that we can leverage in
starting the adoption of Asset-Based Development at ZYX Electronics. Figure 7-13 on
page 139 is used to illustrate to the ZYX team how these components all fit together.
We use the Reuse adoption model as a starting point to lead into the Asset-based
Governance material. Based on the Asset-based Governance material, we are able to
structure a pilot, which in turns leads into our Asset-Based Development process.
138
Strategic Reuse with Asset-Based Development
Figure 7-13 Bringing together adoption, pilot, governance, and development
Note: Figure 7-14 shows the cover from the completed ZYX Electronics Reuse
Assessment document. The document leverages the Reuse Strategy template provided by
the Asset-Based Development Rational Method Composer plug-in. The contents of the
document appear in the following sections of this chapter. Appendix C, “Additional
material” on page 725 provides details about how to download a text document that
contains the content to use as a starting point for your own assessment.
Chapter 7. Adopting Asset-Based Development
139
Figure 7-14 Cover from the ZYX Electronics Reuse Assessment document
7.7 Purpose
The purpose of this document is to describe the opportunities and capabilities of ZYX
Electronics (ZYX) to conduct strategic asset reuse within its software development teams.
We have not yet adopted any formal reuse program; any reuse that has happened to date
has been ad hoc and driven by individuals. The expectation is that a strategic reuse program
will allow the IT organization to deliver results more quickly, deliverables will be of higher
quality, and we will be better aligned with the overall business.
Planning, diligence, and execution, at the corporate level, are necessary to ensure that reuse
happens successfully for ZYX Electronics. Software reuse will not simply be a by-product of
software development. To be useful, reusable assets must be:
Well designed, implemented, and tested
Documented regarding how to reuse
Cataloged and made easily retrievable
140
Strategic Reuse with Asset-Based Development
As a company, we need to assess our ability to create reusable software assets. Today, IT is
not organized for this reuse to happen. Our software development teams are autonomous
and not aligned with the way that our business operates. No reusable asset library is
available within the company today. And, we have no standard end-to-end software
development processes to exploit best practices to identify or guide the development and
management of reusable software assets. This document will detail these issues, as well as
highlight a few positive areas that will be leveraged as we roll out a strategic reuse program.
7.8 Background
ZYX Electronics is adopting a strategic reuse program within the IT organization. Reuse
capability describes the organization’s ability to conduct reuse activities. Reuse opportunity
describes the extent to which recurring problems and recurring solutions exist within the
selected scope.
An organization’s reuse capabilities are increased when the following factors are in place:
Management support:
– Management specifies policies that support asset reuse.
– Management provides top-down support for investing with bottom-up implementation.
Mature software process in the organization:
– Project teams follow a repeatable software process.
– Management artifacts are produced from the process, and management uses them.
There are generally more reuse opportunities when the following factors are in place:
Well understood domains
The business problem space is understood by the software organization.
Architecture to support reuse
The software architecture permits assets to be harvested and plugged in for reuse.
Mature versioning and configuration management:
– The software team practices source code versioning and configuration management.
– A release cycle is in place for delivering software in the organization.
To ensure that the entire team is on the same page, we provide the following definitions:
Systematic reuse is defined as, “Systematic reuse is the reuse of assets within a structured
plan with well-defined processes and life cycles and commitments for funding, staffing, and
incentives for production and use of the reusable assets.”7
Strategic reuse builds on the idea of systematic reuse and sees an organization tie their reuse
program to the strategy of the business. Therefore, the strategic reuse program must
implement a systematic approach to reuse that enables the organization to deal with
expertise shortages, globalization, regulatory concerns, rising customer expectations, and so
forth.
7
The definition for systematic reuse comes from Lim, Wayne C., MANAGING SOFTWARE RE-USE, 1st, ©1998.
Electronically reproduced by permission of Pearson Education, Inc., Saddle River, NJ., which references M.
Ogush, “Terms in transition: a software reuse lexicon,” Crosstalk: The Journal of Defense software Engineering,
pages 41-45, December 1992
Chapter 7. Adopting Asset-Based Development
141
7.9 Scope
In general, it is not a good practice to apply reuse principles to the entire enterprise at one
time. As input to the reuse assessment, the business problem and priority need to be
understood, which provides the necessary context and scope for focusing the reuse
assessment. Therefore, we have decided that we will limit the scope of the reuse assessment
to the team lead by Duncan Munchkin, the Development Manager for the Credit Application
(see Figure 7-15).
Figure 7-15 Organization chart for the CIO
The reasons for the limited scope decision are:
The team contains a mix of development locations, as well as third-party contractors from
a Global Systems Integrator (GSI). We need to ensure that we capture our reuse
capabilities in a globally distributed development (GDD)-enabled portion of the
organization.
As determined in the Component Business Model (CBM) analysis, the Credit
Administration component is a key element to the business (see Figure 7-16 on
page 143). If we want reuse to be a strategic effort, we need to ensure that reuse works in
our strategic business components.
The culture within Duncan’s team is open to new ideas and change.
142
Strategic Reuse with Asset-Based Development
Figure 7-16 Component business model heat map for ZYX Electronics
7.10 Maturity
In order to truly determine where our reuse capabilities are as a company, we will set the bar
against known criteria. In the software industry, several maturity models have been
documented and found to be very effective in measuring a company’s current software
development and asset reuse maturity. In addition, the maturity model can provide a road
map in helping the organization plan how they will move forward and advance their approach
to reuse.
Perhaps the most well known of these is Capability Maturity Model Integration (CMMI). CMMI
is a process improvement approach that provides organizations with the essential elements
of effective processes. However, this is a more generic maturity model and therefore is not
tailored to reuse.
Taking reuse into account, other maturity models are available. In particular, ZYX Electronics
will leverage the Reuse Maturity Framework – The Five Stages of Reuse Maturity by Kulton
and Hudson, because it was the best at outlining organizational reuse capabilities in a well
described approach. The Reuse Maturity Framework, as depicted in Figure 7-17 on
page 144, describes the dimensions of a company’s reuse maturity. Although we have a
Chapter 7. Adopting Asset-Based Development
143
minor issue with the framework not directly targeting our business, it provides a great deal of
value as we plan a reuse adoption.
Figure 7-17 Reuse Maturity Framework8
In addition to the Reuse Maturity Framework itself, we will also leverage the characteristics of
each level in the framework that are shown in Figure 7-18 on page 145. Thoroughly
understanding our current level of reuse maturity can only help us to better formulate a
successful Reuse Strategy.
8
Lim, Wayne C., MANAGING SOFTWARE RE-USE, 1st, ©1998. Electronically reproduced by permission of Pearson Education, Inc.,
Saddle River, NJ.
144
Strategic Reuse with Asset-Based Development
Figure 7-18 Reuse Maturity Framework Stage Characteristics9
7.11 Areas of assessment
In this section, we discuss the abilities of ZYX Electronics to conduct asset reuse practices
and the opportunities for future reuse. The assessment will review the organization from a
number of perspectives, including:
Management support
Software process
Business domain understanding
Architecture to support reuse
Versioning and configuration management
Within each perspective, we will also align our responses with the Reuse Maturity
Framework. As a result of this alignment, we will provide more depth to the assessment and
position ourselves to move further up the maturity model. As seen in Figure 7-19 on
page 146, there are both Motivations and Travel Events that we will be using as a loose guide
indicating that we need to be looking at moving to a particular level in the framework. These
motivations and travel events usually occur before we can migrate from one level in the
9
Lim, Wayne C., MANAGING SOFTWARE RE-USE, 1st, ©1998. Electronically reproduced by permission of Pearson Education, Inc.,
Saddle River, NJ.
Chapter 7. Adopting Asset-Based Development
145
framework to the next higher level. For example, to move from the Initial/Chaotic level to the
Monitored level, we must recognize that competitive pressures require increased reuse. In
addition, the management team must be requesting reports detailing the progress made
toward this reuse goal.
Figure 7-19 Maturity Framework Progression10
7.12 Management support
From the management perspective, we need to answer the following questions:
Does management specify policies and support asset reuse?
Does management provide top-down support for investing with bottom-up
implementation?
And from the Reuse Maturity Framework, we want to evaluate the organization based on:
Motivation and culture:
– Is reuse encouraged? Noted? Rewarded?
– Are there incentives in place for reuse?
– Is reuse seen as “the way we do business”?
Planning for reuse
Is there any planning for reuse? If so, what approach? Ad hoc? Opportunistic? Part of
business strategy?
10
Lim, Wayne C., MANAGING SOFTWARE RE-USE, 1st, ©1998. Electronically reproduced by permission of Pearson Education, Inc.,
Saddle River, NJ.
146
Strategic Reuse with Asset-Based Development
Responsibility for making reuse happen
At what level does responsibility for building assets show up? Individual? Shared?
Dedicated resource? Dedicated group? Corporate group?
7.12.1 Does management specify policies and support asset reuse
In general, ZYX management has been supportive of the IT operations, although there is a
perception that there is room for improvement. Within the IT organization, the management
team has been focused on results and has allowed the teams freedom in terms of process,
tooling, and overall project approach. The IT management team views this as a shortcoming
that needs to be addressed.
Of our 2000 IT staff, 1000+ are developers using more than 40 diverse development tools
and environments. In addition, there is no standard end-to-end development process in
place.
In the past, the IT management team was made aware of isolated instances of reuse success
and bestowed small awards to the individuals involved. However, the focus of IT
management has been on meeting project deadlines, defect rates, and overall acceptance of
the deliverables. To this end, little encouragement has been given to reuse or process
initiatives. The side effect has been slipped projects and budget overruns, sometimes
causing the business units to lose faith in our ability to deliver to their needs. Although this
might sound like poor performance, based on the metrics gathered from the wider industry,
we are performing at least at industry average levels.
The lack of a common approach in our software development practices will require education
and mentoring as we adopt a process. The expectation is that this will position us for a
significant return on investment. To this point, the IT management team is fully committed to
supporting a software reuse initiative. Reuse policies and decision responsibilities will be
specified and supported from the highest management levels to encourage project teams
about the importance of software reuse. The IT management team recognizes that they need
to create a new culture within ZYX Electronics that values:
Strategic reuse
Common, proven development process
Leveraging of industry best practices
Leveraging an iterative and incremental approach
Leveraging abstraction and automation
7.12.2 Does management provide top-down support for investing with
bottom-up implementation
From the highest levels of executive and IT management, we have general commitment to
support our reuse initiatives. In reviewing the “Generations of Basic Technology
Advancements” report as summarized in Figure 7-20 on page 148, we recognize that the
industry trend is toward considerable software reuse.
Chapter 7. Adopting Asset-Based Development
147
Figure 7-20 Generations of basic technology advancements
Note that as an organization, we do not map to one specific column. Our interpretation of our
current as is situation is depicted in Figure 7-21 on page 149. In terms of reuse, based on the
definition of elements that can be considered a reusable asset (components, frameworks,
models, test scripts, design documents, and so forth), we have determined that a limited
amount of reuse has been occurring. However, this reuse has not been systematic or
strategic.
As noted in Figure 7-21 on page 149, our team configuration and work approach is based on
a distributed model. A major concern is that with having a distributed IT organization, along
with leveraging GSI partners, our lack of advancement in the other areas will limit the success
of leveraging a distributed model (and will likely lead to failure).
148
Strategic Reuse with Asset-Based Development
Figure 7-21 ZYX as is: Software governance - generations of basic technology advancements
As an organization, we need to achieve the benefits listed, including predictable project
performance, on budget and on schedule deliveries, and a higher success rate.
However, there is still skepticism regarding the levels of investment required and the real
benefits reuse will provide us. Therefore, initial support and investment will be provided for
the program. However, a longer term commitment will require proof that strategic reuse is
possible at ZYX and that the benefits seen are as advertised. A strategy is needed for
building and proving the reuse business case as a means to secure long-term funding and
support.
7.13 Software process
From the Process perspective, we need to answer the following questions:
Do the project teams follow a repeatable software process?
Are there management artifacts produced from the process, and does management use
them?
And from the Reuse Maturity Framework, we want to evaluate the organization based on:
Process by which reuse is leveraged:
– Is there a process in place that accounts for reuse?
– At what point in the process is reuse brought up?
– Does reuse only focus on off-the-shelf components?
– Does reuse see the creation of families of products?
– Are all products generalized for future reuse?
Chapter 7. Adopting Asset-Based Development
149
Metrics:
– Are reuse metrics collected? At the code level? Based on Repository assets?
– Is an analysis performed to determine the payoff for developing an asset?
– Are the tooling and accounting mechanisms set up to track reuse?
7.13.1 Do the project teams follow a repeatable software process
The short answer is “No”. Over the years, we have allowed software teams to utilize any
software development process found capable of helping the team produce software products.
As mentioned earlier, a common, proven and repeatable process is required both to improve
our overall software delivery capabilities, as well as to support a strategic reuse program. In
addition, to support our globally distributed development team, we need to ensure that when
the process is put into place that it is managed and measured.
With the current lack of process and lack of focus on reuse, it is difficult to state when reuse is
considered in the development process. For several members of our team, reuse is never
discussed. Several of our other teams will leverage reuse in an ad hoc fashion, but it is
usually (there are exceptions, of course) something that is brought up by and leveraged by an
individual.
7.13.2 Are there management artifacts produced from the process and does
management use them
With the lack of a formal process in place, it is not surprising that few management artifacts
are produced from the process. A key success that has been achieved in this area is the
implementation of Unified Change Management. Metrics regarding defects, components, and
project progress are available.
Although reuse is occurring, no metrics are yet collected on the reuse, what is being reused,
or the benefits of the reuse. Information regarding reuse is collected via informal discussions
and anecdotes.
7.14 Business domain understanding
From the Business Domain perspective, we need to answer whether the business problem
space is understood by the software organization.
And from the Reuse Maturity Framework, we want to evaluate the organization based on
breadth of reuse involvement. Is reuse seen as requiring the involvement of just individuals,
workgroups, departments, division, or the enterprise?
7.14.1 Is the business problem space understood by the software
organization
Recently, we brought in a management consulting firm to conduct a report of our core
business processes, structure, and practices. A detailed report was produced, as well as a
model of ZYX Electronics business processes. This model has helped us to better
understand and focus on our core business competencies on those business areas most
important to us for revenue and growth. In addition, this model has helped us to refine our
150
Strategic Reuse with Asset-Based Development
corporate strategies, overall direction and policy, the way that we monitor our business and
manage exceptions, tactical decision making, and business execution.
This model, referred to as a Component Business Model (CBM) and shown in Figure 7-22,
has led us to begin organizing our early service-oriented architecture (SOA) efforts to the
goals of our business. We still have a long way to go, but IT is headed in the right direction to
align with the ZYX Electronics business structure. Aligning IT with our business goals allows
us to focus on the needs of the business, create software products that mirror the business,
and will help us to identify business areas where we perform the same tasks.
As discussed in the scope section, our initial reuse efforts will focus on the Credit
Administration component. This is a core component for the business and therefore, an area
where we need to focus IT investment.
Figure 7-22 ZYX Electronics component business model heat map
In regard to the business drivers within this component, we are aware of the following
requirements for the Credit Administration component:
Centralizing siloed departments and building optimized services to support the converged
organization and then negotiating better prices with our vendors and taking advantage of
our combined size help us:
– Decrease the negotiated cost (vendor volume discounts) of credit report retrieval by
20%.
Chapter 7. Adopting Asset-Based Development
151
– Automate 75% of all credit report retrievals.
Implementing consistent business rules to manage risk
Decrease the number of credit report retrievals by 10%.
7.15 Architecture to support reuse
From the Architecture perspective, we need to answer the following question:
Does the software architecture permit assets to be harvested and plugged in for reuse?
And from the Reuse Maturity Framework, we want to evaluate the organization based on:
Motivation and culture:
– Is reuse encouraged? Noted? Rewarded?
– Are there incentives in place for reuse?
– Is reuse seen as “the way we do business”?
Breadth of reuse involvement:
Is reuse seen as requiring the involvement of just individuals? Workgroups?
Departments? Division? Enterprise?
Responsibility for making reuse happen
At what level does responsibility for building assets show up? Individual? Shared?
Dedicated resource? Dedicated group? Corporate group?
7.15.1 Does the software architecture permit assets to be harvested and
plugged in for reuse
To date, many people within the organization have taken a “not built here” approach – and so
far, little has been done to fix this culture. When object-oriented programming languages
really started hitting the mainstream, it was our general assumption that we “automatically”
reuse encapsulated functionality across IT. However, we have found that this was an
incorrect assumption.
We recently selected SOA as an architectural style. The SOA techniques, practices, and
process are mature, and SOA is successful within many organizations today. Our SOA
choice aligns very well with our corporate initiatives to align IT with business goals and
objectives. In addition, SOA will allow us to be more flexible to changes in our business
offering and take us from an autonomous application development shop to a shop that can
mix and match business components to create a business solution. A concern is whether an
organization that is siloed – a “not built here” attitude and a history of non-reuse – will be able
to leverage the reuse aspects of SOA.
We also have the opportunity to make reuse of other application development artifacts, such
as open source and internally built frameworks, architecture and design patterns, code
templates, and so forth, not to mention the opportunity to expose existing code through
business services and Composite Business Services.
Our lack of consistency in tooling, process, and architectural styles has made it difficult to
identify recurring solutions, areas of commonality, and possible points of variability. When
everyone does things differently, it seems as though everything is a unique solution. As we
work toward a consistent set of best practices, standardized architectural styles, standard
152
Strategic Reuse with Asset-Based Development
tooling, and a common process, we expect to identify many recurring solutions that can be
converted into assets.
7.16 Versioning and configuration management
From the Versioning and Configuration Management perspective, we need to answer the
following question, “Does the software team practice source code versioning and
configuration management?”
And from the Reuse Maturity Framework, we want to evaluate the organization based on:
Technology support:
– Are configuration management tools used? If so, are they specialized for reuse?
– Are asset classifications used?
– Is a Repository separate from the source code Repository used?
– Is there integration between the asset Repository and development tooling?
7.16.1 Does the software team practice source code versioning and
configuration management
An area of strength for ZYX Electronics is their source code versioning and configuration
management approach. With the globally distributed development approach of the IT
Organization, a strong software configuration management approach was needed. The IT
Organization has adopted Unified Change Management supported by IBM Rational.
One of the key aspects of the Unified Change Management model is that it unifies the
activities used to plan and track project progress and the work products undergoing change.
The Unified Change Management model is realized by both process and tools. The IBM
Rational products Rational ClearCase and Rational ClearQuest are the foundation
technologies for Unified Change Management. ClearCase manages all of the work products
produced by a software project, including both system work products and project
management work products. ClearQuest manages the project’s tasks, defects, and requests
for enhancements (referred to generically as activities) and provides the charting and
reporting tools necessary to track project progress.
Currently, however, there is no specialized focus on reuse. In addition, because little work
has been done to identify the assets that we currently use, we have not taken steps to create
a classification schema or an asset Repository, nor has work been done to determine how
our development tools support assets.
7.17 Conclusions
In this section, we look at our alignment with the maturity model, as well as a summary of the
assessment.
7.17.1 Maturity model alignment
Figure 7-23 on page 154 shows the “as is” assessment results aligned with the Reuse
Maturity Framework, in other words, our current reuse maturity as it stands today. Not too
Chapter 7. Adopting Asset-Based Development
153
surprisingly, we find ourselves primarily in the Initial/Chaotic level of the framework. When the
ZYX Reuse Strategy is developed, the Reuse Maturity Framework will be used to guide many
of our key reuse competency improvement decisions.
Figure 7-23 Reuse Maturity Framework ZYX as is11
7.17.2 Summary
Coming into this assessment, the team had a number of preconceptions regarding ZYX’s
reuse abilities and opportunities. The assessment guidelines and maturity framework details
have assisted the team in looking past our preconceptions and have also led to interesting
discoveries regarding reuse abilities and opportunities. In particular, we had the impression
that we were less prepared than we actually are and that we had fewer opportunities for
reuse than actually exist.
Although we did find a number of areas that are problematic and will require attention, we
also found a number of positive aspects that will position us for reuse, including:
Alignment with our SOA initiative: In addition to SOA having reuse of services as a key
concept, the alignment with business, business agility, and business flexibility concepts
will serve ZYX well in a wider, more general reuse program.
11
Lim, Wayne C., MANAGING SOFTWARE RE-USE, 1st, ©1998. Electronically reproduced by permission of Pearson Education, Inc.,
Saddle River, NJ.
154
Strategic Reuse with Asset-Based Development
Unified Change Management adoption: The Unified Change Management approach
already adopted will serve us well as we implement the reuse program. Having controls
and a process in place surrounding code artifacts will translate very well to a reuse
program.
Culture: The IT team led by the Credit Application team, which is led by Duncan, is open to
improving their process and leveraging reuse and service as a role model for the rest of
the organization.
Business Support: The organization sees the software team as key to the competitiveness
of the overall company. There is both support and a strong desire to see the IT team
succeed.
7.18 References
For more information, refer to:
Incentive Compatibility and Systematic Software Reuse, Journal of Systems and
Software, Apr 27, 2001; Vol. 57, Iss. 1, Robert G. Fichman
Managing Software Reuse, Prentice Hall, 1998, Wayne Lim
Measuring Software Reuse, Addison Wesley, 1997, Jeffrey S. Poulin
Global Development and Delivery in Practice: Experiences of the IBM Rational India Lab,
SG24-7424-00
Note: Figure 7-24 shows the cover from the completed ZYX Electronics Reuse Strategy
document. The document leverages the Reuse Strategy template provided by the
Asset-Based Development Rational Method Composer plug-in. The contents of the
document appear in the following sections of this chapter. Appendix C, “Additional
material” on page 725 details how to download a text document that contains the content
to use as a starting point for your own strategy.
Chapter 7. Adopting Asset-Based Development
155
Figure 7-24 Cover from the ZYX Electronics Reuse Strategy document
7.19 Purpose
Systematic software reuse is the purposeful creation, management, support, and reuse of
assets. In Software Reuse: Architecture, Process, and Organization for Business Success,
Jacobson, Griss, and Jonsson estimate the following benefits of systematic reuse12:
Time to market: 2 to 5 times reduction
Defect density: 5 to 10 times reduction
Maintenance cost: 5 to 10 times reduction
Strategic reuse builds on the idea of systematic reuse and sees an organization tie their
reuse program to the strategy of the business. Therefore, the strategic reuse program must
implement a systematic approach to reuse that enables the organization to deal with
expertise shortages, globalization, regulatory concerns, rising customer expectations, and so
forth.
12
156
Software Reuse - Architecture, Process, and Organization for Business Success. Ivar Jacobson, Martin Griss,
Patrik Jonsson, pg 7.
Strategic Reuse with Asset-Based Development
Leveraging these definitions, the mission for the ZYX Electronics (ZYX) reuse program is to
improve the quality and time lines of deliverables from the IT organization to support and
enable the business goals and objectives of ZYX Electronics.
ZYX Electronics expects to realize this mission by developing tools, processes, and policies
that will establish, maintain, and encourage strategic reuse.
There are many challenges, however, to implementing software reuse at an organization,
because reuse has an impact and dependency on culture, process, and tooling. All three of
these elements must come together to realize a successful reuse program.
This document discusses the changes in policy and practice that will be required at ZYX
Electronics to adopt and apply Asset-Based Development.
As detailed in the Reuse Assessment, the initial scope for the reuse program will be the
Credit Application development team. Also, as detailed later in this document, the initial
rollout of this program will include a pilot phase. Therefore, this document must be seen as a
living artifact as decisions, best practices, and documents are built during the rollout.
7.20 Key concepts
This section defines key Asset-Based Development concepts. These terms form the
vocabulary that we will use throughout this document and in the other guideline documents.
All teams within ZYX Electronics are expected to leverage and use this set of definitions when
discussing and working within the reuse program. Any changes in definition or additionally
required terms must show up in future revisions of this document.
7.21 Asset-Based Development
Asset-Based Development is a way to develop software solutions using and reusing cohesive,
documented software artifacts. It is organizing software development in a way that leverages
previous investments and influences the nature of future investments. In addition, its modular
approach of using components and assets makes it easier to adopt changes to a system that
has already been built.
The four elements of Asset-Based Development are:
Assets
Cohesive, documented software artifacts that provide a solution to a
problem for a given context
Standards
Consistent specification and representation of software assets and
processes
Process
Conducting software development in a way that leverages previous
investments and preserves current investments
Tooling
Automation that supports the process (that is, the production,
management, and consumption of assets)
The relationships among the elements are shown in Figure 7-25 on page 158.
Chapter 7. Adopting Asset-Based Development
157
Figure 7-25 Standards, Tooling, Processes, and Assets in Asset-Based Development
7.22 Motivations for Asset-Based Development
Motivations for Asset-Based Development are described in Figure 7-26. Note that Cost shows
up in both columns. It is important for the organization to be aware that reuse does not occur
for free. Additional costs will be incurred in building and supporting reusable assets. However,
as shown in Figure 7-26, we expect the benefits to far outweigh the associated costs. In
particular, the cost to apply and use an asset is significantly lower than rebuilding the solution
found in the asset. Therefore, the more that we can reuse an existing asset, the greater the
cost benefit. Also, because certain assets provide lower creation costs, we will be looking for
types of assets that help to minimize the costs while magnifying the associated benefits.
Figure 7-26 Asset-Based Development motivations
7.23 Assets and artifacts
An asset is a collection of artifacts that provides a solution to a problem for a given context
with rules for usage and variability points. Types of assets include components, patterns,
Web services, frameworks, code, documentation, models, and templates. Artifacts are work
158
Strategic Reuse with Asset-Based Development
products from the software development process, for example, requirements, models, source
code, and tests. The relationship between assets and artifacts is shown in Figure 7-27.
Problem
Solution
Artifact
Artifact
Artifact
Artifact
for a context
Variability point
Asset
Artifact
with rules for usage
Figure 7-27 Assets and their artifacts
Of particular importance to our reuse program will be the idea of variability points. We expect
that the assets that we create are engineered for reuse. Therefore, they must either support
Black box reuse (that is, zero variability points) or Gray box reuse where a small number of
variability points are provided. It is unacceptable to produce and contribute reusable assets
for White box reuse (that is, unlimited points of variability). White box reuse drives
development to rewrite instead of reuse. Encapsulating and controlling the functionality within
a reusable asset is of the utmost importance.
7.24 Asset standards
The Reusable Asset Specification (RAS) describes a standard for consistently organizing and
packaging assets. This standard requires that assets include the following sections, which
are also shown in Figure 7-28 on page 160:
Classification
Contains name and value pairs that describe, classify, and categorize
the asset
Solution
Contains the asset’s “payload” (that is, the artifacts, such as models,
code, and so forth, which comprise the solution that the asset
provides)
Usage
Provides usage instructions
Related Assets
Describes the association, aggregation, dependency, and so forth with
other assets
Chapter 7. Adopting Asset-Based Development
159
Figure 7-28 Reusable Asset Specification
The tooling that we use for producing, consuming, and managing assets must support the
RAS standard. We do not want to end up with just a scrap heap that contains a collection of
stuff that no one can figure out how to use. To support strategic reuse, the assets that are
created, in addition to providing a correct and proven solution, must be packaged as a
reusable asset. The Reusable Asset Specification provides us with a mechanism to use in
increasing the reusability of our assets. In addition, we are able to leverage an industry
standard, which prevents vendor lock-in.
7.25 Reuse vision
Asset-Based Development uses standards, processes, and tooling so that software
development artifacts can be reused. This development method leverages previous
development efforts, reduces development time and costs, reduces maintenance costs, and
improves product quality.
Figure 7-29 on page 161 depicts the Component Business Model (CBM) heat map for ZYX
Electronics, capturing the key business areas and priorities for the organization. The IT
organization within ZYX needs to ensure that our work is tied to the business needs of the
organization. The heat map indicates the key business components, as well as the most
important areas where we need to focus our efforts and investment. When we have proven
our reuse approach, we will broaden the scope of the reuse program. In the initial rollout and
pilot, we will focus on the second tier priorities, because they allow us to continue to deliver
value to the business. However, if issues arise, we will not jeopardize the most important
areas of the business.
160
Strategic Reuse with Asset-Based Development
Figure 7-29 ZYX Electronics component business model heat map
ZYX Electronics has initiated efforts in Asset-Based Development and strategic reuse to
support the Credit Administration business component. As discussed in the Reuse
Assessment, the initial efforts for reuse will focus on this business area and the associated
development organization.
We want to support business agility and flexibility within Credit Administration. The business
drivers within this component are based on the following requirements:
Centralizing siloed departments and building optimized services to support the converged
organization and then negotiating better prices with our vendors and taking advantage of
our combined size to help us:
– Decrease the negotiated cost (vendor volume discounts) of credit report retrieval by
20%.
– Automate 75% of all credit report retrievals.
Implementing consistent business rules to manage risk
Decrease the number of credit report retrievals by 10%.
The development team wants to reduce software development costs, increase software
quality, and reduce software maintenance costs.
In this section, we describe ZYX Electronics’ vision for Asset-Based Development.
Chapter 7. Adopting Asset-Based Development
161
7.26 Vision
The overall vision of the ZYX Electronics Asset-Based Development (ABD) strategy is to
produce systems through a strategic reuse program in support of the following themes:
Business alignment in support of a larger IT Governance requirement. We need to ensure
that the investments made in the reuse program support the business. The result will be
targeted investments that support business agility and flexibility.
Reduce software development costs.
Increase software quality.
Reduce software maintenance costs.
The ZYX Electronics business drivers that motivate this vision are:
Improve business agility and flexibility.
Improve efficiency of business operations.
Reduce skill shortages.
Meet rising customer expectations.
The ZYX Electronics IT drivers that motivate this vision are:
Leverage Reuse Strategy in all architectural layers, including in the code.
Improve maintainability, availability, and scalability.
Minimize total cost of ownership.
Reuse is a two-part decision process: first, the organizational level decision to institute
strategic reuse and second is the decision for practitioners to practice reuse at lower levels of
the organization. Both decision levels require management support and enforcement. For the
reuse vision to be successful, the application development teams must see from the start that
the reuse efforts provide value to their development challenges and assignments. Relying on
a Reuse Strategy that holds out benefits in the distant future will fail.
Therefore, assets must be identified early that have high value for a targeted Asset
Consumer audience, namely, the application development teams. There are two approaches
here: identify assets that are reusable across a broad sector of the development teams or
identify assets that are highly valuable to a narrow sector, perhaps for a specific project or
two. The latter strategy tends to be more approachable, because it helps to control scope,
cost, training, project coordination, and so on.
To successfully implement the reuse vision, there are fundamental principles that must be
observed. Without support for these principles, implementing the reuse vision is placed at
risk:
Management support for Asset-Based Development. In particular, the management team
will monitor the team deliverables and reuse metrics and will both recognize and
encourage reuse.
Seek ways to shift the extra costs and risks of reuse production and consumption out of
the individual application development projects and into the core asset development team.
Look for high quality, relevant assets that are critically needed by the target Asset
Consumers, namely the application development teams.
The functional and non-functional requirements must be well understood by both the
application development teams, as well as the core asset development team.
Application development teams have limited resources available for reinvention.
162
Strategic Reuse with Asset-Based Development
There is a strong architect, who acts as the reuse guardian for asset assessment and
usage.
Seek reuse opportunities where they have the highest probability of a net positive project
payoff. A key aspect of this principle is that we will have team members enabled on
pattern-based engineering to ensure that we find and build assets that provide an ROI
within the projects where they are used.
Recognize and encourage all forms of reuse that have net benefits at a project level,
which includes reusing document templates, procedures, and so on.
With these principles in mind, the reuse vision is to provide cost-effective assets that provide
value to Asset Consumers – in particular, application development teams – so that there is
business value to using these assets. The business value can be described in terms of
increased production time, lower development and maintenance costs, improved return on
investment, and so on. The reuse program can be altered to focus on the identified value that
the business seeks to obtain.
A critical element of this vision is that the reuse program is implemented so that the costs of
reusing assets are continually pushed down. The reuse cost is a major factor in the success
of the reuse program. Increasing the packaging costs to decrease reuse costs is generally a
reasonable strategy. However, having nicely documented non-reusable assets only
increases costs for the business. Refer to 7.27, “Identified risks” on page 166.
Of particular importance at ZYX Electronics is a desire to avoid unnecessary formality and
over-engineering. Therefore, we leverage iterative and incremental approaches to building
our assets. At the end of each iteration, there must be a reviewable deliverable.
A critical aspect to controlling asset production and reuse costs is through the nature of the
relationship of the asset development team and the Asset Consumer teams. As part of the
reuse vision, the asset development team provides resources for ensuring the success of
assets on the asset consumption teams. This not only helps the asset consumption teams in
terms of their costs, but it also provides valuable feedback on the assets that benefits future
asset development efforts.
The scope of the reusable assets can also affect the cost. As seen in Figure 7-30 on
page 164, there are multiple scope levels regarding how an asset can be reused within an
organization. Generally the higher the asset’s scope for reuse, the higher the testing,
packaging, communicating, and maintenance cost. The strategy for this reuse, as outlined in
this document, is to start with smaller scoped assets and then grow the scope across the
phases over time as experience and lessons learned are gathered.
Chapter 7. Adopting Asset-Based Development
163
Figure 7-30 Asset reuse scope
With the guiding principles outlined in this vision, the real focus becomes what can help ZYX
Electronics develop systems to meet the overall vision and business drivers that have been
specified.
There are four major aspects to how we plan to leverage reuse, including:
Open source software: An abundance of open source software is available for use by
organizations. ZYX Electronics will leverage assets from the open source realm. An
important concern with this aspect is a need to ensure that all legal issues are addressed
and managed.
Tools and frameworks: Industry leading tools and frameworks will be leveraged. A
preference for open standards and specifications exists.
Services: ZYX Electronics is adopting the SOA architectural style. Therefore, there is the
expectation that siloed application development will be reduced or eliminated, services will
be reused, and there will be alignment with the business. As part of this effort, work will be
done regarding how to ensure that business services are reused, Composite Business
Services are created and used as necessary, and the WebSphere Business Services
Fabric is leveraged as appropriate.
Pattern-based engineering: A strong bottom-up, quick ROI approach to building pattern
implementations in support of frameworks, industry best practices, and ZYX Electronics
best practices is required.
7.26.1 Realizing the vision
The overall vision is to provide a set of assets that conduct a series of transformations from a
description of the business or organization ultimately to the code. This vision must be
approached in controlled steps. These steps are outlined in this section of this document.
Implementing the entire vision requires a level of familiarity with pattern technology and a
commitment to support sophisticated assets. Figure 7-31 on page 165 describes the
significant steps for realizing the vision.
164
Strategic Reuse with Asset-Based Development
This approach is a top-down, model-driven style of reuse. There are multiple styles for
addressing reuse. This template only illustrates one approach.
Figure 7-31 High-level ABD process steps
The exact steps and approach will differ depending on the aspect and the types of assets. For
example, this approach can be compressed via the use of pattern implementations that infuse
architectural best practices and decisions. Therefore, it might be possible that the seven
steps turn into a smaller number of steps, such as two or three steps. The number of steps
will depend on the patterns that are identified and the amount of variability that exists. Also,
the input models into the patterns can be graphical, as shown in Figure 7-31, or they can be
textual (for example, XML-based). For more information about a pattern-based engineering
approach, refer to Part 4, “Patterns” on page 455. For more details about a Service-based
approach that leverages Composite Business Services and the WebSphere Business
Services Fabric, refer to Part 3, “Service Assets in an SOA” on page 333.
Next, we briefing describe each of these steps. For more information about ZYX Electronics’
Asset-Based Development (ABD) process, see Part 2, “Reusable Assets” on page 123:
Step 1: Business Process/Solution Architecture Mapping: Starting with the ZYX
Electronics Business Model (considered a mandatory input), the IBM Patterns for
e-business are applied, which describe the mapping of the business processes onto a
runtime topology. Then the product mapping is developed, which identifies the
technologies and products that are to be used within the high-level Solution Architecture.
Chapter 7. Adopting Asset-Based Development
165
In addition, an analysis is done to determine which industry and open source software
frameworks must be included in this solution. In cases where it is clear that certain
frameworks will fit, a further analysis for identifying supporting assets and best practices
that are associated with the framework will be conducted.
Step 2: Application Use-Case Modeling: The application use cases that implement the
business processes are defined. As can be expected, work is done to prioritize the use
cases, and consideration is given to the iterations in which the use cases will be attacked.
In addition, a pattern opportunity analysis will be done to find areas of recurring problems
that can be addressed via pattern-based assets. As part of the analysis, a search for
exemplars will be performed. In cases where exemplars do not exist, archetypes will be
built to serve as input into the pattern creation process.
Step 3: Application Behavioral Modeling: The key abstractions, use-case realizations
(for example, interaction diagrams), and other behavioral models are created. In cases
where we have identified a pattern opportunity, we perform these tasks in building the
archetype. In cases where we have a unique and non-repeating solution, we will leverage
this approach to build the solution.
7.27 Identified risks
There are several key risks that must be understood and mitigated in the organization. We
describe a list of several of these risks with an accompanying mitigation strategy next.
7.27.1 Asset misidentification
There is a general tendency in asset identification to consider that each “interesting” piece of
code or other artifact is reusable. If this course of action is followed, it tends to produce a
large number of assets that are in fact “interesting”, but in reality are not reusable. This tends
to drive up the costs of the asset reuse effort, therefore, pushing out the time line when a
return on investment can be achieved.
Mitigation strategy
Identify asset identification criteria and conduct regular asset surveys and assessments with
these criteria. Establish governance policies and acceptance policies whereby management
has the option to accept or deny the development and long-term maintenance of the asset. In
addition, leverage the Asset Scorecard as published in Chapter 6 of the Strategic Reuse with
Asset-Based Development book.
7.27.2 Asset Consumer mis-targeting
Although an asset might have been thoroughly evaluated and the proper governance
strategies have been identified, the asset might be packaged and organized at a level that
misses the skill level of the target Asset Consumer. What this means is that assets are
produced that are too difficult or complex for the target Asset Consumer to use. This drives up
the reuse costs, which drives down the business value proposition and the time line for
achieving a return on investment.
Mitigation strategy
Establish an asset packaging policy that tests the organization of the asset’s documentation,
guidance, and even variability points that eases the effort to reuse the asset. Increasing
packaging costs to lower reuse costs are a critical part of the success of the asset reuse
166
Strategic Reuse with Asset-Based Development
activities. Another key element to the mitigation strategy for this risk is to establish training for
the Asset Consumers on the process, tooling, policies, and guidelines early in the asset reuse
program.
7.27.3 Volume-centric Repository
Management can mandate that there must be “x” number of assets within a certain time
frame. With this motivation, the organization can focus its energies on meeting this objective.
The result is that the Repository can truly reflect this number, but the value of the Repository
is generally low while the cost goes up as fewer valuable, reusable assets are found in the
cadre of assets. A key concept on which the team must be educated is that there is a cost
associated with reuse failure. Focusing solely on volume increases the number of failures and
negatively impacts the reuse culture that we are trying to create.
Mitigation strategy
Set objectives in place that seek to positively impact the value to the Asset Consumer’s
project, such as increased productivity or decreased development and maintenance cost.
The Repository must always be kept fresh through asset usage reviews, statistics, and
feedback. Assets must be retired that are not providing value to the Asset Consumers.
7.27.4 Asset governance
Assets are identified and developed, but no clear sponsor has been identified. The sponsor
owns the responsibility of funding the development and maintenance of the asset over the life
of the asset.
Mitigation strategy
The assets that are commissioned and developed by the reuse team will be owned and
maintained by the reuse sponsor’s funding. Those assets developed by the application
development teams will be owned and maintained on the budgets of the respective projects.
The application development teams can propose assets to the reuse team to own and
maintain. The business case for the cross-project relevance of the proposed asset must be
achieved. If the reuse team takes ownership of a project-developed asset, the funding model
must support the reuse team’s ownership and maintenance costs associated with the asset,
because there will generally need to be refinements to the newly acquired asset to support a
broader reuse scope.
7.27.5 Over-engineering
There is often a tendency to build the perfect reusable asset that will solve the entirety of the
problems facing a project. Development time becomes lengthy, costs rise, and the asset
development becomes a project unto itself.
Mitigation strategy
An iterative and incremental approach to asset creation will be a key aspect to the mitigation
strategy. We will avoid the creation of custom and in-house frameworks and other large scale
assets. A compositional approach to building larger solutions must be followed, which means
that we plan to have a selection of smaller assets, which can then be composed into larger
and larger solutions.
Chapter 7. Adopting Asset-Based Development
167
7.27.6 Do It Yourself (DIY) equals innovation
A perception that “Do It Yourself” (DIY) equals innovation arises, where in order to be
innovative, you have to build and do everything on your own. Therefore, the team only looks
to internal sources for best practices, solutions, and assets.
Mitigation strategy
Innovation can be achieved by bringing together a number of smaller assets in a unique
composition. Therefore, we again stress the importance that we will favor smaller,
composable assets. We can create new and innovative compositions quickly and easily from
a selection of smaller and proven assets. Those assets can be built by ZYX Electronics or
sourced from other organizations (either commercial or open source).
7.27.7 Budget and resources
The level and number of resources required to support Asset-Based Development is
underestimated. The organization does not have a sufficient budget to establish and maintain
the reuse environment, including both processes and tools. The lack of both resources and
budget can severely jeopardize the success of the reuse program.
Mitigation strategy
We will leverage estimation and cost calculators provided by industry sources to assist in
building reasonable estimates. In addition, we will focus on finding assets that quickly
produce desired levels of ROI.
7.28 Reuse environment
7.29 Reuse environment
A very important part of a successful reuse program is the establishment of a reuse
environment, where that environment consists of both a well-defined process and automation
that directly supports the process. In this section, we provide a high-level view of the
envisioned reuse environment at ZYX Electronics. The reuse environment focuses on the IT
drivers just listed with a heavy emphasis on making the application development process
simple and avoiding undue complexity for the organization roles supporting the process. Note
that we will be leveraging the Asset-Based Development and Asset Governance Rational
Method Composer plug-ins as the basis of our process. The expectation is that we will refine
and customize the process workflows, roles, and process content as we gain experience with
our reuse program.
7.30 Asset-Based Development process
For the Asset-Based Development process to be used at ZYX Electronics, ZYX needs to
implement the Reuse Strategy defined in this document. A high-level view of the process is
shown in Figure 7-32 on page 169. You can obtain more details about the workflows,
activities, roles, and disciplines in the Asset-Based Development and Asset Governance
Rational Method Composer plug-ins.
168
Strategic Reuse with Asset-Based Development
Figure 7-32 ZYX Electronics ABD overview diagram
Rational Method Composer will be used to publish a ZYX Electronics-specific RUP
configuration that includes process guidance for Asset-Based Development and Asset
Governance.
7.31 Organization
In this section, we describe how the ZYX Electronics organization will be structured to support
Asset-Based Development. The ZYX Electronics entities involved in the Asset-Based
Development process are shown in Figure 7-33 on page 170.
Chapter 7. Adopting Asset-Based Development
169
Figure 7-33 ZYX Electronics organization chart
We describe these organizational roles and their responsibilities with regard to reuse next:
ZYX Electronics management (CIO and CTO): ZYX Electronics management needs to
support the reuse efforts in order for those efforts to be successful.
Chief Technology Officer (CTO): The CTO oversees and leads the Solution Architects.
Enterprise Architecture (EA) Team: The EA Team is responsible for developing,
implementing, and maintaining the Enterprise Architecture within ZYX Electronics. Within
ZYX Electronics, the Enterprise Architecture is represented in multiple levels, each with its
own architectural framework, and each with its own architect:
– Solution Architects are responsible for assembling and integrating core assets and
developing solutions to specific technical requirements (Solution Architectures).
– Application Family Architects are responsible for application architectures that
leverage commonality across a family of applications (Application Family
Architectures).
– Application Architects are responsible for the development of the software
architectures for specific application architectures.
Reuse Team: The Reuse Team shoulders much of the Asset-Based Development
responsibilities. The Reuse Team provides the reuse environment (both process and
tools), develops the core reusable assets, certifies all produced enterprise assets,
manages the enterprise asset repositories, and manages and coordinates the overall
reuse program.
Core Asset Development (CAD) Team: The Core Asset Development (CAD) Team is
responsible for performing the hardest tasks of qualifying, harvesting, and delivering the
core reusable assets. Assets can be commissioned to be built from respected Asset
Producers, who can be the Reuse Team or a specific domain expert. The Reuse Team
will build several of the assets and will gather funding to pay respected Asset Producers to
170
Strategic Reuse with Asset-Based Development
develop and maintain reusable assets. At times, a respected Asset Producer might need
to be pulled into an application development project to provide support. The CAD team
requires the funding to support this kind of activity.
Reuse Working Group (RWG): The Reuse Working Group (RWG) includes
representatives fulfilling each of the Asset-Based Development process roles (for
example, asset production, asset consumption, and so forth). The RWG serves as the
champion for the reuse program, communicating management’s goals regarding the
reuse program and reporting on the progress of achieving those goals.
The RWG supports the development of the Asset-Based Development environment
(including the ABD guidelines), identifies candidate assets, approves the development of
enterprise assets, and encourages inter-organizational cooperation.
The RWG provides asset marketing services to the architecture and application
development teams (the primary Asset Consumers). Representatives from the RWG work
with the development teams to understand their requirements and then they communicate
to those teams the kinds of assets that are in the Repository that might fit those needs.
The RWG also provides asset support services to the architecture and application
development teams to help ensure the success of using the assets. They formally solicit
feedback from the development teams in order to understand the effectiveness of the
assets; this information is then communicated to the Asset Development team to improve
the assets.
Asset Certification Board (ACB): The Asset Certification Board (ACB) is responsible for
certifying assets before they are published in the asset Repository.
User Requirements (UR) Team: The User Requirements (UR) Team is the liaison
representing the users and their requirements. This role exists in application development
and is impacted by the set of assets that begin to flow within a description of the
requirements and the users’ needs.
Business Architect (BA): The BA drives the activities for describing the business
requirements, processes, and use cases. The BA role exists as part of the business unit
and application development teams. The BA is impacted through assets that describe the
business and also is responsible for ultimately driving the technical solution from the basis
of the business description.
The previous organizational role descriptions provided a high-level strategy for how the ZYX
Electronics organization will support Asset-Based Development.
7.32 Asset production strategy
Before producing assets, important decisions must be made regarding what assets will be
developed, who will develop them, and when they will be built.
There are multiple approaches for identifying the assets to be built:
Identifying candidate assets based on an analysis of the domain (top-down approach)
Identifying candidate assets by reviewing existing artifacts (bottom-up approach)
The initial strategy for selecting assets to build will follow a bottom-up approach. In this
approach, we will evaluate and harvest artifacts from the landscape of existing artifacts and
systems within ZYX into potential reusable assets. We will avoid the prohibitive costs of
performing a top-down analysis of the ZYX Electronics domain. This does not preclude
developing reusable assets based on performing domain analysis or building new assets
from scratch, which can be pursued further in the implementation of this strategy.
Chapter 7. Adopting Asset-Based Development
171
There are also multiple options for determining where in the life cycle the assets are built:
Prior to application project development
During application project development
After application development projects have been completed (harvesting assets)
There are several places within the organization that assets can be produced: the reuse team
and the application development teams. The reuse team operates outside the context of any
given project, but it certainly must be tightly associated with the application development
teams to ensure the success of the teams’ use of reusable assets. Application development
teams can also develop reusable assets, although the scope of these assets is bound by the
current project on which they are created. Application development teams building assets
must be aware of the potential costs of creating and maintaining reusable assets. In certain
cases (that is, with small, closely located teams), informal reuse can occur, and this is
encouraged where possible and where the obvious benefits exist.
Initially, the reuse team will create assets based on conducting reuse assessments and
determining redundant problems and solutions across the teams. The artifacts from these
projects will be harvested and organized for reuse. It is possible to see a time when the reuse
team can create artifacts and assets from scratch, rather than from harvesting activities.
There are several reuse failures that can occur during asset consumption. These failures
must be addressed as part of the reuse program management and the asset production
activities. A reuse failure is ultimately when an asset is not discovered, found, or cannot be
used, as listed:
Assets are not searched for: In other words, the asset repositories are not being used.
This situation creates the need for incentives and influencing the behavior of potential
Asset Consumers.
Assets are not found: Tracking the nature of the queries on the Repository to help Asset
Producers understand the needs of Asset Consumers helps mitigate this situation.
Asset cannot be used: The asset does not accomplish what is needed. The earlier in the
asset consumption workflow that it can be determined that the asset is not going to meet
the needs, the less expensive the reuse failure is. Therefore, this situation creates the
need to have strong packaging and documentation that outline the asset very clearly so
the decision to not use the asset can be made as early as possible. This situation also
creates the need for a strong asset certification workflow.
The real goal is to lower the costs of reuse, and this goal falls squarely into asset production
(effective asset consumption depends on effective asset production). The goal here is to
reduce the number of reuse failures that are more costly, such as discovering the asset will
not work after the asset has already been brought into a project and development activities
are taking place, or discovering the asset will not work during testing and validation. This
experience is expensive reuse failure, and many times, it can be mitigated through strong
asset packaging and documentation strategies. The assets must be high quality and well
documented. There can be variants of the same asset supporting the same functionality but
supporting different performance requirements.
7.33 Reuse infrastructure
It is extremely important that we have tooling that supports us in creating our assets.
Automation and simplification lead to situations where asset quality is higher, quicker to
market, and in many cases, easier to consume. The more that we can automate and simplify
the creation of assets, the easier it becomes to make the case that we must build the asset.
172
Strategic Reuse with Asset-Based Development
The general tooling infrastructure for supporting Asset-Based Development is illustrated in
Figure 7-34.
Figure 7-34 Asset-Based Development tooling infrastructure
7.34 Reuse implementation strategy
In this section, we discuss the approach and steps that will be taken in adopting a reuse
adoption program.
7.34.1 Reuse adoption strategy
The reuse adoption process13 that is being applied at ZYX Electronics is shown in
Figure 7-35.
Figure 7-35 Reuse adoption steps
The adoption strategy includes the following simple steps:
Initiate: In this phase, we acquire a commitment from the organization to investigate
adopting a reuse approach.
Investigate: In this phase, we determine the feasibility of leveraging reuse within an
organization. An important aspect of this work is to ensure that a clear understanding of
the business drivers exists and how reuse aligns and supports the business.
13
Lim, Wayne C., MANAGING SOFTWARE RE-USE, 1st, ©1998. Electronically reproduced by permission of
Pearson Education, Inc., Saddle River, NJ.
Chapter 7. Adopting Asset-Based Development
173
Plan: In this phase, we create a plan that details how we are going to leverage reuse
within the organization.
Implement: In this phase, we follow through on our plan and work to become a
reuse-based organization.
Improve: As we follow through on our plan, it will likely become apparent that we will learn
about reuse, our organization, and the need to make adjustments. In this phase, we
recognize the need to improve our approach and then roll those improvements back into
our plan.
During initiation, the Reuse Team gained an understanding of Asset-Based Development
and presented it to several levels of management for support and commitment. The Reuse
Team then initiated a program (investigation) to explore Asset-Based Development concepts
and work with Rational to develop an initial set of guidelines and standards to prepare ZYX
Electronics for Asset-Based Development. As part of the initiation, the decision was made to
that we will make two passes through this adoption model as part of the reuse rollout. In this
first pass, we will go through all of the steps in a pilot project. Then, based on the results from
the pilot, we will take a second pass through the model as part of a larger rollout.
Figure 7-36 depicts the high-level steps that we will include in the pilot project. The results
from the pilot project will feed into this document, as well as into a second pass of the
adoption strategy.
Figure 7-36 Pilot project phases
ZYX Electronics is currently in the investigation phase. With the support of Rational, ZYX
Electronics has started to investigate how to implement a reuse program within ZYX
Electronics. The results are described in the ZYX Electronics Asset-Based Development and
Strategic Reuse Guidelines and Standards document set. The purpose of the guidelines and
standards is to provide a solid foundation for the ZYX Electronics Asset-Based Development
and strategic reuse initiative. The ZYX Electronics Asset-Based Development and Strategic
Reuse Guidelines and Standards are:
Part 1: Reuse Strategy (this document)
Part 2: Asset-Based Development Process Overview
Part 3: Asset Packaging Guidelines
Part 4: Asset Configuration Management and Version Control Guidelines
Part 5: IBM Patterns for e-Business Guidelines. You can refer to these guidelines and
associated guidelines at:
http://www.ibm.com/developerworks/patterns/
Part 6: Asset Modeling Guidelines
Part 7: Asset Certification
174
Strategic Reuse with Asset-Based Development
Part 8: Asset-Based Development User’s Guide
As part of the investigation, ZYX Electronics also worked with IBM Rational to develop an
initial phase plan for implementing Asset-Based Development at ZYX Electronics.
After the results of the investigation have been presented to ZYX Electronics management
(CIO) and those results are approved, ZYX Electronics will enter the planning phase.
During planning, ZYX Electronics will work with IBM Rational to refine the initial
implementation plan and prepare a detailed plan for implementing Asset-Based Development
within the organization, including identifying the steps to get started.
In parallel with the planning phase, the Reuse Working Group (RWG) will provide leadership
and reach out to the ZYX Electronics community and will present the Asset-Based
Development strategy to several levels of management for support and commitment.
During implementation and improvement, the implementation plan will be conducted and the
reuse program (including the reuse environment) will be refined as lessons are learned. At
the completion of these steps, we will roll these lessons into the second pass through the
adoption model.
7.35 Maturity model
In order to determine where our reuse capabilities are as a company, we will set the bar
against known criteria. In the software industry, several maturity models have been
documented and found to be effective in measuring a company’s current software
development and asset reuse maturity. In addition, a maturity model can provide a road map
in helping the organization plan how they will move forward and advance their approach to
reuse.
Taking reuse into account, other maturity models are available. In particular, ZYX Electronics
will leverage the Reuse Maturity Framework – The Five Stages of Reuse Maturity by Kulton
and Hudson. The Reuse Maturity Framework, as depicted in Figure 7-37 on page 176,
describes the dimensions of a company’s reuse maturity. Although we have a minor issue
with the framework not directly targeting our business, it provides a great deal of value as we
plan a reuse adoption.
Chapter 7. Adopting Asset-Based Development
175
Figure 7-37 Reuse Maturity Framework14
Figure 7-38 on page 177 provides further details regarding the framework by depicting the
characteristics of each level in the framework.
14
Lim, Wayne C., MANAGING SOFTWARE RE-USE, 1st, ©1998. Electronically reproduced by permission of Pearson Education, Inc.,
Saddle River, NJ.
176
Strategic Reuse with Asset-Based Development
Figure 7-38 Five Stages of Reuse Maturity and associated characteristics15
Figure 7-39 on page 178 uses a star shape to show the “as is” – current state – assessment
of ZYX Electronics’ position within each of the categories in the framework. The target symbol
is used to indicate the desired endpoint for the organization in the medium term. Longer term
advancement along the framework will depend on results during the pilot and then in the
initial rollout of the program.
15
Lim, Wayne C., MANAGING SOFTWARE RE-USE, 1st, ©1998. Electronically reproduced by permission of Pearson Education, Inc.,
Saddle River, NJ.
Chapter 7. Adopting Asset-Based Development
177
Figure 7-39 ZYX Electronics to-be Reuse Maturity Framework16
Figure 7-40 on page 179 shows the motivation and travel events that are associated with
each level in the framework. The Motivations and Travel Events will be used loosely as a
guide to indicate when we need to move to a particular level in the framework. These
motivations and travel events usually occur before we can migrate from one level in the
framework to the next higher level. For example, to move from the Initial/Chaotic level to the
Monitored level, we must recognize that competitive pressures require increased reuse. In
addition, the management team must request reports detailing the progress made toward this
reuse goal.
A key challenge for the reuse program will be to prove itself to the organization to earn a
multi-year funding commitment and to reach the Planned level in the framework.
16
Lim, Wayne C., MANAGING SOFTWARE RE-USE, 1st, ©1998. Electronically reproduced by permission of Pearson Education, Inc.,
Saddle River, NJ.
178
Strategic Reuse with Asset-Based Development
Figure 7-40 Progression across stages of reuse maturity17
As a result of the funding commitment issue, we envision the organization migrated from the
Initial/Chaotic level to the Coordinated level in the initial rollout of the reuse program (see
Figure 7-41 on page 180). A longer term goal, when further funding commitments are in
place, will be to move to the Planned and Ingrained levels.
17
Lim, Wayne C., MANAGING SOFTWARE RE-USE, 1st, ©1998. Electronically reproduced by permission of Pearson Education, Inc.,
Saddle River, NJ.
Chapter 7. Adopting Asset-Based Development
179
Figure 7-41 ZYX Electronics next stage in the Reuse Maturity Model18
7.36 Organizational templates
When setting up an organizational structure within which the asset reuse program will
operate, we can leverage organizational templates to help plan the structure. The templates
provide guidance in terms of governance, repositories, and team and organizational
structure. The templates can be used as is or can be modified to better fit within your
organization. Our plan is to use the templates as is when getting started and then to modify
them when we have gained experience in asset reuse. Although this template is not a
maturity model, there is a loose relationship between an organization’s maturity and the
template selected. As seen in the previous section, there are a number of aspects that
surface within a maturity model, such as:
Reuse culture
Process
Funding and sponsorship
18
Lim, Wayne C., MANAGING SOFTWARE RE-USE, 1st, ©1998. Electronically reproduced by permission of Pearson Education, Inc.,
Saddle River, NJ.
180
Strategic Reuse with Asset-Based Development
Each of the organization templates has a number of categories that are used to describe its
characteristics, including:
Reuse scope: The intended reuse visibility. As can be expected, more formality and
structure appear as the scope of the reuse increases.
Governance board: The number and kind of governance boards
Asset management: Location of the resources that manage the assets
Asset manufacturing: Location and resources producing assets
Asset use: The techniques and formality for asset reuse
Figure 7-42 provides a comparison of the characteristics for each of the organization
templates.
Figure 7-42 Organization templates
Figure 7-43 on page 182 provides an overview of the Governed organization template. Key
characteristics of this template include:
Asset production is funded, supporting both the development and maintenance of key
assets.
Use of the assets is supported by the Asset Producers.
Asset use is both planned and opportunistic.
Chapter 7. Adopting Asset-Based Development
181
Figure 7-43 Governed organization template
Figure 7-44 provides an overview of the Enterprise Full organization template. A key
characteristic of this template is that the functions around asset production and asset
management require overhead, and the organization can achieve efficiency by centralizing
them.
A challenge for this structure is that asset production can occur too distantly from the domain
experts working on the projects. Attention and effort need to be in place to ensure that this
undesirable circumstance does not occur.
Figure 7-44 Enterprise Full organization template
We have decided to adopt the Governed organization template for the pilot. Depending on
the success of the pilot and funding levels, the preference is to then move to the Enterprise
Full template.
182
Strategic Reuse with Asset-Based Development
The organization chart shown in Figure 7-44 on page 182 provides a view of the to-be
organization structure after we have completed the pilot of our reuse program. Those
employees who work in the pilot will become a reuse team during the pilot and will then see
their responsibilities grow from just the Credit Administration development team to the wider
organization.
7.37 How it all fits together
Figure 7-45 provides an overview of how the Reuse Adoption Steps, Asset Governance,
Reuse Pilot Project, and the Asset-Based Development content fit together. Remember that
this is not a “one size fits all” approach. As we gain experience with the process elements,
roles, deliverables, and workflows, we will customize and adapt them to the unique
characteristics of our organization. However, until we gain more experience in using this
guidance, we will leverage it as is and leave customization and tailoring until later. Our focus
at this moment is to identify and leverage the high-value aspects of the guidance and focus
on those areas. It is not our intent to adopt all aspects of each of these elements. As
discussed previously, our approach is iterative and incremental.
Figure 7-45 Asset-Based Development tooling infrastructure19
19
Adapted from Lim, Wayne C., MANAGING SOFTWARE RE-USE, 1st, ©1998. Electronically reproduced by permission of Pearson
Education, Inc., Saddle River, NJ.
Chapter 7. Adopting Asset-Based Development
183
7.38 Reuse implementation plan
In this section, we describe the initial plan for introducing the reuse program to the
organization. This plan will be refined and expanded on during the planning phase, and a
detailed implementation plan will be created.
The implementation plan described in this section is a phased adoption plan where variations
of the workflows are applied over time to meet ZYX Electronics’ needs. The phases describe
the major steps to adopting the reuse program within ZYX Electronics. The phases increase
in scope and complexity over time. At the completion of the first phase, the pilot pass-through
the reuse adoption steps, a second pass will be made through the adoption steps leveraging
the lessons learned from the pilot.
The pilot will contain four phases, each of which is discussed further in the following sections.
The pilot will run over two quarters (six months total) with an interim analysis of the progress
and results completed at the halfway point. Internally, the team will be guided to consider this
as six one month iterations. We describe the highlights of this pilot:
1. Establish the initial reuse environment, including both process and tools. This includes
identifying the resources and involved organizational unit to perform the related roles (that
is, the reuse program plan).
Note: The reuse environment will be continually refined/improved throughout all of the
phases.
2. Roll out the reuse environment. All affected ZYX Electronics organizations will receive
training in the Asset-Based Development environment, both process and tools.
3. Harvest existing artifacts and assets.
4. Support the application development teams who use the components.
5. Start discussions with other organizations regarding federated component governance
and development, project and component selection, and so on (in preparation for the
development of federated assets in later phases).
6. Refine the reuse environment, especially the ZYX Electronics Asset-Based Development
and Strategic Reuse Guidelines and Standards, based on the experiences in the pilot
projects.
7.39 Phase one: Existing assets
Next, we describe Phase one and its goals, which consider existing assets.
7.39.1 Description
Although we have had little focus on reuse in the past, we do expect to find a number of
assets already in use within the organization. Therefore, we need to locate the assets,
evaluate the assets, ensure legal compliance as necessary, and make the assets available
for other people to use. This is a key step for the organization, because it provides a quick win
and provides momentum for the organization.
184
Strategic Reuse with Asset-Based Development
7.39.2 Goals
The goals for this phase include:
Get a quick start to reuse.
Get teams thinking about reuse.
Ensure license and legal compliance with open source software use.
Get team started using reuse adoption model (RAM) and consulting RAM for assets.
Start collecting feedback and discuss the assets.
Define communities and asset types within the asset Repository.
7.40 Phase two: Pattern-based engineering rollout
Next, we describe Phase two and its goals, which consider pattern-based engineering.
7.40.1 Description
In this phase, we get the team enabled on pattern-based engineering (PBE) and leveraging
this approach in how we deliver software. A key appeal of starting with this approach is the ability to
learn how to build patterns quickly, build patterns, and deliver a positive ROI. A key aspect of
this work is opportunity identification, where the team is able to analyze the work that needs
to be done for pattern opportunities. Perform evaluations of other preexisting pattern
implementations that are provided by third-party sources.
7.40.2 Goals
The goals for this phase include:
Enable the team to build pattern implementations.
Evaluate, select, and acquire pattern assets from third-party sources.
Include pattern activities in project plans.
A pattern opportunity identification mentality is created within our development
organization.
7.41 Phase three: Services as assets rollout
Next, we describe Phase three and its goals, which consider services as assets.
7.41.1 Description
In this phase, we focus on getting the team to look at SOA as a key mechanism for leveraging
and supporting reuse. Therefore, we will enable the team on the RUP-SOMA approach to
creating SOA solutions and in particular will focus on the Service Identification phase.
In addition, we need to find ways to reuse service assets that are made available from
third-party providers. In particular, we need to evaluate the IBM WebSphere Business
Services Fabric (WBSF).
Chapter 7. Adopting Asset-Based Development
185
7.41.2 Goals
The goals for this phase include:
Enable the team to identify, design, and build reusable service assets leveraging
RUP-SOMA.
Identify an initial set of services within the Credit Application component.
Identify opportunities for leveraging WBSF elements within the Credit Application
component.
Enable the team to leverage pattern opportunity identification for finding pattern
possibilities within the creation of service assets.
Complete an evaluation of the WBSF product as a source of reusable service assets.
7.42 Phase four: Post-pilot review and analysis
Next, we describe Phase four and its goals, which consider the post-pilot review and analysis
activities.
7.42.1 Description
In preparation for a larger rollout of the reuse program, we need to evaluate the results of the
pilot project. As part of the evaluation, we capture lessons learned, both good and bad. The
investment in the pilot project is seen as providing payback in improving our odds of success
as we broaden the scope of the reuse program and roll it out to a larger portion of the
organization.
We expect that the ZYX Electronics Asset-Based Development and Strategic Reuse
Guidelines and Standards will be updated based on the experiences in the pilot projects.
The metrics and maturity models will be leveraged to interpret the results of the pilot. The
metrics will serve as a baseline for future iterations.
We will enhance and update the process workflows, roles, and deliverables to better suit ZYX
Electronics.
7.42.2 Goals
The goals for this phase include:
Gather and report on lessons learned from the pilot.
Gather metrics and results that have proven reuse and that prove that a further investment
is warranted.
Create a Repository instance with useful and proven assets.
Provide a foundation upon which the reuse program can grow.
Build a plan for the next phase of the reuse adoption program, looping back to the Initiate
step in the reuse adoption model.
Update the ZYX Electronics Asset-Based Development and Strategic Reuse Guidelines.
186
Strategic Reuse with Asset-Based Development
7.43 Metrics for measuring progress
Figure 7-46 provides an overview of the sources available for generating metrics related to
our reuse program. Capturing metrics is a key aspect of our Strategic Reuse program
adoption, because we need to ensure that we are managing our investments. Therefore, we
need to understand details regarding asset production, asset consumption, and asset
management.
Figure 7-46 Sources of metrics
Successfully measuring the reuse program is based on the fundamental premise of a
consistent measurement and comparison framework. Crucial to this framework is the need to
agree early in the process how reuse will be measured in the organization. There must be
agreement on the metrics and the definition of how those metrics are calculated and captured
for reasonable comparison and reporting.
Identifying the business needs and the measurements for meeting those needs ultimately
guides the organization to the set of behaviors for addressing the needs. The reuse program
must operate within the context of the business needs. Progress toward meeting those needs
must be measured on a regular basis. To do this, the following list identifies business
motivators for conducting reuse activities. The metrics for these motivators and the
approaches for collecting them must be defined. In practice, there must be a minimal set of
Chapter 7. Adopting Asset-Based Development
187
motivators that are initially selected; when selected, the proper metrics and measurement
techniques must be put in place:
Reduce development costs.
Reduce maintenance costs.
Increase productivity.
Improve product quality.
Provide a consistent look-and-feel.
Remove the barriers to entry for new products.
The general framework for categorizing these metrics is illustrated in Figure 7-47.
Figure 7-47 Reuse metrics framework 20
Each category in Figure 7-47 lists sample metrics to consider. Considering the potential
breadth and depth of the metrics outlined in Figure 7-47 and the costs of capturing those
metrics, a subset of these metrics will be gathered initially for the purposes of the ZYX
Electronics reuse program. The categories for these initial metrics must include economic
metrics, primary metrics, and Asset Consumer feedback. As the program matures, additional
metrics must be added to each category, as well as specific categories of metrics, such as
library metrics and so forth.
7.44 Economic metrics
For general economic metrics, consider two categories: producer costs and consumer
benefits. In the area of producer costs, there are startup costs and ongoing costs. There can
be a different funding model for the startup costs than for the ongoing costs. Table 7-1 on
page 189 illustrates items to consider tracking.
20
Lim, Wayne C., MANAGING SOFTWARE RE-USE, 1st, ©1998. Electronically reproduced by permission of Pearson Education, Inc.,
Saddle River, NJ.
188
Strategic Reuse with Asset-Based Development
Table 7-1 Economic metrics
End of year
FY 06
FY07
FY08
$0
$0
$0
Total ongoing costs
$0
$0
$0
Total startup and ongoing costs
$0
$0
$0
Total benefits
$0
$0
$0
Net result
$0
$0
$0
Producer costs
Startup
Reuse management
Work product creation
Library creation
Tools creation
Training/marketing
Other
Total startup
Ongoing
Reuse management
Workproduct creation
Library creation
Tools creation
Training/marketing
Other
Consumer benefits
Total asset ROI
Development resources saved
Quality Assurance resources saved
Development Manager resources saved
Chapter 7. Adopting Asset-Based Development
189
7.45 Primary metrics
Each of the application development teams must capture asset usage metrics, such as
quality impact and productivity impact. These metrics must be reported to the reuse team for
assimilation and reporting.
These metrics capture items, such as level of quality, productivity, and time-to-market. The
individual application development teams must identify the impact of an asset on their
development efforts.
7.46 Asset Consumer feedback
Vital to any program is the need to collect and evaluate feedback. Early in the reuse program,
there must be mechanisms in place to capture, assimilate, and report Asset Consumer
feedback.
The Asset Consumer and application development teams must identify the asset’s ROI using
a simple asset ROI calculator. Also, the Asset Consumer must identify and report the
percentage of reusable assets within the application. The following links help to capture asset
ROI and other measurements:
http://home.stny.rr.com/jeffreypoulin/html/reucalc_basic.html
http://home.stny.rr.com/jeffreypoulin/html/reucalc_adv.html
7.47 Library metrics
The driver for these metrics must not be the number of assets in a Repository. This will not
measure the success of the program. Rather, the Reuse Team must keep track of the
locations where assets are used and must glean from the application development projects
the amount of time and money that was saved by using the assets.
There are several types of metrics to track on the library. At the very least, the reuse team
must capture these kinds of metrics for the repositories that they manage. However, this will
take time to get to the point where these metrics can be captured, and the team must be
given time throughout the implementation of the phases to make this happen.
Several types of metrics to track on the library are:
Asset defect rate/time period: Number of defects submitted for an asset in a given time
period
Asset defect correction turnaround: Amount of time from receiving a change request to
publishing the revised asset
Library search missed hits/time period: Number and content of searches for which no
hits were found in the library in a given time period
Library search hits/time period: Number of searches for which there were hits in a given
time period
Library retrievals/time period: Number of retrievals from the library in a given time
period
Library deletion rate/time period: Number of asset removals from the library in a given
time period
190
Strategic Reuse with Asset-Based Development
Asset change request rate/time period: Number of change requests for an asset in a
given time period
Asset maturity: Breakdown of the asset versions in the library
7.48 Additional considerations
An effective Reuse Strategy involves additional considerations. We describe these
considerations in the following sections.
7.49 Reuse incentives
Planning the reuse program also calls for evaluating the Asset Consumer incentives and
Asset Producer incentives. Incentives generally are needed to align the behaviors of one
group with the intentions of another group. Therefore, an elaborate incentive model can
articulate a deeper problem in terms of the nature of the reuse program itself. This is not to
say that there must be no incentive plan, but rather that it must be modest and must rely on a
foundation and an approach that, by its very nature, provides an immediate value proposition
to those individuals who are seeking to reuse assets.
The reuse program must be structured, where possible, so that the existing values of the
developers naturally lead to the outcomes that are desired by the management. The values of
the target Asset Consumers must be understood. The assets and activities must be prepared
that meet management’s needs and that leverage the values of the target Asset Consumers.
When creating the incentive, only use modest control systems (Fichman, page 8):
Behavioral-based approach
Rewarding projects and individuals based on the levels of reuse. This approach requires
consistency in capturing what is counted, how, and when.
Outcome-based approach
Identifying the results of applying assets, such as improved quality, time-to-market, and
productivity. Refer to 7.43, “Metrics for measuring progress” on page 187 for an
introduction of the types of metrics to capture for this approach. These metrics are more
difficult to capture, and therefore, the incentives for this approach can be more difficult.
Socialization-based approach
Indoctrinate developers on the value of reuse; reach out to the set of values that
developers have and seek to change them; and seek to make the developers’ values the
same as management’s values.
For example, if the target Asset Consumers value high quality in reusable assets, the Asset
Producers must have incentives that are attached to defect reports, which reflect the quality
level of the assets; this approach is an outcome-based approach.
ZYX Electronics must evaluate the values of the target Asset Consumers and producers and
identify the necessary incentives. These incentives must be identified within the context of
Asset-Based Development activities that benefit the target Asset Consumers. To accomplish
this task, there needs to be a consistent effort to communicate the status of the Asset-Based
Development efforts to key stakeholders, and there needs to be sufficient training for all
stakeholders. Without these elements of the program, the incentives will not be as effective.
The CTO and Solution Architecture team will determine the best approach for ZYX
Electronics under the direction of the CIO and other executives.
Chapter 7. Adopting Asset-Based Development
191
7.50 Internal communication model
The reuse activities within the organization must be communicated to several stakeholders,
including executive management, department and division management, project
management, and engineers. The Reuse Coordinator is responsible for all communication of
the reuse program to the various stakeholders. The type of information about the
Asset-Based Development activities that needs to be communicated includes:
Executive management (CIO): Value to organization
Application Project Management: Asset and reuse impact to deadlines, budgets, and
quality
Architects (solution architects and application architects): Relevance of architectural
assets to the applications and problems that the organization is trying to solve
Core Asset Development Team: Reusability of assets, quality, and feedback
Application Developers: Upcoming asset support, impact on development workflows,
and asset complexity
The communication of this information is extremely critical during the adoption phase and
must be communicated on a regular basis. This communication is necessary for the life of the
reuse program. The earlier that this information can be communicated, the sooner the
organization can make appropriate refinements in implementing the Reuse Strategy.
7.51 Training model
The people in the various roles need to be trained on Asset-Based Development processes
and workflows, tools, standards, and policies. This training must occur within the context of
each of the phases just listed. Table 7-2 on page 193 identifies the training that is relevant to
the ZYX Electronics workflows. Each ZYX Electronics workflow has the RUP ABD workflows
within it. The training on these ZYX Electronics workflows also implies training on supported
tooling and policies.
The training needs to provide an overview of the tooling and reuse infrastructure for several of
the roles, such as the Software Architect (SA), Application Architect (AA), Business Architect
(BA), Application Development (AD) Teams, the User Requirements (UR) Team, and the
Reuse Team. However, other roles will need detailed training on applying asset production,
asset management, and asset consumption within the context of the ZYX Electronics
workflows.
192
Strategic Reuse with Asset-Based Development
Table 7-2 ZYX Electronics workflow training model
ZYX Electronics Workflow
SA
AA
BA
AD
UR
Reuse
Business Solution Architecture Workflow
Asset production
Asset management
Asset consumption
Software Architecture Workflow
Asset production
Asset management
Asset consumption
Application Development Workflow
Asset production
Asset management
Asset consumption
Core Asset Development Workflow
Asset production
Asset management
Asset consumption
Asset Certification Workflow
7.52 Funding model
In typical funding situations, the funds are allocated for the activities to deliver the artifacts for
the project. This relationship changes with the reuse model where the funding for assets and
their artifacts can provide value for several projects.
There are several models for funding the reuse team and related reuse efforts:
Overhead funding: The costs for the reuse team are handled in the pool of overhead
expenses.
Tax funding: Each application development project pays a tax, which covers the cost of
the reuse team.
Payments for assets and services: The application development teams pay for the
assets and services that they use from the reuse team.
Clearly, ZYX Electronics needs to determine its funding model for conducting Asset-Based
Development. An initial recommendation is to start with overhead funding and shift to
payments for assets and services. The purpose for this recommendation is to provide time for
startup costs and then move to another funding model, such as for services or assets when
the initial value has been verified. One approach here is to use the overhead funding model
throughout the four phases identified in this document and then shift to an asset and services
funding model thereafter. The CTO and Solution Architect Team will determine the best
approach for ZYX Electronics under the direction of the CIO and other executives.
7.53 References
For more information, refer to:
Incentive Compatibility and Systematic Software Reuse, Journal of Systems and
Software, Apr 27, 2001; Vol. 57, Iss. 1, Robert G. Fichman
Chapter 7. Adopting Asset-Based Development
193
Managing Software Reuse, Prentice Hall, 1998, Wayne Lim
Measuring Software Reuse, Addison Wesley, 1997, Jeffrey S. Poulin
Software Reuse: Architecture, Process, and Organization for Business Success, 1997,
Jacobson, Griss, and Jonsson
Global Development and Delivery in Practice: Experiences of the IBM Rational India Lab,
SG24-7424-00
Patterns for e-business: A Strategy for Reuse, Adams et al., ISBN: 1-931182-02-7
7.54 Looking ahead
In the next chapters, we take a more in-depth look at how we produce, consume, and
manage assets. In addition, we look at how the governance policies that we have chosen will
be enforced, monitored, and acted upon as we move through these workflows.
These next few chapters look at these activities and tasks but do not focus on specific types
of assets. The latter portions of this book, found in Part 3, “Service Assets in an SOA” on
page 333 and Part 4, “Patterns” on page 455, will revisit these topics but with a focus on
specific asset types, including SOA Services and Patterns.
194
Strategic Reuse with Asset-Based Development
8
Chapter 8.
Configure your Asset Repository
This chapter introduces the information metamodel that is used by Rational Asset Manager. A
solid understanding of this metamodel is needed for customizing the Repository to implement
an Asset-Based Development approach that meets the organization’s needs and promotes
reuse.
We also discuss best practices and specific concepts related to Rational Asset Manager
configuration. The chapter wraps up by describing how to apply these best practices to create
an initial Repository configuration for the ZYX Electronics case study.
© Copyright IBM Corp. 2008. All rights reserved.
195
8.1 Rational Asset Manager information metamodel
The Reuse Strategy document that was generated during the Asset Governance Planning
Phase will help you to understand the approach that the organization will take in pursuing
asset reuse activities.
During the Asset Governance Definition Phase, you will use the Reuse Strategy document as
an input and define the tool or set of tools that you will use to support your Asset-Based
Development process. In addition, you will configure this toolset to provide a governed asset
management environment. This is an initial task that needs to be done before users start to
use the Repository. Remember that this initial configuration is not permanent and can be
modified based on experience and user feedback.
This Repository configuration information must be described and detailed in a Usage Model
document. The goal of the Usage Model is to provide a consistent process and tool
environment configuration that will support your specific project’s asset development needs.
As stated in Chapter 7, “Adopting Asset-Based Development” on page 125, we will use
Rational Asset Manager as the collaborative asset management Repository to cover all
phases of asset production, consumption, and management for ZYX Electronics. Different
tools or solutions can use different terms to refer to the Repository structure, so we will start
defining how the Rational Asset Manager Repository is structured, the terms that are used to
define it, and which information you can customize. The objective is to understand how you
can configure your Rational Asset Manager Repository to support an organization’s
Asset-Based Development process. A goal for this work is to ensure that the resulting
Repository configuration facilitates reuse.
Figure 8-1 presents a simplified view of the Rational Asset Manager Information Metadata
Model.
Community X
Assets
Community Map: Users, Roles, Permissions
Asset Workflow Specification: Review Process
Connections to:
Asset Type Specification
Asset Types
Rational ClearQuest,
WebSphere Service Registry and Repository
Community Y
Assets
Category
Schemas
Asset
Attributes
Relationship
Types
Community Map: Users, Roles, Permissions
Asset Workflow Specification: Review Process
Connections to:
Rational ClearQuest,
WebSphere Service Registry and Repository
Figure 8-1 Rational Asset Manager information metadata model
In the next sections, we will explain in detail the terms represented in Figure 8-1, including:
196
Community Map
Asset Workflow Specification
Asset Type Specification
Administration Roles
Strategic Reuse with Asset-Based Development
As part of the explanation, we will also discuss best practices to configure your Rational Asset
Manager Repository to govern the assets that are relevant for your organization.
8.1.1 Community Map
The organization of a Rational Asset Manager Repository in terms of its communities, user
roles, and their permissions is described in a Community Map artifact.
A community is a collection of assets grouped by a common use and purpose. Rational Asset
Manager Repository will contain communities to group architecturally related elements
together, to minimize administrative overhead, and to facilitate access control. A community
is a Repository structure that facilitates user interaction with a group of assets that are
related. An asset can only belong to one community, but users can search for assets in more
than one community at the same time.
Communities are formed by users, their roles and permissions, and their assets and review
processes.
Users can have various roles and permissions on each community. For example, a database
architect will have permissions to create and update database design assets in the Analysis
& Design community, but the database architect only has permissions to search, browse,
and download assets from the testing community that contains the test plans for all of the
projects in the organization.
This access control allows you to implement a consistent Asset-Based Development process
across the whole organization, defining what users can do in each community Repository and
with which assets they can work as shown in Figure 8-2.
Rational Asset Manager repository
Analysis and Design Community
Role = Asset Producer
Permissions to:
Database Architects
User Group
create and update Database Design Asset Types
search and browse other asset types
Can create and modify
Cannot create
or modify
Database Design Asset Type
Open Account database design
Artifacts:
datamodel.ldm
Software Design Asset Type
Open Account analysis model
Artifacts:
use case model.mdx
analysis model.mdx
Testing community
Testers
User Group
Cannot create
or modify
Role = Asset Consumer
Permissions
search and browse Test Asset Types
Can create and modify
Test Asset Type
Open Account test plan
Artifacts:
Test Plan.doc
Role = Asset Producer
Permissions
create and update Test Asset Types
Figure 8-2 Rational Asset Manager access control
Chapter 8. Configure your Asset Repository
197
Important: If you are interested, you can download a template of the Community Map
artifact that is provided as additional material to this book. For details, refer to Appendix C,
“Additional material” on page 725.
Organizing the Rational Asset Manager Repository into partitions of assets for specific users
and interests enhances scalability by easing reusable asset communication and
maintenance, as well as the approachability of the Repository user experience. Making all
assets visible to everyone quickly decreases the value proposition of the Repository, because
it becomes too large for people to navigate.
Administrators will use communities to:
Control the level of access that users will have to the community’s assets.
Define and configure the review processes for specific community’s assets.
Integrate with external tools to extend the default functionality provided by Rational Asset
Manager:
– Use with Rational ClearQuest to customize asset review processes and forum
discussions.
– Use with WebSphere Service Registry and Repository to publish and search for
services in the runtime environment.
To control the level of access of users to the various communities created, the Administrator
will define and configure roles, users, user groups, and permissions:
A role is a collection of permissions that Administrators can assign to individual users or
user groups. Roles are defined by community.
A user is an individual with assigned roles and permissions within a community. A user
can have multiple roles and permissions. Rational Asset Manager manages two types of
users: authenticated or anonymous:
– Anonymous users do not have to log in to the Repository, but they are restricted to
searching and reading the general details of an asset. They have permission to search
for assets, but they do not have permission to modify, download, or view the artifacts’
contents.
– Authenticated users need a valid login and password to log in to the Repository, and
their permissions depend on the permissions assigned by the community
Administrator.
A user group is a collection of users with the same roles and permissions for a particular
community.
Users and user groups can come from an Lightweight Directory Access Protocol (LDAP)
registry or can be manually added to the Repository. For more information about how user
authentication works in Rational Asset Manager, see A.2.4, “User authentication” on
page 657.
Permissions define the actions that a user can perform in any given community. Roles
provide a way for community Administrators to group those permissions and assign them
to all users, particular users, or user groups as shown in Figure 8-3 on page 199.
198
Strategic Reuse with Asset-Based Development
Rational Asset Manager repository
Configure
LDAP
LDAP Group
Community
User Group 1
User Group 2
Query
User Group 1
A list of users that comes
from an LDAP group
Users
A list of users entered
into the repository, or
from LDAP.
Users
Roles
Review Process
User Group 2
A list of users
entered directly in
the repository
Roles
A list of roles and
their permissions,
scoped within one
Community
Review Process
References user and user groups to
participate in the review process.
Figure 8-3 Community roles, user groups, users, and permissions
A role consists of a role name, description, permissions, and scope. Administrators can
constrain the scope of a role by making permissions apply only to assets that meet a specific
criteria (specific types or categories).
Each new community is created with a set of default roles, as shown in Figure 8-4 on
page 200, including:
Administrator: The Administrator has administration capabilities to configure the
community.
Asset Owner: The Asset Owner role is a person or an organization that defines and
submits the asset version, as well as updates or removes the asset version. The Asset
Owner is the original creator of the asset version.
Asset Review Board: The Review Board is responsible for specifying review processes. It
works with the Community Administrator to get the assets into the Repository. The Review
Board identifies the potential reviewers and customizes the review process in the
Repository to add the reviewers. The Review Board also initiates the review in the
Repository, monitors who has submitted reviews, and then evaluates the submitted
reviews and casts the final vote on an asset. This role needs to be optional, allowing
varying degrees of formality in the asset review process.
Asset Reviewer: The Repository notifies the Asset Reviewer when an asset is submitted
for review. The Asset Reviewer selects the asset to review and evaluates the asset,
prepares review material, and then votes to accept or reject the asset.
Asset Consumer: The Asset Consumer searches and browses Reusable Assets in the
Asset Repository, and ultimately uses the assets. The Asset Consumer provides feedback
about the assets.
Asset Producer: The Asset Producer updates an asset version by developing artifacts
and harvesting artifacts, as well as making changes to the metadata. If the updates
require the creation of a new asset version, the Asset Producer becomes the Asset Owner
in the Repository.
Chapter 8. Configure your Asset Repository
199
Figure 8-4 Default community roles
Important: These are the same roles that are defined by default in the Asset-Based
Development plug-in of Rational Method Composer.
Administrators can create additional roles as a method of grouping permissions that can be
assigned to users or user groups. Individual users or groups can have more than one role.
Note: Roles are not used to group Repository users; user groups are used to group
Repository users. Roles are used to assign permissions to individual users or groups of
users.
These Repository roles must be assigned to the various users or user groups of the Rational
Asset Manager Repository. When assigning roles, Community Administrators must consider
a user’s tasks within the context of a particular community. For example, user groups, such
as Analysts, are not required to modify or change development code and only need browse,
download, and submit access in a development community. However, users with a role of
Analyst in the Analyst Community can adopt full permissions so that the Analyst can modify
existing assets or upload new assets in their field of expertise.
The same role can be assigned to different users or user groups, and more than one role can
be assigned to a single user or user group.
The following list describes the permissions available to choose from when defining a role
within a specific community:
Browse assets: Users can view the asset, including the artifacts, which includes
searching and reading details.
Create assets: Users can create new assets. Creating assets includes describing and
adding artifacts.
200
Strategic Reuse with Asset-Based Development
Delete assets: Users can permanently delete assets from the Repository.
Download assets: Users can download assets. This permission also includes describing
and adding artifacts.
Forums administration: Users can administer forums for an asset (if assigned to an
asset role) or administer all forums and forum connections in a community.
Publishing administration: Users can perform publishing actions for an asset (if
assigned to an asset role) or perform all publishing actions (including publishing
connections) in a community.
Read asset details: Users can view asset details beyond the standard search asset
page.
Search assets: Users can search for assets using keyword and filter searches.
Subscribe to assets: Users can subscribe to e-mails or Really Simple Syndication (RSS)
file feeds to receive notification when an asset is modified.
Update assets: Users can update the content or descriptive metadata of assets.
Table 8-1 shows the various roles that are defined by default when a new community is
created and the permissions that are associated by default to each role.
Table 8-1 Roles and permissions for a community
Permission
Administrator
Asset Owner
Asset
Producer
Asset
Consumer
Asset Review
Board
Asset
Reviewer
Browse assets
YES
YES
YES
YES
YES
YES
Create assets
YES
NO
YES
NO
NO
NO
Delete assets
YES
YES
NO
NO
YES
NO
Download assets
YES
YES
YES
YES
YES
YES
Forums
administration
NO
NO
NO
NO
NO
NO
Publishing
administration
NO
NO
NO
NO
NO
NO
Read asset
details
YES
YES
YES
YES
YES
YES
Search assets
YES
YES
YES
YES
YES
YES
Subscribe to
assets
YES
YES
YES
YES
YES
YES
Update assets
YES
YES
YES
YES
YES
YES
Asset Review
Board *
N/A
N/A
N/A
N/A
YES
N/A
Review asset *
N/A
N/A
N/A
N/A
N/A
YES
Note: Permissions marked with * are not available to the Community Administrator to
assign to new roles. These permissions are only assigned and used by the Asset Review
Board and Asset Reviewer default roles.
Chapter 8. Configure your Asset Repository
201
Criteria for creating a community
When making the determination whether to create a new community, there are a number of
different approaches that can be followed. It is unlikely that one approach or one set of
communities works across all organizations.
The most important criteria that you must follow for defining the communities within your
organization is to create a community for each unique set of assets over which you want
specific control and governance. That control might be needed by a manager, a business
unit, or by a customer. So, if your enterprise sees value in providing a place for Business
Analyst assets and controlling the access to and the review and approval process of those
assets, it likely makes sense to create a Business Analyst community.
Tip: Create a community for each unique set of assets over which you want specific control
and governance.
A community can be defined along, but not limited to, multiple boundaries, including:
Organizational unit: You can create a community based on the organization chart.
Project: You can create a community based on a project or an initiative, even though this
is often a temporary community, if you can justify the overhead and the organization.
Users with a common role: You can create a community based on a common role
(Business Analyst) that crosses organizational boundaries.
In Figure 8-5, the Business Analyst Community is organized according to IT role; the Project
XYZ Community is organized according to an IT project; and the Testing Team Community is
organized according to an organizational unit.
Business Analyst
Community
Business Analyst
Repository Permissions
Search asset Browse asset
Retrieve asset Create asset
Update asset Delete asset
Community
Admin
Project XYZ Community
Architect
Service Designer
Service Developer
Repository Permissions
Create asset
Delete asset
Update asset …
Testing Team
Community
Service Tester
Service Assembler
Repository Permissions
Search asset Browse asset
Retrieve asset …
Repository Permissions
Search asset Browse asset
Retrieve asset Create asset
Update asset Delete asset
Community
Admin
Community
Admin
Figure 8-5 Criteria to define communities
There are trade-offs to consider when creating communities, including:
If you create too few communities, the scope can be too broad, leaving the user to
navigate many assets.
If you specify too many communities, the administration costs can become too
burdensome for specifying access control rights, review processes, asset types, and so on
for each community.
202
Strategic Reuse with Asset-Based Development
It will take several iterations to create the proper set of communities. In most cases, the
Repository will need to be configured and then exercised for a period of time in order to
properly refine it. It is best to start with fewer communities and then add more as necessary.
8.1.2 Asset workflow specification
Community Administrators define review processes that provide a framework for reviewing
assets leading to the assets being approved or rejected. This way, users can review and
verify the quality and accuracy of assets according to their specific area of expertise. Within
Rational Asset Manager, this asset workflow specification is referred to as a Review Process.
Review processes can be specific to one or more asset types, specific to one or more
categories, or a combination of both. For example, you can specify different review processes
depending on the business domain to which the component belongs, because each business
domain must follow different workflow approvals. More specifically, if the asset belongs to the
Market Campaigns business domain, it must have only the marketing manager approval, but
if the asset belongs to the Credit Administration business domain, it must go through an
approval and have authorization from the legal and finance departments.
You can also constrain the review process to have different reviewers or review board
members, so that each review is unique and appropriate for each business context.
There can be several levels of governing bodies to oversee the process of approving assets
for reuse. For instance:
At the simplest form, assets can be automatically approved as soon as they are submitted
to the Repository, which can be reasonable for certain asset types.
The next level of review can include one or more reviewers. Based upon their reviews and
the votes that they cast, the asset might be approved or it might be rejected.
There is another level of control, which is to use a Review Board. In this case, the
reviewers submit their reviews and cast their votes. Then, the Review Board evaluates the
submitted reviews and casts the official vote to accept or reject the asset.
Rational Asset Manager has three types of review process:
As is: This means that there is no review process, assets submitted as is are
automatically approved. Administrators normally have to approve the selection of this type
of review process.
Default review process: This review process has specific states and transitions, as
shown in Figure 8-6 on page 204.
Chapter 8. Configure your Asset Repository
203
Figure 8-6 Default Rational Asset Manager review process
The states defined in the default review process workflow include:
– Draft: Only the Asset Owner and Administrators can view the assets. The Asset
Owner can make changes to the asset.
– Plan review: Only Administrators and Review Board members can view the assets.
Administrators and Review Board members can specify reviewers and start the review
process.
– Review: Assets are under review. Reviewers can participate in discussion forums
about the asset and submit reviews concerning the asset.
– Approved: Assets have passed the review. The Review Board has the highest level of
authority to approve an asset, followed by reviewers.
– As is: Assets bypass the review process. Community Administrators can designate “as
is” assets to require administrative approval.
– Retired: Assets are available in the Repository to Asset Owners or Administrators, but
cannot be downloaded.
– Archived: This state makes a retired asset unavailable to users for access.
– Deleted: This state means that assets are no longer available in the Repository.
The states and transitions of this default review process are fixed and cannot be modified,
but the Community Administrator can configure this default review process by adding
different Reviewers or Review Board members.
204
Strategic Reuse with Asset-Based Development
Rational ClearQuest driven review process: Although the default review process is
generic, and it can be used in a wide majority of cases, if the organization requires a
customized review process with different states and transitions, Rational Asset Manager
(RAM) can be connected to the Rational ClearQuest change management tool. With
Rational ClearQuest, you can create a customized review process integrated with the
Rational Asset Manager review process. For more information about how to install,
customize, and use Rational Asset Manager and Rational ClearQuest to implement a
custom review process, go to A.3.2, “Integrating Rational Asset Manager with Rational
ClearQuest” on page 665.
An asset can have more than one review process assigned to it, but Administrators can
assign priority to them, so the users can view the review processes in order of the lowest
priority to the highest priority. Each review process is characterized by a single asset type and
zero or more category selections. The review processes are then ordered in a top-down
review process list. RAM checks this list from the top down. When it locates a review process
that meets all of the characteristics of the asset being submitted, it then uses that review
process. If no review process is found, the asset review process is skipped, and the asset is
automatically approved.
8.1.3 Asset type specification
So far, we have discussed the communities, roles, and review processes associated with an
instance of the Repository. However, we still need to discuss the assets that will go within the
Repository. As you can imagine, we want to continue to work toward creating an environment
where it is easy for the users of the Repository to find the right assets. To help with that
search, the user needs to understand what the asset is, how it can be used, and possibly to
what other assets it is related. Therefore, we will create a set of asset type specifications to
define and capture the assets and related information needed to have a successful
Repository.
Assets can contain any number of artifacts, or relate to other assets, and also have
associated information or metadata that will help users to classify, search, and reuse assets.
Asset metadata includes the following mandatory information fields:
Name
Version
Community where the asset belongs
Asset type
Short description
There are other optional information fields that can be filled by the user when submitting a
new asset, such as a long rich-text description of the asset and tags to help in asset
searches. Also, “creation time” and “usage time” can be specified and later used to produce
metrics and statistics about the usage and return on investment (ROI) of the assets.
Rational Asset Manager can be customized to include additional metadata information and
attach it to the asset. This additional information will be dependent on the asset type that the
user selects.
When creating an asset type specification, there are four types of information to capture,
including:
Asset types
Category schemas
Asset attributes
Relationship types
Chapter 8. Configure your Asset Repository
205
Asset types
An asset type is the primary level of organization for assets within the Asset Manager
Repository. As discussed previously, asset types contain information that helps a user store
and find assets. Another important aspect of asset types is that they also facilitate
governance. Therefore, when a user submits an asset, the asset type controls the information
and artifacts that users must include with the asset.
Repository Administrators can customize the asset type with the following constraints:
Artifacts: You can define rules to control the number and types of artifacts that must be
part of the asset of a specific type.
Categories: A category is a classification that helps to organize assets within the
Repository so that users can find and reuse them more easily. You can configure and
control which category or group of categories the user can complete when submitting a
new asset of a specific type.
Relationships: You can define restrictions to control the number of relationships that the
asset that you are creating needs to have, and you can specify the type of assets with
which it needs to be related.
Attributes: An attribute is an additional information field associated to the asset. You can
control the additional information fields (and make them optional or mandatory) that the
user must complete when submitting a new asset of a specific type.
For example, you can define an asset type called Software Design with the following rules or
restrictions:
Contains at least one “.emx” file, which represents a Uniform Modelling Language (UML)
model
Has at least one related asset of type “Requirement” with a relationship named “design
for”
Defines its associated Business Domain (category)
Defines the type of architecture that is used to implement the asset (Java 2 Platform,
Enterprise Edition (J2EE), batch application, and so forth) (category)
The Repository Administrator can also customize the constraints (category schemas,
relationship types, and asset attributes) that will later be referenced when creating a new
asset type as represented in Figure 8-7 on page 207.
206
Strategic Reuse with Asset-Based Development
Figure 8-7 Asset types reference categories, relationship types, and asset attributes
Tip: Remember that you can also use asset types and categories to constrain the scope of
roles when configuring communities. Therefore, the permissions associated with a role will
only apply to assets that meet a specific criteria.
Category schemas
Category schemas can be used as mechanisms for searching and discovering assets, and an
asset can be classified using values from many category schemas. The category schemas
can be exclusive and unrelated to each other. Using category schemas in this manner
permits many perspectives to be captured. For example, not only do practitioners (architects,
developers, testers, and so forth) work with assets, but certainly Administrators and technical
management will interact with the assets, as well as with report generators, metrics
collectors, and other tools.
Each classification schema must be created with a specific focus. For example, you can
create a classification schema to describe the business domain of interest to the enterprise.
You might create another classification schema to describe the technical contexts for the
enterprise, such as runtime platforms and development platforms.
Category schemas are often created from the perspective of a target consumer. For example,
architects might want to discover an asset’s relevancy from the perspective of non-functional
characteristics so a “Technical environment” category schema will be created as represented
in Figure 8-8 on page 208.
Chapter 8. Configure your Asset Repository
207
Figure 8-8 Asset classified from multiple classification schemas
Category schemas do not have to apply to all types of assets. You can define and use
specific category schemas to facilitate searches and the organization of specific asset types.
Administrators must evaluate the way in which users will view and access their assets. In
general, the Administrator will create one classification schema per perspective. To keep
things simple, remember that not all users need to be burdened with all perspectives.
Tip: When creating the schemas, the use of models or pictures to communicate the
category schema simplifies the effort to achieve acceptance from the users.
Asset attributes
Custom asset attributes are metadata elements that help you to provide an asset with
additional information that fits a specific context.
Custom attributes contain either strings or predefined lists and are defined at the Repository
level by the Community Administrator. They are associated with asset types and might be
required or optional on the asset type.
The following are examples of custom attributes that Administrators can create:
Project: The project that has created the asset
Support contact: The person with the knowledge to answer questions about the asset
Relationship types
Relationships enable users to specify which assets are related to each other within the
Repository and to describe the nature of that relationship. Relationships facilitate search,
governance, and impact analysis.
Asset relationships are bidirectional, and each relationship end has a type. If a user creates a
relationship from asset A to asset B, the reverse relationship exists from asset B to asset A.
For example, if you create a relationship type “Uses open source framework” to describe that
a component asset type was built using an open source framework, you must also define the
reversed relationship “Open source framework used by” to describe that the framework is
being used by the component as shown in Figure 8-9 on page 209.
208
Strategic Reuse with Asset-Based Development
Component Asset Type
Opening Account Application
Artifacts:
openaccount.ear
source files
Uses open source framework
Open source framework used by
Framework Asset Type
Spring Framework
Artifacts:
springfiles.zip
license.text
Figure 8-9 Two-sided relationship types
Rational Asset Manager is pre-populated with the following relationships:
Dependent/Dependency
Parent/Aggregation
Tutorial/Tutorial for
Test/Test for
Specification/Implementation
In order to provide governance, Repository Administrators can place relationship constraints
on an asset type. The Repository Administrator can require users that submit an asset of a
certain type to also include assets of a certain relationship. For example, if the organization
produces assets that require testing, the Repository Administrator can create a constraint on
an asset type so that users must include a related testing asset along with it.
Relationships facilitate searching and also make it easier for a user to access all of the assets
that are necessary for a project. When a user searches for an asset, they can see the other
assets that are related to their project and gain information about the nature of those
relationships.
8.1.4 Administration roles
There will be several administration roles involved when configuring a Rational Asset
Manager Repository. These roles can be played by a single person, but it is more likely that
multiple people will be involved in playing these roles. The administration roles include:
Repository Administrator: Repository Administrator sets up the structure for how the
Repository is organized and how users interact with the Repository. The Repository
Administrator also manages communities, asset types, relationships, categories, and
attributes and has authority to perform any activity within the Rational Asset Manager Web
interface. The main tasks that this role has to perform are:
– Create communities and assign users as Community Administrators.
– Add additional Repository Administrators.
– Configure asset definitions: Define the infrastructure and criteria for assets as they are
submitted into the Repository. This task will include the following actions:
•
Define asset types
•
Define asset attributes
•
Define asset relationships
•
Define Repository category schemas
– View and configure Repository metrics and statistics
– Configure Repository settings
Chapter 8. Configure your Asset Repository
209
Community Administrators: Community Administrators manage access control, review
processes, and configure integrations with external tools, such as Rational ClearQuest
and WebSphere Service Registry and Repository (WSRR), for groups of assets called
communities.
Integration Administrators: An additional Administrator role might be necessary when
Rational Asset Manager is integrated with external tools. This role is responsible for
integrating the Rational Asset Manager Repository with other development life cycle tools,
such as Rational ClearCase, Rational ClearQuest, and WebSphere Service Registry and
Repository.
While Repository Administrators oversee high-level Repository maintenance and
organization, Community Administrators ensure that users can work with the Repository
effectively by managing assets, roles and privileges, review processes, and connections with
external tools as shown in Figure 8-10.
Rational Asset Manager Repository
Community X
Information Metadata Model
Asset Types
Category
Schemas
Asset
Attributes
Users, Roles, Permissions
Review Processes
Connections to ClearQuest, WSRR
Community Y
Relationship
Types
Users, Roles, Permissions
Review Processes
Connections to ClearQuest, WSRR
Figure 8-10 Rational Asset Manager Repository organization
Administrators will use specific Administrator menus that are available in the Rational Asset
Manager Web client to configure metadata information (this functionality is not available in the
Rational Asset Manager Eclipse client). For more information about the differences between
these client types, go to A.2.3, “Installing Rational Asset Manager clients (Web and Eclipse)”
on page 655. The next section in this chapter shows how ZYX Electronics configured their
Rational Asset Manager Repository and gives you detailed information about how to
configure your Repository.
Tip: If the Administrator wants to have a visual representation of a specific Rational Asset
Manager configuration, the Rational Asset Manager Configurator plug-in can be used in
Rational Software Architect to provide a UML visualization of the configuration and allow
you to import and export these configurations into an XML Metadata Interchange (XMI) file.
See A.5.1, “Rational Asset Manager configurator tool” on page 711 for more information.
210
Strategic Reuse with Asset-Based Development
8.1.5 Best practices to customize your Repository
This section provides best practice guidance that you can leverage as you customize your
Repository configuration.
Remember that the configuration of your Repository will be an iterative process, and it will be
redefined and improved over time. You have to define an initial configuration for your
Repository when you start to deploy Rational Asset Manager in your organization, but based
on user feedback, metrics collected, and reports generated, you might need to update the
configuration.
Tip: The main theme running through all of these best practices is that you want to create
a usable Repository. Therefore, you will want to create a logical structure, which is as
simple as possible, and then effectively communicate this information to your user
community.
Community Map
To create the community map:
Start with a basic configuration that is easy to understand. With the introduction of your
new Asset-Based Development process and asset management tooling, a basic
configuration needs to be easy to digest by the users in the short term. Later, the tool
configuration can be modified to include more process detail as your situation allows.
Communities must group architecturally related elements together and facilitate access
control.
Start with fewer communities and then add more communities as necessary.
Create a community for each unique set of assets over which you want specific control
and governance, which will facilitate administration.
When considering creating a role, evaluate the asset types that are defined in the
Repository against asset type specifications. This action can both discover potential asset
types, as well as help refine with which assets the role will be working.
Asset workflow specification
To create the asset workflow specification:
Do not forget to define review processes for the asset types. If review processes are not
defined, assets will not be forced to follow a review process and will go directly to the
approved state.
Recall that there is a cost to reuse failure. Therefore, it is imperative that the asset review
process is set up to favor quality over quantity. There are no awards for having a
Repository with a high number of assets. Favoring quantity over quality will lead to more
instances of reuse failure.
The review process can play an important role in the overall governance of the software
organization. Ensure that you have the appropriate participants from management,
technical, and legal groups involved in the approval process.
Asset type specification
To create the asset type specification:
A category schema must have only one focus to classify the asset. Do not use the same
category schema to define different or complex classifications.
Chapter 8. Configure your Asset Repository
211
The asset type specification plays an important role in helping Asset Consumers discover
assets. So when creating this specification, do so from the perspective of Asset
Consumers and other stakeholders.
Do not confuse categories and asset types. Both are used for describing the asset, and
both are used for searching and discovery. But the asset type has a stronger affinity with
describing the set of artifacts that must exist in the asset and also with the kinds of
relationships that the asset must have with other assets. An asset has one type, whereas
it can have many classifications, which enhance the description of the asset.
There is a balancing act that needs to be performed when defining the necessary asset
types. An asset must contain a number of artifacts that are necessary to make the asset
meaningful. However, you must include only the artifacts that are meaningful to the asset.
If you include too many artifacts, the asset type definition is diluted and becomes
meaningless.
Define attributes for important information needed to describe the asset or for additional
information needed to generate metrics and reports on the Repository contents. For
example, if you want to measure the return on investment from reusing a specific type of
asset, define an attribute called “Time saved” to represent the time saved by users when
reusing the asset and make this attribute mandatory.
Create a policy document describing the rules by which the assets must comply as they
are created. Table 8-2 provides a sample of this type of a document.
Table 8-2 Sample asset rules and policies
Asset type rules
Version
1.0
Description
Asset type must describe the kinds of users
who will use the assets and at what point in
the development process the assets will be
used.
An asset type specification must be created
and approved by the Asset Governance
Board. This is to minimize redundant or
similar asset types in the Repository.
Asset rules
Target audience
Architects and Administrators
Version
2.0
Description
All assets must include support contact
information.
All asset names must abide by the
naming conventions described here:
– No asset names can use
abbreviations.
– Asset names can use industry
acronyms.
– All words in asset names start with a
capital letter.
Target audience
212
Strategic Reuse with Asset-Based Development
Practitioners (analysts, architects, and so
forth) who submit assets.
Artifact rules
Relationship type
rules
Asset classification
rules
Version
1.0
Description
An artifact name can be the same as the file
name.
Target audience
Practitioners (analysts, architects, and so
forth) who submit assets.
Version
1.0
Description
Relationship types must be approved with
the Asset Governance Board before they
are used.
Target audience
Architects and Administrators
Version
2.0
Description
All assets must be classified with the
enterprise business domain schema and
the technology schema.
Custom tags need to abide by the
naming conventions here:
– No tags can start with a number.
– Tags with multiple words must be
concatenated with an underscore “_”.
Classification
schema rules
Target audience
Practitioners (analysts, architects, and so
forth) who submit and use assets.
Version
1.0
Description
Classification schemas must be
approved by the Asset Governance
Board. The schema must be reviewed
and compared with other schemas for
redundancy.
The classification schema must have a
name that follows the same naming
convention as for asset types.
The classification schema must have a
description that identifies the target
users and audience for the schema.
Target audience
Architects and Administrators
General
In general:
Define naming conventions and policies to give coherent and standard names to the
configuration that you create.
Create a community in the Repository called “Repository Configuration” to store the
assets describing the policies and decisions you have followed for your configuration
(create a specific Dev Time Policy asset type to store these information assets). The
Administrator must have a single picture or a spreadsheet of the asset types, their
Chapter 8. Configure your Asset Repository
213
definitions, and their structure along with the artifact definitions in order to reduce
confusion and provide the consistent use of terms.
When users come to the Repository they often do not understand many things about the
Repository (information metamodel, communities, access control, asset versioning policy,
and so forth). So, you must create a Repository Configuration Overview document and
distribute it to the Rational Asset Manager users.
Integrate the Repository with the LDAP registry for your organization to manage users and
groups. Doing so, you will avoid a great deal of administration overhead.
8.2 Repository configuration for ZYX Electronics
This section describes the Rational Asset Manager configuration that ZYX Electronics
decided to create based on the best practices detailed earlier in this chapter. The ZYX
Electronics Reuse Assessment and the ZYX Electronics Reuse Strategy documents were
additional sources of input into this configuration.
Because we will refer to a number of roles and individuals from ZYX Electronics, it is
worthwhile to take a moment to refamiliarize yourself with the IT team, as depicted in
Figure 8-11.
Figure 8-11 Organization chart for the IT organization
214
Strategic Reuse with Asset-Based Development
Also, as discussed in the ZYX Electronics Reuse Strategy document, a new Reuse Team has
been created within the organization, as depicted in Figure 8-12. The Reuse Team will work
with Duncan Munchkin and the team as they work through the pilot phases of the Reuse
Adoption project.
Figure 8-12 Reuse Team within the larger IT organization
Important: The Reuse Team will report into the Enterprise Architect, because ZYX
Electronics is using Rational Asset Manager as the Repository to manage the details and
artifacts associated with the overall enterprise architecture. The Enterprise Architecture
represents a key set of assets, which ZYX Electronics needs the entire organization to
follow and leverage. Therefore, this will be a key aspect of the Rational Asset Manager and
Reuse program adoption.
ZYX Electronics’ management team decided that Duncan Munchkin, the Development
Manager for the Credit Application, is the best candidate to lead this project due to his great
experience and knowledge of software reuse. In addition, as part of his team’s effort in the
Reuse Pilot, they will define the initial Repository configuration and be the first to work with
the Repository. Therefore, they will produce, consume, and manage the first set of assets to
be loaded into ZYX Electronics’ Rational Asset Manager Repository.
Using this initial configuration, the objective is to have an environment ready to start using
Rational Asset Manager at ZYX Electronics to validate the defined process and the tool
implementation.
This initial configuration will not be the final one. It will be reviewed and updated later based
on user feedback, collected metrics, and reports generated. In Part 3, “Service Assets in an
SOA” on page 333 of this book, you will see how this initial configuration can be expanded to
manage service assets to help ZYX Electronics to transition to a service-oriented architecture
(SOA) and in Part 4, “Patterns” on page 455 to manage pattern assets.
Chapter 8. Configure your Asset Repository
215
ZYX Electronics had recently created a methodology team to establish a software
development approach using the Rational Unified Process (RUP). They wanted to define
their own software development process based on the standard “RUP for Large Projects”
configuration, using the Rational Method Composer tool to simplify the predefined process
and to adapt it to ZYX Electronics’ needs. The Asset-Based Development plug-ins are
leveraged, and content added into the ZYX process will be sourced from these plug-ins.
Based on the early work of the methodology team, ZYX Electronics was familiar with RUP
terminology, and they had already defined roles similar to the ones described in RUP for the
various software development disciplines. Their software development projects follow an
iterative approach, and the phases correspond to RUP disciplines. The artifacts that they
consume and produce during the software life cycle are also in-line with the artifacts defined
in RUP (although they wanted to generate only a small set of the artifacts described in the
“RUP for Large Projects” process configuration).
Tip: Although largely outside the scope of this book, more information about customizing
RUP for an organization is provided in Appendix B, “Integrating Asset-Based Development
into a process” on page 713. It is important to remember that RUP is not a “one size fits all”
solution. It is a resource to leverage and guide you as your organization develops its
process. As you build your own process, you will determine which deliverables are
important to your organization and which deliverables offer less value.
To define the optimal configuration for the Repository, Duncan Munchkin, the ZYX
Electronics Development Manager, decided to organize several meetings with key people
(analysts, developers, and project managers) involved in development to have their feedback
and to define an initial Repository configuration that meets their needs. He also invited
Victoria Prezzio, the VP of Development, to these meetings to be sure that the approach they
were following was in-line with the objectives that the ZYX Electronics executives want to
achieve with this pilot project.
Deon Adminio, the Developer Tools Administrator, was also invited to participate in these
meetings. He had already attended Rational Asset Manager training, so during the first
meeting, he presented and delivered a demonstration to the other participants to show the
major features and to explain the major concepts of Rational Asset Manager.
Because ZYX Electronics was going to use RUP for their software development projects, they
decided to use its terminology to define the first Rational Asset Manager Repository
configuration. The following sections describe in detail the criteria that they agreed to use to
define their Repository structure and how they implemented this configuration using Rational
Asset Manager.
Based on his early exposure and experience with Asset Manager, Deon will be involved in the
reuse pilot. However, a key element to his role is to ensure that there is a skill transfer
occurring to Tim Spectacle from the Reuse Team. Therefore, Deon was designated the
Rational Asset Manager Repository Administrator in charge of installing, configuring, and
administering Rational Asset Manager.
In order to summarize the agreements from the meetings, Duncan created a document
describing the structure for their Rational Asset Manager Repository called ZYX Electronics
Usage Model.
The following sections assume that Rational Asset Manager was already installed and that
the main administration configuration tasks had been completed. For example, the
connection with the LDAP registry to manage users and user groups in ZYX Electronics had
already been established. For more information about how to install and configure Rational
216
Strategic Reuse with Asset-Based Development
Asset Manager, see Appendix A, “Rational Asset Manager: Installation and administration” on
page 637.
8.2.1 Creating communities and Community Administrators
Because users were going to be organized by RUP disciplines, ZYX Electronics decided to
take the approach of defining one community per RUP discipline. This approach minimized
the administrative overhead to define and configure permissions and review processes
(communities were oriented to group assets used by users with common interests and
purposes). They also adopted the best practice described in the previous chapter to define a
special community called Repository Configuration to store assets that describe the policies
and decisions made by ZYX Electronics to configure the Rational Asset Manager Repository.
ZYX Electronics defined the following communities to be created in Rational Asset Manager:
Business Modeling
Requirements
Analysis Design
Implementation
Test
Deployment
Project Management
Environment
As per the best practices covered earlier, ZYX Electronics also created a community for
managing the assets related to the configuration of the Repository. So one additional
community was created, which was called Repository Configuration.
To facilitate administration, Deon Adminio, the Rational Asset Manager Repository
Administrator for ZYX Electronics, wanted to assign Administrators to each community.
Because this was a pilot project, and not many people were involved, he decided to assign
Duncan Munchkin (the Development Manager) as the Administrator for all of the communities
instead of having to define different Administrators for each community.
To create communities and to assign Duncan as the Community Administrator, Deon used
the Rational Asset Manager Web interface, which contains all administrative capabilities.
Deon performed the following steps as depicted by Figure 8-13 on page 218 for each
community that he needed to create:
1. Click the Administration tab.
2. Click New Community.
3. Specify the following information in the New Community window:
– Name: name to identify the community, for example, Analysis Design.
– Description: brief description of the community
– Type the name of the specific user who will be assigned as the Community
Administrator and click Search.
– Select the check boxes next to the users who will be added as Community
Administrators.
– Click OK.
Chapter 8. Configure your Asset Repository
217
Figure 8-13 Create a new community
8.2.2 Creating asset types, category schemas, relationship types, and
attributes
Because ZYX Electronics’ software development projects created several of the RUP
artifacts, ZYX decided to define an asset type for each set of artifacts that were related in
RUP. They did not create an asset type for each RUP artifact, because this means you must
have many asset types without real value to the user. For example, they created an asset
type called “Software Design” that contains at least the UML analysis and design models and
any additional documentation needed to understand these models, instead of defining a
different asset type for each file type generated.
During the meetings to define the initial Repository configuration, ZYX Electronics also
described the constraints they wanted to associate to each asset type (categories, asset
relationships, attributes, and which artifacts to include).
Table 8-3 on page 219 describes the asset types and associated restrictions that ZYX
Electronics agreed to configure in the Rational Asset Manager Repository (this was a
simplified configuration model used for the pilot project and all asset types might not be
represented).
218
Strategic Reuse with Asset-Based Development
Table 8-3 Asset types and restrictions associated to each asset type
Asset type
Artifact constraints
Category constraints
Relationship
constraints
Attribute
constraints
Business
Process
Requirement
Include at least
one .doc file to
represent the
requirements
document
Optionally, include
one .emx file to
represent the use
case model
Architecture
Include at least one
.doc file
Include at least one
relationship of type
“architecture for” with
the “Requirement”
asset type
Software
Design
Include at least one
.emx file to represent
the UML file
Include at least one
relationship of type
“design for” with the
asset type
“Architecture”
Database
Design
Include at least one
.ldm file to represent
the data model
(developed with
Rational Data
Architect)
Include at least one
relationship of type
“database design for”
with the asset type
“Software Design”
Database Type:
SQL Server®
DB2
Oracle®
DB Schema
Name
Microsoft Access
SQL Anywhere
Chapter 8. Configure your Asset Repository
219
Asset type
Artifact constraints
Category constraints
Component
Include at least
one BIN label
artifact
Technology
software:
Include at least
one SourceCode
label artifact
–
–
–
–
Relationship
constraints
J2EE
Cobol
C++
Others
Technology
hardware:
–
–
–
–
–
Windows
Linux®
UNIX
z/OS
Others
Development
Type:
– Internal
development
– External
development
Framework
Include at least one
.doc file to know how
to use the framework
Framework type:
– Open source
– Commercial UI
components
– SQL scripts
– Batch scripts
Technology
hardware:
– Windows
– Linux
– z/OS
Test
Optionally include
one .ini file to specify
the connection to
ClearQuest
TestManager
Include at least
one relationship of
type “tests for” with
the “Component”
asset type
Include at least
one relationship of
type “tests for” with
the “Requirement”
asset type
220
Strategic Reuse with Asset-Based Development
Attribute
constraints
Asset type
Artifact constraints
User Support
Material
Include at least
one .doc file to
contain the user
manual
Category constraints
Relationship
constraints
Attribute
constraints
Optionally include
one .emx file to
define the
Deployment
model
Project
Management
Information
Process
URL link to
Rational
Portfolio
Manager
Include at least one
.doc file to explain the
process artifacts
Methodology
used
Asset Governance
Artifact type:
Dev Time
Policy (asset
describing the
policies and
decisions for
the ZYX
Electronics
configuration)
Asset type
specification
Workflow
specification
Asset versioning
policy
Category schema
Repository
configuration
overview
Community map
Presentation
Include at least one
.ppt document
To facilitate searches and navigation through the Repository, ZYX also defined additional
categories and attributes that were associated to all asset types, as Table 8-4 on page 222
and Table 8-5 on page 222 describe.
Chapter 8. Configure your Asset Repository
221
Table 8-4 Categories common to all asset types
Category
Values
Business Domain
Business Administration
Business Planning
Business Unit Tracking
Staff Appraisals
Account Administration
Product Administration
Purchasing
Branch/Store Operations
New Business Development
Sector Planning
Sector Management
Product Management
Product Directory
Marketing Campaigns
Relationship Management
Account Planning
Relationship Management
Credit Assessment
Credit Administration
Servicing and Sales
Sales Planning
Sales Management
Sales
Customer Service
Collections
Product Fulfillment
Fulfillment Planning
Fulfillment Monitoring
Product Fulfillment
Document Management
Financial Control and Accounting
Portfolio Planning
Compliance
Reconciliation
Customer Accounts
General Ledger
Geographic Area
North America
South America
Europe
APAC
Rational Unified Process Phases
Inception
Elaboration
Construction
Transition
Table 8-5 Attributes common to all asset types
Attribute
Project name
In advance of creating and configuring these asset types and their restrictions, the Repository
Administrator had to create the categories, asset relationship types, and attributes.
222
Strategic Reuse with Asset-Based Development
Create categories
To create a new category schema that represents the Database Type that is referenced by
the Database Design asset type, Deon performed the following steps:
1. Go to the Administration tab.
2. Select Category Schemas from the Repository Administration sidebar as Figure 8-14
shows and click New Category Schema.
Figure 8-14 Create a new category schema
3. Define the new category by entering a category Name and Description. Use Add Field to
create additional “root nodes” as necessary.
4. To begin creating the Category tree, click Add Field to add the root of the category tree.
Note that the Add Field link creates new root nodes of the Category Schema. Use Insert
Child to create leaf nodes.
5. Enter the Name and Description of the category node.
Note: When you select “Children are exclusive”, it means that an asset can be categorized
using only one of the subcategories. Each choice in the list of subcategories is mutually
exclusive; therefore, the user can only assign one value from the list to the asset.
6. To add child categories, click Insert Child as many times as necessary to add the
necessary child categories to complete the category definition as shown in Figure 8-15 on
page 224 (add SQL Server, DB2, Oracle, MS Access, and SQL Anywhere values).
Chapter 8. Configure your Asset Repository
223
Figure 8-15 Create category hierarchy
7. Click OK to save the newly created category.
Repeat the same process to create the other categories in the Repository.
Create relationship types
Next, Deon moved on to create the necessary relationship types. The relationship type will
later be referenced as a restriction when specifying the asset type. For example, the
relationship type “Database design for” can be used to associate the Database Design asset
types with Software Design asset types. To create the relationship types, Deon followed
these steps:
1. Go to the Administration tab.
2. Select Relationship Types from the Repository Administration sidebar as Figure 8-16 on
page 225 shows and click New Relationship.
224
Strategic Reuse with Asset-Based Development
Figure 8-16 Create a new relationship type
3. As shown in Figure 8-17, in the New Relationship window, specify database design for
as the Relationship type. Then, specify database design as the value for Reversed
relationship.
Figure 8-17 Define relationship type and its reversed relationship
4. Click OK to save the new relationship.
He repeated the same process to create the other relationship types in the Repository.
Create attributes
Next, Deon moved on to create the necessary attributes. Attributes will be used at a later time
as a restriction in the asset type. For example, a new attribute called DB Schema Name can
be used to describe the type of database associated with an asset of type Database Design.
Chapter 8. Configure your Asset Repository
225
Deon followed these steps to create the attributes:
1. Go to the Administration tab.
2. As shown in Figure 8-18, select Asset attributes from the Repository Administration
sidebar and then click New Attribute.
Figure 8-18 Create a new asset attribute
3. In the New Attribute window, as shown in Figure 8-19, type the name and description for
the new attribute. To specify a default value to be assigned to the attribute, select the
check box Use preset values, type the value to be displayed, and click Add.
Figure 8-19 Create a new attribute dialog
4. Click OK to save the new attribute.
Deon repeated the same process for the other attributes that needed to be created in the
Repository.
226
Strategic Reuse with Asset-Based Development
Create asset types
After Deon created all of the categories, relationship types, and attributes, he proceeded to
create the ZYX Electronics’ asset types.
Deon performed the following steps to create the Database Design asset type:
1. Go to the Administration tab.
2. As shown in Figure 8-20, select Asset Types from the Repository Administration sidebar
and click New Asset Type.
Figure 8-20 Create a new asset type
3. Provide a name and description for the new Database Design asset type.
4. Define a new artifact constraint by clicking New Artifact Constraint. A new window will
appear as is shown in Figure 8-21. Select the number of artifacts that will be required, the
restriction type, and the type of the required asset. When finished with these selections,
click OK. For example, to create the restriction to check if the datamodel diagram created
with Rational DataArchitect is included, Deon created a restriction to verify that the asset
type has at least one datamodel diagram (one file with extension .ldm).
Figure 8-21 Add new artifact constraints to the asset type
Chapter 8. Configure your Asset Repository
227
5. Define the category constraints that will be shown to the user when creating a new
instance of this asset type. As Figure 8-22 shows, Deon selected just the general
categories (Business Domain and Geography) and the specific category for this type of
asset called Database Type.
Figure 8-22 Select categories to constraint to the asset type
6. Define a new asset constraint by clicking New Relationship Constraint. A new window
will appear as is shown in Figure 8-23. To define the constraint to have a relationship with
the Software Design asset type, Deon selected the number of relationships that will be
required (1), chose the asset type to relate with (Software Design), selected the type of
relationship already defined in the Repository (Database Design for), and then clicked
OK.
Figure 8-23 Add new relationship constraints to the asset type
7. Define the attribute constraints that will be shown to the user when creating a new asset of
this type. Figure 8-24 shows Deon was able to select with a check box the attributes that
were already defined in the Repository to use to add additional information to the
Database Design asset type. To make the attribute mandatory when the asset is
submitted, Deon checked the Required check box for the DB Schema Name attribute.
Figure 8-24 Add attribute constraints to the asset type
8. Click OK to save the new asset type created.
Deon repeated these same steps to create the other asset types.
8.2.3 Managing users and assigning roles in communities
Because ZYX Electronics was going to use several of the standard RUP roles and the ZYX
Electronics Systems Administrator had already configured the connection with the LDAP
registry, the permissions configuration task was quite easy. He used the default roles defined
228
Strategic Reuse with Asset-Based Development
by Rational Asset Manager when a new community is created so for each community he just
had to assign the role’s permissions to the LDAP user groups according to the permissions
agreed upon in Table 8-6.
Important: Roles not listed in the table have Asset Consumer permissions in all
communities.
Table 8-6 ZYX Electronics roles permissions
Community
User groups
Role permission
Business Modeling
Business Analyst
Asset Producer
Project Manager
Asset Reviewer
System Analyst
Asset Producer
Project Manager
Asset Reviewer
System Analyst,
Architect, and
Database Architect (but only
with permissions to produce
“database design” asset types)
Asset Producer
System Analyst
Asset Reviewer
Developer,
Integration Developer, and
Architect
Asset Producer
Project Manager
Asset Reviewer
Test Architect/Manager
Asset Producer
Project Manager
Asset Reviewer
Release/Build Engineer and
Technical Writer
Asset Producer
Project Manager and
Test Architect/Manager
Asset Reviewer
Project Manager and
Development Manager
Asset Producer
Executives and Development
Manager
Asset Reviewer
Development Tools
Administrator
Asset Producer
Development Manager
Asset Reviewer
Development Tools
Administrator and
Development Manager
Asset Producer
Requirements
Analysis_Design
Implementation
Test
Deployment
Project Management
Environment
Repository Configuration
Community
As stated before, Duncan Munchkin (Development Manager) was designated the
Administrator for all of the communities that were created.
These are the steps that Deon followed to associate the Role’s permissions with the User
Groups for the Analysis_Design community. Note, because Duncan Munchkin had been
Chapter 8. Configure your Asset Repository
229
designated as a Community Administrator, this task might also have been performed by
Duncan as well:
1. Open the Administrator tab.
2. Click the community name Analysis_Design to modify the user groups and their
permissions that are associated with the community.
3. Open the User Groups tab.
4. To add a new user group to the community, click New User Group.
5. Type a name and a description for the new user group that is going to be created (System
Analyst, Architect, and Database Architect).
6. Because authentication was configured to use an LDAP directory, he clicked Bind to
select the LDAP group that he wanted to bind to Rational Asset Manager.
Note: A scheduled job will pick up any user information modifications for the group listed
on the LDAP server. After you bind the LDAP group to this user group, you can no longer
modify any of the user’s information about the Rational Asset Manager server (for
example, a user’s name or telephone number). This information must be modified on the
LDAP server.
7. To add new users to the user group, Deon clicked Add User in the Group Members
section. Then, he typed a search string and clicked Search to retrieve a list of user
names. Note that this search might return multiple user names.
8. Select the check box next to each user’s name to add them to the user group as shown in
Figure 8-25.
Figure 8-25 Select users to add to the user group
9. Select the roles to assign to the user group as shown in Figure 8-26 on page 231 and click
OK.
230
Strategic Reuse with Asset-Based Development
Figure 8-26 Select roles to assign to the user group
Tip: If the roles that are listed do not satisfy the needs of the user groups that you are
adding, add the user group and then go to the Role tab to create the new role. Later, you
can edit a user group and modify its roles.
Asset Owner, Asset Reviewer, Asset Review Board, and Administrator roles are created
automatically by Rational Asset Manager. These roles cannot be assigned to users or user
groups. There will be specific menus to assign these roles to users:
Administrator: This role will be assigned by the Repository Administrator to users when
creating a new community.
Asset Reviewer and Asset Review Board: This role will be assigned by the Community
Administrator when creating and configuring the review process for an asset type
(Review Process tab).
Asset Owner: This role is the original creator of the asset version.
To implement a restriction for the Database Architect role in the Analysis_Design community
so that it only has permissions to produce Database Design asset types, Deon had to create
a new role called Database Asset Producer and restrict the scope to only “database design”
asset types. To modify default roles permissions to constrain “database design” asset types,
Deon followed these steps:
1. Open the Administrator tab.
2. Click the community name Analysis_Design to modify the roles and permissions that are
associated with the roles in the community.
3. Open the Roles tab.
4. Because Deon needed to create a new role for the community, Deon clicked New Role to
add a new role definition to the community.
Chapter 8. Configure your Asset Repository
231
5. As shown in Figure 8-27:
– On the Community Role page, Deon provided a name (Database Asset Producer) and
description for the role.
– In the Role Permissions section, he selected the permissions that this role will have in
the community (he selected all, except the permission to “Delete assets”).
– In the Roles Scopes section, Deon selected the restriction that the role must only have
permissions for the Database Design asset type.
– He clicked Add Constraint to create the restriction.
Figure 8-27 Select permissions for the role
6. Click OK to save the changes.
8.2.4 Defining default review processes in communities
For this first phase of the pilot project, Duncan Munchkin and Deon Adminio decided to use
the default review process that comes with Rational Asset Manager. This default review
process allows the team to get familiar with a review process and later provide an educated
opinion when evaluating the need to move to a custom review process.
To implement this default review process in Rational Asset Manager according to what was
agreed to in Table 8-6 on page 229, Duncan and Deon defined review processes at the
community level and assigned as reviewers the user groups defined in the table.
These are the steps that Duncan and Deon followed to create a default review process in the
Analysis_Design community for the System Analyst user group:
1. Log in to Rational Asset Manager Web client with the Community Administrator’s
permissions.
232
Strategic Reuse with Asset-Based Development
2. Open the Administration tab.
3. Click the community name Analysis_Design to create a review process in that
community.
4. Open the Review Process tab and click New Review Process.
5. As shown in Figure 8-28, select Default review process from the list and then click OK.
Tip: If you want to know how to customize and use a Rational ClearQuest review process,
go to A.2.2, “Installing Rational Asset Manager Server” on page 648.
Figure 8-28 Select default review process
6. Describe the new review process:
a. Type a name for the review process: Analysis_Design review process.
b. Type a description for the review process. Descriptions can include spaces and special
characters.
7. Define the conditions for the review process:
If no conditions are selected, this review process will apply to all assets in the community.
So, ZYX Electronics did not add any condition as shown in Figure 8-29.
Figure 8-29 No special conditions were selected for the review process
8. Deon did not select “Add review board members” to this review process.
9. Rather than select individual reviews, Deon wanted to assign the responsibility for reviews
to a user group. So, to add the System Analysts user group to this review process as a
Reviewer, Deon followed these steps:
a. Click Add User Group and select System Analyst group from the list as shown in
Figure 8-30 on page 234.
Chapter 8. Configure your Asset Repository
233
Figure 8-30 Add user group-based reviewers
10.Specify 1 as the number of Required Reviews.
11.Optionally, select the Make reviews private check box so that reviewer names are not
visible to other users.
12.Optionally, set reminders to send an e-mail notification on the schedule that you choose in
the lists. Deon specified 3 Days, so Rational Asset Manager will send an e-mail reminder
every three days to the reviewers that Deon specified.
13.Click OK.
Tip: An asset can have more than one review process assigned to it, but Community
Administrators can assign priority to them, so the users can view the review processes in
the order of the lowest priority to the highest priority.
Because ZYX Electronics wanted to force assets to follow a review process, Deon configured
that the assets submitted “as is” (see Figure 8-6 on page 204) must have administration
approval as shown in Figure 8-31 on page 235.
234
Strategic Reuse with Asset-Based Development
Figure 8-31 Administrator approval for assets submitted “as is”
To create the other review processes of Table 8-6 on page 229, Duncan and Deon just
followed the same process that we just described for the rest of communities.
8.3 What comes next
Following the criteria and steps just detailed, ZYX Electronics’ Repository and Community
Administrators (Deon Adminio and Duncan Munchkin) defined and implemented an initial
configuration for the Rational Asset Manager Repository. They have created the initial
environment needed to start to implement and use an Asset-Based Development approach.
As discussed previously, this was just an initial configuration that will be updated to be able to
manage new asset types as services and patterns.
We have not covered how ZYX Electronics’ Community Administrators defined Rational
Asset Manager connections with external tools, such as WebSphere Service Registry and
Repository and Rational ClearQuest. This information will be covered in other chapters of the
book:
The connection between Rational Asset Manager and WebSphere Service Registry and
Repository allows users to publish service assets to the WebSphere tool directly from the
Rational Asset Manager Web interface and to search for services that were already
published to WebSphere Service Registry and Repository. For detailed information about
how to create and configure the connection between both tools, go to A.3.1, “Integrating
Rational Asset Manager with WSRR” on page 661.
The connection between Rational Asset Manager and Rational ClearQuest allows users
to replicate forum discussion topics to Rational ClearQuest and to customize the asset
review process to adapt it to specific organizational needs. For detailed information about
how to install and configure the connection between both tools, go to A.3.2, “Integrating
Rational Asset Manager with Rational ClearQuest” on page 665.
Chapter 8. Configure your Asset Repository
235
The remaining chapters of Part 2 will detail the asset management life cycle tasks and roles
that are needed to produce, consume, and manage assets using the Rational Asset Manager
configuration that we have just created and defined for ZYX Electronics.
Part 3, “Service Assets in an SOA” on page 333 of the book will extend the configuration
defined in this chapter to include new metadata that is needed to manage services following
an SOA approach.
Part 4, “Patterns” on page 455 of the book will extend the configuration defined in this chapter
to include new metadata needed to manage patterns that are developed using Rational
Software Architect.
236
Strategic Reuse with Asset-Based Development
9
Chapter 9.
Produce reusable assets
In this chapter, we look at how we must go about producing reusable assets. We include a
further discussion of best practices in producing reusable assets and how ZYX Electronics
produced reusable assets and leveraged Rational Asset Manager in order to produce
reusable assets.
9.1 Introduction
In this chapter, we look at the asset manufacturing life cycle, that is, the production of assets.
As shown in Figure 9-1, it is important to remember that this is a cycle. We are not looking at
a large waterfall type process with long lags between deliverables and infrequent
opportunities to adjust course.
Figure 9-1 Manufacturing cycle
© Copyright IBM Corp. 2008. All rights reserved.
237
Also, we need to remember that there is a connection between the manufacturing cycle and
the usage cycle. This interaction is a key aspect of the success of any asset reuse program.
The assets that are produced must find an audience, be usable by that audience, and
address issues that are important to that audience. The Asset Producers need to
communicate with the consumers listening to the needs of this community, as well as accept
the feedback that is provided on assets that have already been built as shown in Figure 9-2.
Figure 9-2 Integration between usage and manufacturing cycles
The remaining portion of this chapter is comprised of two major sections:
A detailed discussion of the process to produce assets
Coverage of how ZYX Electronics was able to leverage this guidance in producing their
assets
9.2 Asset manufacturing
As described in Chapter 5, “Asset-Based Development and Asset Governance Rational
Method Composer plug-ins” on page 61, the Asset-Based Development plug-in provides the
asset manufacturing process as a capability pattern.
Tip: You might encounter this capability pattern referred to as either Producing Reusable
Assets or Asset Manufacturing. The terms are meant to be interchangeable; and therefore,
you will see references to both terms in this book.
Figure 9-3 on page 239 shows the workflow and tasks that compose this capability pattern.
238
Strategic Reuse with Asset-Based Development
Figure 9-3 Workflow of manufacturing process
9.2.1 Asset manufacturing roles
This chapter describes the tasks involved in asset manufacturing mainly from the views of the
following three roles:
Asset Owner: The Asset Owner role is a person or an organization that defines and
submits the asset version, as well as updates or removes the asset version. The Asset
Owner is the original creator of the asset version.
This role mainly performs the Create Asset task.
Asset Producer: The Asset Producer updates an asset version by developing artifacts and
harvesting artifacts, as well as making changes to the metadata. If the updates require the
creation of a new asset version, the Asset Producer becomes the Asset Owner in the
Repository.
This role mainly performs the following tasks:
–
–
–
–
Conduct Recurring Problem Analysis
Develop Asset Specification
Create Asset
Update Asset
Asset Manufacturing Team: This team creates and uses Asset Specifications to create
and maintain assets. The intended scope of the team must be defined. Will the team be
responsible for creating assets for the declared reuse scope at the enterprise level or the
divisional level? Will the team create the assets, or is the purpose of the team to clean up
assets and prepare them for reuse?
Directly associated with the scope of the Asset Manufacturing Team is the manufacturing
process. There are several models to consider. These models use the basic producer and
Chapter 9. Produce reusable assets
239
consumer model for assets. The premise is that an organization is focused on the creation
of assets and another organization is focused on the usage of assets.
In more mature organizations, the assets having a wider scope and impact are developed
by special teams as part of an Asset Manufacturing Center or Excellence Center. This role
captures the responsibilities and the tasks performed by these development groups with
regard to the asset production.
This role mainly performs the following tasks:
– Create Asset
– Update Asset
9.2.2 Conduct recurring problem analysis
Figure 9-4 shows the position of this task in the workflow of the Asset-Based Development
plug-in. The purpose and expected inputs and outputs defined for this task are:
Purpose: To protect the organization’s investments in Reusable Assets and to ensure
that the proper assets are developed.
Inputs: None.
Outputs: Asset Specification.
Figure 9-4 Conduct recurring problem analysis
In this task, the Asset Producer analyzes recurring problems, or problems that are expected
to be recurring, and evaluates whether it makes sense to build a reusable asset to address
the problem.
As part of the analysis, the Asset Producer needs to determine the cost to build the asset, as
well as the benefits derived from using the asset. We encourage you to leverage the material
from Chapter 6, “Value, impact, and return on investment” on page 103 to help you to perform
these calculations. A good starting point is to leverage the relative cost factors proposed by
240
Strategic Reuse with Asset-Based Development
Jeffrey Poulin, in Measuring Software Reuse. He proposes that the Relative Cost of Writing
for Reuse is 1.5, which means that there is an additional 50% cost when building reusable
software. He also proposes that the Relative Cost of Reuse is 0.2, which means that the
relative cost to use the asset is 20% of the cost to rebuild the solution1.
Recommendations:
Leverage the tooling and automation that support reuse. As discussed in “Value, impact,
and return on investment” on page 103, place value on those tools that help you to build
and consume assets. Consumability is a key aspect of reuse; the harder it is to build and
use an asset, the more likely it is that your reuse program will fail.
Pragmatism is a valuable trait. Take a common sense approach, ask many questions, and
avoid over-engineering. For example, ask these questions:
– Why are we building this asset?
– What is the value of building the asset?
– What is the cost of not building the asset?
– Does this solution really represent a best practice?
– Is there an incremental approach to building the asset, where we can achieve results
more quickly?
Unfortunately, it is not unusual to come across situations where the time pressure for a
project leads the team to decide that reuse introduces risk into a project. From the outside,
this looks to be a strange decision, because reuse and assets are meant to address
time-to-market issues and reduce project risk. However, human nature is often at odds with
accepting change and views change as introducing risk. We have actually come across a
number of projects where this decision has been made, and it is only later in the project’s time
line, when it is clear that deadlines will not be met that reuse is reconsidered and then
adopted. Tips to consider if you find yourself in this type of situation:
A strategic reuse program adopted throughout the organization leads to a culture that
views reuse as “the way that we do business” and looks to leverage reuse as a risk and
time line reducer.
Again, tooling and automation need to be in place for building the assets.
Iterative and incremental asset delivery need to be considered. The quicker that you can
show that there is a payoff for the reuse investment, the better. Assets that take a team
three years to build before allowing for reuse are not likely to help the situation.
This task includes the following three steps:
1. Identify recurring problem: To understand the problem, the Asset Producer needs to
understand the impact of the problem on the users. When defining the problem, define the
context within which the problem exists. Explain the context in business terms and in
technical terms. Also, verify that the problem and its context exist in multiple places and
determine if this is an issue that occurs in other teams, projects, or organizations. When
the scope of the issue has been determined, ensure that communication occurs with those
individuals within the scope.
2. Identify common solution to recurring problem: The temptation is to focus on
describing the solution before having a solid definition of the problem. Fight this tendency
and do not spend significant time on this step until step 1 is completed. The proposed
solution must be relevant to the problem’s context and assumptions.
3. Verify the existence of the problem: A general rule from the patterns community is that
the problem and solution combination must be verifiable in three places in order for it to be
1
Measuring Software Reuse. Jeffrey Poulin, pages 25-29.
Chapter 9. Produce reusable assets
241
a candidate for a pattern. While this rule is not strictly prescribed here, it is a reasonable
guideline to follow.
It is critical to evaluate the combination of the problem and the solution. In certain
contexts, the solution to the same problem can vary slightly. It is possible to have multiple
implementations, or solutions, to the same problem. The variance is caused by changing
contexts, target Asset Consumers, and delivery channels for the assets. Also, ensure that
over-engineering does not occur. We need to be aware of variations of the problem, but it
is likely that if we address several of the variants initially and prove the asset and results,
we can return to the asset later and generalize it further.
9.2.3 Develop asset specification
Figure 9-5 shows the position of this task in the workflow of the Asset-Based Development
plug-in. The purpose and expected inputs and outputs defined for this task are:
Purpose: Provide clarity and design for a proposed asset.
Inputs: (Optional) Asset Specification.
Outputs: Asset Specification.
Figure 9-5 Develop asset specification
A major goal of this task is to properly describe the problems, their context, and the solution.
This task can be described as “asset proposal and adoption”, because specification can be
used as a key input into the decision regarding whether to build the asset.
After an asset is published, it is natural that the asset can be used by the people who do not
know its background or context. That is, the problem, their context, and the solution of the
asset must be specified precisely enough for the consumer to evaluate the fit of the asset for
their problem.
242
Strategic Reuse with Asset-Based Development
Ideally, the asset will be able to be used in slightly different contexts from the original source
of the asset. The asset will need to provide future Asset Consumers with ways to adjust the
asset to meet the needs of their situations. Therefore, a key aspect of the specification is that
it accurately captures the points of variability that will be provided by the asset.
To reduce reuse failure costs, the specification must provide the information needed by Asset
Consumers as they determine whether to use the asset in their project.
This task includes the following steps:
1. Analyze asset requirements: Understand the problem that you want to solve, its scope,
and specific context. In cases where an asset is created for unspecified consumers, the
requirement of the asset tends to be based on the experience and decisions of the Asset
Producer. Define asset requirements while considering these points:
– Conducting recurring problem analysis in advance helps to find the true requirements.
– Collect requirements from many candidate consumers, if possible, to raise the
precision of the requirements.
– It is often a good idea to build an architectural prototype or an archetype of the asset,
as a means of mitigating risks and getting early feedback, even when the asset is not
executable software.
2. Describe the asset: Leverage the Five “Ws” and One “H” (Who, What, Why, Where,
When, and How) to help write the specification in a manner that will answer Asset
Consumers’ questions. For example:
– “Who do I ask for help?”
– “What points of variability are available for this asset?”
– “Why must I use this asset?”
– “Where must this asset be used?”
– “When must this asset be used?”
– “How can I use this asset?”
The asset’s specification must include the following information:
– Asset name and version
– The problem that the asset is expected to solve
– Description of the solution
– Expected contexts:
•
Development context
•
Testing context
•
Runtime context
•
Business domain context
– Expected artifacts in the asset
– Asset relationships and dependencies
– Possible categorization and classification:
•
Business
•
Technical
•
Organizational
– Expected Asset Consumer skills
Chapter 9. Produce reusable assets
243
– How the expected Asset Consumer will use the asset
– Asset Owner and maintainer
– Sponsor and funding
– Estimated asset development effort
– Estimated Asset Consumer benefits
Reusable Asset Specification (RAS)
Reusable Asset Specification (RAS) is an Object Management Group (OMG) standard that
was jointly produced by a number of member companies, including IBM. RAS describes the
structure of information about an asset and is generally captured in XML Metadata
Interchange (XMI)/Extensible Markup Language (XML).
There are many kinds of software development artifacts in many forms, and from many
authors with varying styles. This variety increases the costs of discovering, comprehending,
and reusing other authors’ artifacts. Providing consistent artifact organization, structure,
description, and packaging mitigates part of these costs through consistency and
predictability. RAS describes an extensible way to organize software artifacts into assets for
future reuse.
As described in Figure 9-6, having a standard mechanism for packaging and documenting an
asset makes it easier for an Asset Consumer to understand:
The solution represented by the asset
The requirements associated with the asset
How to consume the asset
(a) Without RAS
(b) With RAS
Requirement
Requirement
Solution
Produce
create
Solution
Consumer
Produce
create
consume
Consumer
Figure 9-6 Difference between without RAS and with RAS
RAS is generally realized in an .xml file and describes the specification of artifacts, such as
classification, solution, usage, and related assets. Also, it indicates the locations of its
artifacts in the solution section. All artifacts, including RAS, can be packaged as a single zip
file with the extension name, “ras”. In general, the structure of RAS is extremely simple;
however, a .ras file can become large and complicated. Regardless of the size and
complexity, using tools, such as RAM, shields us from having to know the structures and
specification in detail.
The important point is that RAS provides a standard for packaging assets so that they can be
supported in production, consumption, and management by a variety of tools.
244
Strategic Reuse with Asset-Based Development
9.2.4 Create asset
Figure 9-7 shows the position of this task in the workflow of the Asset-Based Development
plug-in. The purpose and expected inputs and outputs defined for this task are:
Purpose: Populate Repository with the right assets, providing solutions to problems in the
enterprise
Inputs: Asset Specification
Outputs: Asset Artifact and Reusable Asset
Figure 9-7 Create asset
In this task, the asset artifacts are created and harvested. The asset is created according to
the Asset Specification. Packaging the asset includes preparing documentation and
supporting material to provide easy comprehension of the asset. The asset’s metadata, such
as name, description, and anticipated context, is prepared. Finally, the asset is submitted to
the Repository.
In asset creation, variability analysis weighs more heavily than in comparison to building a
traditional software artifact. Rather than building a solution to be used in just a specific
instance, you look at how you can leverage the solution in multiple situations. Part of the
analysis looks at:
What must be common to the solution and asset across all uses of the asset?
What aspects of its use are unique to certain situations?
What assumptions can be made within the asset?
What information must be provided by the user of the asset? Is there a subset of this
information that can be calculated based on a combination of other values in the set of
assumptions?
Chapter 9. Produce reusable assets
245
Even in the case of an asset that is meant for reuse in a White box manner, it is worthwhile to
spend time thinking of how and where the asset can or must be adjustable. Preferably, we
want to limit the points of variability and provide the Asset Consumer with a manageable set
of points of variability. If we allow the set of points of variability to be unconstrained, we make
it much more difficult for the user of the asset to succeed.
Also, initial versions of the asset are unlikely to have a perfect set of points of variability
defined. In the first iteration or two, focus on building the asset and a best effort approach on
the points of variability. In later iterations, you can increase your focus in this area and
incorporate feedback from Asset Consumers as you harden the asset for wider reuse.
This task includes the following five steps:
1. Understand the considerations in creating assets: Several of the main considerations
are described in the description for this task that is provided earlier in this section.
Understanding the answers to these considerations is critical to building the proper asset.
Again, the goal is to not over-populate the Repository with assets just because we can.
The goal is to populate the Repository with the right set of assets that provide a solution to
a problem that the organization faces and that are easy for Asset Consumers to use.
Remember, reuse failure has a cost as well.
2. Create or harvest artifacts: An asset can have many artifacts. Certain artifacts are
created for the asset, whereas other artifacts can be harvested. In either case, the
artifacts must be prepared to the accepted level of context and dependencies.
In many cases, dependencies need to be removed or modified in the artifacts to meet the
expected context Asset Consumers will have. The artifacts are prepared in the Asset
Owner’s or Asset Producer’s workspace. The artifacts must be checked in to a software
configuration management system before associating the artifacts with the asset in the
Repository.
A project that produces a reusable asset needs to address many of the same concerns
addressed by Software Architecture, even for assets that are not executable software.
Therefore, architectural concerns for an asset can include:
– The logical structure of components that make up the asset and the relationships to
other assets (for software, this is covered by the Design Model)
– The physical files that make up the asset, and how will they be packaged (for software,
this is the Implementation Model). The nature of the target user experience, as well as
the target audience, might require that the asset is reorganized. This reorganization
can involve adjusting the way that the artifacts contained in the asset are organized or
can involve splitting the original asset into several assets.
– The major technical decisions driving development of this asset
At a high level, the architecture of a reusable asset must include a description of its parts
(the asset artifacts), how those parts fit together, and how those parts can be customized
or tailored to fit into a specific context. For the reusable asset as a whole, you must
describe:
– Within what environment or context you intend to apply the asset. This environment
includes the development context, deployment context, business domain context, and
so forth.
– How the Asset Consumer must use the asset or an initial usage model for the asset
(view this as the use case view of the asset)
– What asset artifacts make up the asset, what their inter-dependencies and the
relationships among these artifacts are, and what is the overall organization of these
artifacts (think of this as the logical view of the asset)
246
Strategic Reuse with Asset-Based Development
– How are the physical files that make up the asset organized (think of this as the
implementation view of the asset)
– Any mechanisms for customization of the asset (for example, variability points,
framework parameters, and so forth). What can be customized and what are the
guidelines for customizing?
– Any relationships to other reusable assets
– Any constraints or limitations
– The relative priority of the asset “use cases” (to assist in iteration planning)
– What, if any, standard representation format is being used to represent the asset
For each asset artifact, you must describe:
– The type of the artifact, for example, document, model, script, template, plan, and so
forth
– What part of the overall solution does the artifact provide
– What customization options must exist for the artifact (the initial definition of the
variability points of the asset)
– Whether the artifact already exists or if it needs to be developed
– What relationships and dependencies the artifact has with other artifacts
– What physical files contain the artifact
Tip: The degrees to which the Asset Consumer can access the artifacts of the asset can
also affect packaging. For example, a “White box” asset can require more packaging and
documentation than a “Black box” asset because of the increased visibility of the asset’s
internal information.
3. Package asset: Addressing documentation quality and ease of asset comprehension are
the purpose of the packaging assets. The extra investment for packaging assets is
justified if the effort in this area reduces the costs of reuse. The type of documentation that
is developed for an asset, and its level of detail, depends on the target audience and the
target user experience.
There are two categories of documentation when documenting an asset:
– External asset documentation: The documentation available to Asset Consumers
when browsing an asset Repository or catalog where the asset is published. This
documentation can be considered marketing material.
– Internal asset documentation: The documentation that an Asset Consumer uses to
install and use the asset. This documentation can be considered the asset’s user’s
guide.
The external documentation can be created by abstracting from the detailed internal asset
documentation. People might question the value in taking the time to develop distinct,
more abstract external documentation that is separate from the internal asset
documentation. However, providing a less detailed description of the asset allows Asset
Consumers to get a feel for the purpose and intent of the asset without having to wade
through all of the details.
4. Categorize asset: There are several terms describing this step, such as classifying the
asset or using taxonomies.
The goal here is to assign values to the asset metadata that benefit the discovery of the
asset. More formal structures, such as category schemas or taxonomies, are typically
used. However, other techniques, such as tagging assets with terms that are meaningful
Chapter 9. Produce reusable assets
247
to the Asset Consumer, are less structured techniques but are often more useful means of
searching and finding assets.
Assets must be categorized as they are created and submitted, but they certainly must be
permitted to be categorized at other points in the lifetime of the asset.
5. Submit asset: Submitting the asset to the Repository, the Asset Owner/Producer typically
fills in the asset metadata, associates the selected artifacts, and categorizes the asset
using category schemas and taxonomies in the Repository.
For certain repositories, the asset version is declared by the person submitting the asset.
When selecting the artifacts to be in the asset, typically the Asset Producer/Owner will
select the root directory where the artifacts live. Certain repositories will permit only one
root directory in the asset, other repositories can permit multiple root directories. When
selecting the artifacts for the asset, the Asset Owner/Producer will often need to identify a
label or other identifiable tag that is stored in the asset metadata and SCM to ensure the
proper retrieval of the asset artifacts for the Asset Consumer.
In a governed Repository, the asset must be submitted to review and approval processes.
Governing the asset submission, review, and approval processes adds to the quality and
usability of the assets in the Repository.
9.2.5 Review and test asset
Figure 9-8 on page 249 shows the position of this task in the workflow of the Asset-Based
Development plug-in. In this task, the Asset Reviewer reviews and tests the asset. The details
regarding this task are explained in 11.2.3, “Review and test asset” on page 307 as the
Administrator’s task.
From the Asset Owner perspective, the key thing to remember is that the asset has been:
1.
2.
3.
4.
248
Tested
Documented
Packaged
Submitted to the Repository
Strategic Reuse with Asset-Based Development
Figure 9-8 Review and test asset
9.2.6 Update asset
Important: As discussed earlier, an issue with the default review process was that the
“Risk, Security, Audit, and Compliance” Department was not involved. In Chapter 15,
“Managing service assets” on page 425, you will see how ZYX Electronics customized this
default review process with Rational ClearQuest to create a special review process to
manage license issues and applied it only to Framework asset types with Framework Type
value equal to Open source. In addition, we describe the submission of a second open
source asset and show how it works its way through the updated process.
Figure 9-9 on page 250 shows the position of this task in the workflow of the Asset-Based
Development plug-in. The purpose and expected inputs and outputs defined for this task are:
Purpose: To improve and refine the asset
Inputs: Reusable Asset. (Optional) Asset Artifact, Asset Review, and Asset Feedback
Outputs: Reusable Asset
Chapter 9. Produce reusable assets
249
Figure 9-9 Update asset
An asset is described with metadata and has artifacts, each of which can be modified. The
nature of the modification, or update, dictates if a new asset version is required.
It is up to the organization to establish the asset versioning policies, such as when a new
asset version is required. For example, certain people might think that modifying a grammar
issue in the metadata does not require a new asset version. Whereas if the grammar issue is
in one of the artifacts, people might state that a new asset version is required.
A general guideline to follow is to categorize asset modifications as structural and
non-structural. Structural changes include modifying the following items:
Metadata:
– Asset version
– Asset relationship
– Artifact reference
Artifact
File name, path, or content
In general, these kinds of changes require that a new asset version is created. Non-structural
changes are modifications to asset metadata other than those described and do not require a
new asset version.
This task includes the following four steps:
1. Identify or discover a problem with an asset: The organization needs to determine the
tolerance level for changes before requiring a new asset version. When the new version is
created, then the asset review and approval activities take place.
250
Strategic Reuse with Asset-Based Development
Asset problems can be submitted as part of a change management system. Alternatively,
requirements can be posted in a requirements management system, or the Asset Owner
can be notified via instant messaging of a defect.
Regardless of the source of the notification, the Asset Owner or Producer must be notified
of the problem and needs to prepare a plan to address this issue.
2. Search for the asset: The asset with the reported issue must be located in the
Repository.
3. Plan asset update activity: The correction or adjustment to the asset must be planned.
The necessary resources to modify the asset must be estimated and secured. The
expected timing of making the changes must be understood.
An impact analysis must be conducted where current Asset Consumers are evaluated and
the impact to their efforts is understood. This can require communication and planning
with Asset Consumers.
The impact analysis must also address asset relationships, including the related assets’
Asset Owners or Producers, as well as other technical dependencies. The Asset Owners
or Producers of related assets might need to participate in the planning, depending on the
nature of the problem and the nature of the asset relationship.
The review process for the asset might need to be revised to include other reviewers and
subject matter experts.
4. Update the asset: To update the asset, a developer will follow steps similar to these
steps:
a. Search for the asset in the Repository.
b. Retrieve the asset. Identify the SCM location from which to check out the asset
artifacts.
c. Modify the asset artifacts and metadata. The Asset Owner/Producer might need to
conduct merges from previous changes to the artifacts made by other people but which
have not yet been incorporated into the published asset in the Repository.
d. Submit the modified asset. Make changes to metadata, supporting documents, and
identify the SCM label or tag that must be applied to this asset version. The asset must
now be ready for the review and test process.
9.2.7 Publish or deploy asset
Figure 9-10 on page 252 shows the position of this task in the workflow of the Asset-Based
Development plug-in. In this task, the Administrator of the Repository publishes the asset or
deploys the asset in case the asset is deployable. The concept of this task is explained in
11.2.4, “Publish or deploy asset” on page 309 as the Administrator’s task.
Chapter 9. Produce reusable assets
251
Figure 9-10 Publish or deploy asset
9.3 ZYX Electronics: Produce reusable assets
This section describes how ZYX Electronics implements producing reusable artifacts using
Rational Asset Manager. To simplify this section, although ZYX Electronics will produce
different asset types (look at Table 8-3 on page 219 to know all asset types that will be stored
in the Rational Asset Manager Repository), we focus only on how ZYX Electronics produces
asset types related with open source frameworks and how these asset types relate with other
asset types.
We will describe how ZYX Electronics:
1. Conducts a recurring problem analysis to justify the costs and benefits of developing
reusable assets for the open source frameworks already used in different projects.
2. Develops an asset specification to describe the content and metadata of one of the open
source frameworks that will be created and submitted to the Repository and validates this
asset specification against the initial configuration created in Chapter 8, “Configure your
Asset Repository” on page 195 for the Rational Asset Manager Repository.
3. Uses Rational Asset Manager to create a new open source framework asset according to
its asset specification and to submit it to the Repository.
4. Uses Rational Asset Manager to create a new version of the existing asset according to
the asset versioning policies document created by ZYX Electronics to know when a new
asset version is required.
5. Implements and uses a review process to manage the approval of these open source
frameworks.
252
Strategic Reuse with Asset-Based Development
Note: Because the sample asset to produce in this section is not a service and it cannot be
published to a service registry, such as WebSphere Service Registry and Repository, we
will not cover the “Publish or Deploy Asset” task in this chapter for the ZYX Electronics
case study. It will be covered in Part 3, “Service Assets in an SOA” on page 333 of this
book when we talk about producing services.
9.3.1 Recurring problem analysis
Following the criteria and steps detailed in Chapter 8, “Configure your Asset Repository” on
page 195, ZYX Electronics’ Repository and Community Administrators (Deon Adminio and
Duncan Munchkin) defined and implemented an initial configuration for the Rational Asset
Manager Repository. They have created the initial environment that is needed to start to
implement and use an Asset-Based Development approach. Therefore, at this point, ZYX
Electronics has an available ready environment to support the reuse initiative.
In this chapter, we will follow the ZYX story and look at how they started to work with the
Asset Manager Repository. The first task that Duncan Munchkin wanted to perform was to
analyze and understand the recurring problems that ZYX Electronics was facing to identify
the first assets to load into the Rational Asset Manager Repository and to justify its
development and long-term maintenance.
ZYX Electronics’ initial reuse assessment determined that they were at Level 1- Initial/Chaotic
of the Reuse Maturity Framework (look at Chapter 7, “Adopting Asset-Based Development”
on page 125 for more information about this framework). It was clear that reuse was not being
supported and that any reuse was happening on an ad hoc and individual basis. Duncan
knew that at least in certain Java projects the developers were using the same development
environment (Eclipse). The use of open source frameworks had become popular at ZYX
Electronics when more and more pieces of code, subsystems, and systems were available
through the Internet.
Duncan also knew than when software developers were moved from one project to another
project, they reused part of the components built (doing a local copy) as the basis for the new
components.
So, Duncan decided to organize a meeting with these teams to determine how much reuse
was occurring and to discover what assets can be created and placed into the Rational Asset
Manager Repository.
During the meeting, Duncan Munchkin discovered that most of the Java projects were using
the same open source Java components, but nobody in the organization was aware of this
situation. These Java components provided frameworks and tools focused on the
development of Java 2 Platform, Enterprise Edition (J2EE) applications. There were also
common open source frameworks used for C++ and COBOL development.
This is a list of the open source frameworks that were used by ZYX Electronics projects.
Open source Java components:
Open source Ajax frameworks:
– DWR: DWR2 is a Java open source library, which allows you to write Ajax Web sites. It
allows code in a browser to use Java functions running on a Web server just as though
it was in the browser. DWR works by dynamically generating Javascript based on Java
classes. The code does Ajax magic to make it feel as though the execution is
2
Adapted from http://getahead.org/dwr
Chapter 9. Produce reusable assets
253
happening on the browser, but in reality, the server is executing the code and DWR is
moving the data backwards and forwards.
Open source build systems in Java:
– Maven: Maven3 is a Java project management and project comprehension tool. Maven
is based on the concept of a project object model (POM) in that all of the artifacts
produced by Maven are a result of consulting a well defined model for your project.
Builds, documentation, source metrics, and source cross-references are all controlled
by your POM. To see the full list of Maven’s features, go to:
http://maven.apache.org
– Ant4: Ant is a Java-based build tool.
Open source caching solutions in Java:
– OSCache: OSCache5 is a widely used, high performance J2EE caching framework. In
addition to its servlet-specific features, OSCache can be used as a generic caching
solution for any Java application.
Open source charting and reporting tools in Java:
– JFreeChart: JFreeChart6 is a free Java class library for generating charts.
Open source integrated development environments (IDEs) in Java:
– Eclipse: Eclipse7 is a type of universal tool platform. Eclipse is an open extensible IDE
for anything and nothing in particular.
– NetBeans8: NetBeans is a full-featured integrated environment for Java developers.
– JEdit: JEdit9 is a mature and well designed programmer’s text editor that has been in
development for over five years.
Open source persistent frameworks in Java:
– Hibernate: Hibernate10 is a powerful, ultra-high performance object/relational
persistence and query service for Java. Hibernate lets you develop persistent objects
following common Java idioms, including association, inheritance, polymorphism,
composition, and the Java collections framework. Extremely fine-grained, richly typed
object models are possible. The Hibernate Query Language, designed as a “minimal”
object-oriented extension to SQL, provides an elegant bridge between the object and
relational worlds. Hibernate is now the most popular Object Relational Mapping (ORM)
solution for Java.
Open source testing tools in Java:
– JUnit: JUnit11 is a regression testing framework written by Erich Gamma and Kent
Beck. It is used by the developer who implements unit tests in Java.
Open source J2EE/Web frameworks in Java:
– Struts: The core of the Struts12 framework is a flexible control layer based on standard
technologies, such as Java Servlets, JavaBeans™, ResourceBundles, and XML, as
well as various Jakarta Commons packages. Struts encourages application
3
Adapted from http://maven.apache.org
Adapted from http://ant.apache.org
5
Adapted from http://www.opensymphony.com/oscache
6 Adapted from http://www.jfree.org/freechart
7
Adapted from http://www.eclipse.org
8
Adapted from http://www.netbeans.org
9 Adapted from http://www.jedit.org
10
Adapted from http://www.hibernate.org
11
Adapted from http://www.junit.org
12 Adapted from http://struts.apache.org
4
254
Strategic Reuse with Asset-Based Development
architectures based on the Model 2 approach, a variation of the classic
Model-View-Controller (MVC) design paradigm.
– Spring: The Spring Framework13 provides solutions to many technical challenges
faced by Java developers and organizations wanting to create applications based on
the Java platform. Because of the sheer vastness of the functionality that is offered, it
can be hard to distinguish the major building blocks of which the framework is
composed. The Spring Framework is not exclusively linked to the Java Enterprise
platform, although its far-reaching integration in this area is an important reason for its
popularity.
– MyFaces: MyFaces14 is an implementation of JavaServer Faces (JSR 127), a new and
upcoming Web application framework that accomplishes the MVC paradigm. It is
comparable to the well-known Struts Framework but has features and concepts that
are beyond those of Struts.
– Aurora: Aurora15 is an open source MVC framework that is aimed at writing
configurable, fully object-oriented form controllers using the Spring Framework. The
code base grew out of experience using Spring’s MVC module and slowly developed
over several versions into a full-fledged framework that attempts to address the most
common problems when using Spring MVC and other J2EE Web-related issues in
general.
Open source COBOL components:
Open source COBOL compilers:
– OpenCOBOL: OpenCOBOL16 is an open source COBOL compiler. OpenCOBOL
implements a substantial part of the COBOL 85 and COBOL 2002 standards, as well
as many extensions of the existent COBOL compilers.
Open source C++ components:
C++ GUI libraries:
– MGui: MGui17 is a cross-platform GUI written in ANSI C. It has the usual widgets, such
as menus, push buttons, editable fields, and lists. It comes with a code generation tool
to design and maintain the graphical interface visually.
– SmartWin++: SmartWin++18 is a C++ abstraction of the Windows API. It is designed
to be type safe and be as thin a layer over the Windows API as possible.
C++ graphic libraries:
– Open Scene Graph: Open Scene Graph19 is a high-level 3-D graphics toolkit used in
the development of games, visual simulation, virtual reality, scientific visualizations,
and modeling.
All of the Java developers who attended the meeting were using Eclipse as their integrated
development environment, modules of the Java Spring Framework, and Ant to build Java
applications. But there was not any standardization in the use of these frameworks and which
versions to use. Each project had its own policies, and developers got their copies by going to
the external Web site and downloading a local copy on their workstations for their own use.
13
14
15
16
17
18
19
Adapted from http://www.springframework.org
Adapted from http://myfaces.apache.org
Adapted from http://auroa.ryotic.de/docs/introduction
Adapted from http://www.opencobol.org
Adapted from http://web.tiscali.it/morello/MGui
Adapted from http://smartwin.sourceforge.net
Adapted from http://www.openscenegraph.org/projects/osg
Chapter 9. Produce reusable assets
255
In fact, during the meeting, there were several discussions between Java developers from
different projects talking about incompatibilities between framework versions. Due to the
framework incompatibility, the developers were uncertain whether the resulting applications
will be compatible.
The COBOL and C++ frameworks were only used by a few teams and all team members
were using the same versions. But the meeting helped Duncan to discover that these teams
were using a common directory in one of the ZYX Electronics’ servers to share these
frameworks. However, no policy was defined for reusing them, and they were not using any
Software Configuration Management System to manage different versions of the frameworks.
In addition, Chris E. Oshman, the Chief Executive Officer at ZYX Electronics, had recently
read an article published in the press about legal issues of using open source and he wanted
to know how this was managed in his company. Refer to “Open Source, Open Legal Issues”
from New York Law Journal, January 2007, at:
http://www.dlapiper.com/files/Publication/97b92444-d924-4820-a3c0-66f0073ffc21/Pre
sentation/PublicationAttachment/220248cd-da82-4c8b-89d2-6cf0783c8396/NYLJ_Radcliff
e_Nelson_Article_Jan07.pdf
Chris was very worried after discovering that there was not a policy in place to manage the
licensing terms of these open source frameworks. Moving forward, Duncan met with the
“Risk, Security, Audit, and Compliance” Department to implement a mechanism to manage
the use and restrictions of open source frameworks within ZYX Electronics.
Duncan analyzed the list of frameworks already used and thought that it might be a good idea
to start uploading these open source frameworks into the Rational Asset Manager
Repository. Publishing these frameworks as assets into Asset Manager provided a number of
benefits, including:
Developers had a central place to look for all open source assets that were allowed to be
used within their organization.
Versioning of frameworks was managed and versioning lowered the incompatibility risk.
Duncan was now able to track which teams were using which assets.
Support for the definition and implementation of an approval process for all of the open
source assets used within the ZYX Electronics organization (including the “Risk, Security,
Audit, and Compliance” Department in this review process).
Figure 9-11 on page 257 shows all roles that benefit from reusing open source frameworks
and the relationships to open source frameworks.
256
Strategic Reuse with Asset-Based Development
Figure 9-11 Roles that will use open source framework assets in ZYX Electronics
The next step for Duncan was to develop the asset specification for this asset type, which we
will see in the next section.
9.3.2 Develop asset specification
The asset specification of the open source framework must provide the business and
technical justification for the asset and must be used by the support teams to understand the
asset.
In 8.2, “Repository configuration for ZYX Electronics” on page 214 (see Table 8-3 on
page 219), ZYX Electronics defined an initial configuration for the Rational Asset Manager
Repository describing the asset types and restrictions that the Repository must be able to
manage. However, after the meetings with developers and then with the “Risk, Security,
Audit, and Compliance” Department, Duncan and Deon had to review this initial structure. In
particular, they needed to determine if the structure was still valid to manage open source
frameworks.
Tip: As discussed earlier, the Repository configuration will need to be revisited periodically
to ensure that it accurately reflects the organization, asset types, and workflow needed by
the organization.
The first step in the review was to confirm that the Asset Manager configuration already had
an asset type defined to manage open source frameworks. They checked that the structure
created in Rational Asset Manager had an asset type called Framework and that there was a
category constraint for this asset type called Framework type with values (Open source,
Commercial UI components, SQL Scripts, and Batch scripts). Therefore, the configuration
was able to manage open source assets by specifying the assets as type Framework and
setting Framework type equal to Open Source.
To be able to manage license issues, the asset must also include information about the
license terms and conditions to use it. An open source license is a copyright license for
software that makes the source code available under terms that allow for modification and
Chapter 9. Produce reusable assets
257
redistribution without having to pay the original author20. These licenses can have additional
restrictions, such as a requirement to preserve the name of the authors and the copyright
statement within the code.
Note: The Open Source Initiative (OSI) is a non-profit corporation formed to educate
individuals about and advocate for the benefits of open source and to build bridges among
various constituencies in the open source community. This corporation has approved a set
of open source licenses that comply with the Open Source Definition (see
http://www.opensource.org/licenses/alphabetical for a complete list of open source
licenses approved by the Open Source Initiative).
So although the initial configuration allowed ZYX Electronics to manage open source
frameworks, the Framework asset type did not include any information about the license
terms and conditions needed to use the asset. As a result, Deon and Duncan had to modify
the initial Framework asset type definition to:
Include additional constraints to verify automatically the content of the asset.
Create a specific asset review process to include the “Risk, Security, Audit, and
Compliance” Department in the review and approval process of open source frameworks.
They also included the following additional metadata information in the Framework asset
type:
New artifact constraint to include a LEGAL TERMS&CONDITIONS label to describe the
specific terms and conditions to use the open source framework. Because the Framework
asset type was also used to manage other frameworks that are not open source, this
constraint is optional.
New category constraint called “Open source license name” specific to this asset type to
classify the open source framework. This category must include the list of open source
licenses approved by the Open Source Initiative (OSI) that are listed at this Web site:
http://www.opensource.org/licenses/alphabetical
Because the Framework asset type was also used to manage other frameworks that are
not open source, this constraint is also optional.
A new category constraint called Technology_Software specific to this asset type and to
the Component asset type to define the technology where this framework must be used.
This category can have following values: J2EE, COBOL, C++, and Others.
A new attribute called “License Expiration Date” to define the expiration date, if it exists, of
the open source framework licenses. This attribute is optional.
A new attribute called “Specific Restrictions” to capture additional information about
restrictions that can apply to use the asset. This attribute is optional.
All component asset types that were using an open source component must include a
relationship named “Uses open source framework” with the Framework asset type that
represents the open source framework.
All open source framework assets were planned for Black box reuse: although the source
code is available, the assets are delivered and used as binaries (libraries and executables).
To include this additional metadata to the Framework asset type, Deon logged in as the
Repository Administrator and used the Administration tab to go to the asset type definition.
When in the Administration section, he modified the asset type definition to include these
20
258
Open Source Initiative at http://www.opensource.org
Strategic Reuse with Asset-Based Development
updates. For detailed information about how to modify an asset type configuration, go to 8.2,
“Repository configuration for ZYX Electronics” on page 214.
To implement the review process for the open source frameworks, Deon and Duncan had to
create a new review process to include the “Risk, Security, Audit, and Compliance”
Department. This review process must only be applied to Framework asset types with
Framework Type equal to “Open source”. Chapter 11, “Manage reusable assets” on page 303
describes how ZYX Electronics created this special review process and assigned it only to
open source frameworks (not to other types of frameworks).
According to the information gathered from developers, one of the assets most often used by
ZYX Electronics’ projects was the Spring J2EE framework. Based on this fact, Deon decided
to develop the Asset Specification for the Spring open source framework as an example to
offer to users.
Table 9-1describes the ZYX Electronics’ asset specification content for the Spring J2EE open
source framework.
Table 9-1 Asset Specification for Spring open source framework
Asset Specification
Value
Name
Spring Framework
Version
Current Version is 2.0.6
Description of problem
A need to increase development productivity and reduce
complexity when building J2EE applications. In addition,
there is a need to improve test coverage and application
quality.
Description of solution
The Spring open source framework provides a set of
solutions to many technical challenges faced by Java
developers and organizations wanting to create applications
based on the Java platform. At a high level, this framework:
Promotes writing code to interfaces
Provides a consistent approach to managing business
objects
Provides data access abstraction
Provides a transaction management abstraction
Provides an Aspect-Oriented Programming (AOP)
framework
Provides an MVC-based Web framework
The framework provides strong support for modularity,
which means that you can choose specific aspects from the
framework as desired. In addition, the solutions within the
framework support work across all architectural layers in a
J2EE solution.
Chapter 9. Produce reusable assets
259
Asset Specification
Value
Expected contexts:
Development context
Rational Application Developer
Testing context
N/A
Runtime context
WebSphere Application Server 6.1
Technical domain context
Development of Java and J2EE applications
Expected artifacts in the
asset
At least one .doc file to know how to use the asset
A LEGAL TERMS&CONDITIONS label to describe the
specific terms and conditions to use the open source
framework
A .zip file containing the framework content
Asset relationships and
dependencies
All component asset types that use the Spring open source
component must include a relationship named “Uses open
source framework” with it.
Category schemas
Framework Type → Open source
Technology Hardware → Windows
Technology Hardware → Linux
Technology Hardware → UNIX
Open Source License Name → Apache License, 2.0
Technology_Software → J2EE
Custom attributes
License Expiration Date → N/A
Specific Restrictions → The Spring Framework 2.0 requires
J2SE™ 1.3 and J2EE 1.3 (Servlet 2.3, JSP™ 1.2, JTA 1.0,
EJB™ 2.0)
260
Expected Asset
Consumer skills
Developers writing J2SE and J2EE solutions
How the expected
consumer will use the
asset
Download the zip file containing the Spring framework. The
“dist” directory contains the following distinct jar files for
developing Java applications.
Asset Owner and
maintainer
Java Developer expert in J2EE development
Sponsor and funding
No funding needed, because it is an open source framework
Estimated asset
development effort
Not applicable, because it is an open source framework
Estimated Asset
Consumer benefits
10% of time consumed by a Java developer writing Java
code
Strategic Reuse with Asset-Based Development
This Asset Specification was used as an input for the asset creation phase as we will see in
next section.
9.3.3 Create asset
The Spring open source framework was created according to the Asset Specification
information of Table 9-1 on page 259.
According to this specification, the Spring asset must be created by a Java developer expert
in J2EE development (Asset Owner and maintainer field in Table 9-1 on page 259) so Duncan
decided that Al Aarkashan (the ZYX Electronics’ Architect with a long experience in Java
development) is the best person to create this new asset in the asset Repository. Al
Aarkashan is also responsible for maintaining and creating new versions of the asset. As the
Asset Owner, he is also the technical contact for other developers’ questions regarding the
asset.
To create this new asset and load its content into Rational Asset Manager, Al logged into
Rational Asset Manager via its Web interface. Deon, the Rational Asset Manager Repository
Administrator, had already included Al in the Architects user group that had Asset Producer
permissions to create assets in the Analysis_Design and Implementation communities.
To create the new Spring asset:
1. Al selected the Submit Asset tab and entered the following information in the Describe
section:
– Name: Spring Framework
– Version: 2.0.6 (because this is the last version of the Spring Framework downloaded
from the Web). For more information about asset version policy, look at 9.3.5, “Update
Asset” on page 272.
– Community: Implementation
– Type: Framework (when the asset type is selected, new information fields will appear in
the window, such as License Expiration Date attribute, that is, restrictions associated
to the Framework asset type will be applied automatically to the asset definition)
– Short Description: Spring open source Java framework to improve Java
development
– Tags: Spring
– Creation time: 0 hours
– Usage time: Leave blank
– Project: Pilot Project
– License Expiration Date: Not applicable
– Specific Restrictions: The Spring framework requires J2SE 1.2 and J2SE 1.3.
– Description: The Spring Framework can be considered a collection of smaller
frameworks or frameworks-in-the-framework. Most of these frameworks are
designed to work independently of each other yet they provide better
functionalities when used together. These frameworks are divided along the
building blocks of typical complex applications:
• Inversion of Control container: Configuration of application components
and life cycle management of Java objects
Chapter 9. Produce reusable assets
261
• Aspect-oriented programming framework: Working with functionalities that
cannot be implemented with Java’s object-oriented programming capabilities
without making sacrifices
• Data access framework: Working with relational database management systems
on the Java platform using JDBC™ and Object-relational mapping tools
providing solutions to technical challenges that are reusable in a
multitude of Java-based environments
• Transaction management framework: Harmonization of various transaction
management APIs and configurative transaction management orchestration for
Java objects
• Model-view-controller framework: HTTP and Servlet-based framework
providing many hooks for extension and customization
• Remote Access framework: Configurative RPC-style export and import of Java
objects over computer networks supporting HTTP-based protocols, RMI,
CORBA, and Web services (SOAP).
• Authentication and authorization framework: Configurative orchestration of
authentication and authorization processes supporting many popular and
industry-standard standards, protocols, tools, and practices via the Acegi
security framework (Java) sub-project.
• Remote Management framework: Configurative exposure and management of Java
objects for local or remote configuration via JMX™
• Messaging framework: Configurative registration of message listener
objects for transparent message consumption from message queues via JMS,
improvement of message sending over standard JMS APIs.
• Testing framework: Support classes for writing unit tests and integration
tests
Figure 9-12 on page 263 shows Al entering this information into the Repository.
262
Strategic Reuse with Asset-Based Development
Figure 9-12 Submit An Asset: Describe tab
2. To include the required artifacts associated to the Spring framework asset, Al selected the
Attach tab and noticed that there was an information message warning about the
constraints associated to the open source frameworks, as shown in Figure 9-13.
Figure 9-13 Constraints associated to the open source framework
Chapter 9. Produce reusable assets
263
3. As shown in Figure 9-14, based on the Asset Specification information of Table 9-1 on
page 259 and the asset type constraints, Al attached the following artifacts:
– A word document describing how to use the Spring Framework
– A license.txt with a Legal Terms&Conditions label to describe the specific terms and
conditions to use the open source framework
– A zip file containing the framework content (both the source and executables)
Figure 9-14 SubmIt An Asset: Attach tab
4. To categorize and classify the Spring framework asset, Al selected the Categorize tab
and entered the following information as Figure 9-15 on page 265 shows, based on the
Asset Specification information of Table 9-1 on page 259. To specify each category
classification, Al had to select the values for each category in the left and then click Add to
add each value to the Repository):
– Framework Type: Open source
– Technology Hardware: Windows
– Technology Hardware: Linux
– Technology Hardware: UNIX
– Open Source License Name: Apache License, 2.0
– Technology_Software: J2EE
264
Strategic Reuse with Asset-Based Development
Figure 9-15 SubmIt An Asset: Categorize tab
1. To associate the Spring framework asset with other assets that already exist in the
Rational Asset Manager, Al selected the Associate tab. However, the Spring framework
was the first asset to be loaded into the Repository so there were no component assets
using this framework, so he left this section empty, as Figure 9-16 shows.
Figure 9-16 SubMit An Asset: Associate tab
2. To finish the asset submission and to verify that all Spring constraints were correctly
introduced as Figure 9-17 on page 266 shows, Al selected the Confirm tab and clicked
Submit for Review. If any of the restrictions for the Framework asset type had not been
entered correctly, this Confirm section displays in red the constraints that were not met for
this asset type.
Al also might have selected other options instead of submitting the asset for review:
Save as Draft: This option saves the modifications made to the asset, but the asset
remains in the draft state.
Chapter 9. Produce reusable assets
265
Submit As Is: This option submits the asset directly to the Approved state, but it still needs
to be reviewed by the Administrator if the review process was configured for an asset to
need administration approval.
Figure 9-17 Submit An Asset: Confirm tab
As shown in Figure 9-18 on page 267, Rational Asset Manager displayed a confirmation to Al
displaying the different options available to continue working with the asset (Subscribe To
Asset, E-mail Asset, and Forums).
266
Strategic Reuse with Asset-Based Development
Figure 9-18 Asset submission confirmation
By default, when Al submitted the asset, the Repository listed him as the Asset Owner. Later
on, if necessary, he can change this Asset Owner to someone else. As Asset Owner, he
automatically is given e-mail subscriptions to the asset and will be notified when any user
downloads the asset, updates the asset’s metadata or content, or discusses the asset.
In Chapter 10, “Consume reusable assets” on page 281, we will talk in detail about these
additional available options and how ZYX Electronics used them for consuming and
managing assets.
The initial Repository configuration had associated a default review process for all of the
assets submitted to the Implementation community. Therefore, the Spring asset automatically
went to the Review state. The Project Managers user group was responsible for reviewing the
asset.
In 9.2.4, “Create asset” on page 245, you saw how ZYX Electronics used this Rational Asset
Manager default review process to implement a generic workflow to review all asset types
stored in the Implementation community.
Important: As discussed earlier, an issue with the default review process was that the
“Risk, Security, Audit, and Compliance” Department was not involved. In Chapter 11,
“Manage reusable assets” on page 303, you will see how ZYX Electronics customized this
default review process with Rational ClearQuest to create a special review process to
manage license issues and applied it only to Framework asset types with Framework Type
value equal to Open source.
Rational Asset Manager stores the artifacts and metadata associated to the Spring open
source framework using the Reusable Asset Specification (RAS) structure. Example 9-1 on
Chapter 9. Produce reusable assets
267
page 268 is a copy of the manifest file created by Rational Asset Manager for the Spring
asset.
Important: This manifest file is shown here to provide additional detail and insight into how
Rational Asset Manager manages information related to assets. In the typical usage of an
asset, you will not need to delve into this level of detail.
Example 9-1 Manifest file for Spring open source framework
<?xml version="1.0" encoding="UTF-8"?>
<defaultprofile:Asset xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI"
xmlns:defaultprofile="http:///defaultprofile.ecore" name="Spring Framework"
id="{DAA188E3-7B78-C115-7F9E-BBBE69199B63}" date="2007-09-04" state="Approved"
version="2.0.6" shortDescription="Spring open source Java framework to improve
Java development">
<classification>
<descriptorGroup name="AssetType">
<nodeDescriptor
href="http://localhost:9083/com.ibm.ram.repository.web/classif/assetTypesSchema.xm
i#framework10"/>
</descriptorGroup>
<descriptorGroup name="CreationTime">
<freeFormValue
freeFormDescriptor="//@classification/@descriptorGroup.1/@freeFormDescriptor.0"><v
alue>0.0</value></freeFormValue>
<freeFormValue
freeFormDescriptor="//@classification/@descriptorGroup.1/@freeFormDescriptor.0"><v
alue>person hours</value></freeFormValue>
<freeFormDescriptor name="CreationTime"/>
</descriptorGroup>
<descriptorGroup name="CustomAttributes">
<freeFormValue><freeFormDescriptor
href="http://localhost:9083/com.ibm.ram.repository.web/classif/assetTypesSchema.xm
i#licenseexpirationdate"/><value>No Applicable (license does not
expires)</value></freeFormValue>
<freeFormValue><freeFormDescriptor
href="http://localhost:9083/com.ibm.ram.repository.web/classif/assetTypesSchema.xm
i#project"/><value>Pilot Project</value></freeFormValue>
<freeFormValue><freeFormDescriptor
href="http://localhost:9083/com.ibm.ram.repository.web/classif/assetTypesSchema.xm
i#specificrestrictions"/><value>The Spring framework requires J2SE 1.2 and J2SE
1.3.</value></freeFormValue>
<classificationSchema
href="http://localhost:9083/com.ibm.ram.repository.web/classif/assetTypesSchema.xm
i#/"/>
</descriptorGroup>
<descriptorGroup name="StandardInfo">
<freeFormValue
freeFormDescriptor="//@classification/@descriptorGroup.3/@freeFormDescriptor.0"><v
alue>6</value></freeFormValue>
<freeFormDescriptor name="revisionCount"/>
</descriptorGroup>
<descriptorGroup name="Framework Type">
268
Strategic Reuse with Asset-Based Development
<nodeDescriptor
href="http://localhost:9083/com.ibm.ram.repository.web/classif/frameworktype.xmi#o
pensource"/>
<classificationSchema
href="http://localhost:9083/com.ibm.ram.repository.web/classif/frameworktype.xmi#/
"/>
</descriptorGroup>
<descriptorGroup name="Open Source License Name">
<nodeDescriptor
href="http://localhost:9083/com.ibm.ram.repository.web/classif/opensourcelicensena
me.xmi#apachelicense20"/>
<classificationSchema
href="http://localhost:9083/com.ibm.ram.repository.web/classif/opensourcelicensena
me.xmi#/"/>
</descriptorGroup>
<descriptorGroup name="Technology Hardware">
<nodeDescriptor
href="http://localhost:9083/com.ibm.ram.repository.web/classif/technologyhardware.
xmi#windows"/>
<nodeDescriptor
href="http://localhost:9083/com.ibm.ram.repository.web/classif/technologyhardware.
xmi#unix"/>
<nodeDescriptor
href="http://localhost:9083/com.ibm.ram.repository.web/classif/technologyhardware.
xmi#linux"/>
<classificationSchema
href="http://localhost:9083/com.ibm.ram.repository.web/classif/technologyhardware.
xmi#/"/>
</descriptorGroup>
<descriptorGroup name="Technology Software">
<nodeDescriptor
href="http://localhost:9083/com.ibm.ram.repository.web/classif/technologysoftware.
xmi#j2ee"/>
<classificationSchema
href="http://localhost:9083/com.ibm.ram.repository.web/classif/technologysoftware.
xmi#/"/>
</descriptorGroup>
</classification>
<solution>
<artifact name="How to use Spring Framework.doc" type="application/msword">
<reference><value>How to use Spring Framework.doc</value></reference>
</artifact>
<artifact name="spring-framework-2.0.6.zip" type="multipart/x-zip">
<reference><value>spring-framework-2.0.6.zip</value></reference>
</artifact>
<artifact name="license.txt" type="text/plain">
<reference><value>license.txt</value></reference>
<artifactType type="Legal terms&amp;Conditions"/>
</artifact>
</solution>
<description><value>&lt;p style=&quot;margin: 0px;&quot;>Spring Asset
Description .... &lt;br></value></description>
</defaultprofile:Asset>
Chapter 9. Produce reusable assets
269
9.3.4 Review and test asset
The Spring asset that Al submitted to the Rational Asset Manager Repository was in the
Draft state, so it had to go to through a review process to get to the Approved state as shown
in Figure 9-19.
Figure 9-19 Rational Asset Manager default review process
Deon had already configured that all of the assets belonging to the Implementation
community must go through a default review process and that users included in the Project
Managers user group must be the reviewers for these assets.
Patricia Moon, the Project Manager, logged in to the Rational Asset Manager Web Interface
and selected the My Asset Manager tab to check for assets pending for review. The section
Assets to Review showed the Spring asset, as shown in Figure 9-20 on page 271.
270
Strategic Reuse with Asset-Based Development
Figure 9-20 Assets pending review
So, Patricia clicked the Spring Framework asset and selected the Review tab. As shown in
Figure 9-21, the Spring asset was still in the Review state.
Figure 9-21 Asset is in the Review state
To start the review process, Patricia clicked Claim Review, added comments to the review,
and clicked Accept to finish the review process as shown in Figure 9-22 on page 272.
Chapter 9. Produce reusable assets
271
Figure 9-22 Accept asset review
After the Spring asset was approved by Patricia (who was the only reviewer assigned to
approve the asset), it went to the Approved state, and it was also available for the other
Rational Asset Manager users.
In Chapter 11, “Manage reusable assets” on page 303, you will see how ZYX Electronics
customized this default review process with Rational ClearQuest and applied it only to the
open source framework assets to involve the “Risk, Security, Audit, and Compliance”
Department in their review.
9.3.5 Update Asset
An asset is described by its metadata and artifacts, and every organization must decide when
a change in its metadata or artifacts must produce a change in the asset version. Therefore,
each organization defines its own asset version policy.
Duncan Munchkin assigned this task to Deon Adminio, the Tools Administrator in ZYX
Electronics, because Deon was the person with the most experience in software
configuration management. Because ZYX Electronics was using Rational ClearCase to
manage software configuration, Deon decided that this might be a good opportunity to define
how Rational Asset Manager and Rational ClearCase must work together and the tasks
associated to each tool. This integration was not clear for many users, and Deon had already
received several questions asking about the difference between Rational Asset Manager and
Rational Clearcase.
Although ZYX Electronics had offices in multiple countries, the first deployment of Rational
Asset Manager was going to be in their main offices in San Jose, California, where ZYX
Electronics had most of their development projects.
272
Strategic Reuse with Asset-Based Development
This is a summary of the Asset Version Policy document that Duncan wrote and sent to all
Rational Asset Manager and Rational ClearCase users to define and clarify the policy that
ZYX Electronics’ users must follow to manage versions of assets and the individual artifacts
of assets.
Asset Version Policy
Rational ClearCase is the software configuration management tool that manages versions of
individual artifacts or files. You must use Rational ClearCase during development time, and it
will help development teams to work together.
The individual ClearCase artifacts will later be grouped in assets with additional metadata
information and submitted as an specific asset version to Rational Asset Manager as shown
in Figure 9-23.
Rational ClearCase
Rational Asset Manager
Spring Asset v2.0.6
Additional metadata *
Spring.jar v2
Spring.jar v2
license.txt v1.9
license.txt v1.9
Additional metadata =
Name, Description, State,
Attributes, Categories, Relationships
Figure 9-23 Rational Asset Manager and Rational ClearCase versions for ZYX Electronics
When you submit a new asset to the Rational Asset Manager Repository, you have to assign
a version to the asset, because the version is a mandatory field.
But when the asset content is modified, you must follow these rules to determine whether you
need to create a new asset version. Rational Asset Manager will not force you to create a
new version when you change asset content:
Create a new asset version when:
–
–
–
–
–
There is a new artifact version.
There is a new artifact included in the asset.
An existing artifact is removed from the asset.
There is a new relationship with other asset.
There is a change in the asset name.
Maintain the same asset version when:
–
–
–
–
There is change in an attribute.
There is a change in a category value.
There is a change in the asset description.
There is a change in the asset state.
A few days after submitting the 2.0.6 Spring asset version to the Repository, Al received an
e-mail from the official Spring Web site indicating that a new version of the Spring framework
Chapter 9. Produce reusable assets
273
was available. Because he was the Asset Owner and responsible for its maintenance, he
decided to update this information into Rational Asset Manager. He reviewed the changelog
file describing what was new in the new Spring version. There was a change in the spring.jar
file, which consisted of the removal of the RemoteInvocationUtilsTests class. Based on this
information, he decided to update the asset in Rational Asset Manager and create a new
version of the asset.
To create a new asset version and update its content:
1. Al logged into Rational Asset Manager using the Web interface. Al selected the My Asset
Manager tab to find the asset version that he had previously submitted into the
Repository. When located, he clicked Spring Framework (Version 2.0.6) to check its
content as shown in Figure 9-24.
Figure 9-24 Spring Framework Version 2.0.6 content
2. Because Al was the Asset Owner, he had permissions to create a new asset version. To
modify its content, he clicked Create new version of the Asset Detail Tools section as
shown in Figure 9-25 on page 275.
274
Strategic Reuse with Asset-Based Development
Figure 9-25 Modify link
3. Because there was a change in one of the asset artifacts, Al had to change the asset
version, so he updated the Version field to 2.1 in the Describe tab as shown in
Figure 9-26. He also included a comment in the Description field to reflect the change
that he introduced.
Figure 9-26 Create a new version for the Spring Framework asset
Chapter 9. Produce reusable assets
275
4. To load the new version of the spring.jar file, Al clicked the Attach tab and removed the old
version of the spring.zip file and replaced it with the new version as shown in Figure 9-27.
There were not any changes in the word document describing how to use the framework
nor in the license.txt file describing the licensing terms and conditions to use this asset.
Figure 9-27 Change spring.jar artifact version
5. Because no additional changes were needed, Al just clicked Confirm to save the
modifications to the new asset version and submit it for review.
6. To verify that the new asset version was submitted correctly to the Repository, Al went to
the My Asset Manager tab to check that there was a new version for the Spring
Framework as shown in Figure 9-28.
Figure 9-28 My Asset Manager tab with all versions created
As we can see in Figure 9-28, the new version 2.1 was submitted to the Repository but was
still in the Review state. The process to approve the new version was exactly the same
276
Strategic Reuse with Asset-Based Development
process that Patricia Moon, the Project Manager, followed to approve the first version of the
asset (See details in 9.2.5, “Review and test asset” on page 248).
The Unique ID, which is an internal field used by Rational Asset Manager to identify each
asset, remains that same across asset versions.
If the modification that Al wanted to make to the asset had not needed to create a new
version according the rules specified by Deon in the Asset Version Policy document, Al might
have used the Modify link instead of Create new version as shown in Figure 9-29.
Figure 9-29 Modify asset content without creating a new version
7. After the modification was made, Al had to confirm the changes using Update, write
comments explaining the change made to the asset, and then submit the asset for review.
If Al had wanted to create another asset with similar information to the Spring asset, he might
have reused the content of this asset and clicked the Duplicate link as shown in Figure 9-30
on page 278.
Chapter 9. Produce reusable assets
277
Figure 9-30 Duplicate asset content
Rational Asset Manager will create a new asset with same content of the Spring asset but will
use a new Unique ID. The asset must be renamed and then updated according to the new
asset specification.
Looking at the functionality provided by the Duplicate link, Al thought that it might be a good
idea to propose creating “template” assets that can be reused later by Asset Producers as
shown in Figure 9-31 on page 279.
278
Strategic Reuse with Asset-Based Development
Asset Template
Duplicate
New Asset
Draft Asset
Save as Draft
Give new name and
version
Download and create
local copy of artifacts
Modify
Artifact templates
Asset Artifacts
Attach
Create new content
based on the templates
Submit
Final Asset
Figure 9-31 Duplicate asset templates process
These “template” assets contain detailed descriptions of what was expected of any new asset
of this type (templates for Microsoft Word documents, models, and so forth) for the Asset
Producer to use as a base, as well as providing default settings for many fields within the
asset. Asset Producers can reuse these asset templates and duplicate their content to make
a copy for their new assets. With this approach, Asset Producers can review the detailed
description with the instructions of how to create the asset, download the artifact (templates
of documents), give the asset a new name, and save it as a draft until they finished creating
the asset artifacts and filling out the asset fields and relationships as necessary. When
complete, the Asset Producer submits the new asset.
9.3.6 Publish or deploy asset
Because the assets produced in this part for ZYX Electronics do not contain service
definitions, these assets will not be published to WebSphere Service Registry and
Repository. Part 3, “Service Assets in an SOA” on page 333 will describe this task for the ZYX
Electronics case study.
Chapter 9. Produce reusable assets
279
280
Strategic Reuse with Asset-Based Development
10
Chapter 10.
Consume reusable assets
In this chapter, we discuss consuming reusable assets. We include a further discussion of
best practices in consuming reusable assets and how ZYX Electronics consumed reusable
assets and leveraged Rational Asset Manager to consume reusable assets.
© Copyright IBM Corp. 2008. All rights reserved.
281
10.1 Introduction
In this chapter, we look at the asset usage life cycle, that is, the consumption of assets. As
shown in Figure 10-1, it is important to remember that this is a cycle. Consumption of assets
happens throughout a project, requests for enhancements and defects will be recorded, and
quite likely, new assets will be identified. This cycle occurs many times both within and across
projects.
Figure 10-1 Asset usage cycle
Also, we need to remember that there is a connection between the manufacturing cycle and
the usage cycle. This interaction is a key aspect to the success of any asset reuse program.
The Asset Consumer team needs to ensure that they are communicating with the production
team. As part of this communication, the Asset Consumer team needs to keep the production
team informed regarding any consumability or quality issues with the asset. In addition, the
consumers might modify an asset as part of their effort and will find themselves making the
updated asset available as a new asset. Last, but certainly not least, the Asset Consumers
need to alert the Asset Producers to opportunities or needs for new assets as shown in
Figure 10-2 on page 283.
282
Strategic Reuse with Asset-Based Development
Figure 10-2 Integration between usage and manufacturing cycles
10.2 Asset usage
As described in Chapter 5, “Asset-Based Development and Asset Governance Rational
Method Composer plug-ins” on page 61, the plug-in provides use process guidance to the
asset as a capability pattern. Figure 10-3 shows its workflow and the tasks composing it.
Figure 10-3 Workflow of use process
10.2.1 Asset consumption roles
This chapter describes the tasks involved in asset consumption mainly from the views of the
following two roles:
Asset Consumer: The Asset Consumer searches and browses Reusable Assets in the
Asset Repository and ultimately uses the assets. The Asset Consumer provides feedback
Chapter 10. Consume reusable assets
283
on the assets. There are many roles from the enterprise which can perform the role of an
Asset Consumer, for example: Manager, Analyst, Architect, Developer, Tester, and so
forth.
This role mainly performs the following tasks:
– Search Asset
– Use Asset
– Provide Asset Feedback
Subscriber: A Subscriber is interested in the activities related to an asset or a specific
search in the Repository. The Subscriber registers interest in the Asset Repository.
Examples of events related to an asset include change in state, submitted rating,
downloads, asset update, and other events. The Subscriber can be notified via e-mail or
Really Simple Syndication (RSS) feeds.
This role mainly performs the Search Asset task.
10.2.2 Search asset
Figure 10-4 shows the position of this task in the workflow of the Asset-Based Development
plug-in. The purpose and expected inputs and outputs defined for this task are:
Purpose: To find a Reusable Asset that fits specific criteria (for example, context,
features, platform, performance, and so forth).
Inputs: Asset Repository. (Optional) Asset Report.
Outputs: Reusable Asset.
Figure 10-4 Search asset
In this task, the Asset Consumer searches, browses, evaluates, and accepts an asset. This
task is the first step of consuming.
As we make asset reuse a part of the business, it is important that Asset Consumers are able
to successfully find the assets that they need and can use in a timely fashion. This highlights
the fact that not only do we need high quality, well documented and consumable assets, we
also need to make sure that they are stored in a logical manner and can be accessed via
search mechanisms. These search mechanisms can include tagging, keyword search, or
schema navigation. Ideally, we want the search mechanisms to be quick and easy to use.
284
Strategic Reuse with Asset-Based Development
Also, remember that when an asset is produced, there is often a connection to related assets.
When looking for assets to use, the Asset Consumer will take advantage of these
relationships to find other worthwhile and beneficial assets.
This task includes the following four steps:
1. Search for asset: This step is where we search for an asset in the Repository. As the
volume of assets in the Repository grows, we will need to ensure that we are as specific
as possible in our search. Just as it can be discouraging to perform a search and not find
any assets, it can be discouraging to search and find too many assets.
2. Browse asset: This is often an informal step. Based on the information provided in the
search results from the Repository, we make decisions regarding the suitability of an asset
for reuse. Several of the assets will be deemed as not being a good fit and other assets
will be considered fit candidates and therefore will be used as the input into the next step.
3. Evaluate asset: Perform a “fit” analysis to see if the asset will work or fit in the required
context. This analysis can involve applying the asset into a temporary location and
validating its compliance with your requirements, including testing out variability point
binding and customization ideas.
This step generally implies a more formal style of assessing the applicability of an asset.
There are several key perspectives to evaluate:
– Evaluate the asset’s business fit:
•
Determine the reuse cost avoidance by using the asset: Another way of saying
this is to determine the potential cost savings to the business by using this asset. To
do this, you must understand the capabilities that the asset provides and what the
cost is for your organization to develop it.
•
Determine the payoff threshold by using the asset: How many uses will it take
to pay off the costs of purchasing and maintaining the asset?
•
Determine if the asset’s terms and licensing fit with your business model: Will
the asset be used in domestic and international locations? Does the asset need to
be distributed to multiple servers?
•
Identify who owns the task of maintaining the asset: What are the maintenance
support agreements? Will the asset authors provide support? If it is a White box
asset, can your organization maintain the asset?
– Evaluate the asset’s organizational fit:
•
Determine if all stakeholders will accept the use of the asset: Can your
organization overcome the “not invented here” mentality? Is the asset viewed as a
threat to any groups or individuals within the organization?
•
Determine if the asset will be used and accepted on multiple projects: Is there
sufficient need for this asset in other projects? Can the costs of reusing this asset
be amortized to other projects? Understanding the asset’s capabilities helps in
determining if the asset is a candidate for reuse on other projects within the
organization.
– Evaluate the asset’s process fit:
•
Determine if the use of the asset will fit into your organization’s process:
Does this asset require new roles and tasks in the process to develop with it and
support it? Is your organization’s process maturity level sufficient to incorporate the
roles and tasks for reuse? Usage information for the asset aids in the evaluation of
the asset fitting into the process, as well as the roles required to work with the
asset.
Chapter 10. Consume reusable assets
285
•
Make sure that tasks and time have been allocated to use and maintain the
asset: Will the asset’s stakeholders (architects, developers, and so on) be given
sufficient time to comprehend, use, and defend the asset?
– Evaluate the asset’s engineering fit:
•
Determine ease of understanding and usage: What is the quality of the
documentation? How many steps are involved to use the asset? How many
variability points does the asset have?
•
Determine functional completeness: Does the asset do what it says and do what
you need?
•
Evaluate reliability: Exercise and test the asset to determine if the asset will fit
your contexts.
•
Evaluate error handling: Will the error handling fit into the way that your
organization’s software handles errors?
•
Review hidden information: Are the complexities encapsulated to strengthen the
value proposition and decrease maintenance issues?
•
Evaluate cohesion and coupling properties: How many dependencies does the
asset have? What technical assumptions does the asset make? Is the asset
organized along reasonable, functional boundaries?
•
Review portability: In what technical contexts will the asset work?
•
Evaluate comments from other users: What has been the experience of other
people using the asset?
•
Understand the level of effort invested in the asset: What reuse metrics come
with the asset? How many person labor months and years are invested in the
asset?
4. Accept asset: This acceptance defines a technical acceptance and does not override the
necessary managerial acceptance needed, if any. The Asset Consumer might take notes
about recommendations for customizing the asset for the required context. This ensures
that what was learned while performing the fit analysis is not forgotten and reduces
duplicate effort between determining if the asset will work and making it work.
10.2.3 Use asset
Figure 10-5 on page 287 shows the position of this task in the workflow of the Asset-Based
Development plug-in. The purpose and expected inputs and outputs defined for this task are:
Purpose: To incorporate or instantiate a located Reusable Asset into the project or the
Consumer’s workspace. The time that it takes to search, browse, evaluate, and reuse an
asset impacts the value of the asset.
Inputs: Reusable Asset.
Outputs: Reusable Feedback.
286
Strategic Reuse with Asset-Based Development
Figure 10-5 Use asset
In this task, the Asset Consumer retrieves, uses, and sometimes extends an asset. Using an
asset is the main purpose of creating an asset.
There are four major styles of reuse:
Black box
Gray box
White box
Glass box
The consumer expects to have an asset that is well built, documented, and supported. From
a producer’s point of view, there is an expectation that the Asset Consumer will provide
feedback about the asset, share information regarding possible enhancements and defects,
and possibly enhance or create supporting and related artifacts. As discussed in the
introduction to this chapter, there is a strong relationship between these roles, and for a
successful reuse program to emerge, this relationship must be supported.
This task includes the following two steps:
1. Retrieve asset: Retrieve an asset from a Repository and bring the asset into the
development environment.
2. Extend asset: Certain assets can be extended through variability points, which are
locations in an asset or a contained artifact to be customized or extended. It is unrealistic
to expect each asset that has been retrieved to be a 100% fit. In these cases, based on
the fit analysis, the team will need to decide whether the extension of the asset is worth
the effort. Again, a well-engineered asset that supports extension through variability points
and proper documentation can be make this a low-risk situation.
Chapter 10. Consume reusable assets
287
10.2.4 Provide asset feedback
Figure 10-6 shows the position of this task in the workflow of the Asset-Based Development
plug-in. The purpose and expected inputs and outputs defined for this task are:
Purpose: To deliver insight and the effects of using the asset back to the Asset Owners or
to benefit other potential Asset Consumers. To have a channel for communicating any
issues with the Repository to the Repository Administrators.
Inputs: Asset Repository. (Optional) Reusable Asset.
Outputs: Reusable Feedback.
Figure 10-6 Provide asset feedback
Offering feedback is essential for accelerating Asset-Based Development. Forms of feedback
include:
Rating system: This method is a well-known form of feedback where stars or other icons
are used; it is great for quick glances but lacks the descriptive power of other forms.
Comments: This method provides textual description of experiences with an asset and is
generally given in a single direction.
Discussions: Discussion threads or forums provide a community approach to addressing
feedback.
Problems or issues: This method is more formal feedback where a problem number might
be retrieved and the asset development team tracks the submitted issue and responds
with future releases of the asset.
Surveys: These surveys are sent to the Asset Consumer asking the Asset Consumer to
answer the questions and reply.
288
Strategic Reuse with Asset-Based Development
Note: When sending a survey to the Asset Consumer, there are sample questions to
consider, such as:
How long did it take to use the asset?
What amount of time was saved by using the asset?
What did not go well with using the asset?
On what asset discussion forums have you participated?
On average, how much time do you spend searching for each asset?
Can you estimate what percentage of searches results in not finding what you want?
What assets do you need in the Repository, but you cannot find?
What kinds of assets do you not need?
When you have submitted defects, have you received a timely response on the defect?
How do you generally search for assets: keywords, search filters, custom tags, or a
combination?
Have you subscribed to any assets or searches? If so, have you received notification of
events?
This task includes the following two steps:
1. Identify form of feedback: Select the type of feedback that meets your purpose.
2. Provide feedback: In general, the feedback must be captured in the Repository, where
you can track the relationship of the feedback to assets, Asset Consumers, feedback
providers, and so forth. If a problem or issue is submitted, these relationships are even
more important, because the Asset Owners, Producers, and other teams involved with
authoring the asset plan are notified of the problem and create plans for addressing the
issue.
10.2.5 Develop asset specification
Figure 10-7 on page 290 shows the position of this task in the workflow of the Asset-Based
Development plug-in. In this task, the Asset Producer, or the Consumer in certain situations,
develops the asset specification. The concept of this task is explained in 9.2.3, “Develop asset
specification” on page 242 from a Producer’s point of view.
When looking at this task from a consumer’s point of view, it might at first seem strange that a
task related to creation is associated with this role. However, the consumer role is often the
one that is closest to the problems and the needs of the team. Therefore, the consumers are
most likely to first recognize a need for a reusable asset. In addition, because they are the
experts regarding the context, project, and reuse need, they are most qualified to write the
asset specification. Writing the asset specification does not necessarily mean that the
consumer will create the asset. Depending on the team structure, asset production
responsibilities might belong elsewhere. However, the person who writes the specification is
usually a key resource who is consulted by those people building the reusable asset.
Chapter 10. Consume reusable assets
289
Figure 10-7 Develop asset specification
10.3 ZYX Electronics: Consume reusable assets
Next, we discuss consuming reusable assets at ZYX Electronics.
10.3.1 Search asset
In Chapter 9, “Produce reusable assets” on page 237, we described how Al Aarkashan, the
ZYX Electronics’ Project Manager for this case study, created a new asset for the Spring open
source framework and how this asset was approved by Patricia Moon, the Project Manager.
Al followed a similar process to load other assets into the Rational Asset Manager
Repository. He loaded all of the open source frameworks that ZYX Electronics projects were
using, and developers started to use these open source frameworks to build their
applications. Later in this chapter, we will describe how developers used Rational Asset
Manager to download the assets that they used.
As expected, before the developers can use any of the assets, they had to find them in the
asset Repository. The initial Rational Asset Manager structure that Deon and Duncan created
was oriented to facilitate user searches looking for specific information. To explain this initial
structure and how to search for specific assets, Deon decided to spend one hour with
developers showing them all of the possibilities they had to look for information. This also
helped him to verify that the initial structure created in the Repository was valid and facilitated
easy searches for the users. This is a summary of what Deon explained to the developers
during that enablement meeting:
To search for assets in the Rational Asset Manager Repository, you can use both the Web
and Eclipse interfaces.
When you search for assets in the Rational Asset Manager Repository, you can search for
assets through all of the communities. But you will only be able to consume and download
assets from communities where you have at least Consumer permissions (see 8.1.1,
“Community Map” on page 197 to see the permissions assigned to each role).
290
Strategic Reuse with Asset-Based Development
You can restrict the scope of your search to:
– Search assets: You will search for information in the asset metadata, but not for
information included in its artifacts. This option is always selected by default, and you
cannot modify it.
– Search remote assets: You will search for information not only for the assets stored in
the Rational Asset Manager Repository, but also in other repositories integrated with it,
such as WebSphere Service Registry and Repository.
– Search within artifacts: You will search for information not only included in the asset
metadata, but also included in its artifacts.
– Search forums: You will search for information stored in the forums associated to the
assets.
To modify the scope of your search, you just have to select the magnifying glass located
to the left of the field search and mark the desired scopes.
To search for assets using the Rational Asset Manager Web interface, you must select the
Search for Assets tab. Rational Asset Manager provides tools that simplify the task of
finding assets within the Repository. You can find assets through keyword search,
advanced search, tags, and filters:
– Search assets by keywords: The primary method of finding assets is to search using
keywords. By default, the search keywords are compared to information in an asset’s
name, description, short description, rating, community, category, attributes, custom
attributes, and tags. As just discussed, this search includes the following options:
Search within artifacts, Search remote assets, and Search forums.
You can use search query terms and operators to help you create meaningful search
queries. Certain operators that you can use include: the asterisk (*) character to
represent a multiple character wildcard or the question mark (?) character to
represents a single wildcard character. For example, if you look for the “spr?ng”
keyword and the scope is modified to search within artifacts, the search will return all
assets containing spring and sprang words in the asset metadata or in its artifacts’
content as shown in Figure 10-8 on page 292.
Chapter 10. Consume reusable assets
291
Figure 10-8 Search for assets using keywords
– Search assets using advanced search fields: Click the Advanced link and you will
see a new window, as shown in Figure 10-9, with additional options to allow you to
increase the specificity of your search.
Figure 10-9 Search for assets using advanced search fields
Use as many fields as you want and in any combination as desired toward this goal of
a more focused search. After you type values in the fields, click Search. The search
query that you created by using the fields will be displayed.
You can also restrict the scope of your search to search within artifacts, remote assets
and, forums.
– Search assets by tags: Tags are words or phrases that users create and assign to
assets (using the Tag field). You can find assets by using your own tags or tags that
are created by other users. Tags are displayed in confined areas that are known as tag
292
Strategic Reuse with Asset-Based Development
clouds. You can use tags to assign meaningful labels that are more unique and
personally relevant than the predefined categories or types that an Administrator
creates for you. You can view all of the tags and information about how many assets
are using those tags across the Repository in the tag cloud, which is located on the
Search for Assets page in the Tags section as Figure 10-10 shows.
Figure 10-10 Search for assets using tags
If in Figure 10-10, you click the spring tag, you automatically see a list of all assets
included in the Rational Asset Manager Repository that have been assigned the
Spring tag.
You can view the number of assets in the Repository that share a tag by clicking the
“Show tag counts” link.
– Search assets with filters: Search filters help limit your asset search by using a
combination of community, asset type, state, categories or subcategories, or rating.
You can view filters on the Search for Assets page in the sidebar “Filter your search”
as shown in Figure 10-11 on page 294.
Chapter 10. Consume reusable assets
293
Figure 10-11 Filter your search
The filters that are displayed change dynamically depending on which assets are
displayed in the search results. As you filter your search, you can apply and remove
any combination of filters. The assets listed in the search results will appear or
disappear depending on the filters that you choose.
For example, if you look only for the assets belonging to the Implementation
community, you click the Implementation link that is under the Community section.
Then, Rational Asset Manager will automatically show you a filter with all of the assets
belonging to the Implementation community as shown in Figure 10-12.
Figure 10-12 Assets belonging to the Implementation community
294
Strategic Reuse with Asset-Based Development
As you can see Figure 10-12 on page 294, the “Filter your search” section has
changed automatically and it has been adjusted dynamically to reflect the filters that
can be applied to the assets displayed in the search results (asset types, categories
assigned, and states).
You click X to remove the filters in any order.
You can also subscribe to your favorite queries using the Subscriptions section of the
Rational Asset Manager Web interface as shown in Figure 10-13.
Figure 10-13 Subscriptions to searches
– Search feed: This option creates an RSS (Really Simple Syndication) subscription to
the search query. RSS is a family of Web feed formats used to publish frequently
updated content, such as blog entries, news headlines, or podcasts. RSS makes it
possible for people to keep up with their favorite Web sites in an automated manner
that is easier than checking the Web sites manually. RSS content can be read using
software called a “feed reader” or an “aggregator.” The user subscribes to a feed by
entering the feed’s link into the reader or by clicking an RSS icon in a browser that
initiates the subscription process. The reader checks the user’s subscribed feeds
regularly for new content, downloading any updates that it finds.
– Subscribe to this search: You will receive an e-mail notification when any asset that
meets the search criteria that you have selected is changed or updated. You can
configure the name of this subscription and the frequency of the e-mails you will
receive (daily, weekly, or monthly).
– Add search engine to browser: This option installs a search engine to your browser
so that you can search within the asset Repository from any open browser window
using browser shortcuts.
– You can also add the bookmark of the Web page displaying the search query results
that you have selected using your Internet browser menu and come back to it later.
Tip: You can also make subscriptions (RSS feeds and e-mail notifications) to individual
assets to receive notifications when the individual asset is changed or updated.
10.3.2 Use asset
After the developers learned how to search for open source framework assets within the
Rational Asset Manager Repository, they started to use open source framework assets to
build their code components.
Deb Devak, a developer who planned to build a Java component for the ZYX Electronics’
Account application, needed to use the Spring open source framework to build it. Deb logged
into the Rational Asset Manager Web application and looked for the Spring open source code
following the instructions that Deon had provided:
1. Deb selected the Search for Assets tab and clicked the spring tag that was already
associated to the Spring open source assets.
Chapter 10. Consume reusable assets
295
2. The Search Results list showed that there were two versions of the Spring Framework
already loaded into the Rational Asset Manager Repository as shown in Figure 10-14.
Figure 10-14 Search Results list for the Spring open source framework
3. Because Deb wanted to be informed of changes in the Spring framework, she clicked the
Subscribe to this search link in the Subscriptions section to receive an e-mail notification
when the Spring asset was changed or updated.
4. Deb was reviewing both versions of the Spring Framework plug-in, navigating through the
General Details and Content tabs. Based on this initial review, she decided to use the
Spring Framework Version 2.1 asset to build her Java component. To download it, she
clicked the Spring Framework Version 2.1 link, and clicked Download as shown in
Figure 10-15 on page 297.
296
Strategic Reuse with Asset-Based Development
Figure 10-15 Download Spring open source framework
5. Rational Asset Manager processed her request and checked if Deb had permissions to
download the asset. Because she was a developer with consumer permissions in the
Implementation community, she was authorized to download the asset to her local disk.
Note: If another user without download permissions had wanted to download the asset,
the user must request access to the asset by clicking the Request permission button.
This request is then sent directly to the Community Administrator.
10.3.3 Provide asset feedback
Deb started to use the Spring Framework to build her Java component, but she noticed that
the reference documentation associated to the Spring version she was using had not been
updated to Version 2.1, and it still had references to Version 2.0.6. To notify the owner of the
asset (Al Aarkashan) and other developers who were using the same version of the
framework of this problem, she selected the Forums functionality available in Rational Asset
Manager. To enter a new comment into the forum associated to the Spring Version 2.1
framework, Deb selected the Forums tab and followed these steps:
a. Deb clicked the General discussion link and clicked New topic to start the
discussion. She introduced a new forum topic, which warned that the documentation
had not been updated to the new version, and she clicked Create to make the
comment visible to other users as shown in Figure 10-16 on page 298.
Chapter 10. Consume reusable assets
297
Figure 10-16 Introduce a new forum topic
b. Al Aarkashan, the Asset Owner, saw that there was a new forum topic, checked it, and
modified the asset to fix the documentation problem. When he finished the
modification, he replied to the obsolete documentation reference topic saying that the
problem had already been solved as shown in Figure 10-17.
Figure 10-17 Respond to Forum Topic
298
Strategic Reuse with Asset-Based Development
c. Because Deb was subscribed to the Spring search list, she automatically received an
e-mail when Al updated the documentation, and she went to Rational Asset Manager
to download the updates.
Note: Optionally, Forum Topics can be automatically synchronized with Rational
ClearQuest record types. Refer to Appendix A, “Rational Asset Manager: Installation and
administration” on page 637 for additional information.
When Deb finished building her code component, she submitted the new version to the
Rational Asset Manager Repository, and she created a “Uses open source framework”
relationship between this component and the Spring asset that she used to build it as shown
in Figure 10-18 and Figure 10-19 on page 300.
Figure 10-18 Search for Spring assets to establish a relationship
Chapter 10. Consume reusable assets
299
Figure 10-19 Establish a relationship between component and framework assets
Establishing relationships between assets helps Rational Asset Manager users to analyze the
impact of changes in other assets. For example, if Al Aarkashan had wanted to update the
Repository with a new version of the Spring framework asset, he might have used the
relationships that developers established with this asset to know how many components
might be impacted by a change in this asset. To analyze this impact, he just had to go to
Rational Asset Manager to see the details of the Spring Framework version that he wanted to
change (for example, Spring Framework Version 2.1), and the Related Assets section of the
General tab shows all assets that had used this version of the framework to build their
applications as shown in Figure 10-20.
Figure 10-20 Components using the Spring Framework
During the meeting that developers had with Deon to learn how to search for assets, Deon
told to them that he wanted to have their input (using the Ratings functionality of Rational
Asset Manager) to record which assets were most valuable for developers. So, Deb searched
for the Spring asset Version 2.1 that she used to build her Java component and selected the
Ratings tab to rate this asset. She clicked the Leave Feedback link and left her feedback as
shown in Figure 10-21 on page 301.
300
Strategic Reuse with Asset-Based Development
Figure 10-21 Ratings: Leave Feedback
This feedback can be used later by Deon to generate metrics, as well as by other users of the
asset as they determine whether they will use the asset. We look further into the rating,
metrics, and evaluation topics in Chapter 15, “Managing service assets” on page 425.
Chapter 10. Consume reusable assets
301
302
Strategic Reuse with Asset-Based Development
11
Chapter 11.
Manage reusable assets
In this chapter, we look at how we manage reusable assets. This discussion includes a
further discussion of best practices in managing reusable assets and how ZYX Electronics
managed reusable assets and leveraged Rational Asset Manager to help manage reusable
assets.
© Copyright IBM Corp. 2008. All rights reserved.
303
11.1 Introduction
As we learn how asset management plays a role in our asset reuse initiative, we need to keep
the following definitions in mind:
Governance: The ongoing, recursive process of establishing decision rights (chains of
responsibility, authority, and communication), measurements, policies, standards, and
control mechanisms to enable people to carry out their roles and responsibilities
Governance Solution: A work product of Governance; a set of governance decisions
applicable to a specific context and scope of activities
Management: The activities of goal setting, decision making, oversight, enablement, and
guidance that implement a governance solution in pursuit of a set of defined objectives
In this chapter, we focus on the management aspect of assets and reuse. As per the previous
definition, we want to make sure that goals have been set, decision making occurs,
enablement is in place, and there is oversight in place - all while reaching the objectives of the
organization.
Also, as shown in Figure 11-1, we see that management is not an event that occurs in
isolation. Management plays a key role in supporting asset production and asset
consumption.
Figure 11-1 Role of asset management in overall asset workflows
Without having asset management in place, the integration, steps, and roles as found in
Figure 11-2 on page 305 likely fall into chaos.
304
Strategic Reuse with Asset-Based Development
Figure 11-2 Integration between usage and manufacturing cycles
11.2 Asset management
As described in Chapter 5, “Asset-Based Development and Asset Governance Rational
Method Composer plug-ins” on page 61, the plug-in provides the management process as a
capability pattern. Figure 11-3 shows its workflow and the tasks composing it.
Figure 11-3 Workflow of management process
Chapter 11. Manage reusable assets
305
11.2.1 Asset management roles
This chapter describes the tasks involved in managing assets mainly from the views of the
following three roles:
1. Asset Reviewer: The Repository notifies the Asset Reviewer when an asset is submitted
for review. The Asset Reviewer selects the asset to review and evaluates the asset,
prepares review material, and then votes to accept or reject the asset.
This role mainly performs the Review and Test Asset task.
2. Asset Review Board: The Review Board is responsible for specifying review processes. It
works with the Community Administrator to get the assets into the Repository. The Review
Board identifies potential reviewers and customizes the review process in the Repository
to add the reviewers. The Review Board also initiates the review in the Repository,
monitors who has submitted reviews, and then evaluates the submitted reviews and casts
the final vote on an asset.
This role needs to be optional, which allows varying degrees of formality in the asset
review process.
This role mainly performs the Review and Test Asset task.
3. Repository Administrator: This role is responsible for the overall configuration of the
Asset Repository. These responsibilities include specifying:
– Server paths
– Repository license
– Application server paths
– Database configurations
– Web server path
– Web services path
– Background index process settings
– Overall performance
This role mainly performs the following tasks:
– Configure Repository
– Report on Asset
4. Community Administrator: The Community Administrator makes Reusable Assets
available to the target audience by establishing and maintaining the Asset Repository.
This responsibility can include activities, such as:
– Defining the asset types for one or more organizations
– Describing the review process for these asset types
– Capturing the taxonomy for these asset types
– Defining the roles for a particular organization
– Defining the access control and permissions for roles in that organization
The Community Administrator coordinates with the Repository Administrator as part of the
overall configuration of the Repository. This role mainly performs the following tasks:
– Publish or Deploy Asset
– Remove Asset
306
Strategic Reuse with Asset-Based Development
5. Integration Administrator: This role is responsible for integrating the Repository with
development life cycle tools, such as Source Configuration Management (SCM) tools,
change management tools, and service registries.
This role mainly performs the Configure Repository task.
11.2.2 Search asset
Figure 11-4 shows the position of this task in the workflow of the Asset-Based Development
plug-in. In this task, the Administrator of the Repository searches the asset to review. The
details of this task are explained in 10.2.2, “Search asset” on page 284 from a Asset
Consumer’s point of view. In this section, we take a moment to look at how things are different
when performing this task within Asset Management.
Ideally, this task is performed in the same manner as the steps taken by the Asset Consumer.
The only difference is the purpose behind the searching. In the case of asset management,
we look for assets for the purpose of reviewing the asset and determining if the asset needs
to be included within the Repository.
An asset Repository, such as Asset Manager, notifies a user when that user is expected to
review an asset. However, the users must still understand and have familiarity with searching
for assets. There can be cases where an asset review is started based on feedback,
discussion, or another ad hoc mechanism, and the reviewer needs to find the asset on their
own.
Figure 11-4 Search asset
11.2.3 Review and test asset
Figure 11-5 on page 308 shows the position of this task in the workflow of the Asset-Based
Development plug-in. The purpose and expected inputs and outputs defined for this task are:
Purpose: To maintain control, quality, and management of the content into the Repository
Inputs: Reusable Asset. (Optional) Asset Artifact
Outputs: Asset Review and Reusable Asset
Chapter 11. Manage reusable assets
307
Figure 11-5 Review and test asset
Assets can be used by an unspecified number of users in various contexts and environments.
Consequently, the review process needs to be able to take multiple perspectives and
requirements into account. For example, assets must be reviewed from the viewpoint of
reusability, such as:
The asset must be easy to use, customize, and apply to another context.
The asset must possess the characteristics of sound engineering: tight internal cohesion,
loose coupling with other assets, and sufficient capabilities.
The asset’s purpose and intent must be easy to understand.
Conducting fit analysis must be easy in order to be able to determine the asset’s match to
a particular context.
Several key perspectives to evaluate are (See 10.2.2, “Search asset” on page 284):
Asset’s business
Asset’s organizational fit
Asset’s process fit
Asset’s engineering fit
This task includes the following four steps:
1. Submit asset for review: The Asset Owner or Producer has completed their refinements
of the asset and now submits the asset to the review and approval process. The Asset
Owner or Producer might have suggestions of subject matter experts who can fill the role
of Reviewers.
2. Notify parties: The Repository must handle the activities of notifying the Reviewers of the
asset to be reviewed. However, in practice, the Asset Owner or the Review Board might
need to provide reminders.
3. Conduct review: There are many aspects of an asset that can be included as part of the
review, including:
– Asset name: The proposed asset name is evaluated in regard to conveying the
purpose and use of the asset.
– Classification: The classification aligns with the manner in which target Asset
Consumers will search for the asset.
308
Strategic Reuse with Asset-Based Development
– Functional compliance: The asset goes through typical functional testing, executing
test cases and using testing tools to validate the asset.
– Non-functional compliance: The asset goes through non-functional testing to verify the
asset’s performance, scalability, security, and so forth.
– Packaging: Verify that the asset contains the necessary support material, making it
easy for the Asset Consumer to use. Also, support contact information is present and
accurate, and the support team is ready to support the asset.
– Asset similarity: The asset is evaluated compared to other assets to determine if the
implementation overlaps or is similar to other assets in the Repository.
– Subject matter expert: A fit for purpose evaluation is conducted, examining if the asset
fulfills the purpose properly and aligns with the Asset Specification.
When a Reviewer completes a review, they submit the review files (if any) and cast a vote.
4. Review board vote: If the Review Board is enabled, the members of the Review Board
cast their vote on approving or rejecting the asset. If the asset is rejected, it returns to an
early submission state, such as Draft; otherwise, it transitions to another state, such as
Approved.
An asset that is Approved is made visible to the anticipated Asset Consumer audience
through the Repository. An asset can transition to other states, as well, after it has been
approved. For example, if the asset is a service, it can be published to a service registry,
which can change the state to Published.
11.2.4 Publish or deploy asset
Figure 11-6 shows the position of this task in the workflow of the Asset-Based Development
plug-in. The purpose and expected inputs and outputs defined for this task are:
Purpose: To move the asset through the life cycle to now be visible in other tools, such as
a service registry
Inputs: Reusable Asset
Outputs: Reusable Asset
Figure 11-6 Publish or deploy asset
In this task, the asset is released to the Consumer, either in the scope of the Repository or in
another tool. The target for the released asset will depend on the asset type. For example, a
Chapter 11. Manage reusable assets
309
pattern asset or code component will be released within the asset Repository. In the case of a
service asset, it is likely that the asset will be published to a service registry and Repository.
This task includes the following three steps:
1. Select approved asset in Repository: If the asset Repository is enabled, the
Administrator selects the asset to be published.
2. Select the target registry or other Repository: If the asset Repository is enabled, the
Administrator selects the target registry of the runtime type and deployable asset or other
Repository.
3. Publish the asset’s contents to the target Repository: If the target Repository is
enabled, the Administrator publish the asset’s contents to the target Repository. If not, the
Administrator publishes the asset’s contents into the target (Consumer) environment.
After the publication, the Administrator must notify the Consumer of the publication.
11.2.5 Configure Repository
Figure 11-7 shows the position of this task in the workflow of the Asset-Based Development
plug-in. The purpose and expected inputs and outputs defined for this task are:
Purpose: Provide a governed asset management environment to preserve and improve
the organization’s software related investments
Inputs: (Optional) Asset Repository and Asset Types
Outputs: Asset Repository and Asset Types
Figure 11-7 Configure Repository
In this task, the Administrator must keep the Repository well-classified and appropriately
accessible for the Consumer. The concept of this task can be applicable to the Administrator,
who has no Repository.
The two major steps of this task are access control for the asset and its classification. The
access control determines the control of the asset logistics while avoiding unauthorized
reuse, and the asset classification influences the visibility of the asset and helps to define the
metrics for the Reuse Strategy.
Chapter 8, “Configure your Asset Repository” on page 195 provided an overview of how ZYX
Electronics configured their asset Repository. If you recall from that discussion, a key concept
is that of a community. A community is a Repository structure that facilitates user interaction
with a group of related assets. Communities are formed by users, their roles, and permissions
and their assets and review processes.
310
Strategic Reuse with Asset-Based Development
This task includes the following seven steps:
1. Create category schema: The Administrator defines and creates category schema in
alignment with the organization’s Reuse Strategy. Creating a category schema often
requires visualization and socialization. To achieve stakeholder agreement, you need to
provide the stakeholders with a representation of the schema that is easy to understand
and discuss. To visualize the category schema, the Administrator might use a model, such
as a Uniform Modelling Language (UML) model, as shown in Figure 11-8.
Figure 11-8 Example of visualization for category schema
After the stakeholders have agreed upon the category schemas, the category schemas
are loaded by the Repository or Community Administrator into the Repository.
2. Specify asset types: The Administrator specifies the asset types that will be supported by
the Repository. Recall that an asset is composed of one or more artifacts. We need to
analyze how these artifacts will group into assets, and as part of the effort, specify the
name of this asset type, provide a description, detail the artifacts that comprise the asset,
and define the relationships among the asset types. Again, the use of visualization can
help both define and then socialize the resulting set of asset types.
3. Specify communities and access control: The Administrator specifies communities and
access control for the assets.
4. Specify review process: The Administrator specifies and configures the review process
for assets.
5. Configure Repository users: The Administrator defines and configures Repository
users. The users can come from existing directory services, such as Lightweight Directory
Access Protocol (LDAP).
6. Configure Repository integrations: When appropriate, the Administrator must integrate
the Repository with various tools, such as SCM tools, change management tools, service
registries, and so forth, to provide a seamless interaction for the software development
workflows.
7. Configure system timers and notifications: The Administrator defines the policy for
scheduling the types of regular events, such as a publication to the target registry, asset
subscriptions, indexing, and so on. The Repository needs to be configured to provide a
balance of optimal performance and timely updates.
11.2.6 Remove asset
Figure 11-9 on page 312 shows the position of this task in the workflow of the Asset-Based
Development plug-in. The purpose and expected inputs and outputs defined for this task are:
Purpose: Bring the asset to the end of its life cycle in the Repository
Inputs: Reusable Asset
Chapter 11. Manage reusable assets
311
Outputs: Asset Repository and Reusable Asset
Figure 11-9 Remove asset
In this task, the Administrator removes an asset from the Repository. The typical situations
where this need arises are:
Asset usage levels: The asset is dormant, and it has few searches, few browses, few
downloads, little feedback, and so forth.
Funding termination: The sponsor changes or terminates funding support, perhaps due
to business prioritization.
Need for solution diminishes: The problem either goes away, or a new solution is
available, or the level of effort to maintain this asset becomes prohibitive.
There are three levels of removing an asset from a Repository. These levels include retiring
an asset, archiving an asset, and deleting an asset:
Retire asset
This task is performed by an Administrator who sets the state of the
asset to retired. The effect of this task is the asset is no longer visible
to the Asset Consumers, but it is still visible to the Asset Owner and
the Administrator.
Archive asset
This task is performed by an Administrator who sets the state of the
asset to archived. The effect of this task is that the asset is no longer
visible to Asset Consumers or to the Asset Owner, but it is still visible
to the Administrator.
Delete asset
This task is performed by the Asset Owner or the Administrator. The
effect of this task is the asset is removed from the Repository.
Certainly, this action needs to be handled with care.
This task includes the following four steps:
1. Determine need to remove asset: An interested party brings forward concerns about an
asset. Examining the considerations for removing an asset, an Administrator and Asset
Owner verify the concerns and evaluate the need to remove the asset.
2. Conduct impact analysis: The Administrator conducts an impact analysis where current
Asset Consumers are evaluated and the impact to their projects is understood.
The impact analysis must also address asset relationships, including the related assets’
Asset Owners and Producers, as well as other technical dependencies. The Asset
Owners and Producers of related assets might need to participate in the planning
depending on the nature of the problem and the nature of the asset relationship.
The Administrator and the Asset Owner must communicate with the Managers to
understand the business impact of removing the asset.
312
Strategic Reuse with Asset-Based Development
A case must be prepared to determine the level of removing the asset. Enough insight
must be collected to answer the question, “Does the asset need to be retired, archived, or
deleted?”
3. Obtain approval to remove: The Administrator obtains approvals from Managers and
other stakeholders to remove the asset.
4. Remove the asset: The Administrator removes the asset from the Repository according
to the appropriate level.
11.2.7 Report on asset
Figure 11-10 shows the position of this task in the workflow of the Asset-Based Development
plug-in. The purpose and expected inputs and outputs defined for this task are:
Purpose: Deliver activity measurements to managers for governance and management
functions.
Inputs: Asset Repository. (Optional) Asset Artifact and Reusable Asset
Outputs: Asset Report
Figure 11-10 Report on asset
As discussed in Chapter 6, “Value, impact, and return on investment” on page 103, the
gathering and analyzing of asset metrics is a key activity as you decide where to make
investments.
In this task, the Administrator collects reports from various sources, such as:
Asset Consumers: Asset Consumer metrics generally include qualitative metrics, such
as reusability ratings (4 out of 5 stars) or text feedback in the form of comments and
discussions. Typically, these metrics are stored in the Repository.
Asset Owners, Producers, and Reviewers: Asset Owners, Producers, and Reviewers
tend to create asset-level metrics. These asset-level metrics include the anticipated level
of effort for an Asset Consumer to use the asset, the level of effort to create a given
version of an asset, and so forth. The metrics also include size, such as the number of
bytes, lines of code, or number of components. Typically, these metrics are stored with the
asset in the Repository.
Repository: Repository metrics are largely quantitative. These metrics the number of
downloads for a given asset version, the number of searches and kinds of searches, and
the number of browses from searches, as well as information about which Asset
Consumers conducted certain downloads. Other metrics can be Repository activity over a
period of time, such as the number of Repository accesses, asset submissions, and so
Chapter 11. Manage reusable assets
313
forth over a certain period of time. The Repository can also track the number of problems
or defects associated with an asset.
Derived for Managers: In general, repositories are not tracking the cost side of asset
development. This cost is typically tracked in project management and financial reporting
tools. Bringing together the metrics from Asset Consumers, Asset Owners, Producers,
Reviewers, and the Repository with costing metrics gives you a foundation for derived
metrics. Several of these metrics include project reuse percentage, project productivity
gains, and return on investment.
This task includes the following three steps:
1. Practitioners provide values: As described earlier, the Asset Owner, Reviewer, and
Consumer provide both qualitative and quantitative values for assets.
2. Repository and assets used: Managers, Administrators, Asset Owners, Reviewers, and
Consumers interact with the Repository and the assets, therefore, creating the basis for
generating reports.
3. Generate report: Reports can be generated graphically or textually. The metrics can be
exported from the Repository into reporting tools, or the Repository can render the reports.
Managers often require reports on a periodic basis, which generally means repositories
need a way to run reporting jobs and send them to the appropriate stakeholders.
Repositories must be integrated with portfolio and project management tools to aid in the
generation of derived metrics.
11.3 Migration of existing assets
In contrast to the ZYX Electronics case study, certain organizations already have a reuse
initiative in place. In these cases, there can be additional work and planning needed to
migrate existing assets into a new Repository. In this section, we briefly look at several of the
considerations to remember when planning this type of a migration.
11.3.1 Migration strategy
Next, we discuss a migration strategy.
Prerequisites
Before starting the migration of existing assets, it is imperative that you have a good
understanding (and documentation) of the existing Repository, its user community, business
purpose, general structure and schema, size, and types of assets.
Considerations
Make sure that you:
Ensure that you have the right resources to define the migration strategy:
– Do they have the authority to speak for the community, database “owners”, and so
forth?
– What is their internal review and approval process for this migration? Who are the
ultimate owners and decision makers?
– Is there an internal review process in place and documented for this community or
area?
314
Strategic Reuse with Asset-Based Development
High-level migration options (define and document):
– Will you migrate the entire contents? If not, what is the selection criteria for migration
(only high value, reusable items, or all items that have been used within a specific time
frame, for example, the last 24 months). This criteria must be documented and
distributed to the users in the community.
– What is the time frame that you are considering for migration? Do you have timing
restrictions? Are you sunsetting the existing Repository? What is your goal: all at once,
a complete migration by a specific date, or a certain number of assets per week? If you
are staging the migration, will the contents be migrated by community or type of asset?
– Is there a cut-over period? If so, how long?
– What resources are required for your strategy?
Measures of success:
– Who makes the decisions on these questions?
– Who will ensure that the decisions are documented and communicated?
Templates
Ensure that you have a:
Migration questionnaire to assist the teams in deciding on a migration strategy
High-level Migration Strategy document
High-level Communication Plan (which can be included in the Migration Strategy
document)
Deliverables
You need to produce a:
High-level Migration Strategy document
High-level Communication Plan
11.3.2 Asset cleansing, defining, and mapping
After a migration strategy has been defined and communicated, look at the assets
themselves. The migration provides an opportunity to ensure that the new Repository
contains those assets that provide the most value to the organization. As you work through
the assets, you also test the structure that has been defined for the new community.
Prerequisites
You must have Asset Taxonomy documentation.
Considerations
The steps and considerations to remember during this task include:
Create a high-level Architectural Design document
If all assets are not being migrated:
– Determine the criteria for migrating assets. Examples of criteria include:
•
Only include assets that have been used within a certain time frame (that is, two
months)
•
Only include high value assets and so forth.
Chapter 11. Manage reusable assets
315
– Determine how assets that are not being migrated will be handled:
•
Will remaining assets be “archived” somehow or just deleted?
•
Is there a notification process documented for assets that are not moving?
Map your assets to your organization’s asset taxonomy:
– Where there is no match:
•
Request additional asset types
•
Reevaluate the asset
Templates
You must have an Asset Mapping spreadsheet.
Deliverables
Ensure that you produce a:
Completed Asset Mapping spreadsheet
Architectural Design document
11.3.3 Mapping and uploading
At this point, we look at the work involved in the actual migration. You must decide whether to
use automation to migrate the assets, what to do with assets that are not migrated, how to
test, and how to confirm the results. In cases where a significant number of assets need to be
migrated, consider using the Asset Manager application programming interfaces (APIs) to
create an automated solution.
Prerequisites
You need the completed Asset Mapping spreadsheet and Architectural Design document.
Considerations
Consider:
Will you migrate data manually or via automation using the provided Asset Manager APIs?
You need to define the resources and responsibilities for one or both options.
For batch upload, map existing metadata to asset metadata.
Determine if an adapter is required to handle additional existing storage types that are not
handled as part of the utility. Document the requirements and determine if adapters are
available from other sources that can be used as a starting point.
Define and document the batch migration process:
– Selection criteria, time lines, roles, and responsibilities
– Approval process
– Funding and resources identified and in place
– Communication plan to stakeholders that outlines the process and time line
– Define initial or test case for initial batch load (including success criteria)
– Testing process
– Success criteria defined and documented
– Define the phases for the migration with a batch utility following a successful pilot
316
Strategic Reuse with Asset-Based Development
Templates
Use a:
Communication plan
Detailed Migration plan
Deliverables
The deliverables need to be a:
Communication plan
Detailed Migration plan (including a test migration case scenario)
At this point, you must also consider whether it makes sense to first run a test migration
before proceeding with a full migration. Steps and considerations for these migrations
include:
Initial test case migration:
– Test case migration is documented and resources are in place
– Run test
– Success criteria met
– Document results and lessons learned
– Deliverables:
Test plan
Full migration:
– Lessons Learned from initial migration
– Revisit Architecture Design Document (if required)
– Revisit and revise Detailed Migration plan (if required)
For example, did the initial batch migration results require changes to your overall
migration plan as far as scope, rollout phases, timing, and so forth?
– Communicate changes to constituents
– Deliverables:
•
Updated Migration plan (if required)
•
Updated Communication plan (if required)
11.4 ZYX Electronics: Manage reusable assets
This section describes how ZYX Electronics implements managing reusable artifacts by using
Rational Asset Manager.
Chapter 11. Manage reusable assets
317
We discuss how ZYX Electronics:
Creates a new customized review process using Rational ClearQuest to involve the “Risk,
Security, Audit, and Compliance” Department in the review of open source frameworks
Uses Rational ClearQuest Web client to review legal license terms and conditions and to
approve the use of open source frameworks submitted to Rational Asset Manager
Uses Rational Asset Manager to remove or retire obsolete assets from the Repository
Uses Rational Asset Manager Repository statistical capabilities to generate reports and
graphs to evaluate Repository usage
11.4.1 Search asset
Deon Adminio, the Rational Asset Manager Repository Administrator, explained to ZYX
Electronics’ developers how to search for assets in Rational Asset Manager. Refer to 10.2.2,
“Search asset” on page 284 for more information.
11.4.2 Review and test asset
To manage licensing issues, ZYX Electronics had to implement a mechanism to involve the
Risk, Security, Audit, and Compliance Department in the review process for open source
frameworks. Richard Compliton, the Director of the Risk, Security, Audit, and Compliance
Department, had to be included in the review process, and without his initial authorization,
open source frameworks cannot be approved for use within ZYX Electronics.
This department was already using Rational ClearQuest to manage and control
authorizations for other departments, so during their conversations with Duncan Munchkin,
the Development Manager, they decided that the best option to involve them in the review of
open source frameworks was to implement a customized review process with Rational
ClearQuest via its integration with Rational Asset Manager.
Rational ClearQuest is a change management tool that helps development teams to manage
software life cycles more effectively. With Rational ClearQuest, users can define automated
workflows to control and enforce development processes, helping them to improve team
communication and coordination.
Duncan, Richard, and Deon agreed to use Rational ClearQuest to create a simple approval
workflow called CQApprovalProcess where the first approval comes from the Risk, Security,
Audit, and Compliance Department. This new process is integrated with the Rational Asset
Manager review process workflow.
A.3.2, “Integrating Rational Asset Manager with Rational ClearQuest” on page 665 describes
in detail how you can install, configure, and create the review process shown in Figure 11-11
on page 319 using Rational ClearQuest Designer. In addition, A.3.2, “Integrating Rational
Asset Manager with Rational ClearQuest” on page 665 details how you can associate this
review process to open source frameworks (Framework asset types whose Framework Type
category value is Open source) that were created in the Rational Asset Manager
Implementation community.
318
Strategic Reuse with Asset-Based Development
Figure 11-11 Rational ClearQuest customized review process
When a new asset is submitted into Rational Asset Manager and if it has been configured to
follow a customized Rational ClearQuest review process, it will automatically create a new
review process request in ClearQuest that will go to the first state configured in the Submit
action. At this point, the review process passes the control to Rational ClearQuest, so
reviewers must use the Rational ClearQuest interface to change the states of the review
process (represented on the right of Figure 11-12).
Figure 11-12 Synchronization of Rational Asset Manager and Rational ClearQuest states
Chapter 11. Manage reusable assets
319
When the Community Administrator configures the synchronization between both review
processes, the Community Administrator must map the approved and rejected states of the
review process in Rational Asset Manager and ClearQuest as shown in Table 11-1.
Table 11-1 Mapping of Rational Asset Manager and Rational ClearQuest states
State
Rational Asset Manager
Rational ClearQuest
Approved (green color)
Approved
Approve
Rejected (red color)
Draft
Rejected
This way, when the Rational ClearQuest review process request reaches the Approved or
Rejected states, it will automatically move the asset state in Rational Asset Manager to the
corresponding state.
After Deon configured the integration between the Rational Asset Manager and the Rational
ClearQuest review processes following the previous guidelines, Al Aarkashan (the Architect
at ZYX Electronics) used the Ant open source framework to test whether the review process
just described had been configured correctly. Al checked the submission and approval
process in this manner:
1. Al submitted the Ant Framework (Version 1.7.0) to the Implementation community as a
Framework asset type with Framework Type category value equal to “Open source” and
submitted it for review.
2. Richard Compliton, the Director of the Risk, Security, Audit, and Compliance Department,
logged in to the Rational ClearQuest Web interface and verified that there was a new
review process request created to review the new Ant open source framework. The new
Ant open source framework was created automatically by Rational Asset Manager when
Al submitted the Ant Framework asset for review, as shown in Figure 11-13.
Figure 11-13 Rational ClearQuest query with Rational Asset Manager assets
3. So, Richard opened the Ant Framework Rational ClearQuest request to see the details as
Figure 11-14 on page 321 shows (Rational Asset Manager automatically synchronized the
Headline field with the asset name and the Description field with the URL to access the
asset details using the Rational Asset Manager Web interface).
320
Strategic Reuse with Asset-Based Development
Figure 11-14 Ant Framework Rational ClearQuest request details
4. Richard Compliton clicked the URL link in the Description Field to see the content of the
asset. Richard selected the Content tab to see the terms and conditions of the open
source framework that were included in the license.txt file as shown in Figure 11-15.
Figure 11-15 Content details of the Ant Framework asset
5. Richard opened the license.txt file from the Web interface to check the special terms and
conditions of the open source framework. Because Richard needed to have a more
detailed review of its content, he changed the state of the review process to Legal (using
the ClearQuest action change State → LegalScanRequired and clicked Save) using the
Rational ClearQuest Web interface as shown in Figure 11-16 on page 322.
Chapter 11. Manage reusable assets
321
Figure 11-16 Changing the state of the Rational ClearQuest review process request to Legal
The state change moved the ClearQuest review process request to the Legal state as
shown in Figure 11-17. While the review process request was in this Legal state, no other
users can change the state. Only Richard Compliton has permissions to change the state
to Review Board state and continue with the review process.
Figure 11-17 Review process has moved to the Legal state
322
Strategic Reuse with Asset-Based Development
If Al had wanted to know the review process state using Rational Asset Manager interface
(selecting the Review Process tab), Al can see that the Ant Framework was still in the
Review Board state. There is a special link to go to directly to Rational ClearQuest to see
the request details. The Review History Link shows that the Rational ClearQuest-driven
review process was still in progress as shown in Figure 11-18.
Figure 11-18 Review process state in Rational Asset Manager
6. When Richard Compliton finished and accepted the review process of the special legal
terms and conditions of the open source license, Richard logs in to Rational ClearQuest
Web to complete the legal scan process and moved the review process request to the
ReviewBoard state (Change State → Legal Scan Completed).
7. From this state, Patricia Moon, the project manager, who had permissions to move the
Rational ClearQuest request to other states, logs in to the Rational ClearQuest Web
interface. Patricia did not want developers to use this Ant Framework, because ZYX
Electronics had already developed an internal application to provide similar functionality,
so Patricia changed the state to Rejected (Change State → Reject).
8. The configuration between Rational Asset Manager and Rational ClearQuest had been
set up so that the Rejected state of the Rational ClearQuest request was mapped to the
Rejected state of Rational Asset Manager. Therefore, the synchronization between both
tools automatically moved the state of the Ant Framework to the Draft state in Rational
Asset Manager. Figure 11-19 on page 324 shows how the states were synchronized
between both tools.
Chapter 11. Manage reusable assets
323
Figure 11-19 Synchronization of Rational Asset Manager and Rational ClearQuest states
In the ZYX Electronics example, because Patricia had rejected the review process and
made a transition in Rational ClearQuest to the Rejected state, this change was
automatically propagated to Rational Asset Manager moving the asset state to Draft.
11.4.3 Publish or deploy asset
Because the assets produced and consumed by ZYX Electronics during this first phase were
only open source frameworks and code components that cannot be deployed as services to
the WebSphere Service Registry and Repository, we will not cover the Publish or Deploy
Asset task in this section for the ZYX Electronics case study. We will discuss this task in
Part 3, “Service Assets in an SOA” on page 333 of this book when we discuss producing
services.
11.4.4 Configure Repository
To read details about how ZYX Electronics configured the Rational Asset Manager
Repository, go to Chapter 8, “Configure your Asset Repository” on page 195.
11.4.5 Remove asset
Two months after starting to deploy and use Rational Asset Manager at ZYX Electronics,
Deon Adminio, the Repository Administrator, received various requests from users asking
how they can delete an asset that was not being used or was obsolete.
According to the asset life cycle described in Figure 11-20 on page 325, Deon explained to
them that they had two alternatives with Rational Asset Manager: retire or delete the assets.
324
Strategic Reuse with Asset-Based Development
Figure 11-20 Asset life cycle
If the Asset Owner and Administrators wanted to maintain the asset in the Repository but
have the asset available only to the Asset Owner or to Administrators and not the rest of the
users, they must ask the Repository Administrator to change the asset to the Retired state.
The Repository Administrator was the only role in Rational Asset Manager with permissions
to change any asset to this state. The content of the asset remains available in the Repository
to the Asset Owners or Administrators, but the content of the asset cannot be downloaded
unless the state was changed again to the Draft state. To move an asset to the Retired state,
Deon just had to log in as a Repository Administrator and select the Retire link that is
available in the Asset Detail Tools section as shown in Figure 11-21.
Figure 11-21 Retire an existing asset
Chapter 11. Manage reusable assets
325
If the users wanted to permanently delete the asset from the Rational Asset Manager
Repository, they needed to ask the Repository Administrator or the Asset Owner, who are the
only roles with Delete permissions, to use the Delete link. After the asset is deleted, it is no
longer available in the Repository. To delete an asset, the Asset Owner just had to log in to
Rational Asset Manager and select the Delete link that is available in the Asset Detail Tools
Section as shown in Figure 11-22.
Figure 11-22 Delete assets
11.4.6 Report on asset
Three months after starting to deploy Rational Asset Manager at ZYX Electronics, Duncan
Munchkin, Development Manager at ZYX Electronics, was having a meeting with Victoria
Prezzio (Vice-President of Development at ZYX Electronics), Chuck T. Offilgy (Chief
Technology Officer for ZYX Electronics), Cid I. Oreo (Chief Information Officer for ZYX
Electronics), and Chris E. Oshman (Chief Executive Officer for ZYX Electronics). Duncan had
to present the results and benefits achieved by ZYX Electronics using Rational Asset
Manager. Duncan knew from the comments received from developers that they were
extremely satisfied with the tool, and it had helped them save time looking for specific assets
in a centralized Repository. In the past, the developers spent too much time going to the
Internet to look for information or calling other colleagues to learn where the code was.
Architects and project managers were also extremely very optimistic with the tool, because
now with Rational Asset Manager, they had a way to know the relationships between assets
and evaluate the impact that a change in one asset can have in other related assets. Al, the
architect, also found it very useful to know which developers were using his frameworks and
he planned specific training for the most frequently used frameworks.
But because Duncan had to prepare a presentation for the meeting, Duncan thought that it
might be a good idea to use the reporting and metrics capabilities included in Rational Asset
Manager.
Rational Asset Manager users can access different reports about the activity of a specific
asset, but Deon wanted to have global metrics and reports to evaluate Repository usage. So
he logged in to Rational Asset Manager as a Repository Administrator. Next, he went to the
326
Strategic Reuse with Asset-Based Development
Administrator tab to have access to the global metrics available in the Repository Statistics
Section as shown in Figure 11-23.
Figure 11-23 Repository Statistics list
Figure 11-23 represents the list of the reports that can be generated. Deon can select the
period of time to use as the basis for the report.
To generate the reports, Deon clicked the link for the report that he wanted and the report
was automatically generated. This is a list and examples of the reports Deon generated:
Repository Contents: This report is used to generate graphs and statistics about assets.
It shows the number of assets by community, type, and state as shown in Figure 11-24.
Figure 11-24 Report example showing the number of assets by type and state
Most of the asset types generated by Rational Asset Manager users were frameworks,
and all of the assets were already approved except one asset that was still pending
Chapter 11. Manage reusable assets
327
review. Other asset types generated by developers were code components that reused
the open source frameworks to build the code.
Important: This report is not affected by the selected date range, because it shows the
current distribution of assets in the Repository.
Asset Activity: This report is used to generate statistics about the number of times that
any asset in the Repository had been downloaded and subscribed to as shown in
Figure 11-25.
Figure 11-25 Asset Repository activity report
The latest Version 2.1 of the Spring Framework was the asset that was most used by the
developers, because it was the first in the list with the maximum number of downloads.
User Activity: This report is used to show how many licenses have been acquired by
each user as shown in Figure 11-26 on page 329.
328
Strategic Reuse with Asset-Based Development
Figure 11-26 User activity report
Al Aarkashan, the architect responsible for loading all Java open source frameworks, was
the person most active in using Rational Asset Manager.
Search History: This report is used to show the most popular search strings used, listed
in order of popularity as shown in Figure 11-27.
Figure 11-27 Search history report
Because all open source frameworks and code components were stored in the
Implementation community, the “Community: Implementation” search string was the
Chapter 11. Manage reusable assets
329
search pattern most often used by the Repository users (in order to get a list of all assets
belonging to that community). The “Spring” framework, which was the second most
common search in the list, was the open source framework most requested by
developers.
Activity Audit: This report is used to show how many times various actions had been
performed over a period of time as shown in Figure 11-28. Deon selected various actions
to generate the report and the starting and end dates for each audit.
Figure 11-28 Activity audit report
The Spring Framework with 5 starts was one of the highest-rated assets by the Rational
Asset Manager users. Other open source frameworks with high ratings (5 stars) were the
Struts and Hibernate Java frameworks, and also the OpenCobol framework to compile
COBOL code.
So, Deon just had to copy and paste each one of the previous graphs into his presentation to
show his managers the usage of the Rational Asset Manager Repository during the last three
months.
Deon also exported and downloaded each report as a comma-separated value (CSV) text file
and included these files in the documentation to send for the meeting. Providing CSV files to
the management team allows them to create other reports and graphs driven by the audit
report data.
With all of this material and the feedback received from the users, Deon was able to make a
magnificent presentation and was congratulated by his managers for the great work.
330
Strategic Reuse with Asset-Based Development
11.4.7 Conclusions and future plans at ZYX Electronics
This first implementation of Rational Asset Manager to produce, consume, and manage open
source frameworks and code components had positive economical results to ZYX Electronics
and demonstrated the high potential benefits of reusing software assets.
With only three months and a small set of assets loaded into the Rational Asset Manager
Repository, it is difficult to perform calculations and give an exact figure for Return on
Investment (ROI). But there are real industrial experiences, similar to the ZYX Electronics
case study reusing open source frameworks, that can help us to deduce that its Reuse
Strategy can bring positive economical and technical benefits to ZYX Electronics.
In particular, there is a paper published by the IEEE, Conventional and Open Source
Software Reuse at Orbotech - an Industrial Experience, that explains the experience and
results obtained by an Israeli systems development company reusing open source software
over a four year period. The paper includes real-world calculations comparing the
development effort of building a systematic reuse approach against the effort of developing
the same functionality in past projects without any reuse at all. The paper compares these
efforts in two components, and the results show that savings might be between 45% to 54%,
representing a total savings equal to nine person years. The paper also provides numbers
about the additional cost of building reusable assets that it is important to mention:
Developing a Black box reusable component costs 160-250% of non-reusable (ad hoc
development) software.
Mining the existing software doubles the effort required for asset definition.
Integration of a Black box reusable component costs 1-3% of ad hoc development.
Use of a development tool (rather than an application function) costs up to 15% of ad hoc
development.
But in spite of these additional costs, the paper clearly demonstrates that the software reuse
approach followed by this company contributed not only to cost reduction but also in the
developer’s satisfaction. In particular, when software reuse is based on the adaptation of an
open source framework, the savings begin immediately (which is no wonder, because there is
hardly any development, only search, evaluation, and adaptation efforts).
With a successful reuse pilot project, as outlined by ZYX’s Reuse Strategy, the following
benefits can be derived, which are in-line with management expectations (described in 2.4.3,
“Benefits” on page 30):
Reduce the costs of new application development and existing application maintenance
significantly through the reuse of existing open source frameworks and code components
instead of writing from scratch.
Develop a central Repository of searchable software assets (Rational Asset Manager)
reducing the time to locate and reuse assets in turn helping to reduce the cost of
implementing new application functionalities.
Increase standardization in development providing a more consistent use of open source
frameworks.
Increase application dependability and quality, because open source frameworks and
components to be used had been proven and validated for technical experts.
Focus on leveraging individual expertise by bringing the experts together to harvest the
reusable assets in their realm of knowledge.
Reduce development time and bring applications to market earlier to increase revenue to
the company.
Chapter 11. Manage reusable assets
331
Reduce the time necessary to reuse open source frameworks and components from
project to project, therefore, being capable of project estimates with greater accuracy.
And the Rational Asset Manager implementation was possible without modifying any
development processes already used in ZYX Electronics. The strategy followed to start
producing open source frameworks and code components as reusable assets helped other
departments to maintain their development processes and way of work, while starting to
integrate several of these reusable assets.
Benefits experienced by the developers (they were the main consumers of the produced
assets) were:
They reduced the time spent looking for information and new versions of open source
frameworks.
Several of the first reusable assets loaded into the Rational Asset Manager Repository
implemented tedious and marginal functions that they had implemented by themselves, so
they were happy to eliminate these tasks and use existing components instead.
Several of the new open source framework assets loaded into the Repository introduced
new technology new to them, so they had a change to use state-of-the-art technologies
that they might not have brought into the project on their own.
They had an easy way to look for the technical expert with deep knowledge of the asset
produced (they just had to look for the Asset Owner) in order to ask that person technical
questions about how to use it.
With the subscription mechanism of Rational Asset Manager, they were automatically
informed by e-mail when a new version of the asset was published into the Repository.
Nevertheless, these benefits were not possible without management funding support and the
commitment of ZYX Electronics’ directors, as well as developer support for the reuse of open
source frameworks and components.
Involving developers in this Reuse Strategy was to key to the successful deployment of a
central Repository. Their involvement also resulted in a configuration suited specifically to
their terminology and needs.
Thanks to benefits obtained reusing development assets and the management commitment
to software reuse, several new asset types were candidates to include in Rational Asset
Manager. Following the incremental adoption of reuse that ZYX Electronics had selected to
follow, the next step for the deployment of Rational Asset Manager at ZYX Electronics was to
include new service asset types and other WebSphere tools to help to transition to a
service-oriented architecture (SOA) approach, where service reuse was key. You will see this
progression in Part 3, “Service Assets in an SOA” on page 333 of this book.
332
Strategic Reuse with Asset-Based Development
Part 3
Part
3
Service Assets in an
SOA
In this part of the book, we look into the details of producing, consuming, and managing
services, which are a key form of reusable assets in a service-oriented architecture (SOA).
Part 1:
Introduction
Part 2:
Reusable Assets
•Introduction to
Asset-Based
Development
•Adopting
Asset-Based
Development
•Process and
Tooling
•Configuring
Asset
Management
•Case Study
Overview
•Produce,
Consume, and
Manage Assets
•Impact and ROI
Part 3:
Services
•Services as Assets
•Produce, Consume,
and Manage Service
Assets
Appendixes
•Rational Asset
Manager
Installation and
Administration
•Process
Integration
Part 4:
Patterns
•Patterns as Assets
•Produce, Consume,
and Manage Pattern
Assets
Figure P-3 An overview of the structure of the book
© Copyright IBM Corp. 2008. All rights reserved.
333
334
Strategic Reuse with Asset-Based Development
12
Chapter 12.
Introduction to service assets
This part of the book focuses on services in a service-oriented architecture (SOA) from an
Asset-Based Development perspective.
This chapter provides an introduction to services and related topics that set the stage for the
rest of the chapters in this part of the book. This chapter covers the following topics:
Setting the context for Part 3, “Service Assets in an SOA” on page 333
SOA, services, and assets
What is a service
Web services and SOA
Types of service assets
Roles involved in service asset development
Service-oriented modeling and architecture
IBM products for SOA implementation
© Copyright IBM Corp. 2008. All rights reserved.
335
12.1 Setting the context for Part 3
Next, we discuss how Part 3, “Service Assets in an SOA” on page 333 integrates with the
other parts of this book.
12.1.1 How does Part 3 relate to the rest of the book
Part 1, “Introduction” on page 1 of this book gives an introduction and the motivation for
Asset-Based Development. It explains the business value of strategic asset reuse and gives
an overview of the processes and methods used for Asset-Based Development.
Part 2, “Reusable Assets” on page 123 of this book explains the basics of Asset-Based
Development from a technical perspective. It mentions the types of assets that can be
developed and reused in an organization. It gives an overview of the products and tooling that
IBM provides to support Asset-Based Development.
Part 3, “Service Assets in an SOA” on page 333 builds on Part 1, “Introduction” on page 1
and Part 2, “Reusable Assets” on page 123. Part 2 shows the types of reusable software
assets that can exist in an organization. One of those types of assets are services. Part 3,
“Service Assets in an SOA” on page 333 elaborates on these service assets by presenting
the details of producing, consuming, and managing service assets.
Part 4, “Patterns” on page 455 explains a different type of asset called patterns. While
designing a service-oriented architecture using service assets, it is common practice to use
several patterns as part of the design activities. Furthermore, solutions to common design
problems in an SOA might lead to the creation of new patterns. Thus, Part 3, “Service Assets
in an SOA” on page 333 and Part 4, “Patterns” on page 455 complement each other in an
Asset-Based Development environment.
12.1.2 How does this part relate to SOA
If you are aware of what an SOA is, this part of the book will give you an asset perspective of
the services in an SOA. It gives an insight into methods, tools, and best practices that can be
used to make services more reusable as software assets in an enterprise. It explains how to
make effective use of certain “asset-oriented” features of many of the IBM products and how
you can integrate the products to produce, consume, and manage services as assets.
This part of the book does not explain how to implement an SOA. It does not give a detailed
description of the usage of tools and products that are available to implement an SOA.
However, it gives a brief introduction to SOA for readers who are not aware of it but are
interested in understanding and leveraging the power of SOA- based assets. It provides links
to relevant books, articles, and other publications for detailed information about the larger
SOA implementation story.
12.1.3 How does this part relate to RUP
If you are unaware of Rational Unified Process (RUP) or the Rational Method Composer
plug-in for Asset-Based Development, refer to Part 1 and Part 2 of this book, which introduce
and explain the importance of this process guidance and associated tooling.
Part 3 of this book explains the Rational Method Composer plug-in for Asset-Based
Development life cycle phases (produce, consume, and manage assets) from an SOA
perspective. In regard to creating SOA solutions, we leverage guidance discussing
336
Strategic Reuse with Asset-Based Development
Service-Oriented Modeling and Architecture (SOMA) as found in the RUP/SOMA Rational
Method Composer plug-in.
As illustrated in Figure 12-1, the RUP/SOMA plug-in is treated as a supporting process for
guidance in the development of service assets in the produce phase of the Asset-Based
Development plug-in. Therefore, when building service-based reusable assets, we leverage
guidance from RUP/SOMA. Note that explaining the RUP/SOMA plug-in in detail is out of the
scope of this book.
Figure 12-1 SOMA within Asset-Based Development
We can also look at the relationship between Asset-Based Development and RUP/SOMA
from another perspective. As shown in Figure 12-2 on page 338, the Asset-Based
Development life cycle plays a role in each of the phases within RUP/SOMA, for example:
In the “Describe the Current Business” phase, you first determine if an existing
WebSphere Business Model asset for this portion of the business is already available.
In the Realization phase, we can leverage Pattern-based assets to assist in the generation
of services.
When a service has been completed, we can leverage the Manage aspects of the
Asset-Based Development guidance for promoting the service to a runtime Repository.
This is certainly not an exhaustive list of examples, but hopefully it shows that assets play a
key role in creating SOA solutions.
Chapter 12. Introduction to service assets
337
Figure 12-2 Asset-Based Development within SOMA
The SOA-Governance plug-in for Rational Method Composer overlaps with the Asset-Based
Development Governance plug-in. This part of the book explains the relationship between the
two plug-ins.
12.2 SOA, services, and assets
Service-based assets are closely related to the concept of service-oriented architecture
(SOA). SOA is an architectural style that aims at aligning the business of an organization with
the information technology that enables it.
In an SOA solution, a service is a repeatable task in a business process. It can be a simple
task or a business process by itself. Consider, for example, the process of ordering a book on
a Web site. We first have to log on to the Web site, search for the book, add the book to the
shopping cart, do an online payment, and log out of the Web site. Here, the individual tasks
that are part of the ordering process are the search function, the shopping cart function, the
payment function, and the user account management function. From an SOA perspective,
each of these repeatable tasks is a service. Note that the payment function can be a process
in itself, involving the processing of the payment with the payment gateways.
338
Strategic Reuse with Asset-Based Development
The services within an SOA solution need to be reusable across different business
processes. Making the services reusable gives the flexibility to change existing processes
and implement new processes easily, thus leading to business agility. In the book ordering
example, each of the identified services (search, shopping cart, payment, and user
management services) can be reused in different processes. For example, a back-end
process for ordering stock from the vendors for delivery to the warehouse can be built using
the same payment processing service. This reuse not only reduces the time required to
automate the new business process, but it also makes it easy to implement changes to the
payment process across the multiple business processes in the organization (when there is a
change made to the organization policies in relation to the payment processing). In this way,
integrating the business as a set of linked services is called service orientation.
A formal definition of a service-oriented architecture is:
An architectural style for creating an enterprise IT architecture that exploits the
principles of service orientation to achieve a tighter relationship between the business and
the information systems that support the business.
We can thus see that reusable software services are important assets of an organization. By
maintaining a Repository of reusable services, organizations can quickly build new processes
as a choreography of existing services. When business processes need to be changed, a
suitable service can be sourced out of the enterprise’s service Repository and plugged into
the right point in the choreography. This makes the business more responsive to changing
market needs, reduces the time and cost to automate new processes, and maximizes the
return on investment of the service assets.
12.3 What is a service
Having seen the importance of service-based assets from a business perspective, let us now
see the technical characteristics of a service. There are many additional aspects to a service
that we must also consider in the definition of a service within an SOA. The most commonly
agreed-on aspects are that services:
Encapsulate reusable business functions
Are defined by explicit, implementation-independent interfaces
Are invoked through communication protocols that stress location transparency and
interoperability
12.3.1 Reusable business functions
A service can be any business function. In an SOA, however, it is preferable that the function
is genuinely reusable. The goal of a service in an SOA is that it can be used and reused by
one or more systems that participate in the architecture. For example, while the reuse of a
Java logging application programming interface (API) can be described as design time (when
a decision is made to reuse an available package and bind it into application code), the
intention of SOA is to achieve the reuse of services at:
Run time: Each service is deployed in one and only one place and is invoked remotely by
anything that must use it. The advantage of this approach is that you only apply changes
to the service (for example, to the calculation algorithm or the reference data on which it
depends) in a single place.
Deployment time: Each service is built one time, but it is redeployed locally to each system
or to the set of systems that must use it. The advantage of this approach is increased
Chapter 12. Introduction to service assets
339
flexibility to achieve performance targets or to customize the service (perhaps according
to geography).
12.3.2 Explicit implementation-independent interfaces
The use of explicit interfaces to define and to encapsulate service function is of particular
importance to making services genuinely reusable. The interface must encapsulate only
those aspects of process and behavior that are used in the interaction between the service
consumer and the service provider. An explicit interface definition, or contract, is used to bind
a service consumer and a service provider. The explicit interface definition must specify only
the mutual behavior that is required for the interaction and must specify nothing about the
implementation of the consumer or the provider.
By explicitly defining the interaction in this way, those aspects of either system (for example,
the platform on which they are based) that are not part of the interaction are free to change
without affecting the other system. This implementation-independent interface allows either
system to change implementation or identity freely.
Figure 12-3 illustrates the use of explicit interfaces to define and encapsulate service
functions.
Figure 12-3 Service Implementation in an SOA
12.3.3 Communication protocols that stress location transparency
SOA does not specify that any specific protocol is used to provide access to a service. A key
principle in SOA is that a service is not defined by the communication protocol that it uses, but
instead, a service must be defined in a protocol-independent way that allows different
protocols to be used to access the same service. Ideally, a service must only be defined one
340
Strategic Reuse with Asset-Based Development
time, through a service interface, and must have many implementations with different access
protocols. This type of definition helps to increase the reusability of any service definition.
12.4 Web services and SOA
SOA represents a conceptual architecture of how to integrate applications. Web services are
a specific set of standards and specifications that are one method of enabling SOA. Web
services technology is a collection of standards (or emerging standards) that can be used to
implement a service-oriented architecture. That is not to say that Web services and SOA are
intrinsically linked, because they can be implemented separately. In fact, many significant
SOAs are proprietary or customized implementations that are based on reliable messaging
and Enterprise Application Integration middleware. For example, IBM WebSphere MQ and
IBM WebSphere Message Broker do not use Web services technologies. Also, most existing
Web services implementations consist of point-to-point integrations that address a limited set
of business functions between a defined set of cooperating partners.
The logical links between Web services and SOA are:
Web services provide an open standard model for creating explicit
implementation-independent descriptions of service interfaces.
Web services provide communication mechanisms that are location-transparent and
interoperable.
Web services are evolving through Business Process Execution Language for Web
Services (WS-BPEL), document-style SOAP, and Web Services Description Language
(WSDL) to support the implementation of well-designed services that encapsulate and
model reusable function in a flexible manner.
12.5 SOA Governance
Next, we discuss SOA Governance.
12.5.1 SOA life cycle
The IBM SOA Foundation defines a four-phased services life cycle as shown in Figure 12-4
on page 342.
Chapter 12. Introduction to service assets
341
Figure 12-4 SOA life cycle
From the IBM SOA Foundation: An Architectural Introduction and Overview white paper (see
the following shaded box for a link to this white paper):
The Model phase includes the process of capturing your business design - from an
understanding of business requirements and objectives - and translating that into a
specification of business processes, goals, and assumptions, creating an encoded model
of your business.
The Assemble phase concerns assembling the information system artifacts that will
implement the business design. The enterprise architect - working with the business
analyst - can begin to convert the business design into a set of business process
definitions and activities, deriving the required services from the activity definitions.
The Deploy phase includes a combination of creating the hosting environment for
service-based (composite) applications and the actual deployment of those applications.
This phase includes resolving the application’s resource dependencies, operational
conditions, capacity requirements, and integrity and access constraints.
The Manage phase addresses the maintenance of the operational environment and the
policies realized by the deployed SOA applications. This phase includes monitoring the
performance of service requests and the time lines of service responses, maintaining
problem logs to detect failures in various system components, detecting and localizing
those failures, routing work around them, recovering work affected by those failures,
correcting problems, and restoring the operational state of the system. The manage phase
also includes managing the business model and tuning the operational environment to
meet the requirements of the updated business design.
Note: For more information, refer to IBM SOA Foundation: An Architectural Introduction
and Overview at:
http://www-128.ibm.com/developerworks/webservices/library/ws-soa-whitepaper/
The rationale for SOA Governance is that in order to achieve the benefits of SOA, it is
important to establish chains of responsibilities, authority, and communication to empower
people to bring about the necessary changes for service orientation and to sustain those
changes, so that the organization does not default to business as usual. As seen in
342
Strategic Reuse with Asset-Based Development
Figure 12-4 on page 342, SOA Governance is applied to all of the four stages in the life cycle
of services.
12.5.2 SOA Governance defined
SOA Governance is an extension of IT Governance that is specifically focused on the life
cycle of services, metadata, and composite applications in an organization’s service-oriented
architecture.
SOA Governance extends IT Governance by assigning decision rights, policies, and
measures around the services processes and life cycle to address concerns, such as:
Service registration
Service versioning
Service ownership
Service discovery and access
Deployment of services and composite applications
Security for services
The agility provided by SOA also provides a set of challenges to the IT organization.
Undisciplined development and deployment of services can do more harm than good. Hence,
organizations must address a set of key questions if they are to obtain value from SOA:
1. How do organizations regulate the deployment of composite applications?
2. What organizational change is required? What new organizational roles and structures
facilitate service identification, design, and sharing?
3. How do you organize the IT function to build and leverage service-oriented capabilities?
4. What metrics support the investment, maintenance, vitality, and sharing of services?
5. How do businesses decide to invest in service creation and maintenance?
As a specialization of IT Governance, SOA Governance addresses how an organization’s IT
Governance decision rights, policies, and measures need to be modified and augmented for
a successful adoption of SOA.
12.5.3 The governance life cycle
SOA Governance is setting decision rights and measures for those individuals who execute
SOA processes. However, executing governance intentionally meets our definition of
process; it requires a sequence of events through which the rights and measures are
specified. The governance process enables organizations to make considered decisions
about the structure and rigor of executing governed processes. For example, the governance
process roles are different than the IT or SOA process roles. An SOA architect in certain
organizations can be granted certain decision rights around the design and use of services,
but does not, in that role, carry out the governance process.
The process of governance has its own life cycle, which is distinct from the process life cycle
being governed. See Figure 12-5 on page 344.
Chapter 12. Introduction to service assets
343
Figure 12-5 The SOA Governance life cycle
As shown in Figure 12-5, the governance process consists of four phases, which we discuss
next. Note the process is repeated cyclically. Each cycle provides an opportunity for improving
the governance approach:
Plan: As previously discussed, good IT and SOA Governance results in better alignment
of the IT organization and the needs of the business. It is in the plan phase that the needs
and priorities of the business are documented along with the role of the IT organization in
meeting these needs. Also, the state and maturity of the current IT organization
governance is assessed, and gaps are identified. The governance vision and strategy, as
well as the roadmap and plan, are documented from all of this analysis.
In the plan, the governance measures are put in place. These measures are used to
assess how well the IT organization is aligned with the business and how well the
business needs are met.
Define: In the define phase, the detailed governance plan is put in place for the current
cycle. In particular, the processes to be governed are specified and prioritized, and the
decision rights, policies, and measures for these processes are defined.
In preparation for the next phase, detailed deployment plans are set. In certain cases,
these plans can include specifying or updating the structure and staffing of the SOA
Governance Center of Excellence (CoE).
Enable: The enable phase is when the defined solution is rolled out to the organization. In
this phase, roles are assigned, the staff is trained, the decision rights can be automated in
workflow tools, and the metrics collection and report mechanisms are put in place.
Measure: In this phase, the governance approach is executed and tuned. The
governance metrics that show alignment with the business are gathered. These metrics
are used in the next cycle to revise the governance approach.
344
Strategic Reuse with Asset-Based Development
12.5.4 Relationship between Asset Governance and SOA Governance
Asset governance was introduced in Part 1, “Introduction” on page 1 of this book. It
mentioned the importance of governance in an Asset-Based Development approach and also
detailed the different stages in the asset-governance life cycle. By now, you have realized that
Asset Governance and SOA Governance both have plan, define, enable, and manage
stages. Figure 12-6 relates SOA Governance to asset, IT, and business governance.
Figure 12-6 Relationship between the governance levels
As seen in Figure 12-6, there is an overlap between SOA Governance and Asset
Governance. This means that SOA Governance deals with the aspects of Asset Governance,
because an SOA treats services as reusable assets. The processes, roles, and competencies
that might be required to produce, consume, and manage service assets might be similar to
those defined by Asset Governance. However, the scope of SOA Governance is much more
than just Service Asset Governance. It includes process, policy, role, and responsibility
definitions for a larger set of activities that are part of the service life cycle in an SOA.
Similarly, an Asset Governance body in an organization can perform governance activities for
assets that might not necessarily be services, even though the organization might be
undergoing an SOA transformation. This distinction explains the non-overlapping portion of
the Asset Governance ellipse in Figure 12-6.
SOA Governance and Asset Governance can coexist in an organization. SOA Governance
can address the issues of Asset Governance at relevant stages in its life cycle. For example,
during the define stage of SOA Governance, asset repositories can also be defined for
service assets. Workflows can be defined for publishing services to the repositories. Policies
can be defined for service reuse. Based on the IT Governance policies of an organization,
there can be common members in the SOA Governance and Asset Governance boards to
align the activities of both the governance bodies.
Chapter 12. Introduction to service assets
345
12.6 Types of service-based assets
Assets related to services can be of various types. Common types of these assets are:
Service interfaces
Basic services (service interface and implementation)
Choreographed services
Business services
Composite Business Services
A service interface is just a standards-based interface for services. It does not contain any
implementation attached to it. The implementation aspects are left to the application that
consumes this asset.
The importance of having service interfaces as assets is to lay a standard for performing
certain tasks across the organization. This standard enhances the interoperability between
applications, because one application that needs to interoperate with another application
knows what to expect from the other application based on the standard interface.
Furthermore, even if application integration is unimportant, it makes sense to have service
interfaces defined for certain tasks that are likely to be implemented by different applications
in the organization. Having the interfaces and data types defined reduces the development
time needed to create them.
At a physical level, a service interface asset is usually a Web Service Description Language
(WSDL) file along with the related XML Schema Definition (XSD) files.
A basic service is a service that performs a certain generic task. As a reusable asset, it is
used as a building block for implementing process choreographies. It is usually implemented
using the Web service standards in order to make it easy to integrate into applications that
want to consume this service. At a physical level, a basic service asset contains a service
interface (WSDL and XSD files) and implementation files.
A choreographed service is a process implementation that is exposed as a service. It is built
using basic services. It has the business logic that drives the business process in it. These
assets can be used as part of other larger process choreographies. The industry standard for
implementing process choreographies is using the Business Process Execution Language
(BPEL). At a physical level, a process implementation contains the files related to BPEL and
the files related to the basic services.
A business service is a business function whose execution can be adapted at run time based
on business policy and user context. It is a matured form of a choreographed service that is
more dynamic and flexible than the choreographed service. It is designed at the business
level to represent a discrete business function. It is derived from disparate IT resources, such
as existing systems, custom applications, independent software vendor (ISV) systems, and
third-party services. It is provisioned through multiple communication channels, such as Web
portal, Business-to-Business (B2B), Fax, or any other channel relevant to the business. It is a
reusable asset in the sense that it can be combined with other business services to create
loosely coupled applications and processes.
To understand these features of a business service, look at the example shown in Figure 12-7
on page 347. A Credit Check service is a business function to evaluate the credit score of a
consumer. It encapsulates a business process that performs credit score lookup, applies
credit rules to determine acceptance, updates the consumer credit profile, provides
notification of acceptance or failure. It is derived from disparate IT resources and comprised
of Web services, such as credit lookup (third-party), credit eligibility (existing), update profile
(packaged application), and notification (custom). It can be provisioned through a Web portal
346
Strategic Reuse with Asset-Based Development
channel and existing customer relationship management (CRM) systems. It can be
composed into Loan Origination solutions and other consumer loan applications. It can be
made flexible and adaptable through policies, such as a rapid pre-approval for qualified low
risk consumers, that is, consumers with a credit score over 720 or an “A” rating.
The "Credit Check" Business Service represents a discrete business
function to evaluate the credit score of a consumer
Business Policies
Communication Channels
Web Portal
IVR
Role-Based
Users
CRM
Pre-Approval
Policies
Risk Assessment
Policies
Business
Service
Technical and industry standards compliance
CSR
• WS-I for service interfaces
• MISMO, IFW for messages and transactions
Consumers
Operational Capabilities
Credit Lookup:
3rd Party Service
Credit Eligibility:
Legacy System
Customer Profile:
Packaged CRM
Customer Notification:
Custom J2EE
Figure 12-7 Business service example
A composite business service is a collection of business services that work together with
existing applications to provide a specific business solution. Figure 12-8 on page 348 shows a
pictorial representation of the concept of Composite Business Services. The service
performing a generic task in Figure 12-8 on page 348 can be either a basic service or a
choreographed service, which is not as dynamic as a business service.
Chapter 12. Introduction to service assets
347
Figure 12-8 Composition of business services
A composite business service is a composition of business services that are selected and
executed dynamically to deliver adaptive and personalized behavior. The individual business
services can be derived from existing, third-party, or custom-packaged applications. Thus,
Composite Business Services enhance reuse of IT assets by leveraging these business
service assets. Furthermore, by being able to create Composite Business Services
incrementally, organizations have the advantage of reduced risk in building composite
business service assets. When compared to assets developed as traditional monolithic
applications, Composite Business Services provide greater flexibility at a lower cost due to
their ability to dynamically adapt behavior at run time using policies, instead of hard coding
new or duplicate functionality.
By reusing Composite Business Services to build larger business processes, organizations
can achieve faster time to market, because Composite Business Services automate part of
the business process and are easy to adapt and configure using business context and
content-based policies.
To summarize, a composite business service has the following attributes:
Composable: Composite Business Services support an asset-based approach to building
an SOA solution leveraging services exposed from existing, ISV, third-party, and partner
assets to incrementally automate a core business process.
Subscribable: Users subscribe to Composite Business Services, and the subscribers of
services are managed with an integrated entitlement model that enables licensing,
packaging, and billing of business level services.
Describable: Composite Business Services and the constituent business services are
described via metadata that can be annotated and published in a catalog for easy
discovery; this type of metadata must include business, application, technical, and
informational architectural elements.
Flexible: Composite Business Services are built with points of variability. These points of
variability within the underlying business processes are dynamically implemented based
on an externalized set of directives. These directives are derived from business,
application, technical, and informational architecture elements including quality of service,
348
Strategic Reuse with Asset-Based Development
industry semantics, and business policies. In this case, a policy is a business rule that
constrains the behavior of a business process.
Visible: Composite Business Services provide contextual visibility to service behavior so
that business services can be optimized or evolved during execution.
Governable: Composite Business Services have the ability to be managed and versioned
through their life cycle from creation through upgrades to end of life.
12.7 Service-oriented modeling and architecture (SOMA)
Building an SOA requires certain activities and artifacts that are not part of traditional
object-oriented analysis and design. SOMA fills this gap by describing a set of modeling,
analysis, and design activities that are required to build an SOA. It defines a three stage
process involving the activities required to identify, specify, and realize services (and their
compositions), components, and flows. Figure 12-9 summarizes these activities.
Figure 12-9 Service-oriented modeling and architecture activities
12.7.1 Rational Method Composer plug-in for SOMA
The RUP for SOA plug-in is a commercial offering from IBM that has been developed to bring
the unique aspects of SOMA 2.4 to the RUP commercial method. The plug-in is included with
Rational Method Composer and provides tooling and guidance that integrate the activities
and techniques provided by SOMA. RUP/SOMA is based on RUP and provides variations
(contributions, extensions, or replacements) for service orientation.
12.8 IBM products for implementing service assets
IBM provides a wide range of products and tooling to enable SOA-based solutions. While a
complete discussion of all of the products is out of the scope of this book, this section
highlights the key products and tools that help in the production, consumption, and
management of service-based assets.
Chapter 12. Introduction to service assets
349
We discuss the following products in this context:
Rational Method Composer plug-in for SOA Governance
Rational Software Architect
WebSphere Integration Developer
WebSphere Process Server
WebSphere Business Services Fabric
WebSphere Business Modeler
WebSphere Business Monitor
WebSphere Service Registry and Repository
WebSphere Studio Asset Analyzer
Rational Asset Manager
12.8.1 Rational Method Composer plug-in for SOA Governance
The Rational Method Composer plug-in for SOA Governance V1.0 helps identify appropriate
best practices, merged with your existing IT processes, to provide proper governance of the
capabilities introduced with SOA. The end result is a project plan to create your organization’s
unique governance framework.
The SOA Governance methodology described in the plug-in is extensive, covering the full life
cycle and many of the key processes. However, based on the specific needs of the
organization, projects can be scoped to include only a subset of the phases, process
activities, and tasks. One of the first tasks is to tailor the methodology to create a project plan
based only on the components of the methodology that are necessary to satisfy the defined
scope of the project.
Providing a description of all of the features provided by the RUP for SOA Governance
plug-in is beyond the scope of this book. For a full description of the RUP for SOA
Governance plug-in features, refer to the information provided with the plug-in.
12.8.2 Rational Software Architect and Rational Software Modeler
Rational Software Architect and Rational Software Modeler include all of the capabilities that
are needed by the software architect, the designer, and the developer. They are part of a
larger picture representing the IBM Rational offering for software development, as we can see
in Figure 12-10 on page 351.
350
Strategic Reuse with Asset-Based Development
Figure 12-10 High-level view of tools and roles
Rational Software Architect includes:
Rational Software Modeler: This is the tool for designers. It offers all Uniform Modelling
Language (UML) 2 modeling capabilities, diagrams, and Model Driven Development
(MDD) features (transformations and patterns authoring). It is based on a basic Eclipse
project, such as UML 2 and Eclipse Modeling Framework (EMF).
Rational Application Developer: This is the tool for developers. It includes all
development features, such as Web development, Java 2 Platform, Enterprise Edition
(J2EE) development with Enterprise Java Beans (EJBs), Web services development,
JavaServer Faces (JSF) development, UML visualization, component automated test, and
run time test environments, such as WebSphere Application Server.
Eclipse Web Tools Platform (WTP): This platform includes basic tooling for Web
developers. It includes source editors for HTML, JavaScript™, cascading style sheet
(CSS), JavaServer Pages (JSP), SQL, XML, document type definition (DTD), XML
Schema Definition Language (XSD), and Web Services Description Language (WSDL);
graphical editors for XSD and WSDL; J2EE project natures, builders, models, and a J2EE
navigator; a Web service wizard and explorer, and Web Services Interoperability
Organization (WS-I) test tools; and database access and query tools and models.
In addition, Rational Software Architect offers other features, such as the selection of ready to
use transformations and patterns. For detailed information about these features, refer to
Part 4, “Patterns” on page 455 in this book.
12.8.3 WebSphere Integration Developer
WebSphere Integration Developer is a common tool for building SOA-based integration
solutions across WebSphere Process Server, WebSphere Enterprise Service Bus (ESB), and
WebSphere Adapters. From an asset development perspective, the primary purpose of the
Integration Developer is to produce service-based assets. However, it integrates with asset
Chapter 12. Introduction to service assets
351
management products, such as Rational Asset Manager, to help you consume and publish
assets from and to the Repository.
All of the types of service assets can be created and tested using the Integration Developer. It
provides an Eclipse-based integrated development environment to code, test, debug, and
deploy SOA solutions. The product is based on industry standards for Web services, such as
SOAP, WSDL, XSD, and Web Services Business Process Execution Language (WS-BPEL),
thus, enabling reuse of the services developed using its environment across multiple
platforms.
WebSphere Integration Developer simplifies integration by using an industry standard
programming model called Service Component Architecture (SCA). SCA is a specification
that describes a model for building applications and systems using an SOA. It decouples
service implementation and assembly from the details of infrastructure capabilities and from
the mechanisms for invoking external systems. By developing service-based assets as SCA
components:
Consumers can integrate the asset as part of their application assembly in a standard
way.
Client programs can use a standard API to invoke the services.
Integration developers can configure the deployment time parameters, such as service
binding information, without having to change the code.
Thus, service reuse can be enhanced to a great extent by using the SCA programming model
to render existing IT assets as service components.
WebSphere Integration Developer enables rapid assembly of business solutions by wiring
reusable service components. It enables the construction of process and integration solutions
using drag-and-drop technology without the need to have a working knowledge of Java. This
capability helps in the quick development of service assets that involve process
choreography, such as business services and Composite Business Services.
12.8.4 WebSphere Process Server
WebSphere Process Server is a high-performance business integration server. From an asset
development perspective, it provides the runtime environment that is required to host basic
services and process choreography-based assets. This integration can happen in the
produce and consume phases of the asset development life cycle.
The WebSphere Process Server contains WebSphere ESB, which internally contains the
WebSphere Application Server. Hence, services developed on WebSphere ESB or
WebSphere Application Server can be deployed without any changes on the Process Server.
Similar to the Integration Developer, the Process Server support for Web services is based
on standards, such as SOAP/HTTP, SOAP/JMS, WSDL 1.1, and WS-* Standards, including
WS-Security and WS-Atomic Transactions. It also provides the run time for SCA
components.
The WebSphere Process Server supports the WS-BPEL standard for process choreography
and provides certain IBM proprietary extensions of the standard in a number of areas,
including human tasks and Java snippets. WebSphere Integration Developer provides the
development environment to support the usage of these features.
352
Strategic Reuse with Asset-Based Development
12.8.5 WebSphere Business Services Fabric
WebSphere Business Services Fabric is an SOA platform for assembly, deployment,
management, and governance of business services. Using the WebSphere Business
Services Fabric, business level services can be assembled into extended, cross-enterprise
business processes and solutions that are dynamically personalized and delivered based on
the business context, content, and contract of the service request.
As an end-to-end platform for Composite Business Services, the Business Services Fabric
consists of two complementary software packs: the IBM Business Services Foundation Pack
and the IBM Business Services Tool Pack. These packs work together to simplify the
business, technology, security, governance, and process interoperability issues associated
with business services in an SOA. To help ensure a robust and extensible SOA platform, the
Business Services Fabric includes WebSphere Process Server and WebSphere Integration
Developer for the composition and deployment of flexible, service-oriented business
processes.
IBM Business Services Foundation Pack provides the integrated runtime and manage-time
environment:
Provides a highly scalable runtime policy definition and enforcement engine that enables
dynamic service assembly and service behavior adaptation based on content, context,
and contract.
Controls and automates entitlement of business services for subscribers, enabling
creation, control, and management of service packages to subscribers across the
ecosystem. It integrates with leading security and identity management products.
Provides visibility and monitoring of service-oriented processes and applications. It
includes multi-perspective views and enables the drill-down analysis of events and
exceptions.
Provides end-to-end governance of business services through design time, run time,
deploy time, and manage time.
Stores and manages business services, policies, and business service entitlements.
IBM Business Services Tool Pack provides the design-time environment and tools:
Provides tools to maintain, manage, and govern services metadata, subscribers, policies,
and governance processes.
Enables domain-experienced software architects to model, create, publish, and manage
industry-specific service metadata models and policies around data, processes,
resources, policies, and domains.
Provides a visual assembly environment for creating and managing industry specific
business service metadata models and policies.
The Industry Content Packs provide reference business services templates optimized to
industry standards that contain the following prebuilt SOA assets:
Reference business services templates that include definitions of business assertions,
business roles, and business channels; all based on a common industry business
glossary
Industry business glossary that presents a taxonomy of industry terms, with associated
relationships and properties
Industry standards-based data types and Web service interfaces that enable
interoperability across disparate systems in the enterprise ecosystem
Chapter 12. Introduction to service assets
353
Industry-common services that can speed up the delivery and assembly of
service-oriented business solutions.
Industry business object model (BOM) used as a semantic model for design and
development of service-oriented business solutions
Knowledge assets that can accelerate the use and extension of the prebuilt SOA content
contained in the industry content packs
Content packs are currently available for the Healthcare, Insurance, Telecom, and Banking
domains.
Figure 12-11 shows how the pieces of the Business Services Fabric product come together to
provide a platform for developing Composite Business Services (CBSs). The lowest layer
consists of the foundation pack and the tools pack, which run on the Process Server (not
shown in Figure 12-11). The industry content packs are developed over the foundation pack
to provide industry-specific reusable assets that help in the quick development and delivery of
industry-specific CBS solutions. The CBSs are developed using the business services, basic
services, and ontology assets in the industry content pack. The CBSs use the dynamic
assembler for policy-based dynamic endpoint selection, basic services, and APIs for
functions, such as subscription management from the foundation pack. CBS developers use
the Web-based administration tool and the Composition Studio, which is an Eclipse plug-in
for Integration Developer, to create, manage, and govern service metadata and policies.
Industry Composite Business Service Portfolio
Trade Payments
Payments Status
Fund Transfer
Bill Payments
…Other
Industry
Composite
Business Service
IBM Industry Content Packs
Product
• Reference Business Services Templates
Composite
Business
Services
Industry
Content
Packs
…Other
Industry
Packs
IBM Tools Pack for WebSphere Business
Services Fabric
IBM Foundation Pack for WebSphere
Business Services Fabric
W ebSphere
Business
Services
Fabric
Flexible, adaptable, loosely
coupled business solutions
Available through Global
Business Services, System
Integrators, and ISVs
Pre-built, industryspecific SOA assets
Industry solution
accelerators that are
optional extensions to
the WBS Fabric
SOA platform for
Composite Business
Services
Fabric incorporates
other SOA Foundation
products
Figure 12-11 IBM platform for Composite Business Services
12.8.6 WebSphere Business Modeler
WebSphere Business Modeler helps organizations to fully visualize, comprehend, and
document their business processes. Rapid results can be obtained through the collaboration
functionality, where subject matter experts team to clearly define business models and
eliminate inefficiencies. The Business Modeler is used in the produce phase of the asset
development life cycle. It is used to model business processes for assets that involve process
choreography. It provides a clean transfer from the business to IT by providing the option to
export the completed model as a BPEL file, which can be used as a starting point by the IT
team to develop the asset in the Integration Developer.
354
Strategic Reuse with Asset-Based Development
Business process models are assets by themselves, which can be maintained in a
Repository, such as Rational Asset Manager. They can be stored as Business Modeler
projects for later reuse, or they can be stored as image files for reference. Having the
business process models ready for reuse reduces the time needed to create business
services and their composites.
12.8.7 WebSphere Business Monitor
WebSphere Business Monitor helps in monitoring business processes in real time. It provides
a visual display of business process status with alerts and notifications to key users that
facilitate continuous improvement of the business processes. The monitor is controlled
through a customizable dashboard implemented as WebSphere Portal pages that are visually
intuitive, featuring scorecards, key performance indicators, and gauges.
While it is primarily used for process management, from an asset management perspective,
the monitor can be used to view and analyze the metrics related to usage of service assets to
gain insight on the benefits gained through reuse.
12.8.8 WebSphere Service Registry and Repository
IBM WebSphere Service Registry and Repository is a tool that enables better management
and governance of your services. WebSphere Service Registry and Repository enables you
to store, access, and manage information about services and service interaction endpoint
descriptions (referred to as service metadata) in an SOA. This information is used to select,
invoke, govern, and reuse services as part of a successful SOA.This service information
includes traditional Web services that implement Web Services Description Language
(WSDL) interfaces with SOAP/HTTP bindings, as well as a broad range of SOA services that
can be described using WSDL, XML Schema Definition (XSD), and policy decorations, but
can use a range of protocols and be implemented according to a variety of programming
models.
You can use WebSphere Service Registry and Repository to store information about services
in your systems, or in other organizations’ systems, that you already use, that you plan to
use, or of which you want to be aware.
WebSphere Service Registry and Repository includes:
A service registry that contains information about services, such as the service interfaces,
service operations, and parameters
A metadata Repository that has the robust framework and extensibility to suit the diverse
nature of service usage
12.8.9 Rational Asset Manager
Rational Asset Manager is an asset management tool that can be used to store not only
service assets but any other kind of software assets in your organization. For more
information about the Asset Manager, refer to Part 2, “Reusable Assets” on page 123 of this
book.
From an asset development perspective, WebSphere Service Registry and Repository
serves as a runtime Repository for service metadata while Rational Asset Manager serves as
a development time Repository.
Chapter 12. Introduction to service assets
355
12.8.10 WebSphere Studio Asset Analyzer
WebSphere Studio Asset Analyzer is an application metadata Repository derived from the
static analysis of source code and the configurations of the database and transactional
systems in which the applications run. It consists of the following components:
Source scanners running on z/OS, and, optionally, distributed scanners running on AIX or
Windows
Metadata Repository in DB2 on z/OS
WebSphere applications running on z/OS, AIX, and Windows systems, which provide the
user interface, impact analysis engine, and optional distributed scanners
Figure 12-12 shows the major components of WebSphere Studio Asset Analyzer that take
part in the process of collecting inventory, performing analysis, and presenting metadata
about software artifacts.
Figure 12-12 Major functions and components of WebSphere Studio Asset Analyzer
The first step is to inventory your applications:
Analyze source and Java bytecode to capture relevant information about the objects in the
application (program names, data stores, program tokens, data elements, control
transfers, relationships between programs and data, program metrics, and so forth).
Capture system configuration information to provide context.
Store this metadata in a DB2 database.
As part of the process, figure out what is missing or inconsistent in your inventory (missing
programs, bad JCL, program name clashes, and so forth).
356
Strategic Reuse with Asset-Based Development
After inventorying an application, its metadata becomes the source of application insight,
which can be used for, among other things, rapid application understanding and change
impact analysis. It is accessible in multiple ways:
People access this application insight through a browser interface
Other tools and programs use a Web service interface or make direct DB2 SQL calls
Chapter 12. Introduction to service assets
357
358
Strategic Reuse with Asset-Based Development
13
Chapter 13.
Producing service assets
This chapter provides best practices, insights, and tooling capabilities for producing service
assets in an service-oriented architecture (SOA). We discuss how services can be reused as
assets to produce larger assets and solutions, Also, we focus on the features of IBM products
that help you produce service assets:
Creating service assets
Service-oriented Modeling and Architecture (SOMA) insights for asset development
Creating Composite Business Service assets
Testing SOA assets
Publishing service assets to the Repository
Case study: SOA Service Reuse at ZYX Electronics
© Copyright IBM Corp. 2008. All rights reserved.
359
13.1 Creating service assets
Chapter 12, “Introduction to service assets” on page 335 gave you an overview of
Service-oriented Modeling and Architecture (SOMA). SOMA enabled by the Rational Unified
Process (RUP)/SOMA plug-in for Rational Method Composer can be used to identify, specify,
and realize services in an SOA. We discuss insights into the SOMA process for Asset-Based
Development next. IBM provides a wide range of tooling to create service artifacts.
Important: Because there are a number of books written about creating basic services
and service choreographies, this chapter focuses only on the creation of Composite
Business Services. For detailed information about creating the types of services, refer to
the following books:
Building SOA Solutions Using Rational SDP at:
http://www.redbooks.ibm.com/abstracts/sg247356.html?Open
WebSphere Version 6 Web Services Handbook Development and Deployment at:
http://www.redbooks.ibm.com/abstracts/sg246461.html?Open
Business Process Management: Modeling through Monitoring Using WebSphere
V6.0.2 Products at:
http://www.redbooks.ibm.com/abstracts/sg247148.html?Open
Technical Overview of WebSphere Process Server and WebSphere Integration
Developer at:
http://www.redbooks.ibm.com/abstracts/redp4041.html?Open
13.2 SOMA insights for asset development
In this section, we provide certain insights about RUP/SOMA for asset development. We do
not intend to explain the SOMA process in detail. We highlight the areas in RUP/SOMA that
are of relevance for Asset-Based Development.
Both the RUP/SOMA and the Asset-Based Development plug-ins define roles to perform the
tasks that they describe. There might be overlap between these role definitions, because
SOA views services as reusable assets. Based on the governance policies of your
organization, you might adopt a subset of these roles that is suitable for your needs.
As shown in Figure 13-1 on page 361 and Figure 13-2 on page 362, we can view the
relationship between RUP/SOMA and Asset-Based Development from two perspectives. In
Figure 13-1 on page 361, we see that we can follow RUP/SOMA as an approach to build a
reusable asset.
360
Strategic Reuse with Asset-Based Development
Figure 13-1 A look at RUP/SOMA inside of Asset-Based Development
In the case of Figure 13-2 on page 362, we can see that the Asset-Based Development
guidance can be used throughout RUP/SOMA.
Chapter 13. Producing service assets
361
Figure 13-2 A look at Asset-Based Development within RUP/SOMA
In the following sections, we look in more detail at the Service Identification, Service
Specification, and Service Realization phases of RUP/SOMA.
13.2.1 Service identification
This phase focuses on the identification of candidate services from the set of assets from
both business and IT. It has three approaches to identify services:
Domain decomposition: Domain decomposition is a top-down approach that takes the
domain models and decomposes them into subsystems to arrive at candidate services.
Reusable assets are involved in a number of ways in this approach, for example:
– Reuse of business models
– Reuse of Component Business Models
– Reuse of Uniform Modelling Language (UML) models
– Industry standards
– Patterns to automate the navigation between levels of abstraction
362
Strategic Reuse with Asset-Based Development
Goal-service modeling: Goal-service modeling is a meet-in-the-middle approach to
identify services that were not identified using the other two approaches. Reusable assets
are involved in a number of ways in this approach, for example:
– Reuse of business models
– Reuse of Component Business Models
– Reuse of UML models
– Industry standards
– Patterns to automate the navigation between levels of abstraction
– Existing services
– Existing systems, such as packaged or custom applications
– Existing code and components that are suitable as the basis for services
Existing asset analysis: Existing asset analysis is a bottom-up approach that involves a
process of leveraging existing assets. Reusable assets are involved in a number of ways
in this approach, for example:
– Existing systems, such as packaged or custom applications
– Industry standards
– Existing services
– Existing code and components that are suitable as the basis for services
Searching for assets
In order to analyze assets, you need to locate them in your asset and service repositories.
Services can be identified from custom applications or packaged applications. If the assets
are maintained in a Repository, such as the Rational Asset Manager, it might be easy to
search for specific assets for analysis using the Repository’s search features. Refer to Part 2,
“Reusable Assets” on page 123.
If you use WebSphere Service Registry and Repository as the runtime Repository for
services, you can use the query features in the WebSphere Service Registry and Repository
to find deployed services. WebSphere Service Registry and Repository provides
search/browse feature for services with varying degrees of criteria driven by any metadata
associated with the service. A common example of service information gathered or searched
is that of documents conforming to the Web Services Description Language (WSDL) or XML
Schema Definition (XSD) standards. Architects and developers can also annotate this
technical information in the registry and Repository with extra information using formal
classification techniques, such as using the Web Ontology Language (OWL) standard or by
adding other content that is defined following the XSD standards. Classification of services
allows for meaningful groupings of the services based on the business objective.
If you have business services deployed in your organization, you can use the search features
in WebSphere Business Services Fabric to find business services and Web services stored in
the business services Repository.
Note that ideally all of the service asset artifacts are stored in Rational Asset Manager.
Hence, you might have to search for assets in one central asset Repository. However, you do
have the option to search in specific service repositories to make use of their unique search
features.
Chapter 13. Producing service assets
363
Note: For detailed information about locating services in WebSphere Service Registry and
Repository and WebSphere Business Services Fabric, refer to Chapter 14, “Consuming
service assets” on page 399.
Using WebSphere Studio Asset Analyzer for asset identification
Chapter 12, “Introduction to service assets” on page 335 introduced WebSphere Studio
Asset Analyzer as an application metadata Repository derived from the static analysis of
source code and the configurations of the database and transactional systems in which the
applications run. By inventorying your application source and organizing metadata about your
heterogeneous software assets in an accessible way, WebSphere Studio Asset Analyzer
helps you identify assets for reuse.
When the process of inventorying the applications and their configurations is complete,
WebSphere Studio Asset Analyzer is ready to analyze the assets. Your approach to the
discovery of assets for reuse with WebSphere Studio Asset Analyzer can start with either
data or programs.
You can start with relevant data of interest. One way to think of a business process is to
consider it as a set of states of the associated data together with the transformations of this
data. If you know part of the data that is created by or consumed in the business process, you
can use WebSphere Studio Asset Analyzer to help you find the related set of applications and
other data stores. Perhaps you know the name of a dataset or DB2 table that contains the
data that your Web service needs to read or update. In this case, you can start by finding the
applications that access this data source. You can then run an impact analysis on a dataset
or DB2 table, the record, or a related data element to find other applications, data elements,
and data stores through which this data flows.
Or perhaps you know only that your Web service needs to deal with employee number, part
number, order number, and so forth. You can construct searches of the data elements
defined in your applications using the various likely permutations of the name. You can then
run an impact analysis on one or more data elements and find other data elements into which
values are moved and the applications containing these data elements, and other data
stores.
You can start with applications or screens that you know are part of a business function that
you want to reuse in your Web service. Applications can have various call sequences. These
call sequences are called run units in WebSphere Studio Asset Analyzer. Software assets
associated with run units include screens, transactions, data stores, and other applications.
Run units often embody and enable one or more business functions. For example, a run unit
can include screens for order entry, which return data to applications that validate that data
and which call other applications that embody the business logic and interact with the data
stores. This characteristic makes the run unit a useful construct when you consider reuse of a
business task or process. When you find any candidate element in the run unit, you can
quickly get a look at that element in the context of its related elements. Figure 13-3 on
page 365 shows an example of a run unit diagram.
364
Strategic Reuse with Asset-Based Development
Figure 13-3 Run unit diagram in WebSphere Studio Asset Analyzer
There are several ways to find specific assets in WebSphere Studio Asset Analyzer:
If you know the name of the asset for which you are looking, you can search on that name.
If you know only part of the name, you can use wildcards and search attributes to find the
asset.
If you know only certain aspects of the asset but not the name, you can drill down in a
likely container, such as the enterprise application archive (EAR) file, one of which must
contain the asset for which you are looking.
WebSphere Studio Asset Analyzer can help you to find:
Which applications perform screen or data I/O or both
Which applications appear to be the hub applications
Which applications are the largest, most complex, or most often invoked by other
applications
Chapter 13. Producing service assets
365
The advanced search allows searching on interesting attributes, as well as asset name
patterns. You can, for instance, select CICS programs that perform or do not perform terminal
I/O. Extending this idea, you can combine these attributes in custom queries to identify just
the programs in which you are interested.
After finding candidate assets from the asset Repository, you can proceed with the Existing
Asset Analysis process to identify candidate services. A detailed discussion about this
process is out of the scope of this book.
The key thing to remember is that even if an organization is not yet leveraging reuse, the
organization likely has code that is suitable to find its way into an asset (service or otherwise).
WebSphere Studio Asset Analyzer can be a key tool to help you analyze the code and
artifacts that are already tested, understood, and in use within your organization. WebSphere
Studio Asset Analyzer can provide you with the insights needed to further leverage that
investment.
Tooling considerations
In addition to the tools mentioned in this section, Rational Software Architect and its
integration features with other tools, such as Rational RequisitePro and WebSphere Business
Modeler, can be used to perform service identification.
Rational Software Architect’s RequisitePro integration allows you to work on RequisitePro
projects from within the Software Architect Integrated Development Environment (IDE).
Almost all of the capabilities provided by the RequisitePro native client are also provided,
except administration capabilities and the ability to create new projects. There is a
Requirement perspective, which supports working with RequisitePro requirements and the
linkage (traceability) of design elements to requirements.
13.2.2 Service specification
This phase of SOMA is focused on the selection of candidate services to be developed into
full-fledged services. These services are then allocated to subsystems identified in the
identification phase and then decomposed into sets of components for implementation. This
phase involves three stages:
Service specification
Subsystem analysis
Component specification
During the service specification phase, it is important to remember the following points.
Service assets in an SOA become part of the enterprise portfolio and are reused in projects
across the organization. When service assets are reused, the service specification is used by
application developers to understand the interactions and requirements of the service or to
provide a different implementation for the service that conforms to the service interface.
Hence, it is important to make sure that the service, message, and collaboration designs that
are performed as part of the service specification are generic enough to be reused across the
enterprise and not very specific to the particular project for which it is being developed. Using
industry standard information and messaging models (such as HIPAA, ACCORD, and so
forth) is one way of making sure that the specification is reusable.
A key aspect of the Service Model artifact, which must be developed during specification, is
the capture of the dependencies between services. As a part of the service model, a number
of dependencies are naturally captured. These dependencies can be as obvious as the
relationship between a service and its specification or more complex, such as the logical
366
Strategic Reuse with Asset-Based Development
relationship between two independent services, because they both implement the same
specification.
If the Existing Asset Analysis phase resulted in identification of deployed services in the
WebSphere Service Registry and Repository, you can use the impact analysis feature in the
WebSphere Service Registry and Repository to analyze the dependencies between these
services. The vast majority of objects that are stored in the WebSphere Service Registry and
Repository do not exist in isolation. Each object can define a number of predefined
relationships (also known as modelled relationships) or user-defined relationships that
connect them to other objects in the WebSphere Service Registry and Repository, forming an
object graph. These relationships indicate dependencies that exist between the objects in the
object graph. They can be traversed in order to determine which objects might be affected by
changes to other objects in the graph. However, for any non-trivial object graph, attempting to
perform this task manually is a time-consuming process.
The impact analysis functionality within the WebSphere Service Registry and Repository can
automatically traverse the relationships in an object graph to determine the list of dependent
objects. More specifically, the impact analysis component recursively navigates the
relationships that originate from a specified object, building a list of all of the reachable
objects in the object graph. It is this list that is returned as a result of running impact analysis.
It represents the collection of objects in the WebSphere Service Registry and Repository that
might be affected by a change to the specified object. This can help in the existing asset
analysis process to understand the impact of choosing to reuse a specific service from the
Repository.
During service specification, it is important to identify the non-functional requirements for the
desired Qualities of Service (QoS), which can be related to security, performance, and
availability. When the service asset is consumed, the non-functional requirements will be
used to commit resources for service components that offer the services and to fund the
realization and maintenance of service components that will ensure the delivery of the QoS
over time. For more general information about non-functional requirements for assets, refer to
Part 2, “Reusable Assets” on page 123 of this book.
When candidate services have been selected and documented in the (categorized) Service
Portfolio, we then need to determine which ones must be exposed as services. Although, in
theory, any candidate service can be exposed by exporting its interface as a service
description, not every candidate service must be. It might not be economically and practically
(non-functional requirements might be compromised) feasible to do so.
In particular, the naive decision to expose “all methods from all classes” will result in an
overwhelming and often unmanageable number of services leading to the “Service
Proliferation Syndrome”. This creates huge performance and service management problems,
not to mention the fact that we might be giving away the company’s intellectual capital.
Moreover, we must remember that there is a cost associated with every service that we
choose to expose: the funding, governance, and the underlying infrastructure (its security,
performance, and management) of the service and the components that will implement them
must be taken into account. Hence, a service litmus test is conducted on the candidate
services to make the right exposure decisions. Table 13-1 on page 368 summarizes the steps
involved in a service litmus test.
Chapter 13. Producing service assets
367
Table 13-1 Steps involved in service litmus test
Name
Description
Ensure service is
business-aligned
The first test of a service is about its business alignment. If the service
is not traceable back to a business task or goal, it might not yield the
benefits required for SOA implementation. The following questions, if
all are answered positively, mean that the service is aligned with the
business:
Does the service provide a required business functionality that
supports business processes and goals?
Is the business willing to fund the service through its life cycle:
provisioning, management, governance, and maintenance?
Is the business willing to share the service internally or externally
with clients or business partners? For example, implications might
be additional costs, business secrets, security, and so forth.
Are there existing or future opportunities within the enterprise to
reuse the service?
Ensure service is
composable
Composability is defined as an attribute that enables the service to
participate in a service composition. Applications can be created using
both types of composition:
Does the service meet the required QoS attributes as defined in
the composition’s non-functional requirements?
Is the service stateless?
Is the service self-contained? Can the service be deployed
independently to meet a business goal although it might cooperate
with other services at run time to perform business processes?
There are no implicit dependencies of the service on other
embedded functionality. All dependent services are either
replaceable or self-contained.
Is the service’s implementation technology-neutral?
Technology-neutral means that the service does not impose
support of nonstandard (and unknown to the consumer) protocols
or devices, for example, the constituent component requires
intervention through a nonstandard application interface.
This test applies only when the service is deployed in the consumer’s
environment. For example, a business provides an image retrieval
service to its customers. It can provide this capability to its subscribed
customers via a Web service. Alternatively, the business can hand
over to its customer the image retrieval capability exposed as a Web
service and a collection of images. Here, the customer will be
burdened by the implementation of the technology search.
368
Strategic Reuse with Asset-Based Development
Name
Description
Ensure service
has an external
description
The most basic property of a service is that it has an externalized
service description. The externalized service description can either be
generated automatically via tools or manually:
Does the service have an externalized service description that is
distinct and separate from the underlying physical implementation?
A current example of this is WSDL.
Can the service be discovered and bound using the service
description?
Does the service description contain metadata about itself? The
service description must be self-sufficient and contain or reference
all of the information necessary to understand the message
exchange between the consumer and the provider of a service.
Ensure service is
reusable
Can this service be used by the business stakeholder within all
processes where its function is required?
Ensure service is
technically
feasible
Technical feasibility ensures that the service can actually be realized
(implemented and deployed) according to functional and
non-functional requirements using available technologies:
Is the implementation and management effort for the service
reasonable and readily achievable given either the requirements or
infrastructure of the implementation?
This is done after the realization’s technical feasibility exploration.
Candidate services that pass all four parts of the Service Litmus Test must then be exposed
as services in the SOA.
There can be candidate services that did not pass the Service Litmus Test but which are still
implemented as services. Service Litmus Test is an aid to determine which services to
expose; if a business chooses to expose candidate services that did not pass the Service
Litmus Test, the implication is that benefits associated with an SOA will not be realized and
the organization might end up spending resources on assets that might not give returns from
reuse.
Candidate services that do not meet the Service Litmus Test will have to be implemented,
because they are required to fulfill business needs. They can be implemented as methods on
service components and not require the generation of WSDL or other forms of service
definitions; or they can be used as non-exposable entities.
While design patterns can be incorporated any time during the design, the service
specification stage is a good time to start. Patterns in UML can be transformed to code using
the transformation capabilities in Rational Software Architect. You can also create your own
model to text transformation in Rational Software Architect. These transformations are
reusable assets that help improve developer productivity. For a detailed discussion about
pattern assets, refer to Part 4, “Patterns” on page 455 in this book.
Tooling considerations
Rational Software Architect is the tool that is primarily used for specifying services. UML is a
generic language, designed for all possible software systems, applications, and solutions.
Although it is possible to represent services using only UML, it is a better idea to use a
specific profile designed for services, because it specializes the modeling language to the
Chapter 13. Producing service assets
369
task. Therefore, when we need to represent, analyze, and design an SOA solution with IBM
Rational modeling tools, we can use the UML profile for Software Services.
We recommend that you use this profile mainly in conjunction with the service identification
and service specification phases of SOMA, but not with the service realization phase.
Therefore, services are identified and specified here. Even if this specification is well detailed,
it does not represent a White box view or realization of services.
This profile extends an existing UML element (we can call them meta classes) by defining new
stereotypes that provide additional semantic and visual representation on UML meta classes.
In Figure 13-4, we can observe these stereotypes and which meta classes they extend. Refer
to the official documentation for the formal specifications of this profile.
Figure 13-4 UML Profile for Software Services
Note: In Version 6 of the Rational Software Architect, this profile was provided as a tool
add-in (through IBM developerWorks). In Rational Software Architect Version 7, this profile
is provided automatically with the product. For a complete description of the profile, refer
to:
http://www-128.ibm.com/developerworks/rational/library/05/419_soa/
Note that there are few differences between Rational Software Architect Version 6 and 7 for
this profile; stereotypes, such as <<serviceModel>>, have been added in Rational
Software Architect V7.
370
Strategic Reuse with Asset-Based Development
13.2.3 Service realization
The realization phase in SOMA is focused on the completion of component design to be
ready for component implementation. This phase involves making realization decisions for
each of the service components that have been identified and specified in the earlier phases
of SOMA. These decisions are beyond the “buy versus build” decisions that involve the
selection of one of the several ways of realizing a service, such as wrapping existing
functionality, subscribing to a service that provides the functionality, and so forth. As a best
practice, SOMA recommends the service model be realized using a design model. This
provides the ability for the designer and implementer to apply patterns to the design model
and model additional capabilities and structures before generating implementation artifacts.
Fine-grained mapping of existing assets
You must not forget that few solutions are built without consideration to existing applications
that either will provide functionality to support the solution or with which the solution must
interact. Therefore, it is vital that existing applications that will be reused as part of any
solution are cataloged, and their functionality is identified. With a service-oriented solution,
there are multiple ways to integrate new services with existing functionality. We demonstrate
the following methods in Figure 13-5:
Wrap existing function as a service. In this case, we are want to leave the function as
is, but use tools or middleware to expose the existing function as a service. For example,
IBM provides the capability to expose existing CICS transactions as SOAP Web services.
Wrap and replace existing function with a service. In this case, we wrap a function as
we have just done, but we use the resulting service specification to redevelop the service
at a later date, replacing the original service and having clients redirected to the new
implementation.
Use an adapter more amenable to service invocation. In certain cases, it is not
possible to wrap a function and expose it as a service, but it might be possible to wrap the
function in something that you can integrate, such as a message queuing interface or the
Java Connector Architecture (JCA). This action allows new services to access the function
in place.
Integrate the function into the service. Obviously in certain cases, it is possible for the
new service to access the existing function in place, simply using the function as a logical
component within the implementation of the service.
Figure 13-5 Fine-grained mapping of existing assets
The third and fourth options provide the most flexibility, because they use the existing
function but do not continue to expose the function “as is” to clients. However, the first and
second options can introduce issues with wrapping existing functions as services, because
the performance of Web service protocols and mismatches between native data formats and
XML can introduce performance concerns.
Chapter 13. Producing service assets
371
You need to analyze existing software assets and their dependencies and interfaces in order
to determine if changes are required to support the business functionality. For example, in
order to create a Web services interface for an existing implementation of a business
function, analysis might involve the examination of the composition and flow of online
transactions or batch jobs, or persistent data stores that help perform that function. The
current design of these existing applications might need to change to support the
functionality. You also need to identify any potential barriers to creating a Web services
interface with the desired quality of service. For example, a monolithic batch implementation
of a business function might require sub-second response time when invoked as a service.
In certain cases, however, it is expedient to develop an existing service partition where a set
of low-level existing functions are exposed individually as services. This partition is only
accessible to higher level services that utilize the functions in presenting a more granular
business-aligned specification to consumers. This encapsulation of the existing functions
must be seen as a temporary solution and must only be undertaken if the performance
characteristics of the wrapping technology is well understood.
During the realization of assets, it is important to know the layer in the architecture to which
the service will be reused. Knowing the layers in which their asset resides, developers know
on what services they can rely in the coding environment. As a rule, components must not
make use of features provided by components on a higher layer, because this makes it
difficult to replace the higher layers without changing the lower ones.
Addressing reuse challenges with WebSphere Studio Asset Analyzer
The basic rationale for WebSphere Studio Asset Analyzer and other tools, such as Asset
Transformation Workbench, is to help address the technical challenges related to “change
complexity” involved in reusing existing assets. By automating portions of the analysis and
transformation process, the cost of the exercise of changing existing software for reuse might
drop to the point where it becomes feasible to modernize and transform applications in ways
that were not feasible when using the previous manual method.
WebSphere Studio Asset Analyzer can be used to address reuse challenges caused by
technical factors, such as:
Intellectual control: Certain applications in your organization are probably better
understood than other applications. How well applications are understood can be a
function of whether your team has spent time working with them recently, the quality of
your documentation, and the application’s size and complexity. When you do not have
sufficient knowledge about an application, the risk and cost of transforming it is higher.
The knowledge gap can involve basic information, including:
–
–
–
–
What programs make up your application
What data these programs use
What interfaces are available today
Where the business logic (rules) reside
Intermingled business logic: The business logic that you want to use might be sprinkled
across a number of programs and intermingled with screen or data I/O and related data
validation, which can make it more difficult to isolate for reuse.
Application pattern: Your application’s pattern might not be optimal for the kind of reuse
that you want to perform. In particular, you might have business tasks handled in batch
mode, which complicates the effort to offer them as synchronous services. Here are
examples:
– Your application writes transactions to a journal, and the journal is then processed in
batch mode at a later time, typically at night.
– Multiple business tasks are done in one job step as an optimization of I/O processing
372
Strategic Reuse with Asset-Based Development
– Your batch application assumes data transformations in a specific sequence, that is, A
and B must run before C, but you only want to reuse C in your service.
– Data might not be immediately accessible, for example, if the application uses
sequential files; your program must read the file from the beginning.
Run unit remediation
Whether starting with data or applications, an analyst or developer can use WebSphere
Studio Asset Analyzer to review the run unit to determine what modifications (if any) are
required before reusing the run unit. Additional work that might be required can include:
Identifying data validation assumptions from screen interactions and ensuring that the
data validation is done somewhere, potentially as part of the contract with the calling
service
Separating the business logic that you want to reuse from what is not relevant
Finding business rules that span a single source module and grouping them in a way that
enables reuse
Removing screen calls down in a call chain and replacing the screen calls with error return
codes
WebSphere Studio Asset Analyzer provides information to the analyst or developer to enable
the analyst or developer to manually do these remediations. WebSphere Studio Asset
Analyzer’s companion product, the IBM Asset Transformation Workbench, can help to
automate many of these activities.
If you have used WebSphere Studio Asset Analyzer to identify existing assets for reuse, you
can use the program structure diagram and the graphic runtime flow diagram in WebSphere
Studio Asset Analyzer to understand the dependency between the assets.
Tooling considerations
Rational Software Architect’s modeling, patterns, and transformation capabilities are used in
the SOMA realization phase. Service components and their relationships are designed in
UML by using relevant design patterns and are prepared for transformation to the next level
of abstraction by using the appropriate profiles.
13.3 Creating a composite business service asset
This section gives you an overview of the various activities that are involved in developing
Composite Business Services. It is out of the scope of this book to provide a step-by-step
detail of the various tasks involved in developing a composite business service. However, this
section intends to provide a high-level summary of the tasks to show how Composite
Business Services can be composed from existing assets and to highlight the attributes of the
composite business service that make it easy to reuse.
This section includes the following key activities:
Modeling a composite business service
Assembling a composite business service
Deploying a composite business service
We describe the management of service assets in Chapter 14, “Consuming service assets”
on page 399.
Chapter 13. Producing service assets
373
13.3.1 Modeling a composite business service
Composite Business Services are modelled using the SOMA process. We described the
SOMA process with supported tooling with an emphasis on Asset-Based Development in the
section 13.2, “SOMA insights for asset development” on page 360.
This section provides further insights on SOMA from a composite business service
perspective.
As mentioned earlier, existing assets can be identified and analyzed during the identification
phase for reuse by the current composite business service. The WebSphere Business
Services Fabric Industry Content Packs contain reusable assets in the form of
industry-specific business services, basic Web services, interfaces, and business models.
The assets within the Industry Content Packs are based on standards, and while modeling
Composite Business Services using these assets, you can closely align with the standards. In
addition, sample reference implementation is provided within the Industry Content Packs
showing how these assets collectively can be used to create an SOA solution. Identifying the
industry content pack assets that can be reused in a composite business service has an
impact on the development time, quality, and reliability of the composite business service. For
more information about reusing the industry content pack assets, refer to Chapter 12,
“Introduction to service assets” on page 335.
The business process is one of the core pieces in an SOA implementation. As a reusable
asset, a composite business service provides generic implementation for part of a larger
business process. The business process that the composite business service implements is
modeled using the WebSphere Business Modeler tool. Models by themselves are reusable
assets. If the process models from the business services that are used to compose the
composite business service are maintained in an asset Repository, they can be reused to
create the models for the composite business service and thus reduce the modeling time.
The model is created by business analysts and IT architects and gives a business
perspective of the process. It forms the basis for identifying potential services which work
together to accomplish the process. In order to identify candidate services from functionality
in existing applications, the relationship between the business process and existing
applications must be understood. Refer to the RUP/SOMA plug-in for RMC for more details
about how to perform this mapping.
You can visualize the business process model created in WebSphere Business Modeler in
UML. Rational Software Modeler (or Rational Software Architect) accesses the Business
Modeler project and creates the UML business use case and skeleton business use case
realizations. This is useful to allow the users of Software Modeler to see the business process
models in UML format.
In addition to the Existing Asset Analysis, you can use the other techniques for service
identification described in the RUP/SOMA to identify the services that are required by a
composite business service.
During the specification phase of a composite business service, in addition to the obvious
SOMA tasks of designing the interfaces, their dependencies, exposure details, namespaces,
and so forth, it is important to specify the policies and assertions that are relevant to the
scope of the composite business service.
You can use these policies to define the dynamic behavior of the composite business service
at run time. The definition of these policies can require that you define certain assertions. You
need to identify and document whether to reuse an assertion from the Industry Content Pack
or to extend the domain ontology with new assertions.
374
Strategic Reuse with Asset-Based Development
You can make the realization decisions for the services. The WebSphere Business Services
Fabric Industry Content Packs provide interfaces for services without providing the
implementation. This avoids multiple interfaces for the same service to be published to the
Repository for potential service clients to look up, while allowing different applications to
provide custom implementations. Realization decisions need to be made on the
implementation of these services. The functionality for this type of a service can be provided
by open source software or a commercial product that can be wrapped as a service, in which
case, the decision might have been made as part of the identification phase.
The implementation of the composite business service is preceded by the detailed design
activities similar to those performed for traditional J2EE applications using the principles of
object-oriented analysis and design. This can require the use of design patterns, which is
detailed in Part 4, “Patterns” on page 455 of this book. The data model might be designed for
the composite business service using Rational Data Architect. The inputs and outputs of the
services that were specified in the service model can be used as input for designing the data
model for the composite business service.
13.3.2 Assembling a composite business service
Assembling a composite business service involves the following tasks:
Implementing the business process choreography
Implementing the services and the user interface
Assembling the composite business service in WebSphere Business Services Fabric
Tip: The WebSphere Business Services Fabric leverages the Service Component
Architecture (SCA) programming model, and the process can be implemented using
Business Process Execution Language (BPEL).
The model from the Business Modeler tool is exported as a BPEL file. This file acts as the
basis for the development team to implement the composite business service. This BPEL file
is imported into WebSphere Integration Developer tool. Integration Developer provides a
visual interface to create and edit BPELs. As an architect or a developer working on the
BPEL, you might never have to see or know the contents inside a physical BPEL file.
WebSphere Integration Developer provides an easy to use drag-and-drop-based interface to
work with BPELs.
Note: While the BPEL for the business process can be created from scratch in WebSphere
Integration Developer, using the process model exported from the Modeler increases the
accuracy of the transition of the model from business to IT and also reduces the
implementation time.
Because Composite Business Services are compositions of business services, the simplest
composite business service is a straightforward wiring of these business services to
accomplish the business goal of the composite business service. However, typically there are
additional services that might be required as part of the choreography. The BPELs of the
existing business services are reusable assets, which might be reused as part of the
choreography for the composite business service. This is implied by the fact that the business
process models of the business services are reused in creating the models for the composite
business service.
The BPEL now needs to be completed by attaching the interfaces to the partner links to the
various activities in it. This requires interfaces (WSDL files) and data types (XSD files) to be
created. The UML representation of the service model from the SOMA process as described
Chapter 13. Producing service assets
375
earlier in the section 13.2, “SOMA insights for asset development” on page 360 can be used
as input for the transformation capabilities in Rational Software Architect to transform the
services to WSDL files and Java skeleton implementations. Figure 13-6 shows the typical
transformations that you can use to move from one level of abstraction to the next.
Figure 13-6 Using transformations to convert models to code
Figure 13-6 shows that the service model can be transformed to WSDL files, and Web
service skeleton code can be generated using these WSDL documents. Also, the design
model, which contains the detailed designs for each of the service-oriented parts in the
service model, namely, the service consumers and service providers, can also be
transformed to source code using transformations in Rational Software Architect.
You can also create your own model to text transformations in Rational Software Architect
and reuse them as assets. For more information about how to create your own
transformations, refer to Part 4, “Patterns” on page 455 of this book.
Note: For detailed information about how to use the features of Rational Software
Architect for performing the SOMA tasks, refer to Building SOA Solutions Using Rational
SDP, SG24-7356, at:
http://www.redbooks.ibm.com/abstracts/sg247356.html?Open
The interfaces and datatypes are used for several tasks during development:
The interfaces are attached to the partner links in the BPEL. The data types are used for
typing the various variables in the BPEL.
They are used to generate the implementation for the services in Integration Developer.
These documents are used by Integration Developer to generate the corresponding Java
source code files.
They form the basis for invoking the services that are defined in the interfaces. This
means that all service clients will use these documents to invoke the service.
These documents are used in assembling business services and their composites using
the Composition Studio tool that is part of the WebSphere Business Services Fabric.
376
Strategic Reuse with Asset-Based Development
When the service has been implemented and is ready for deployment, these documents
are published to the WebSphere Service Registry and Repository to serve as runtime
metadata for clients that might want to use the service.
Note: Care must be taken to use the correct namespaces and names for the various
elements in the WSDL and XSD documents, because they are reused in several other
tasks during development. Changes to these documents at a later point of time have an
impact on various pieces of the solution. A complete and reviewed service model
document can help you produce these artifacts correctly. The service model might have
identified the existence of service interfaces (and implementations) in the WebSphere
Business Services Fabric Industry Content Packs or in the asset Repository. These
interfaces need to be sourced from the identified sources for reuse.
After the BPEL is complete, you have to create the SCA assembly for the composite business
service in the Integration Developer. The assembly diagram will give you an end-to-end view
of the composite business service, with the business process wired to all of the referenced
services in it. The assembly diagram is used to provide the implementation details, such as
the binding information, the endpoints, and other transaction details for the services
referenced by the BPEL.
Tip: The BPEL process that is implemented is a generalized process. The BPEL process
designed until now does not have dynamic capability support. For example, there is no
conditional logic provided in a BPEL process to determine which set of services to call if
the customer is a gold level customer compared to a silver level customer. If you are using
the WebSphere Business Services Fabric and require dynamic capability support, you
need to use the SCA Dynamic Assembler component in Assembly editor while composing
the application. WebSphere Business Services Fabric leverages the SCA model and
provides a Dynamic Assembler component, which simplifies the business service
programming model.
Using the SCA Dynamic Assembler component eliminates the static binding between
service consumers and the service provider. The SCA Dynamic Assembler enables
dynamic policy assembly and service selection based on the context, content, and
contract. The SCA Dynamic Assembler provides business agility through the policy-driven
runtime assembly of business services.
You can test the BPEL in the integrated test environment by using Integration Developer,
without having to provide an implementation for all of the services. The Integration Developer
gives you the option to use emulators for the services referenced by the BPEL. Alternatively,
you can provide mock implementations for the services and use them to test the correctness
of the flow of the BPEL.
The composition of a composite business service can be tested through mock services and
emulators without having any knowledge of how the service has been or will be implemented
in reality. This decoupling of the choreography from the actual implementation of the services
makes Composite Business Services flexible SOA assets that allow the business process to
be changed at any time without having to consider the technicalities of the actual service
implementation.
Implementing the services and the user interface
Integration Developer provides a feature to create the implementation files for a service from
the interface (WSDL) and datatypes (XSD) that were used by the process choreography.
These files can be used by application developers as the starting point for coding the
business logic.
Chapter 13. Producing service assets
377
The implementation is usually based on micro design that is based on traditional
object-oriented analysis and design using artifacts, such as the class diagram, sequence
diagram, and design patterns. As shown in Figure 13-6 on page 376, you can use the
transformation features in Rational Software Architect to generate skeletons for your services
from the design model.
The server-side implementation of the composite business service is independent of the
presentation layer that can be used as the front end for the composite business service. Any
technology or framework that is capable of locating and executing the composite business
service can be used to implement the user interface for the composite business service. The
composite business service is usually exposed as a Web service using SOAP/HTTP.
WebSphere Business Services Fabric
Assembling the composite business service involves the creation of business level service
metadata for the composite business service and publishing it to the business service
Repository through the WebSphere Business Services Fabric governance process. It
involves the following key activities:
1. Use the WebSphere Business Services Fabric tools to create service metadata, such as
channels, roles, and policies. Configure the WebSphere Business Services Fabric using
the governance manager. This involves creating the organization, roles, namespaces,
business service project, and other related metadata.
2. Import the SCA module into Composition Studio.
3. Attach channels, roles, and assertions to the various services in the composite business
service.
4. Create the policy assertions, which are policies that were identified during the
identification and specification of services in SOMA, by using the Composition Studio.
5. After all of the business-centric service metadata has been created in the Composition
Studio, you have to publish it to the business service Repository through a governance
process. The governance process ensures that the business services and metadata
created by the users follow a review process and eventually get published to the business
service Repository or get rejected back to the user who submitted them.
6. When the service metadata has been published to the business service Repository, you
can configure the SCA assembly to use the dynamic assembler to route service requests
using the Integration Developer. The dynamic assembler selects suitable endpoints for the
service requests based on the context, content, and contract attached to the service
request.
Thus, you can see that the composite business service externalizes business level service
metadata, such as channels, roles, policies, assertions, and so forth, to a Repository giving
the Asset Consumer the flexibility to change them during consumption without having to
change the existing code or write new code.
For example, policies based on non-functional requirements, such as performance, reliability,
interoperability, security, and manageability, are created in the Composition Studio and
stored in the business service Repository. The composite business service then uses the
WebSphere Business Services Fabric dynamic assembler to select the correct endpoint
based on the context and content of a specific request. This separates the business logic
required to implement the non-functional requirements from the BPEL and from the service
implementation code. This makes it easy to reuse the composite business service in different
business environments, because changing these policies does not require any code
changes.
378
Strategic Reuse with Asset-Based Development
Note: If you use the WebSphere Service Registry and Repository for registering services
deployed in your organization, you can source the interfaces and data types from the
WebSphere Service Registry and Repository.
Figure 13-7 summarizes the composite business service development tasks.
Figure 13-7 Producing composite business service assets
As seen in Figure 13-7, the business process model in WebSphere Business Modeler is
exported as a BPEL, which is imported into the WebSphere Integration Developer. The BPEL
and SCA assembly wiring are completed in parallel with service implementation in the
WebSphere Integration Developer. The composite business service is then assembled in the
Composition Studio and published to the business services Repository. Figure 13-7 also
shows that the service metadata can be sourced from WebSphere Service Registry and
Repository. Service invocations in the BPEL are routed through the dynamic assembler,
which at run time, selects a suitable endpoint based on the context, content, and the contract
associated with the request.
The Rational Asset Manager is shown as the central Repository where all service artifacts are
stored. The business process models, service interfaces, implementation artifacts, and
reusable metadata in the form of ontology files that are used through the rest of the
composite business service creation process can be sourced from the Rational Asset
Manager. The Rational Asset Manager Eclipse plug-in helps developers source the relevant
Chapter 13. Producing service assets
379
assets in WebSphere Integration Developer. Rational Asset Manager can be integrated with
WebSphere Service Registry and Repository to publish and synchronize service metadata
with the service Repository. These links between the products are not shown explicitly in
Figure 13-7 on page 379.
13.3.3 Deploying a composite business service
A composite business service is typically packaged as set of J2EE applications. These
applications contain the SCA modules, service interfaces, implementations (WAR files), and
components that can be used by the service implementation. These applications are
deployed on WebSphere Process Server. You configure WebSphere Process Server and
other middleware based on the requirements of the composite business service just as you
do for traditional J2EE applications.
The WebSphere Business Services Fabric needs to be configured with the service metadata
for the composite business service to dynamically locate and execute the services. This
metadata is exported as .fca (fabric content archive) files from the business service
Repository using the WebSphere Business Services Fabric tools and packaged along with
the composite business service deployables.
The composite business service asset typically contains the following artifacts:
The source code for the asset, which includes service implementations, generated code
for the process implementation, user interfaces, and other code artifacts
The service metadata for the WebSphere Business Services Fabric (.fca files, which
contain the channels, roles, policies, and so forth for the composite business service)
The scripts to build source code and configure the Process Server and other middleware
that might be required for the composite business service to run (such as DB2, MQ, and
so forth)
The asset documentation
Packaged assets can be published to the Rational Asset Manager Repository. For more
information about publishing the assets to the Repository and for management aspects of
service assets, refer to Chapter 15, “Managing service assets” on page 425 in this book.
We describe customizing the composite business service for consumption in detail in
Chapter 14, “Consuming service assets” on page 399.
13.4 Testing service assets in an SOA
Testing SOA applications introduces unique challenges that are not found in traditional
applications. However, the scope of this book is limited to testing individual services rather
than testing applications based on SOA.
From an Asset-Based Development perspective, consider the following insights while testing
services in an SOA.
Testing for reusability
As it has been mentioned several times in this book, services are treated as reusable assets
in an SOA. Hence, the tests performed on services need to test for reusability of services.
Services can be reused in different styles, as a Black box, White box, or Gray box. We
380
Strategic Reuse with Asset-Based Development
describe these styles further in Chapter 14, “Consuming service assets” on page 399. Test
cases can be written based on the reuse style of the service.
Industry standards are key drivers for reusability. Using relevant industry standards enhances
the chances of reusability of a service. For example, Web services can follow the Web
Services Interoperability Organization (WS-I) standards to ensure that they are interoperable
across multiple platforms. WS-I is an open industry organization chartered to promote Web
services interoperability across platforms, operating systems, and programming languages.
Test cases can be written to ensure relevant standards compliance.
Potential consumers can use any of the various points of variability of the services that awe
describe in Chapter 14, “Consuming service assets” on page 399. Test cases must be written
to test these various points of variability.
Because reusable assets services can be deployed in a variety of target environments, test
cases can be written to test the services in the various environments in which they are
expected to be reused. This can involve various client technology and operational
environment considerations.
Testing services at various levels
You might have to test services at various levels: service components, atomic and composite
services, business composition, and end-to-end. Testing at each level enables you to locate
and fix defects at the point where they were introduced, which helps you find and fix defects
early. Testing must be an iterative process that continues throughout the life cycle of the
application. Code reviews and inspections must be done for each code drop along with unit
and regression testing.
Service composition tests do not need to wait all of the service implementations that are part
of the composition are available for testing. The composition can be tested using mock
services that simulate the behavior of the actual service using the interfaces that have been
specified during the design stage.
Testing Composite Business Services poses challenges that are close to those that are found
in the end-to-end testing of full-fledged applications. Beyond testing the process automation,
the ability to access the service through multiple channels, the dynamic behavior of the
service based on the various contexts and content of the service request, and the policies
that govern this dynamic behavior all need to be tested. For example, Composite Business
Services using the Web portal channel might have to be tested for compatibility with multiple
browsers. Consider another example where there might be a policy governing the business
service that directs specific high priority customers to a high performance service. Test cases
need to ensure that the composite business service adapts its behavior at run time and
selects a suitable service to process a request.
Composite Business Services might also have to be tested for non-functional requirements.
However, these requirements differ based on the consuming application. A best practice is to
document a set of benchmarks based on historical information and the industry trends about
what type of requirements are expected in the consuming environment and test the asset
against those benchmarks. For example, a specific industry trend is around 10000 real-time
requests through the portal channel per minute with 24x7 availability. The consuming
applications might have slightly different requirements and different operational
environments. However, by testing the composite business service based on known trends
and the most common and expected operational environments, the chances of its reusability
get enhanced.
Chapter 13. Producing service assets
381
13.4.1 IBM products for SOA testing
The IBM Rational Software Development Platform (SDP) supports SOA testing with a
portfolio of modular, open standard base products. Use the following tables to help determine
the tools that can assist you in unit, functional, and system testing.
Tools to assist in unit testing are shown in Table 13-2.
Table 13-2 Tools to assist in unit testing
Area
Tools
Defect management/metrics
Rational ClearQuest
Performance
Rational Performance Tester
Code inspector/static analysis
Rational Application Developer: Code
Review
Java Runtime analysis metrics
Rational PurifyPlus™
Rational Application Developer
Test automation
Rational Application Developer with
Rational Component Test Automation
Rational Functional Tester
Test management
Rational ClearQuest
Rational Manual Tester
Change management
Rational ClearCase
Requirements tracking
Rational Requisite® Pro
Tools to assist in functional testing are shown in Table 13-3.
Table 13-3 Tools to assist in functional testing
Area
Tools
Source control/change management
Rational ClearCase
Defect tracking
Rational ClearQuest
Test management
Rational ClearQuest
Rational Manual Tester
Test automation
Rational Functional Tester
Code inspection
Rational Application Developer: Code
Review
Metrics
Rational ClearQuest
Rational PureCoverage®
Rational Application Developer
Tools to assist in system testing are shown in Table 13-4.
Table 13-4 Tools to assist in system testing
382
Area
Tools
Defect management
Rational ClearQuest
Performance
Rational Performance Tester
Strategic Reuse with Asset-Based Development
Area
Tools
Test automation
Rational Functional Tester
Test management
Rational Test Manager
Rational Manual Tester
Metrics and reporting
Rational Project Console (Dashboard)
Requirements tracking
Rational Requisite Pro
Customer interaction programs
Design reviews, residency, and visitations
Change management
Rational ClearCase
Note: For more information about these tools, refer to Building SOA Solutions Using
Rational SDP, SG24-7356, at:
http://www.redbooks.ibm.com/abstracts/sg247356.html?Open
13.5 Publishing service assets to the Repository
Next, we discuss publishing service assets to the Repository.
13.5.1 Repositories in the life of a service asset
In Chapter 1, “Introduction to Asset-Based Development” on page 3, 1.6, “Asset repositories”
on page 12 mentions the importance of an asset Repository in an Asset-Based Development
environment. This section highlighted the benefits of using a Repository, such as Rational
Asset Manager, and mentioned the use of a Repository for services in an SOA. During their
life cycle, service assets are stored and managed in various repositories (in addition to the
Rational Asset Manager) serving different purposes. In this chapter, you learn about many of
the key repositories that are used during the lifetime of a service and also the relationships
between them.
Rational Asset Manager is a development time registry containing assets that are used by
development teams. When service assets are produced, they are moved into the Rational
Asset Manager Repository. Developers can search and source reusable assets from the
Rational Asset Manager during the development process.
Service-oriented applications at run time might need to find services suitable for their
business requirement based on QoS factors or certain business policies. Services might
need to be monitored at an enterprise level for various metrics. WebSphere Service Registry
and Repository, which is a service metadata Repository, establishes a central location for
finding and managing service metadata acquired from a number of sources, including service
application deployments and other service metadata and endpoint registries and repositories.
It is where service metadata that is scattered across an enterprise is brought together to
provide a single, comprehensive description of a service. When that happens, visibility is
controlled, versions are managed, proposed changes are analyzed and communicated,
usage is monitored, and other parts of the SOA foundation can access service metadata with
the confidence that they have found the single, correct copy of record. In this context, the
WebSphere Service Registry and Repository handles the metadata management aspects of
operational services and provides the system of record of these metadata artifacts - the place
where anybody looking for a catalog of all services deployed in or used by the enterprise
Chapter 13. Producing service assets
383
goes first. Hence, when a service asset that has been published to the Rational Asset
Manager is ready for deployment, the service metadata might be published to the
WebSphere Service Registry and Repository. When a Rational Asset Manager asset’s
artifacts are passed onto the WebSphere Service Registry and Repository, they are now
owned and managed in the WebSphere Service Registry and Repository as runtime
documents.
The definition of a service in this respect is broad, including:
Traditional Web services implementing WSDL interfaces with SOAP/HTTP bindings
A broad range of SOA services that can be described using WSDL, XSD, and WS-Policy
decorations, but might use a range of protocols and be implemented according to a variety
of programming models
Business services and Composite Business Services are business level services, which
contain service metadata from a business perspective. Beyond the technical metadata, there
are interfaces and data types of a service and there are business services that include
metadata, such as channels, roles, and so forth. WebSphere Business Services Fabric as a
platform for assembling Composite Business Services contains a Repository called the
business service Repository for storing business service metadata. Developers assembling
Composite Business Services can source the technical service metadata from the
WebSphere Service Registry and Repository into the business service Repository and add
business context information to compose business services. After passing through a
governance process, the service metadata for the business services gets stored in the
business service Repository. At run time, Composite Business Services use this metadata for
the dynamic selection of endpoints based on the business context, content, and contract
metadata associated with the business service.
For more information about using WebSphere Service Registry and Repository with
WebSphere Business Services Fabric, refer to Chapter 14, “Consuming service assets” on
page 399.
Note: During the development of a service, the service artifacts are typically maintained in
a configuration management system, such as Rational ClearCase. The services are
maintained in Rational ClearCase until they are developed and tested. This approach is
not unique to services; it is true across all types of assets.
This section discusses only the primary repositories that are relevant to services. For
detailed information about Rational Asset Manager and Rational ClearCase positioning
and integration, refer to Appendix A, “Rational Asset Manager: Installation and
administration” on page 637.
The three repositories are used for three distinct purposes during the life cycle of a service
asset, as shown in Figure 13-8 on page 385.
384
Strategic Reuse with Asset-Based Development
Figure 13-8 Repositories in the life of a service
The following points summarize the distinction between the Rational Asset Manager and the
WebSphere Service Registry and Repository:
The Rational Asset Manager is seen as a development time registry targeted at
development teams and the WebSphere Service Registry and Repository is a runtime
registry that deals with documents and logical services derived from the service artifacts in
the Rational Asset Manager. WebSphere Service Registry and Repository does not
contain all service artifacts, such as the service implementation files. These service
implementation files are stored in the Rational Asset Manager. Only the service metadata
is published from the Rational Asset Manager to the WebSphere Service Registry and
Repository.
When a Rational Asset Manager asset’s artifacts are passed onto the WebSphere Service
Registry and Repository, they are free to change and to be governed as needed by the
runtime organization. However, it is useful for both development and the runtime
organization to preserve linkages between the development assets and their runtime
counterpart documents. This way you can understand the linkages between developed
assets and the deployed documents.
Rational Asset Manager manages information that is useful for developing, reusing, and
managing all types of reusable assets. It gives you the ability to define asset types, create
and manage assets, and provide traceability and details, and includes collaboration
software. WebSphere Service Registry and Repository manages information that is useful
for the runtime operation, management, and development use of services. It gives you the
ability to select service endpoints dynamically in an SOA run time, govern runtime
changes to service metadata, set and get runtime policies for service execution, and get
deployed service details, such as endpoints and service definitions. Together, the two
Chapter 13. Producing service assets
385
products create seamless, reusable asset tracking mechanisms through development and
runtime activities.
The following points summarize the distinction between the WebSphere Business Services
Fabric and the WebSphere Service Registry and Repository:
WebSphere Service Registry and Repository does not manage all service metadata, and
it does not manage service metadata across the whole SOA life cycle. It focuses on a
minimalist set of metadata that describes capabilities, requirements, and the semantics of
deployed service endpoints. It interacts and federates with other metadata stores that play
a role in managing the overall life cycle of a service. The business service Repository in
the WebSphere Business Services Fabric contains business-related metadata and
industry semantic models for use in dynamic service selection and assembly. The
business service Repository includes business-related policies, semantics, metadata, and
subscriptions. The WebSphere Business Services Fabric leverages and extends the
WebSphere Service Registry and Repository to source technical service metadata
information and provides business context through the use of the business service
Repository.
The integration between the WebSphere Service Registry and Repository and the
WebSphere Business Services Fabric is a convenience mechanism in the WebSphere
Business Services Fabric to source the service metadata from a central location and to
accelerate the assembly of Composite Business Services. It does not result in physical
links that can be used to navigate from the metadata in the WebSphere Service Registry
and Repository to the business metadata in the WebSphere Business Services Fabric
unlike the case of the WebSphere Service Registry and Repository and the Rational Asset
Manager integration.
13.5.2 Governance options for publishing services
The Asset-Based Development process guidance states that the service artifacts need to be
published to external repositories during the manage stage of the asset life cycle. However,
there are other valid options that can be considered while making decisions that govern at
which stage of the development process a service asset can be published to the various
repositories. Here are two options:
Maintain the service life cycle in WebSphere Service Registry and Repository and publish
the tested asset to Rational Asset Manager.
WebSphere Service Registry and Repository supports life cycle management of services.
This means that right from the stage of modeling and design to deployment and
management, the service resides in WebSphere Service Registry and Repository. You
can leverage this feature in WebSphere Service Registry and Repository and publish your
service metadata to WebSphere Service Registry and Repository during the modeling
stage, when the services have been identified and specified. These services can be
governed with custom life cycle definitions in WebSphere Service Registry and
Repository, which indicate that the service is still not ready for runtime invocation but has
been defined. This makes the service visible to other project teams in the organization and
thus helps you avoid service proliferation. If you have configured Rational Asset Manager
with WebSphere Service Registry and Repository connection information, this metadata
can be replicated to Rational Asset Manager. Rational Asset Manager users can find
these services while searching for assets in Rational Asset Manager. By viewing the life
cycle status of the service in WebSphere Service Registry and Repository (by navigating a
link), users know that the service is still under development. They might, however, source
the metadata files for reuse in their applications.
The service as an asset is published to Rational Asset Manager when it has been
implemented and tested. At that stage of the project, the service metadata is already
386
Strategic Reuse with Asset-Based Development
present in WebSphere Service Registry and Repository, and hence, you do not have to
publish the service metadata artifacts to WebSphere Service Registry and Repository.
Important: A variation to this option is to publish the metadata early in the service life
cycle to Rational Asset Manager and then publish it to WebSphere Service Registry
and Repository for life cycle management. The other artifacts for the service asset can
be updated when they have been developed and tested. While this is a technically
feasible option, we do not recommend that you follow this path, because the service
metadata that is published in the early stages of the service is likely to change.
We recommend that you store only tested and reviewed assets in Rational Asset
Manager.
For the same reason, you might want to only replicate service metadata from services
that have matured enough for reuse from WebSphere Service Registry and Repository
to Rational Asset Manager. You can achieve this by having multiple instances of
WebSphere Service Registry and Repository. Services, which are not yet in a state
where they can be reused, can be maintained in a separate instance of WebSphere
Service Registry and Repository. Service metadata from this instance must not be
replicated into Rational Asset Manager.
Publish the tested asset to Rational Asset Manager and publish service metadata to
WebSphere Service Registry and Repository.
In this option, you can publish service assets to any of the repositories only when they
have been developed and tested. These assets are published to Rational Asset Manager.
You can then publish the necessary metadata to WebSphere Service Registry and
Repository. This option does not make good use of the service life cycle management
feature in WebSphere Service Registry and Repository.
In situations where the services are not developed from scratch, they are first published to
Rational Asset Manager as assets and then published to WebSphere Service Registry
and Repository. These cases are common when services are sourced from third parties,
open source resources, or from software resulting from acquisitions.
Note: In both of these governance options, technical service metadata to assemble
Composite Business Services can be ideally sourced in WebSphere Business Services
Fabric from WebSphere Service Registry and Repository.
13.5.3 Publishing assets to Rational Asset Manager
Assets that have been developed and tested can be published to the Rational Asset Manager
Repository. We describe the details of how to publish an asset to the Repository in Part 2,
“Reusable Assets” on page 123 of this book. This section mentions things to consider while
using Rational Asset Manager as a Repository for publishing service assets.
Rational Asset Manager is shipped with a data model for managing SOA-based assets. This
model contains communities, asset types, asset categories, and other configuration elements
that are relevant for an organization that contains SOA-based assets. This model can be
used as a starting point to configure the Rational Asset Manager to manage assets in an
SOA. It is expected to be extended to include attributes, categories, asset types, and other
asset configuration elements that suit your organizational needs.
Chapter 13. Producing service assets
387
Figure 13-9 shows the list of asset types, relationship types, asset attributes, and category
schemas in the sample SOA model for the Rational Asset Manager.
Figure 13-9 Configuration elements in the sample SOA model for Rational Asset Manager
As seen in Figure 13-9, the basic types that are typically required in an SOA implementation
have been included in the model. Figure 13-10 on page 389 gives a UML representation of
these asset types. It shows that a service interface asset can have implementations, design,
and test cases attached to it. It can fulfill architectural requirements and can also serve as the
contract for business processes. The artifacts from RUP/SOMA identification, specification,
and realization phases typically are business process and service design types. The
implementation assets fall under the service interface, service implementation, and
component types. Test cases are the Service Test type. Requirements and other higher level
architecture documents have their corresponding types defined as well.
Important: It is important to note that this model is not an exhaustive listing of the asset
types and other configuration elements for your SOA assets. It helps you get a jump start
in setting up the configuration for the SOA requirements in your organization.
388
Strategic Reuse with Asset-Based Development
Figure 13-10 Asset types in the sample SOA model for Rational Asset Manager
Figure 13-11 on page 390 shows the communities that are part of the sample SOA model for
Rational Asset Manager and the assets that are contained in them. These communities have
sample business processes, interfaces, and service documentation assets. You can create
new communities or customize these communities based on your organizational policies.
Chapter 13. Producing service assets
389
Figure 13-11 Communities and assets in the sample SOA model for Rational Asset Manager
The sample SOA Model for Rational Asset Manager also comes with three connection
configurations for development, test, and production WebSphere Service Registry and
Repository instances, which we do not show in Figure 13-11.
Extending the sample SOA model for Rational Asset Manager
The sample SOA model that ships with the Rational Asset Manager can be customized with
additional attributes and categories suitable for business services and Composite Business
Services. This section mentions many of the possible extensions. The intent of providing
these extensions is to help potential consumers looking for assets in the Rational Asset
Manager make a better decision about the usefulness of the asset for their requirement
without having to download and analyze it. This reduces the time that is spent trying to reuse
existing assets and hence the impact of a failed attempt to reuse.
Important: The best practices for defining a new asset types and attributes are detailed in
Part 2, “Reusable Assets” on page 123 of this book. Refer to these best practices before
proceeding with this section.
Asset type extensions
The sample SOA model for the Rational Asset Manager contains several asset types for an
SOA. This section mentions other possible service asset types that might be required in an
SOA. Whether to a create new asset type in the Rational Asset Manager for your asset
requires governance decisions with respect to organizational policies and the expected usage
of the Repository. Based on your organizational governance policies, you might have to use
390
Strategic Reuse with Asset-Based Development
these asset types. Alternatively, you might choose to use other metadata, such as asset
attributes, or a generic asset type to distinguish between the assets.
You can use the following guidelines to define custom service asset types in the Rational
Asset Manager:
Different service assets contain different artifacts. For example, a choreographed service
contains the process choreography files in addition to the candidate service interfaces and
their implementations. You might have to define an asset type for choreographed services
to lay a restriction on the artifacts that are published to the Rational Asset Manager. Based
on the type of the asset, the Rational Asset Manager has capabilities to check that the
correct artifacts are being published to the Repository.
A business service typically contains artifacts including a business process
implementation, service interfaces and implementations, service metadata (typically .fca
files for the WebSphere Business Services Fabric), and supporting documentation. The
artifacts for a composite business service are the same as that of a business service.
However, you might still want to define a custom type for Composite Business Services if
you have different access requirements for users of business services and users of
Composite Business Services. For example, if you want the Composite Business Services
to be published by the architects and not by programmers, you might have to create a
specific asset type for the two types of services.
In the Rational Asset Manager, you might want to relate the business services to
Composite Business Services or relate the Composite Business Services to the business
services, because Composite Business Services are by definition composites of business
services. This enables the Rational Asset Manager users to see what business services
are used in a specific composite business service or the compositions in which a particular
business service has participated (thus, reflecting the reusability of the asset). To be able
to define these relationships, the Rational Asset Manager requires you to define different
asset types for the participants in the relationship.
Based on your SOA implementation, you might want to define a type to hold ontologies.
Part 2, “Reusable Assets” on page 123 of this book details the basics of an ontology.
Ontologies are usually represented in Web Ontology Language (OWL) and the artifacts
that represent them are .owl files. Ontologies are used to represent the business object
models and business service metadata in WebSphere Business Services Fabric. The
Industry Content Packs ship with industry-specific ontologies. You can extend or define
the ontology for your industry. Furthermore, you can define your own service life cycles in
WebSphere Service Registry and Repository using ontologies. Defining an Ontology type
might help you to manage these ontology artifacts.
Tip: For a step-by-step guide for Administrators to create new classification systems and
life cycles for WebSphere Service Registry and Repository, go to:
http://www-128.ibm.com/developerworks/websphere/library/techarticles/0703_shore
/0703_shore.html
Asset attribute extensions
The possible attribute extensions to the SOA model for Rational Asset Manager are:
Supported channels: Business services and their composites typically support multiple
channels of access, such as Web portal, FTP, FAX, and so forth. The channels that are
supported by a business service can be a possible attribute for the business service asset.
Supported industry standards: Composite Business Services solve business problems
for a specific industry. They support different industry-specific data and messaging
Chapter 13. Producing service assets
391
standards, which can be another possible Rational Asset Manager attribute for the asset.
For example, possible values for a health care business service might be HIPAA or HL7.
Number of endpoints: Business services and their composites might have multiple
endpoints to access them. Typically, Rational Asset Manager users can use this as an
indication to know that the service has been enabled to adapt to different environments
based on context-based business policies. Note that this attribute can be used for basic
Web services as well. A variant form of this attribute indicates the number of services with
multiple endpoints which comprise a composite business service. This number is an
indication of the flexibility of the composite business service.
Business process type: The business process that is implemented by a composite
business service can be either a long running process with several human tasks, or it can
be a quick process that runs completely in a single invocation. This attribute helps the
Rational Asset Manager users to understand the complexity of the composite business
service, because long running processes typically run several days or weeks and hence
require system resources for longer durations than the short processes.
Requires open source or third-party software: This attribute can be used to indicate
that the composite business service uses open source or third-party software for its
service implementations. This can be used as an alert about additional costs and licensing
issues for potential consumers of the asset. Note that this attribute can be used for all
types of assets and not just service assets.
13.6 Case study: SOA service reuse at ZYX Electronics
This section starts the discussion regarding how ZYX Electronics configured and used
Rational Asset Manager and WebSphere Service Registry and Repository tools to produce,
consume, and manage service assets to transition to an SOA reuse approach. In this
chapter, our focus is on the production of service assets. Chapter 14, “Consuming service
assets” on page 399 focuses on how ZYX Electronics used these repositories to consume
service assets. Then, Chapter 15, “Managing service assets” on page 425 concludes the
discussion by looking at how ZYX Electronics used the repositories to manage service
assets.
To simplify the discussion, we focus only on how ZYX Electronics created, consumed, and
managed services from a reuse perspective, but we do not describe how these services were
built using other IBM tools, such as WebSphere Business Modeler, WebSphere Integration
Developer, and Rational Software Architect. We assume that the service artifacts have
already been produced using these tools, and we concentrate on how Rational Asset
Manager and WebSphere Service Registry and Repository helped ZYX Electronics to reuse
these services in the development and runtime environments.
13.6.1 Current state of service reuse at ZYX Electronics
Building on the discussion from Part 2, “Reusable Assets” on page 123, ZYX Electronics
continued with the deployment of Rational Asset Manager. In addition, as part of their SOA
adoption project that was also occurring, ZYX Electronics was already using WebSphere
Service Registry and Repository as a service registry for the runtime environment, but they
had many inconsistencies in the services that were developed. The issues encountered
included:
They did not have any standardization and projects created services using Web Services
Description Language (WSDL) files while other projects just used XML files to create other
services.
392
Strategic Reuse with Asset-Based Development
There was no mechanism in place to manage the development and publication of
services. As a result, developers were unable to find the code that was used to build the
services.
Experienced developers included a document explaining how to use the service, but most
of them just created the code and files to be deployed to the service registry without
verifying its quality.
So, following the incremental adoption of reuse that ZYX Electronics had selected to follow,
the next steps for the deployment of Rational Asset Manager at ZYX Electronics included:
Specifying new service asset types and associated metadata
Integrating with other WebSphere tools to help to transition to an SOA approach. This
helps business analysts, architects, developers, and service assemblers to manage and
control the life cycle of services.
Recall from earlier that Duncan Munchkin (Development Manager at ZYX Electronics) is
leading the reuse adoption initiative with support from Deon Adminio.
13.6.2 Rational Asset Manager configuration for ZYX Electronics
The initial Rational Asset Manager configuration created by Deon Adminio (Rational Asset
Manager Repository Administrator) and Duncan Munchkin (Development Manager) did not
include any information for managing SOA-based assets, so the first task that they had to
approach was to modify the Rational Asset Manager configuration.
After looking at the default SOA Model that ships with Rational Asset Manager, they decided
that it was a good idea to start using this basic model and extend it later just in case it was
needed. But, at least this initial configuration provides a simple base to begin to work with
SOA-based assets.
To load this SOA model and modify the Asset Manager configuration, Deon just had to go to
the Administrator tools and import this SOA Model. For a step-by-step guide of how to import
this SOA Model into Rational Asset Manager, go step 8, “Import predefined sample SOA
Model” of A.2.2, “Installing Rational Asset Manager Server” on page 648.
Duncan and Deon had created the initial Rational Asset Manager configuration for ZYX
Electronics in Chapter 8, “Configure your Asset Repository” on page 195. The SOA model
import created additional elements needed to manage SOA-based assets. The SOA model
import includes asset types and attributes for service design, interface, implementation, test
cases, and communities for service analysis, development, and testing teams. Figure 13-12
on page 394 provides an overview of the communities and assets in the sample SOA model
from Asset Manager.
Chapter 13. Producing service assets
393
Figure 13-12 Communities and assets in the sample SOA model for Rational Asset Manager
13.6.3 Produce and Publish service assets
To achieve the business goals of reducing costs and cycle times, ZYX Electronics had started
an initiative called “Business Process Optimization” to analyze and improve critical business
processes. Bob Analyn, the Business Service Analyst, was leading this team. The team had
used WebSphere Business Modeler to create “as is” models to represent the current state of
the services and “To-Be” models to represent a target state. The team created these “To-Be”
models by enhancing the “as is” models with improvements that they identified through
simulation and analysis.
As part of the SOA transformation process, the SOA team from ZYX Electronics followed the
SOMA process to identify candidate services for reuse. In the course of the analysis, they
discovered that account verification is a reusable business process across multiple
applications in the enterprise. In particular, the analysis helped Bob to discover that a new
service was needed to determine applicant eligibility. This process is called Determine
Applicant Eligibility and the service implementing this process choreography is called
EligibilityService.
To determine if another department had already created a similar business process model
that can be reused in the creation of the new service, Bob used Rational Asset Manager to
search for other business process models already developed and loaded into the Repository.
Bob logged on to the Rational Asset Manager Web client, selected the Search tab and used
the keyword “Eligibility” to search for assets related to the new service that Bob had to
create, as shown in Figure 13-13 on page 395.
394
Strategic Reuse with Asset-Based Development
Figure 13-13 Search assets related to “Eligibility”
Rational Asset Manager located two business process models in the Service Analysis
community. Bob reviewed the content and discussion forums attached to them and
discovered that one of the business process models that had been created, Account Opening
Business Process Model, was similar to what he required.
Bob downloaded the Account Opening Business Process Model asset and used it as a base
to model the new process model for the Determine Applicant Eligibility business process.
Because he had producer permission, when he finished modeling the new process model
with WebSphere Business Modeler, he created a new process model asset in Asset Manager
called Determine Applicant Eligibility, as shown in Figure 13-14.
Figure 13-14 Submit “Determine Application Eligibility business process model” asset
Chapter 13. Producing service assets
395
The Business Process asset type had associated the constraint of having at least one artifact
with a label of “ProcessModel” as shown in Figure 13-15. Therefore, Bob had to attach the
new process model files with the “ProcessModel” label.
Figure 13-15 Artifact constraint to business process asset types
As shown in Figure 13-16, Bob also created a relationship between both process model
assets (the old “Account Opening Business Process Model” and the new one that Bob
created) to make it clear that these assets were related. It must be clear to future users of the
Repository that there is a connection between these assets.
Figure 13-16 Create relationship between business process assets
Bob completed all asset information and verified that there were no errors in the information
provided. Note that Rational Asset Manager shows red messages when the constraints
associated to the asset type are not met. Next, Bob submitted the asset to the Repository,
and it followed the default review process configured in Rational Asset Manager. When the
review was accepted by the project manager, the new asset moved to the Approved state.
For more information about how you can configure and create the review process in Rational
Asset Manager, go to Chapter 9, “Produce reusable assets” on page 237.
396
Strategic Reuse with Asset-Based Development
After submitting the new process model to the Rational Asset Manager Repository, Bob sent
an e-mail to Al Aarkashan (the SOA architect at ZYX Electronics), as shown in Figure 13-17.
The purpose of the e-mail was to inform Al that there was a new asset submitted to Rational
Asset Manager for the Determine Applicant Eligibility business process, and Al can start to
create the requirements specification, design models, and initial implementation of this
service.
Figure 13-17 Bob sent an e-mail about the new business process asset to Al
Chapter 13. Producing service assets
397
398
Strategic Reuse with Asset-Based Development
14
Chapter 14.
Consuming service assets
This chapter provides details to consider during the consumption of services in a
service-oriented architecture (SOA).
This chapter discusses the following details:
Locating services for consumption
Consuming services from WebSphere Service Registry and Repository (WSRR) to
assemble Composite Business Services (CBSs)
Points of variability of service assets
Customizing Composite Business Services for consumption
Reusing services from the WebSphere Business Services Fabric Industry Content Pack
Providing service reuse feedback: using WebSphere Service Registry and Repository,
dynamic assembler, and Rational Asset Manager
Case Study: SOA Service Reuse at ZYX Electronics
© Copyright IBM Corp. 2008. All rights reserved.
399
14.1 Locating services for consumption
Chapter 11, “Manage reusable assets” on page 303 mentioned the types of repositories that
can be used in the life cycle of service assets. These repositories are a good place to locate
services when there is a need for consumption. This section focuses on how to locate
services stored in these repositories.
Service consumption can happen either at the time of modeling, design, and assembly
(hereafter referred to as development time) of SOA solutions and assets, or it might happen at
the run time of the applications that consume services.
When using a Repository, we need to understand and be able to leverage its search
capabilities. By doing so, we are able to find and reuse assets more effectively. In particular,
we want to minimize the following occurrences:
False negative: A search is performed, and we are unable to find an asset to reuse.
However, one or more assets do exist in the Repository that we are using.
False positive: A search is performed and returns a set of assets that match our search
criteria. However, as we work with the assets, we discover that none of the assets is really
a good fit.
Here is a brief overview of the features in the various repositories that help you locate
services for consumption:
Rational Asset Manager can be used to locate service assets at development time.
Rational Asset Manager provides extensive search features based on various parameters
to find assets. For detailed information about the search features in Rational Asset
Manager, refer to Part 2, “Reusable Assets” on page 123 of this book.
WebSphere Service Registry and Repository can be used to locate services at
development time as well as run time. At the time of development, you can look for the
deployed services in your organization and analyze their dependencies using WebSphere
Service Registry and Repository. If you need access to the complete set of artifacts for a
service that you have identified for reuse, you can use the integration features of Rational
Asset Manager and WebSphere Service Registry and Repository to locate the asset in
Rational Asset Manager. WebSphere Service Registry and Repository provides several
interfaces to locate services at run time.
WebSphere Business Services Fabric can be used to locate business services and
Composite Business Services at development time and run time. At the time of
development, you can use the search features in the WebSphere Business Services
Fabric Web-based administration tool to discover what business services and Web
services have been deployed in a particular organization. At run time, you can use the
dynamic assembler routing engine to select specific service endpoints based on the
context, content, and contract associated with the service request.
14.1.1 Locating services in WebSphere Service Registry and Repository
Next, we discuss locating services in WebSphere Service Registry and Repository.
Locating services at development time
WebSphere Service Registry and Repository provides a number of ways to search for
deployed services. The key search features include:
Quick search: Use the quick search field at the top left of the navigation tree in the
WebSphere Service Registry and Repository Web user interface to find any type of object
400
Strategic Reuse with Asset-Based Development
stored in the registry. The search is performed on the entire registry using an exact-case
match on the text entered. It is matched against the name and description properties of
any object. The text is used as a partial match; for example, a search for “Echo” returns
both “Echo.wsdl” and “MyEcho”. You can specify an asterisk character (*) in any part of
the search text to denote that any number of other characters are permitted to occur at
that position in the search results.
Query Wizard: The Web interface for the WebSphere Service Registry and Repository
provides a query wizard that can be used to search for service metadata based on the
following criteria:
–
–
–
–
–
–
–
Different specific types of entities
All entity types
Entity name
Custom property name or value
Classifications
An entity property (for example, namespace)
AND or OR queries
The wizard walks the user through a series of windows to select the previously mentioned
criteria to create a search query and then displays all of the service metadata in the
Repository that matched the criteria.
View query definitions: The WebSphere Service Registry and Repository view query
system is a highly customizable method of creating predefined queries against the
contents of the registry. It uses a simple XML file that defines the parameters of each
query, associating that query with a unique identifier. These queries then form the main
method of providing links from the navigation tree to show relevant views in the Web user
interface. Users can customize existing or new navigation trees in the user interface by
defining additional view queries in a new view query definition file and then referencing the
new queries in the navigation tree.
Eclipse Plug-in: The Eclipse plug-in for the WebSphere Service Registry and Repository
is primarily a tool used to search for and publish documents from the development
environment. It contains a search feature that is highlighted here for the sake of
completeness of the content with respect to its query capabilities.
From the Service Registry view of the WebSphere Service Registry and Repository
Eclipse plug-in, you can search WebSphere Service Registry and Repository using one or
more of the following criteria:
– The object’s uniqueness identifier or any part of it. If you search on only one or two
parts of the identifier, more than one object can be returned in the search results.
– The type, or types of objects that you want to retrieve. For example, you can search for
XML and WSDL documents.
– One or more properties and property values of the object
– The classification of the object in the WebSphere Service Registry and Repository. If
you specify a high-level classification, all of the objects in all of the classifications
beneath it are returned in the search results.
Programmatic query: Although we do not go into detail here, because it is out of our
scope, the WebSphere Service Registry and Repository provides other programmatic
query capabilities that can be used for searching for assets for reuse.
Locating services at run time
WebSphere Service Registry and Repository has several interfaces that provide a variety of
ways to access the product’s functionality. We are the most interested in the context of this
Chapter 14. Consuming service assets
401
book in the Java application programming interface (API) Enterprise Java Bean (EJB) and the
Web Services API. These APIs can be used to locate services at run time.
14.1.2 Locating services in WebSphere Business Services Fabric
The IBM Business Services Repository is a standards-based Business Service model
Repository that captures information about Business Services, Business Policies, And
Service Subscribers. WebSphere Business Services Fabric allows you to search for and view
the details of the various Repository objects through a Web-based interface. Figure 14-1 on
page 403 shows the various metadata elements that you can search for in the Business
Services Repository.
As seen in Figure 14-1 on page 403, you can search for Resources, which typically refer to
discrete IT assets. Types of Resources include Application Suites, Applications, Business
Services, Interfaces, Endpoints, and Business Events.
You can search for subscribers, who might be a person, role, organization, or a machine that
consumes business services. You can also search for policies by name. Figure 14-1 on
page 403 also shows the views that are available in the search results for each of the
metadata elements. You can also run correlation queries to know the relationships between
different objects.
402
Strategic Reuse with Asset-Based Development
Figure 14-1 Search features in WebSphere Business Services Fabric
14.2 Consuming service metadata from WSRR for CBS
assembly
Next, we discuss consuming service metadata from WSRR for CBS assembly.
14.2.1 WebSphere Business Services Fabric and the WSRR integration
As mentioned earlier in this section, the WebSphere Business Services Fabric integrates with
the WebSphere Service Registry and Repository to source service metadata. The service
metadata is then extended with business context, policies, and assertions as part of the
assembly of business services (and its composites) and is stored in the Business Service
Repository in the WebSphere Business Services Fabric. As a result of the integration, the
WebSphere Business Services Fabric replicates service metadata from the WebSphere
Service Registry and Repository into the Business Service Repository. Developers
assembling Composite Business Services can then use this service metadata during
assembly without having to populate the Business Service Repository manually. Figure 14-2
Chapter 14. Consuming service assets
403
on page 404 shows the positioning of the WebSphere Service Registry and Repository with
respect to the WebSphere Business Services Fabric.
Figure 14-2
WebSphere Business Services Fabric and WSRR integration
Configuring Repository integration
In order for the integration to work, the WebSphere Business Services Fabric needs to be
configured with an External WebSphere Service Registry and Repository project. This project
contains the WebSphere Service Registry and Repository connectivity details along with the
authentication information if the Repository instance has been secured. Details about how to
configure this integration can be found in the following article:
http://www.ibm.com/developerworks/websphere/library/techarticles/0708_balaji/0708_
balaji.html
How the replication works
When the WebSphere Business Services Fabric is configured for replicating, it queries the
WebSphere Service Registry and Repository for service endpoints, interfaces, and
operations. The first time that the WebSphere Business Services Fabric connects to the
WebSphere Registry, it retrieves all of the service metadata from the Web Services
Description Language (WSDL) files and catalogs them in the Business Service Repository.
On subsequent connects, it retrieves updates that have been made to the services in the
WebSphere Service Registry and Repository or any new service metadata that might have
been published in WebSphere Service Registry and Repository since the previous connect.
When a WSDL file is deleted from the WebSphere Service Registry and Repository, the
service metadata is not deleted from the Business Service Repository in order to avoid
invalidating the assertions that have been defined on the deleted endpoints.
404
Strategic Reuse with Asset-Based Development
Any metadata deleted from the Business Service Repository that is a replicated instance from
the WebSphere Service Registry and Repository will be restored back from the WebSphere
Service Registry and Repository upon their next connection.
WebSphere Business Services Fabric validates the contents of the WSDLs based on the
Web Services Interoperability Organization (WS-I) standards before it replicates the
metadata into the Business Service Repository. Specifically, the following validations are
performed on the WSDL file:
1. Endpoint fields must have a display name (port name), address (per port soap address),
and support service (per portType).
2. Addresses must have a valid HTTP URL.
3. Web service display name (portType name) must be specified.
4. Service operations must have input and output messages
(wsdlInput/wsdlOutputMessage).
Note: Web Services Interoperability Organization (WS-I) is an open industry organization
chartered to promote Web services interoperability across platforms, operating systems,
and programming languages. For more information about WS-I, refer to the Web site:
http://www.ws-i.org/
The WebSphere Business Services Fabric validation validates WSDLs based on WS-I
standards while trying to replicate from WebSphere Service Registry and Repository to
Business Service Repository. Only the WSDLs that pass the validation checks are replicated.
Any WSDLs that fail the validation will not be replicated. Therefore, the best practice is to
ensure that WSDLs published to WSRR are WS-I compliant.
Using replicated metadata
After ensuring that the WebSphere Business Services Fabric has been successfully
configured to replicate service metadata from the WebSphere Registry, you can now use this
data to assemble your composite business service. Composite Business Services are
assembled using the Composition Studio tool, which is an Eclipse plug-in that ships as part of
the WebSphere Business Services Fabric tools pack. It is installed as a plug-in to WebSphere
Integration Developer. Using the metadata from the WebSphere Service Registry and
Repository in your composite business service involves a two stage process:
1. The fabric project that is created for the WebSphere Service Registry and Repository
replication needs to be replicated into the Composition Studio. You will then be able to
view the services and endpoints that were retrieved from the WebSphere Service Registry
and Repository in the Composition Studio. You can then define assertions for these
endpoints.
2. The Business Service project that is typically created to hold composite business service
metadata needs to be replicated into the Composition Studio. This project needs to import
the namespaces of the External WebSphere Service Registry and Repository project in
order to make the content replicated from the WebSphere Service Registry and
Repository visible to the composite business service. In this project, you can define
policies and assign them to the services retrieved from the WebSphere Service Registry
and Repository.
In this way, service metadata can be sourced from the WebSphere Service Registry and
Repository and extended with business level metadata in the WebSphere Business Services
Fabric.
Chapter 14. Consuming service assets
405
14.3 Points of variability of service-based assets
An asset, by definition, has variability points through which it can be customized for specific
consumption requirements. The definition of variability points from that section is repeated
here for elaboration in the present context of service assets:
“A variability point is a location in an asset, specifically an artifact that can be modified or
extended as part of being reused. It is a planned for, controlled extension point of the asset.”
The variability points of an asset depend largely on the type of the asset. Services have
several extension points based on their style of reuse. There are four major styles of reuse:
Black box: An asset that is not altered by the Asset Consumer
Gray box: An asset that is modified using parameters
White box: An asset whose internals are modified by the Asset Consumer
Glass box: An asset that exposes internals for evaluation and browsing purposes
In this section, we discuss which styles of reuse apply to services and what points of
variability are available based on the style of reuse of a service.
In theory, services can be reused based on any of the four styles just mentioned. However,
the following three styles warrant further discussion:
Black box reuse: Generic services, which perform a specific task, such as validation or
transformation, are generally reused as Black boxes. However, it is common to have to
perform minor configuration work on the asset, such as changing the endpoint of the
service based on the deployment environment. Therefore, this configuration work can turn
this asset reuse into Gray box reuse.
Gray box reuse: Certain services have deployment parameters that can be configured at
the time of deployment to suit the deployment environments. A common example of this
parameter is the endpoint of a Web service. Services that are usually shipped as part of
licensed products are usually Gray boxes. Web services that are part of WebSphere
Business Services Fabric industry content pack are examples of these services. These
services provide implementations of generic tasks in specific industries, such as
transformation, validation, and so forth.
White box reuse: Reuse of Composite Business Services are examples of White box
reuse. Composite Business Services provide generic implementation of common
industry-specific business processes. It is usually expected that you customize the
business processes and implementations that are used by a composite business service
based on the reuse scenario. The business services in the WebSphere Business Services
Fabric Industry Content Packs are examples of White box reuse. They contain mock
implementations of the Web services that can be customized based on the requirements
of the larger solutions of which they are usually a part.
406
Strategic Reuse with Asset-Based Development
Important: As discussed earlier, a goal for the organization must be to support all forms of
reuse. Therefore, although typically White box reuse has a lower value than Black box and
Gray box approaches to reuse, it can still provide a significant amount of value.
A key aspect to the Composite Business Services is that they are intended to provide
organizations with a best practice approach to building services within a specific industry.
However, there is also a need to allow each business to provide their unique, and likely
competitive differentiating, approach to the algorithm within the services. Therefore, there
is a balance between providing a standards-based set of services and providing an
organization with room to innovate.
Last but not least, when the composite business service has been customized to a
particular organization, it then migrates to the Black box and Gray box reuse models as
others in the organization consume this completed set of services.
Technically it is possible to reuse a composite business service as a Gray box by configuring
the business level service metadata, such as channels, roles, and policies.
Common points of variability of service assets are:
Business level service metadata: Business services and their composites are
characterized by business level metadata, such as channels, roles, and policies. This
metadata can vary based on the consuming application. WebSphere Business Services
Fabric helps externalize this metadata to a business service Repository. It uses
externalized policies to select specific implementations of a service based on the context,
content, and contract associated with a service request. This makes it easy to change
policies that govern the business process without having to write or change the source
code. Changes to metadata, such as what roles can access the business service through
what channels, can also be made declaratively, making it easy to customize the business
services and their composites for specific solutions. Changes to this metadata are made
using the WebSphere Business Services Fabric Composition Studio tool.
Service Endpoints: Endpoints of Web services are the most common points that vary
based on the deployment environment of the service. In the case of Composite Business
Services, new endpoints can be added for a specific service in the business service
Repository by using the Composition Studio tool. At run time, the WebSphere Business
Services Fabric dynamic assembler then uses the new endpoint as part of the dynamic
endpoint selection process.
The actual endpoint URL itself can vary based on the deployment server configuration.
Endpoint URLs for basic services can be edited using the WebSphere Process Server
administration console.
Messaging protocol: The protocol that is used to communicate with a service can vary
based on the application requirements. The most common protocols that are in use are
SOAP/HTTP and SOAP/Java Message Service (JMS). Implementing a service as a
Service Component Architecture (SCA) component gives you the flexibility to choose the
binding protocol at the time of service creation or assembly of Composite Business
Services. WebSphere Process Server provides three binding protocols: SOAP/HTTP and
SOAP/JMS for Web service bindings, JMS binding, and SCA binding.
Service implementation: Services that are intended for White box reuse expose the
implementation source code for customization by consumers. Customizing existing
implementation is usually a cumbersome task if it involves understanding existing code.
The best practices that can help facilitate a service implementation change are:
– Externalize all probable application-specific variability points in an application. This
reduces the chances of having to change the service implementation code.
Chapter 14. Consuming service assets
407
– Keep the service implementation cohesive and use the right design patterns to
separate the logical layers and specific products used by the composite business
service into logical modules. Using adapters to connect to third-party and open source
software makes it easy to switch between alternatives for this software.
Implementing services as SCA components gives you the flexibility to select one of the
implementation types at the time of service creation or assembly of Composite Business
Services.
Business process: Business agility is one of the key goals of service orientation.
Organizations need to change their business processes as quickly as possible to meet the
demanding market needs. Hence, the business process implemented by business
services and their composites is a key point of variability of these services. At a technical
level, common changes to the Business Process Execution Language (BPEL) include
adding completely new services to the choreography, changing conditions that select
specific services for invocation, or selecting specific implementations of a service based
on the context.
There are multiple ways of varying a specific service in the business process
implementation. These methods vary in terms of the degree of the flexibility that they bring
to the business process and their ease of implementation. These options are described
here in brief:
– Baseline SCA implementation: This approach is the simplest and most
straightforward option to implement service endpoint selection. It involves using the
choice elements in the BPEL to select a specific service based on the evaluation of a
condition. The SCA assembly for the business process will have the actual endpoints
configured. These endpoints can be changed using the WebSphere Process Server’s
administrative console.
– Selectors: Selectors are special purpose SCA components that are part of
WebSphere Process Server. You can use a selector to indirectly wire a workflow with
one or more SCA import components. When a workflow sends a request through a
selector, the selector routes the request to an endpoint based on a selection criteria
that is evaluated for each request.
Integration Developer 6.0.2 provides predefined support only for selectors that use
date as a variable in selection criteria. Extending the selectors to use more complex
criteria, specified using Java, requires that you write custom code that implements the
SelectionAlgorithm interface.
At run time, the selectors can be modified using the administrative console, though this
applies only to the Integration Developer-supported selectors. Custom selectors
implementing the SelectionAlgorithm interface do not qualify. The console has
windows for editing selector tables that can point to specific service endpoints
compliant with the selector’s Web service operation. There is also support for
protocol-independent aliasing using a selector table. Because each entry in a selector
table resolves to an SCA component, an entry can be an import component with HTTP
or a JMS binding. Selectors also support runtime dynamicity of endpoint choices.
When an SCA module is deployed to a process server, the module’s binding
components can be added as entries in a selector table.
Selectors can be good candidates for a points of variability implementation. However, it
is important to assess the risks of deploying selectors to production and to fully
understand the capabilities of the points of variability implementations based on
mediation modules, service registries, and dynamic assembly.
The selector-based implementation requires access to the WebSphere Process Server
administrative console. It might not be suitable in environments where security requires
separation of access rights for the role responsible for editing the selector choices and
408
Strategic Reuse with Asset-Based Development
the role of the Process Server Administrator. This security risk is particularly serious in
cases where selectors are used to implement points of variability in business logic that
must be inaccessible to system Administrators. In many production environments,
business users must not have the capabilities of a Process Server Administrator
(stopping or deleting applications, changing system configuration, and so on).
Points of variability implementations that rely extensively on selectors are also a
regression risk for development organizations. When deploying a new version of an
application, developers must update the runtime selector tables from an existing
version of an application before an upgrade. When the selector tables change
frequently, this can mean downtime for existing applications.
Because selector tables are modified through the WebSphere Process Server
administrative console, they do not allow invocation time dynamicity for service
endpoints. WebSphere Process Server provides scripted access to the administrative
console capabilities, including selection table modification, but the performance impact
of using this scripting interface at endpoint invocation time is unacceptable to most
applications.
– Mediation modules: In Enterprise Service Bus (ESB)/Process Server terminology, a
mediation module is a type of SCA component. Mediation modules are designed to
perform message transformations, usually between application specific and generic
business objects. Mediation modules are not limited to mediating content; each
module’s implementation, called mediation flow, can contain alternative service
invocation steps, along with associated logic routing the control flow to a specific step.
Mediation modules can alias across different protocols (for example, from SOAP/HTTP
to SOAP/JMS) and across different message exchange patterns.
Although mediation modules lack runtime and administrative user interfaces to access
and modify routing logic, ultimately they are more flexible than selectors for service
endpoint aliasing.
Mediation modules are a step up from selectors in terms of flexibility and tooling
support. WebSphere Integration Developer provides a collection of mediation
primitives that assist you in developing complex protocol and endpoint independent
implementations. For example, there are primitives available for logging, event
notification, and request routing.
– Mediation with service registry: Thus far, our discussion of options for implementing
endpoint selection ignored the issue of managing service endpoint choices.
Implementations based on selectors, business rules, and mediation modules do not
provide a standard approach for storing, querying, and manipulating information about
service endpoints.
WebSphere Service Registry and Repository can be used in conjunction with
WebSphere Enterprise Service Bus or WebSphere Process Server to enable
dynamicity of service endpoint choices at run time. WebSphere Service Registry and
Repository exposes Java and Web service APIs for managing service endpoints in an
internal registry. WebSphere Service Registry and Repository can also keep track of
classification metadata for describing service endpoints. For example, an endpoint can
be stored in WebSphere Service Registry and Repository along with:
•
Associated metadata describing the WSDL interface of the endpoint
•
Alternative service endpoints with different protocols or message exchange
patterns
•
Business information, such as the name of the company hosting the service
endpoint
In terms of implementation, SCA mediation modules can be written to query
WebSphere Service Registry and Repository to retrieve service endpoints prior to
Chapter 14. Consuming service assets
409
performing a service invocation. In parallel, BPEL workflows or other WebSphere
Service Registry and Repository clients can modify the pool of service endpoints,
potentially changing the behavior of the mediation modules querying WebSphere
Service Registry and Repository. Governance features help ensure that WebSphere
Service Registry and Repository clients are not affected when these changes are
made.
– Business rules: Using rule groups and rules is one option for implementing an SCA
component. Business rules can implement selection of a service endpoint in a
workflow, and they can be edited during development time and run time.
During development, you can use Integration Developer to define an initial
implementation of endpoint selection based on criteria embedded in a business rule.
The selection criteria can be expressed using a business rule specific language, which
is a subset of Java expressions with the capabilities of querying Service Data Objects
(SDOs). Alternatively, the workflow containing the business rule can have an
equivalent selection expression in a Java snippet and simply pass the result to the
business rule.
Two types of business rule implementations are relevant to endpoint selection:
•
If-then business rules for evaluating a selection criteria
•
Action rules containing endpoint invocations that are executed depending on the
outcome of selection criteria evaluation
At run time, an application can use the Process Server Business Rule Manager to
modify the business rules. When selection criteria is specified purely in the business
rules expression language, the criteria can be rewritten entirely. Naturally, at run time,
the criteria can only be modified within the limits of the input parameters that are
passed to the business rule. This limitation can be anticipated and mitigated by
passing the entire workflow state to the rule. When the selection criteria is captured
using a Java snippet, it cannot be modified using the rule manager application.
– Dynamic assembler: WebSphere Business Services Fabric provides dynamic
assembly capability for workflows. Implementations based on dynamic assembly differ
from the other options, because they rely on an out-of-workflow scope evaluation of
selection criteria for service endpoints. A business analyst can implement the selection
criteria in Composition Studio (a tooling part of WebSphere Business Services Fabric)
using a simple expression language without any need for Java programming skills.
A points of variability implementation using WebSphere Business Services Fabric is
the approach that offers the most flexibility to developers of Composite Business
Services. When deciding to use WebSphere Business Services Fabric, however, it is
important to understand the additional development requirements of WebSphere
Business Services Fabric. For example, preexisting BPEL workflows cannot be
retrofitted to leverage WebSphere Business Services Fabric without changes to the
workflows and the implementation of additional data and logic structures for the
dynamic assembly engine.
14.4 Customizing Composite Business Services
Composite Business Services are essentially choreographies of industry-specific business
processes. The business process and the other variability points that were mentioned in 14.3,
“Points of variability of service-based assets” on page 406 hold true for Composite Business
Services.
410
Strategic Reuse with Asset-Based Development
Given that Composite Business Services are much more complex than basic Web services,
the following points must be considered while customizing composite business service during
their consumption:
Note: Many of these considerations are relevant not only to services but to all kinds of
assets that solve business problems and can be reused as customizable applications in
larger solutions.
Composite business service assets need to be tested for non-functional requirements,
such as performance, security, and availability based on certain benchmarks. The test
results along with the operational environment that was used to conduct the tests need to
be published as part of the supporting documentation for the asset. This will help the
consuming team to tune the environment of its solution for the composite business
service. In fact, publishing these details as attributes of the asset in the asset Repository
can help you decide whether to reuse the asset in a specific context.
The use of commercial or open source third-party software in composite business service
assets needs to be evaluated prior to consumption. This can have a cost impact on
reusing the asset due to licensing issues. You might also consider replacing certain
commercial or open source software used by the composite business service with other
software that might be available for use at a lower cost or that has been mandated for use
by the governance policies.
The use of commercial or open source third-party software in a composite business
service (and in all kinds of assets in general) can cause technical issues related to version
dependencies. For example, the composite business service can require a certain version
of the third-party software and the consuming application can need a different version.
These two versions might or might not reconcile to a single latest version based on the
technicalities of the specific open source software. This can require packaging or
structural changes in the consuming project and the composite business service.
User interfaces are usually built for a composite business service primarily to be able to
test and demonstrate the capabilities of an asset to solve a domain specific problem.
These interfaces are most likely to be customized to match the look and feel of the
consuming application, at a minimum. In certain cases, the user interface can be
discarded, and the business process implementation alone can be reused.
The user registry used by a composite business service is likely to vary based on the
consuming application requirements. As a best practice, we recommend not to use any
registry-specific APIs in the composite business service. Using a standard API, such as
Java Authentication and Authorization Service (JAAS), ensures that the composite
business service is user registry-independent. Consuming applications can switch
registries, most likely to Lightweight Directory Access Protocol (LDAP), based on their
requirements.
14.5 Reusing assets from the Industry Content Packs
Composite business service asset development can be accelerated using the WebSphere
Business Services Fabric Industry Content Packs. These packs include valuable industry
common services and reference industry models to simplify interoperability between IT
systems and partners, facilitate service reuse, and drive industry standards compliance.
The industry packs are industry specific assets in the form of reference business service
templates. The service templates have been derived from standard industry specific
processes and are extensible and configurable to support the unique requirements of a
Chapter 14. Consuming service assets
411
specific solution. They follow industry standards, such as ISO 200022, NACHA in the banking
domain, and HIPAA and HL7 in healthcare, to name a few.
The assets that are part of the Industry Content Pack are:
Reference business services templates: The reference business services templates
consist of the business services, metadata that includes decompositions of business
services and Web services, and the associated definitions of business policy assertions,
business roles, and business channels, based on the industry business glossary.
Industry Business Glossary that presents a taxonomy of industry terms, with associated
relationships and properties
Industry standards-based Web service interfaces and data types that enable
interoperability across disparate systems in the enterprise ecosystem
Industry-common services that contain specific implementations that are consistently
reused in multiple solutions to enable transactional industry-specific functions, such as
validation, bulking, debulking, transformation, and so forth. These services follow
industry-specific standards.
Industry Business Object Model used as a semantic model for design and development of
service-oriented business solutions
Knowledge assets that can accelerate the use and extension of the prebuilt SOA content
contained in the industry content packs
To understand the content of these assets, let us look at the Banking Payments Pack.
Figure 14-3 summarizes the assets in the Banking Payments Pack. Similar assets are
available as part of the Healthcare, Insurance, and Telecom content packs.
Figure 14-3 Banking payments industry content pack assets
The IBM Banking Payments Pack supports payment processes for financial institutions.
412
Strategic Reuse with Asset-Based Development
Benefits of reusing this content pack to develop composite business service assets are:
The Banking Payments Business Glossary contains a banking payments common
vocabulary that represents the taxonomy of banking terms with associated relationships
and properties based on ISO 20022 payments standards, Electronic Payments
Association, formerly the National Automated Clearing House Association (NACHA)
payments standards, and the IBM Information Framework (IFW) business object model.
You can choose one of the models based on your requirement as the semantic model for
your Composite Business Services. This model forms the basis for defining assertions,
channels, roles, and other metadata for your Composite Business Services. The glossary
is used to define business metadata for reference business service templates that are part
of the content pack as well.
The assets within the Banking Payments Pack leverage payments standards from ISO
20022, NACHA, and IFW. This ensures that the assets that you develop using the content
pack comply to the industry standards.
The business service templates contain a decomposition of the domain into the
application suites, applications, and business services. These business services
represent the reference templates. Each business service has been configured with
channels that can be used to access the service and roles for which the service can be
personalized. The associated Web services that are required by the business service
have been mapped in the template. Sample policies are defined for each template using
the context, content, and contract-based assertions sourced from the business glossary.
Reusing these business services and metadata reduces the time required to assemble
Composite Business Services.
The Banking Payments Business Object Model is an ISO 20022 payments
standards-based business object model that represents the conceptual view of the
payments domain through business objects. The Business Object Model is a logical data
model that can be used for implementing operational data stores for your Composite
Business Services.
The Banking Payments Service Interfaces contain banking payment-specific schemas
and Web service interfaces based on a subset of Interface Design Model (IDM) of IFW.
The Banking Payments Common Services is based on ISO 20022 and NACHA payments
standards. These are basic interfaces and services that can be reused in your Composite
Business Services.
The following steps summarize the tasks that need to be done to develop a composite
business service reusing the assets in the content packs:
Note: The following summary of steps gives an overview of the key tasks that need to be
performed to reuse the assets in the Industry Content Pack. An exhaustive list of steps
required to reuse these assets is out of the scope of this book.
1. Leveraging the Service-Oriented Modeling and Architecture (SOMA) process, identify the
assets from the content pack that can be reused.
Important: Steps 2 through 6 are performed using WebSphere Integration Developer.
2. The business services templates are available as SCA modules. Service interface assets
are represented as SCA libraries. Import the templates and libraries that have been
identified for reuse. Note that the use of a template might mandate the need of the
common services and interface libraries, because these libraries are reused by the
templates.
Chapter 14. Consuming service assets
413
3. Customize the BPEL for the business service if necessary.
4. Integrate the business services sourced from the content pack into the choreography of
your composite business service. (This involves adding the business service partner links
in the BPEL for the composite business service).
5. Create or update the SCA assembly for the composite business service with the
references wired to the business services imported from the templates.
6. The business services templates are configured to route the service requests through the
dynamic assembler. Ensure that the right context and content information is populated in
the service requests that are made from the templates. This affects the service endpoint
that is selected at run time by the dynamic assembler. You can test the business polices
relevant to your business services using the Composition Studio Policy Simulator tool.
7. Customize the implementations for the services reused from the content pack. The
business services templates might contain mock implementations or have no
implementation attached to them. You will have to provide custom implementation for
these services. Service interfaces, which have been sourced from the content pack, will
require that implementations are provided as well.
8. Customize the metadata for the reused business services in the templates using the
Composition Studio. This involves customizing roles, policies, channels, and other
metadata with which the business service is configured. While it is optional to change the
business level metadata (such as the channels and roles) based on your business needs,
you might have to customize the technical metadata, such as the endpoint URLs for the
services, based on your environment. Because you are developing a reusable asset, you
might want to reuse the default business level metadata and leave this step for the
consumers of the asset.
9. If your composite business service requires metadata, for example, assertions that are not
part of the industry business glossary, you might have to extend the glossary using the
Uniform Modelling Language (UML) models in Rational Software Architect. Terms not in
the glossary can be introduced into the glossary from the industry standard Business
Object Models.
14.6 Providing service reuse feedback
Consumers of assets need to provide feedback on their reuse experience of an asset. This
feedback provides the following benefits:
Helps the producers assess the value, quality, and reusability of their asset
Helps the governance bodies to assess the degree of success or failure of the governance
policies related to asset reuse
Helps Repository Administrators to assess the value of the Repository with respect to
asset reuse
We recommend the following best practices to service consumers in this regard:
Business services and their composites can use the WebSphere Business Services
Fabric dynamic assembler component to route the requests to service endpoints. This
helps Administrators to use the WebSphere Business Services Fabric Performance
Manager to monitor the performance of business services and use this information to
assess service reuse. More information about this topic can be found in the Chapter 14,
Manage service assets.
414
Strategic Reuse with Asset-Based Development
Use WebSphere Service Registry and Repository as a central service Repository in the
organization and use the integration features of WebSphere Service Registry and
Repository and IBM Tivoli® Composite Application Manager to feed operational
information about service usage from the management infrastructure to WebSphere
Service Registry and Repository. WebSphere Service Registry and Repository stores
information, such as metadata, associated with the related services for users and
applications to access it when needed. For more information, refer to Chapter 15,
“Managing service assets” on page 425.
Rational Asset Manager contains a feature to rate assets that are stored in it. Services
consumed from the asset managers can use the feedback facility provided by the
repositories. Refer to Chapter 10, “Consume reusable assets” on page 281 for more
information about Rational Asset Manager’s feedback capability.
14.7 Case study: SOA service reuse at ZYX Electronics
In this section, we see how ZYX Electronics uses the features of Rational Asset Manager to
consume service assets. Note that aspects of asset production also appear in this section. As
discussed earlier, the asset manufacturing and asset use life cycles have connections and
usually occur at the same time.
Recall from Chapter 13, “Producing service assets” on page 359 that a new asset has been
placed into the Repository.
After submitting the new process model to the Rational Asset Manager Repository, Bob sent
an e-mail to Al Aarkashan (the SOA architect at ZYX Electronics), as shown in Figure 14-4.
The e-mail was to inform Al that there was a new asset submitted to Rational Asset Manager
for the “Determine Applicant Eligibility” business process and that Al can start to create the
requirements specification, design models, and initial implementation of this service.
Figure 14-4 Bob e-mails the new business process asset to Al
Chapter 14. Consuming service assets
415
Al Aarkashan, the SOA architect, received the notification sent by Bob and logged in to
Rational Asset Manager to look at the newly created business process, as shown in
Figure 14-5.
Figure 14-5 Search for Determine Applicant Eligibility process model asset
Al then used Rational Requisite Pro to create the requirements specification of this process
and Rational Software Architect to create analysis and design models. When Al finished, he
also used Rational Asset Manager Web interface to submit these new assets to the
Repository (he created new Requirement and Software Design assets). He also created a
relationship between these new assets and the business process asset submitted by Bob.
Al then sent an e-mail notification to Deb Devak (the Service Developer at ZYX Electronics) to
inform her about the newly loaded assets and to request that Deb start to design and
implement the service. Deb received the e-mail, searched in Rational Asset Manager for the
newly produced assets, and looked at the skeleton implementation produced by Al.
Deb used WebSphere Integration Developer and WebSphere Process Server to assemble
the process choreography and to implement and test the necessary services that are part of
the choreography.
Deb had previous experience using Spring from her time at a previous employer. However,
rather than download the asset from the Internet, she searched in the Repository to learn
whether it was available to be used and if so, what version. As shown in Figure 14-6 on
page 417, Spring Version 2.1 was indeed available for reuse on ZYX projects.
Important: According to the governance policy in ZYX Electronics, developers need to use
Rational Asset Manager for reusable frameworks, such as the Spring framework, in order
to avoid individual employees downloading content from the Internet, which might have
potential copyright and licensing issues.
416
Strategic Reuse with Asset-Based Development
Figure 14-6 Search for Spring open source framework V 2.1
Deb then proceeded to download the artifacts associated with the Spring V 2.1 asset. Also,
based on her previous experience with the asset, she decided to rate this asset and gave it 5
stars using the Rating tab as shown in Figure 14-7.
Figure 14-7 Rate Spring V2.1 asset
When Deb verified that the service implementation worked correctly, she generated the
Eligibility EAR to be used for deployment. When she generated this EAR file, she decided to
add the implementation and service interface to Rational Asset Manager and associate them
with the business process they support and the design model, which drove the creation, as
shown in Figure 14-8 on page 418.
Chapter 14. Consuming service assets
417
Figure 14-8 Service asset type relationships
Because Deb already used Eclipse, she used the Rational Asset Manager Eclipse interface
to create these new Service Implementation and Service Interface assets. To create the new
Determine Applicant Eligibility Service Interface asset, she followed these steps:
1. Switch to the Asset Management perspective by clicking Asset Management as shown
in Figure 14-9.
Figure 14-9 Switch to Asset Management perspective in Eclipse
Deb had already created a connection to the Rational Asset Manager Repository, so she
did not have to create it again. For detailed steps of creating a connection to the Rational
Asset Manager Repository using the Rational Asset Manager Eclipse Interface, go to
A.2.3.2, “Eclipse client installation” on page 655
2. Right-click in the whitespace of the Asset Explorer view and select New → Asset as
represented in Figure 14-10.
Figure 14-10 Create new asset
3. Complete the New Asset window as shown in Figure 14-11 on page 419, and click Next.
418
Strategic Reuse with Asset-Based Development
Figure 14-11 Complete new Eligibility Service Interface asset window
4. Click Next to skip the next window in the wizard, because Deb did not enter any asset
attribute information.
5. Select the Business Planning and Sales categories for the asset and then click Next as
shown in Figure 14-12 on page 420.
Chapter 14. Consuming service assets
419
Figure 14-12 Select categories for the Service Interface asset
420
Strategic Reuse with Asset-Based Development
6. Select the Determine Applicant Eligibility.DOC and Eligibility.wsdl files from her
workspace to be associated to the asset and click Finish as shown in Figure 14-13.
Figure 14-13 Select artifacts to be associated to the asset
After Deb completed these steps, the Eligibility Service Interface asset icon representation
contained a red X as shown in Figure 14-14, which means something was missed with the
asset, and Deb was unable to complete the submission process until it is resolved.
Figure 14-14 Error submitting the Service Interface asset
To fix the problems, Deb went to standard Eclipse Problems view and she discovered that
she had not associated the WSDL file to the asset as Figure 14-15 on page 422 shows.
Chapter 14. Consuming service assets
421
Figure 14-15 Problems submitting the Service Interface asset
This constraint is added by default to the Service Interface asset type to verify that all service
interface assets have at least a WSDL file describing the service.
So Deb selected the Content tab to add the Eligibility.wsdl file to the asset. And, because she
had also forgotten to create a relationship between this service interface and the process
model, she created a “Fulfills” relationship between these assets as shown in Figure 14-16.
Figure 14-16 Establish relationship between service interface and process model assets
To submit the asset to the Rational Asset Manager Repository, Deb clicked Submit.
Because it was configured by default in the SOA Model, the Service Interface asset must
follow a review process, so Deb selected to follow this review process as shown in
Figure 14-17.
Figure 14-17 Submit the asset for approval through the review process
The review process configured for the Service Interface asset type is similar to the one
described and explained in Chapter 11, “Manage reusable assets” on page 303 for reviewing
open source frameworks. Chapter 11, “Manage reusable assets” on page 303 provides more
information about the review process and how reviewers can use the Rational Asset Manager
Web interface and Rational ClearQuest to review the asset.
After adding the Eligibility service interface to Rational Asset Manager, the service
implementation code needed to be added and associated with this service interface. Deb
used the same Rational Asset Manager Eclipse interface and followed the same steps
previously described for the Service Interface asset type. The only difference was that the
constraints associated to each asset type were different. The Service Implementation asset
type has three possible constraints placed upon it:
First, it must be related to a Service Interface asset.
422
Strategic Reuse with Asset-Based Development
It must contain at least one artifact labeled as Binary. In the case of service
implementation, this must be the .war, .ear, or other executable file supporting the
services implementation and able to execute.
One other optional constraint is the labeling of a deployment descriptor file.
Chapter 14. Consuming service assets
423
424
Strategic Reuse with Asset-Based Development
15
Chapter 15.
Managing service assets
This chapter provides information about the management aspects of services in a
service-oriented architecture (SOA) from an Asset-Based Development perspective. In
Chapter 1, “Introduction to Asset-Based Development” on page 3, 1.4.1, “Asset
management” on page 9 mentions the issues involved in managing assets in an SOA. This
chapter describes how to use the management features of multiple IBM products and tools for
SOA to address these issues. It shows how you can use specific product features and their
integration capabilities with other IBM products to enforce governance policies that help you
better manage the services in an SOA.
This chapter discusses the following topics:
Configuring the repositories for effective service management:
– Integrating Rational Asset Manager with WebSphere Service Registry and Repository
– Integrating WebSphere Business Services Fabric with WebSphere Service Registry
and Repository
Reviewing and approving services
Reporting on service reuse:
– Assessing service reuse with WebSphere Service Registry and Repository and IBM
Tivoli
– Assessing service reuse with WebSphere Business Services Fabric performance
manager
Retiring service assets
Asset management insights for WebSphere Studio Asset Analyzer users
Understanding the Service Integration Maturity Model
Managing service assets in our case study: SOA Service Reuse at ZYX Electronics
© Copyright IBM Corp. 2008. All rights reserved.
425
15.1 Configuring the repositories for effective service
management
Chapter 13, “Producing service assets” on page 359 mentions the various repositories in the
life of a service asset, including Rational Asset Manager, WebSphere Service Registry and
Repository, and the Business Service Repository. It also shows the relationships among
these repositories and mentions when each of these repositories can be used, as shown in
Figure 15-1.
Figure 15-1 Repositories in the life of a service
This section provides details about integrating these repositories for effective asset
management. Before we go into the details, it is important to understand how this integration
can help you in better service management. Assuming that the products mentioned here
have been configured for integration:
Consider this scenario regarding a under-performing service:
– You can use the service operational data that is fed into WebSphere Service Registry
and Repository from IBM Tivoli Composite Application Manager to identify defects in
the services.
– You can find this service in WebSphere Service Registry and Repository and navigate
to the corresponding asset in Rational Asset Manager directly from WebSphere
Service Registry and Repository and raise a defect in Rational ClearQuest using the
Rational Asset Manager-ClearQuest forum integration feature.
– You can track the status of the defect from Rational Asset Manager. Using the
integration between ClearCase and Rational Asset Manager, developers can source
the asset from Rational Asset Manager into ClearCase to fix the defect. When the
asset has been updated in Rational Asset Manager with the fix, and its review process
has been completed, you can publish the service back to WebSphere Service Registry
426
Strategic Reuse with Asset-Based Development
and Repository. In this way, you can effectively manage assets from a central
Repository (Rational Asset Manager) while using Rational Asset Manager’s integration
features to work with the capabilities of other related products.
By sourcing technical service metadata from WebSphere Service Registry and Repository
to assemble Composite Business Services in WebSphere Business Services Fabric, you
can manage updates to service metadata from a single Repository (WebSphere Service
Registry and Repository) without having to make changes in multiple repositories, thus
improving developer productivity and metadata consistency across the organization.
The following sections detail the integration of Rational Asset Manager with WebSphere
Service Registry and Repository and the integration of WebSphere Business Services Fabric
with WebSphere Service Registry and Repository.
For details about integration of Rational Asset Manager with Rational ClearQuest and
Rational ClearCase, refer to Appendix A, “Rational Asset Manager: Installation and
administration” on page 637.
15.1.1 Integrating Rational Asset Manager and WebSphere Service Registry
and Repository
The integration of the Rational Asset Manager and the WebSphere Service Registry and
Repository has two sides to it:
Synchronize service metadata from the WebSphere Service Registry and Repository into
the Rational Asset Manager.
Publish service metadata from the Rational Asset Manager asset into the WebSphere
Service Registry and Repository.
Synchronizing service metadata
The service metadata that is in the WebSphere Service Registry and Repository can be
useful for the users of the Asset Manager to understand, for example, what services are
deployed in the run time or the relationships between the various services. Hence, the
Rational Asset Manager provides a synchronization facility to replicate service metadata from
the WebSphere Service Registry and Repository into the Rational Asset Manager. This
allows users working in the Rational Asset Manager to have visibility to the service runtime
characteristics and to make use of this metadata in better utilization of the assets stored in
the Rational Asset Manager.
The integration works by configuring the Rational Asset Manager with the WebSphere
Service Registry and Repository server details. Refer to the Appendix A, “Rational Asset
Manager: Installation and administration” on page 637 for more details about how to
configure the Rational Asset Manager for WebSphere Service Registry and Repository
connectivity. As part of the configuration, you can provide a time interval for the
synchronization to run.
Each time that the synchronization happens, the Rational Asset Manager checks the
WebSphere Service Registry and Repository for new assets or updates for existing assets
and brings them into the Rational Asset Manager. By bringing in service metadata in Web
Services Description Language (WSDL) files, XML Schema Definition (XSD) files used by
services, and the relationships among various services from the WebSphere Service Registry
and Repository, the Rational Asset Manager users can get access to this metadata when
they are searching for an asset in the Rational Asset Manager.
Chapter 15. Managing service assets
427
As a result of synchronization:
A category called service registry is created in the Rational Asset Manager for the data
retrieved from WebSphere Service Registry and Repository. All of the classifications,
WSDLs, XSDs, and other data brought in from WebSphere Service Registry and
Repository are stored in this category.
The unique ID of the document in WebSphere Service Registry and Repository is also
brought in to the Rational Asset Manager to help users relate between the Asset Manager
and WebSphere Service Registry and Repository.
A link called bsrURI is created and associated with the replicated document in the
Rational Asset Manager. Users can click this link to navigate to view the service metadata
in the WebSphere Service Registry and Repository Web interface.
Publishing service metadata
If you have a new service that is developed and stored in the Rational Asset Manager but is
not updated with service metadata in the WebSphere Service Registry and Repository, you
can use the Rational Asset Manager to publish service metadata to the WebSphere Service
Registry and Repository.
You can publish the following document types into the WebSphere Service Registry and
Repository:
WSDL
XSD
XML
Web Services Policy Framework (WS-Policy)
Service Component Architecture (SCA) Module
You need to create a WebSphere Service Registry and Repository server configuration in
order to be able to publish services to the WebSphere Service Registry and Repository. Refer
to Appendix A, “Rational Asset Manager: Installation and administration” on page 637 for
more details about how to configure the Rational Asset Manager for the WebSphere Service
Registry and Repository connectivity. When an asset is published into the WebSphere
Service Registry and Repository:
A concept is created in the WebSphere Service Registry and Repository with the name of
the asset. This new concept contains the ID and the version of the asset that was in the
Rational Asset Manager.
Note: A WebSphere Service Registry and Repository concept can be used to represent
anything that does not have a physical document in the WebSphere Service Registry
and Repository. For detailed information about WebSphere Service Registry and
Repository concepts, refer to the WebSphere Service Registry and Repository
Handbook, SG24-7386.
The individual artifacts that are selected for publishing, such as WSDLs, XSDs, and so
forth, are then published. You can overwrite the authentication credentials for the
WebSphere Service Registry and Repository that are part of the WebSphere Service
Registry and Repository configuration information in the Rational Asset Manager with a
new set of credentials while publishing service metadata to the WebSphere Service
Registry and Repository. You can select specific documents that are part of the Rational
Asset Manager asset to be published to the WebSphere Service Registry and Repository.
After the artifacts are successfully published, you might see them as custom relationships to
the new concept that was created for the asset in the WebSphere Service Registry and
428
Strategic Reuse with Asset-Based Development
Repository. You can also see the link to the Rational Asset Manager asset as a custom
property of the published document in the WebSphere Service Registry and Repository.
When Rational Asset Manager tries to synchronize its contents with WebSphere Service
Registry and Repository, it creates a single asset shadowing the WebSphere Service
Registry and Repository service metadata concept that was created as a result of the publish
operation. Rational Asset Manager also creates a content artifact for each WebSphere
Service Registry and Repository service document related to the WebSphere Service
Registry and Repository service metadata concept. The shadow asset is linked to the original
asset that was used to publish to WebSphere Service Registry and Repository. This is
necessary, because these services can undergo any kind of versioning or life cycle changes
at the WebSphere Service Registry and Repository level when they are in the WebSphere
Service Registry and Repository. By having the asset in the Rational Asset Manager linked to
the published data in the WebSphere Service Registry and Repository, users can know which
artifacts were originally used to publish the service and what the current status of the service
is in the WebSphere Service Registry and Repository.
Figure 15-2 summarizes the publish and synchronization tasks that happen as part of the
Rational Asset Manager and the WebSphere Service Registry and Repository integration.
Figure 15-2 Rational Asset Manager and WebSphere Service Registry and Repository integration
Chapter 15. Managing service assets
429
Figure 15-2 on page 429 shows the steps that are performed by Rational Asset Manager
when the CreditCheckService asset is published to the WebSphere Service Registry and
Repository. The box with a dotted outline in Figure 15-2 on page 429 represents a logical
grouping of the concept and the documents in WebSphere Service Registry and Repository
that resulted from the publish operation.
Figure 15-2 on page 429 also shows the steps that are performed by Rational Asset Manager
when it is configured to synchronize service metadata from WebSphere Service Registry and
Repository. Figure 15-2 on page 429 shows two synchronize operations to differentiate the
steps that are performed during the synchronization of WebSphere Service Registry and
Repository content that has been published from Rational Asset Manager from the steps that
are performed to synchronize content that was found in WebSphere Service Registry and
Repository but was not published from Rational Asset Manager. However, in reality, these
two types of assets are synchronized during a single attempt to synchronize.
Note that there is only one shadow asset for the CreditCheckService. This shadow for the
WebSphere Service Registry and Repository concept holds the CreditCheck.wsdl and
Account.xsd as its contents. The Transformation.wsdl is an example of a service found in
WebSphere Service Registry and Repository that was not published from Rational Asset
Manager.
Multiple Repository instance configurations
You might want to have a dedicated instance of the WebSphere Service Registry and
Repository for the development, testing, and the production environments. The Rational
Asset Manager can be configured to work with multiple WebSphere Service Registry and
Repository servers. The synchronization process results in a shadow asset being created for
every WebSphere Service Registry and Repository instance that has been configured in
Rational Asset Manager. You can also select from this set of repositories when you publish
an asset to WebSphere Service Registry and Repository.
15.1.2 Configuring WebSphere Business Services Fabric for sourcing
metadata from WebSphere Service Registry and Repository
Chapter 13, “Producing service assets” on page 359 mentions the basics of consuming
services from WebSphere Service Registry and Repository to assemble Composite Business
Services. For detailed step-by-step instructions of how to configure WebSphere Business
Services Fabric for WebSphere Service Registry and Repository integration, refer to the
following article:
http://www.ibm.com/developerworks/websphere/library/techarticles/0708_balaji/0708_
balaji.html
15.2 Review and approve services
Creation and access to services need to be governed by policies that are laid out by the
governance boards. Services submitted to repositories need to pass through certain review
and approval processes before they get published. This section details the features of
WebSphere Service Registry and WebSphere Business Services Fabric in this respect.
430
Strategic Reuse with Asset-Based Development
15.2.1 Security features in WebSphere Service Registry and Repository
WebSphere Service Registry and Repository makes use of the security mechanisms
provided by WebSphere Application Server to ensure that only authenticated users are able
to access the various interfaces that it exposes. However, it also extends these capabilities to
allow more fine-grained access control to the information that it stores. These capabilities are
discussed in the following sections.
J2EE security roles
Because WebSphere Service Registry and Repository is a Java 2 Platform, Enterprise
Edition (J2EE) application; it defines a number of security roles within its deployment
descriptors. When global security is enabled within WebSphere Application Server, these
J2EE security roles are used to restrict who can access WebSphere Service Registry and
Repository at run time. In other words, WebSphere Application Server uses these roles to
enforce standard J2EE security within the relevant J2EE containers at run time.
The J2EE security roles defined by WebSphere Service Registry and Repository are:
User
Administrator
In order to be able to access the WebSphere Service Registry and Repository Web user
interface or to invoke methods on the WebSphere Service Registry and Repository
application programming interface (API), a user must at least be mapped to the J2EE User
role. By default, the special subject AllAuthenticatedUsers is mapped to both the User and
Administrator roles during WebSphere Service Registry and Repository installation. Mapping
the AllAuthenticatedUsers special subject to a role maps any user who has authenticated to
WebSphere Application Server to that role. Therefore, in a default WebSphere Service
Registry and Repository installation, all users who are able to authenticate to WebSphere
Service Registry and Repository are able to perform any action against WebSphere Service
Registry and Repository.
Note: We recommend that you modify the relevant environment script prior to installation
to ensure that only those users or groups who are permitted to access WebSphere Service
Registry and Repository are mapped to the relevant roles. However, note that the Server
user ID that is configured in your WebSphere Application Server environment must be
mapped to the Administrator J2EE security role in WebSphere Service Registry and
Repository. If this mapping is not defined, WebSphere Service Registry and Repository will
fail to start when running in a WebSphere environment where security has been enabled.
User-defined roles
The access control provided by the use of J2EE security roles within WebSphere Service
Registry and Repository is very coarse-grained. It is only able to control who can access the
WebSphere Service Registry and Repository Web user interface or the WebSphere Service
Registry and Repository API methods themselves. It is not able to control access to the
objects on which the WebSphere Service Registry and Repository API methods operate.
In order to provide more fine-grained access control functionality, WebSphere Service
Registry and Repository provides an authorization component that allows additional roles to
be defined and for permissions to be added to these roles. User or group principals must be
explicitly mapped to these roles in order for the principal to have the entitlement (permissions)
associated with the role.
When a method is invoked on the API, WebSphere Service Registry and Repository uses the
authorization component to determine whether the user is authorized to perform the
Chapter 15. Managing service assets
431
requested action on the target object or objects. Therefore, in a secure environment, each
method invocation on the WebSphere Service Registry and Repository API results in the user
being authorized twice: one time for standard J2EE role-based access control and one time
for the more fine-grained access control provided by WebSphere Service Registry and
Repository.
Note: Any roles that are defined to the authorization component in WebSphere Service
Registry and Repository are completely separate from the J2EE security roles defined
within the deployment descriptors for the WebSphere Service Registry and Repository
application. At run time, WebSphere Application Server is only aware of the Administrator
and User J2EE security roles.
To simplify the installation and configuration of WebSphere Service Registry and Repository,
the installation process creates roles within the WebSphere Service Registry and Repository
authorization component that match the J2EE security roles. That is, the installation process
creates an Administrator and a User role within the WebSphere Service Registry and
Repository authorization component. It also maps the same users and groups to these roles
that are mapped to the J2EE security roles.
Permissions
As shown in Figure 15-3, a permission within WebSphere Service Registry and Repository
encapsulates an action and the target objects on which it can be performed. Adding a
permission to a role grants the users who are mapped to that role the permission to perform
the specified action on the specified target objects.
Figure 15-3 Permissions in WebSphere Service Registry and Repository
Permissions can be configured with name, action, and target properties. The name of the
permission is used to identify the permission within WebSphere Service Registry and
Repository. The action property for a permission specifies the operation that the permission
432
Strategic Reuse with Asset-Based Development
authorizes. In addition to the create, retrieve, update, and delete operations, other valid
actions include control over state transitions and governance of the objects in WebSphere
Service Registry and Repository. The target property for a permission specifies the objects in
WebSphere Service Registry and Repository to which the permission applies. Examples of
valid targets are an XSD document, a WSDL document, and a SCA Module, to name a few.
Default permissions
WebSphere Service Registry and Repository adopts a permissive approach to access control
in the authorization component. This means that access to all of the artifacts in WebSphere
Service Registry and Repository is unrestricted by default. This approach allows users to
continue to access objects in WebSphere Service Registry and Repository when security is
enabled without the need to define permissions that explicitly grant them access to these
objects. However, when a role is explicitly granted access to a set of target objects in
WebSphere Service Registry and Repository, all other roles are implicitly denied access to
that set of objects. In this situation, in order for other roles to access the same set of target
objects, each role must also be explicitly granted access to the set of objects.
For example, if you add a permission to the Administrator role that granted its members
permission to create WSDLDocument objects in WebSphere Service Registry and
Repository, all other roles that were defined to the authorization component can no longer
create WSDLDocument objects. In order to grant users in a Developer role the permission to
create WSDLDocuments, you need to add the same permission to this role.
WebSphere Service Registry and Repository also defines default permissions for
Administrator and User roles.
Extensible Access Control Markup Language (XACML)
The Extensible Access Control Markup Language is an XML-based language that is
designed to express security rules, policies, and policy sets that define the access rights of
users (subjects) to resources. The goal of XACML is to provide a common policy language
that allows organizations to enforce all of the elements of their security policy across all of the
components of their IT infrastructure. The XACML specifications were developed through a
collaborative effort involving various companies, including IBM, Sun™ Microsystems, and
Entrust. XACML was ratified by the Organization for the Advancement of Structured
Information Standards (OASIS) in February 2003. The XACML specification can be found
here:
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml
The WebSphere Service Registry and Repository authorization component uses XACML to
represent the security policies that have been defined to it. It generates XACML policy files
that are then stored in WebSphere Service Registry and Repository and are used during
application startup to initialize the WebSphere Service Registry and Repository authorization
component with the current security policies. The WebSphere Service Registry and
Repository authorization component makes use of two policy files, and we discuss these files
in more detail in the following sections.
Role mapping file
The WebSphere Service Registry and Repository authorization roles, and the user and group
principals that have been mapped to these roles, are defined in the role mapping XACML file.
This file is read from WebSphere Service Registry and Repository during application startup
and is used to initialize the role mappings within the WebSphere Service Registry and
Repository authorization component. The role mapping file is stored in WebSphere Service
Registry and Repository as a configuration document called SrrAuthzRoleMappingXacml of
type XACML.
Chapter 15. Managing service assets
433
Authorization policy file
The WebSphere Service Registry and Repository authorization policy is defined in the
authorization policy XACML file. This file defines the mapping between permissions and the
roles to which they have been added. This file is read from WebSphere Service Registry and
Repository during application startup and is used to initialize the authorization policy within
the WebSphere Service Registry and Repository authorization component. The authorization
policy file is stored in WebSphere Service Registry and Repository as a configuration
document called SrrAuthCheckedPolicyXacml of type XACML.
15.2.2 WebSphere Business Services Fabric Governance Manager
IBM Business Services Repository stores metadata that is used to create business services
in a service-oriented architecture (SOA) system. The metadata describes the services,
policies, relationships among them, and entitlements to subscribers. Using IBM Business
Services Composition Studio, you can create or modify this metadata. A multi-authoring
environment facilitates controlling the changes published to IBM Business Services
Repository. To ensure data integrity, changes applied to the metadata must be monitored and
conflicts must be resolved. IBM Business Services Governance Manager enables you to
manage this process through the following business services.
Configure Projects: To create Fabric projects and assign project teams: IBM Business
Services Governance Manager provides the mechanism to create multiple types of
projects. All projects are associated with a team, which is an organization managed
through IBM Business Services Subscriber Manager. Only users on the team can use a
given project through IBM Business Services Composition Studio. A Fabric project is
created to manage the metadata for a set of applications and services. You can also use
Configure Projects to carry out the configuration of federation data sources, such as
Lightweight Directory Access Protocol (LDAP) directory and WebSphere Service Registry
and Repository (WebSphere Service Registry and Repository) to enable external
repositories.
Configure Namespaces: To create and manage namespaces for each project: After you
create a Fabric project, you have to staff it with the team and allocate the namespaces in
which the instances will be stored. Metadata instances can be created in or moved
between namespaces using IBM Business Services Composition Studio. Content can be
exposed to another team by having their project import a namespace owned by another
project.
Configure Environments and Configure Repository: An environment is a named
collection of logical and physical resources used to support the performance of a function.
Often, a service is deployed in multiple environments, for example, development
environments and testing environments. A single instance of WebSphere Business
Services Fabric allows you to manage business services deployed across multiple
environments. Also, every environment can have a dedicated instance of WebSphere
Business Services Fabric to manage the applications deployed within it. Through the
Configure Environments business service, organizations can define environments that
provide a named scope in which services are deployed.
Every WebSphere Business Services Fabric instance is tied to a single instance of IBM
Business Services Repository and the metadata within it. Using the Configure Repository
business service, organizations can associate a Repository instance with specific
environments. This association specifies the subset of environments that the associated
Repository instance is allowed to use. At run time, only endpoints in supported
environments are considered for endpoint selection.
434
Strategic Reuse with Asset-Based Development
Manage changes business service: To view, approve, or reject metadata changes and
to publish approved changes to IBM Business Services Repository: The governance
process enqueues the service metadata changes in an approval system for immediate
pass-through. While automatic approval of changes is the preferred process in a
development environment, deployments in other environments might necessitate a
designated approver for all metadata changes. Using the Manage Changes business
service, the approver can sanction or reject business service metadata submitted by IBM
Business Services Composition Studio users. After approving the changes, the approver
or the designated user must publish the approved change lists to IBM Business Services
Repository. Thus, only authorized individuals can approve and publish or reject the
proposed changes to business services’ metadata.
View change history business service: To view metadata changes that have been
processed through the governance system: Using this business service, a change
Administrator can trace metadata changes published to IBM Business Services
Repository, through visibility into their status, and other pertinent details, as they pass
through the various approval stages.
Import/export business service: To transport content: between environments, for
translation, and for version control: When changes have been made and it is time to
deploy the metadata created in a development Repository to another environment for
testing and ultimately promotion, this is where the import and export of a Fabric Content
Archive is needed. A Governance Administrator can export part or all of the data for a
project to a Fabric Content Archive file, and then import or update this project on to
another system.
Usage scenarios
The following scenarios exemplify the usage of the governance business services:
Scenario 1: Consider an example where an enterprise wants to develop a credit check
business service that will automate the assessment of the credit-worthiness of customers.
Using the Configure Projects and Configure Namespaces business services, you can
create a development project workspace and assign a development team with controlled
access to the business service metadata during the development process.
Scenario 2: To develop and test the credit check business service, you might require two
separate environments. Using the Configure Environments business service, you can
create two named environments, “develop” and “test”, and define a scope for each
environment. You can associate one or more of these environments to endpoints defined
by using IBM Business Services Composition Studio. Using the Configure Repository
business service, you can associate these environments with Repository instances.
Scenario 3: During the development process or later, you can export the project that you
created in Scenario 1 to other deployments, such as a test or production environment. A
prerequisite to exporting a project is exporting the environments associated with the
project. Therefore, you export the “develop” and “test” environments that you have created
in Scenario 2 before you export the project.
Other requirements, such as providing multilingual support for the business service to cater to
a global market, necessitate externalizing and translating user-facing service elements.
Maintenance of the service versions, such as the alpha, beta, and release versions, is also a
key requirement. The Import/Export business service provides the functionality to fulfill these
requirements.
Chapter 15. Managing service assets
435
Governance process in WebSphere Business Services Fabric
The following steps enumerate the governance process in WebSphere Business Services
Fabric:
1. Create a Fabric project.
2. Assign the team members for the project.
3. Create and configure the appropriate namespaces (both Owned and Imported).
Note: You perform steps 1, 2, and 3 by using IBM Business Services Governance
Manager.
4. Using IBM Business Services Composition Studio, select the project and create instances
of the objects. This action generates a list of Business Service model changes.
5. Submit this list through IBM Business Services Composition Studio.
6. The system transfers these changes to IBM Business Services Governance Manager.
7. Authorized individuals approve or reject these changes through IBM Business Services
Governance Manager.
8. Approvals or rejections are reflected in IBM Business Services Governance Manager.
When approved, the Change Administrator can publish approved changes to the
Repository.
9. Export the metadata content from a development environment; import it into another
WebSphere Business Services Fabric environment.
In a typical usage scenario, developers import and export content archive files to test them in
stand-alone WebSphere Business Services Fabric deployments. An entire WebSphere
Business Services Fabric deployment runs on an embedded server in WebSphere Integration
Developer, and the default setting for the IBM Business Services Governance Manager
approval is set to pass through.
15.3 Reporting on service reuse
One of the key concerns of asset management is to be able to assess the reuse of assets in
the organization and thus be able to assess the value of Asset-Based Development. This
section provides the details of the features of WebSphere Service Registry and Repository
(WSRR) and WebSphere Business Services Fabric that help you assess the value of
Asset-Based Development.
15.3.1 Assessing service reuse with WSRR and IBM Tivoli
WebSphere Service Registry and Repository is the source of service information and
metadata in an organization. Therefore, it plays a double role in the overall domain space of
SOA management:
It provides the SOA management infrastructure with detailed information about the
registered services.
It supports the enrichment of service information with operational data that is observed
and processed by the SOA management infrastructure.
Figure 15-4 on page 437 shows the interactions between a service registry and Repository
and the SOA monitoring and management infrastructure.
436
Strategic Reuse with Asset-Based Development
Figure 15-4 WebSphere Service Registry and Repository and SOA Management
Registered services are managed in the WebSphere Service Registry and Repository. This
information is accessed by multiple actors, including the Service Provider (registering
services) and the Service Consumer (looking for services to consume).
The monitoring and management infrastructure uses this information about registered
services to enhance its understanding of the topology and characteristics of the services in
the monitored SOA. This information can include immediate details about service endpoints.
It can also consist of a meaningful description of service interfaces and behavior, or it can
provide a formal description of relationships across services and other SOA citizens, such as
business processes, consumers, and providers. Based on this information, the Monitoring
and Management infrastructure can enhance its view of the managed resources and their
topologies.
The monitoring and management infrastructure then feeds back operational data that it
collects about the observed services to the service registry and Repository. This data has
been captured and collected at run time by the observation points from the running services
that are part of the managed resources. Various elements of the runtime behavior of the
services can be collected, such as the average response time, the fault rate, the size, the
frequency of the messages, and so on.
These operational elements are used to further enrich the service information model
managed by the service registry and Repository, therefore, allowing other factors in the SOA
to use this information.
Chapter 15. Managing service assets
437
IBM Tivoli Composite Application Manager for SOA provides the management function for
managing the services and mediations in a service-oriented architecture (SOA) running on
multiple application servers and SOA infrastructures. For supported environments, IBM Tivoli
Composite Application Manager for SOA monitors and performs simple control of message
traffic between Web services in the SOA. IBM Tivoli Composite Application Manager for SOA
relies on a distributed network of data collectors to feed data into IBM Tivoli Monitoring for
analysis and management.
The integration between IBM Tivoli Composite Application Manager for SOA and WebSphere
Service Registry and Repository can be broken down into two key scenarios:
WebSphere Service Registry and Repository Discovery Library Adapter (DLA) discovers
services and static relationships between service artifacts that are registered with
WebSphere Service Registry and Repository. The data discovered by the DLA is
displayed in the new Services Management Workspace within the Tivoli Enterprise Portal.
This integration also includes the ability to discover and display certain XML-based
metadata files associated with a service and extracted from WebSphere Service Registry
and Repository.
IBM Tivoli Composite Application Manager for SOA sends status events back to
WebSphere Service Registry and Repository when a situation is detected for a service
port and operation. This mechanism can be used to enrich service metadata in
WebSphere Service Registry and Repository with additional operational information that is
monitored and fed back by IBM Tivoli Composite Application Manager for SOA. Providing
coarse-grained information about service health allows registry users, such as mediations,
to dynamically select services and human beings to choose a specific service to access.
This book focuses on how the exchange of information between the WebSphere Service
Registry and Repository and the IBM Tivoli Composite Application Manager for SOA can be
used to gain insights about services as reusable assets. In other words, it tries to show how
the integration of the two products can be used to answer questions, such as:
Which of the services are registered in the WebSphere Service Registry and Repository
but not being used?
Which of the services are being used but are not registered in the WebSphere Service
Registry and Repository?
Which of the registered services fault frequently?
The answers to these questions coupled with the integration features of the various IBM
repositories help you better manage your assets, thus enhancing their reusability across the
organization.
Important: A detailed description of the integration of the WebSphere Service Registry
and Repository and IBM Tivoli Composite Application Manager for SOA is out of the scope
of this book. For more information about how to configure the products for integration and
the benefits of the integration, refer to the WebSphere Service Registry and Repository
Handbook, SG24-7386.
Using service discovery information
IBM Tivoli Composite Application Manager discovers service metadata relevant for SOA
management through the use of adapters:
IBM Tivoli Composite Application Manager for SOA Discovery Library Adapter
discovers the relationships between service ports and operations and the application
servers and computer systems on which they are deployed, using data collected by IBM
438
Strategic Reuse with Asset-Based Development
Tivoli Composite Application Manager for SOA monitoring agents and retrieved from Tivoli
Enterprise Monitoring Server.
WebSphere Service Registry and Repository Library Adapter discovers the
relationships between service ports, operations, services, port types, and metadata
documents from WebSphere Service Registry and Repository. WebSphere Service
Registry and Repository can process Web Services Description Language (WSDL) and
other definition files to determine these static relationships.
Business Process Execution Language for Web Services Discovery Library Adapter
discovers the relationships between port types, operations, and business processes from
BPEL files.
Using these adapters:
Observed services are discovered using IBM Tivoli Composite Application Manager for
SOA Discovery Library Adapter from the running agents monitoring operational
applications and services.
Registered services are discovered using WebSphere Service Registry and Repository
Discovery Library Adapter by querying WebSphere Service Registry and Repository for
published services and related information.
IBM Tivoli Composite Application Manager for SOA captures all this information in a
Repository called the Common Object Repository. The information in the Common Object
Repository must be reconciled to link observed and registered services together and ensure
consistency between designed and operational states of services.
After configuring the adapters and other integration elements of the WebSphere Service
Registry and Repository and IBM Tivoli Composite Application Manager for SOA, the service
information can be viewed in the Tivoli Enterprise Portal using the Services Management
workspace.
This workspace provides topology views to help you with the following tasks:
View the services and service relationships that are registered with WebSphere Service
Registry and Repository that have been discovered by WebSphere Service Registry and
Repository DLA and imported into the Tivoli Common Object Repository.
View service metadata documents from WebSphere Service Registry and Repository.
View the service ports and operations that are discovered by the IBM Tivoli Composite
Application Manager for SOA DLA and imported into the Tivoli Common Object
Repository. Compare a set of service definitions with a set of discovered services in order
to verify that services are implemented and operating as designed.
View the business processes that use activities that are implemented by Web services
that are discovered by the IBM Tivoli Composite Application Manager for SOA DLA or the
WebSphere Service Registry and Repository DLA.
The business process and service relationship data is discovered by the BPEL DLA and
imported into the Tivoli Common Object Repository.
Chapter 15. Managing service assets
439
Reconciliation of the observed and registered service information helps to point out the
following situations regarding asset (service) reuse:
Services observed but not registered: Assuming that registering a service in the
WebSphere Service Registry and Repository is a prerequisite to a broader reuse of that
service, this situation might reflect one of the following scenarios:
– The operational services, which are currently observed, are not the ones targeted for
exposure and reuse. These observed services might be only test services whose
implementation is due to change.
– The observed services can reflect the existence of service assets in the Rational Asset
Manager that are not registered in the WebSphere Service Registry and Repository.
– The observed services can reflect the existence of reusable assets in the organization
that have not been published and registered in the repositories.
Knowing these facts about the assets can help enforce governance policies on the assets,
thus, enabling better reuse.
Services registered but not observed: This situation might indicate:
– The fact that the common services, which are registered in the WebSphere Service
Registry and Repository and potentially highly reused, are missing monitoring
capabilities
– The fact that certain registered services are not being used by consumers probably
due to defects in the service, such as poor performance and so forth
This information about the assets can lead to the identification of defects in the services,
thus, helping to improve their quality.
Services registered and observed: This situation can prove to be a sound foundation to
enable and understand common service reuse.
Using forwarded service information
Service status information is forwarded to WebSphere Service Registry and Repository using
the situation and event mechanisms provided by Tivoli management infrastructure and
leveraged by IBM Tivoli Composite Application Manager for SOA.
IBM Tivoli Monitoring gathers data from the various monitoring agents that are installed on
the computers in your environment. Information about Web services is collected for IBM Tivoli
Composite Application Manager for SOA and stored for display in tables of attributes. Events
are triggered in IBM Tivoli Composite Application Manager when the attribute values hit
certain thresholds. While there are several attribute tables that contribute to the generation of
events related to observed services, only the events generated from a specific table called
the KD42IT: Services Inventory_610 attribute table are propagated to WebSphere Service
Registry and Repository.
A situation in IBM Tivoli Composite Application Manager for SOA is a condition where a set of
attributes is tested against a threshold. The situation evaluates the conditions at predefined
intervals and invokes the appropriate automated responses and notification methods. IBM
Tivoli Composite Application Manager for SOA provides a set of predefined situations.
The following situations are supported for WebSphere Service Registry and Repository
integration, because they are generated from the information stored in the KD42IT: Services
Inventory_610 attribute table:
440
Fault_610:
MessageSize_610
MaxMessageSize_610
ResponseTimeCritical_610
Strategic Reuse with Asset-Based Development
ResponseTimeWarning_610
MaxResponseTimeCritical_610
MaxResponseTimeWarning_610
These situations are triggered when there are faults caused by Web services, messages
sizes, and response times for the Web services that exceed the configured thresholds. These
predefined situations can be configured with custom threshold values or custom situations
can be defined to monitor specific attributes of the services. When a situation event is
detected, the properties of the service in WebSphere Service Registry and Repository are
updated with the operational metadata.
From a service management perspective, you can use this information to measure the
utilization of the service assets and plan service migration/retirement strategies accordingly.
The effectiveness of the SOA can be captured in the service information where service usage
can directly reflect the success of the overall reuse policy of services across consumers.
Defects might be identified in the services (for example, based on the fault situation event)
and might be raised in Rational ClearQuest by tracing the asset artifacts from WebSphere
Service Registry and Repository to Rational Asset Manager and utilizing the integration
features of Rational Asset Manager and Rational ClearQuest.
15.3.2 Using WebSphere Business Services Fabric Performance Manager for
asset management
IBM Business Services Performance Manager provides business visibility and monitoring of
service-oriented processes and applications. It includes multi-perspective views and enables
drill-down analysis of events and exceptions in a loosely coupled, service-oriented business
ecosystem.
Designed for seamless interoperability with leading business activity monitoring and Web
services management tools, IBM Business Services Performance Manager provides greater
visibility across service-oriented business processes and functions.
The Performance Manager provides predefined reports:
Business Service Usage report
Service Performance report
Business Service Invocation report
Ecosystem Performance report
This section highlights these reports with a focus on how these reports can help you better
manage service assets.
Chapter 15. Managing service assets
441
Service Usage report
The Service Usage report shows the analysis details of business service used in an
enterprise or its ecosystem.
This report shows the following service utilization details:
Name: Name of the organization using the business service
Volume: The number of times that the business service was invoked (utilized) by the
organization within the specified duration
Cost: The amount per unit charged to the organization for the utilization of the business
service
Cost Modifier: The base unit for calculating the cost of business service usage. Valid
values for base unit are transaction, second, minute, hour, day, month, and year.
Total: The total amount charged for business service usage. It is the product of the volume
of transactions and the cost per transaction.
The volume metric shows the number of times that the business service was invoked
(utilized) by the organization within the specified duration. If this business service is managed
as a reusable asset in the organization, this metric can be used to judge the use of the asset
in the organization. A low value indicates that the business service is not being utilized, which
can lead to further analysis of the asset at the business and technical levels to understand the
cause for low utilization. The asset might have technical defects that make it less reusable in
multiple Composite Business Services. This metric can also lead to the conclusion that the
asset does not solve a problem that has business value and hence might not qualify to be a
reusable asset.
In Chapter 6, “Value, impact, and return on investment” on page 103, 6.1, “Impact and ROI”
on page 103 discusses various costs that are involved in Asset-Based Development. One of
the costs is the runtime cost of executing a service asset. This can include the cost of the
software and hardware infrastructure that is required for a successful execution of a business
service. The service usage report can be used as feedback to the asset management team to
measure the level of reuse and the cost involved in the reuse of a business service asset. The
cost metric gives the amount charged to the organization for utilizing the service. Assuming
that this service is an asset, this value indicates the runtime cost of using this asset. This can
be used to add up to the additional costs that are involved in creating and maintaining this
asset and relate the final value to the income earned out of this business service.
In a business model where a composite business service is being used by a service provider,
the provider can configure the cost of the business service to an appropriate value and use
the cost from the utilization report to charge the consumers. In this model, the cost metric
turns out to be the returns obtained from using the asset. Figure 15-5 on page 443 shows an
example of this report.
442
Strategic Reuse with Asset-Based Development
Figure 15-5 Service Usage report in WebSphere Business Services Fabric
5.3.1, “Asset governance” on page 66 mentions the various models through which the reuse
team can be funded during the Planning phase. One variation to the “Payment for assets and
services” model is to pay the reuse team based on every usage of an enterprise-wide
common set of services, which can be reused at run time by multiple departments in the
organization. This report can be used to find the amount that needs to be charged to the
departments that use the services, and a percentage of this amount can be used to maintain
the reuse team.
The report in Figure 15-5 also shows the Claims Submission asset being used by multiple
organizations. It also shows the volume of usage by each organization and gives the total cost
charged to the organization.
Service Performance report
The Service Performance report allows you to analyze the performance of Web services and
endpoints in an enterprise or its ecosystem. This performance analysis is in terms of key
performance measures (KPMs), such as the total number of transactions for a business
service, the average response time of a Web service or an endpoint, and the number of failed
transactions. Of specific relevance here is the number of transactions for a business service
metric. This displays the Web service’s average response time for the transaction volume for
a specified duration. The X axis shows the service performance period for which the data is
generated. The Y axis shows the total number of transactions, the number of failed
transactions, that is, transactions that encountered Web service failures, and the average
Chapter 15. Managing service assets
443
response time in milliseconds. The number of transactions for the service is an indication of
how well the service is being used at run time similar to the volume metric for the business
service in the Service Usage report.
A similar type of service performance report can be generated at the service endpoint level,
as shown in Figure 15-6, for fine-grained information about which specific endpoint is getting
used the most or the least. Note that the performance reports can be filtered based on the
context parameters, such as the organization, duration, business services, and so forth.
Figure 15-6 Service Endpoint Performance report in WebSphere Business Services Fabric
The report also shows the ratio of the Web service requests that are serviced to the total
number of Web service requests made. This metric can be used to analyze the availability
requirements that are expected from the service at run time. A low availability value can
indicate a defect in the asset with respect to non-functional requirements.
444
Strategic Reuse with Asset-Based Development
15.4 Retiring service assets
11.2.6, “Remove asset” on page 311 provides details about asset removal, including the
considerations for removing and retiring an asset. It also shows how to retire an asset in
Rational Asset Manager. Using the management features discussed in 11.2.7, “Report on
asset” on page 313, you can discover services that are not being reused in your organization.
These services can be retired and eventually removed from the asset Repository. You can
use the WebSphere Service Registry and Repository life cycle management features to
transition the service to a retired state. This indicates to WebSphere Service Registry and
Repository users that the service cannot be reused anymore.
You can use WebSphere Studio Asset Analyzer to identify assets that do not appear to have
a means of invocation. These can be source code, documentation, and design models that
are no longer used in your organization. If, after further examination, you determine that they
are obsolete, you can remove these from your inventory and thereby reduce future
non-productive analysis efforts.
Having found the appropriate asset for reuse, you can begin to assess the impact that the
proposed changes to this asset will have on the entire enterprise application. You assess this
impact by determining which files use this class.
15.5 Service Integration Maturity Model
Part 3, “Service Assets in an SOA” on page 333 of this book provides an Asset-Based
Development perspective to services in an SOA. It gave you certain insights to producing,
consuming, and managing services as reusable assets in an SOA. At any point of time during
the life cycle of services, you might want to know the maturity of your organization with
respect to the reuse of assets and the flexibility of your implementation of SOA with respect to
the reuse of service assets. The reuse maturity models presented in Part 2, “Reusable
Assets” on page 123 in this book help you access the reuse maturity. In SOA, the Service
Integration Maturity Model helps you assess where an organizational subset resides in the
area of service-orientation adoption. In addition to being used to access your organization’s
current state in service integration and flexibility, this maturity model can also be used to
assess how well the services in your organization are reused.
The Service Integration Maturity Model is a paradigm developed by IBM that defines the
extent to which various services are integrated in an SOA. In this context, a service is a
component of an automated sub-process representing a unit of work done as part of a
specific business function.
Note: The Open Group Service Integration Maturity Model (OSIMM) is the industry’s first
collaborative maturity model for SOA adoption. Spearheaded by members of The Open
Group, including IBM, BEA, HP, EDS, and Capgemini, the initiative is working to provide
an industry-recognized maturity model for advancing the adoption of SOA within and
across businessesa.
a. http://www.opengroup.org/sandiego2007/OSIMM.html
The Service Maturity Model has seven maturity levels from silo to dynamically reconfigurable
services. It also has seven domains, each of which has an increasing level of maturity.
Figure 15-7 on page 446 shows the maturity levels and the characteristics of each of the
domains at the various levels of maturity: the level of decoupling and the amount of flexibility
achievable at each stage of maturity.
Chapter 15. Managing service assets
445
Figure 15-7 Service Integration Maturity Model1
A brief description of the levels of maturity are:
Level 1- Silo: In this data integration level, the organization starts from propriety and ad
hoc integration, rendering the architecture brittle in the face of change.
Level 2 - Integrate: In this application integration level, the organization moves toward a
form of Enterprise Application Integration (EAI). The approaches that it uses are tailored to
use existing systems.
Level 3 - Componentized: This functional integration level allows the organization to
componentize and modularize major or critical parts of its application portfolio. It refactors
existing Java 2 Platform, Enterprise Edition (J2EE) or Microsoft .NET-based systems with
clear component boundaries and scope, exposing functionality in a more modular fashion.
Level 4 - Simple services: At this process integration level, the organization embarks on
the early phases of SOA by defining and exposing services for consumption internally or
externally for business partners. It acts as a service provider.
Level 5 - Composite services: This supply-chain integration level allows the organization
to extend its influence into the value chain and into the service ecosystem. Services form
1
https://w3.webahead.ibm.com/w3ki/download/attachments/733007/SIMM+Models+3.0+V2+-+July+6+2007.ppt?version=1
446
Strategic Reuse with Asset-Based Development
a contract among suppliers, consumers, and brokers who can build their own ecosystem
for on demand interaction.
Level 6 - Virtualized services: In this virtual infrastructure level, the organization creates
a virtualized infrastructure to run applications. It achieves this level after decoupling the
application, its services, components, and flows. It externalizes its monitoring,
management, and events (common event infrastructure).
Level 7 - Dynamically reconfigurable services: The organization, in the ecosystem
integration level, now creates a virtualized infrastructure to run applications. It achieves
this level after decoupling the application, its services, components, and flows. It
externalizes its monitoring, management, and events (common event infrastructure).
Note: Refer to the article Increase flexibility with the Service Integration Maturity Model at
this Web site for more information about the Service Integration Maturity Model:
http://www-128.ibm.com/developerworks/webservices/library/ws-soa-simm/
15.6 Case study: SOA service reuse at ZYX Electronics
In this section, we revisit ZYX Electronics to see how they use the Rational Asset Manager
and WebSphere Service Registry and Repository integration features to manage service
assets.
15.6.1 Publish developed service to WebSphere Service Registry and
Repository
After Duncan Munchkin (the Development Manager at ZYX Electronics) approved the
Eligibility service interface asset, it was available to other Repository users and ready to be
published to the WebSphere Service Registry and Repository.
As discussed earlier, the integration between both products allows us to publish to
WebSphere Service Registry and Repository WSDL, XSD, XML, WS-Policy, and SCA
Module file types attached as artifacts to service interface assets stored in Rational Asset
Manager.
Deon Adminio (the Rational Asset Manager Repository Administrator at ZYX Electronics) had
already created a connection for each dedicated instance of the WebSphere Service Registry
and Repository for the development, testing, and production environments.
Note: Refer to Appendix A, “Rational Asset Manager: Installation and administration” on
page 637 for more details about how to configure the Rational Asset Manager and
WebSphere Service Registry and Repository connectivity.
The steps to publish the Eligibility service interface to the WebSphere Service Registry and
Repository are:
1. Duncan was the only user with permissions to publish the Eligibility service interface to the
WebSphere Service Registry and Repository development instance, so he selected the
asset and clicked Publish to service registry as shown in Figure 15-8 on page 448.
Chapter 15. Managing service assets
447
Figure 15-8 Publish service interface to service registry
2. Rational Asset Manager knows which file types can be published to the WebSphere
Service Registry and Repository so it only showed Duncan the WSDL file as the file to be
published to the service registry (although the asset also had other artifacts, such as a
Word document explaining the service interface) as shown in Figure 15-9.
Figure 15-9 Select WSDL file to publish to WebSphere Service Registry and Repository
3. Duncan selected the EligibilityService.wsdl file. Duncan then clicked Next to go to the
following windows where he selected the registry to which to add the asset and entered
his user name and password as shown in Figure 15-10.
Figure 15-10 Select WebSphere Service Registry and Repository connection
4. Duncan clicked Confirm to verify that the asset information and selected Repository were
correct, and then clicked Publish as shown in Figure 15-11 on page 449.
448
Strategic Reuse with Asset-Based Development
Figure 15-11 Confirmation page to publish WSDL file to WebSphere Service Registry and Repository
5. When Duncan clicked Publish, the publishing process began. It took a few minutes for
Rational Asset Manager to communicate and publish the Eligibility Service Interface to the
development WebSphere Service Registry and Repository. When completed, Duncan was
presented with a message indicating that the publishing was successful, as shown in
Figure 15-12.
Figure 15-12 Confirmation message of successful publishing
The publishing process from Rational Asset Manager to WebSphere Service Registry and
Repository created:
A new service metadata concept in WebSphere Service Registry and Repository as
shown in Figure 15-13 on page 450. There was a link to the Rational Asset Manager asset
as a custom property of the published concept in the WebSphere Service Registry and
Repository.
Chapter 15. Managing service assets
449
Figure 15-13 New service metadata concept in WebSphere Service Registry and Repository
A new service document for the WSDL artifact was selected in Rational Asset Manager as
shown in Figure 15-14.
Figure 15-14 New service document concept in WebSphere Service Registry and Repository
A custom relationship from the service metadata concept was established to the service
document artifact as shown in Figure 15-15 on page 451.
450
Strategic Reuse with Asset-Based Development
Figure 15-15 Custom relationship between service metadata concept and service document
Upon execution of the Rational Asset Manager and WebSphere Service Registry and
Repository synchronization process, a new asset was created in Rational Asset Manager
representing the published artifact as shown in Figure 15-16.
Figure 15-16 Rational Asset Manager published asset
Chapter 15. Managing service assets
451
This new asset created in Rational Asset Manager:
Had the same name as the Service Interface asset used for the publishing (Eligibility
Service Interface)
Was of the type “Published Asset”
Had a link property “Link to WebSphere Service Registry and Repository” to go directly to
the WebSphere Service Registry and Repository service metadata concept that was
created as a result of the publishing process
Had a relationship of the type “Publish by” with the Service Interface asset that was used
for publishing (Eligibility Service Interface)
Figure 15-17 summarizes the new assets that were created as a result of the publish and
synchronization tasks between Rational Asset Manager and WebSphere Service Registry
and Repository for the Eligibility Service.
Figure 15-17 Rational Asset Manager and WebSphere Service Registry and Repository integration
After the service was published to the service registry, Patricia Moon, the Product Manager at
ZYX Electronics, received a notification that the Eligibility service had been published to the
service registry and that it was ready for use in applications that need the service. She sent a
notification to Irene Devin (the Service Assembler at ZYX Electronics) to inform Irene of the
availability of the service.
The browser-based portal applications that needed the account verification reused the
Eligibility service. However, this service did not solve the reuse issue completely.
Over a period of time, as ZYX Electronics was getting deeper into its SOA transformation,
more and more processes needing the Eligibility service were identified. The Eligibility
process needed to be accessed by other process automations similar to the Business to
Business (B2B) channel interaction. These interactions posed security constraints on who
was allowed to access the service through the B2B channel compared to the portal channel.
In addition, according to ZYX Electronics’ business policies, the portal channel needs a
higher priority of service than the B2B channel, because the portal channel runs in real time.
452
Strategic Reuse with Asset-Based Development
To enhance the reusability of this service, ZYX Electronics decided to re-engineer the
Eligibility service, which is a simple choreographed service, into a business service that can
behave dynamically based on the context (in this case, the channel of access) of the request.
Irene, the service assembler, sourced this service from WebSphere Service Registry and
Repository into the Business Service Repository (that is part of WebSphere Business
Services Fabric) by using the WebSphere Service Registry and Repository integration
features in WebSphere Business Services Fabric. Irene then used the WebSphere Business
Services Fabric Governance Manager to create the Eligibility business service. She then
used the Composition Studio plug-in for Eclipse and created the necessary channel, role, and
policy metadata for the business service. Multiple service implementations were coded for the
Eligibility service to handle various levels of performance. The policies were designed to
select high performance endpoints for the service requests that were made on the portal
channel. The service was tested and deployed. The service artifacts were updated in Rational
Asset Manager.
Based on these updates, the Eligibility business service was made available with enhanced
reusability. Consuming applications can easily configure the channels, roles, and policies
associated with the service based on their requirement without having to write code. The
business level metadata updates were controlled by governance mechanisms and were
driven by visual tooling that eliminates the need for technical resources to change service
metadata. Thus, ZYX Electronics moved one step ahead in reusability by bringing its IT into
alignment with its business.
15.6.2 Conclusions and benefits for ZYX Electronics
This sample scenario to produce, consume, and manage service assets related with the
“Determine Applicant Eligibility” business task helped to demonstrate to ZYX Electronics that
the SOA Model included in Rational Asset Manager was valid for them and that extending the
asset reuse approach to manage SOA-based assets had reported benefits, such as:
Change business systems dynamically, decreasing time to application availability
Decrease time-to-market by developing applications more quickly
Preserve existing IT assets by encapsulating them into dynamic business services
Control IT costs and help make IT more efficient
Enforce consistency of business and IT behavior across the company
Chapter 15. Managing service assets
453
454
Strategic Reuse with Asset-Based Development
Part 4
Part
4
Patterns
In this part, we introduce a specific type of assets known as Patterns. As shown in Figure P-4,
we will look at patterns as assets and then how we can produce, consume, and manage
these assets. This section builds on the content that was described in Part 2, “Reusable
Assets” on page 123. In addition, there is a relationship between the content in Part 3,
“Service Assets in an SOA” on page 333 and in this part. Service assets can be generated by
Patterns. In addition, we will use best practices in Services as the basis for creating Pattern
assets for generating Services.
Part 1:
Introduction
Part 2:
Reusable Assets
•Introduction to
Asset-Based
Development
•Adopting
Asset-Based
Development
•Process and
Tooling
•Configuring
Asset
Management
•Case Study
Overview
•Produce,
Consume, and
Manage Assets
•Impact and ROI
Part 3:
Services
•Services as Assets
•Produce, Consume,
and Manage Service
Assets
Appendixes
•Rational Asset
Manager
Installation and
Administration
•Process
Integration
Part 4:
Patterns
•Patterns as Assets
•Produce, Consume,
and Manage Pattern
Assets
Figure P-4 An overview of the structure of the book
© Copyright IBM Corp. 2008. All rights reserved.
455
456
Strategic Reuse with Asset-Based Development
16
Chapter 16.
Introduction to patterns
This chapter introduces patterns, pattern-based engineering, and how they relate to
Asset-Based Development.
© Copyright IBM Corp. 2008. All rights reserved.
457
16.1 Improving productivity in software development
It is a truism of software development that you can have any feature you want, as long as you
have enough time and money. But, most projects work with both fixed time frames and
budgets, so the real question is, “How can we get more features for the same time and
money?”
The generic answer lies in increasing productivity. Process, skills, quality, and automation all
can play a role. All of the chapters in Part 4 discuss improving productivity by reliably sharing
the knowledge of the most skilled software developers across an entire team. The goal is not
only to document this knowledge, but to also create automation around it. We call this shared
knowledge patterns and the approach to using it pattern-based engineering.
16.1.1 How to use this part of the book
This part of the book presents both a practical approach to Asset-Based Development
centered around patterns, specific information, and working examples of their implementation
using tools in the Rational modeling platform (IBM Rational Software Architecture 7.0, IBM
Rational Software Model 7.0, IBM Rational Systems Developer 7.0, and IBM Rational
Application Developer 7.0).
This part can be read independently of the rest of the book:
This chapter describes a process for making pattern-based engineering cost-effective,
even at the level of a project.
Chapter 17, “Produce: Model-to-text pattern implementations” on page 469 describes
JET, the pattern implementation technology that helps make pattern-based engineering
cost-effective.
Chapter 18, “Produce: Model-to-model” on page 529 describes model-to-model
transformations, Uniform Modelling Language (UML) Patterns, and other IBM Rational
technologies that enable the graphical representation of patterns.
Chapter 19, “Produce: Packaging for deployment” on page 587 describes deployment of
the pattern assets that are developed in Chapter 16, “Introduction to patterns” on
page 457 and Chapter 17, “Produce: Model-to-text pattern implementations” on page 469.
Chapter 20, “Consuming pattern implementations” on page 613 describes the use of
pattern assets.
Chapter 21, “Managing pattern implementation assets” on page 631 describes the
management of pattern assets.
If you are in a hurry for results, try the following path through this part:
16.2, “Patterns” on page 459
16.3, “Developing a pattern” on page 460
16.4, “Pattern-based engineering” on page 461
Chapter 17, “Produce: Model-to-text pattern implementations” on page 469
19.2, “Sharing JET projects” on page 588
16.5, “A process for pattern-based engineering” on page 462
From there, you can explore other aspects of patterns, as interest or necessity dictate.
458
Strategic Reuse with Asset-Based Development
16.2 Patterns
A pattern is defined as a proven solution to a recurring problem. The concept was originally
developed in architecture (of buildings), but it has been adapted to software development
starting with Design Patterns: Elements of Reusable Object-Oriented Software, by Gamma et
al.
Gamma and the other authors describe each of their twenty-three (23) patterns by specifying
a name, a problem description, a solution, and the consequences from use. We call this
description a pattern specification.
The solution that a pattern describes is abstracted from the reference solution. The value of
using a pattern comes from reusing the object roles and interactions, rather than by reusing
concrete algorithms or bodies of code. Concrete implementations can vary significantly.
Implementation language, naming conventions, and the choice of algorithms and data
structures can differ. As a result, considerable effort is still required to apply a pattern in a
particular situation.
When a particular design pattern is repeatedly applied in similar contexts, it has proven
effective to create a tool that helps automate the application. We call this tool a pattern
implementation.
A pattern implementation typically predetermines a common number of aspects of the
concrete solutions, but leaves other aspects of the pattern variable. This type of a variation is
called a point of variability. As an example, a pattern implementation can generate Java
code (fixing the language aspect of the solution), but leave the names of the key classes
variable.
The utility of a pattern implementation rests in whether the points of variability are sufficiently
large to allow for frequent reuse, but not so large as to make reuse difficult or complex.
Finally, the use of pattern implementations requires directions about how they must be used.
We call these directions pattern recipes. A recipe can combine the use of multiple pattern
implementations.
To summarize, we have defined:
Pattern
A proven solution to a recurring problem in a given context
Pattern specification
A formal description of a design pattern, including name, problem
description, solution, and consequences
Pattern implementation A tool that automates or partially automates the application of a
pattern in a particular solution
Point of variability
An aspect of a pattern or pattern implementation that varies from
concrete application to concrete application
Pattern recipe
Directions about how to use one or more pattern implementations
to implement a solution
Patterns, or more properly, pattern specifications are clearly reusable assets. But, so are
pattern implementations. This part is about pattern implementations as assets: How to create
them, how to use them, and how to manage them.
Chapter 16. Introduction to patterns
459
16.3 Developing a pattern
Developing a pattern is inherently bottom-up. Pattern specifications are not developed from
top-down requirements, but from careful observation of experience in solving problems.
Figure 16-1 shows this process.
g
p
p
p
(
p
)
10010011000100100100100
10010011000100100100100
10010011000100100100100
10010011000100100100100
10010011000100100100100
10010011000100100100100
10010011000100100100100
10010011000100100100100
10010011000100100100100
10010011000100100100100
10010011000100100100100
Problem
Exemplar
(Solution)
Pattern
Pattern
Specification Implementation
Pattern
Recipe
Figure 16-1 The pattern development process
Pattern development starts with a problem and the creation of a solution to that problem. After
encountering and solving a problem several times, a pattern is recognized, and a pattern
specification can be created. Typically, the pattern specification is developed by reference to a
solution that exemplifies the characteristics of the pattern. In this text, we call this solution an
exemplar. An exemplar facilitates the development of pattern specification and of pattern
implementations.
16.3.1 Roles in developing pattern implementations
Five roles have been identified for pattern development:
Pattern user
A user pattern
Pattern author
An expert in the problem and solution domain
Pattern specification author
Writes pattern documentation (the pattern specification)
Pattern implementation author Develops the tool that implements the pattern
Asset librarian
Maintains and archives assets for the organization
Table 16-1 shows how these roles relate to those roles defined in Rational Method Composer
plug-in for Asset-Based Development.
Table 16-1 Pattern author roles and their corresponding Asset-Based Development roles
Pattern authoring role
Asset-Based Development role
Pattern user
Asset Consumer
Pattern author
Asset Producer
Pattern specification author
Asset Producer
Pattern implementation author
Asset Producer
Asset librarian
Any and all asset management roles
A single person can, of course, fulfill more than one role. Typically, a pattern author’s primary
job responsibilities are in areas other than pattern production. The pattern author’s time is
valuable and limited. Because the creation of pattern specifications or pattern
implementations requires specialized knowledge or tools, it can be more cost-effective to
460
Strategic Reuse with Asset-Based Development
have those roles fulfilled by specialists rather than by the pattern author. If the pattern author
also specifies and implements a pattern, close collaboration between the pattern author and
the pattern specification and pattern implementation authors is required.
16.4 Pattern-based engineering
Pattern-based engineering (PBE) unites three software engineering initiatives:
Model-driven development (MDD)
Patterns
Pattern implementations
MDD provides a version and conceptual framework for PBE. MDD has four key principles:
Models expressed in a well-defined notation are key to understanding enterprise-scale
systems.
Transformations between models enable organization into a layered architectural
framework.
Metamodels facilitate meaningful integration and transformation and are the basis for
tooling.
Standards provide openness to consumers and foster healthy competition among
vendors.
Patterns provide the concepts to be modeled and transformed. The abstractions and points of
variability of a pattern specification constitute a model. The realization of those abstractions
by following the pattern constitutes a transformation.
When applying patterns without the supporting tooling, the effort to realize solutions easily
overwhelms the time spent to select patterns and model the solution in the abstract. The
value of an artifact is often perceived as being equivalent to the time invested in creating it. As
a result, applying a pattern manually leaves the perception that solutions are more valuable
than developing their key abstractions, even though initial development typically constitutes
the most intellectually valuable activity.
Automated tooling dramatically changes this perception. Because most of a solution can be
realized automatically from an abstraction, developers’ time investment is more clearly
aligned with the important task of selecting the correct patterns and abstractions.
Table 16-2 shows how the MDD principles map to the creation and use of pattern-based
engineering.
Table 16-2 Mapping pattern implementation to MDD principles
MDD Principle
Pattern implementation concept
Models
Pattern abstractions and points of variability
Transformations
Pattern implementations
Metamodels
Describe models using standardized
technologies, such as XML Schema or UML
Profiles
Standards
Metamodel technologies and pattern
implementation technologies
Chapter 16. Introduction to patterns
461
Pattern-based engineering is not only a process of pattern selection and application. It is also
a process for pattern identification and for the development of pattern implementations.
Tooling is an essential ingredient to making the development of pattern implementations
cost-effective. Next, we assume that this tooling exists and describe the pattern-based
engineering process.
16.5 A process for pattern-based engineering
The success of pattern-based engineering depends on integrating pattern identification and
the development of pattern implementations into the project life cycle. Experience has shown
that successful pattern assets are those that were initially developed and profitably reused
within a single project.
We will describe the process for PBE in the context of the Rational Unified Process (RUP).
Figure 16-2 shows the standard depiction of RUP, showing its four phases and typical activity
level in the standard RUP disciplines.
Figure 16-2 RUP Architecture showing projects phases plotted against disciplines
The process for pattern-based engineering can be summarized as:
During inception, identify key patterns based on candidate architectures, and build
supporting pattern implementations:
– Pattern identification is primarily a part of the Analysis & Design activity, but significant
patterns can be identified in other disciplines.
– Pattern implementation development is part of the Environment activity.
462
Strategic Reuse with Asset-Based Development
Pattern identification and pattern implementation development continues throughout the
project. Having a project resource dedicated to aiding in pattern identification and pattern
implementation development facilitates reuse and continuous improvement.
Test pattern solutions early and often to verify that requirements are being met.
Figure 16-3 shows the primary activities of pattern-based engineering. We depict the primary
activities as occurring during the RUP inception phase, but the activities are applicable to the
development of a pattern-based solution in any phase.
Figure 16-3 Inception activities for pattern-based engineering
Each of the activities in Figure 16-3 is detailed in the following subsections.
16.5.1 Establish project constraints
Knowing project constraints is an essential prerequisite to a successful project. Start with the
current application characteristics as a baseline (assuming that the current project has
similarities to previous ones). What do you like? What do you not like? These dislikes are
your pain points. Are these pain points compelling reasons to change? Not every pain point is
worth eliminating.
Ultimately, you must balance resources among constraints for function, quality, and budget:
Function
The business processes that you need to support
Quality
The non-functional requirements, such as reliability, usability,
efficiency, maintainability, and portability
Budget
Time, money, people, and other limited resources
Chapter 16. Introduction to patterns
463
16.5.2 Identify representative use cases
Use case development is the primary tool for understanding functional constraints. In
pattern-based engineering, use cases are then examined to drive the identification of
potential patterns:
1. Start with “mission critical” use cases.
2. Explore the ranges of variability that occur in the use cases. Considering both functional
and non-functional requirements, group use cases with common characteristics together
into what we call use case types.
3. Within each use case type, identify the characteristics that vary between the use cases.
These are the points of variability. A use case type will have a fixed number of points of
variability, although individual use cases will not manifest all of them.
4. Pick a representative use case from each use case type for further investigation. Make sure
that your representative use case manifests all of the points of variability of the use case.
5. Gather the full set of functional and non-functional requirements for the representative use
cases.
At the end of this activity, you have a collection of use cases, each of which is representative
of a class of related use cases in the system.
16.5.3 Develop candidate architecture
The goal of this activity is to develop (conceive, code, and test) a candidate architecture for
each representative use case that was defined. Much of this activity is no different than the
standard RUP activity for developing candidate architectures.
A candidate architecture demonstrates that an architecture can meet its requirements.
Adopting several of the principles of extreme programming proves valuable in this context. In
particular:
Design the simplest thing that can possibly work for each representative use case.
Reuse proven designs from previous projects where possible and look for simple
variations on a theme.
Employ “test first” (outside in) and “depth first” (small increments) approaches. That is,
devise tests to verify requirements prior to implementing those requirements. And, favor
full development of one representative use case over an incremental process on all of
them.
Prove that your candidate architecture meets the requirements, both functional and
non-functional. Ensure that test cases for all requirements are created and executed
regularly.
Demonstrate (frequently) to your users and stakeholders to show progress and further
validate the requirements.
Capture end-to-end development time for planning and estimation purposes.
The output of this activity is a collection of implementations that have been proven to meet
the requirements of each use case type. These implementations serve as models for the
realization of the remaining use cases.
To put this into the language of patterns, the candidate architectures for each representative
use case type are patterns; they are proven solutions to a recurring problem in a given
context.
464
Strategic Reuse with Asset-Based Development
16.5.4 Customize the development process
The goal of this activity is three-fold:
Document the patterns identified.
Where it appears cost-effective, create pattern implementations that automate the
application of these patterns.
Develop a customized process that leads developers through the use of these patterns
and pattern implementations.
This activity involves the following steps:
1. Start with the proven candidate architectures as reference solutions (also known as
exemplars) for the remaining use cases.
2. For each reference solution, examine every artifact that must be touched by human
hands:
– Code, test cases, deployment descriptors, scripts, property files, data definition
language (DDL), and so forth.
– Do not forget artifacts, such as operations checklists, build scripts, and so forth.
3. Outline the steps to realize another use case using the reference solution as a model.
Enumerate the inputs, tools used, and outputs of interest (many of these might have been
produced by a tool rather than manually).
4. Look for opportunities to eliminate manual steps by automating them with custom tools
based on JET, model-to-model transformations, UML patterns, and other automation
technologies.
5. Document a project development cookbook for the remaining use cases in each use case
type. (These are pattern recipes).
Consider using Rational Method Composer as a tool-assisted cookbook.
6. Test the cookbook by having a representative project team member develop a different
use case from the same use case type.
7. Measure results and develop a high-level plan for the remaining use cases to determine
whether budget constraints can be met. Note that:
– Time can be compared against the baseline captured in the architecture step to
estimate the return on investment (ROI) for the customized process.
– The team might want to do a head-to-head test (manually compared to tool-assisted)
on comparable use cases.
8. Demonstrate with the stakeholder team to show progress and further validate the
business requirements.
At the end of this activity, you have:
Tooling and a proven process to correctly implement all known use cases
Data that will enable you to estimate the remaining development effort
However, you must not expect this point to be the end of pattern identification. Requirement
changes and clarifications can result in new or revised patterns. Also, new patterns can be
discovered in a later project phase, particularly those unrelated to analysis, design, and
construction. As project disciplines, such as test and deployment, become more active, more
manual and repetitious activities might be discovered. These activities, too, constitute
patterns and can be automated.
Chapter 16. Introduction to patterns
465
16.5.5 Pattern harvesting
The patterns identified during a project are potentially useful to future projects. The process of
collecting, documenting, and distributing these patterns is called pattern harvesting.
In a traditional development process, harvesting occurs late in the project and requires
considerable effort by the project team in the form of documentation and perhaps tooling.
There is typically little direct reward to the team for doing this harvesting.
With pattern-based development, these late-in-the-project costs are largely avoided. The
project team has already created the necessary material and tools to meet its own
requirements. All that remains is the distribution of the project’s pattern assets to a shared
Repository.
An important part of pattern harvesting is the assessment of the pattern quality. Asset
repositories, such as IBM Rational Asset Manager (RAM) make it easy for project teams to
distribute their assets and to record their experiences. In order to avoid late-in-the-project
costs associated with documenting asset quality, project teams must consider using tools,
such as RAM, for managing their pattern assets throughout the project. This way,
assessment can be a continuous process throughout the project.
16.6 Reality check: Does pattern-based engineering really work
Can the pattern-based engineering process really work? The short answer is yes with the
correct tools and in the right domains.
Several factors must come into play in order to achieve success:
The correct tools must exist to enable the rapid production of pattern implementations.
Production and usage costs of a pattern implementation must be significantly better than
the anticipated cost of implementing the use cases that the pattern addresses.
Problems must recur if the project team is to see any benefit from tooling development.
Fortunately, even in “one-off” projects, repetition is typically abundant. Consider how
many:
– Windows get developed in the average application
– Database tables are accessed
– “Statements” in a language interpreter or compiler are created
– Times that you change your mind about implementation details
The following subsections briefly describe pattern-based engineering successes.
16.6.1 Case study one: A large banking application
Develop a user interface (UI) and services framework to minimize the learning curve required
by the majority of the developers using Java 2 Platform, Enterprise Edition (J2EE).
Results
The results are:
Pattern implementation tooling not only generated over 50% of the code, but it minimized
the number of components needed in the framework:
– Modeling was based on Rational XDE™.
466
Strategic Reuse with Asset-Based Development
– Pattern implementation tooling was created with the Design Pattern Toolkit (DPTK)
from alphaWorks®. DPTK is a precursor of JET.
The team was enabled to make an aggressive schedule for showcasing the next
generation system based on Java/J2EE:
– Identified other opportunities for pattern tooling, such as test cases
– Factored naming conventions to maximize maintainability of MDD tools
Lessons learned
Test extensively during inception:
Bad news
The testing was delayed due to schedule constraints; the architecture
required extensive redesign after the rollout in order to meet
non-functional requirements.
Good news
The platform-independent models insulated the analysts and the
programmers from changes to the architecture.
16.6.2 Case study two: An IBM product development team
Re-architect a large number of servlet-based commands into Web services so that the
business application services can be separated from the presentation. The solution involved:
Exposing approximately 130 operations via services
Compiling with a complex data format specification. The documentation was 112 MB, and
the schema contained 430 files.
Results
The results are:
Identified a pattern and pattern specification, which was distributed to developers
Ultimately, developed a pattern implementation that drastically reduced the work for
developers, while increasing implementation consistency and product quality.
The development team used Rational Application Developer 6.0. The pattern
implementation was developed with Design Pattern Toolkit from alphaWorks.
Lessons learned
Documenting pattern specifications is sometimes not enough to ensure successful pattern
usage:
Good news
One developer mastered the specification and developed a procedure
(a pattern specification) for successful implementation. It was over 100
pages long.
Bad news
It took individual service developers four days to follow the
instructions, and they often had difficulty following them faithfully.
Errors early in the process were not caught until much later.
Ultimately, developers demanded the help of the original expert,
creating a heavy workload and a bottleneck.
Good news
An initial pattern implementation was developed during a two-day
training course. The revised process was reduced to two pages.
Service developers can automatically generate the complex
infrastructure code and unit tests in minutes; they can then focus on
implementing the service.
Chapter 16. Introduction to patterns
467
16.6.3 Critical success factors
The following list summarizes the factors that we believe are critical to the successful use of
pattern-based engineering:
Get buy-in from key practitioners (architect and development leads).
Have domain experts available during the pattern development process.
Build models that abstract the solution. Abstractions that too closely parallel physical
artifacts do not provide value.
Do not limit the pattern discovery to just the code. Other project phases and disciplines,
such as testing, configuration management, and deployment, must be examined.
16.7 The next steps
To learn about the creation of pattern implementations that generated text (including source
code), read Chapter 17, “Produce: Model-to-text pattern implementations” on page 469.
To learn about the creation of pattern implementations based on graphical models or to
develop graphical front ends to the transformations produced in Chapter 17, read Chapter 18,
“Produce: Model-to-model” on page 529.
468
Strategic Reuse with Asset-Based Development
17
Chapter 17.
Produce: Model-to-text pattern
implementations
This chapter describes the production of pattern implementations that create text-based
artifacts, such as language source code, configuration files, and documentation.
© Copyright IBM Corp. 2008. All rights reserved.
469
17.1 Case study: Identifying a recurring problem
Deb Devak, a developer at ZYX Electronics (ZYX), has learned about the asset reuse
initiative and is eager to learn how it can positively impact her work. Deb recently attended a
presentation by an IBM consultant about patterns and automation. Although Deb had been
distracted by several important e-mails, she had taken the following information away from
the presentation:
Patterns are a proven solution to a recurring problem.
New tooling in the IBM Rational modeling platform 7.0 family of products makes it easy to
turn a proven solution to a problem into an tool (the consultant had called it a “pattern
implementation”). The pattern implementation automates much of the drudgery of
applying the pattern to a particular situation.
This pattern tooling is lightweight enough that a positive return on investment can be
achieved in a single project without significant investment in asset management
infrastructure. (The consultant did indicate that asset management software is essential to
share assets between projects).
The new tooling was best at producing text (such as source code), rather than complex
things, such as diagrams.
To be successful with the tooling (the consultant kept repeating this remark), you need to
start from a proven solution to a problem and work “bottom-up” to create an automated
tool.
Armed with this admittedly sketchy knowledge, Deb has decided to give the pattern tooling
and pattern-based engineering a try. She considered her current efforts and decided to focus
on a very simple problem: Java beans.
Java beans
In just about every project on which Deb has worked, she sees Java beans. A Java bean is a
simple Java object with a number of properties that are accessed by getter methods and
updated by setter methods. Example 17-1 illustrates a typical Java bean.
Example 17-1 A typical Java bean representing information about a book
package com.zyx.exemplar.beans.library;
/**
* Define a Book Java bean
*
*/
public class Book {
private String author;
private int numberOfPages;
private String title;
/**
* Package private constructor prevents instantiation except through factory
*/
Book() {
}
470
Strategic Reuse with Asset-Based Development
/**
* Return the book author
* @return the author the author
*/
public String getAuthor() {
return author;
}
/**
* Return tne book number of pages
* @return the numberOfPages the number of pages
*/
public int getNumberOfPages() {
return numberOfPages;
}
/**
* Return the book title
* @return the title the title
*/
public String getTitle() {
return title;
}
/**
* Set the book author
* @param author the author to set
*/
public void setAuthor(String author) {
this.author = author;
}
/**
* Set the book number of a pages
* @param numberOfPages the number of pages to set
*/
public void setNumberOfPages(int numberOfPages) {
this.numberOfPages = numberOfPages;
}
/**
* Set the book title
* @param title the title to set
*/
public void setTitle(String title) {
this.title = title;
}
}
Deb is frustrated about Java beans, because:
They are numerous.
They result in little intellectual value in return for the time that is invested to create them.
No two developers at ZYX manage to produce exactly the same results.
Chapter 17. Produce: Model-to-text pattern implementations
471
This latter point is a particularly sore point for Deb, because she had carefully produced a ten
page document discussing how Java beans were to be used at ZYX for the other developers.
Java bean factories
According to Deb’s standard, a Java bean must be instantiated by a factory. This factory
isolates users of the bean from its actual implementation. Example 17-2 shows a typical Java
bean factory, which creates the related beans: Library and Book.
Example 17-2 A Java bean factory
package com.zyx.exemplar.beans.library;
/**
* Factory class for beans in the ‘library’ package
*/
public class LibraryFactory {
/**
* Singleton instance of the LibraryFactory
*/
public static final LibraryFactory INSTANCE = new LibraryFactory();
/**
* Private constructor prevents instantiation.
*/
private LibraryFactory() {
}
/**
* Create a new book instance
* @return the new Book object
*/
public Book createBook() {
return new Book();
}
/**
* Create a new library instance
* @return the new Library object
*/
public Library createLibrary() {
return new Library();
}
}
Relationships between beans
One last aspect of Deb’s Java bean standard was that beans can refer to each other. For
example, a Library might have a collection of Books. The variety of ways that developers can
find to implement a simple feature still amazes Deb. Example 17-3 on page 473 illustrates
how Deb wants these references implemented.
472
Strategic Reuse with Asset-Based Development
Example 17-3 Implementation of reference from one bean to another bean
package com.zyx.exemplar.beans.library;
import java.util.ArrayList;
import java.util.List;
/**
* Implement a Java bean representing a Library
*
*/
public class Library {
private final List books = new ArrayList();
... other fields removed
/**
* Return the list of books in the library
* @return a list of Book objects. Will not be <code>null</code>
*/
public List getBooks() {
return books;
}
... other methods removed...
}
Reference solution
Recalling the consultant’s admonitions, Deb put together a representative Java bean solution.
With the solution, Deb started IBM Rational Software Architect 7.0 and got to work.
17.2 Model-to-text pattern tooling
The consultant to whom Deb listened was referring to the forced expansion Java Emitter
Templates (JET). This section introduces JET, the IBM tools for developing JET-based
pattern implementations, and techniques for using these tools effectively.
Pattern implementations that create text-based artifacts, such as source code and
configuration files, are known as model-to-text patterns or model-to-text transformations.
17.2.1 What is JET
JET is an open source technology developed by IBM. It is included in several IBM Rational
Modeling Platform 7.0 products:
IBM Rational Application Developer 7.0
IBM Rational Software Modeler 7.0
IBM Rational Software Architect 7.0
IBM Rational Systems Developer 7.0
These products are based on the open source Eclipse platform. Eclipse was developed by
the Eclipse Foundation. IBM is a member of the Eclipse foundation and contributes
Chapter 17. Produce: Model-to-text pattern implementations
473
significantly to Eclipse development. JET is built on and for the Eclipse platform. In the rest of
this chapter, any reference to Eclipse includes all of the previously mentioned IBM products.
JET is a template language. A template is a sequence of text interspersed with special
annotations that are interpreted by the template language. When a template is expanded,
these annotations are interpreted and typically turned into content. An example of a template
is a form letter created in a work processor. A form letter contains special annotations to draw
names and addresses from a database into the form letter. When the word processor
expands the template against a particular set of database rows, a number of customized
instances of the form letter are produced.
The form letter example illustrates an important element of template languages. Templates
are expanded in a certain context. Form letters are expanded in the context of a word
processor and a backing database. JavaServer Pages (JSP), which are templates, are
expanded in the context of a Web browser’s request to a Web application, and that
applications response to the browser.
JET templates are also expanded in a context. In the case of JET, the context is an Eclipse
workspace and an input model. The term input model is a sophisticated term for a form of
structured data. JET’s prototypical data model is an eXtensible Markup Language (XML)
document, but JET can be adapted to many other data structures. In this chapter, however,
we will stick with XML.
JET templates are typically not invoked in isolation. Instead, they are grouped together into a
transformation, which evaluates related templates against a single input model. The results
of these template evaluations are then written to the Eclipse workspace. A lot of JET’s appeal
is that it lets developers create transformations without much knowledge of Eclipse, its
extension mechanisms, or its application program interfaces (APIs). In fact, JET solutions can
be developed even without knowledge of Java, the language in which Eclipse is typically
extended.
JET: A tale of too many acronyms
The official name for JET is the Eclipse Modeling Framework Technologies Java Emitter
Templates (EMFT JET). Getting to a complex name is no easy task. Here, briefly, is the story
of JET (and its acronym):
JET began as a tool included in the Eclipse Modeling Framework (EMF). This initial
version of JET supported template annotation only via Java code and required a
significant amount of additional Java code and knowledge of Eclipse APIs to produce
model-to-text transformations in Eclipse. To avoid confusion, we will refer to this version of
JET as JET1.
In 2005, a new version of JET was started, which was called JET2. The goal for JET2 was
to create a template engine that can produce artifacts without requiring any Java
programming at all. The IBM alphaWorks Design Pattern Toolkit (DPTK) had
demonstrated that producing artifacts without requiring any Java programming was both
possible and valuable. DPTK significantly reduced the skills and time required to produce
model-to-text transformations in the Eclipse environment.
The development of JET2 took place in the Eclipse Modeling Framework Technologies
(EMFT) project, which is an open source project sponsored by the Eclipse Foundation.
This version of JET was not compatible with JET1. The IBM Eclipse-based products that
include JET2 also include JET1. To distinguished the technologies, JET2 officially became
EMFT JET. You will see the string EMFT JET in several places in IBM products.
The EMFT project is dedicated to developing new technologies related to modeling. When
these technologies reach maturity, they move on to other projects. This is the case with
JET. In early 2007, JET moved to the Model to Text (M2T) subproject of the Eclipse
474
Strategic Reuse with Asset-Based Development
Modeling Project. The M2T goal is to support the development and use of model-to-text
languages within Eclipse. In spite of this move, the EMFT JET name has been retained
(the potential for confusion with JET1 remains).
The M2T project plans to “graduate” in 2008. At that point, EMFT JET will completely
support the original JET1. Then, the EMFT prefix will be dropped from the name and the
integrated product will be called simply JET. But, this integrated version of JET is not likely
to make its way into IBM products until late 2008.
This book uses EMFT JET (JET2) exclusively. As a result, the book refers to EMFT JET
simply as JET. In screen captures and instructions, however, you will often see the text EMFT
JET.
Getting more information
The Eclipse foundation Web site is:
http://www.eclipse.org
You can get more information about the Model to Text (M2T) project and JET at:
http://www.eclipse.org/modeling/m2t
You can get more information about the Eclipse Modeling Project at:
http://www.eclipse.org/modeling
17.2.2 IBM tools for creating JET-based solutions
The productivity tools to which Deb’s consultant referred are called the JET Authoring Tools,
and are part of the Rational modeling platform products. These tools are not open source, but
they do produce JET transformations that require only the open source components to
execute.
Important: The tools discussed in this section are not included in default installations of
the Rational modeling platform 7.0 products. These tools are included in the optional
Transformation authoring component. If your installation does not include the tools
referenced in the section, start the IBM Installation Manager, click Modify Packages and
follow the wizard instructions to add Transformation authoring.
The JET authoring tools allow for rapid development of pattern implementations given an
example of the desired output of the transformation. This example output is referred to as an
exemplar or more simply as a reference solution. Figure 17-1 on page 476 illustrates this
process.
Chapter 17. Produce: Model-to-text pattern implementations
475
1. Jet Authoring
Input
Model
Reference
Solution
(Exemplar)
JET Transformation
Figure 17-1 JET exemplar-based authoring: working backward from a reference solution
This approach integrates with 16.5, “A process for pattern-based engineering” on page 462.
The JET authoring tools permit the development of a pattern implementation from a
candidate architecture (as described in 16.5.3, “Develop candidate architecture” on page 464
at a cost that is incremental to the cost of developing the candidate architecture initially).
Figure 17-2 illustrates the value proposition of using JET authoring for pattern-based
engineering.
Timelines to Value
Solve the problem, solve similar problems via manual pattern application
Solve the problem, implement a pattern, solve similar problems via
automatic pattern application
Legend:
Search asset repository for applicable assets
Solve problem manually
Author pattern implementation to automate solution
Use pattern implementation to solve problem
Figure 17-2 Time to value using JET authoring and pattern-based engineering
Analogy: Writing a form letter
Creating a JET transformation from an exemplar is analogous to creating a form letter in a
word processor. To create a form letter:
1. Create or find a letter that will serve as a model for the form letter. This is the reference
solution.
2. In your word processor, start the form letter by making a copy of the reference solution or
exemplar.
3. Identify parts of the letter that must be replaced with data fields. Insert appropriate
references to fields in the template letter.
476
Strategic Reuse with Asset-Based Development
4. If not already defined, define the database tables and columns.
JET authoring follows a similar process with a number of differences:
The reference solution (exemplar) with which you are working typically requires multiple
templates. JET authoring is similar to creating a customized portfolio of documents rather
than just a single document.
The input model that you create is not a flat structure, such as a database table. Instead,
the input model is hierarchical and includes several types of model elements. Think of the
model as an XML document rather than a table.
Authoring goals
JET authoring has several goals:
Define an input model structure that reveals the pattern’s abstractions and the desired
points of variability in the pattern.
Account for every file, folder, and project found in the reference solution (these are known
as exemplar artifacts). For each exemplar artifact, either match it to a model element from
which it is directly derived, or mark it as not-of-interest to the transformation.
The JET authoring process
The authoring process works iteratively toward achieving these authoring goals. The process
is driven by the exemplar artifacts and the need to identify abstracts that account for their
existence. At each step, a new abstraction is identified (which becomes a model element)
that accounts for one or more of the exemplar artifacts.
Figure 17-3 on page 478 illustrates the process for identifying a model element.
Chapter 17. Produce: Model-to-text pattern implementations
477
Figure 17-3 The process for identifying a new model element
In the next section, we will work with Deb Devak’s Java bean problem to illustrate this
process in detail.
Getting more information
The best way to learn a process is to work through it with an example, which is shown in 17.3,
“Developing a pattern implementation for Java beans” on page 479. If you are a visual
learner, the 7.0.0.2 and later versions of the Rational modeling platform tools include a “watch
and learn” tutorial. To view it, follow these steps:
1. Click Help → Tutorial Gallery.
2. In the tutorial gallery, click Watch and learn.
3. Click Create model-to-text transformations with JET.
The full tutorial takes approximately 60 minutes to view, although individual sections are much
shorter.
478
Strategic Reuse with Asset-Based Development
17.3 Developing a pattern implementation for Java beans
In this section, we will work through the development of a JET pattern implementation using
Deb Devak’s Java bean solution as the reference solution.
17.3.1 Create a JET authoring project
Deb has created an Eclipse Java project that contains her reference bean solution or
exemplar. The project is included in the supplemental materials that you can download. You
can import it into your workspace by following these steps:
1. Click File → Import.
2. Type existing to filter the available choices.
3. Click General → Existing Projects into Workspace and click Next.
4. Click Select archive file, and then click Browse.
5. Find the ch16exemplar.zip file from Appendix C, “Additional material” on page 725 within
the ABD-Part 4-Projects.zip file, and click OK.
6. Ensure that the project com.zyx.exemplar.beans is checked, and then click Finish.
Figure 17-4 shows the contents of this project.
Figure 17-4 The imported reference bean solution (exemplar)
Chapter 17. Produce: Model-to-text pattern implementations
479
When the exemplar project is in the workspace, create a project to contain the pattern
implementation by following these steps:
1. Click File → New → Project.
2. Enter jet to filter the available choices.
3. Click EMFT JET Project with Exemplar Authoring, and then click Next.
4. Enter a project name: com.zyx.patterns.beans and click Next.
Note on project naming that JET transformations are extensions (plug-ins) to the Eclipse
environment. Therefore, JET transformations must follow established naming
conventions. The convention is to use reverse domain name order, starting with your
organization’s internet domain name (in reverse order). Because ZYX Electronics’s
internet domain is zyx.com, the project name starts with this name is reverse order,
com.zyx.
5. Finally, select com.zyx.exemplar.beans (the reference bean solution) in the Exemplar
Scope list, and click Finish.
The wizard creates the JET transformation project and opens the JET transformation
authoring editor. Figure 17-5 shows the editor.
Figure 17-5 The newly created JET project and the JET transformation authoring editor
The JET transformation authoring editor has three key components:
The left pane, which is titled Exemplar shows all of the projects, files, and folders
contained in the reference solution. Collectively, these projects, files, and folders are
referred to as exemplar artifacts, or simply artifacts if the context is unambiguous. Note
480
Strategic Reuse with Asset-Based Development
that the pane includes files and folders that are normally hidden by certain Eclipse view
filters. (Notice the .project and .classpath files and the bin directory.)
The right pane, which is titled Transformation Input Schema and Output Actions, declares
the structure of the input model and the transformation actions. Transformation actions
are responsible for the creation of files, folders, or projects.
Finally, the Properties view provides detailed information about the current selection in
the editor.
With the JET transformation project created, Deb is ready to start the exemplar analysis
process.
17.3.2 Identify an abstraction
The first step in the analysis process is to identify an abstraction that represents one or more
exemplar artifacts. This is the key step in the process. It requires expert knowledge of the
reference solution domain. If the pattern implementation author does not have this
knowledge, the pattern implementation author needs to work closely with the subject matter
expert (SME) for this domain. By considering the remaining unassociated exemplar artifacts,
the SME must look for the “next” abstraction that accounts for at least part of the artifacts.
Using domain knowledge, the SME looks at artifacts and groups them into logical roles in the
architecture. The pattern implementation author must be listening for comments, such as:
These four projects constitute a XYZ type solution. (XYZ solution is an abstraction).
These six Java classes constitute an Enterprise Java Bean. (Enterprise Java Bean is an
abstraction.)
This Java class controls the actions of all of these other classes that represent operations.
(Controller is an abstraction, and operation appears to be a related, subordinate
abstraction.)
In Deb’s case, she notes that Book.java and Library.java are manifestations of Java beans,
and the LibraryFactory.java file is a manifestation of a group of related Java beans, which
Deb calls a “bean package”.
Note that not every abstraction discovered must be exposed in the input model’s structure.
Only abstractions that account for desired variability in the output count.
In this step, the goal is to identify the most inclusive abstraction that manifests at least one
point of variability. In Deb’s case, the “bean package” is more inclusive than “bean”, and so,
Deb selects bean package as the top-level abstraction.
Questions to ask
When identifying abstractions, it is helpful to ask the following questions:
Is this artifact a manifestation of an abstract concept?
What other artifacts are manifestations of the same concept?
Are aspects of this concept points of variation in the pattern?
Is this concept a subsidiary to another concept that has not already been identified?
Chapter 17. Produce: Model-to-text pattern implementations
481
17.3.3 Create a model element
This step translates the abstraction identified in the previous 17.3.2, “Identify an abstraction”
on page 481 section into a model element. Slightly different procedures are required,
depending on whether this is the first identified abstraction.
The first identified abstraction
The first abstraction that you identify is a candidate for the top-level abstraction in your model.
The top-level abstraction is representative of the pattern itself − there must be only one
top-level abstraction.
For the first identified abstraction, you can choose to implement it as the root element of the
model or as a child element of a meaningless root element. Recall that we conceive of our
model as an XML document. XML documents can have only one root element. If the top-level
abstraction is implemented as the root element, a model instance can only describe one
instance of the pattern. However, using a child element of a meaningless root element allows
a single input model to describe multiple pattern instances.
In general, a model that allows multiple instances of its top-level abstraction allows more
flexibility at little cost, so we recommend the second approach.
Best Practice: Create the top-level model abstraction as the child of a generic “root”
element, which lets a model define multiple instances of your pattern.
In Deb’s case, the first abstraction identified is “bean package”. Following best practices, Deb
elects to have a meaningless root element (called root). Follow these steps to create the first
model element:
1. Right-click root in the right pane and click New → Type.
2. Enter beanPackage as the element name. The editor enforces a naming convention where
names start with a letter and contain only letters and numbers. If the text that you enter
violates these conventions, the editor modifies the text that you entered to conform to the
convention.
Figure 17-6 shows the result.
Figure 17-6 The JET authoring editor after the creation of the first abstraction called beanPackage
482
Strategic Reuse with Asset-Based Development
All other abstractions
For all abstractions other than the top-level abstraction, you must identify a parent
abstraction. The parent abstraction serve as a container for the abstraction. For example,
Deb’s bean abstraction has the “bean package” abstraction as its parent.
The inability to identify a parent abstraction indicates one of several situations:
There is an undiscovered abstraction that includes the current top-level abstraction and
the new abstraction.
There are two distinct patterns in your exemplar. In this case, create a second pattern
implementation project.
The existing top-level concept is a child of the new concept.
In Deb’s case, the “bean” abstraction is a child of “beanPackage”. Deb creates another
element type in her model by following these steps:
1. Right-click beanPackage in the right pane and click New → Type.
2. Enter bean as the element name.
Figure 17-7 shows the result.
Figure 17-7 The JET authoring editor after the bean abstraction has been defined
You can read the model description on the right pane as:
A model has a single “root” element.
The root element has zero or more “beanPackage” elements.
Each beanPackage element has zero or more “bean” elements.
17.3.4 Identify exemplar artifacts arising directly from the abstraction
The newly defined abstractions arose from considering one of more exemplar artifacts. Now,
you must consider how those artifacts arise from those abstractions and whether your pattern
implementation generated them.
Chapter 17. Produce: Model-to-text pattern implementations
483
What artifacts to consider
During this activity, you consider only artifacts that are in a one-to-one relationship with an
abstraction. That is, if you can say “This kind of artifact gets created one time for every
instance of this model element,” the artifact must be considered.
In Deb’s case, the LibraryFactory.java artifact is a direct manifestation of beanPackage. For
every beanPackage, there must be exactly one factory class. The files Library.java and
Book.java are direct manifestations of bean. For every bean, there must be exactly one bean
class. So, LibraryFactory.java is associated with beanPackage, and Library.java and
Book.java are associated with bean.
Normally, JET transformations create any necessary folders automatically. Thus, you do not
need to explicitly account for most exemplar folders. Exemplar files and projects, however,
must be explicitly created.
For each file and project artifact, you must decide:
Will the artifact be generated by the pattern implementation? In this case, the artifact will
be handled in the next step.
Will the artifact not be generated by the pattern implementation? This can happen if the
artifact is generated by another process, such as a compiler. In this case, the file’s
artifacts can be deleted from the exemplar pane by right-clicking the artifact and clicking
Delete. Folder and project artifacts must be deleted from the exemplar pane only if none of
their contents is to be generated. Otherwise, they must be marked as ignored by
right-clicking the artifact and clicking Ignore.
For each folder identified as requiring generation, you must decide:
Is the folder necessary for the structural integrity of the project? Java source folders are an
example. Most other folders do not meet this criteria. Folders that meet this criteria will be
handled in the next step.
Is the folder part of the path to another identified artifact? In this case, the artifact can be
marked as ignored. Right-click the folder, and click Ignore.
In Deb’s case, there are a number of artifacts that Deb does not want her pattern
implementation to generate:
The bin directory and all of its contents are produced by the Java content. Delete the bin
directory and all of its contents from the exemplar artifacts pane by right-clicking the bin
folder, and then clicking Delete.
Deb is uncertain about the .* files, so she right-clicks them, and clicks Ignore. She does
the same for the chain of directories from src down to library. If she changes her mind, she
can always right-click them again, and click Unignore.
Figure 17-8 on page 485 shows the resulting editor.
484
Strategic Reuse with Asset-Based Development
Figure 17-8 The exemplar view with bin deleted and the other files ignored
17.3.5 Create actions
Artifacts that are produced by the pattern implementation are created by the execution of a
transformation action. JET authoring includes the following types of actions:
File actions, which create a file by expanding a JET template
Folder actions, which create a folder
Project actions, which create an Eclipse project
Copy file actions, which copy a file (no template expansion occurs). Copy file actions are
useful for binary files, such as images.
Actions are contained within model elements. Each time that a model element is encountered
in an input model, that actions that it contains are executed. The artifacts identified in the
previous 17.3.4, “Identify exemplar artifacts arising directly from the abstraction” on page 483
section represent the output of required transformation actions. These actions must now be
defined.
Actions can be defined by dragging an exemplar artifact onto an model element. Deb has
determined that LibraryFactory.java is a manifestation of the “beanPackage” abstraction, so
she drags the file from the left pane and drops it on beanPackage. Figure 17-9 on page 486
shows the result.
Chapter 17. Produce: Model-to-text pattern implementations
485
Figure 17-9 The action created by dragging LibraryFactory.java to beanPackage
Dragging LibraryFactory.java to beanPackage results in a new child of beanPackage called
Create File: LibraryFactory.java. This is a file action. JET authoring has created a
suggested name for the action, but in many cases, you will want to change it to a name that
describes the purpose of the artifacts that are produced.
Note also, that JET authoring has placed a check mark on LibraryFactory.java in the
Exemplar pane to indicate that it is associated with a transformation action.
In Deb’s case, a purpose of the new action is to create a factory Java class. Change the
name to factory.java by following these steps:
1. Double-click Create File: LibraryFactory.java. The text LibraryFactory.java will be
selected.
2. If the text LibraryFactory.java is not selected, select it. Then, replace the text with
factory.java.
Ultimately, JET authoring will create a JET template called factory.java.jet for this action. The
template will be evaluated to produce the factory class’ contents. The convention is to include
the ultimate content extension in the file action’s name (hence, the name factory.java).
Figure 17-10 on page 487 shows the updated action name.
486
Strategic Reuse with Asset-Based Development
Figure 17-10 The renamed action for creating the bean factory class
Deb next considers the artifacts Book.java and Library.java. These are both manifestations of
a single concept, bean. They both represent the Java class that implements the bean.
Therefore, only one action is required to create them. Create the action:
1. Drag Library.java onto bean in the right pane. Name the action bean.java.
2. Drag Book.java onto the Create File: bean.java action.
Figure 17-11 shows the resulting input action.
Figure 17-11 The bean.java action with Book.java and Library.java associated with it
Chapter 17. Produce: Model-to-text pattern implementations
487
The tree in the right pane now indicates that the transformation has two actions:
For each bean instance, Create File: bean.java will be executed. The reference solution
includes two artifacts that must be produced by this action: Book.java and Library.java.
For each beanPackage instance, Create File: factory.java is executed. The reference
solution includes one artifact, LibraryFactory.java, that must be produced by this action.
17.3.6 Parameterize actions
After transformation actions have been defined, they must be parameterized so that they
respond to values in the input model. This task involves several changes to the input model
and output actions:
Attributes will be added to model elements to represent values required as input.
Action properties will be modified to reference these attributes where required.
Repeated calculations will be encapsulated in derived attributes, which appear to be
normal attributes, but which are calculated rather than specified as input.
Parameterizing actions makes use of the Properties view. Figure 17-12 shows the properties
for the action Create File: factory.java.
Figure 17-12 Properties of the Create File: factory.java
Each action has a number of action parameters. JET authoring has set several of these
values based on the properties of the exemplar artifact that is used to define the action.
Typically, the pattern implementation author must examine each of these parameters to
determine whether any part of the parameter must derive from the input model or a
calculation based on the input model.
Parameterize the factory.java action
In the case of the Create File: factory.java action, the parameter path needs
parameterization. The following changes through parameterization must be made:
Do not hard code com.zyx.exemplar.beans/src as the Java source folder. Deb decides
that users will provide this information directly. This will be a point of variability of the
pattern implementation.
Do not hard code the folder com/zyx/exemplar/beans/library. The folder corresponds to
the Java package containing the factory java class. The directory name is derived from the
package name com.zyx.exemplar.beans.library. Deb composed of a name for the bean
package (library) and a base package that is a common prefix for many packages in the
project (com.zyx.exemplar.beans). Deb decides to represent these values as separate
attributes in the input model: a base package and a bean package name.
488
Strategic Reuse with Asset-Based Development
Do not hard code the factory class name as LibraryFactory. Deb decides that this class
name derives from the already identified name for the bean package with the text Factory
appended.
Create the new attributes:
1. Right-click beanPackage in the right pane, click New → Attribute, and enter srcFolder.
2. Right-click beanPackage again, click New → Attribute, and enter basePackage.
3. Right-click beanPackage a final time, click New → Attribute, and enter name.
Figure 17-13 shows the results of these actions.
Figure 17-13 Attributes defined for beanPackage
Modify the path parameter of Create File: factory.java:
1. Click Create File: factory.java in the right pane.
2. In the Properties view, select the text com.zyx.exemplar.beans/src in the path field.
Right-click the selection and click Replace with Model Reference. Figure 17-14 shows
the resulting dialog.
Figure 17-14 The Replace with Model References dialog
The dialog lets you select a model attribute and insert it in place of the selected text.
Expand beanPackage, select srcFolder and click OK. Figure 17-15 on page 490 shows
the resulting value for the path parameter.
Chapter 17. Produce: Model-to-text pattern implementations
489
Figure 17-15 The XPath expression inserted by the Replace with Model References dialog
The string {$beanPackage/@srcFolder} has replaced the original selection. This is an XML
Path (XPath) expression. JET uses XPath to reference data in the input model. The
expression is interpreted as:
– The braces delimit the expression from the surrounding text.
– $beanPackage is a reference to the XPath variable beanPackage. JET authoring
defines a variable for each element type. By default, the variable name is the same as
the element type. You can view and change the variable name in the Properties view
for each element type.
– The slash (/) separates the steps in the expression, similar to a file system path.
– @srcFolder references the srcFolder attribute of the beanPackage element.
You can learn more about XPath in 17.5, “An XPath primer” on page 518.
3. Define the derived attribute for the directory to contain the generated factory and bean
classes. Select the text com/zyx/exemplar/beans/library, right-click it, and click Replace
with Model Reference.
4. Expand and select beanPackage in the dialog. There is no attribute representing the
directory for the bean classes. To create one, ensure beanPackage is selected, and then
click New. Figure 17-16 shows the resulting Create new derived attribute dialog.
Figure 17-16 The Create new derived attribute dialog
The dialog lets you define an attribute whose value is derived from a calculation. It shows
the attribute’s name, the text that you selected to create in step 3 (the exemplar text), and
the calculation of the value. The calculation is initially the same as the exemplar text. For
the time being, we will leave the calculation unchanged.
5. Enter dirBeans in the Attribute Name field and click OK. Click OK again in the Replace
with Model References dialog. Figure 17-17 on page 491 shows the resulting path value.
490
Strategic Reuse with Asset-Based Development
Figure 17-17 The path parameter after replacing the beans directory (dirBeans)
6. Define a derived attribute for the factory class name. Select LibraryFactory, right-click it
and click Replace with Model Reference.
7. Expand and select beanPackage and click New.
8. Enter clsFactory as the Attribute Name.
9. In the Calculation field, select Library, and then click Insert Model Reference.
10.Expand beanPackage, click name, and click OK. Figure 17-18 shows the Create New
Derived Attribute dialog.
Figure 17-18 The definition of the clsFactory derived attribute
11.Prior to closing this dialog, modify the XPath expression $beanPackage/@name so that it
ensures that the name is properly formatted for Java names by calling the XPath function
camelCase. Enter camelCase($beanPackage/@name) in place of the original XPath
expression. Remember to retain the braces. Figure 17-19 shows the final result.
Figure 17-19 The clsFactory derived attribute calculation using the XPath camelCase function
12.Click OK to close the dialog, and click OK again to close the Insert Model References
Dialog. The final value of the path parameter is shown in Figure 17-20 on page 492.
Chapter 17. Produce: Model-to-text pattern implementations
491
Figure 17-20 The final value of the path parameter
The action Create File: factory.java is now completely parameterized. However, the
calculation of the derived attribute dirBeans is not complete. In order to complete it, create
another derived attribute representing the Java package into which the bean classes will be
written. Follow these steps:
1. Right-click beanPackage in the right pane, and click New → Derived Attribute.
2. Enter pkgBeans as the Attribute Name.
3. Enter com.zyx.exemplar.beans.library as the Exemplar Text and as the Calculation (we
will modify the calculation in the next step).
4. Select com.zyx.emplar.beans in the Calculation field, click Insert Model Reference,
expand beanPackage, select the basePackage attribute, and click OK.
5. Select library in the Calculation field, click Insert Model Reference, expand
beanPackage, select the name attribute, and click OK.
6. Modify the XPath expression $beanPackage/@name by calling the lower-case function,
and creating the XPath expression lower-case($beanPackage/@name). Figure 17-21
shows the final calculation.
Figure 17-21 The definition of the pkgBeans derived attribute
7. Next, update the calculation for the dirBeans calculation. Click dirBeans in the right tree.
8. In the Properties view, look at the Calculation parameter. Replace the value with:
{translate( $beanPackage/@pkgBeans, ‘.’, ‘/’ )}
This value uses the XPath function translate to replace the dots in the package name with
the slash character (/).
Figure 17-22 on page 493 shows the final calculation.
492
Strategic Reuse with Asset-Based Development
Figure 17-22 The calculation for the derived attribute dirBeans
Finally, the derived attribute calculation for dirBeans depends on the calculated value for
pkgBeans. It is important to ensure that the calculations occur in the correct order.
1. Click the Sort on Calculation Order icon in the JET authoring editor. Figure 17-23 shows
this icon circled.
Figure 17-23 The Sort on Calculation Order icon in the JET authoring editor
2. Right-click pkgBeans and click Move → Up. Repeat until pkgBeans is listed higher than
dirBeans in the tree.
3. Click the Sort Alphabetically icon (to the left of the Sort on Calculation Order icon).
Parameterize the bean.java action
Next, the action Create File: bean.java must be parameterized, which is a similar task to the
parameterization of the factory action.
The bean.java action will reuse the srcFolder and dirBeans derived attributes. In addition, a
name is required for the bean class itself. This suggests that each bean element must have a
name attribute.
Create the name attribute and parameterize the bean.java action:
1. Expand bean in the rightmost tree of the JET authoring editor.
Chapter 17. Produce: Model-to-text pattern implementations
493
2. Right-click bean and click New → Attribute. Type name and press Enter.
3. Click Create file: bean.java.
4. In the Properties view, select com.zyx.exemplar.beans/src (the Java source folder),
right-click and click Replace with Model Reference.
5. The Replace with Model Reference dialog appears with the srcFolder derived attribute
already selected. (This was the last value that replaced the selected text).
6. Click OK to insert the reference.
7. Select com/zyx/exemplar/beans/library, right-click and click Replace with Model
Reference. The dirBeans derived attribute is automatically selected. Click OK to insert the
reference.
8. Select Library, right-click and click Replace with Model Reference. This time, a new
derived attribute will need to be created to represent the bean class name. Expand the
tree to reveal bean, select it, and then click New.
9. Enter clsBean as the Attribute Name.
10.In the Calculation field, select Library, and click Insert Model Reference. Expand the
tree to reveal bean and its contents, and select the name attribute underneath bean. Click
OK.
11.Surround the XPath expression $bean/@name with a call to the XPath function
camelCase. Figure 17-24 shows the final calculation.
Figure 17-24 The calculation for derived attribute clsBean
12.Click OK to create the derived attribute. Click OK again to insert the reference into the
path parameter. Figure 17-25 shows the final value for the bean.java action’s path
parameter.
Figure 17-25 The completed path parameter for the Create File: bean.java action
The parameterization of actions is now complete.
494
Strategic Reuse with Asset-Based Development
17.3.7 Update templates
Up to this point, Deb has been describing her transformation in the JET authoring editor. Now
that all of the actions are described, she is ready to parameterize the templates that create
the content for the file actions.
JET authoring uses a transformation (a JET transformation, of course) to convert the
transformation model into appropriate JET templates. To invoke this transformation, right-click
any element in the rightmost tree and click Update Project. A JET transformation project will
be updated to reflect any changes made in the JET authoring editor.
Updating a JET project affects the following files:
The templates/main.jet file, which is responsible for coordinating the transformation’s
execution. It computes derived attribute values and executes the actions defined in the
JET authoring editor.
The schema.xsd file, which is an XML Schema (XSD) that can be used in conjunction with
an XSD-aware XML editor to produce well formed input for the JET transformation.
Templates corresponding to JET actions. These templates are created if they do not exist.
They are not overwritten by subsequent project updates. When a template is created, its
content is set to the content of the exemplar file that is used to create the output action.
The first time Deb updates the JET project, the following files are updated:
templates/main.jet
schema.xsd
templates/beanPackage/factory.java.jet
templates/bean/bean.java.jet
Subsequent updates will only update the first two files, unless new actions are created, or one
of the action templates is removed or renamed.
17.3.8 Parameterize templates
The final step is to modify the templates created by JET authoring to include appropriate
annotations to customize the template output to the model.
Annotations in JET templates are done via XML tags, called custom tags or JET tags. The
most common types of annotations done in a JET template are:
The JET tag <c:get> gets a value from the input model (or a derived attribute).
The JET tag <c:iterate> repeats a block of template text by iterating over part of the input
model.
The JET tag <c:if> conditionally includes a block of template text by evaluating a condition.
All of these tags reference the input model using XPath expressions.
You will see examples of each tag as you work through parameterizing the templates in Deb’s
transformation.
Parameterizing the factory.java.jet template
The template factory.java.jet created by the update project command is a copy of the
exemplar file LibraryFactory.jet. The text must be parameterized to refer to model elements
where appropriate. In parameterizing the template, the task is to identify text that can be
replaced by information in the model.
Chapter 17. Produce: Model-to-text pattern implementations
495
Replacing text with model references
JET authoring helps identify this text by remembering previous text replacements. Each
model attribute and derived attribute has associated “Exemplar Text”. Each time that the text
is replaced by a reference to an attribute or derived attribute, JET authoring remembers the
original text. When you edit a template, JET authoring highlights any occurrences of these
remembered text strings and displays special annotations on the text.
Figure 17-26 shows the contents of the template factory.java.jet as it was created by the JET
authoring project update.
Figure 17-26 The JET template factory.java.jet showing editor annotations of replaceable text
Note that the text com.zyx.exemplar.beans.library is highlighted. It was referenced as
exemplar text when the derived attribute pkgBeans was defined in Figure 17-21 on page 492.
The JET editor highlights this text in three ways:
It is underlined with a blue wavy line.
A blue “information” icon appears in the left margin next to the line containing the text.
A yellow file position bar appears in the right margin. (The total height of the right margin
represents the length of the template. The yellow marks represent the relative position of
the text in the template.)
In addition to annotations in the editor, the Problems view includes an Information message
associated with the line. Figure 17-27 on page 497 shows the message for the first line in the
template.
496
Strategic Reuse with Asset-Based Development
Figure 17-27 The Problems view shows the information marker for replaceable text
To replace highlighted text with a model reference, you can use the editor’s quick fix
command:
1. Click anywhere in the text.
2. Press Ctrl-1. Figure 17-28 shows the pop-up list quick fix actions.
Figure 17-28 Quick fix choices for com.zyx.exemplar.beans.library
3. Click Replace “com.zyx.exemplar.beans.library” with “$beanPackage/@pkgBeans”,
and press Enter. The resulting template line is:
package <c:get select="$beanPackage/@pkgBeans" />;
The c:get tag evaluates the XPath expression specified in its select attribute and writes
the expression value to the expanded template.
In certain cases, a single text selection has multiple possible replacements. In this case, the
quick fix list will show them all. The replacements are sorted first by length of the replaceable
text (longest text is listed first) and then by the replacement XPath expression.
Moving between replaceable text annotations
Most templates have many replaceable text annotations. You can navigate quickly between
them by using the editor’s navigation capabilities. Pressing Ctrl-. moves you forward to the
next annotation. Pressing Ctrl-, will move you backward to the previous annotation. These
commands are shortcuts for the menu commands Navigate → Next Annotation and
Navigate → Previous Annotation, respectively.
Chapter 17. Produce: Model-to-text pattern implementations
497
To finish replacing text, use the navigation and quick fix commands to replace each
highlighted text string with the first proposed fix. There is one exception: the string Library
when it is embedded in the longer string createLibrary, and it is desirable to create a derived
attribute representing the entire string.
Identifying new replaceable text
Create a new derived attribute to calculate the text createLibrary. The original template line is:
public Library createLibrary() {
It is a good practice in templates to only replace whole language tokens. If part of a token is
flagged as replaceable, it is best to create a derived attribute to represent the entire token.
Following this practice means that the language token (in this case, a method name) is
encapsulated, which allows you to quickly implement name convention changes.
To create a new derived attribute for the method name, follow these steps:
1. Select the text createLibrary.
2. Right-click it, and click Find/Replace with JET Model Reference. The dialog in
Figure 17-29 appears.
Figure 17-29 The Find/Replace with model reference dialog
3. Create a new derived attribute representing the name of the method that instantiates a
bean. One method is required for each bean, so the derived attribute must be defined on
bean. Expand the tree to find and select bean, and click New.
4. Enter mthdCreate for the Attribute Name.
5. Select Library in the Calculation field, and click InsertModelReference.
6. Click clsBean, and then click OK. Figure 17-30 on page 499 shows the resulting derived
attribute dialog.
498
Strategic Reuse with Asset-Based Development
Figure 17-30 The definition of the derived attribute mthdCreate
7. Click OK to create the attribute, click Replace, and then click Close to insert the model
reference and close the Find/Replace dialog.
Inserting a repeating block of text
The role of the factory class is to provide a create method for each bean, which suggests the
template will require a repeating block that generates each create method.
The template contains a block of text that is already parameterized to produce a create
method for a bean. All that remains is to include annotations to repeat the block for each
bean.
Example 17-4 shows the factory template as it is now. The parameterized create method is
highlighted in bold.
Example 17-4 The factory.java.jet template before defining a repeating block
package <c:get select="$beanPackage/@pkgBeans" />;
/**
*
*/
public class <c:get select="$beanPackage/@camelCase" /> {
/**
* Singleton instance of the <c:get select="$beanPackage/@camelCase" />
*/
public static final <c:get select="$beanPackage/@camelCase" /> INSTANCE = new
<c:get select="$beanPackage/@camelCase" />();
/**
* Private constructor prevents instantiation.
*/
private <c:get select="$beanPackage/@camelCase" />() {
}
/**
* Create a new book instance
* @return the new Book object
*/
public Book createBook() {
return new Book();
}
Chapter 17. Produce: Model-to-text pattern implementations
499
/**
* Create a new library instance
* @return the new <c:get select="$bean/@clsBean" /> object
*/
public <c:get select="$bean/@clsBean" /> <c:get select="$bean/@mthdCreate" />() {
return new <c:get select="$bean/@clsBean" />();
}
}
Follow these steps to make the block repeating:
1. Just prior to the Java doc comment for the parameterized create method, insert a JET
c:iterate tag:
<c:iterate select=”$beanPackage/bean” var=”bean”>
2. At the end of the parameterized method, insert a closing c:iterate tag:
</c:iterate>
3. Remove the method createBook and its Java doc comment. It is not needed in the
template.
Example 17-5 shows the modified template with the iterate block highlighted in bold.
Example 17-5 The factory.java.jet template with a repeated block.
package <c:get select="$beanPackage/@pkgBeans" />;
/**
*
*/
public class <c:get select="$beanPackage/@clsFactory" /> {
/**
* Singleton instance of the <c:get select="$beanPackage/@clsFactory" />
*/
public static final <c:get select="$beanPackage/@clsFactory" /> INSTANCE = new
<c:get select="$beanPackage/@clsFactory" />();
/**
* Private constructor prevents instantiation.
*/
private <c:get select="$beanPackage/@clsFactory" />() {
}
<c:iterate select="$beanPackage/bean" var="bean">
/**
* Create a new library instance
* @return the new <c:get select="$bean/@clsBean" /> object
*/
public <c:get select="$bean/@clsBean" /> <c:get select="$bean/@mthdCreate" />() {
return new <c:get select="$bean/@clsBean" />();
}
</c:iterate>
}
500
Strategic Reuse with Asset-Based Development
One final change is required. The Java doc comment in the create method block still
references the text library. Replace it with a reference to the bean name:
1. Select the text library. Right-click and click Find/Replace with Model Reference.
2. Expand the tree to expose bean and its attributes. Select the attribute name.
3. Click Replace and then Close.
The factory template is now complete. Save and close the editor. Click File → Save and then
File → Close.
Update the JET project
In the process of parameterizing the factory template, a derived attribute was defined. In
order that this definition be reflected in the generated main.jet file, the JET project must be
updated. Follow these steps:
1. If the JET authoring editor is not open, open it by double-clicking transform.tma.
2. Right-click any element in the rightmost tree, and click Update Project.
Parameterizing the bean.java.jet template
Parameterization of the bean template follows a similar process to that of parameterizing the
factory template. In the interest of brevity, we do not provide detailed steps. Instead, we will
review the key issues that must be addressed. The complete JET transformation is available
as additional material for this book. Refer to Appendix C, “Additional material” on page 725
and look inside the ABD-Part 4-Projects.zip file for ch16transform.zip.
Representing bean properties in the input model
The input model structure has been driven observing workspace artifacts. Java bean
properties do not manifest themselves as artifacts, so they have not yet been included in the
input model description. You must define:
A new element type property contained by bean
A new attribute name on property
A new attribute type on property
Representing list properties in the input model
Recall that the case study requires that beans are able to reference other beans. These list
properties must be represented in the input model. Deb has chosen to implement them as:
A new element type listProperty contained by bean
A new attribute name on listProperty
A new attribute containedBeanName on listProperty
Derived attributes on property
During the parameterization of the bean.java.jet template, the following derived attributes
were identified and defined for property:
mthdGetter
The name of the get method for the property
mthdSetter
The name of the set method for the property
varField
The name of the Java field containing the property value
varLocal
The name of a Java local variable that will contain the value
Chapter 17. Produce: Model-to-text pattern implementations
501
Derived attributes on listProperty
During the bean parameterization of the bean.java.jet template, the following derived
attributes were identified and defined for listProperty:
mthdGetter
The name of the get method for the listProperty
varField
The name of the Java field containing the list contents
The completed bean.java.jet template
Example 17-6 shows the final text of the bean.java.jet template. JET comments (<%-- --%>)
have been added to explain several of the tags. The only new tag is c:if which is used to
create a conditional block; the block is expanded only if the bean has list properties.
Example 17-6 The completed bean.java.jet template
package <c:get select="$beanPackage/@pkgBeans" />;
<%-- only generate list imports if list properties are defined --%>
<c:if test="$bean/listProperty">
import java.util.ArrayList;
import java.util.List;
</c:if>
/**
* Implement bean <c:get select="$bean/@name"/>
*/
public class <c:get select="$bean/@clsBean" /> {
<%-- define fields for 'property' elements --%>
<c:iterate select="$bean/property" var="property">
private <c:get select="$property/@type" /> <c:get select="$property/@varField" />;
</c:iterate>
<%-- define fields for 'listProperty' elements --%>
<c:iterate select="$bean/listProperty" var="listProperty">
private final List <c:get select="$listProperty/@varField" /> = new ArrayList();
</c:iterate>
/**
* Package private constructor prevents instantiation except through factory
*/
<c:get select="$bean/@clsBean" />() {
}
<%-- define getter and setter methods for 'property' elements --%>
<c:iterate select="$bean/property" var="property">
/**
* Return the <c:get select="$beanPackage/@name" /> <c:get
select="$property/@name" />.
* @return the <c:get select="$property/@name" />
*/
public <c:get select="$property/@type" /> <c:get select="$property/@mthdGetter"
/>() {
return <c:get select="$property/@varField" />;
}
502
Strategic Reuse with Asset-Based Development
/**
* Set the <c:get select="$beanPackage/@name" /> <c:get select="$property/@name"
/>
* @param <c:get select="$property/@varLocal" /> the new <c:get
select="$property/@name" />
*/
public void <c:get select="$property/@mthdSetter" />(<c:get
select="$property/@type" /> <c:get select="$property/@varLocal" />) {
this.<c:get select="$property/@varField" /> = <c:get select="$property/@varLocal"
/>;
}
</c:iterate>
<%-- define getter methods for 'listProperty' elements --%>
<c:iterate select="$bean/listProperty" var="listProperty">
/**
* Return the list of <c:get select="$listProperty/@name" /> in the <c:get
select="$beanPackage/@name" />
* @return a list of <c:get select="$beanPackage/bean[@name =
$listProperty/@containedBeanName]/@clsBean" /> objects. Will not be
<code>null</code>
*/
public List <c:get select="$listProperty/@mthdGetter" />() {
return <c:get select="$listProperty/@varField" />;
}
</c:iterate>
}
17.3.9 Running the JET transformation
With the transformation complete, it is time for Deb to test it. These are the instructions Deb
wrote for using her transformation:
1. Create a Java project:
a. Click File → New → Project.
b. Click Java → Java Project, then click Next.
c. Enter a project name, and specify a source folder, such as src.
d. Click Finish.
2. Ensure that the XML capability is enabled. IBM Rational System Developer (RSD) and
IBM Rational Software Modeler (RSM™) do not include the XML capability:
a. Click Windows → Preferences.
b. Click General → Capabilities.
c. Check XML Developer, and click OK.
3. In the root of the Java project, create a file named beans.xml:
a. Click File → New → Other.
b. Select XML → XML. With RSD and RSM, you must select General → File. Click Next.
c. Click Create XML file from an XML schema file and click Next. (Skip this step for
RSD and RSM.)
Chapter 17. Produce: Model-to-text pattern implementations
503
d. Enter the file name beans.xml and specify a location in the root folder of the project
created in step 1. Click Next. (With RSD and RSM, click Finish, and skip the next
step).
e. Click Select file from workbench and select com.zyx.patterns.beans/schema.xsd
as the XML schema. Click Next, and then click Finish.
4. Enter data. Example 17-7 models a simple archive. Note that the XML Editor (not available
in RSD and RSM) has two tabs: Design and Source. Click the Source tab to enter the
example text.
Example 17-7 Test input describing a simple archive
<<?xml version="1.0" encoding="UTF-8"?>
<root
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="../com.zyx.patterns.beans/schema.xsd">
<beanPackage basePackage="test.bean.proj.base"
name="my archive"
srcFolder="test.bean.proj/src">
<bean name="building">
<property name="location" type="String"/>
<property name="name" type="String"/>
<listProperty name="artifacts"
containedBeanName="artifact"/>
</bean>
<bean name="artifact">
<property name="catalog number" type="int"/>
<property name="description" type="String"/>
<property name="date entered"
type="java.util.Calendar"/>
</bean>
</beanPackage>
</root>
5. Save and close beans.xml.
6. Configure the JET transformation to run:
a. Select beans.xml in the Package Explorer, Navigator, or Project Explorer view. Click
Run → Run.
b. Select JET Transformation, and click the New icon (the first icon on the tool bar).
c. For Name, enter Generate beans for project name, where project name is the name
of the project that you created in step 1.
d. For Transformation Input, ensure that the beans.xml file is listed. If not, click Browse to
select it.
e. For ID, select com.zyx.patterns.beans.
Figure 17-31 on page 505 shows the completed field values.
504
Strategic Reuse with Asset-Based Development
Figure 17-31 The Run dialog defining the test launch of the zyx beans transformation
f. Click Run.
As the JET transformation executes, it produces progress information in the Console view.
Figure 17-32 shows the console output.
Figure 17-32 JET Console output
The transformation ran, and the Java beans were created, just the way that Deb liked them.
Can these instructions be another pattern
Just as Deb was about to declare victory, something the IBM consultant said came back to
her:
“Long lists of instructions are often a sign of an undiscovered pattern.”
Chapter 17. Produce: Model-to-text pattern implementations
505
Deb wondered if these setup instructions can be automated with JET, too.
The answer is yes, and a pattern com.zyx.patterns.beans.setup has been included in the
Appendix C, “Additional material” on page 725 inside the ABD-Part 4-Projects.ZIP for the
ch16transform.setup.zip file.
17.4 Enabling iterative development
Most software development is iterative. That is, software artifacts are designed, created,
tested, evaluated, and then revised (often repeatedly). If a pattern implementation is used, in
most cases, it must accommodate this iteration. Typically, this means that pattern
implementations cannot destroy valuable artifacts created by a previous invocation of the
pattern, nor can they destroy user-created artifacts. This section discusses when and how a
pattern implementation must support iterative development.
17.4.1 Case study: Adding derived properties to beans
The bean pattern created in the case study overwrites the generated Java files each time that
it is run. So far, this is not a problem. Developers can use the generated beans “as is”. But, in
many pattern implementations, things are not so simple.
When Deb showed her bean pattern to other developers, they were generally positive.
However, a number of developers noted that sometimes it is desirable to have properties on a
bean that derive their value from other properties. Deb thinks this is a good idea, but Deb
cannot imagine being able to succinctly model the calculations using JET authoring. The
most obvious thing to do is to have the bean transformation generate a stub implementation
of the property getter method, and let the bean developer provide the implementation.
Deb quickly updates her reference solution with a derived property. Example 17-8 shows a
typical derived property solution.
Example 17-8 An implementation of a derived property
/**
* Return the library years open (derived)
* @return the years open
*/
public int getYearsOpen() {
return java.util.Calendar.getInstance().get(java.util.Calendar.YEAR)
- getYearFounded();
}
But, Deb still has the problem of how to integrate this into the bean.java.jet template. A
straightforward modification of the template means that each time that the pattern was run on
the same input, any custom code previously entered is lost.
What Deb needs is a strategy for dealing with aspects of a reference solution that are too
complex (or too inconvenient) to capture in the transformation’s abstraction. We call this
problem an incomplete abstraction. Another term is a leaky abstraction.
506
Strategic Reuse with Asset-Based Development
17.4.2 Reapply strategies: Handling incomplete abstractions
Incomplete abstractions occur frequently when creating pattern implementations. The goal of
a pattern implementation is to reliably reproduce the common aspects of a proven solution.
But interesting pattern applications usually have unique characteristics (otherwise, the
pattern has been bundled up into a standard application programming interface (API) long
ago). The pattern author must accept that their pattern abstractions will usually be incomplete
and learn techniques that integrate pattern-generated artifacts with the user-created artifacts.
We call these techniques reapply strategies, because they come into effect when a
transformation is applied repeatedly on the same input.
There are three ways that a pattern implementation can deal with an incomplete abstraction:
Complete the abstraction.
Let the user edit the generated solution to introduce the to-be-completed aspects.
Re-factor the generated solution to separate the to-be-completed aspects from generated
ones.
In the second case, identifying and protecting user changes to the generated solution
becomes a concern of the pattern author. However, in any case, it is important that a pattern
implementation establish a contract with the user regarding generated artifacts.
Pattern implementation contracts
Every pattern implementation must document a contract with its users specifying (the names
are appropriate from the users’ perspective):
Non-modifiable files Files that the transformation owns and that users must not modify
User files
Files that the users own and that the transformation will not modify
Shared files
Files that both users and the transformation can modify
Shared files require additional contract terms, indicating how and when users and the
transformation can modify a file, how their changes will be identified, and how conflicts will be
resolved.
Tip: Avoid having shared files in your transformations, if at all possible.
Case study: Implementation choices for derived properties
Deb has come up with several approaches for supporting derived properties in the bean
pattern.
Capture the calculations in the model (that is, complete the abstraction)
Generate stub methods for derived attributes, and have users complete them (that is,
generated shared files.)
Refactor the generated solution so that the derived attribute calculations are stored
separately (in user files) from the rest of the bean and factory classes (non-modifiable
files).
Chapter 17. Produce: Model-to-text pattern implementations
507
Deb has rejected the first option as impractical. While the calculations can be included in the
model simply as strings, this approach leads to a significantly degraded editing environment
for the derived property calculations. She has identified four other approaches:
Shared file approaches:
– Use JETs generic “user region” tags to protect user-entered calculations in the bean
classes.
– Use JETs Java-specific “jmerge” tags to implement a more sophisticated mechanism
to protect user-entered code in the bean classes.
User file approaches:
– Modify the bean class to delegate the derived property calculation to a utility class. The
utility class is a user file, while the bean class remains a non-modifiable file.
– Modify the bean class to declare the getter method derived property as abstract, and
modify the factory to instantiate a concrete class that implements the abstract method.
The concrete class is a user file.
Exemplar appropriate for JET’s user region tags
JET’s user region tags preserve user code so long as it is entered in predefined document
regions. These regions are identified by unique-to-the-file begin and end patterns. This
approach can be used for any text file. Example 17-9 shows an exemplar bean with the
appropriate markup text highlighted in bold. The user calculation is between the marker text:
//begin getYearsOpen()
and
//end getYearsOpen()
Example 17-9 A derived property implementation with user region markers
package com.zyx.exemplar.beans.library;
/**
*
*/
public class UserRegionLibrary {
... other text removed for clarity
/**
* Return the library years open (derived)
* @return the years open
*/
public int getYearsOpen() {
//Place your custom code between the begin/end comments below
//begin getYearsOpen()
return java.util.Calendar.getInstance().get(java.util.Calendar.YEAR)
- getYearFounded();
//end getYearsOpen()
}
}
Exemplar appropriate for JMerge
WIth JMerge, a Java class can be marked up to indicate which class members are
user-owned and which class members are transformation-owned. This markup is via the
508
Strategic Reuse with Asset-Based Development
@generated Javadoc™ annotation. The transformation will overwrite any class member that
has an @generated tag. The transformation will not modify any member that does not have
the tag or where the tag has been modified. Example 17-10 shows an exemplar bean with
appropriate @generated markup. Note that the derived property getter getYearsOpen does
not have the @generated markup.
Example 17-10 A typical implementation compatible with the java:merge tag
package com.zyx.exemplar.beans.library;
/**
* @generated
*/
public class JMergeLibrary {
/**
* @generated
*/
private int yearFounded;
/**
* Package private constructor prevents instantiation except through factory
* @generated
*/
JMergeLibrary() {
}
/**
* Return the library year founded
* @return the year founded
* @generated
*/
public int getYearFounded() {
return yearFounded;
}
/**
* Set the library year founded
* @param yearFounded the new year founded
* @generated
*/
public void setYearFounded(int yearFounded) {
this.yearFounded = yearFounded;
}
/**
* Return the library years open (derived)
* @return the years open
*/
public int getYearsOpen() {
return java.util.Calendar.getInstance().get(java.util.Calendar.YEAR)
- getYearFounded();
}
}
Chapter 17. Produce: Model-to-text pattern implementations
509
Exemplar appropriate for a utility class
Example 17-11 shows the typical implementation of a utility class. The bean class (which will
be a non-modifiable file) delegates to this utility class for the derived property calculation. The
utility class is a user file. The bean class is not shown.
Example 17-11 A typical utility class implementation
package com.zyx.exemplar.beans.library.derived;
import com.zyx.exemplar.beans.library.UtilityLibrary;
/**
*
*/
public class UtilityLibraryUtil {
/**
* Utility method to calculate years open (derived)
* @param library the library
* @return the years open
*/
public static int getYearsOpen(UtilityLibrary library) {
return java.util.Calendar.getInstance().get(java.util.Calendar.YEAR)
- library.getYearFounded();
}
}
Exemplar appropriate for an abstract method implementation
Example 17-12 shows a typical implementation of an abstract method. The class
DerivedAbstractLibrary is a concrete class that extends an abstract bean implementation
(AbstractLibrary, which is a non-modifiable file) to calculate the derived property. The
concrete subclass is a user file. The abstract bean class and the modified factory class are
not shown.
Example 17-12 A typical abstract method implementation
package com.zyx.exemplar.beans.library.derived;
import com.zyx.exemplar.beans.library.AbstractLibrary;
/**
*
*/
public class DerivedAbstractLibrary extends AbstractLibrary {
/*
* (non-Javadoc)
*
* @see com.zyx.exemplar.beans.library.AbstractLibrary#getYearsOpen()
*/
public int getYearsOpen() {
return java.util.Calendar.getInstance().get(java.util.Calendar.YEAR)
- getYearFounded();
}
510
Strategic Reuse with Asset-Based Development
}
We will look at implementing each of these approaches in the following sections.
17.4.3 Reapply strategies: Implementation
This section discusses the implementation of each of the reapply strategies just identified:
Using JET user regions
Using JMerge for Java code
Generating a user-owned concrete class
Generating a user-owned utility class
Complete solutions for each reapply strategy are included in the additional materials
described in Appendix C, “Additional material” on page 725 inside the ABD-Part
4-Projects.zip file for the ch16transform.derived.zip file. The zip file contains the following
projects:
com.zyx.exemplar.beans
An updated exemplar project that includes implementations of examples of each of the
reapply strategies
com.zyx.patterns.beans.derived.userregion
The zyx beans pattern that uses JET user regions
com.zyx.patterns.beans.derived.jmerge
The zyx beans pattern that uses JMerge
com.zyx.patterns.beans.derived.utility
The zyx beans pattern that generates user-owned utility classes
com.zyx.patterns.beans.derived.subclass
The zyx beans pattern that generates user-owned concrete subclasses
com.zyx.patterns.tests
A project containing test inputs for each of the previous patterns
In this next section, we discuss the highlights of these implementations.
Common characteristics of all solutions
Each solution uses the identical input model structure to describe the derived properties.
They each define:
derivedProperty
A model element representing a derived property
name
An attribute of derivedProperty defining the name of the property
type
An attribute of derivedProperty defining the type of the property
mthdGetter
A derived attribute of derivedProperty that calculates the name of the
property getter method
Using JET user regions
Example shows the additional JET template code that is necessary to include derived
property getters inside the bean class. Example specifically shows the JET template code
creating a derived property getter method (highlighted in bold) with a user region to protect
the implementation.
Chapter 17. Produce: Model-to-text pattern implementations
511
Example 17-13 JET template code creating a derived property getter method
<c:iterate select="$bean/derivedProperty" var="dp">
/**
* Return the <c:get select="$beanPackage/@name" /> <c:get select="$dp/@name" />.
* @return the <c:get select="$dp/@name" />
*/
public <c:get select="$dp/@type" /> <c:get select="$dp/@mthdGetter" />() {
//Place your custom code between the begin/end comments below
<c:userRegion>//begin <c:get select="$dp/@mthdGetter" />()<c:initialCode>
// TODO Implement this method
throw new UnsupportedOperationException();
</c:initialCode>//end <c:get select="$dp/@mthdGetter" />()</c:userRegion>
}
</c:iterate>
The user region is defined by the JET tags <c:userRegion> and its child tag <c:initialCode>.
The tags use the text before <c:initialCode> and after </c:initialCode> as markers for the user
region. No two user regions in a file must have the same markers. The template ensures this
does not happen by including the getter method name in the markers.
The <c:initialCode> element contains the content to be written into the template output when
the user region is first created.
Each time that the <c:userRegion> tag executes, JET calculates the begin and end tags and
attempts to find them in the previous version of the file being written. If found, the existing
content is used instead of the content within the <c:initialCode> tag.
Tip: JET does a literal search for the begin and end markers. White space (blanks, tabs,
and new lines) as well as the case of letters (uppercase or lowercase) matter. A best
practice is to include as little white space as possible in the markers by placing the
<c:userRegion> and <c:initialCode> tags on the same line in the template. Similarly, the
closing </c:initialCode> and </c:userRegion> tags must be on a single line.
Note that JET user regions have the following disadvantages:
User text can only be added in predefined regions. For example, Java code entered in a
method body user region might require additional import statements elsewhere in the file.
The template must anticipate this situation, and the transformation user must understand
this constraint.
User regions that are no longer generated by the template will be removed from the
template output. Thus, there is a risk that user-entered code can be lost, which is
particularly likely in the case where a model element was renamed.
Using JMerge for Java code
Example 17-14 shows the modified bean template that protects user-entered code via a JETs
<java:merge> tag.
Example 17-14 The bean template modified to use JMerge to protect user code
<%-- Mark this template as requiring a merge with existing content --%>
<java:merge/>
package <c:get select="$beanPackage/@pkgBeans" />;
512
Strategic Reuse with Asset-Based Development
<%-- only generate list imports if list properties are defined --%>
<c:if test="$bean/listProperty">
import java.util.ArrayList;
import java.util.List;
</c:if>
/**
* Implement bean <c:get select="$bean/@name"/>
* @generated
*/
public class <c:get select="$bean/@clsBean" /> {
<%-- define fields for 'property' elements --%>
<c:iterate select="$bean/property" var="property">
/**
* @generated
*/
private <c:get select="$property/@type" /> <c:get select="$property/@varField" />;
</c:iterate>
<%-- define fields for 'listProperty' elements --%>
<c:iterate select="$bean/listProperty" var="listProperty">
/**
* @generated
*/
private final List <c:get select="$listProperty/@varField" /> = new ArrayList();
</c:iterate>
/**
* Package private constructor prevents instantiation except through factory
* @generated
*/
<c:get select="$bean/@clsBean" />() {
}
<%-- define getter and setter methods for 'property' elements --%>
<c:iterate select="$bean/property" var="property">
/**
* Return the <c:get select="$beanPackage/@name" /> <c:get select="$property/@name" />.
* @return the <c:get select="$property/@name" />
* @generated
*/
public <c:get select="$property/@type" /> <c:get select=