SharePoint Evolutions roadshow 2014 - If apps are the answer what was the solution
•Descargar como PPTX, PDF•
3 recomendaciones•3,447 vistas
Full trust solutions have been a SharePointers bread and butter approach for as long as we can remember, but with the app world looming large in the rear view mirror what does this really mean when designing and implementing business solutions? Using a real world scenario we’ll walk through the changes to the approach when you start looking at the world of apps. How it influences the design approach, the technical implementation and the delivery of the solution to the business.
Recomendados
Recomendados
Más contenido relacionado
Similar a SharePoint Evolutions roadshow 2014 - If apps are the answer what was the solution
Similar a SharePoint Evolutions roadshow 2014 - If apps are the answer what was the solution (20)
Más de Wes Hackett
Más de Wes Hackett (10)
Último
Último (20)
SharePoint Evolutions roadshow 2014 - If apps are the answer what was the solution
- 8. _api JavaScript library Silverlight library .Net CLR library Custom client code _api Lists and libraries Execute query REST/ OData User profile Search Taxonomy Feeds …
- 9. _api
- 10. _api
- 15. contemplation - Ambivalence preparation – Lets get going action – Doing it maintenance – Living it pre-contemplation - Denial
- 22. qualification and planning decision to proceed opportunity preparation post opportunity the future project opportunity submission new opportunity
- 32. creating the backlog creating the designs building deploy testing analyse the requirements
- 33. creating the backlog creating the designs building deploy testing analyse the requirements
- 35. creating the backlog creating the designs building deploy testing analyse the requirements
- 40. creating the backlog creating the designs building deploy testing analyse the requirements
- 42. creating the backlog creating the designs building deploy testing analyse the requirements
- 44. creating the backlog creating the designs building deploy testing analyse the requirements
- 46. creating the backlog creating the designs building deploy testing analyse the requirements
- 50. creating the backlog creating the designs building deploy testing analyse the requirements
- 51. creating the backlog creating the designs building deploy testing analyse the requirements
- 53. creating the backlog creating the designs building deploy testing analyse the requirements
- 58. creating the backlog creating the designs building deploy testing analyse the requirements
- 61. creating the backlog creating the designs building deploy testing analyse the requirements
- 63. creating the backlog creating the designs building deploy testing analyse the requirements
- 65. creating the backlog creating the designs building deploy testing analyse the requirements
Notas del editor
- Full trust solutions have been a SharePointers bread and butter approach for as long as we can remember, but with the app world looming large in the rear view mirror what does this really mean when designing and implementing business solutions? Using a real world scenario we’ll walk through the changes to the approach when you start looking at the world of apps. How it influences the design approach, the technical implementation and the delivery of the solution to the business.
- TODO (WES) Introduce myself Wes Hackett Principal Solution Architect at Content and Code Working with the company since 2007 Working with SharePoint since 2003, MOSS 2007, SP2010 and now SP2013, Office365 SharePoint MVP CKSDev
- Get people to approach solution designs on SharePoint when approaching SP2013/Office 365 stuff Focus on why this matters to me…. Off boxing protects my precious sharepoint
- Initially our platform was all techie… Moves to something slightly more business focused but still in nonsense language Finally it becomes more aligned to Microsoft vision of Devices and Services -Key elements are the ‘app surface’ and ‘data store’ ideas
- 2003 What is an application SharePoint was not an application platform, except web parts Investments were in portals and content 2007 Everything is an application Push to embrace SharePoint for LOB applications Experience was to write custom server side code 2010 Choose the right application SharePoint and Developer tools come together Silverlight, CSOM and other new capabilities Partially trusted code reduces impact and risk to the farm 2013 Redraw your application as an App Client site experience via html or iFrame Leverage CSOM and REST APIs from Azure and other clients Investments in app discovery and management via SharePoint store
- Full trust solutions You’re missing control, since we basically grant full access rights for the code cross our application and in servers. In previous versions you could have limited provide access, but that was difficult to do and was not used that often. In general deployment always causes service break on the servers, since there’s really no way to update server without at least recycling application pool. Sandbox Our customization story basically grew up little bit or from Administrative perspective we gained some control. This was introduced in 2010… too strict from server side API level which developers have been used to use and client side APIs were also so limited that even though you could have implement some App model - Model is growing up with key objectives being on control, trust and management
- Wider choice of tools App design can be done using familiar tools like VS2013 Can be done in non-Microsoft tools too Hosting options Host your own services Leverage Microsoft Azure Service consumption Integration of other services to your App Providing a service via your App
- This shows a simple representation of the tool set available to SharePoint developers. These are being called familiar but doing some simple counting its clear that these are not that familiar to veteran SharePoint developers. These are more mainstream web technologies which are good to adopt. Don’t underestimate the learning curve here.
- This has been the way of thinking for the last 7 years. Features are written and packaged as Solutions Solution installed to SharePoint farm Site owner turns on features This deploys bits onto the SharePoint farm Code runs on the farm Users access the farm via a browser Comfort in building full trust WSP based solutions Code running on the box Full big bang solution builds and rollout
- The app model. This is the new way of thinking about customisations. Features are written and packaged as Apps Apps are deployed to the Office store or Company catalogue Apps are installed by the Site owner This deploys bits somewhere outside of the SharePoint farm (think Windows Azure here) Code runs somewhere other than the SharePoint farm (browser, native app, web server) Code speaks to SharePoint via API Users access the app via a browser Developers are ring-fenced from affecting SharePoint like bad bankers. Apps OOTB configurations Off box everything Don’t customise and invest in maximising OOTB use
- Put a roadmap against time about the stages of denial Pre-Contemplation => No = Denial Contemplation => Maybe = Ambivalence Preparation => Yes = Lets get motivated Action => GO = Doing it Maintenance => Living It What im trying to do here is get the devs to consider where they are right now….
- User research Find out how your app can support the users activity Become better informed about the need Not constrained to SharePoint Not constrained to the way SharePoint works Fresh canvas is you want to take that approach Prototyping becomes key Iterating a prototype for your user experience Delivering changes quicker
- Think about your app ‘brand’ Do you create something blended with your company brand? Do you go bold by having a unique app brand? You need critical mass Having a single lone app is going to miss the mark Better to go live with more apps The outside world Don’t be afraid of the outside world apps But do plan for them
- Wider choice of tools App design can be done using familiar tools like VS2013 Can be done in non-Microsoft tools too Hosting options Host your own services Leverage Microsoft Azure Service consumption Integration of other services to your App Providing a service via your App
- Solution v App Frequency of deployments Evergreen the platform Impact on delivery processes What does the delivery team need to change? Can your customer match pace Change Helping message the new features within the organisation Change in smaller chunks
- This is an example process for an organisation which completes proposals for new work It covers 7 main stages New opportunity Qualification and planning Decision to proceed Opportunity preparation Opportunity submission Post opportunity The future project
- Sales hear about a new lead From personal contacts Register the new opportunity Initial client research Have we worked with them before? Who are they and what do they do? Register interest to submit Submission of interest to the prospective client
- Legal review Contract sent for legal review Prospective client appraisal performed by legal team Assemble internal team Find the right skills to create a response Plan the activities for the opportunity team Engage partners Decide which partnerships can be used Brief the partner and plan their engagement
- Have we met with the client? Question and answers? Met key stakeholders? Presentation approach? How the presentation will be done? What can we already leverage? Commercials? Have the commercials been review? Legal agreements and contracts ready?
- Complete the submission pack Locate assets and case studies Locate CVs for the project team Create project proposal Facilitate the creation of the actual designs Comment and review for the design artefacts
- Final checks Review point for commercials Legal approval gained Proposal submitted Pack provided to the client Commentary collected Presentation scheduled Opportunity team and key project team scheduled Client meeting scheduled
- Provide client support Capture questions and provide responses Revise and track any revisions Record outcome Capture client decision Invoke record holds for materials such as contracts Lessons learnt Capture positive aspects of the opportunity Capture negatives from the opportunity
- Transition to project Create the project work spaces Move crucial assets into the work space Select project team Select the project team Ensure the team skills match the project Client engagement Continue to engage the client Manage schedules and tasks
- CRM Maintains the Client and other client relationship information Manages the ‘state’ of the process for opportunities Search Enterprise wide search is already available People profiles exist and contain skills Assets A digital asset site exists Asset search exists to provide a specific search vertical
- At this point we’re all about muscle memory and ‘what we know’ patterns On this section we want to leave the audience with the sensation that they would jump to a conclusion already after years of muscle memory building templates loaded with widgets Looking for SharePoint features Gut reaction is to translate the requirements to SP features Highlights gaps in the native capabilities Focus on templates We always build templates We assume we need to template the thing Scour existing code Evaluate solutions we’ve built before for code reuse Bend the solutions to meet there
- Register new opportunity form Web part or application page containing a data entry form Direct calls the CRM system to add a new record Research the client Web part surfacing the client CRM record summary details Web part to display public search results for the client Legal review workflow Custom content type for legal documents Custom legal approval workflow
- Opportunity team listing List definition and instance for team members information Custom Content Type ‘Team Member’ Partner selections Web part surfacing the partner details Web part to display selected partners Decision to proceed review Web part or application page containing a data entry form Direct calls the CRM system to add a new record
- Opportunity preparations List definition and instance for proposal information Custom Content Type ‘Proposal’ Opportunity submission Custom proposal approval workflow Site Mailbox and External Sharing features enabled Post opportunity review Web part or application page containing a data entry form Direct calls the CRM system to add a new record
- Future project Web part or application page containing a data entry form Custom workflow to transfer site into a project site
- Site home page Summarises all the sites information Widgets provide as much functionality in one page as possible Information architecture All Content Types rolled into the solution Possibly minimising the document libraries Led by solution structure Features tend to be led by Visual Studio layout Technical versus business structure
- Building….. Talk about the tooling be already available and people have loads of patterns they can use Also talk about the fact environments are fairly well understood but all maintained by you internally Visual Studio Using the available tooling for SharePoint Laying out features by best practices Server side an old friend Using the built up expertise of your server side knowledge Full suite of the API to use We’re on box Want to modify that core SharePoint file, go on then
- Large surface to test The solution contains a large volume of features Every backlog item in one test cycle Automation SharePoint doesn’t lend itself to testing TDD is harder to use therefore more manual testing One fail = all fail If one key feature fails the entire solution can’t be deployed Tightly coupling the entire solution problematic
- IT impact ITPro’s don’t like solutions breaking their servers Detailed information required for deployment Training and adoption Large amount of change and features to train people on Will the users understand and use it? Roll out and roll back Detailed roll out instructions Detailed roll back instructions
- Feature centric design Designs tend towards SharePoint features Laying out features by best practices One size fits all Home page containing a little bit of everything Users expected to understand everything More rigidity What is designed now might not be viable in 2 weeks…
- User Experience led Understand your users needs and desires Build Personas and Scenarios Looking for Activities Translating the business requirements into groups of activity Highlights gaps in the native capabilities Templates still have a place We always build templates that hasn’t changed High level information architecture across the requirements
- New opportunity App App page containing a new opportunity data entry form Direct calls the CRM system to add a new record Client 360 App Display Client CRM record details, including summary Display public search results for the client Legal review workflow app Custom content type for legal documents Custom legal approval workflow
- People Directory App People and skills based searches CV and experience pivots Task template App Collection of task templates a user can add to the opportunity Several versions, based on business experiences Partnership Directory app Partnership searches Industry sector, technology, partnership experience pivots
- Opportunity Go/No go App Question and answers capture Opportunity ratification and risk profiling form Opportunity App Custom content types for opportunity documents Library and list templates Asset Directory app Digital Asset searches Industry sector, technology, opportunity success pivots
- Opportunity Review App App page containing a opportunity review form Direct calls the CRM system to add a update the record Outcome Review App App page containing a outcome review form Direct calls the CRM system to add a update the record Move to Project app Custom provisioning for a related Project work space App page to capture the information to move
- User Experience led Scenarios translated into App user experiences Aligned to user journeys and personas Information architecture Specific to the ‘activity’ the app is facilitating Provisioning what it needs to function within the host web Clickable prototyping Giving the user something to experience Getting early feedback and iterations
- Employing App shapes Using the various shapes to extend the app into host web Making the app seamlessly feel part of the environment Branding the App Options to blend with the host web or go string unique Depends on the sorts of App App Catalog presence Ensuring the App Catalog is delivered Getting the user into the Catalog to install the App
- Building….. Talk about the tooling be already available and people have loads of patterns they can use Also talk about the fact environments are fairly well understood but all maintained by you internally Visual Studio Using the available tooling for SharePoint Using hosting like Azure Provider Hosted is preferred MVC5 Provider Hosted gives best flexabilty Full suite of the CSOM and REST available We’re off the box We’re building in the common web app patterns Protecting SharePoint
- App sized surface to test We are only testing the app and its integration points The testing cycles can iterate quicker Automation Apps lend themselves to testing TDD is easier to use therefore less manual testing One fail = just this App fails If one key feature fails only this App fails Loose coupling allows other Apps to still progress
- IT impact ITPro’s will be deploying to IIS instead of SharePoint Becomes part of the web application estate Training and adoption Smaller targeted user experiences are more manageable User feedback is quicker to incorporate Roll out and roll back Power of installation is in the users hands Power of removal is in the users hands
- Activity centric design Designs tend towards activities for users Apps are self contained use cases Simplicity of UX App user experience is focused on just the activity Abstracting away from the ‘feature’ focus of SharePoint More flexibility What is designed now might not be viable in 2 weeks… Update the Apps as they need it