1. 2005 Microsoft PAKISTAN DEVELOPER CONFERENCE June 13-15, 2005

2. 2 Arvindra Sehmi Head of Enterprise & Architecture Developer & Platform Group Microsoft EMEA HQ asehmi@microsoft.com www.thearchitectexchange.com/asehmi MOTION Helping Business Customers Understand the value of Service Orientation

3. EMEA 3 Agenda  Exploring SO Thinking and SOA  Conceptualizing the Business – Motion Methodology  Future Tooling Concepts  Some Thoughts on Implementation  Conclusions

4. EMEA 4 Exploring Service Oriented Thinking and SOA

5. EMEA 5 ITBusiness Business Practice Business Functions Applications Infrastructure judgment insight tradeoffs change oversight strategy Reconciling IT and Business

6. EMEA 6 Inward Technology Driven View Silos Focus on Document Exchange Components Requirements Drive Solution BUSINESS TECHNOLOGY Hard Boundaries (organizations & systems) Service Oriented Thinking – The “Old” Perspective  Internal focus  Conventional view of development-led process – primarily focused on containment of complexity; separation, componentization, parallel development  IT and business are aligned; ergo requirement “should” drive the solution  Focus on boundaries – organizational and system  Formal definition of document exchange  Components  Cost containment, reuse, adaptability Source of text: Modeling for SOA, CBDI Journal, Feb 2003

7. EMEA 7 Modelling Connected Systems The “Old” Way System Model (Classic) Business Model Technical Model

8. EMEA 8 Today

9. 9 If You Invest …Then Tomorrow

10. EMEA 10 10 Years Later What Actually Happened

11. EMEA 11 Business Applications Business Practice Infrastructure Business Functions Applications Infrastructure Collaborate DecideActInsight Oversight The Agile Business

12. EMEA 12 Soft Boundaries (process & services) Outward Business Driven View Processes Focus on Contract Services BUSINESS TECHNOLOGY Requirements and Solution Tightly Interdependent Service Oriented Thinking – The “New” Perspective  External focus  Externalized view encourages more radical view of process design; supports reengineering of business processes which becomes possible when there is the possibility of automating what have previously been seen as discrete processes, with different ownerships  IT and business are synonymous; requirements and solution are tightly interdependent  Focus on cross-organizational processes and services  Formal definition of contracts  Services  Common or shared functionality. Information services as integral part of business product. Elimination of data duplication, access to current data sources, etc. Source of text: Modeling for SOA, CBDI Journal, Feb 2003

13. EMEA 13 Modelling Connected Systems The “New” Way Business Model Service Oriented Architecture Model Technical Model System Model (Service Based) Lots of debate about what to call this!

14. EMEA 14 For many, SOA matters but we are hearing “There are big challenges in moving to SOA…”  From a technical perspective  we think we understand what SOA is from a technical perspective  we talk a lot about it amongst ourselves and with suppliers  we have started to imagine what it could mean to the business - but we have no methods, techniques or tools to engage the business in a structured dialog about it  From a business perspective  we are hearing a lot about it but are not sure what it means at a business level  we cannot fund the transition to SOA as a technical project – it is too big, we need to have real business impact and value every step of the way  early projects should both prove the benefits of the new architecture (technical and business) and deliver business results  we have no methods, techniques or tools to engage with the technical organization in a structured dialog about it

15. EMEA 15 Modelling Connected Systems Business Model What  Capabilities How  Business Processes Technology Model Service Interface Orchestration Engine Service Implementation Service Host SOA Model Service Contract OrchestrationService Management SLA

16. EMEA 16 Modelling Connected Systems Business Model What  Capabilities How  Business Processes Technology Model Service Interface Orchestration Engine Service Implementation Service Host SOA Model Service Contract OrchestrationService Management SLA

17. EMEA 17 Conceptualizing the Business

18. EMEA 18 No Company Is An Island Customers Suppliers Employees Partners Suppliers Suppliers Employees Customers PartnersPartners It Is Business Capabilities and People That Knit The Business and Customers Together

19. EMEA 19 This is One Way to Conceptualize The Business, but… C.F. Module Maps

20. EMEA 20 Conceptualizing the Business Motion Methodology

21. EMEA 21 A Better Way to Conceptualize The Business  Think about your customer’s “enterprise” and its capabilities  Create “views” that reflect how its business partners think about each other  Create a “capabilities view” to publish outside organization boundaries

