Sustainable IT Architecture

Pierre Bonnet is co-founder of Orchestra Networks Master Data Management software. He is a Consultant and Director of the SOA project. He is also co-founder of the Praxeme Institute for a public enterprise method, particularly applied to SOA.Jean-Michel Detavernier is Information Director of a mutual insurance company. He is responsible for It studies and Director of the company’s informatization project.Dominique Vauquier, modelization and methodology specialist, is the creator of the public method, Praxeme. He has participated in a large SOA project for an insurance company.Erik Steinholz is a Senior Integration Architect at Progress Software.Jérôme Boyer is a Senior Technical Director at ILOG.

• Acknowledgements xiiiForeword xvPreface xxiGuide for the Reader xxviiIntroduction to the SOA Project at SMABTP xxxiChapter 1. Initial Perspectives 11.1. 50 years of computing – an overview 11.2. What remains today? 5Part I. Why a Sustainable Information System? 7Chapter 2. Company-oriented Services 92.1. Consequences of the Internet revolution 92.2. What do the leading market players say? 122.3. What do the chief information officers think? 142.4. The issues faced at general management level 142.5. Levels of maturity 16Chapter 3. SOA Maturity Levels 213.1. Towards the creation of a more agile information system 213.2. Cosmetic SOA 233.3. Extended SOA 243.4. Overhaul SOA 263.5. The matrices of SOA maturity 283.5.1. The matrix showing the definitions of SOA 283.5.2. The matrix showing the quality criteria of SOA 293.5.3. The matrix showing the strengths and weaknesses of SOA 29Chapter 4. Economic and Social Aspects 314.1. Removal of obstacles that may slow down the progressive overhaul of an information system 324.2. The future of IT specialists 334.3. Off-shoring 334.4. The generation mix 344.5. The role of software infrastructure editors 35Part II. The Principles of SOA 37Chapter 5. The Properties of SOA 395.1. The definition of service for users 415.1.1. The user of the service 425.1.2. A business ambiguity 425.1.3. An example of a business service 435.2. The definition of service for IT specialists 445.2.1. The granularity of service 445.2.2. The separation of concerns 465.2.3. The service categories 475.2.4. Batch services 495.3. The properties of basic SOA 505.3.1. Loose coupling 505.3.2. Communication by messages 515.3.3. Design by contract 525.3.4. The limits of the basic properties 565.4. The properties of agility 565.4.1. The difference between the version and the variant of a service 585.4.2. Agility of the data 605.4.3. Agility of the rules 655.4.4. Agility of the processes 665.4.5. Agility of the human–computer interface 67Chapter 6. Orchestration (BPM and SOA) 696.1. Multiple requirements in orchestration 716.1.1. Orchestration and SOA maturity levels 716.1.2. Functional requirements 736.1.3. Technical requirements 756.1.4. Enterprise architecture requirements 776.2. The levels of orchestration 786.2.1. Orchestration at the process level 796.2.2. Orchestration at screen level 806.2.3. Orchestration at the micro-process level (use cases) 816.2.4. Orchestration at the business service level 826.2.5. Orchestration between domains through the use of ESB 836.2.6. The orchestration of batches 836.3. The techniques of orchestration 856.3.1. The BPM engine 856.3.2. The business rules engine 866.3.3. Specific programming 866.4. Towards the homogenization of orchestration 876.4.1. Unified modeling 876.4.2. Unified standard 896.5. The benefits of orchestration 916.5.1. Advantages 916.5.2. Disadvantages 91Part III. The Need for an Enterprise Method 93Chapter 7. The Discovery of Services (Reference Framework and Urbanization) 957.1. New needs for the information system 967.1.1. Expansiveness and progressiveness 977.1.2. Mobilizing the many different competences 987.2. Why are different methods seldom used within companies? 987.3. Reference frameworks 1017.3.1. Zachman’s framework 1017.3.2. TOGAF 1027.3.3. Peter Herzum’s framework 1037.3.4. Important information to be taken from the reference frameworks 1047.4. Essential tools 1057.4.1. UML (Unified Modeling Language) 1057.4.2. MDA (Model Driven Architecture) 1067.4.3. Urbanization of the information system 107Chapter 8. The Praxeme Enterprise Method 1118.1. Praxeme: the initiative behind a public method 1128.2. The Praxeme method 1128.2.1. Product 1138.2.2. Process 1138.2.3. Procedures 1148.2.4. Combining the three dimensions1148.3. Enterprise system topology according to the Praxeme method 1158.3.1. Upstream models 1158.3.2. Logical (SOA), technical and software architecture models 1178.3.3. Hardware and physical architecture models 1178.3.4. Enterprise system topology 1188.3.5. Pre-modeling 1198.4. What the Praxeme method means for SOA 1208.4.1. How can we find the correct services? 1208.4.2. The link between urbanization, the object-oriented approach and SOA 1218.5. Advantages of the Praxeme method 1248.5.1. A method that unites different approaches and integrates SOA 1248.5.2. Risks associated with the Praxeme method 126Chapter 9. Modeling with Praxeme 1299.1. The modeling of requirements 1309.2. Semantic modeling 1309.2.1. The basic principles 1309.2.2. How to obtain a semantic model 1339.2.3. How to validate a semantic model 1349.2.4. Semantic models and property rights – who owns a semantic model? 1349.2.5. The structure of a semantic model 1359.3. Pragmatic modeling 1379.3.1. The basic principles 1379.3.2. A new procedure for designing processes 1399.3.3. Usage view 1409.4. Pre-modeling 1429.5. Logical modeling 1439.5.1. SOA’s style of logical architecture 1439.5.2. Service-oriented architecture as logical architecture 1449.5.3. Types of logical components 1459.5.4. The strata of logical architecture 1519.5.5. Pivot language 1539.5.6. Service algorithm specification 1549.5.7. Specification of the services’ pre- and post-conditions 1549.5.8. Logical architecture of data 1569.5.9. Logical architecture of data repositories 1579.5.10. Logical architecture and user interface 1589.5.11. Designing a logic for tests 1599.5.12. Considering ERP 1609.5.13. Considering existent assets 1609.5.14. Federation of systems 1609.5.15. Roles of logical modeling 1619.6. Logical modeling of batch computing 1629.7. Technical modeling 1639.7.1. Required competences 1639.7.2. Technical/logical negotiation 1649.8. Software modeling 1669.8.1. General principles 1669.8.2. Towards the industrialization of programming 1699.9. Benefits of the methodology 1699.9.1. Opportunities 1699.9.2. Obstacles 171Part IV. Mastering Existing Techniques 173Chapter 10. Tools for Industrializing the Method 17510.1. Requirements in the industrialization of procedures 17610.2. Frameworks and design patterns 17810.2.1. From services framework to virtual machines 17910.2.2. Frameworks and human–machine interfaces 18210.2.3. Design patterns 18610.3. Tools for increased agility 18910.3.1. Rules engine 18910.3.2. Reference data management system 19610.4. Representation tools 20310.4.1. Modeling CASE tool 20310.4.2. Formal language (pseudo-language) 20710.4.3. MDA 20910.5. Tools for tests and management 21210.5.1. Non-regression tests 21210.5.2. Designing tests and test data 21310.5.3. Different levels of tests 21410.6. Tools for the management of different versions and the configuration of programs 21610.6.1. The level of versions and variants 21610.6.2. The level of delivery packages 21810.7. Benefits of using tools in the method 21910.7.1. Opportunities 21910.7.2. Risks 220Chapter 11. Systems Integration and Common Information Language 22311.1. New requirements in communication 22511.1.1. Increase of data flow 22511.1.2. Considering the business 22511.1.3. Take the bus! 22711.2. ESB’s functions 22711.2.1. Use perimeter 22711.2.2. ESB’s components 23011.3. Integrating ESB into SI 23511.3.1. Towards a common language 23511.4. ESB’s benefits 23911.4.1. Opportunities 23911.4.2. Limitations 240Chapter 12. SOA Platform 24312.1. Requirements for the global vision of technical architecture 24412.2. New technical components 24512.2.1. The transformation of data 24512.2.2. From a directory to a registry of services 24812.2.3. Security 25012.2.4. Traceability of services in production 25212.2.5. BAM and CEP 25412.2.6. Business Intelligence 25512.2.7. Editing 25712.3. Managing performance 25912.3.1. A new order of things? 25912.3.2. Best practice 26012.3.3. Testing performance 26112.4. Managing exploitation 26312.5. Managing maintenance 26912.6. Benefits of SOA platforms 26512.6.1. Opportunities 26512.6.2. Limitations 266Chapter 13. Rules Management at the Scale of the Whole Enterprise 267Jérôme BOYER, ILOG Software13.1. Overview 26713.2. Deep view 26813.3. When to use a rule engine 27113.4. Logical architecture view 27313.5. BRMS and SOA 283Chapter 14. Semantic Integration 287Erik STEINHOLTZ, Progress Software14.1. Enabling the adaptive enterprise 28814.2. Inhibitors for change 28914.3. Definition of semantic integration 29014.4. Parallel track information modeling 29114.5. Change inhibitors addressed with semantic integration 29414.6. Putting it to work 29514.6.1. Canonicalizing the BIM 29514.6.2. The quick win: a pilot project 29614.6.3. Using the CIM for integration 29614.6.4. Tools used 29714.6.5. Managing change and keeping the models alive 298Conclusion 299Weblinks 303Bibliography 305Special Technical Note 307Index 309