1 Integration and Extension Hohmann Chapter 8

2 Definitions Hohmann talks about customer’s ability to extend and integrate your software Integration Extension

3 Motivations for Integration/Extension Plan for change Customers want flexible solutions Large solutions consist of integrated subcomponents You want to increase switching cost You want to create a Product Ecosystem It’s easy money: your core probably already has an API

4 Layered Business Architectures Fig 8-1 Persistent Data Domain Model Services User Interface UI and UI Management (Actions, Buttons, input fields, etc.) Services (Make / cancel flights reservations etc.) Domain Objects (Flight, customer, etc.) Files/DB Object Translation

5 Spiking: Creating a Business Architecture UI Services Domain Database

6 Spiking: Creating a Business Architecture UI Services Domain Database

7 Spiking: Creating a Business Architecture UI Services Domain Database

8 Spiking: Creating a Business Architecture UI Services Domain Database

9 Spiking: Creating a Business Architecture UI Services Domain Database

10 Integration and Extension at the Business Logic Layers Case: Enterprise Software Important to know the locus of control –Caller is in control: your application most likely treated as service that creates and produces a result –System is in control: you’re almost always using a either a registration or callback model in which the caller registers some aspects of functionality to the system (plug-in, PN modul)

11 Integration through APIs (caller in control) Important items to consider when creating APIs –Should the API be platform dependent: e.g. COM/.NET interface, or C library –What is the market preference –What are your partners preference (product ecosystem) –Make your API easy to use (naming conventions etc.) –Expose only what customers need –Explain what you API can and cannot. Train customers in understanding you application –Possibly create several APIs (internal,externel)

12 Integration through APIs (caller in control) Managing APIs over multiple releases. –Give plenty warning. Rule of thumb: one release cycle –Provide one release overlap. Functionality not fully deprecated before after 2 releases –Provide “unsupported” backward compatibility layers as e.g. an optional module –Provide automated tools to translate code to new API

13 Extension through Registration (system in control) Think: PostNuke modules and Plug-ins It is key to define how these extension can be made 1.What language / file organization conventions exist 2.How are modules called (events) 3.How are resources shared with the system

14 Integration and Extension of Persistent Data Normally a no-go: if customers can change DB data there is a high risk of data corruption Workarounds –Views: only read access –User fields in DB: however, this often makes data suspect –Hook Tables System tableCustomer Hook table Events Create Delete etc.