| Foreword |
|
xv | (2) |
| Preface |
|
xvii | (4) |
| Acknowledgments |
|
xxi | |
| Part I Context for Understanding Distributed Client/Server Systems |
|
1 | (34) |
|
1 Why Build Client/Server Systems? The Primary Design Goal for Information Systems Must be to Facilitate Change in Business Processes and the Applications which Enable Them |
|
|
3 | (15) |
|
1.1 Business Under Pressure to Change Shrinking Business Cycles are Forcing a Major Shift in I/S |
|
|
4 | (2) |
|
1.2 Legacy Systems Inhibit Change Legacy Code Inhibits Change Because it was Built for Processing Efficiency and not Reuse |
|
|
6 | (1) |
|
1.3 Adaptive Client/Server Systems Enable Change Process-Driven Architectures Enable Change |
|
|
7 | (1) |
|
1.4 The Evolution of Computing From Host-Centric to Network-Centric Systems |
|
|
8 | (2) |
|
1.5 What is New in Client/Server New Thinking for People, New Behavior for Systems |
|
|
10 | (3) |
|
1.6 What is Not New in Client/Server? Rigor and Discipline of a Formal Process of Working Together |
|
|
13 | (1) |
|
1.7 The Need for Design Successful Systems Don't Just Happen; They are Engineered |
|
|
14 | (1) |
|
1.8 The Need for Modeling Modeling Produces on Explicit Design Which Can Be Reviewed and Validated |
|
|
15 | (3) |
|
2 Models and Modeling Models Provide the Rigor and Discipline for Engineering Adaptive Systems |
|
|
18 | (7) |
|
2.1 Objectives of Modeling Models Help Prevent Defects by Making the Design Explicit |
|
|
19 | (1) |
|
2.2 What is a Model? A Model is an Accurate, Concise, and Unambiguous Description of a System |
|
|
20 | (1) |
|
2.3 The Modeling Process The Modeling Process Focuses on Distinct Subjects Individually, Then the Interaction Between the Different System Components |
|
|
21 | (1) |
|
2.4 The Structure of a Model Models Have a Hierarchal Structure to Show Interaction Among Components and to Enable Them to be Used for Project and Enterprise Level Efforts |
|
|
22 | (1) |
|
2.5 Benefits of Modeling An Ounce of Prevention is Worth a Pound of Cure |
|
|
23 | (2) |
|
3 The IllumiSys(TM) Design Method An Event- and Object-Based Method for Developing Distributed Client/Server Systems |
|
|
25 | (10) |
|
3.1 Objectives of the IllumiSys(TM) Design Method The Method Creates a Blueprint for Building Adaptive Systems |
|
|
27 | (1) |
|
3.2 Creating Business Components: The Essential Model The Design of Adaptive Systems Must be Business Driven |
|
|
28 | (2) |
|
3.3 Distributing Components Across the Distributed Technical Architecture: The Implementation Model The Primary Design Point for Client/Server Systems is Adaptability |
|
|
30 | (3) |
|
3.4 Organizational Enablers Creating an Organization to Enable Change |
|
|
33 | (1) |
|
3.5 Fleury Market Case Study An Example of the IllumiSys(TM) Design Method |
|
|
34 | (1) |
|
3.6 Benefits of the IllumiSys(TM) Design Method Building Enterprise-Wide Scalable Distributed Systems |
|
|
34 | (1) |
| Part II Business Components--The Essential Model |
|
35 | (80) |
|
4 Essential Model Overview The Design of Adaptive Systems Must be Business Driven |
|
|
34 | (16) |
|
4.1 Objectives of the Essential Model Requirements Modeling Ensures the System Accurately Models the Business Processes |
|
|
40 | (2) |
|
4.2 The Essential Model and Its Structure The Essential Model Provides Different Views of the Business |
|
|
42 | (1) |
|
4.3 Statement of Purpose The Statement of Purpose is the Contract with the Business |
|
|
43 | (1) |
|
4.4 Creating the Statement of Purpose The Statement of Purpose Defines the Business Reason for the Existence of the System |
|
|
43 | (2) |
|
4.5 Defining Metrics Tied to the Business Redefining how I/S Measures Success |
|
|
45 | (2) |
|
4.6 Creating the Essential Model An Iterative and Creative Process which is Managed Through Artifacts |
|
|
47 | (3) |
|
5 The Environmental Aspect Declaring the Scope of the System by Focusing on Business Events |
|
|
50 | (9) |
|
5.1 Objectives of the Environmental Aspect Providing a Clear Definition of the System's Scope |
|
|
51 | (2) |
|
5.2 The Context Diagram Viewing the System Boundary by Defining its Interaction with People, Business Units, Systems, Organizations, and Other Enterprises |
|
|
53 | (2) |
|
5.3 Specifying Business Events Defining the Real World Events which the System Must Respond To |
|
|
55 | (2) |
|
5.4 Consistency Rules Between Events and Context Diagram Verifying the Overall Scope of the System |
|
|
57 | (2) |
|
6 The Information Aspect Defining the Business Information and its Rules of Access |
|
|
59 | (10) |
|
6.1 Objectives of the Information Aspect Gaining Consensus on the Definitions and Business Rules of Shared Information |
|
|
60 | (1) |
|
6.2 The Entity Relationship Diagram Defining the Categories of Information and How they Relate |
|
|
61 | (2) |
|
6.3 Constructing the Entity Relationship Diagram Modeling Business Information and Rules so They can be Verified by Business Users |
|
|
63 | (2) |
|
6.4 Entity, Relationship, and Attribute Specifications Specifying the Meaning of the Business Terminology |
|
|
65 | (2) |
|
6.5 Attribution Assigning Information Elements to Entities, Associative Entities, and Relationships |
|
|
67 | (2) |
|
7 The Bridge Aspect Bringing Process and Information Together to Get a Complete and Consistent Picture of Requirements |
|
|
69 | (9) |
|
7.1 Objectives of Bridging Process, Data, and Time Different Aspects Must Ultimately Define One Cohesive System |
|
|
71 | (1) |
|
7.2 The Entity Event Table Understanding the Information Needed to Service Each Business Event |
|
|
72 | (2) |
|
7.3 The Entity State Transition Diagram Understanding How Business Events Change the State of an Entity |
|
|
74 | (2) |
|
7.4 Maintaining Consistency Between Entities, Events, and Context Diagrams Keeping the Models in Synch |
|
|
76 | (2) |
|
8 The Behavioral Aspect Decomposing the System into Detailed Component Responses to Business Events |
|
|
78 | (13) |
|
8.1 Objectives of Behavioral Modeling Detailing All Responses to Each and Every Event |
|
|
79 | (2) |
|
8.2 Event Response Table Defining Responses for Each Event |
|
|
81 | (1) |
|
8.3 Data Flow Diagrams Data Flow Diagrams Provide Another View of System Responses to Events |
|
|
81 | (3) |
|
8.4 Constructing Event Response Data Flow Diagrams Detailing System Responses Through a Synthesis of the Essential Model |
|
|
84 | (2) |
|
8.5 Entity Response Table Defining the Information Required for Each Response |
|
|
86 | (1) |
|
8.6 Consistency Checks With the Environmental Bridge Aspects System Responses must be Completely Consistent with the Responses Implied by the Context Diagram and the Entity Event Table |
|
|
86 | (1) |
|
8.7 Consistency Checks with the Information Aspect The Internal Operations of System Responses Must be Completely Consistent with the Business Rules |
|
|
87 | (2) |
|
8.8 Developing Minispecs Creating Detailed Specifications for Granular Components |
|
|
89 | (2) |
|
9 The Event Distribution Aspect Moving from a Centralized View of the System to a Distributed View of the System |
|
|
91 | (11) |
|
9.1 Objectives of the Event Distribution Aspect Understanding Where Business Events Occur |
|
|
92 | (1) |
|
9.2 Event Distribution by Logical Location Assigning Business Events to Logical Locations |
|
|
93 | (2) |
|
9.3 Logical Location/Response Distribution Table Further Detailing the Logical Boundaries |
|
|
95 | (2) |
|
9.4 Logical Location Distribution by Geography Defining How the Business Operates Across Geographic Boundaries |
|
|
97 | (1) |
|
9.5 Geographic Distribution Table Depicting the Geographic Distribution of Logical Locations |
|
|
97 | (2) |
|
9.6 Logical Location Diagram Defining How Logical Locations Operate Within and Across Geographic Locations |
|
|
99 | (3) |
|
10 The Component Measurement Aspect Understanding How the Natural Cycles of the Business Constrain Design Decisions |
|
|
102 | (13) |
|
10.1 Objectives of Measurement The Measurment Aspect Helps Define Design Constraints |
|
|
104 | (1) |
|
10.2 Determining What to Measure Measuring the Key Business Components of the Essential Model |
|
|
105 | (1) |
|
10.3 How to Design Measurements Defining Clear and Consistent Metrics |
|
|
106 | (1) |
|
10.4 The Terminator Measurement Table Measuring Each Terminator on the Context Diagram |
|
|
107 | (1) |
|
10.5 The Event Response Measurement Table Measuring Business Events to Determine Processing Requirements |
|
|
108 | (4) |
|
10.6 The Entity Relationship Measurement Table Measuring the Information Aspect to Determine Storage Requirements |
|
|
112 | (1) |
|
10.7 Using the Component Measurement Aspect to Size Systems Creating the Necessary Information to Take Advantage of Scalable Technology |
|
|
113 | (2) |
| Part III Software Components--The Implementation Model |
|
115 | (116) |
|
11 Implementation Model Overview Implementing the Essential Model With "Real World" Constraints |
|
|
119 | (4) |
|
11.1 Objectives of Modeling Software Components Modeling the Implementation Before It is Built Reduces Risk |
|
|
119 | (1) |
|
11.2 The Implementation Model and Its Structure The Implementation Model Provides a Roadmap for Distributing Business Events and Responses Across the Distributed Architecture |
|
|
120 | (2) |
|
11.3 Creating the Implementation Model An Iterative and Creative Process which is Managed Through Artifacts |
|
|
122 | (1) |
|
12 Design Metrics Design Metrics Guide Design Trade-offs |
|
|
123 | (8) |
|
12.1 Objectives of Design Metrics Using Metrics to Build Software Components |
|
|
125 | (1) |
|
12.2 Creating Design Metrics Design Metrics Must be Aligned with Business Goals |
|
|
125 | (2) |
|
12.3 Defining Design Goals A Set of Design Principles to Guide All Design Decisions |
|
|
127 | (1) |
|
12.4 Defining Constraints Existing Factors will Impact Design Decisions |
|
|
128 | (1) |
|
12.5 Defining Standards Technical Standards Impact Design Decisions |
|
|
128 | (1) |
|
12.6 Defining Performance The Performance of the System Equals the Performance of the Slowest Component |
|
|
129 | (1) |
|
12.7 Conflicting Design Goals Optimize at the Enterprise Level |
|
|
129 | (2) |
|
13 Multi-Tier Partitioning Aspect Partitioning Business Components Across Clients, Servers, and Mainframes |
|
|
131 | (12) |
|
13.1 Objectives of Multi-Tier Partitioning Multi-Tier Partitioning Creates Adaptive Systems |
|
|
133 | (1) |
|
13.2 What is Multi-Tier Partitioning? Partitioning Events and Responses into Presentation, Business Rules, Data Access, and Data |
|
|
134 | (4) |
|
13.3 The Essential Model and Multi-Tier Partitioning The Essential Model Maps Easily to Multi-Tier Architectures |
|
|
138 | (1) |
|
13.4 Presentation The Presentation Tier Manages Events |
|
|
139 | (1) |
|
13.5 Business Rules Business Rules Define Responses to Events |
|
|
139 | (1) |
|
13.6 Data Access Rules Data Access Rules Define How Responses Use Data |
|
|
140 | (1) |
|
13.7 Data Data is a Persistent Artifact of Process |
|
|
140 | (1) |
|
13.8 Defining the Application Architecture Choosing Between Two-Tier and Multi-Tier Architectures |
|
|
141 | (2) |
|
14 Technical Architecture Design Selecting the Technology to Implement the System; Including Processors, Communications, Tools, and Components |
|
|
143 | (40) |
|
14.1 Business Drivers Adaptive Systems Require Process-Driven Architectures |
|
|
145 | (3) |
|
14.2 Comprehensive Inventory Before You Move Forward, First Understand Where You Are |
|
|
148 | (4) |
|
14.3 Technology Requirements Components of the Technical Architecture are Chosen to Meet Changing Business Requirements |
|
|
152 | (20) |
|
14.4 Technical Specifications Technical Specifications Unambiguously Define and Depict the Technical Infrastructure Supporting Each and Every Software Component |
|
|
172 | (7) |
|
14.5 Gap Analysis Gap Analysis Defines the Difference Between "What Is" and "What Will Be" |
|
|
179 | (1) |
|
14.6 Migration Planning Migration Planning Provides a Roadmap for Getting From "What Is" to Where the Organization Wants to Be |
|
|
180 | (2) |
|
14.7 Defining Support The Feasibility of the Technical Infrastructure Lies in Long-Term Support and Maintenance |
|
|
182 | (1) |
|
15 Processor Distribution Aspect Distributing the Multi-Tier Design to Physical Processors |
|
|
183 | (28) |
|
15.1 Objectives of Processor Distribution Designing Reuseable, Adaptable Software Components |
|
|
185 | (1) |
|
15.2 The Processor Model Creating the Processor Model from the Technical Architecture Model |
|
|
185 | (2) |
|
15.3 The Processor Distribution Table Distributing Event Management and Responses to Processors |
|
|
187 | (3) |
|
15.4 The Processor Data Flow Diagram Highlighting Interaction between Processors to Define System Events |
|
|
190 | (1) |
|
15.5 Detailing Processes on Each Processor Creating DFDs and Minispecs for Each Processor |
|
|
191 | (3) |
|
15.6 Modeling the Presentation Tier Designing how the User Interfaces with the System to Process Business Events and how the System Responds to Those Events |
|
|
194 | (2) |
|
15.7 Synchronous vs. Asynchronous Design Designing for Adaptability and Scalability |
|
|
196 | (3) |
|
15.8 Guidelines for Process Distribution Applying Principles of Adaptive Designs to Software Blueprints |
|
|
199 | (1) |
|
15.9 Data Distribution Creating a Distributed Data Architecture That can be Managed |
|
|
200 | (1) |
|
15.10 The Data Warehouse The Data Warehouse Plays a Central Role in the Enterprise Data Architecture |
|
|
201 | (4) |
|
15.11 Entity-Processor Table Defining Data Requirements for Each Processor |
|
|
205 | (1) |
|
15.12 Data Distribution Table Defining Authoritative Data Sources and Replication Targets |
|
|
206 | (1) |
|
15.13 Guidelines for Data Distribution Guidelines for Designing Optimal Data Distribution Strategies |
|
|
207 | (3) |
|
15.14 Message Specification Table Specifying Messages Between Processors |
|
|
210 | (1) |
|
16 Geographic Distribution Aspect Distributing the Processors Across Geographic Locations |
|
|
211 | (11) |
|
16.1 Objectives of the Geographic Distribution Aspect Site-By-Site Planning for Distributed Operations |
|
|
212 | (2) |
|
16.2 Processor Distribution Tables Distributing Events to Processors at Each Location |
|
|
214 | (1) |
|
16.3 Processor Data Flow Diagrams Defining Communication Between Processors at Each Location and Across Locations |
|
|
215 | (2) |
|
16.4 Data Distribution Table Defining Authoritative Data Sources and Replication Targets |
|
|
217 | (2) |
|
16.5 Guidelines for Geographical Process Distribution Systems Management and Performance Are Key |
|
|
219 | (1) |
|
16.6 Guidelines for Geographic Data Distribution Balancing Distributed Data Requirements with Data Integrity and Manageability as well as Network Traffic |
|
|
220 | (2) |
|
17 Traffic Analysis Traffic Analysis Measures the Impact of the Design on the Network |
|
|
222 | (9) |
|
17.1 Process for Performing Traffic Analysis Designing for the Network |
|
|
223 | (1) |
|
17.2 Traffic Analysis Table Estimating Message Traffic |
|
|
224 | (1) |
|
17.3 Traffic Flow Diagram Depicting the Estimated Network Traffic |
|
|
225 | (1) |
|
17.4 Frequency Distribution Graph Determining Event Frequency Over Specific Intervals of Time |
|
|
226 | (1) |
|
17.5 Load Balancing Analyzing the Design for Processing Overloads |
|
|
227 | (1) |
|
17.6 Evaluating Design Alternatives Choosing on Adaptable, Implementable, and Supportable Design |
|
|
228 | (1) |
|
17.7 Guidelines for Evaluating Designs Guidelines Based on Best Practices |
|
|
229 | (2) |
| Part IV Organizational Enablers |
|
231 | (38) |
|
18 Organization Architecture In Order to Respond to Change, the Organization Must be Organized to Enable Change |
|
|
233 | (15) |
|
18.1 Objectives of Organizational Structure The Organizational Structure Must Enable Alignment Between Business and I/S and Cross-Functional Teaming |
|
|
234 | (1) |
|
18.2 Leadership Structure The Leadership Structure Must Ensure Alignment Between the Business and I/S |
|
|
234 | (1) |
|
18.3 Organizational Structure The Team Structure Must Cause Alignment with the Enterprise and Enable Maximum Utilization of Expertise |
|
|
235 | (2) |
|
18.4 Business Roles Active Business Involvement is Crucial to Success |
|
|
237 | (1) |
|
18.5 Enterprise Architecture Group A Structure for Providing Enterprise Integration |
|
|
238 | (3) |
|
18.6 Application Development Roles Development of Multi-Tier Systems Requires Many Different Skills |
|
|
241 | (1) |
|
18.7 Cross-Functional Teams The Purpose of Creating Cross-Functional Teams is to Provide Seamless Service to the Customer |
|
|
242 | (1) |
|
18.8 Operations and Support Minimizing Operational Costs, Maximizing Efficiency, and Making Client/Server as Robust as the Mainframe |
|
|
243 | (3) |
|
18.9 Metrics for Critical Support Areas Metrics Keep the Organization on Track |
|
|
246 | (1) |
|
18.10 Building the Organizational Architecture Which Comes First, Infrastructure or Return on Investment? |
|
|
247 | (1) |
|
19 Process Management Successful System Design Efforts Require a Formal Well-Managed Approach |
|
|
248 | (12) |
|
19.1 Objectives of Process Management Prevent Defects, Produce Anticipated Results, and Maximize Reuse at Every Level |
|
|
249 | (1) |
|
19.2 Avoiding Analysis Paralysis in Modeling Defining the Scope and Sufficiency of the Modeling Effort |
|
|
250 | (1) |
|
19.3 Roles and Responsibilities for the Modeling Process Team Members may be Authors, Experts, Readers, or Approvers |
|
|
250 | (2) |
|
19.4 Managing the Modeling Process Managing through Tasks, JAD Sessions, and Metrics |
|
|
252 | (1) |
|
19.5 The Benefits of Review Cycles Review Cycles Prevent Defects and Contribute to the Expansion of Organizational Knowledge |
|
|
253 | (1) |
|
19.6 Types of Reviews Different Types of Reviews Serve Different Purposes |
|
|
253 | (2) |
|
19.7 Managing the Review Process Optimizing Review Cycles to Streamline the Process |
|
|
255 | (2) |
|
19.8 Essential and Implementation Model Activities and Artifacts Tasks and Deliverables for Each Aspect |
|
|
257 | (3) |
|
20 Organizational Transformation Organizational Transformation is Required to Enable Business Change |
|
|
260 | (9) |
|
20.1 Promoting the Vision The "Vision" Provides the Conceptual Framework to Guide All Other Decisions |
|
|
261 | (1) |
|
20.2 Education and Training Building the Necessary Skillsets Within the Organization |
|
|
262 | (3) |
|
20.3 Designing a Training Curriculum Effective Migration of Mainframe Programming Skills Requires An Understanding of the Paradigm Shift |
|
|
265 | (1) |
|
20.4 Motivation and Reward Organizational Transformation Requires a Change in the Way I/S Personnel are Measured |
|
|
266 | (3) |
| Part V Case Study |
|
269 | (74) |
|
21 The Fleury Market Case Study An Example of a Distributed Systems Design Project |
|
|
271 | (13) |
|
21.1 Background on Fleury Market The Purpose and Major Components of Fleury Market |
|
|
271 | (3) |
|
21.2 A Typical Day at the Market Understanding How the Market Operates |
|
|
274 | (1) |
|
21.3 Background for the Essential Model Creating Automated Systems for Fleury Market |
|
|
275 | (1) |
|
21.4 Gathering Requirement Details for the Essential Model Interviews with Market Personnel |
|
|
276 | (4) |
|
21.5 Background for the Implementation Model Designing the Distributed System |
|
|
280 | (4) |
|
22 The Fleury Market Essential Model A Model of Business Requirements |
|
|
284 | (28) |
|
22.1 Statement of Purpose Negotiating Scope to Rapidly Deliver Business Solutions |
|
|
284 | (2) |
|
22.2 The Environmental Aspect Defining the System Scope within the Context of the Overall Environment |
|
|
286 | (3) |
|
22.3 The Information Aspect Modeling the Information, Relationships, and Business Rules Concerning Data |
|
|
289 | (3) |
|
22.4 The Bridge Aspect Bringing Together Business Events, Data, and Time |
|
|
292 | (2) |
|
22.5 The Behavioral Aspect Defining Granular Responses to Business Events |
|
|
294 | (6) |
|
22.6 The Event Distribution Aspect Understanding Where Events Occur |
|
|
300 | (6) |
|
22.7 Component Measurement Aspect Measuring the Business Components to Inform and Guide Design and Implementation Decisions |
|
|
306 | (6) |
|
23 The Fleury Market Implementation Model Partitioning the Essential Model Across the Distributed Technical Architecture |
|
|
312 | (31) |
|
23.1 Design Metrics Establishing Criteria for Evaluating the Design for Business Optimization |
|
|
312 | (2) |
|
23.2 Multi-Tier Partitioning Aspect The Essential Model Maps Easily to a Multi-Tier Architecture |
|
|
314 | (1) |
|
23.3 Technical Architecture Design Defining All Technical Components of the System |
|
|
315 | (4) |
|
23.4 Processor Distribution Aspect Distributing Business Process, Rules, and Information to Physical Processors |
|
|
319 | (10) |
|
23.5 Geographic Distribution Aspect Creating Design Specifications for Each Location |
|
|
329 | (8) |
|
23.6 Traffic Analysis Determining Feasibility and Optimizing the Design for the Network |
|
|
337 | (6) |
| Appendices |
|
343 | (8) |
| A Data Flow Diagram Language |
|
343 | (1) |
| B Entity Relationship Diagram Language |
|
344 | (1) |
| C State Transition Diagram Language |
|
345 | (1) |
| D Processor Diagram Language |
|
346 | (1) |
| E Structure Chart Language |
|
347 | (1) |
| F Model Artifacts |
|
348 | (2) |
| G Issue List |
|
350 | (1) |
| Bibliography |
|
351 | (2) |
| Index |
|
353 | (6) |
| About the Authors |
|
359 | |
