I’ve got tons of exiting stuff to share, and will be doing so over the next few weeks. 

Here’s a sampling of the very broad range of things on my topic plate:

From the simple:  Defaulting a target audience in a SharePoint Calendar – another low hanging fruit for Microsoft that they missed?

to the industry focused:

The looming EMR crunch for small businesses and doctor’s offices.  It’s time to finally get on board with electronic medical records.  Is your facility or office prepared? 

Midwest game production and development companies are still rare.  In the state that houses the “video game capital” of the world why isn’t there more production talent in Iowa?

The next big things for the Des Moines market.  What and or who will get this economy rolling.  Will Finance and Insurance continue to dominate the big business climate of the city, or will there be other unknown players emerge?

To a candid conversation:

What does a consultant do really?

When pitching or developing a solution it is very important to be able to quickly create compelling prototypes that can make people excited about an idea and advertise what we can do in an effective manner.  Prototypes need to be cost effective and give that immediate business value-add.

Many of us when we create design do it at a time when we really are not paid for the initial stages of that design; we have to answer to an RFP or in a corporate setting we have a proposal that hasn’t been approved yet. 

In the past, getting the design right meant a fairly labor intensive process that involved a lot of administrative overhead on the part of the designer / developer.    So much overhead in fact that we often leave RFPs with a very simple high level design represented in a single Visio diagram, or textual explanation. Prudence dictates that spending the time may not be worth the effort or there isn’t enough time on top of billing for other projects to get the level of design that we need.   Often times we require the client to trust us to get the more detailed design correct after they’ve hired us based on a simple high level design or references where we’ve completed that work in the past.

Even when we get into the detailed design of a project we have struggled with quick prototypes.  On a past project we used Visual Studio and actual asp.net pages and controls to model the design.  It was thought that we could then more quickly transition the design into the actual application. The pages were static representations of how the page would look in the application with no actual wiring, no interactivity, no state transitions, and minimal style queues.  We would then take a screenshot of each mocked up page, group it with a set of functionally related pages, and present them via projector at a joint application design session with the end users.  During the sessions we would cycle through each page getting feedback on each page while we marked up the screenshot with what was essentially Paint-like tool.   We then would iterate through the process again.   When we all agreed on the functionality of the page we then cut and paste the final iteration of the screen into the Business and Technical requirements documents for additional review.  

Overall this process worked, but it was very labor intensive and not quite agile enough.  More importantly however it presented challenges when it came to the overall flow of the application and getting things consistent in terms of styling and control use which in turn produced many downstream discussions.

Fortunately today we need not go through much of the same troubles and headaches involved in that process.  With the introduction of SketchFlow in Expression Blend 3 we could save time by orders of magnitude and produce better design.  SketchFlow is a prototyping tool that encapsulates everything we were doing in our old process and makes it much easier, more intuitive, and leads to better design.   

Christian Schormann, the Group Program Manager for Expression Blend, gave a one hour overview at the MIX09 conference of how SketchFlow in Expression Blend 3 works.  I recommend watching it.

 He shows that a great design process can help to:

• Communicate design ideas fast and efficiently
• Communicate the value of Sketching and Prototyping
• Explore a multitude of ideas rapidly, timely, inexpensively 

He also shows how SketchFlow supports the idea of an evolution of design.

• Quickly experiment with dynamic UX
• Fast, plentiful, disposable, inexpensive – Significantly lower cost for design exploration
• Communicate design intent
• Present, Collect and evaluate feedback
• Provide immediate business value
• Deliver compelling proposals to clients quickly and cost effectively – Make prototypes real with navigation, data, behaviors
• Fast and easy prototyping – Evolve from storyboards to rich prototypes

One of the great design elements of SketchFlow is that it comes with sketch fonts and sketch like controls that can be used to represent the design concept.  

It’s important not to mock up models that are too technical from the start.  That is, placing your navigation, buttons, and other controls as they would be actually rendered on the initial design.  Doing so makes the stakeholder focus on the actual rendering of those controls and not the overall feel and flow of the application. 

Another feature (and one of the most important ones) of SketchFlow is the feedback collection tool.   Enabling integrated feedback speeds up the iteration process while ensuring adequate stakeholder buy in.  There are two key parts to feedback in SketchFlow.  The first being that the design can be sent o stakeholders which they can preview in a preview window or on a website and note their feedback directly on the page or SketchFlow player.  This cuts down on administrative and meeting time.  The second key component is that that once stakeholders send the feedback back to the designer the designer can overlay the feedback on top of the design to assist in making the changes.

