1 / 28

The Microsoft Technology Centre Process - Accelerating and De-Risking Technology Adoption

The Microsoft Technology Centre Process - Accelerating and De-Risking Technology Adoption. Dave Brown, Microsoft Technology Centre Architect. Microsoft Technology Centre Video. http://www.microsoft.com/mtc. Introduction to the Microsoft Technology Centre.

ava-huff
Download Presentation

The Microsoft Technology Centre Process - Accelerating and De-Risking Technology Adoption

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The Microsoft Technology Centre Process - Accelerating and De-Risking Technology Adoption Dave Brown, Microsoft Technology Centre Architect

  2. Microsoft Technology Centre Video http://www.microsoft.com/mtc

  3. Introduction to the Microsoft Technology Centre “Microsoft Technology Centres provide an ideal environment to envision, architect, and demonstrate customised solutions.” • Locations • United States – Austin, Boston, Chicago, Reston, Silicon Valley • Worldwide – Bangalore, Beijing, Copenhagen, Dubai, Munich, Paris, Taipei, Thames Valley (UK) • Methodology • Developed over time to a re-usable process for de-risking technology adoption

  4. Repeatable Process Offerings • Strategy Briefing • 1 day • Targeted demonstrations • Architecture Design Session • 2-3 days • In-depth envisioning, design and planning • Proof of Concept • 2-3 weeks • Development and demonstration • Productivity • Last financial year, The Microsoft Technology Centre Thames Valley completed 164 Strategy Briefings, 50 Architecture Design Sessions, and 45 Proof of Concepts

  5. Team Structure • Management • Opportunity qualification • Engagement process • Partner & industry relationships • Architects • Broad knowledge of products and technologies • Architectural & strategic business skills • Customer-facing role • Technology Experts (Virtual Team) • Lab Engineers • Client and server builds • Networking • Briefing Coordinator • Logistics

  6. The Facilities • Architecture Design Session Room • Meeting configuration • Whiteboards • Proof of Concept Room • Lab configuration • Whiteboards • Server Room • Dedicated network, servers & storage • Demonstration Room • AV with home automation in multiple “zones”

  7. Strategy Briefing Overview “ A clear, actionable picture of how software can realise specific customer business goals." • Audience • Business-focus, CEO/CIO-level, influencers • Process • Customer-led business strategy presentation • Microsoft Technology Centre-led, targeted solution scenario presentations, e.g. Information worker, Integration, etc • Scenario & technology drill-downs

  8. Architecture Design Session Overview “Architectural and strategic guidance, risk-analysis, and best-practice approach of how software can realise specific customer business goals.” • Flavours • Envisioning • Architectural Design • Proof of Concept Planning • Process • Preparation (Architecture Design Session Team & Customer) • Delivery • Follow-up (& documentation)

  9. Architecture Design Session Preparation • Architecture Design Session Team • Qualification • Preparation, planning, customer conference call, expectations • Technical resources identification • Facilities booked, agenda circulated and agreed, invites sent • Customer • Company & organisational presentation • Project presentation • Requirements presentation • Technology topology presentation • Scenarios presentation

  10. Architecture Design Session Agenda • Discovery • Introductions • Expectations • Approach • Customer background • Business context • Business benefits • Drivers • Issues • Business scenarios • Non-functional requirements • Technology Landscape • Envisioning • Review • Architecture and Design • Components • Interfaces • Communication • Non-functional requirements • Scenario testing • Planning • Review • Scope • Proof Points • Metrics • Deliverables • Assumptions, Risks, Constraints • Resources • Roles, responsibilities • Dates • Communication • Escalation plan

  11. Architecture Design Session Team • Architecture Design Session Team • Architecture Design Session Lead • Technical Specialists • Domain-specific specialists • Customer • Senior management sponsor • Business representative • Development representative • Infrastructure representative • User representative • Project manager

  12. Architecture Design Session Responsibilities • Architecture Design Session Team • Facilitation • Question assumptions, drill into issues • Ensure agenda followed, bring discussions back up • Ensure objectives/ expectations met • Get agreement • Provide technical/ industry expertise • Ensure everything is documented • Customer • Business buy-in • Provide business and technical background • Decision makers

  13. Architectural Design Session Deliverables • “Vision & Scope” document • Problem Statement • Business Goals • Scenarios • Proof-Points • Deliverables, Exclusions • Architecture, Design • Risks, Pre-requisites

  14. Proof of Concept

  15. Proof of Concept Overview “Transfer knowledge, develop and demonstrate custom solutions defined in an Architectural Design Session.” • Drivers • Provide (technology) vision, de-risk technology adoption • Demonstrate use of product features, system integration, business processes, non-functional requirements in a custom solution • Developer productivity

  16. Proof of Concept Timeline Mon Tues Weds Thurs Fri Agree vision Initial plan complete Week 1 Solution concept complete Development begins Mid-point review Feature-set freeze Week 2 Bug-fix, stabilise Code complete Demo walkthrough Demonstration Week 3 Finalise POC package POC complete

  17. Proof of Concept Team • Proof of Concept Team • Proof of Concept Lead • Developer Lead • Developer(s) • User Experience • Lab Engineers • Customer • Business Sponsor (kick-off, mid-point review, final demonstration) • Developers • Experienced • Inexperienced

  18. Proof of Concept Responsibilities • Proof of Concept Team • Build & maintain lab environment • Work item definition and assignment • Daily reviews • Communication to customer • Ensure Vision & Scope met • Architectural, technical, and developer expertise • Code reviews • Ensure everything is documented • Customer • Business buy-in for kick-off, mid-point review, and final demonstration • On-site developers • Decision support available • Agile methodology • SCRUM-'like'

  19. Proof of Concept Constraints • Exclusions • Best-practice development in all areas • Exception handling • Development framework and methodologies • Auditing, logging, monitoring • Administration, management • Installation and deployment • Versioning • Performance and scalability

  20. Proof of Concept Deliverables • Final Demonstration • Screen capture • Film crew recording • Proof of Concept Review Document • Key findings • Work completed • Template available for download • Source code • Source control archive

  21. Proof of Concept Demonstration • Attendees • Business sponsors, CEO/CIO etc, Account Team • Format • Introduction, scene setting • Scenario playback • Customer-driven, primarily non-technical • Q&A, summary • Benefits • Real business solution in simulated customer environment • Business buy-in, solution-focussed audience • Demonstrator/video disseminated to wider audience

  22. Server Room

  23. Envisioning Centre

  24. Key success factors • Dedicated environment for meeting/developer productivity • Whiteboards • Server room, network, internet connectivity, automated builds, sand-boxed environment • Demonstration • Resource identification • Business sponsors • Decision makers • Technical experts • Business focus • Business goals realised through software

  25. Common Pitfalls • Preparation • Opportunities not correctly qualified • Expectations incorrectly set • Architecture Design Session • Too many attendees – optimum around 6 • Lack of business input • No decision makers (lack of business buy-in) • Treat as a ‘consulting’ exercise • Proof of Concept • Scope and proof points not clearly defined • Non-developer lab attendees

  26. Case Study Example – Major Oil Company • Background • Disparate systems with large numbers of interfaces, often complex & difficult to maintain • Large numbers of Excel spreadsheets leading to de-centralised data and intellectual capital, hard to make decisions based on big-picture • Solution • Integration of sample back-end system following a strategic architecture based on SOA • Aggregation and visualisation of sample data sets in personalised dashboard • New possibilities for data consumption using PDA smart client • Impact • Technology-enabled strategy on service-oriented business intelligence • Rapid adoption, global alignment via follow-on engagements

  27. Case Study Example – Global Paper Producer • Background • Silos of information (lack of re-use), duplication • Low-bandwidth environment • Solution • Replaced replication-based solution with collaborative intranet • Architecture for global intranet, collaboration with automated publishing, local and global search proven over simulated low-bandwidth network • Impact • Information re-use and global collaboration • Rapid adoption (first go-live POC + 10months)

  28. Further Information • Microsoft Technology Centres, dave.brown@microsoft.com,http://www.microsoft.com/mtc • Lynx Technology Customer Innovation Centre, http://www.lynxtec.com/cic/cic_offerings.htm • To discuss engaging with the MTC, contact your Microsoft Account Manager

More Related