Examples of my SharePoint work

All of these are sites that are internal to the client. Contact me if you want more information.

A public utility in NorCal

· internal directory application exposing AD - Active Directory was dumped to a SQL2k5 DB and I made an ASP.NET 2.0 application to access and expose this as an SP application in /_layouts/

A large pharmaceutical in SoCal

· InfoPath FormServer integration – create InfoPath chemical compound shipping form with simple approval workflow included; test with users; deploy to FormServices
· web services based administration tools – crawl multiple sites to make security and other settings changes without touching the SharePoint backend
· email settings crawled from client – write a Powershell script to use .NET to make a "keyboard robot" to access/change settings not available to web services
· powerpoint slide manager – integrated consolidated slide deck application by using SharePoint facilities (e.g. permissions) and adapted a script to do consolidation with PowerPoint OM
· project schedule webpart – integrated SharePoint facilities (e.g. alerts) with script driving MSProject OM XML extraction to feed a SP XML webpart on the SP site
· XL Services integration – import/deploy chem-informatics spreadsheet to XL Services for search and customer access
· Integration to an internal Java application – built web part to integrate chemistry data and expose internal application results using web services
· BDC setup – XML definitions to use DBC to access Oracle data; included SP list integration, SP Designer web-parts as well as search integration
· Administration of the developers SP environment – installation, configuration and customization of the local developers SP environment including MSDN, TFS and compiler setup
· education for scientists - wrote and presented SP for Scientists class at 2 levels

A large health system in Missouri

· Initial TFS setup – installed and configured a developer image under VMWare delivered as a DVD
· Project design consulting – architecture design; use case review; deployment design
· Installation, configuration of TEST/PROD deployments – debugging related to FBA, IIS setup
· HTTP module development – C# module for custom authentication

A financial services company in NorCal

· integration in a large system - integrated Sharepoint upload into ASP.NET 2.0 application
· team participation beyond SP - responsible for several non-SP modules in the system
· ASP programming - used ASP.NET 2.0 declarative programming extensively
· Build setup/operation – installation, configuration and customization of build environment for developers for TFS, MSDN and SharePoint

Application #2

Let's call this: slide deck managment system

The business analyst asks the user: What is the requirement?

We have the slide deck of about 300 Powerpoint slides that we need to manage every 3 months or so. Each team leader has about 25-30 slides for which they make sure the content is correct.

We have to keep these separate so no one destroys anyone else's content. Then at the end of the quarter, we need to consolidate them all into one deck. When the consolidation comes, we need to lock out the changes and let everyone know where the final version is.

The business analyst writes down:

This is just like a group of editors who are each managing a bunch of chapters of a book. Let's use Sharepoint facilities to provide:

• check-in/check-out
• alerts
• permissions

Then I need the tech guys to make a script that will consolidate all of the slide decks. The business analyst finds a script that will [almost] do it here:

Together the busines analyst and the tech guys come up with the solution by following these steps:

• create a site with unique permissions
• create a document library
• name the slide decks so that the script can read them in the proper order
• upload the various slide decks
• set the alerts on each slide deck to point to the team leader for that deck
• set the alerts so that when the consolidated deck is stored, the correct people will be notified
• get each team leader to initially check-out their deck so no one else can modify it

Then modify the script to:

• read the slide decks from the SharePoint site using the UNC name
• store the consolidated file back into the site
• be run every 3 months or at the behest of the business user consolidator

This stripped-down implementation will work [I implmented it for one of my clients] and is in-lieu of a custom system that would cost big-dollars to develop/deploy/support/operate.

Application #1

Let's call this: The Plungers Ordering system

The business analyst asks the user: What is the requirement?

We always order plungers through Bob. He adds the details of the order as a row in a spreadsheet file. This works fine except: There is only one "correct" version of the file. Most of the time Bob has it. Sometimes other people have it. And then Bob does not have the latest one.

Then we order stuff we already have in-house.
Also, other people will add stuff to the sheet they want ordered without Bob knowing about it.