The SketchFlow player is not part of Expression Blend; it is part of the “prototype” project, a new project type. The project itself is redistributable including the player. The stakeholders have access to it via a browser for Silverlight types of projects and can be included in an archive or zip file for WPF applications.

 Another great feature is the ability to automatically generate design documentation.  At any point in time during the making of a prototype SketchFlow allows the generation of design documentation via export to Microsoft Word.  It generates the design document where every screen in the application has an entry in the table of contents, each state of those screens get created as a sub section. The automatic generation includes the overall application flow diagram and screenshots for each page and state.  This can be used to very quickly get documentation for stakeholders to red line or for creating initial detailed specs.

Utilizing SketchFlow and Expression Blend also solves the problems of:

• modeling states and transitions – this is very difficult to achieve with static screenshots.
• generating sample data -  it allows the mock up of a meaningful and interactive sample data without the need to create an actual data source
• modeling interactive behaviors – packaged extensible building blocks of user activities – like drag and drop
• leveraging existing design elements – via Adobe Photoshop Imports

SketchFlow has brought the ability to do quick prototyping and design to a broader audience that fits with today’s development methodologies of quick, iterative, and collaborative.  Everything in a SketchFlow project is a standard object in a Visual Studio project. Everything that gets created is a reusable asset.  

In the not too distant future I can envision a Sogeti gallery of reusable UI objects and components that will not only help us design applications at a higher level when delivering, but will help us leverage our experiences in a tangible way when designing a prototype for a demonstration or RFP. 

Check out Expression Blend 3 Preview

My first thought was “great, more people getting skills for jobs that aren’t in this country anymore.” and “yeah, but it’s all proprietary Microsoft technology, we’re going to assimilate you into the borg, yadda, yadda, yadda”

Then I thought about all of the freely available knowledge already out there that MSDN and Technet.  I’ve got to give kudos to Microsoft for actually putting money behind getting people that may have lost their job, a way to gain some valuable skills, regardless if it’s Microsoft focused or not.

There isn’t a vendor out there that gives you as much for free.   It’s knowledge for the taking. It’s very, dare I say, open source like of Microsoft.  Its open education.  

Of course, it’s all in an effort to get you to implement Microsoft solutions when the time comes, so this isn’t totally in the true spirit of giving.  However in a time when more and more jobs are outsourced out of the country,  and many of our dollars are going to build economies elsewhere, putting a focus back on our own back yard is certainly a welcome approach on many fronts.  I applaud Microsoft’s efforts.

Now, if your organization already has SOAP document/literal type web services in place that you can retrieve a WSDL from to subsequently use to update your data consider yourself ahead of the game, and your Information Workers will thank you so they can get their work done.

But suppose that SOA hasn’t really caught on yet at your company and those web services aren’t there. How can you serve an InfoPath form in SharePoint that needs to update a backend database? You’ll need to write a web service to do that. This isn’t something a typical InfoPath form creator is going to be comfortable doing or will even want to try. At that point they will typically have to enlist I.T.’s help and get a developer involved. Thus breaking most any chance that Information Workers will be able to develop browser based forms on their own.

“You need a new web service over the customer database? No Problem!” your developer might say since they’ve got the latest and greatest with Visual Studio 2008 and .NET 3.5 they can whip up ADO.NET data services in short order. Unfortunately the developer isn’t going to go home early having knocked one out of the park. They are going to be gravely disappointed after they quickly whip up that service, demo their RESTful services coupled with the ease of querying content from the database, only to find out that InfoPath isn’t compatible with that most excellent RESTful ADO.NET data service.

Bonk! Here’s where I insert a plea to MS InfoPath team — can we please have a service pack to make AtomPub or JSON web services consumable?

Go talk to the Astoria team if you need to. I hope the InfoPath team has found a new Program manager by now.

So our developer heads back to the drawing board.

Let’s say you’re fortunate enough to be using SQL Server 2005 or newer on the back end. And let’s face it, SQL Server ROCKS!

Your developer, who is a DBA on the side, knows that stored procedures already exist on the server and all he’ll need to do is wrapper those in service endpoints and away we go. Of course opening up service end points on SQL Server will undoubtly raise eyebrows with your “real” DBA, so our developer likely doesn’t have high enough level permissions to instantiate those service end points.

