Web Architecture considerations

1. Web Architecture considerations Tim Taylor August 2000

2. Agenda • Assumptions • Approach • dealing with uncertainty • service architecture • why use services? • Possible standards • “Straw Man” architecture • Issues • Next Steps

3. Major Assumptions • There will be 3 main areas to be supported by the web architecture • “Intranet” provision of information to employees / co-workers • Extranet bi directional exchange of information with External Service Provider’s (ESP’s) • E-business full integration with selected partners systems, including financial transactions, eg: e-procurement • Systems architecture requiring integration

4. Approach - dealing with uncertainty • The current lack of clear business direction leads to some fundamental requirements for any proposed architecture, ie: it must be • scalable, able to support growth in a controlled manner, without extensive reworking • flexible, able to support a variety of business models • adaptable, capable of including new functions without major rework • To achieve these objectives, an architecture based on Services is proposed • separating the elements of architecture and defining the communications required between them • To reduce the risk of costly errors, implementation should start small • prove the architecture • expand delivery on to a proven platform

5. Approach - service architecture “Can I change my dd payment amount?” Logon. A service is a component of the architecture which you ask a question of, and get a predictable response. They have always been present in systems. A service architecture just makes them explicit, and classifies them according to their function. System management and security. Receipt of incoming requests from clients. Dispatch of requests for external processes. “Sorry, Mr anon, but your current balance of £nn does not allow this” Output of formatted information for presentation on client (for browser services likely to be HTML). Dd payment must not be < curbal/12 Application of business rules to data, eg: MIS, Workflow. Management of interactions with back end data sources select dd payment & curbal where cust = anon

6. Approach - why use services? Traditional project specific architecture would implement most of these elements independently, many times. Changes to one component requires changes to others Application A Application B Client Mainframe Hardware is dedicated to end to end processing for systems Integration and communication between systems is often only achievable at the data level Server There may be some scope for reuse, eg: of databases, but this is often not maximised

7. Approach - why use services? Helps ensure that as many elements of the architecture as possible can be reused Changes to one component do not require changes to others Web server Hardware can be optimised for specific tasks for multiple applications Integration and communication between systems can be achieved where most appropriate Application Server App A App B Data Server Data can be reused by many applications If done properly, otherwise - CHAOS!

8. Possible standards - Communication services • Networking Services • Network Protocols – TCP/IP, IPX/SPX, NetBEUI • Routing Protocols – ARP, ASs, BGP-4, EIGRP, ICMP • Network Topology – Star, Bus, Ring • Addressing • Router Topology • Network Utilisation • Directory Services (LDAP, X500) • Databases • Partitioning • Replication • Caching • Access Control • Organisation and data relationships PRIORITY • User groups • Security requirements CONSIDERATIONS • Shared services • ESP / EDI standards

9. Possible standards - Presentation services • User Interface Design • Consistent User Interface • Human-Computer Interface Standards • Ease of Use • “Style guide” • not a major priority?

10. Possible standards - Business Logic services • Application Programming Interfaces (API) and Development Platform Services • Programming Languages – C/C++, Java • Development Tools & Strategies • Frameworks & Reusability • Threads • Inter-Process Communication • Internationalisation • GroupWare Services • E-mail Service • Fax Service • Web Servers • Transaction Services • Transaction Monitoring • Object Technology • Rollover and Rollback • Transactional Roles • ACID • Resource Manager • Transaction Manager PRIORITY • Toolsets • Languages • Hardware CONSIDERATIONS • Existing projects • Pilots • Skillsets

