![]() |
![]() |
User-to-Business Application Topology |
![]() |
![]() |
The following are typical user-to-business application topologies. Choose the topology which is the best fit to the customer solution you are working. Clicking on the image brings up the appropriate runtime pattern for you to continue. |
![]() |
|
![]() |
![]() |
![]() |
Topology 2 represents a client with a 3270/5250/ASCII emulator or Host on Demand accessing an existing application. The business driver for this is to provide wider and easy usage of existing centralized applications without having to rewrite/re-engineer these applications. A very simplistic enterprise-out scenario. |
![]() |
|
![]() |
![]() |
![]() |
.Topology 3 represents the target topology for most web-up thin client application server vendors. It aims to fix the scaleability problems of client/server and at the same time provide reuse of the business logic and data by all styles of web browser (and perhaps PC thin clients). It should be noted that where the business logic and data are held outside the glass house there will be a significant system management cost to manage this asset. The business driver for this is currently to extend the current web-enabled publishing capability with a web-enabled transaction capability. i.e. a classic web-up strategy |
![]() |
|
![]() |
![]() |
![]() |
Topology 4 represents an extension to the web-up strategy in topology 3. It allows for one or more point to point connections to back-end heritage applications or databases. One of the key issues to address is - where will the prime copy of the data be held - and thus where is the major system management investment. The business driver for this is to exploit existing transactions and data within a classic web-up design. |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
|
![]() |
||||||
Topology 5 represents a typical topology used to web-enable existing robust highly-scaleable transactions. The extra scaleability requirements generated by enabling thousands of web users are security, protocol conversion, session concentration and routing. The business driver for this design is fast, highly scaleable, highly available web-enablement of existing business transactions. i.e. a classic web server enterprise-out strategy. This design is also valuable in the case of company mergers and takeovers. |
||||||
![]() |
||||||
Topology 6 represents a step beyond topology 5 where the enterprise wants to make the third tier applications seamless by integrating the business logic at the intermediate tier. This design is increasingly valuable because it can support multiple styles of thin client with a common intermediate tier. The business driver is to provide customer-oriented support systems rather than product-oriented systems. |
||||||
![]() |
||||||
Topology 7 represents the next step beyond topology 6 where for example an insurance customer contacts an insurance company to check the status of an insurance claim. While answering his query the system can also retrieve any information about his family, house, car, birthdays etc. from the corporate data repositories. This data can be held as work-in-progress on the intermediate tier and used to prompt the insurance customer with cross-selling opportunities. The business driver for this design is customizing goods and services to a market of one (aka mass customization). . |
||||||
![]() |
![]() |
![]() |
Topology 8 represents a further step beyond topology 7. In the latter case the customer relationship (CRM) data and the line of business (LOB) data are both held on the third tier. In topology 8 the CRM data is held on the third tier which 'owns' the customer relationship, whilst the LOB data is accessed on the fourth tier from various third party suppliers. The business driver for this design is the need to support virtual enterprises, intermediaries or the equivalent of airline hubs on the web. . |
![]() |
|
[e-business Build & Run] [Build Solutions] [Resources] [References] [Feedback] |