|Danny Ryan:||Hello, this is Danny Ryan and welcome to the ThreeWill Podcast. Today, I have Chris Edwards here with me. Hey, Chris. How’s it going?|
|Chris Edwards:||Hey, doing great.|
|Danny Ryan:||Good, looking forward to getting an update from you. You’ve been busy, my man.|
|Chris Edwards:||I always try to stay busy all the time. Try to.|
|Danny Ryan:||Keeps you out of trouble.|
|Chris Edwards:||Yeah, hope so.|
|Danny Ryan:||Hope so. How are the puppies?|
|Chris Edwards:||They are all adopted except for one. We’ve decided to adopt one.|
|Danny Ryan:||To keep one, very nice.|
|Chris Edwards:||There was struggle is trying to get a name. Figured it out when we finally got one.|
|Danny Ryan:||What’s the name of the-|
|Danny Ryan:||Sheldon, sounds kind of formally dressed or something. Let’s get to it. I wanted to get an update on … I know you’ve created a trial version of the Migrator Tool.|
|Danny Ryan:||I just wanted to get an overview of what that is and just catch up on things. I know you’ve been working on a video as well of what Migrator does and demo for me and just catching up with you as far as what things you’ve been up to lately.|
|Chris Edwards:||Migrator, it is … Basically it’s a initial visual interface that allows someone to just download it. They want to see how large their Jive environment is. We typically work in terms of number of places. When I say number of places, in Jive there are different kinds of places. There’s the concept of the space, concept of a group, concept of a blog and a concept of a project. We just call all those places just to have a generic name term for it.|
|Chris Edwards:||One of the first things we do in a migration is we do an inventory check. We basically pool all of the different number of places and then a basic hit on the content. To have that initial conversation is hard to know how the day of a customer is. The Migrator utility in its current state doesn’t actually migrate content. It’s not what its intention is at the moment. We’ll talk about that in a minute.|
|Danny Ryan:||The trial version of it, it just goes out and does these counts for you and just get-|
|Chris Edwards:||It’s designed to be the super simple. All its trying to do is gather your Jive Instance URL, basically what you use to get the Jive. A user name and password that … In this case, the user name should have the access to all the different places that we need to find. Typically, it didn’t have to have right access-|
|Danny Ryan:||Just real access.|
|Chris Edwards:||Just real access that needs to be able to use the API behind the scenes and actually get hold of the places themselves. Then what it does, it goes off and does, this is magic behind the scenes, it pools all the details and just report a summary. It just allows that conversation to be very clear in terms of when we are looking for the number of places looking for a size of what you guys … What a particular Jive particularly has. We have a clear talking point and clear denominator to work off of.|
|Danny Ryan:||Partially it’s kind of funny because when we’re talking about doing pricing based off of places …So many times I say species not places. I’m saying the right word places. I had some folks who prospects who were saying, “Okay, that’s great. How do I find out what that is?” I would be like, “Ah.” There’s not a real place you can go to. I’m assuming in the Jive admin where you can go see or just show you the same information, correct?|
|Chris Edwards:||There’s not a clear way of saying, “Okay Jive, how many places are there and what does that break down? I’ve not been able to find a clear indicator of that. That’s what the simple utilities in its current state is designed to do.|
|Danny Ryan:||There’s also a very real. This is almost like what you often do with projects for flashing one through the pipes which is seeing if somebody can test it against their Jive or whatever they happen to be running Jive-wise. This is just hitting drive, it’s not hitting SharePoint or doing anything with regards to Office 365 or SharePoint.|
|Chris Edwards:||Yes, that’s actually a great point. It’s only hitting your Jive Instance, so it is not … Before there’s backend information. It’s not recording information other than what’s in the log file, it’s log goes to the really application apps. In the video I pointed that out because I know what that is.|
|Danny Ryan:||You’re storing the credentials anywhere-?|
|Chris Edwards:||We’re not storing the credentials anywhere. The intention was to not do any of that. It’s really just an exercise to get the number of places to have that conversation.|
|Danny Ryan:||Where does this go? I know one of the things I’d love to have is just 2, because a lot of people ask, “Can you just migrate one place for me?” I know maybe eventually if there’s some arm twisting going on and you have enough time we may be able to get to that or maybe not. Who know? We may need to work into it.|
|Chris Edwards:||I’d love to look into it.|
|Danny Ryan:||I know that’s something we want to do. There’s also maybe getting a little bit more information about sizes of things or what are the things are on the backlog right now or things that you want to add to the trial version?|
|Chris Edwards:||The trial version, the next major … The logical thing to do would be to go a little deeper in terms of the contents. One of the things we do is … Part of the inventory process is we capture the number of places but we also do an initial high level pool of content that actually pool the binaries, not do the full mass of pool but the high level details of what’s in the content that allows us to get the number of content per place.|
|The beautiful thing about that is to do that in a simple way, adapt to the utility then we can actually start talking about how do we group all places in such a way that we’re able to batch them up. We can do them in a very consistent way. If we wanted to migrate 100 or 200 or maybe 1,000 at a time, that 1,000 we identify is similar to the next 1,000 and not guessing in terms of how long something is going to take. We get more predictable with how long an actual migration is going to take. The next phase would be more predictable, has a more predictability to the output and how long things will take to do.|
|Danny Ryan:||Very nice.|
|Chris Edwards:||It just helps us plan and it adds to the overall process of how migrations are done. That information will be super useful to have.|
|Danny Ryan:||It’s a nice, I appreciate you creating a little video and I’ll put a link to the video in the notes in this podcast, but just walking through what the typical drive migration looks like and what the tool does. I know it’s a command line tool so its doing what it’s doing and it’s writing to a log file and you … I really appreciate you going through what the whole process is. That just makes it more real to me and for folks who want to see what does it look like to do an actual migration.|
|Chris Edwards:||We’re trying to keep things simple. We’re trying to go after stuff that truly makes sense. We want to help people be successful in their migrations. We don’t want to overdo it or over-engineer it. At least we’re very specific about where we’re going after, ask the right questions and make sure we’re able to things correctly. Also estimate things correctly so we don’t over blow the budget or anything like that.|
|That’s the only designed to be … Someone to go from end to end, be predictable about it and be successful the whole process. Also, keeping the tool simple, allows us the customer is done very easily. Someone, “Oh, I don’t like the that works.” I said, “Wait.” The whole migration process, I want to change something about it. I’m going to make it very easy for us to adapt to that.|
|Danny Ryan:||Very nice.|
|Chris Edwards:||That’s the plan. That’s your idea.|
|Danny Ryan:||You are in a middle of migration right now, right?|
|Danny Ryan:||How is that going?|
|Chris Edwards:||Going pretty well. Looking forward to getting this one under the belt as well, but it’s good it’s a pretty big one.|
|Danny Ryan:||Big like certain amount of content or big like number of spaces or number of places?|
|Chris Edwards:||Number of places.|
|Danny Ryan:||How? Do you mind me asking?|
|Chris Edwards:||We’re actually migrating 2500 but then archiving over 10,000 so it’s a fairly large effort.|
|Danny Ryan:||Very nice. Well done.|
|Danny Ryan:||Well done. That’s it for now. I appreciate these little updates and continue your hard work. There’s lots of people who are contacting us about migrated from Jive to SharePoint and Office 365 and it’s amazing what you guys have built over the last couple of years. It’s not just the tool, it’s also the whole process and the far that you guys have put behind this that I appreciate.|
|Chris Edwards:||We’re also looking at improving how we can really leverage the SharePoint. The SharePoint functionality in what it does. I’m really trying to change the way we think about … This is not your bunch of wikis. Let’s just not migrating Jive content, let’s make this content come alive in SharePoint and really take advantage of that. We’re looking into that as well.|
|Danny Ryan:||I think we’ve recently seen some of the new you. All I changed is the SharePoint and some of them smell a little Jive like. They’re trying to go a little bit more down that pass. Hopefully we’re getting more towards they’re moving a one to one and the experience is similar to … In SharePoint to what you have in Jive. It’s because there some transition and there’s some change right now and hopefully we’ll see Office 365 continue to improve the whole UX experience and then getting the content and hopefully everybody will be happier With that improved experience.|
|Chris Edwards:||Absolutely. Looking forward to seeing that continue to improve.|
|Danny Ryan:||Thank you for taking the time to do this, Chris.|
|Chris Edwards:||All right, thanks.|
|Danny Ryan:||Thank you everybody for listening. Have a wonderful day. Take care. Bye bye.|
|Danny:||Hi. This is Danny Ryan and welcome to the ThreeWill Podcast. I have procured Chris Edwards for your listening enjoyment. He has been quite busy lately.|
|Chris:||Yes, very much so.|
|Danny:||He’s been very busy, so I really appreciate you taking the time to do this. I’ve been talking to a lot of people about the Jive, the SharePoint migration tool. I’m anxious to get an update on what are the things you’ve been doing recently, maybe hit it at a high level and let’s dive in to some particular things. I know you’ve added some additional features to it. What’s been going on lately?|
|Chris:||Just a lot of activity on the Jive, the SharePoint migration tool. Lots of things more so around just refining the process. Not so much the tool. Actually, I’ve got quite a bit of updates on the tool but more of the process of how we go about capturing inventory, really refining the inventory in such a way that people can understand what is out there in Jive. What do people have that they really care about, and how do they make decisions whether or not a particular Jive place or a collection of Jive content needs to stay or go. We’ve done some improvements really with the process to help make some of those decisions as well as understand when we do move a Jive place, how do we know if we did it correctly?|
|It’s great to be able to move content, but when we move content, what if only fifty percent of it came across? How do you know that? How do you know if eighty percent of it came across? If only eighty percent of it comes across, is that a big deal or not? Do we need to care about those exceptions and care about things that happen? A lot of more improvements around the tool, really around understanding the process and capturing ins and outs and making sure people are able to make really wise decisions about the content itself.|
|Danny:||It sounds like you have people you take a look at, you have a way of understanding what’s currently in their Jive environment so that they can sort of … Because part of this process may be pruning some of it or not moving content over?|
|Chris:||Yeah. One of the things that people may want to do is look at when was the last time a place or a particular piece of content within a place … When I say place, I mean this is a Jive terminology for any kind of container in Jive. One of the things we were able to expose now is when was something last modified in the context of a place? A lot of companies, especially the bigger companies, they want to have a retention plan in play. They don’t want to move stuff over that was last touched more than two years ago. We can now identify that a little bit better than we could before and really, it maybe that they want to archive it. The way the tool has been designed, I mean we talked about this last time, is that the tool still maintains the same design where we pull content out of Jive and we store it into either database and/or a file system. That’s kind of the archive, if you will. That’s still in play.|
|Whether or not we move it forward though, that same content, we transform it into something SharePoint can understand and push it into SharePoint which is our upload piece, we actually have terms for these things now, then … It’s crazy who that kind of stuff works. We can actually make decisions on whether or not something goes to SharePoint or not, and better decisions, not just everything. On top of the process and just being able to measure what are we doing well, what do we need to triage as an exception, we’re getting timeouts all over the place, how do we go about fixing that? Then, minimizing how much redo we have to do. We don’t want to have to redo everything that we find an error later on in the process. We want to minimize that. We’re not billing for that time. We want to make sure we’re using our customer’s money wisely and really making sure that we can wise decisions, enabling them, and then also making sure that they get their content in SharePoint and they’re happy with what they get. That’s all part of that.|
|We really have made a lot of improvements to the tool with regards to performance and pulling content out of Jive. We got more respect around the tool now. Before, it was kind of a loosey-goosey, here are the command lines, very … I thought it was good, I just threw it out there. It was quickly put together. Now we actually sat back and said, “Okay, what do we really need to be pulling out of Jive? How do we need to control it? Do we need to pull everything? Do we need to pull it by type? Do we need to be able to pull things by maybe something that was last modified by a certain time frame? We can specify these different parameters and really hone in on what we want to pull out of Jive.|
|We also have added multithreading to the tool. Now, the tool doesn’t just go after one place in Jive at a time. It can actually go after a whole collection of them based on how many processes around whatever server or whatever environment you’re running on, it can actually utilize those processors. Instead of being restricted by the latency of Jive and just pulling one place at a time, which is extremely slow, we can actually queue up and run multiple pulls from Jive simultaneously.|
|Danny:||In the command line, do you like /ludicrous mode?|
|Chris:||Exactly, ludi mode.|
|Chris:||I put it in ludi mode and it just pulls it all down in two seconds.|
|Danny:||Then that server starts warming up and it starts …|
|Chris:||You can really see it rip and do stuff. It’s trying to get a balance of what can we really pull out of Jive? How fast can we pull stuff down without causing it to break as well? It’s kind of getting that, trying to get to that balance point.|
|Danny:||When we’re moving over, so we’re moving over like a batch of … We’re probably working with a client to decide what’s coming over first, is that correct?|
|Danny:||Then, once that moves over, there’s some … I’m sure there’s some remediation on our side and then on their side, some … Are they going through in some acceptance? “Yes, my content has been moved over properly,” is that what goes on/|
|Chris:||Yes. Typically the customers’ responsible for validating their own content, but we put a lot of stuff and try to put a lot of stuff in place and really structure the roles for the … Like I said, I’m more of the migration engineer and tool, I make changes to the tool but we actually have a migration engineer person now that actually is just running the migrations. That’s all that their role is and they’re managing the exceptions and monitoring things before the customer even sees the content. They can help direct, “Oh, we have a lot of timeouts. Maybe something was going on in Jive. Maybe things were happening at that time. We need to go back through and check to see if any code needs to be modified to fix this.”|
|Really identifying patterns and what kind of issues are out there, so we can decide if it has to be redone or not, before even the customer gets it. Then the customer would get it, we would inform them that we’re going to get a dashboard format into our regular format where they could say, “These are the new places that are available in SharePoint.” We’ll have a look. If we find issues, then we’ll track it and the migration engineer will basically go to work with individuals to do that, and see do we need to redo things or not? We got more of process. We have to because we’re dealing with a lot more volume of content now. When we originally did the migration, it was for ourselves. We don’t have so much content. If we had to do manual steps, manual process, we did it.|
|Danny:||How many years ago did we do that?|
|Chris:||Two or three years ago.|
|Danny:||Two or three years ago?|
|Chris:||Yeah. It was the first kind of iteration of the tool itself. Since then, the tool has basically stayed in the same overall form. It’s still a console-based tool. It was built that way on purpose to keep it simple.|
|Chris:||Exactly. There’s no reason that … I mean, why bring an interface into this if it’s not needed. We have found the need for an interface in certain ways like when people want to manage what places go into Jive and we’re dealing with a spreadsheet right now.|
|Danny:||That’s great. People are very familiar with working with a spreadsheet as well.|
|Chris:||It’s great but it’s unwieldy as the same time. There’ll eventually be some improvements there where we can not be so tied to the spreadsheet and make it a little bit more … At least that’s my hope. Make it a little bit more of a user interface on that part of it. Can never guarantee that particular functionality is going to happen. It really depends on how many people are interested in the tool, how often we’ll use it and whether or not we really see the bang for doing that.|
|Danny:||When you’re doing this, you must pull all of the user information over first before the content? Is that correct? What’s the sort of high level series of what happens?|
|Chris:||Typically, we focus on inventory first. We talked about this a little bit the last …|
|Danny:||You can say something twice. I will forget. Actually if somebody listen to it, you don’t have to hit it too hard, but go ahead.|
|Chris:||That’s cool. Typically, we pull, we do a getPeople. We’d pull the people in Jive first because everything is dependent on the person. Even the creation of a place, even the specification of a place. When I say place, in Jive, it’s the concept of blogs, spaces, groups, and projects. Those are the kind of four container text. Place is just a generic term for that, so I keep saying that every time. Essentially we pull the people, we pull the places, and then we pull what’s called the metadata run of content. We pull the high level of content into our database so we can get content counts. We know kind of at breadth what’s out there, what was last modified at the content level and at a place level, and we produce a spreadsheet out of that. We take that and we give that to the customer so they can say, “Okay, these are the particular places that really have been modified most recently, which ones have not been touched forever.”|
|They have a lot of information as well as counts as well as the size of each of the places, I mean, all that kind of stuff’s in the spreadsheet. They can take that and make their decisions. Then we batch it like you said earlier into logical chunks. We found that a logical chunk of like fifty places at a time is a nice focused batch. We may ramp that up as we really get further into this and work with larger customers. A batch of fifty at a time seems to be pretty reasonable because you can report updates on those, you can monitor exceptions on those, and it’s a consumable amount to say, “Here customer, here’s another batch of fifty. You can communicate this to your end users.” It seems to be a pretty nice manageable amount. That’s pretty much how it works.|
|Danny:||It sounds like here’s a couple of new folks that are working with you. Is that like Lisa and Brendan?|
|Chris:||Mainly Lisa. I have Gary working with us a little bit as well, doing more of some performance improvements and helping with some of that.|
|Danny:||What about, are there different content types? Have there been some content types nuance that we’re supporting? I know we’re giving some estimates around where a blog post maybe coming.|
|Chris:||When we originally wrote the tool, it was focused on three different containers. I kind of rattled them off earlier. There was the blog, project, group, and space. Originally blog was not part of our mix. It wasn’t really treated as a primary content type inside of Jive. We were really focusing on the spaces, projects, and groups. That really came over when we originated the tool for ourselves. I don’t think blog as a container type was really even around that time. We’ve been improving the tool. We got some updates to it that actually include blogs as a primary container type now as well and bringing over that content as well too. That’s some improvements to the tool and really making sure we can cover any type of place that’s in Jive. We have a story to deal with that. We focused on tasks. We’ve pulled discussions. We’ve actually changed the tool now so instead of generating pages like Wiki pages, things like that for discussions, it actually generates SharePoint discussions and real thread SharePoint discussions in SharePoint.|
|Chris:||It’s nice because it actually can be begin to introduce as a discussion. A discussion in Jive can be moved over to SharePoint and continued to be used as a discussion in SharePoint. The user information’s maintained, the timestamp’s maintained and the whole threaded nature of the discussion is maintained. That’s definitely the super improvement to the tool.|
|Danny:||I used discussions. I used one like, I think the last time was six years ago. I mean, it was [inaudible 00:12:42]. I don’t remember.|
|Chris:||Yeah. It’s not …|
|Danny:||I don’t remember the la- … I’m being just upfront. It seems like that’s been something that again with the overlap between SharePoint and Yammer, more recently just got lot of the discussions go on inside of Yammer.|
|Danny:||At least this gives you an archive or the content and you can pick up the Yammer discussion off of it as well.|
|Chris:||You can do that.|
|Danny:||You can refer to it or, you know, stuff.|
|Chris:||You could use it by its pure nature, you could use it as a discussion in SharePoint, so that doesn’t really end that, but yeah you said it, it’s a great launching point to start from Yammer to say, “Okay, I want to point to this discussion and continue from there.” It works either way. It maintains the integrity too of the threaded nature of it and kind of how things were created in Jive. It matches a little bit better. Before, we were doing things where we would create these pages and it was more of a static pull. You would have to go to something like a Yammer. It was really your only option that can continue the conversation. Now we have a little bit more of a rich set of options to go continue the conversation.|
|Danny:||Jive has the concept of secret groups. We’re handling those as well?|
|Chris:||We’re actually capturing permissions. In terms of when I say permissions, really we’re capturing the users at the place level. How many members are in different Jive places? We’re actually able to capture that detail now in our database. That’s another piece of archive information we have. We could also play that forward. If something was a secret or private group in Jive, we can actually provision the site in SharePoint, apply the actual permissions in terms of who is a member of what in SharePoint, and then pull in the content. That way, we’re not actually opening up content to folks that shouldn’t see it. We’re actually able to leverage and move over the people and the people membership references from Jive into SharePoint.|
|Danny:||Then those people would, you’d have to have the acceptance on their side, you’d have to have somebody who has access to the secret group to say, “Yes, the content’s moved over.” You have a secret group, you moved it over, how do you know …|
|Chris:||Secret private groups in terms of SharePoint, there’s really no kind of differences between those. They’re basically the same thing.|
|Danny:||Once it’s moved over to validate … Let’s say there’s a super secret HR discussion group, three members in that group that are over in Jive, it gets pushed over into SharePoint, then you have to have one of those three people to go and verify that the content did get moved over properly.|
|Chris:||Right. As part of that spreadsheet I mentioned earlier, we actually have a list of all those types of users. For those highly sensitive places, it’s still up to the customer to communicate to their end users when it’s time to go look at it. We don’t add users to a site in SharePoint unless they were part of the appropriate place in Jive.|
|Danny:||You’ve added, done some tweaks with multithreading.|
|Danny:||Some of the [crosstalk]. What are we at a high level, just at a high level, what does that mean? Like you’re moving over a certain number of sites per hour or what is that?|
|Chris:||This is for like the content metadata run like I talked about earlier where we just wanted not necessarily to pull down all binaries but we just iterate through all the content in Jive. We’ve been able to do something that previously took like a day, day and a half, I’ve seen it go down to like an hour, hour and a half. It’s a substantial difference.|
|Danny:||Nice. Then the file content, it’s dependent upon how quickly the bits go over the … Is it pretty quick?|
|Chris:||Pretty quick as well. Yeah. Typically we’re pulling down content and all the binaries that come with all that. Pretty much, everything that, let’s say from a batch of fifty like I talked about earlier.|
|Chris:||A batch of fifty places, let’s say they’re not super large places but let’s say a batch of fifty, we could pull that down in say like fifteen minutes. Before, that might have taken us half a day to do that just because we’re doing it at a very single-threaded way. There’s just a lot of latency there that we’re just not taking advantage of the machine that was running the tool. Really try to take full advantage of the machine and what Jive could actually accept for throughput. That way, we’re able to really trim that down. It’s important because people that are wanting to come off Jive, they want to get off there within a timely manner. It can be a major risk if they’re running up against the licensing end date and they’ve got a lot of content. We want to be able to get that content down quickly and be able to, I don’t know what we’re going to do with it.|
|Danny:||Is there any plans to, because I know with Jive you can request a backup, let’s say when you’re moving off of Jive. Are there any plans for us to, instead of working with our API, to work directly with the backup to do this?|
|Chris:||I’ve done that myself. Just poking into the database, but we don’t have any plans at the moment that allows us to programmatically look at that.|
|Danny:||It might be interesting for us to look at that because if that’s … Because APIs change, right?|
|Danny:||Just in case like as a backup plan, if you can get the database backup of the whole thing and …|
|Chris:||Can we take in a full content out there and transform it the same way?|
|Danny:||Can we take in full content and then … Yeah.|
|Chris:||That’s one of the nice things. The way we’ve designed this is that if you could read that database programmatically then you could basically push it through the same procedures we currently have for the transform piece and the uploads. All that would stay the same.|
|Danny:||The only reason why I said it is it’s also a backup plan in case they’re not able to get out in time and we’re not able to get everything out if we can work with the database backup. That gives an alternative planning for people.|
|Danny:||Just a thought I tried to come up with.|
|Danny:||Such a little thing.|
|Danny:||That’s probably the worst type ever. You would say that to me like, “Danny, that is the worst idea.” You’re going to leave the room and go tell people, “Danny said we’re going to [crosstalk].”|
|Chris:||I think [crosstalk]. No.|
|Danny:||He obviously hasn’t touched Visual Studio in over seven years.|
|Chris:||It’s all good.|
|Danny:||It’s all good. Thank you.|
|Chris:||You know what, it’s actually a good idea. If companies are coming up with that, running into that risk of that restriction, we want to have as many options. It’s really one of those things if people really need it, we’ll do it. Probably not going to be something we’re going to focus on right now.|
|Danny:||You’re now moving over to doing some getting started workshops, another some that we’re throwing on your calendar to help out. I think there’s some other folks who are jumping into the fray as well …|
|Danny:||… to help out. That’s going to be good for you also just to see a couple, you know, more environments, see what people are doing and making the tool even better.|
|Chris:||Making the tool better, getting other folks familiar with the tool, and really getting their thoughts too on ways that it could improve. Like I said, it was designed quickly. It was put together quickly to accomplish a task. We definitely refined it and made it a whole lot better, but it doesn’t mean it couldn’t be even better.|
|Danny:||A lot of products come from scratch in your back. It’s amazing.|
|Chris:||It’s solving a problem, right?|
|Danny:||Yeah, solving a problem.|
|Danny:||Anything else before I let you go and don’t see you for another quarter? Well, I’ll see you I guess at the kick-offs for these things.|
|Chris:||Sure. No, I mean, that’s the basic gist. We are putting together some documentation to better define some of the stuff we’re talking about so it’s not just me rattling this stuff off on a recording like this. We’re actually going to put together some book and some details, so if someone wanted to pick this up, they could understand it in much more detail.|
|Danny:||I get request all the time from folks in foreign lands asking for this as a product and I know right now it’s still a fluid thing, but maybe even- … I’m not saying we would never package it up as a product, but for right now, I think it’s best we’re doing the services along with it and then including the tool itself until we get it to a point where we’re happy with it.|
|Chris:||Yeah. We talked a little bit about being able to monitor exceptions, monitor the … I mean, I just don’t think it’s at a state where I’d feel comfortable with handing this off to someone and they go run it. I want to be pretty confident that they’re going to be successful with the tool. It definitely requires some hand-holding. It doesn’t mean one day, we’ll just have to wait and see what it looks like and what the demand is.|
|Chris:||If it’s really going to help someone, we’ll make that decision then.|
|Danny:||Awesome. I hope everybody enjoyed this especially if you’re looking at moving from Jive to SharePoint. Just a little update. Probably the next time, I’ll probably just do another update on this. This really helps me because when people are contacting us, unfortunately I’m the first line of defense.|
|Chris:||I don’t know what.|
|Danny:||I don’t know what it does actually but at least if we get an update once a quarter, I kind of can say what it does. This really helps me out, so thank you for taking the time to do this.|
|Danny:||Awesome. We have recently added some intro and outro music to our podcast.|
|Danny:||We’re getting there. I’m slowly putting a spit shine on it. It’s getting there. Thanks everybody for listening. Please drop by our threewill.com site. You’ll see a whole section on migration. Come drop by and let me know what you’re trying to do, what you’re trying to migrate from, where you’re trying to go. Really appreciate everybody reaching out there and have some real good leads come to the website. We really appreciate you taking the time to reach out. Thank you so much for listening to this podcast and have a super day. Bye.|
We’ve been contacted by many of organizations that can’t justify the annual licensing costs for Jive when they already have Office 365 (which includes Yammer for Social and SharePoint for Document Management/ECM).
These conversations have been focused primarily around Intranets – the sites that internal employees use for collaboration. Jive remains a dominant player in building external communities (and from an outsider looking in, it looks like Microsoft is conceding some areas with announcements about no longer supporting Public sites on Office 365).
I had a question from a customer last week about wanting to know the other reasons why to make the move as a part of their business case.
Here’s my initial list of additional reasons –
Speed of Innovation
For many years, Jive was able to run rings around SharePoint because of the three year update cycle of SharePoint. Three years is an eternity when it comes to collaboration, especially social. With the acquisition of Yammer, and probably even more important the adoption on continuous delivery, Microsoft is moving as fast as it’s smaller competitors.
The sales tactic of, “It’s coming in a upcoming version (and it doesn’t come for years),” is no longer being employed. Kudos to the Office 365 team for putting out a clear roadmap – I haven’t seen this level of transparency from a software company.
I didn’t see this coming. Microsoft has been putting out solid versions of Office on iOS and Android. They are embracing other platforms and this strategy is succeeding. Employees can BYOD and Microsoft is enabling their productivity – regardless of their choice of device.
Here’s a quote from Satya Nadella (TechCrunch Nov 2014 article) –
I just think about three things. There are a few other efforts we do, and I’ve been very clear about those efforts and why they exist and why we are proud of them. But, there are three products in all of this. There is Windows, there is Office 365, and there is Azure. That’s it. Everything else to me is, of course, you can call them features, you can call them parts of that, and even there there’s complexity. Do we need to tame it make sure that we’re not inundated by lots and lots of things? But, from a business model, from what moves the needle for both usage and our revenue, those are the three big things that we are very, very focused on.
Thanks to the new CEO, Microsoft has never been more focused than it is now.
What would you add to this list?
Leave a comment below if there are other reasons you would add if you’re having the same discussion internally.
If you’re the more technical type, here’s a great post on making the move from Jive to Office 365.
Migrations are a fact of life for many software products. Updates to existing products you have implemented often require migrations to current versions, and if you have been in the SharePoint world for any length of time, you know the drill. Many enterprise customers are moving to Office 365 and related services, including SharePoint and Yammer, to streamline their IT services footprint. But what about migrating from one product to a completely different product? An increase in customers moving from previous versions of SharePoint to Office 365 and SharePoint 2013 on premises is obvious, right? But we are also experiencing an increase in customers investigating migrating from Jive to SharePoint + Yammer.
With an increase in customers asking about what is involved in migrating from Jive to SharePoint + Yammer, I thought I would quickly describe our processes and some decisions points surrounding migrating from Jive to SharePoint + Yammer. Now, I am not here to argue the merits or shortcomings of Jive, SharePoint, or Yammer – that’s a post for a different day (or maybe never..). This is purely a discussion about our experience with migrating content from Jive to SharePoint and Yammer if your business is investigating a migration or has already made a decision to migrate.
Jive Content Inventory
First, an inventory of all users, places, (Spaces, Groups, Projects, …) and content (discussions, files, attachments,…) in Jive must be completed. Determining what people, places, and content exists is critical to determining where and how this content will be migrated. We have developed processes and utilities that enable us to interrogate on premises or cloud Jive implementations and export all of the metadata associated with Jive content. The interrogation and metadata extraction is all pulled into a SQL Server database to enable iterative mapping and migration passes. This enables us to export the metadata, provide the information to a client, and then facilitate filtering and sorting the data . Once we have reviewed the data with the client, we can create a mapping and migration strategy based on the structure, volume, and type of the existing content.
As with any migration, you want to identify mandatory and optional items to migrate. Part of any migration effort from disparate systems typically involves a mapping of content from one system or product’s entities to the other. In the case of Jive to SharePoint + Yammer, you’ll need to determine the original Jive structure (based on the inventory already performed) and the intended SharePoint site structure. Specifically, you’ll need to map the content from containers (e.g. a Technology Group in Jive) to SharePoint containers (e.g. a Technology team site). In our experience, mapping typically falls into 3 high level categories:
- Jive place to SharePoint web + Yammer group – the intention here is to move a Jive Space, Group or Project to an analogous SharePoint web in it’s entirety. Conversations within or around content in Jive must also be mapped to Yammer groups.
- Jive place(s) content to SharePoint document library – the intention here is to consolidate content including binary documents (Excel, Word, PDF, …), Jive Documents, conversations, and more into a target document library or wiki’s and Yammer conversations.
- Jive place(s) content to lists – the intention here is to move content from a Jive space into a list(s) and documents or other content into document libraries, wiki content, and links (e.g. Project tasks migrate to a Task list).
Finally, migrating content to SharePoint + Yammer can be done in a variety of ways depending on whether you are moving to SharePoint 2013 on premises or in Office 365. For our clients, we have been building up a set of tools and utilities to automate the process, independent of target location. As the image above depicts, content from a Jive Space may be moved to SharePoint in the following ways:
- 1 : 1 – moving all data from a Jive place data into a SharePoint web (one to one)
- Many : 1 – selective migration of content from Jive place(s) into SharePoint webs or document libraries
Typically, one of the above approaches prevails, but there could be a many to many scenario. Although possible, this is something we have not experienced yet (let us know if this is your situation, we’d love to help). However, if Jive and SharePoint were implemented in an enterprise, in our experience there was typically some parity of Jive places to SharePoint sites/webs designed as part of the social integration strategy. At a finer grain level, actual content migration my take the following forms:
- moving Jive binary document content into a document library in SharePoint (e.g. Excel, Word, PDF, etc.)
- moving Jive (native) collaborative documents into SharePoint Wiki’s
- moving converted Jive (native) collaborative documents (PDF’s) to document libraries
- moving conversations associated with documents to wiki pages
- moving conversations associated with documents to Yammer conversations
- moving tags and rating data to managed metadata or list columns
The options above are some for the more common fine grain content mappings, but there are others. Based on our experience, the collapsing of the two products creates business decisions and technical options which are often at odds. For example, converting all conversations around document content in Jive to Yammer conversations and linking these to the content in SharePoint is technically feasible, but organizational and business decisions have typically ruled this option out in favor of speed or simplicity of content migration.
The inventory and mapping processes are usually straight forward, but as mentioned there can be areas which are more complicated. I always like to say “people are messy, technology is easy”. However, this is a case where technically things can get messy too. Jive, SharePoint and Yammer are different products, based on different platforms, with very different purposes. Product implementation differences mean you may need to make some tradeoffs and weigh some benefits and drawbacks when migrating. Below are three of the most common tradeoffs required during migration from Jive to SharePoint + Yammer:
- Content Conversion – Converting some types of Jive content to SharePoint content is a simple conversion, but there are cases where Jive content simply may not map easily to SharePoint or Yammer content. In these cases, the business may need to decide on how much they are willing to spend to convert these data types. Sometimes, deciding to simply exporting a PDF of the content is enough. There will be decisions about what content to keep, what content to migrate and what content requires a cost benefit analysis to migrate. One size does not fit all here!
- Content Relevance – The content, conversation or outcomes within Jive may no longer be relevant or required to migrate to SharePoint + Yammer. In some cases, there is no need to migrate the content at all. In other cases, the conversation and collaboration around the content is not relevant, but the outcome (e.g. a report or sales template) might be sufficient to migrate. Deciding if the primary content item (document, conversation, etc.) is relevant or if the primary and secondary content (conversation, tags, ratings, etc.) are relevant can greatly increase the mapping effort and overall duration of the migration.
- Metadata Migration – For some organizations, maintaining meta-data like author information, creation and modifications dates, tags or ratings from Jive may be essential for historical or compliance reasons. But in many organizations the need to map the associated user accounts, actual creator or modifier, or creating and managing the SharePoint Managed Metadata to map to may be cost prohibitive. In this case, deciding on migrating metadata associated with Jive content might be more about risk avoidance than return on investment.
There are a variety of reasons for migrating from Jive to SharePoint + Yammer, including reducing licensing costs, reducing maintenance, increasing operations efficiencies, deeper Office 365 integration, and more. As I mentioned, my intention here is to describe the process we use for assisting migrating customers interested in moving from Jive to SharePoint +Yammer, not to get into a flame war about which solution is “better”. The process used is important, and we even used what was described above to migrate our own internal content from Jive to Sharepoint + Yammer. Whatever the reason you may be making the switch from Jive to SharePoint + Yammer, if you have questions or comments, feel free to comment below or contact us. We’d love to hear some thoughts on what might be done differently, better, or just have an opportunity to help.
Are you looking to move from Jive to SharePoint/Yammer?
Enterprise social with SharePoint has been a constant struggle over the past 5+ years. There were social features added in SharePoint 2010 and SharePoint 2013 and technically “My Sites” was the answer for social for SharePoint with little to no adoption.
There were many third party attempts to bridge that gap – like Social Sites from Newsgator (now Sitrion). These attempts were typically described as “lipstick on a pig”. I think that is a bit harsh, but bottom line was that third party social solutions were not compelling enough to be widely adopted. As a result of not having a truly viable third party social add-on for SharePoint, many companies started evaluating integrations with purpose-built social platforms like Jive and Chatter. This again was not the silver bullet. These integrations did add strong social capabilities, but they created complications with the overlap of capabilities between the two platforms which caused confusion of “what goes where” across the two platforms. We know these challenges intimately; we built the first generation commercial integration with Confluence, Jive and Chatter with the promise of making SharePoint social.
We know SharePoint Social
If there is an area of expertise that ThreeWill has the most qualifications, it is in social software integration with SharePoint. We have the built first connectors for 3 significant social platforms and have deep knowledge and assets to integrate SharePoint with Confluence, Jive and Chatter.
Now with the acquisition of Yammer, is the problem solved? I would say not yet. The integration story of Yammer + SharePoint is still a work in progress and has left enterprise customers confused and between a rock and a hard place. Enterprises with SharePoint now do not know if they should use the social features in SharePoint or wait for better integration between Yammer and SharePoint (this integration is quite lightweight at the moment). We are very excited to see what will be shared at the SharePoint Conference in March. We believe that Microsoft should have a clearer picture by then.
So why all the fuss about Social + SharePoint? I believe it is all about awareness, engagement and adoption. I once heard from a very wise person (who will remain anonymous for the purpose of this post) that “Content is not king, awareness is!” I thought this was a great insight. You can have all the content in the world, but if there are no eyeballs on this content, it will have very little value to the organization.
Why have My Sites not been SharePoint’s answer to Social?
What has proven successful in social platforms is the activity stream and how that activity stream can be adjusted to dial in the visibility to the right activity. That is, in a timely manner showing you activity that matters most to you in the role you play and the people you interact with in your job.
My Sites have been an attempt at this, but never made it to the landing/home page for the organization. My Sites are usually just another site and typically just a site the IT folks would use along with a few power users. My Sites were rarely rolled out to the entire organization successfully. Even if it was rolled out, I have never seen it rolled out as the landing page in SharePoint. For the landing page, organizations would typically deploy more of a site map that would have announcements and links controlled by a very few set of administrators or site owners. There was not much you could do as a user to get the attention of others on the landing page of the site.
With social and activity streams, the user with knowledge, insights and ideas can now get the attention from others and have a better chance at making an impact on the organization. My Sites have not delivered an effective activity stream. Even if you would visit your My Site, you rarely would get social interactions and awareness of new things that might interest you or be of value to you.
The biggest shortcomings of My Sites is that they were not “front and center” and did not naturally produce a healthy activity stream that made you aware of the content that mattered most to you.
Social platforms have been the latest answer to driving awareness to content. Social attracts people into a place that can be the “digital” water cooler where organization’s can share the ideas that are locked up in document repositories. Content grows in value as you increase the number of people looking at and contributing to the content. Social features like comments, ratings, likes, shares, etc are the mechanisms that amplify the signal of awareness and drive better adoption of the systems that contain your enterprise content.
So what is the key to Social + SharePoint? We think it is making sure the integrations of social systems are seamless and simple as possible. The more complex the integration is for administration and end users, the higher probability of low adoption or no adoption. Also, the user should not have to be trained on how to use the social integration features, it should be natural. It should use the user interface design patterns that are getting adoption in other systems.
Social with Gamification
While we are on the topic of social, gamification is becoming an exciting aspect of how to keep a company focused around goals and desired behaviors when interacting in enterprise systems. ThreeWill is excited about how gamification can be layered into SharePoint solutions. It is a great way to create formal narratives around the behaviors you want to encourage and reward in your organization. The approach of gamification has been around for a while and used in the consumer space for years with loyalty programs like frequent flyer miles. But in the past three to five years, you are seeing this applied more to the enterprise in systems like SharePoint.
To learn more about gamification at work, see What is Gamification? | TechnologyAdvice.com
Are you wanting to make SharePoint more social? We would love to hear from you. We are interested to see what others think on this topic. Do you think Yammer will be the silver bullet for making SharePoint social? Do you think social is key to SharePoint adoption?
And the answer is…iframes.
Not too far back, using iframes on a web site was all taboo, but as of today at least three major cloud products have embraced it as part of their integration/customization strategy:
- Jive – Jive apps are hosted on a server separate from Jive and are rendered using an iframe.
- SharePoint – SharePoint 2013 apps render custom applications hosted outside of the application using an iframe.
- Salesforce – Salesforce Canvas Apps render custom applications outside of Salesforce using an iframe.
While Jive is using an iframe approach for apps, I’ll have to let them fall away from the conversation at this point. Reason: Though Jive apps are hosted outside of the Jive application server and rendered in an iframe, you cannot host your app entirely outside of Jive. You must host your Jive apps on a special Jive server. They’re on the right track, and I suspect they’ll be following the others, allowing apps to be hosted outside of Jive.
So, what’s new? What’s the big deal?
- The big deal (for an integrator, admins aside) is that the host application is providing a method for the remote application to issue authenticated requests back to the host. (Sounds like a tongue-twister, and it is. Hopefully the illustration below will help).
Previously, yeah, you could pop in an iframe and render one app inside another, but there was no way for the app within the iframe to issue requests back to the host.
To solve this, Salesforce and SharePoint are both providing two methods for the iframe hosted application to authenticate back to the host:
- Method 1: A login token is included as a query string parameter on the url source for the iframe. The remote application performs some manipulation of this login token and then uses it for calls back to the host.
- Method 2: A certificate is shared between the host and remote applications. In SharePoint, this is called a high-trust application. In Salesforce, it is called the SAML Bearer flow.
Let me start by illustrating a simple example for how an integration might work, using Azure.
In the example below, a SharePoint 2013 app hosted in Azure is being used to render Chatter feed contents from Salesforce. I could argue that this approach is acceptable and is approximately what we might expect., but it has some significant disadvantages:
- Requires identify mapping for calls out to Salesforce.
- Requires that the UI rendering of the Chatter feed be duplicated, re-coded, in Azure.
So, let’s get rid of Azure. I like the concept of Azure, and I’d like to brag that I’m using it for an app, but it may just be creating extra work.
Salesforce, like many platforms, has it’s own method for customization called Visualforce. Visualforce pages are a lot like asp.net pages and are nearly as powerful. So, instead of hosting our app in Azure and then connecting to Salesforce, let’s host the SharePoint app directly in Salesforce.
- Identify mapping is not required because the user is directly authenticating to the iframe hosted in Salesforce. (Note: Salesforce is typically configured with Web browser SSO, so users do not need to manually authenticate.)
- The Visualforce page, hosted in Salesforce, can use many of the Chatter building blocks so that the UI/html need not be recoded in a middle tier, like Azure.
And, btw, since Salesforce has it’s own iframe apps strategy, we can reverse this pattern for hosting a SharePoint app within Salesforce.
So, this looks pretty good on paper, but it may or may not be a reality for all integration projects, today. There are going to be good reasons for including a middle tier like Azure, so I wouldn’t want to rule it out, but there are some advantages to a more direct connection.
Some questions to consider when deciding if a middle tier is beneficial:
- For both Salesforce and SharePoint, some server side coded is required in order to process the login token provided on the url string. Can the remote application provide the processing required?
- If using certificate based authentication, can the remote application access a cert and sign a request.
- Is SSO configured for the remote application or is the manual login process acceptable?
In summary, this method of integration seems highly useful, and I’m expecting to see more of it in the future (e.g. Jive).
And, if we agree that cutting out the middle tier, Azure, is a good idea, then I think we’ll see more integration projects which require us to be coding in the native language:
- A drop box integration with SharePoint may very well be coded in the technology native to Dropbox.
- A YouSendIt integration with SharePoint may be coded in the technology native to YouSendIt.
- And as illustrated above, a Salesforce integration may be coded in the technology native to Salesforce.
Have you noticed any other trends in cloud integration? Leave a comment below if you have so we can discuss.
ThreeWill and Microsoft
ThreeWill has been a Microsoft Partner pretty much since we opened our doors in 2001. They have been a great company to work with and there have been a couple of key people that have made a big difference in the success of ThreeWill. This month we want to highlight one of those people – Owen Allen (LinkedIn, Twitter).
Our Introduction to Owen
For those of you who don’t know Owen, he used to be in charge of the SharePoint ISV ecosystem for Microsoft (his official title was Sr. Product Manager – SharePoint ISV Partners at Microsoft). And, yes, it is “used to” because he left Microsoft last year to start his own company (more about that later). We first started working with Owen when we were finishing up the initial version of the SharePoint Connector for Confluence. Although Owen wasn’t the one to introduce and recommend us to Atlassian (thanks to Lawrence Liu and Deb Bannon for that), he was the one that showed us the support we needed to grow and go after SharePoint Product Development opportunities.
As many of our readers know, we have been fortunate to work with some pretty fantastic companies through the years, one of the biggest highlights has been Jive Software (another account referred to us by Microsoft). During the design of Jive for SharePoint, Owen met with us a couple of times and provided great input on the integration. He was able to provide crucial guidance about which platform aspects were safe to incorporate on and which were safe for us to extend. It was helpful to get his insight on the integration and have him provide a sanity check. He’s worked with so many varied companies to provide strategic guidance on SharePoint that having his input has been invaluable.
Connect, Extent, Build On
Tommy and I attended the SharePoint Conference in 2008 where Owen had a presentation on building products and the SharePoint Ecosystem. One of the key concepts, Connect, Extend, Build On – stuck with us. This probably happened because we could classify almost all of the work that we were doing with SharePoint into these buckets. It made a lot of sense to us. In the weeks following the session and after a few conversations with Owen, it was apparent that we both were thinking of writing a white paper on the topic. Here’s the result of that collaboration – Benefits of SharePoint 2010 as a Product Platform White Paper. To this day, we have 3-4 people download the white paper each day.
Starting SharePoint Directions
Owen has quite a following in SharePoint circles and he is highly regarded as the go-to expert on the SharePoint ISV ecosystem. So, as he parted ways with Microsoft last year he had many options to choose from for his next move. Fortunate for us, he decided to start his own company, SharePoint Directions. This has allowed us to work together with ISV’s and product companies. Owen is a master at the strategic (and tactical, if needed) moves required for product management decisions to be made. And ThreeWill loves to work with people like Owen — his skills complement our implementation skills and our passion to ship new product features and successful field deployments.
Owen is a ThreeWill Hero – he understands what we do and where we are going better than anyone else…like a number of the other ThreeWill Heroes, he has been a strong advocate for us through the years. Everyone at ThreeWill wishes him continued success with SharePoint Directions. I have no doubt he will – please take a minute to learn more about his services at his website.
More About Microsoft
There are a lot of people that we could recognize at Microsoft as a ThreeWill Hero. Anyone from our current Partner Account Manager, Jason Jones, to our good friends Rob Bohm and Emilio Matt (we love you guys 😉 ). We’re grateful for the years of commitment from people at Microsoft. We feel lucky and grateful to have the chance to ride the SharePoint wave that has been building for years.
A Word From Owen
Owen had the following to say about being recognized as a ThreeWill Hero…
It has been a pleasure to work with ThreeWill, and I’ve always been happy to represent them as a development company with integrity when other software companies ask about them. ThreeWill understands that helping software companies build a SharePoint-compatible product that can be shipped is different than helping a SharePoint customer with an implementation. It requires a slightly different approach to the project. The focus has to be on the long term sustainability of the product and has to take into account the culture of the client with much more depth. ThreeWill gets this, and works hard to work well with software companies. I look forward to seeing their list of clients with SharePoint integrations continue to grow!
Thanks again for being a ThreeWill Hero Owen!
ThreeWill has been fortunate to work with some of the most innovative companies in the world through the years (including Atlassian, Informative Graphics, Accordent and JackBe, to name a few). But, perhaps there is not a better example of an innovative company than Jive Software. They lead 3 of the Gartner quadrants for Social Software in the Workplace, Externally Facing Social Software, and Social CRM. This month we would like to recognize Bill Lynch, Jive Software’s Co-Founder and a Vice President of Product Management, as March’s ThreeWill Hero.
[cb type=”person”]Bill Lynch[/cb]
The most innovative companies have the brightest and best working for them – this usually means that they are not willing to go outside their organization to be successful. Much like our hero from last month, we need to have someone that is willing to give us a try. That person was Bill Lynch.
A lot of things led up to us working with Jive Software. One of the most important was the work that we did with Atlassian for the SharePoint Connector for Confluence (read How We Did It coverage from the SharePoint Product Team blog). Jive was looking to take a similar approach for a SharePoint connector for their product. Fortunately for us, they were willing enough to look for an outside partner for help.
Support To Be Successful
It’s safe to say that building “world class” integration between two complex software platforms could be one of the most difficult ventures out there for software development.
Although we had a leg up experience-wise with the integration that was built with Atlassian, we still had a long road ahead of us. Bill had the patience to see this integration come together and in general the whole team at Jive treated this as a team effort. Throughout the development phase we worked as one team (even through the stresses of release deadlines). This is the recipe for success for a successful endeavor between two companies. We have transitioned off our development efforts to their capable engineering teams and today we are focusing on making sure that the integration is successfully deployed to the field with our Jive Packaged Services offering.
Building On Strengths
As with Confluence, there is plenty of overlap between SharePoint product features. The difference with Jive (as we would soon find out) is that people fall in love with their product. And with Social, this experience of falling in love with the accompanying high adoption is key.
At ThreeWill, we believe that using SharePoint and Jive together is a great solution for a lot of enterprises – especially for enterprises that demand “best in class” solutions. But, in a world of limited enterprise funds of course there are times in which the two products compete. Sophisticated buyers recognize that both Jive SBS and Microsoft SharePoint are platforms with their own strengths. It’s been a blast to see companies that are putting Jive (with its refined Social UI and branding options) together with SharePoint (the “Swiss army knife” of ECM platforms).
Bill has also looked out for us as a company, providing sound advice and even making introductions to other companies. A great case of this was an introduction last year to Zvi Guterman of Cloudshare. These introductions have helped us grow and thrive through the years and we are grateful for the doors he has opened for us.
Humbly Confident = “GNAC”
When you work closely together on a product you get a sense of whether there is a cultural fit. On one occasion, Tommy and I were talking to Bill about how it was important for us to find “humbly confident” people for ThreeWill (we were probably talking about Chris “Bazooka” Edwards). Bill related this to a similar Jive value – a “GNAC”. This stands for good natured a** kicker. Love it.
Today (and Tomorrow)
Jive is making bold moves today and we can’t wait to see what is in store for the company through the next couple of years. We’re excited about the upcoming version of Jive and the new opportunities for developers to build on the Jive Platform. We have no doubt that it will be a wild ride and we look forward to being a part of that journey. Bill, thank you for your support through the years and the trust that you have put in us.
SharePoint Conference 2009
It was great to see people in the SharePoint community (fellow partners, customers, and consultants) and we enjoyed supporting the Jive Booth (showing off Jive’s SharePoint Connector that we built with Jive).
A highlight of the conference was hearing Owen Allen, Sr. Product Manager for SharePoint ISV Partners, present “SharePoint as a Platform”. Owen said there has to be a perception change from “SharePoint as an Application” to “SharePoint as a Platform.” What we heard (from the conference and with discussions with Microsoft) is having ISVs and Enterprises connect, build, and extend SharePoint is critical to the future of SharePoint. Connecting, building, and extending “validates” the platform and the new features of SharePoint 2010 (see Kirk Liemohn’s Top 10 SharePoint 2010 features) will continue to maintain SharePoint as the best in breed web portal platform.
At ThreeWill, we have seen “SharePoint as a Platform” since the inception of SharePoint 2007. We have struggled with Microsoft backing that story (it has been more support for “SharePoint as an Application”). Steve Ballmer said early on with SharePoint 2007 that SharePoint is the new OS, but I think he was planting a seed to be harvested later and we think that time has come.
We are excited about delivering solutions built on top of the rich SharePoint API. The set of features that will be available in 2010 will be overwhelming. We look forward to helping our clients understand which of these features best map to their business problems. That being said, we see that SharePoint 2007 is a strong foundation and the development techniques (like Silverlight, AJAX, RESTful Web Services, and JQuery) we use today map well to the upcoming features and put us in a great place to take advantage of SharePoint 2010.