Lastly the spreadsheet can accidentally be seen by people in other groups and then they cause a political ruckus.

The business analyst writes down:

We just need to share this file, be able to review it before placing new orders, search for orders already placed and know we are looking at the latest version of the file. Also if we make a mistake we need to see what changes are made and optionally go back to an earlier version of the data.

We also need to make sure that noone outside of our group can see the contents of the file.

What is one technical alternative?

• Load the spreadsheet into a DB.
• Write some desktop or web code to access the DB.
• Work with the users to design the screens.
• Add a module to enforce security or put this in the DB DDL.
• Add a module to do versioning in the DB and screen to allow them to select/use old versions.
• Add help support to the system.Teach the users how to use the application.
• Have a QA process to make sure the application meets the business requirement.
• Roll out the application to production.
• When it needs to be changed [e.g. somebody quits], tell the users to call the programmer.

Usually the tech people go beyond this and also add:

• A forms system to order plungers
• A status screen to show everyone the status of the plunger orders.
• A security system to show everyone who has what permissions and to allow them to change the permissions.

What is an easier code-free alternative?

• Use Sharepoint.
• Optionally create a site to hold the data.
• Create a custom list by importing the spreadsheet data.
• Set Versioning=on for the custom list.
• Set up the security giving the appropriate people read access and others write access.
• Optionally, tell the Sharepoint administration group to make sure search works for this site.
• Test the application security and search functions.
• Show Bob how to check-in/check out the spreadsheet so versions will be kept.
• Show Bob how to change the security for the system.

Compare/contrast tech vs. code-free alternatives.


Advantages=Benefits

• tech - application is *exactly* like the users wants and no more
• code-free - user can build it themselves
• code-free - application goes to production much quicker
• code-free - user can use it immediately, on their own schedule
• code-free - application is managed by the user (security, et.al.)
• code-free - application can be changed by the user
• code-free - other code-free applications will behave the same

Disadvantages=Costs

• code-free - some SharePoint screens may not be exactly to the users taste
• code-free - MSoft bug in import needs a workaround
• code-free - users may proliferate applications that may need cleanup by IT staff
• tech - a coder is needed
• tech - application takes much longer to create/test/deploy
• tech - application is available to the users on IT schedule
• tech - application needs a coder to manage it (security, et.al.)
• tech - application needs a coder to change it

The Plungers Ordering system

This is a very simple system. I have seen requests like this from users for many years. Of course, they have their own types of plungers.

The usual scenario, which will also be described here, includes:

• the business analyst asks the users to describe the requirement
• the users tell their view of the system in their own words
• the business analyst translates the user requirement into a set of specifications to tell the coders
• the coders come up with a design
• the process of system construction starts ending with a system that meets the users' requirements

Of course this is very simplified and there are many detours to trip us up at each step.

Next I will describe in more detail 2 ways to construct the Plungers Ordering System.

Helping Users get Solutions Faster (=Cheaper)

For many years users have exploited various shortcuts because we (the IT guys) cannot get the solutions to them fast enough at the speed of business. Everyone knows that a very famous shortcut was when they started ordering Excel & 1-2-3 on the departmental budget. And we all know about the 3GLs and 4GLs.

Since then, and seemingly always, they have the desire to make their own solutions, if not the know-how.

In the last few years a Microsoft platform offering called SharePoint has gained widespread deployment, if not acceptance. In a few organizations I have consulted in, the users tell IT they want it. In some environments, marketing just tells IT to put it up and they say they will learn it themselves. I have seen these types of projects crash as often as succeed, but it does give some measure of the hunger.

SharePoint has a massive front-end, administration and development surface area. We will not cover very much of it. The focus will be on user-perceivable function and architecture.

One of its capabilities is the ability to create so-called no code solutions or almost no code. These approaches still have many kinks to work out, but I believe that it does point towards a future where (a new kind of) business analyst and some educated users can use these tools and the platform to create prototypes, if not applications, in the timeframe that business requires.