Rethinking Infrastructure Architecture: Service Oriented Infrastructure

1. Rethinking Infrastructure Architecture: Service Oriented Infrastructure Kevin Sangwell Infrastructure Architect Microsoft EMEA HQ

2. The Organic Infrastructure Each new application or part of infrastructure is introduced as a stovepipe.Each new application or part of infrastructure is introduced as a stovepipe.

3. The Organic Infrastructure Higher cost, more complexity Less secure (no end-to-end identity management) Compliance difficult/expensive to enforce cross-company CRM, ERP vendors are typically 3rd party. However these are now being forced to take an SOA perspective.Higher cost, more complexity Less secure (no end-to-end identity management) Compliance difficult/expensive to enforce cross-company CRM, ERP vendors are typically 3rd party. However these are now being forced to take an SOA perspective.

4. The Organic Infrastructure Poor user experience re-enforces the “IT as a necessary evil” mindset Lower productivity These all increase business risk Cost implications of diuplication Poor service experience for customers (inconsistencies)Poor user experience re-enforces the “IT as a necessary evil” mindset Lower productivity These all increase business risk Cost implications of diuplication Poor service experience for customers (inconsistencies)

5. Consolidation is the answer, right? Reduces number of stove pipes, but doesn’t solve them Next application/project adds another stovepipe I think of this as “backwards consolidation” Doesn’t change thinking The problem with consolidation from an SOI perspective is that it is viewed as a project. Once consolidation is complete, its finished. There is no change in approach for future projects, resulting in more stovepipes. SOI fundamentally changes the thinking from stovepipes and solutions to shared services which applications can consume. The definition of insanity if doing the same thing and expecting different results!The problem with consolidation from an SOI perspective is that it is viewed as a project. Once consolidation is complete, its finished. There is no change in approach for future projects, resulting in more stovepipes. SOI fundamentally changes the thinking from stovepipes and solutions to shared services which applications can consume. The definition of insanity if doing the same thing and expecting different results!

6. SOI: What it looks like

7. SOI: What it looks like

8. Getting There

9. Define & prioritise services according to ROI Put low hanging fruit at the top The difference between centralised and service-oriented is “shared service” ROI=Estimated cost savings (e.g. lower management overhead) and improved user experience vs technical complexity and scale of service ROI=Estimated cost savings (e.g. lower management overhead) and improved user experience vs technical complexity and scale of service

10. Good candidates Identity Management / Directory Web Hosting Database File store

11. If IT infrastructure is obvious to the business = poor perception of IT IT Infrastructure is not designed around users Seek to improve Enterprise user experience Unified view (network drive, published printers) Single sign-on Location independence/roaming User Subscriber experience User experience is one of the key things which, if done correctly, will make the business think of IT as a strategic asset. The moment IT becomes “exposed” to the business (e.g. having to manually map network drives, call helpdesk to add a new printer when roaming), it becomes an overhead: poor perception, and costs productivity At this phase, we’re looking at the enterprise user experience, not service user experience. Subscriber experience = graceful failure mode: when service dependency fails, give users a “service currently unavailable” page rather than application errorUser experience is one of the key things which, if done correctly, will make the business think of IT as a strategic asset. The moment IT becomes “exposed” to the business (e.g. having to manually map network drives, call helpdesk to add a new printer when roaming), it becomes an overhead: poor perception, and costs productivity At this phase, we’re looking at the enterprise user experience, not service user experience. Subscriber experience = graceful failure mode: when service dependency fails, give users a “service currently unavailable” page rather than application error

12. Forward consolidation for each service Attach to Projects Major pain/cost areas such as IDM

13. Forward consolidation The future is difficult to predict - what i/o, RAM, CPU will my future application need … so Abstract & Standardise Categorise subscribers as High, Medium or Low Capacity (storage & bandwidth) Load (concurrency / transactions) Performance (responsiveness / user expectations) Availability Implement Standard platform (hardware/software) for each of above When you’re defining services in the application architecture domain (SOA) you should be doing this already. Infrastructure Architects can help Solution Architects in this areaInfrastructure Architects can help Solution Architects in this area

14. Backward consolidation Low hanging fruit Challenges QOS: many services don’t support QOS

15. Assign Service Manager for each service Owns relationship with other services Subscribers Publisher Service Delivery Service Level Management Capacity Management Availability Management IT Continuity Management Financial Management Service Support Service Support Incident management Problem management Configuration management Change management Release management Service Support Incident management Problem management Configuration management Change management Release management

16. Blockers Technology Security Regulatory & compliance Aim to centralise these instead of service-orient them Technology: no QOS. Support of vendor (e.g. moving functionality out of stove pipe) Performance: moving functionality off hosts (e.g. MIIS and SQL)Technology: no QOS. Support of vendor (e.g. moving functionality out of stove pipe) Performance: moving functionality off hosts (e.g. MIIS and SQL)

17. SOI Enablers/facilitators Virtualisation is your friend, and your enemy But doesn’t solve all problems: remember virtual hosts still need managing & are lower performance Clustering Cost of resilience reduces with addition of services SAN Flexibility; capacity, replication, backup Evaluate on a case-by-case Slower than DAS Some applications don’t support SAN replication/backup Virtualisation: some QOS controls isolation (security/regulatory) Clustering: Offering better SLAs for minimal extra cost Lowering operational cost – maintenance easier to perform in service hours Virtualisation: some QOS controls isolation (security/regulatory) Clustering: Offering better SLAs for minimal extra cost Lowering operational cost – maintenance easier to perform in service hours

18. An Example: File & Print Easy for central sites: clusters Difficult for branch: Either centralise & cache or replicate data Migrate users to DFS for its location-awareness & server abstraction Fileserver Migration Toolkit does the legwork Don’t forget this is a service; apps can consume Benefits Reduces backup pain Easier to manage/apply policies/report on Easy to add resilience & DR support

19. Example: Identity Management Service Define Service: Single directory of users for authentication and access control User Experience Transparency (SSO, location independence, discoverability) Subscriber Experience (Capabilities) LDAP Directory (e.g. AD) Authentication (LDAP Bind, NTLM, Kerberos) Authorisation (Group membership) Auditing (directory access)

20. Example: Identity and Access Management Design Logical Service Capacity Performance Scalability Backup & DR Security Extensibility for subscribers Design Physical Service Server sizes Server locations Capacity: how much storage? How much network bandwidth Performance: user/subscriber load Scalability model: up, out, partition?Capacity: how much storage? How much network bandwidth Performance: user/subscriber load Scalability model: up, out, partition?

21. Extensibility Remember “blockers”? Technology (Schema) Regulatory (Forest) Security (Account Policies) Schema: use ADAM as application directory where you can extend the schema. Proxy calls into AD meaning you still take advantage of the directory “service”. Regulatory: split the users across forests (or maybe domains). Establish trusts if possible. Security: split the users across domainsSchema: use ADAM as application directory where you can extend the schema. Proxy calls into AD meaning you still take advantage of the directory “service”. Regulatory: split the users across forests (or maybe domains). Establish trusts if possible. Security: split the users across domains

22. Example: Identity and Access Management Service Evolution Move to Identity Management Service Provisioning/de-Provisioning triggered from HR database Federation User Self Service All subscribers benefit from these capabilities

23. Does SOI really have an ROI Gartner modelGartner model

24. Architecture Design Review 1 Day engagement Follow-up report Limited number

25. Question & Answer Panel