11. Possible standards - Data Management services • Database Services • Data Model • Database Engine • Database Model - Relational, Object-Oriented, etc • Connectivity Interfaces • Online Storage Devices and Services • FDDI • Hardware/Software RAID • Storage Area Networks • Offline Backup Storage Devices and Services • Tape Backup • Automated Scheduling Software • Integration with Legacy Systems • Mainframe/Mini Hardware` • Networking/Communication • Transaction Systems (CICS, VSAM, etc) • Database Systems • Legacy Applications • Emulation PRIORITY • Information Architecture CONSIDERATIONS • Current data architecture • Existing projects • Pilots • Skillsets

12. Possible standards - System services • Security Services • Manageability versus strength • Inside versus outside the firewall • Cryptography – Public Key Cryptography, Digital Certs • Communications – SSL • Authentication - Kerberos • Environment, Distributed Objects, Component Models • Concepts - Components, Objected Oriented • Object Middleware - COM/DCOM, CORBA, EJB • Operating Systems - Windows, UNIX, Linux, Solaris • Web Server • Performance - Local, Network, Load Balancing, Clustering • Robustness , Resilience, Scalability • Failover & Recovery, Disaster Recovery • Management and Maintenance Services • Remote Management Services, Fault Alerts • Self Healing Mechanisms • Asset Management, Configuration Management • Device Sharing Services and Integration • Integration with external devices PRIORITY • Security services • Firewall • Middleware • Basic systems management CONSIDERATIONS • Current systems • Existing projects • Shared services

13. Straw Man architecture - initial configuration Hardware Components • 1 x Web Server • 1 x app/db server • Cost: £5k - £10k Options • SUN • HP • IBM Software Components • development toolkit • Cost: £5k-10k Options • integrated, eg: Oracle Internet Application Server (IAS) • Components, eg: WebLogic, iPlanet Application Server, and WebSphere 3.5 Web Server Application & data Server Total Cost: approx £10k - £20k

14. Straw Man architecture - mid size Hardware Components • approx. £20k per processor required • 1 x Web Server (1) • 1 x app/db server (2) • Cost: £50k - £100k Options • SUN • HP • IBM Software Components • development toolkit • system management tools • middleware • Cost: £25k-50k Options • integrated, eg: Oracle Internet Application Server (IAS) • Components, eg: WebLogic, iPlanet Application Server, and WebSphere 3.5 Web Server Application & data Server Total Cost: approx £75k - £150k

15. Straw Man architecture - ‘full strength’ Hardware Components • approx. £20k per processor required • n x Web Server • n x app server • n x db server • Cost: £100k - £200k Options • SUN • HP • IBM Software Components • development toolkit • system management tools • middleware • Cost: £50k-100k Options • integrated, eg: Oracle Internet Application Server (IAS) • Components, eg: WebLogic, iPlanet Application Server, and WebSphere 3.5 Web Server Application Server Data Server Typical Cost: approx £150k - £300k

16. Example of a ‘full-strength’ architecture

17. Issues • Complexity of web architecture - if poorly implemented will make the current situation look like a picnic! • multiple components • complex interactions • process driven • open to outside scrutiny • Needs to be integrated with other architectures • information (what data is being used) • functional (which business functions are being transacted) • business (needs to be process driven) • Relationship with other initiatives and architecture • Hosting / ASP • Uncertain business model (plans, priorities etc) • Business ownership and buy in

18. Next Steps - framework 1LearningGaining understanding of the e-business marketplace 2PlanningDetermining your e-commerce strategy 3SystemEvaluating your current system software 4NetworkEvaluating your internal and external network infrastructure 5SecurityAdding security to your web site, intranet and extranet 6PaymentHow you will be paid, and how you will pay suppliers 7BuyingPurchasing from suppliers over the internet 8SupplierLinking into a centralised suppliers catalogue for purchasing 9LogisticsUsing the internet to manage stock levels and deliver goods 10SellingCreation of selling and affiliation tools for your web site 11CustomerCreating a community of customers through your web site 12PersonalisationCreating electronic relationships

19. What are we currently addressing? 1LearningGaining understanding of the e-business marketplace 2PlanningDetermining your e-commerce strategy 3SystemEvaluating your current system software 4NetworkEvaluating your internal and external network infrastructure 5SecurityAdding security to your web site, intranet and extranet 6PaymentHow you will be paid, and how you will pay suppliers 7BuyingPurchasing from suppliers over the internet 8SupplierLinking into a centralised suppliers catalogue for purchasing 9LogisticsUsing the internet to manage stock levels and deliver goods 10SellingCreation of selling and affiliation tools for your web site 11CustomerCreating a community of customers through your web site 12PersonalisationCreating electronic relationships 3System Evaluating your current system software 4Network Evaluating your internal and external network infrastructure 5Security Adding security to your web site, intranet and extranet

20. Next Steps • Connect with the business • what is the e-business strategy? • what current developments are happening in this area? • SELL, SELL, SELL • the e-business framework • why they need an architectural approach • Understand related standards and architecture • Tie in with metadata repository and other architecture work • provide focus for detailed investigation • include in plan • include in model