It can happen that somehow your central admin site is gone, detached, not there anymore. Do not panic. There is an easy solution for it. Check out the video and be happy again!
There's an interesting program related to SharePoint called the Microsoft Certified Solutions Master. It makes yourself a master related to SharePoint solutions and the amount of exams you have to do to earn this title is although doable, it is quite an impressive list. This post takes you down the road of the needed information concerning some of the training materials out there to learn and earn this new and exciting Microsoft Title.
SharePoint 2013 Training for developers
SharePoint Training videos for IT pros
Creating a SharePoint 2013 Development machine is not a very complex task, if you know what you want and where you want to use it for. Valid questions are: am I only going to create server side code? Do I want to create Apps for my corporate catalog? Do I want to create Office Apps and use Office 365? What kind of client tools I want to use? And more questions can be asked. Through a video and some articles I want to show you how you can be up and running in no time with a solid and sound basic development environment for SharePoint 2013.
In some articles in this post you'll find some Hyper-V information for creating VM's to host the machines. In a previous post I showed you information about how to deploy SharePoint on Azure. So, the hyper-V information can be translated to the Azure information and the picture of deployment is complete.
Setup the development environment for SharePoint 2013
How to: Set up an on-premises development environment for apps for SharePoint
Setting up a SharePoint 2013 Development Environment 101
SharePoint 2013 Development Environment
Apps for Offcie and SharePoint Dev Center
SharePoint 2013 Manager on CodePlex
Sahil Malik SharePoint 2013 Development Machine
You hear a lot of things around IaaS, PaaS and SaaS and SharePoint is very attractive as a SaaS solution running on PaaS which is build on IaaS. This can be done in different ways and with different complexities. In this post you learn how Windows Azure IaaS can support a small or large SharePoint infrastructure, including the newly released SharePoint 2013 gallery
image along with PowerShell to automate.
Lets dig out something from Paul Stubbs
Here's another post on SharePoint Deployment on Windows Azure Virtual Machines
How you can make PowerShell work is explained in this post:
You can automate Windows SharePoint deployment with PowerShell:
SharePoint on Windows Azure Series
SharePoint on Windows Azure pricing
Office Business Applications (OBAs) are a class of enterprise composite applications. They provide solutions that integrate the core capabilities of back-end business systems with the widely deployed and widely used business productivity services and applications that constitute the Microsoft Office System. OBAs implement business logic that is maintained through end- user forms, providing a rich user experience that can help to improve business insight and assist in integrating existing internal or external systems.
OBAs usually integrate with new and existing line-of-business (LOB) applications. They leverage the rich user interface (UI) and automation capabilities of the Office clients to simplify complex processes that require user interaction, and help to minimize errors and improve processes. Effectively, OBAs use the Office client applications to fill the gaps between existing LOB systems and users.
OBAs can vary from the very simple to extremely complex custom solutions. OBAs generally incorporate one or more common patterns. One of those patterns is Document Integration. These applications enable the generation of Office documents from LOB applications; enable information workers to embed LOB data in Office documents by interacting with LOB data while authoring the document; and enable server-side processing of documents containing LOB data.
Document Integration applications enable the generation of Office documents from LOB applications; enable information workers to embed LOB data in Office documents by interacting with LOB data while authoring the document; and enable server-side processing of documents containing LOB data.
The Document Integration approach supports four different integration patterns that use XML to pass information to and from LOB systems. The simplest is the Application Generated Documents pattern. In addition, there are three Intelligent Document integration patterns: the Embedded LOB Information pattern, the Embedded LOB Template pattern, and the LOB Information Recognizer pattern. The following sections describes the Embedded LOB Information pattern in a simplistic way to get you on the road.
The Intelligent Documents Embedded LOB Information pattern is where LOB data is embedded directly in the body of the Office document, or embedded as an XML document part and exposed through a content control. Alternatively, the Office application can use the Office Custom Task Pane (CTP) to display LOB data that an information worker can browse or search, and embed into a document.
Email is by far the most popular program used in organizations. Huge amount of information is saved in Outlook for example, which could be beneficial for lots of people working in a specific organization but also for people outside that organization. But how often doesn’t it happen that you are looking for an email and it can’t be found? Or how often doesn’t it happen that you are looking for information when working with Excel or Word and you cannot find it or doesn’t even know where to look? In many of those occasions its email information you are looking for when working in Word or Excel or Outlook itself. In many occasions also you are looking for information from emails of your colleagues and looking or phoning for it costs us a lot of time. Time is money. Searching for the right information can be translated to a lost of money for the organization. Let us look at a very simple overview of this lost of money.
What you can see is that when we have an organization with 100 employees and when these people search for information 15 minutes a day, then this will costs us 15000 dollars a month. Every minute we save on search will save us big money. By the way, it is not unusual that the 15 minutes are 30 minutes or more. When 30 minutes or more we are talking about 30000 dollars or more the search for information will costs us every month. If you throw 30000 dollars against a good search solution company wide than I can guarantee you that it is possible to implement a nice solution which will save you lots of dollars. When we talk about 30000 dollars a month search costs, then in about three months you can earn back a search solution of 30000 dollars (we will not have the full 100% profit of course, so no pay back in one month). Do the math. What will this save you in a year? What will this save you in 5 years? Yes, a lot of money and frustration. Let us look therefore more closely to a solution where we can more easily find our email from all our business applications and that email is put into Sharepoint. Of course it is possible that you can think about another server product when I mention Sharepoint, but in this blog Sharepoint will be used as the example server product and the Office applications Word, Excel and Outlook will be used as the client applications in this example.
Let us look at some possibilities to create controlled information in Sharepoint 2010. How can we manage metadata and taxonomy management in Sharepoint? What this does is making it possible to create surrounding information and some sort of indexed information to make it possible to find our stored information in Sharepoint a lot easier. A nice article is written about this matter and you can find it here:
The search possibilities in Sharepoint improved a lot. This means that you can find your information more easily and a lot faster than was the case in previous versions. This can benefit us when we look for information from out our business applications and it can help us finding our email a lot faster when we put it into Sharepoint. A basic article about this matter you can find here.
Although this article will be about saving email into Sharepoint, that doesn’t mean that putting email, Word documents or Excel files into Sharepoint and make them become easily searchable for all your employees is the only possibility. It would be amazingly more productive if you would do the same for all kinds of applications you have in your organization. There are several tools and applications which can help you do just that and the article behind the link below will give you the proper mindset about it.
The picture above is quite useful for my previous blogs about Office Business Applications and hooking it all up together. For a refresher about what Office Business Applications are and what you can do to get all the information out of Sharepoint and into those Sharepoint Office Business Application it’s advisable to read those previous blogs.
If you want to know more on what you have to think about when implementing new Sharepoint related solutions in your organization on the field of organizational Change and Change Management, then these articles will give you a nice starter:
Let’s move on and get back to our main concern of this article: how do we get email easily into Sharepoint and how can we access that email easily from out our other Sharepoint Office Business Applications? The solution discussed here can be used with Sharepoint on premise and with Office365, the cloud version of Sharepoint 2010. This means that you can save your email in both versions of Sharepoint and make the finding of it an integral part of your Sharepoint Office Business Applications. In other words, you can save your email from out Oulook to Sharepoint on premise and Office365 and when implemented the proper taxonomy, metadata and search configurations as mentioned in the above paragraphs and the given links to informative articles about these matters, then your email will be easily to look for from out all you Sharepoint Office Business Applications like Word, Excel, Powerpoint, Infopath and Outlook itself.
There are two possibilities to approach this: you can make an application yourself to hook up Outlook to Sharepoint or you can buy a solution for it. When buying a solution you can make it expensive or cheap. For this blog one program is chosen as a possible solution to hook up Outlook to Sharepoint which is not expensive, does what we want and is also a great example what your program should look like when you build it yourself. Another great thing it does is showing us how a panel should look like in Word for example when we hook up Word to Sharepoint. The panel used by the program which we use as example is lean and mean and clean. Really a great design and even understandable for a child. I didn’t made it myself but I’m a happy user and a happy user of the free version for private use. This tool can be found here:
What will be shown down here is the tool itself and the integration with Outlook, which is what it does. The pictures of the integration with Word, Excel and Powerpoint are made up by myself to show you what it can be.
This product does a bit more than only making it possible to drop and save email to Sharepoint, but that is something you have to find out yourself. It will not be mentioned in this blog. This blog is going about getting your email into Sharepoint easily and making it findable by all your colleagues and saving lots of money doing so. There are two great things possible with Harmon.ie and that is dropping email onto the panel and saving the email while you are sending it, included are the attachments. Of course you have a choice. You don’t have to do the saving of the email if you send it, but it is given as a possibility.
Another important thing is that someone has set up the proper file and folder structure in Sharepoint. While the email is dropped into Document Libraries as document files and email files, it is important that the saving is done in a well known structure with the right metadata and included in some taxonomy and coupled with keywords and a proper term store. When this is done, then the email can be easily found in Sharepoint itself or other Sharepoint Business Applications around Sharepoint, like Word, Excel Outlook, Powerpoint or Inforpath for example. Imagine that every email from everyone in the organization is instantly saved into Sharepoint and also instantly hooked up to the proper metadata, terms, taxonomy and keywords? This is mind blowing and even more mind-blowing when you realize how easily this can be done. It is even so mind-blowing to realize how few organizations have this properly in place and how much money is loosed every single day by looking for email information which isn’t there or just can’t be found.
Harmon.ie has a solution sheet and it presents a possible email solution for you when you choose to integrate Oulook with Sharepoint. This solution sheet can also be used when you decide to implement your own Outlook solution and hook it up to Sharepoint. I think personally that what is mentioned by Harmon.ie in their solution sheet is the minumum you want to have when implementing your own Outlook integrated solution with Sharepoint. I go even a step further by saying that this solution sheet can be used to create the proper requirements for your business case when thinking about an integrated Outlook-Sharepoint solution in your own organization. The simplicity of this solution sheet is remarkable. Even for the abstract thinking people who like the concepts more than the bits and bytes, this solution sheet makes it clear what is needed to create a usable Outlook-Sharepoint integration.
We go a step further in this blog by bringing forward the possibility to do the same with other Office Business Applications like Word, Excel, Powerpoint and Infopath of which Word and Excel are probably the most important. And of Word and Excel, Word is the most widely used within organization. How great would it be if we had the same possibilities in Word and Excel as we can find in the solution sheet of Hamon.ie for Outlook? How cool would it be that when we need information out of the saved email in Sharepoint when working with Word or Excel, that we could find it through some sort of application panel residing next to the document or sheet we are working on? That would be a time saver and a money saver. Think again about the picture I gave you at the start of this blog, where you can see what it can save you if you bring down the search time in your organization. I’m talking about not only a Harmon.ie Outlook oriented integration but I’m talking about a Harmon.ie alike Outlook, Word and Excel integration company wide. That would blow up everyone’s mind and the productivity would go sky high. And this is easily to make and easily to implement.
Why isn’t it already there? This is a valid question. On the one side you have the lack of the proper insight in the mentioned applications and how you can hook’em up and on the other side you have the fact that this integration is just easily possible the last couple of years. In a previous blog I wrote about the fact that we did these kind of things already in the nineties. In those days it was like hacking around and you had to know many different things, interfaces, applications and programming languages to do so. Nowadays this is made easy and with the last versions of Office and Sharepoint it is made childless easy to build, in comparison with what we had in the past and Harmon.ie gives us a great example of these possibilities.
Let us look at a picture of what I have in mind.
With this last picture I want to round up this blog. In my previous blog I talked about how to get information out of Sharepoint and into your other Office applications like Word, Excel, Outlook, Powerpoint and Infopath. What I emphasized in that blog was the use of a loosely couple service layer called Windows Communication Foundation (WCF) or just plain old Web Services. What I didn’t brought forward in that blog was other possibilities like creating connections with external data through Business Connectivity Services and hook that information into your Sharepoint Office Business Applications with External Content Types which exposes that external data. I will write more about that in future blogs but to give you a great overview on this matter, I want to give you a great article about it which I found on the internet:
If you get the information out of this article into your head and combine it with the information given in the rest of this blog, then you will have a clear understanding of how you can put your information into Sharepoint right after you created it and how you can expose that information to other Sharepoint Office Business Applications. We started with getting Outlook information into Sharepoint and make it easily findable from out other business applications and we ended up by putting all your information from out all your Office Applications like Word, Excel, Outlook, Powerpoint and Infopath into Sharepoint and make that information easily accessible through applications panels in these Sharepoint Office Business Applications. As an example I used Harmon.ie, but just to get your mind going on this matter. The last article I gave you is a round up on how you can hookup your Office Applications together with Sharepoint and make it all a happy family of information gathering and information exposing bunch of Sharepoint Office Business Applications, hooked up even to all kind of other information silos at your back end. The starter of this blog gave you another example of this hooking up all kinds of applications to Sharepoint.
Information is crucial for you organization and it happens that finding that information is a costly business. We are in a world where it is possible to put all the information from out your Office Business Applications into Sharepoint right after creating it. This is also true for other kind of back end applications if you use the proper hook up meganisms. When Sharepoint is rightly configured it is possible to find this information instantly from out other applications. This can be done through application panels like the example given in this blog from Harmon.ie. All the employees in your organization will have access to all the information of all people from all applications at all times and in an easily build up way of finding that information through panels in the applications they work with. The flow of information will speed up and the knowledge of your organization will be up to date in every brain cell it has. Let us start by doing business at the speed of light and get it done yesterday.
As an afterthought I want to present to you this final picture:
I will relate the situation discussed in this blog to the proper Change theories in a future blog.
Just….be careful out there.
Longitude Connectors for Sharepoint and FAST search. (2011). Retrieved from BA Insight:
Cawthorne, J. (2010). How Search Has Improved in SharePoint 2010. Retrieved from CMS Wire:
Gilani, A. (2011). Creating Office Business Applications in Microsoft SharePoint 2010. Retrieved from Sharepoint Pro:
Harmon.ie. (2011). Harmon.ie for SharePoint. Retrieved from Harmon.IE:
Hormon.ie. (2011). Harmon.ie solution Sheet. Retrieved from Hormon.ie for Sharepoint Outlook Edition:
Lemieux, S. (2009). Overview: SharePoint 2010 Metadata and Taxonomy Management. Retrieved from CMS Wite:
Meier, J., Homer, A., Hill, D., Taylor, J., Bansode, P., Wall, L., et al. (2010). Chapter 20: Office Business Applications (OBA). Retrieved from Microsoft Patterns & Practices:
First, to get you up to speed on (Sharepoint) Office Business Applications, read this:
Imagine that you are the CEO of a company and you are determining what to do with all your heterogeneous data that is residing
in your company in all sorts of information silos. That is the problem a lot of organizations deal with nowadays. In this blog I will give you on a high level the possible solution to the problem under certain circumstances. This means that there are circumstances which could be different than the ones you are dealing with, but probably you will recognize some mutual elements which could lead to some good ideas in your specific situation. Furthermore, I will give a sketch of the hard and software available in this specific situation and that also could be different than the one you are dealing with. Again: probably you will see similar elements which could lead to great ideas in your situation. Final: it is always possible to create a more similar situation with the one described here by buying in new hard and software.
Let us first see what kind of situation we have in this case. I’m the CEO and I know that I have all kind of data residing in several possible information holders. My managers tell me that this situation costs us a lot of money because a huge pile of information of quite some important value for the company is difficult to access from everywhere. Every department in the organization has its own way of saving and categorizing the data it needs, while this information is also important for other departments. Customers must wait sometimes quite a long time to get some answers. Furthermore: some decisions are not made or badly made because people lack the proper information to make those decisions. Managers tell me that our speed of reaction to the market is dropping and the same goes for our sales numbers. There are more phenomena in the organizations which tells me as a CEO that getting the right information on the right time and with the right speed is the overall cause of a lot of problems we deal with at the moment.
From out strategic considerations I want my company to have the right information at the right time, at the right places and within the right applications. I want my company to be able to react to outside information with light speed and my customers must get answers fast, not now but yesterday. I want the information being accessible from anywhere in the organization and from out every application my employees work with. That’s the only thing I want, how difficult could that be? Well, that’s what we will discuss in this blog and we will not analyze all the possible situations out there, but we will choose one that should be quite common. Let us first see what all the places are where our information can be found.
First of all we see that we have licenses for Microsoft SQL Server and that several departments use that as the information holder. Second we see licenses for Microsoft Office throughout the organization. What is used most is Word, Excel and Outlook. Outlook is our main email client. We have intel based computers and Microsoft Windows is our main operating system. There are some other Unix and Linux machines where we can find some financial and recourse management information. Some of those machines have crucial data on it where our customers depend on. Furthermore there are some Oracle machines with Java as the main language. Also we have some Oracle databases and again: also on those boxes we find crucial information. Last but not least, we have SAP with a huge amount of crucial HR information. My analysts tell me that also crucial data can be found in the email stores. It happens that this scattered email information is crucial in a lot of decisions we have to make. Last but not least, people tell me that the way we save documents is a mess and those documents hold crucial information. Most documents have some sort of Microsoft format, but the documents on the Unix and Linux machines have other formats. There is Microsoft.NET C# and Java as programming languages. This is the situation and it sounds like a real mess to me. Let us look at the picture.
I’m the CEO of this mess and I talked to some people inside the organization about how to get the data at one place and make it accessible for every department in the organization. Among several other possible solutions also Sharepoint came into the picture. The reason for this is the fact that we have a lot of Microsoft products already in place and by using Sharepoint we also will use our sleeping licenses a bit more. With sleeping licenses I mean the licenses which are not fully used or not use at all.
Because Office is our main application, it would be unwise to first invest in getting the people used to another kind of Office like OpenOffice for example. Besides this fact, I also like the commercial model with which we can do good business. Open source is great, but it lacks static versions, the proper helpdesk model and every open source programmer has its own set of tools to hack around. I don’t say this is bad, but I say it is something I do not want at this critical moment in my organization. I want to be able to blame someone if things get screwed up or if software doesn’t work. If you want a real static open source environment, my experience is that you pay big money eventually. At this moment I don’t have that money and still I want this problem solved.
So, I listen to my people advising me to use Sharepoint. I point them wisely to a blog about Sharepoint and Change management and my managers agree that we first have to deal with that. That means, following some sort of model to get our change management structures in place before we introduce Sharepoint. A great blog told us if we don’t do that, that rampage will follow. We don’t want that. The blog also told us that we must introduce Sharepoint top down and not bottom up. Do not give Sharepoint to our system administrators too early in the process or else we will end up with another mess and we already have a mess. For further reading on this one:
Right. We have our change management things in place. We communicated our vision and the vision was: “ We want all our information accessible any time and any place and we want to do that with Sharepoint.” This vision is conforming what other people tell us about a vision. It is short, to the point, crystal clear and people can remember it. Every layer in the organization can understand what this vision is about. See the above links to read about what we have to do after forming this vision. When we dive into the technical things on a conceptual level, we assume that the information given behind the above links is being done and that the first stage is properly in place. If you do the things described in the following paragraphs and you didn’t do something in the form of what the links told you to do before implementing Sharepoint, than you are an unwise CEO and probably one with lots of extra problems in the near future. Don’t let that happen.
Let us continue. We have implemented Sharepoint and we did it with the links about Change and Change Management. We did it top down, we have a guiding coalition, we have all our managers and leaders aligned and we are ready to Sharepoint rock and roll. Now we can give Sharepoint to our administrators after we bought in the proper knowledge about Sharepoint in the form of education or new people. Don’t start the rest of this blog if you did not do that. Let them be certified and let them read the proper blogs and rss channels before you let your people play with the essence of your organization: the information. Their goal is simple: get all the needed information into Sharepoint and make that information searchable and accessible for everyone and every application. It sounds daunting, it is in the basic quite simple.
Before you put the information into Sharepoint, first think about the structure in which you want to have it. That is, how many site collections do you want to have? For which departments must there be a site collection? How many webs are allowed in every site collection? Who is responsible for the overall architecture of Sharepoint? Who is responsible for the architecture per site collection? Are we going to use personal site collections or My sites? What kind of search will we use? FAST search, out of the box search, our own search mechanisms?
What kind of security will we use? Ntlm, kerebos or claims based and what else do we have? What kind of lists will we use? How many content types will we use and what is the maximum complexity level of these things? Are we using workflows? If not, will we start using workflows? For what will we use workflows and for what not? How do we index all our data? What is in Sharepoint and what in SQL Server? How do we do the proper backup? How do we keep Sharepoint fast? And there are many more questions. That is not what this blog is about, but you should have this properly organized before you begin with the rest of this blog. There are many nice places of information and books on this matter and future blogs at this place will dive into these things.
The main topic of this blog is how do we get the data in Sharepoint to all the other applications in my organization if I’m the CEO? It’s about the step after all the decisions of the above paragraphs. Sharepoint is bought, it is in place, it has all the data but that data must flow to all our other business applications. The first barrier we have solved. All the data is now in one place. How it got there is not described in this blog. That will be the topic of other blogs. What we will describe is a possible solution about how to get that information from out Sharepoint into other applications. A part of this solution could also be used to get the data into Sharepoint and when that is the case, I shall mention it. I’m talking about Sharepoint on premise. Future blogs will dive into Office365, that other awesome product of Microsoft rocking the world.
There are two object models of Sharepoint which can be used to get data out of it or into it. You have the Server Object model and the Client Object Model. The big difference is that the Server Object model can be used if you are on the box where Sharepoint itself is residing and the Client Object model can be used if you are on a box other than the one where Sharepoint is residing. The Object models themselves have minor detail differences, but the way you program against it is similar. These Object models could be used to get information out of Sharepoint but also to get information in it. I can imagine that these object models were used when aggregating all the scattered information into Sharepoint in the previous steps.
The client Object model is light weight en general, but for the Unix and Linux machines where Java is king, it could be made even more general. This can be done with another layer called WCF, Windows communication foundation or plain old Web services. The funny thing is that we can make a Sharepoint project in our Microsoft development environment wherein we define a WCF service talking to Sharepoint objects. It’s a service which will reside in the Sharepoint catacombs. In that same solution we could make another WCF project outside the Sharepoint project and this WCF project can use the Sharepoint specific WCF layer. We make a loosly coupled layer around Sharepoint which is not Sharepoint specific anymore. This non specific WCF layer can also be made accessible true plain old Web services and these are even more easy to use in a Java environment. Another huge advantage of this theory is the fact that we can make our own objects which can be made more aligned to our business objects or internal object model. This idea can also be used to get information into Sharepoint.
By doing this we have created a layer which can be used easily by the Java clients on the Unix and Linux machines but we also made a layer which can easily be used by our other office applications like Word, Excel and Outlook. As mentioned in the previous blog at this place, we saw that we can use the Office applications to create Office Business Application where you can access all kind of information from out your other applications. We did that in the past and we can do it still. We also could have used this without first putting Sharepoint in place.
You can make a proper Web service or WCF layer with standard interfaces which access all kind of information layers in your organization, like the Unix and Linux machines. The problem with that solution is that you have to make a huge business layer which hold all the business specific logic to deal with the data. And the information has to be aggregated somewhere and that means extra databases and extra tables, relations and so on and so forth.
That is just the reason why Sharepoint came to existence, among other reasons of course, to have a place where all our business information will reside and which is accessible throughout the organization with all kinds of business rules, workflows and what not. So, we first introduce Sharepoint, put all the information in it in smart ways and then we make that information programmatically accessible to all our other business applications and that is what we are doing now. So, we do not use the Business Connectivity Services while that is also a great tool to get the data aggregated into Sharepoint to be used or shown there or make it available to other applications through for example External Content Types. Instead we use another WCF and Webservices layer to talk to Sharepoint specific WCF objects to present the Sharepoint information to other application and not all of them are Microsoft based. With this technique we can make our own business objects and this also can be used to get information into Sharepoint.
An interesting article about integrating Sharepoint Office Business Applications with Business Connectivity Services and External Content Types can be found here:
We came a long way and we are almost there. The vision was “We want all our information accessible any time and any place and we want to do that with Sharepoint.”. First we’ve put the information into Sharepoint in a structured and smart way and following the blog about Change and Change management and that sort of things, do not underestimate that part. Then we made the structure accessible from out Sharepoint itself with all kinds of lists, content types, workflows and what not. After this step we created a Sharepoint specific WCF layer in Sharepoint projects which is talking to the objects of Sharepoint.
Because we have so many non Microsoft places where the information must also be accessible, we choosed not to use the server or client object model directly but we’ve put a generic WCF and Webservice layer in front of it. This generic WCF layer or Web service layer is easily accessible from Java oriented appplications and those Java oriented applications will talk on our Unix and Linux machines. The financial data residing in Oracle and SAP and all our human resource things also in SAP, can be easily coupled now with our WCF and Web service layer.
Now we have all the pieces to make even the scattered data in Outlook an integral part of our information management strategy. Every email gets saved into sharepoint under certain conditions and this information is instantly accessible from out my other Office applications. The same goes for Word, Excel, SAP and Oracle forms. With my WCF and Web service layers talking to the Sharepoint world, I put all the needed information from all my business applications into Sharepoint after creation. Everything in Sharepoint is accessible and searchable after about 5 minutes when it is inserted. For every application I have in every department in my organization this 5 minutes thing will be the case. No document, no email, no worksheet, no SAP form, no Oracle forms entity really nothing is there that is not connected to Sharepoint through the WCF and Web Service layer and everything talks with everything. Don’t forget that behind that WCF and Web Service layer is the server and client object model of Sharepoint.
Let is look at the new picture.
This is amazing. All the intelligence is in Sharepoint and the WCF and Web Service layer is nothing more than a passing through point of information. All the smart lists, workflows, content types, taxonomy and what not, is pulled out of the scattered applications, pushed into Sharepoint at a central place, and made useable and accessible through a light weight WCF and Web service layer. With this it is even possible to hook up business to business solutions together with your clients and customers.
Of course the picture looks more simple than reality will be. But when we look at the basics of the problem, then this last picture is indeed what it should and can be. A very important piece of equipment you need as a CEO when doing this trick inside your organization is having the right knowledge at the right moments. It is smart to start with an investigation of your knowledge base. Don’t be afraid to do that and don’t be afraid to pump it up. Tune up your organization when dealing with these kind of transitions. You will be knocked down when you start the rounds without proper training of your people. The bell will not save you and your organization will be kicked out of the main ring.
This is common sense but this common sense has become a bit more complex than it was in the past. So this common sense must be trained and feed with the proper knowledge. Look at the pieces in the picture, read the things mentioned in this blog and especially read the link about Change and Change management and this will be your roadmap to knowledge. If you as a CEO can say that every piece of information needed and mentioned in this blog is covered with knowledge, than you have your team ready. Read the paragraph where I mention basic things about Sharepoint, the knowledge about lists, content types, workflows and what not and buy that from outside or get your people on that level. They need it when importing and structuring all the information from out all your scattered information silos.
After that you need the proper knowledge to keep Sharepoint up and running. And you need the knowledge to make the WCF and Web Service layer. If you have great designers who can dream about the proper UML diagrams and who can do magic with C#, WCF, Team Foundation Server and Visual Studio in combination with the Sharepoint object model, then you are King. Don’t you have this in house? Buy it. Don’t you have it and you cannot buy it? Don’t start with this and put your energy in getting your organization at the right level.
Make this picture your goal and keep up that vision “ We want all our information accessible any time and any place and we want to do that with Sharepoint.”, which could be your strategic roadmap for the coming years. Start hiring brains now to get you there in the future. This blog was about Sharepoint and if you think about totally other products to do this, I think the essence stays the same. My experience is that Microsoft at this moment has one of the best decks of cards available with an impressive code base. This can work in our financial favor and it could mean organizational stability in the future.
Get your scattered data at one place and knock’em down.
Just be careful out there.
A. (2011). Creating Office Business Applications in Microsoft SharePoint 2010. Retrieved from Sharepoint Pro:
Back in the days of the nineties we made office business applications with all kind of different software products. That was fun but difficult. What we always had in mind was making a layer of office applications around some database, financial system, human resource management system, document management system, an archive, databases, legacy system and so on and so forth. In the days of Clipper, DBase, Ansi C, C++, Visual C++, Fortran, Pascal, Visual Basic, Java and what not it was a matter of hacking it all together and end up with something way to complex and not maintainable. But every business wanted to have it and lots of organizations bought it. Happy us, sad for them.
Then came Microsoft Office from 1993 and on. It conquered the world and that was good. The same is true for Visual Basic, Visual C++, Visual J++ (yes, a lot of things were possible with this card of the pack) and VBA (Visual Basic for applications). The world became a bright place. A lot of things on the Office Business Application front could be done which couldn't be done before this pack of cards from Microsoft; at least, not in the same RAD (Rapid Application Development) way. I don't want to start the discussion here as if RAD was always great. It wasn't and a lot of bad coders made a mess of it. But that doesn't make the pack of cards bad. People who play bad poker even make a gold pack of cards dirty. The same was true for Visual Basic and VBA. Buying cheap means ending up expensive. Organizations bought the bad coders themselves out of greed. Don't blame Microsoft for that.
Let's move on. A great era began and there were tools to make great Office Business applications where the front-end consisted out of the Office Applications Word, Excel, Powerpoint and Outlook. The backend could be everything, from archives, document management systems, financial systems and what not. It all could be unlocked through a similar and for everyone well known interface. The fact that there was VBA made it possible to program everything in the Office Suite and make it talk to whatever you want; if you knew what you was doing of course. Lots of organizations. began to develop house styles with macro's and VBA code and it all looked great. Imagine that you can access all the data in your organization, in the legacy systems, in email, in your database, in the financial systems, from customers and business partners from out your Word interface, Excel or Outlook. This was mind blowing!
But still a lot had to be done. You had the Office pack of cards from Microsoft but at the back end there still was everything you could find. This meant that you still had to program against dozens of interfaces and all with their own characteristics. Times were better than before but still big time tooth hand string programming and putting it all together. Till the end of the nineties and the beginning of the new millennia this was what we had and we did great things with it. Thanks to Microsoft, let us not forget that. If this pack of cards wouldn't have been there, then a lot of great office business applications could not have been programmed and certainly not for that price and not with that efficiency.
After that came Microsoft.Net and some server products like Sharepoint, Biztalk, content management server and some others. All had the goal of being open interfaced and easy to program at. The new line of coding languages made it possible to integrate the office products more easy than before. The Office products could talk to .NET code and with .NET code you could do everything. Sharepoint could be used for collaboration and document management, Biztalk for the business processes and content management server for content management. Let us not forget Outlook which became a lot easier to program against (true, in the beginning of the new millennium still a bit rusty and difficult) and the new SQL server line was more mature then the versions before.
All in all Microsoft offered a more attractive pack of cards than it had in the nineties. With this pack we were able to make very attractive and usable office business applications where Word, Outlook, Excel and Powerpoint were the king entrance to whatever laid behind it. Later in time a new member kicked in called Infopath with which we could make really great forms with some intelligence in and around it. These forms could be used as simple data getters, transformers and pushers to the backend and all done with ease. Still, bad coders are everywhere and if you don't know what you are doing and why you are doing it, than you can make even a mess with lego. Again, don't blame Microsoft for your own resource management problem: buy better coders, architects and consultant and you get what you want.
The world became a better place to be in. Microsoft had what it takes to do what was needed: making great office business applications that could deliver. The Visual Studio pack of cards became mature, the Software Development Life Cycle Management tools became more mature in the form of Team Foundation Server and all kinds of language additions and smarties were added to the .NET pack of cards. Later on we could even program in .NET C# inside the Office pack and a Word or Excel document became things like the Windows Forms entities, with the same characteristics, control and possibilities. With all these additions and development, also the ongoing development of Sharepoint, Biztalk, Team Foundation Server, Visual Studio, Infopath and the Office Suite the world of Office Business Applications became mature and words with starting capitals.
This is where we are now and this is what I shall write about. Not the past things that were done and could be done, but the things that can be done now, with Office, Sharepoint, Biztalk, Visual Studio, Team Foundation Server and SQL Server. What are the possibilities of Office Business Applications in relation with Sharepoint? Because that will be my main focus. I also want to relate this to change management issues and what Office Business Applications in combination with Sharepoint can trigger in the world of change. How do OBA's change the organization? How do OBA's change the way people work in the organization? How do OBA's change the way people work together in the organization and how do OBA's change the way organizations will work with other organizations? Not only shall I make clear what OBA's are and how the pieces in it are related to each other but I want to embed this in the changes it will cause within organizations.
It is a bit strange to create such a 'hard' blog on a 'soft' site going about change management around Sharepoint implementations. You will not see code when dealing with Office Business Applications on this site. It will all be on a conceptual level. With doing this I shall try to make it easy to get a grip on it. The reason why I want to write about OBA's on a conceptual level on this site is because I want to make the strategic brains more aware what can be done with the combination Office and Sharepoint and what the changes are that must be analyzed when implementing Office Business Applications. The power of this combination, Sharepoint and Office (and Biztalk) is so immense powerfull and usefull, that it would be a missed change not talking about it and not making the strategic minds aware of this great oppertunity. It is important that those strategic minds have enough knowledge about the Office Business Applications opportunities with the Microsoft pack of cards to place it where it belongs when making strategic decisions for their organizations: in the front seat of the car of progression and innovation.
Last but not least I want to present a picture of the compilation I'm talking about. Don't panic, after the blogs that come I promise that this picture will be as easy to interpreted for the strategic minds as it is for the operationals among us:
What you see is organizations with the Office applications Word, Excel, Outlook, Powerpoint and Infopath which are fully integrated and presenting an interface for business workers to Sharepoint, Biztalk and other external and legacy systems. The business workers work with applications they know and they don't have to change how they do things. Meanwhile there is a lot of business logic integrated into the Office applications and together this logic is integrated into Sharepoint, Biztalk and Powerpoint. Together these applications can form a very intelligent Office Business Application serving all the layers in the organizations. Think about the financial department, the human resource department, the contract department, the development department and whatever departments you want to integrate into your overall solution.
The people working with this overall Office Business Applications are also working with Sharepoint without knowing it if their standard applications are the interface, like word, Excel, Outlook and Powerpoint. Infopath can be used to develop intelligent forms to create access to Sharepoint, Biztalk, SAP, Oracle, SQL or what not. If needed, application pages or server pages could be made in Sharepoint to add and combine a specific Sharepoint interface to the interface of the Office Applications. We can also create smart panes, menu's and panels into the Office Applications themselves which could form jet another way of accessing Sharepoint, Biztalk, SAP, Oracle or other legacy systems. With Sharepoint Business Connectivity Services we can integrate many other external sources into the overall Office Business Application and this all can communicate with other organizations having the same integrated solution. Sky is the limit. The pack of cards is ready to shuffle and with the good players, great Office Business Applications can be made.
Let us start!
Jaap Zwart MA, MSc, BICT