22. EMEA 22 What Drives Your Business Success? Maturity vs. Interconnectedness

23. EMEA 23 What Makes You Different? Organizational Goals and Priorities QualitySpeedConvenienceFashionSelectionAmbiancePrice Location Service Expertise High Medium Low Emphasis StarbucksIndustry

24. EMEA 24 Main Issues Facing the Business  Examples of concrete issues businesses face today  How can we define a strategy to organically grow revenue  I need to drive a better customer experience  How do we decide which capabilities should I outsource this function?  I am Planning for a merger of companies or business units  We have multiple “Business Capabilities” how do we chose which is best  I am an IT executive and I need requirements from the business  Defining “Business”  Not just the four walls of a legal entity  All of the companies that make a complete business  Enterprise is something else  Business units can be defined by capabilities

25. EMEA 25 Disaggregation of the value chain The Capabilities Of A Credit Granting Process… Corporate Credit Building Credit Consumer Credit Payment Payment Entry in Land Register Entry in Land Register Payment Payment Collaterals Registration Collaterals Registration Check Contract Get Signature Get Signature Final Vote & Decision Final Vote & Decision Collaterals Evaluation Collaterals Evaluation Product Config- uration Product Config- uration First Vote First VoteRating Data Data Entry Entry Collaterals Acquisition Collaterals Acquisition Product Selection Product Selection Check Contract Get Signature Get Signature Final Vote & Decision Final Vote & Decision Collaterals Evaluation Collaterals Evaluation Product Config- uration First Vote First VoteScoring Data Data Entry Entry Collaterals Acquisition Collaterals Acquisition Product Selection Payment Payment Check Contract Get Signature Get SignatureDecision Vote VoteScoring Product Selection Product Selection Data Data Entry Entry Product Configuration Product Selection Collaterals Registration Collaterals Evaluation Scoring Rating Product Configuration Product Selection Entry in Land Register Collaterals Evaluation Scoring Collaterals Acquisition Get Signature Vote Payment Data Entry CheckContractDecision

26. EMEA 26 Capability Model Overview  A Business Capability Model is a nested hierarchy of Business Capabilities  Business Capabilities exist in both the internal operations of a business as well as in an ecosystem or business environment  Operations Capabilities  Environment Capabilities

27. EMEA 27 Level 1 Represents Core Capabilities  Level 1 consists of the highest level of Capabilities, Core Capabilities  It is at this level that businesses decide what to produce, how to generate demand for the product, how to produce it, how to communicate within the organization and with others in the value chain and how continually manage the business Core Capabilities Operations Environment Business Capabilities Can be decomposed Capability Attributes Capability Groups Service Level Expectations Impediment/Constraint Ownership/Accountability Level 1 Core Capabilities Level 1 Core Capabilities Level 2 Capability Groups Level 2 Capability Groups Level 3…n Business Capabilities Level 3…n Business Capabilities

28. EMEA 28 Bank Example Module Map Business Partners 1. Develop Product / Service 2. Generate Demand 5. Collaboration 3. Fulfill Demand 4. Plan & Manage Enterprise Business Partners Service Providers Regulatory Institutions Customer Facing Channel Partners Banking Business Within the traditional bank, operations are captured in 5 areas  Develop Product / Service  Generate Demand  Fulfill Demand  Plan & Manage the Enterprise  Collaboration Outside of the bank, external entities are shown  Customers and Suppliers/Partners  Service Providers  Channel Partners  Regulatory Institutions Customers

29. EMEA 29 Level 2 Consists of Capability Groups  Level 1 Capabilities are composed of Capability Groups, for example, the Core Capability of “Develop Products/Services” often contains a group of Capabilities known as “Product Engineering”  Level 2 is where initial analysis begins because it is the level that introduces:  Service level expectations  Impediments and constraints  Organizational ownership and accountability Core Capabilities Operations Environment Business Capabilities Can be decomposed Capability Attributes Capability Groups Service Level Expectations Impediment/Constraint Ownership/Accountability Level 1 Core Capabilities Level 1 Core Capabilities Level 2 Capability Groups Level 2 Capability Groups Level 3…n Business Capabilities Level 3…n Business Capabilities