Time to reassign the project task to the DBA who will need to get those services up and running for our end user. Luckily our DBA can reference the InfoPath team blog where they’ve detailed this procedure out. The DBA reluctantly opens up service end point on the server and lets the form creator know that they are ready to be consumed.

Can you guess what’s next? Let’s go back a second, we’re developing online browser based forms. Not InfoPath client only forms. Can you consume that SQL Server data service from Online Form services? Perhaps, but you will need to become familiar with a tricky little concept known in the Windows Authentication world as the double hop.

Oh crikey, we’re going to also have to enlist the services of the SharePoint Farm Administrator to get SSO working and that is just plain scary and time consuming. Are you using Kerberos? Do we have service accounts set up for our SQL server instance? Could we just use a UDC or ODC file? What are those mysterious xml connection files anyway? Do they go in the farm or on the site….. etc, etc…. ++ points of failure.

Never fear, your SharePoint Admin understands all of that and will get it set up straight away. Hold on, is your SharePoint Admin a domain admin as well? Can they even add accounts to Active Directory?

At this point in the chain, the original InfoPath form creator is probably getting tired of waiting for it to “just work” and decides that it if it takes at a minimum 3 IT personel working in coordination to get a simple web service so they can do a simple submit form that it may be time to “just leave InfoPath development to I.T”.

This is the unfortunate usability and development path of InfoPath online services and consequently SharePoint. Although it’s really not all SharePoint’s fault, it merely the middleman that makes things complicated from an authentication and authoriztion stand-point; it is a problem of trying to create a development environment utilizing InfoPath inside of SharePoint supposedly targeted at Information Workers.

Contrast this by an agile development life cycle used to get the requirments from the business user and complete a short iteration using ASP.NET, ADO.NET Data Services, .NetTiers, or heck even Silverlight to make it prettier and it’s a hard sell to see what is gained by the former rather than the later.

Here’s hoping that the next version of InfoPath and Online form services cross that boundary to get to a truly Information Worker based creation space.

I do have my doubts though countless years of hearing how end users will be creating their own BI reports in super easy no development required reporting tools; This process seems quite similar. The trouble is, it always seems to end up back in I.T’s court.  There is nothing wrong with that, but it needs to be understood before embarking on an InfoPath Online Form solution.

Yet SharePoint still fails to solve business problems…

To be honest I was never a true citizen of SharePointistan, I have merely visited there on several engagements. As a professional developer I can say it’s a nice place to visit, but I wouldn’t want to live there.   Please read this as more of a plea to Microsoft to fix some of the usability and development challenges within the product. 

As consultants of the trade we get questions like these quite often: “what can we use SharePoint for”? “Can we use it for X” “Can you provide us a proof of concept”?

SharePoint is a content management system that, with each version is becoming increasingly extensible.  It is also extremely easy to use as a content management portal, and is designed to do most of the real work by putting administrative settings in the browser.   In a couple weeks you can get familiar with the tasks you’ll do most often as an administrator. That is, using or administering SharePoint is dead easy — it is designed for “non-programmers”.

The moment you try to create a true business application, or address specific business needs that fall outside of out-of-box functionality, SharePoint becomes unreasonably difficult.  Many things can be done via web parts and workflows, but the time required to create a truly useful, robust web part/workflow in a business context requires a level of effort that is not practical for most organizations, it’s more like the effort required to develop commercial components.   Once you embark on this extensibility, it quickly becomes clear that SharePoint was never intended to be a true application development platform, it is simply an extensible content management system.

Take a look around for InfoPath and what users are finding out about it in real-world scenarios.  It is one of those technologies that is misleading, because it’s so easy to get started with the out of the box, but when you start to modify things to work the way you really need them to work, the truth becomes clear.

Anyone that claims SharePoint to be a truly viable development platform is deluded or dishonest. I’m an advocate of SharePoint development, and in the right hands it can do some great things, but I’m honest enough to admit its (many) faults.

I know of several companies that have implemented or more appropriately “stood up” SharePoint only to have it languish on the corporate network infrastructure unused and unloved. In most cases SharePoint becomes nothing more than a glorified file share server. It’s a classic case of putting the cart before the horse. The customers go in with the promises and marketing hype only to find that six months down the road they are burdened with more administration, more effort for their users, and no real solution to their real business need. They were better off pre-SharePoint with a network file share and simply clicking File -> Save in their Office application.

We can do better! With the right processes, plans, and implementation many of these “dead” SharePoint sites could have been saved.