30. EMEA 30 Bank Example Module Map: Decomposition 1. Develop Product / Service 2. Generate Demand 5. Collaboration 3. Fulfill Demand4. Plan & Manage Enterprise Customers Suppliers Logistics ProvidersFinancial Service Providers Customer Facing Channel Partners Enterprise 1.1. Develop Product / Service 2.1. Partner Relationship Mgmt.2.2. Marketing 2.3. Sales 5.1. Strategic Collaboration5.2. Planning Collaboration5.3. Operational Collaboration 4.1. Financial Management 4.2. Project Management 4.3. Human Resources 4.4. Property and Advisory 3.1. Provide Service 3.2. Advanced Planning3.3. Procurement 3.4. Produce Product 3.5. Logistics Level 2 3. Fulfill Demand 3.3 Procurement

31. EMEA 31 Level 3 Represents Business Capabilities  Capabilities that reside at Level 3 and below are the building blocks of the model  Decompose these Capabilities when more detailed attributes need to be defined  Capabilities are always labeled within their appropriate parent grouping: Core Capabilities Operations Environment Business Capabilities Can be decomposed Capability Attributes Capability Groups Service Level Expectations Impediment/Constraint Ownership/Accountability Level 1 Core Capabilities Level 1 Core Capabilities Level 2 Capability Groups Level 2 Capability Groups Level 3…n Business Capabilities Level 3…n Business Capabilities

32. EMEA 32 Bank Example Module Map: Decomposition 1. Develop Product / Service 2. Generate Demand 5. Collaboration 3. Fulfill Demand 4. Plan & Manage Enterprise Customers Suppliers Logistics ProvidersFinancial Service Providers Customer Facing Channel Partners Enterprise 3.1. Provide Service 3.2. Advanced Planning 3.3. Procurement 3.4. Produce Product 3.5. Logistics 3.3.1 Sourcing and Supplier Contract Management 3.3.3 Receiving of Indirect / Capital Goods and Services 3.3.2 Purchasing Level 3 3. Fulfill Demand 3.3 Procurement 3.3.2 Purchasing

33. EMEA 33 Bank Example Module Map: Decomposition 1. Develop Product / Service 2. Generate Demand 5. Collaboration 3. Fulfill Demand 4. Plan & Manage Enterprise Customers Suppliers Logistics ProvidersFinancial Service Providers Customer Facing Channel Partners Enterprise 3.1. Provide Service 3.2. Advanced Planning 3.3. Procurement 3.4. Produce Product 3.5. Logistics 3.3.1 Sourcing and Supplier Contract Management 3.3.3 Receiving of Indirect / Capital Goods and Services 3.3.2 Purchasing Level 4 3. Fulfill Demand 3.3 Procurement 3.3.2 Purchasing - Request Resources - Create - Create Purchase Purchase Requisitions Requisitions Create Purchase Requisitions Request Resources