So what do SharePoint users really get? A development framework or platform to which they can quickly apply those business idea’s and collaboration? Many will claim that is exactly the case, that the company now has an platform and environment to build their solutions with; whatever those may be.

Unfortunately, like most technology, there is no silver bullet.

SharePoint isn’t something you can just plug in and it makes toast.

SharePoint is designed for a particular type of application (content management) and does that at an above average level with the right business processes in place. Without those processes, like most technology implemented over bad processes, it will fail to deliver. SharePoint is a nightmare for multi-environment (i.e. Dev, Test, Production) migration and custom development. Debugging in SharePoint is a hair pulling exercise. More on my Infopath Online Services adventures in another post.

Another question we often get asked by clients is along the lines of “Do I have to upgrade from Office [insert old version here] to use the latest version of SharePoint?”  SharePointistanians often mention the “Fair, Good, Better, Best” mantra when explaining the intricacy of integration with Office client tools and the Office Server (SharePoint). You can read it for yourself via the latest version of the white-paper can be found here.

To sum up:

• Fair = Crap
• Good = Unbearable
• Better = Barely Tolerable
• Best = Good

 For Reference that’s:

• Crap = Office 2000
• Unbearable = Office XP
• Barely Tolerable = Office 2003
• Good = Office 2007

Do yourself a favor. If your Office deployment (or a large part of it) currently falls into the “Crap” or “Unbearable” categories, STOP NOW! Don’t waste anymore time on feasibility studies, strategic/planning meetings, governance, etc. Just put together a business justification and upgrade to the latest Office. Failure to do this renders the vast majority of the SharePoint benefits null and void.

Once you “get” the fact that SharePoint provides a lock in for the Office tools for Microsoft you may see the light. If you aren’t keen on keeping Office around you may want to look at Joomla, an open source alternative content management system.

SharePoint is also designed as a collaboration tool for Web 2.0 (wikis, blogs, collaboration); which it does pretty poor job of compared to other tools on the market. Because of poor implementations, SharePoint can actually convince people that Web 2.0 initiatives are too hard to deliver on, or deliver too little value. What they might not realize is that it’s the fault of the system, not the idea.

While I’m defecting from SharePoint, this post shouldn’t be summarily construed as a “SharePoint is crap” post because it is a great product in it’s area if used in the way it was intended.  There are some really cool things you can do with SharePoint that indeed are faster than developing it on your own, which I hope to illustrate in future posts. 

There are also a number of things that Microsoft could do to improve the collaboration aspect and development usability of the product and I’ll also get to those in future posts.

Go get it. 

https://connect.microsoft.com/site/sitehome.aspx?SiteID=218&wa=wsignin1.0

Judging from the test times listed at Prometric the 70-241 test is shorter in duration;  1 hr 15 min versus the 2 hr 45 min listed for 70-235.  This doesn’t directly mean that it’s easier but it may make for a quicker certification process.

Let’s back up a minute. I recently received a new laptop from work (cheers for a new Thinkpad… woot!), and I needed to re-install software. I decided that with this new environment I’d be solely focused on the 2008+ stack (Visual Studio 2008, SQL Server 2008, etc.) and leave the 2005 stack off. I also need to have the BizTalk developer tools installed for working with BizTalk projects. The BizTalk installer flat out refused to give me the option to install the developer tools since it couldn’t find Visual Studio 2005. I really didn’t want to run another full version and license of Visual Studio so I decided to try running the express version. No luck there either, the BizTalk installer still will not pick up on it being installed.

Thus if you are a BizTalk developer don’t plan on jumping to Visual Studio 2008 just yet. There is a MS event webinar coming up on December 16th from Microsoft that will focus on integrating BizTalk Server solution development into the application lifecycle in VSTS 2008.

Sogeti is very adept at migrating clients from VB6 or other legacy applications to .NET.  One obvious thought I had was that our VB6 migrations will now need some additional value added activities to go along with the migration.  Value added in terms of assessing whether or not it makes sense to move the application to the cloud.  Think running on 64 bit Windows Server 2008 with unlimited scalability, load balancing, and instances hosted in their own hypervisor VM with support and a pay for only what you use model.

Moving a client’s capital expenditures for supporting those applications to operational costs in serving them from the cloud is something that is sure to be on everyone’s radar in this time of frugality.  Even more so in our market since Microsoft is building a data center right here in West Des Moines.