34. EMEA 34 Process Area: 3.3.1. Sourcing And Supplier Contract Management  Purpose: To identify, select, and contract with the best suppliers based on characteristics such as quality, capability, pricing, and service  Description: Sourcing begins with an analysis of the products/services being purchased; Purchasing professionals known as buyers, research how much internal demand there is for a given product as well as the overall demand for the product/service within the marketplace; Buyers typically look at historical purchasing volumes, pricing data, as well as conduct initial research to identify suppliers that provide the product/service of interest; This information is used to identify a list of potential suppliers from which the organization might purchase goods or services; Once the potential suppliers have been identified, they are screened more carefully using RFIs, RFQs, & RFPs (Request for Information, Quotations, or Proposals) to narrow the list; These requests for information provide the buyer with more detailed information regarding product specifications, supplier pricing information, and anything else the buyer may have included in the inquiry. Buyers will then evaluate suppliers based on things such as price, industry benchmarks, capabilities, services, flexibility, and dependability. Suppliers meeting the organization’s list of criteria, become known as "qualified" suppliers and are eligible to receive orders; Typically, an organization negotiates contracts with their suppliers; Contracts reflect agreements between the purchasing organization and the supplier and may include things such as pricing and quantity agreements, service levels, and quality requirements; These contracts are managed throughout the year by purchasing professionals known as supplier managers, to ensure the supplier is fulfilling their agreements; How well the supplier fulfills their contract often determines whether the contract will be renewed in years to come  Key Constituents:  Buyer, Supplier Manager  Major Inputs:  Prices, Product Specifications, Purchasing Volumes, Supplier Performance Data  Major Outputs:  Contracts, List of Qualified Suppliers, Negotiated Competitive Price, RFXs (RFI, RFQ, or RFP), Sourcing Decisions & Requirements, Supplier Information  Sub-Processes:  Select and Qualify Suppliers, Create Supplier Profile, Qualify Suppliers, Manage RFI/RFQ/RFP Process, Manage Auctions, Manage Bid Auctions, Analyze Supplier Bids, Supplier Contract Management, Develop Service Level Agreements, Contract Development, Manage Negotiations, Finalize Contracts, Establish Mechanisms for Procurement`

35. EMEA 35 80 Attributes  Who owns it  Who is the customer of it  Inputs/outputs  Exception handling  Exception notification  Performance (past, current, future)  Implementation (past, current, future)  People, process, technology, etc.  Initiator (time, inputs, etc.)  Documents  Governance, compliance  Best practice  Variance thresholds  Volatility / stability  Critical path item  Complex  Industry-specific  Etc.

36. EMEA 36 1. Develop Product /Service 2. Generate Demand 5. Collaboration 4. Plan and Manage Manage Enterprise Enterprise Product Bank Business 3. Fulfill Demand 1. Develop Product /Service 2. Generate Demand 5. Collaboration 4. Plan and Manage Manage Enterprise Enterprise Retail Business 3. Fulfill Demand 1. Develop Product /Service 2. Generate Demand 5. Collaboration 4. Plan and Manage Manage Enterprise Enterprise Transaction Bank Business 3. Fulfill Demand 1. Develop Product /Service 2. Generate Demand 5. Collaboration 4. Plan and Manage Manage Enterprise Enterprise Bank Business 3. Fulfill Demand The Transformation Process

37. EMEA 37

38. EMEA 38 Service contract Message exchange

39. EMEA 39 Introduction to Motion Methodology  The Motion methodology uses the concept of Business Capabilities to model a business – starting with a specific project  A Capability describes “what” is done, not “how” something is done  A Capability Model abstracts structural information (capabilities and connections) and separates this structure from dynamic information (process)  This results in a more stable model  Supports a more “end-to-end” view of functions or “services”  The simple distinction of thinking beyond process to the concept of “movement of work” creates a meaningful and valuable perception change  Motion is a straightforward, template-rich analytical framework that complements process improvement efforts  BPR, Six Sigma, Lean, etc.

40. EMEA 40 Points of Entry  A Point of Entry is a condition that warrants project initiation; Motion methodology refers to this as the Project  The methodology describes six types of efforts:  “Hound dog”: a general sense of pain is realized with no clear Project discerned  Change modeling: a Project is already being considered, Motion is used to add structure and consistency  Sourcing: similar to change modeling with its focus on changing owner of Capability and “who” does the work – internal vs. external  Incremental success: Project focus is known but complexity of solution requires definition of interim milestones  Business Architecture: A manager, such as someone in IT needs to make a decision or a change, but to execute the change, they need clarification with respect to what is known about the current and future Business Architecture in the context of the project. In this context, requirements are related to, but not the same as Business Architecture  Regulatory: Regional or enterprise-wide projects related to compliance and governance.

41. EMEA 41 Project Delivery Team  Composition of teams can vary dependent upon Point of Entry and Project, but certain roles are necessary:  Executive Sponsor provides capital and has Go/No Go authority  Project Champion recognized the Project  Project Lead is responsible for project delivery  Motion Lead is trained in methodology and is chief facilitator  Capability Subject Matter Expert has deep understanding of area in question  Project Financial Analyst is responsible for financial models that support change recommendations  Motion Tool Expert enters information and produces required reports and diagrams  Information Technology Liaison provides access to pertinent applications and information  Project Management Liaison provides project portfolio information  Administrative Support schedules meetings, produces status reports, etc.

42. EMEA 42 Motion Overview - Tasks

43. EMEA 43 Motion Overview – Roadmap with Deliverables, Point of Entry and Exit

44. EMEA 44 How Does Capability Management Differ from Process Management?

45. EMEA 45 How capability management differs from process management - The argument for “what then how”  Roots of contemporary performance problems are due to organizationally based operating model  Process models (though an improvement) are not the optimal view or management layer, and they expose “how” business is done  Capabilities manage “what service at what service level” – which is the most stable and concise level for design and management From Traditional Organizational Management To Process Optimization To Capability Management

46. EMEA 46 Conventional performance improvement techniques – go-in and go-down  Conventional business performance improvement and application development techniques; Theory of Constraints, Six Sigma, Total Quality, Lean Production, CMM, Business Process Reengineering all;  Start from a hierarchical and organizational (internal) basis and decompose within that context  Analysis typically does not associate the specific situation with the rest of the overall business  Views often exclude resources and connections across the entire business ecosystem  Can be helpful with efficiency / improvement, but do not put the problem in full context and rarely expose opportunities for innovation Go In/Go Down

47. EMEA 47 Motion enables the analytical power of go- in, go-up, go-out and only then… with that context, go-down

48. EMEA 48 Specific differences in this method  “Go in, go up, go out, go down” is a unique approach that can yield dramatic and innovative results that are less likely to be found other methodologies  Short repeatable project format with clear, measurable results  Time line is rigorously enforced  Very prescriptive  Template-based deliverables  Rich case study and FAQs provide added direction and guidance  Very repeatable for a variety of business problems  Objective metrics for the business and the problem or opportunity at hand  Expectations alignment deliverable used throughout projects helps to avoid project surprises  Offers specific guidance with respect to how it complements other methods, authored by experts of those other methods  6 Sigma  BPR  Zachman  And more on the way  Provides for an array of different types of problems in different kinds of businesses  Not “one size fits all”  Perhaps most valuable, this methodology lays the groundwork for establishing clear communication between business and IT  Particularly for organizations migrating to a services-oriented architecture (SOA), the final project recommendation from the business is broken down in terms that align directly with SOA

49. EMEA 49 Comparison to Zachman and TOGAF?

50. EMEA 50 Zachman  Knowledge base for artifacts  Organize based on point of view of participants with goal of getting comprehensive and disciplined perspective  5 Perspectives  Partner  Owner  Designer  Builder  Implementer  Dimensions  Data or entities  Function or process  Location on the Network  People or performer  Time  Motivation or goals  Great for implementing IT governance  Unlike Motion  Does not focus on capabilities  Artifact based, not performance based  Change is difficult and becomes a barrier  No awareness of the “ecosystem”

51. EMEA 51 TOGAF – The Open Group Architecture Framework  Enterprise architecture focus  Originated as TAFIM (Technical Architecture For Information Management) in US DOD  Core components  ADM – Architecture Development Method  Foundation architecture  Supports  UML unified modeling language  BPMN business process modeling notation)  ICAM integrated computer aided manufacturing  IDEF definition  Enterprise architecture  All org behavior  Data that is processed  Who does what  Where it happens  Why it is done  Unlike Motion  Foundation in technology, not business  Not a unique mapping method  Not as detailed in business architecture mapping  Not used as a problem solving methodology  Difficulty  Information maintenance  Lack of tools  Lack of standard notation and consistent vocabulary

52. EMEA 52 Future Tooling Concepts

53. EMEA 53 AnalyzeDeployImplementDesignOperate Business Technology Business Capabilities Business Capabilities Technology Architecture Technology Architecture Business Processes and Entities Business Processes and Entities Logical Data Center Logical Data Center Physical servers & segments Physical servers & segments Services, Messages, Contracts, Schedules Services, Messages, Contracts, Schedules XML, Database, Classes, Code XML, Database, Classes, Code Manual Procedures

54. EMEA 54 Carrier Selection and Optimization Carrier Planning Carrier Contracts Carrier Planning Track and Trace Shipping Management Customs Management Shipping Management Damage Management Shipping Management 3.5.2. Transportation Management 3.5.2.1. Carrier Planning 3.5.2.3. Shipping Management Manage Carrier Bids Carrier Performance Identify Capable Carriers

55. EMEA 55 Track and Trace Shipping Management Customs Management Shipping Management Damage Management Shipping Management BI Shipping Management 3PL Shipping Management APO Carrier Planning and optimization Carrier Selection and Optimization Carrier Planning 3.5.2. Transportation Management Carrier Selection and Optimization SCM Carrier Contracts 3.5.2.1. Carrier Planning 3.5.2.3. Shipping Management Carrier Contracts Carrier Planning Manage Carrier Bids Carrier Performance Identify Capable Carriers

56. EMEA 56 BI Shipping Management 3PL Shipping Management APO Carrier Planning and optimization Cross Docking Carrier Selection and Optimization SCM Carrier Contracts Track and Trace Shipping Management Customs Management Shipping Management Damage Management Shipping Management Carrier Selection and Optimization Carrier Planning 3.5.2. Transportation Management 3.5.2.1. Carrier Planning 3.5.2.3. Shipping Management Carrier Contracts Carrier Planning Manage Carrier Bids Carrier Performance Identify Capable Carriers Cross Docking Shipping Management Cross Docking

57. EMEA 57 Implementation Begins with Architecture Driven Design

58. EMEA 58 Modelling Connected Systems Business Model What  Capabilities How  Business Processes Technology Model Service Interface Orchestration Engine Service Implementation Service Host SOA Model Service Contract OrchestrationService Management SLA

59. EMEA 59 Modelling Connected Systems Business Model What  Capabilities How  Business Processes Technology Model Service Interface Orchestration Engine Service Implementation Service Host SOA Model Service Contract OrchestrationService Management SLA

60. EMEA 60  Business (process) model  Use case model  Business rules  Non functional requirements  ConstraintsTechnologyModel(OOAD)  Service definitions  Contract definitions  Information semantics and ownership  Communication patterns SOA Model (SOAD) So what do we need for SOA?

61. EMEA 61 Services Message Exchange Pattern describe OperationalRequirements enforce State manage Applications composed of Messages exchange is a set of Contracts bound by contain Schemas define structure of governed by Policies have Service Orientation - Key Concepts

62. EMEA 62  The business functional requirements of a system can be identified in use case analysis  Use cases can be realized using design patterns, message-exchange patterns, and service contract & policy definitions Business Requirements Business Requirements Business Use Cases Analysis Business Use Cases Analysis Design & ME Patterns, & Contract & Contract &PolicyRealization Service Oriented Analysis & Design Process

63. EMEA 63 Use Case Model Collaboration Model Interaction Model Requirements Statement Domain Model Class Model Dynamic Static Classic UML-based OOAD applied at the business abstraction level gives us a way to start SOAD Code SOA Model Derivation: Service Use Case Process Collaboration MEP Interaction Canonical Data MEP Semantics Domain Contract MEP Canonical Schema

64. EMEA 64 Implementation  Model your solution today, based on the elements that can be externalized  A Web Services Model  A Process Model  An Event Model  A Recovery Model  A System Definition Model  Build these solution using Biztalk Server and the.Net Frameworks today  For your next generation  How do you make processes core to the architecture

65. EMEA 65 Implementation Real World Example Bank Austria Case Study (Pub 9-Jun-05) http://www.microsoft.com/resources/casestudies/ casestudy.asp?CaseStudyID=16807

66. Use Case Model Developed with Business Analyst

67. Service Model Derived from Use Case Model

68. Interaction Model (example – loan consultation) ProcessActivity Look for Messages, MEPs, Canonical Schema, Service Contracts, Processes

69. Canonical Schema “On-the-Wire” Data Model

70. Application Architecture View Think of tenets

71. Technical Architecture View Think of service deployment & hosting model

72. EMEA 72 Summary Service Orientation: The 4 Tenets Not just about Code!  Boundaries are explicit  Services are autonomous  Services share schema and contract, not class  Service compatibility is determined based on policy Technology Model Hosting Hosting Interface Interface Technology Model Implementation Implementation SOA Model Contract Contract SOA & Business Model SLA SLA Capabilities Capabilities

73. EMEA 73 Conclusions

74. 74 Conclusions – Why is Motion Valuable?  Problem solving tool - establishes a powerful new business analysis and problem solving tool with a systematic and structured approach to discovering operational innovations  Common context for project portfolio - provides new context for evaluating existing people, process and technology development programs  On-going SLE management structure - creates a clear structure for on-going service level and performance management  Clear SOA Roadmap - positions the organization to develop a clear and concise road map to services oriented architectures  Common language – gets the business, finance and IT organizations talking the same language within a shared architectural view of a network-based operating model  Most importantly – you go at whatever pace make sense for you and your organization

75. THANK YOU 2005 Microsoft PAKISTAN DEVELOPER CONFERENCE June 13-15, 2005