Here we go… another Cleverworkarounds waffle!

Now, we all know that Joel Oleson is the Russell Crowe of the SharePoint world! I mean, he’s multi-skilled, loads of talent, has the respect of his peers and has built a well deserved reputation of being one of the best at what he does. (Although unlike Russell I am fairly sure that he has not thrown a telephone at an annoying IT manager in a fit of rage just yet).

But despite his best intentions and with his heart in the right place, Joel is one of the unwitting architects of a butterfly effect that is now plaguing the SharePoint world. One that is now causing much pain and damage to already beleaguered enterprises.

In short, he set the wheels in motion that helped destroy a word via buzzword abuse 🙂 That word is…

"Governance"

See, way, way back in the bowels of time (okay, around 2006), when the stock market was soaring and therefore SOX compliance was being conveniently ignored by investors in equities, Joel’s blog was one of a couple of blogs of any significance SharePoint-wise. He was out there doing his bit for the common good, stressing the importance of governance in the SharePoint world before the word governance was really used in this context. Joel cited this article by Matthew Cain at Gartner which seems to be the root of it all. Now this is perfectly fine and dandy, but Joel made one fatal mistake that we are still feeling the effects of…

He de-nerdified his blog and made this stuff accessible! Thus, somewhere in the world, a marketing person read it and understood just enough syllables to get a gist of what Joel was talking about. Sensing the opportunity to add a new word to glossy brochureware, from that moment forward the true meaning of "governance" was lost forever as the snowball effect of a new buzzword taking root gained momentum. As the snowball rolls faster, more and more vendors get onto the bandwagon, each skewing the definition to suit their own ends.

So now, I am afraid that governance is now irreversibly sliding down the same slippery slope as such luminaries as "convergence", "portal", "ubiquitous", "social networking" and the current cream of the crop – "web 2.0".

…and it’s all Joel’s fault, right? 🙂

So, how to reclaim this word? I don’t know if you can. I have, however, decided to start a social experiment making my own future buzzword. More on that in a minute.

Governance = systems thinking

Before I present my version of what governance really means, I want to enlighten you to an important philosophical concept that underpins governance called "systems thinking" or "the systems approach". Systems thinking approaches problem solving from the perspective that the problem must be looked at as parts of an overall system, rather than focusing on individual outcomes. Wikipedia has quite a nice quote which captures the philosophy nicely.

Systems thinking attempts to illustrate that events are separated by distance and time and that small catalytic events can cause large changes in complex systems. Acknowledging that an improvement in one area of a system can adversely affect another area of the system, it promotes organizational communication at all levels in order to avoid the silo effect.

Either I have been officially typecast, or many organisations are feeling the same pain. The reason I say this is because I’ve been called in to assist organisations that are suffering a crisis of confidence with the SharePoint platform. In each case there are one or more highly visible and persistent problems that are causing user dissatisfaction. That translates to a stressed and under-confident SharePoint/IT project team who are questioning the validity of the SharePoint platform.

My brief in each was to help them pinpoint the root cause of their immediate pain, but in the context of a more holistic review of the SharePoint service to try and identify the gaps that allowed the situation to arise in the first place. The interesting fact about these sites is that they did have governance plans and on the surface of it all, most of the boxes could be ticked.

So, what went wrong?

It all boiled down to this: Stakeholders had a different interpretation of what governance actually means – the curse of a buzzword!. Most stakeholders in fact were more interested in the fact that they had a thirty page document someone wrote with "Governance plan" in the title and thought "okay that’s done, what’s next?".

This is not a systems thinking approach and therefore, this is not good governance. In fact, it really has missed the point entirely.

"SharePoint Assurance" is the new buzzword :-) 

At the end of the day, there are two immutable facts of working life.

1. We are all accountable to someone. Whether it is the board of directors being accountable to shareholders or the guy on the helpdesk being accountable to his operational manager, the vast majority of us are tasked with various responsibilities that our performance is judged on. If we fail to perform to the expectations, we not only let ourselves down, but we can adversely affect others.

2. We all want to go home from work, secure in the knowledge that we performed what was expected of us and we are still going to have a job tomorrow.

Both of these facts underpin the principle that we are all cogs in a complex organisational machine where our individual (and organisation-wide) fate is reliant on each other in complex, often implicit interdependencies.

Governance therefore is all about providing assurance. If you do not provide assurance, you will have fear, uncertainty and doubt. Take a look at the stock markets crashing around the world. Clearly assurance is in extremely short supply!

A Social Experiment

Now what I want to do twofold. For some strange reason I see the funny side of creating a new buzzword and see how long it takes to get to a brochure. Thus I am officially raising a virtual flag and laying claim to being the first person to use the term "SharePoint assurance" instead of SharePoint governance. (at the time of a writing a google search on this phrase yields only 5 hits).

Once you see the term in a marketing brochure, please let me know 🙂

But on a more serious note, I think that assurance in the SharePoint space can be done a lot better than it is and I have a few ideas on how this can be achieved.

More (hopefully much more) on this topic area soon…

Thanks for reading

Paul Culmsee

(Nerds are going to find this post dead boring).

Before I start, let me state that I am a believer in the Honey and Mumford theory of learning styles, as well as the Marston DISC assessment. I think both are closely related, and go some way to explaining many mysteries of the world like – "Why are there Metrosexuals?", "Why doesn’t everyone listen to Opeth?" and most importantly of all "What goes on in the strange world that is the engineer mind"?

"Engineer mind"?

Don’t bother googling that term because I made my own definition. I’m really referring to tech nerds generally, but the definition actually extends beyond nerds to a certain type of personality that tends to be a combination of an Activist learning style with a Steady/Conscientious DISC profile.

The point is that engineer minded people live in a factual world. Questions are factual and answers are usually pretty absolute. An engineer’s dogma also has a way to make facts more ‘factual’ in their eyes as well.

For a chunk of the rest of humanity, factual questions are not quite that factual. In many contexts, particularly political ones, a factual question is often open to more liberal interpretation.

This is in essence why engineers dress badly and sales people commonly exhibit metrosexual tendencies. 🙂

Continue reading “It’s all in the way you ask the question…”

I think as you age, you become more and more like your parents. Not so long ago I went out paintballing with some friends and we all agreed that the 16-18 year olds who also happened to be there were all obnoxious little twerps who needed a good kick in the rear. At the same time, we also agreed that we were just as obnoxious back when we were that age. Your perspective changes as you learn and your experience grows, but you don’t forget where you came from.

I now find myself saying stuff to my kids that my parents said to me, I think today’s music is crap, I have taken a liking to drinking quality scotch. Essentially all I need now to complete the metamorphosis to being my father is for all my hair to fall out!

So when I write an article whining about an assertion that IT has a credibility issue and has gone backwards in its ability to cope with various challenges, I fear that I have now officially become my parents. I’ll sound like grandpa who always tells you that life was so much simpler back in the 1940’s.

Consequences of complexity…

Before I go and dump on IT as a discipline, how about we dump on finance as a discipline, just so you can be assured that my cynicism extends far beyond nerds.

I previously wrote about how Sarbanes Oxley legislation was designed to, yet ultimately failed to, provide assurance to investors and regulators that public companies had adequate controls over their financial risk. As I write this, we are in the midst of a once in a generation-or-two credit crisis where some seven hundred billion dollars ($700,000,000,000) of US taxpayers’ money will be used to take ownership of crap assets (foreclosed or unpaid mortgages).

Part of the problem with the credit crisis was through the use of "collateralized debt obligations". This is a fancy, yet complex, way of taking a bunch of mortgages, and turning them into an "asset" that someone else who has some spare cash invests in. If you are wondering why the hell someone would invest in such a thing, then consider people with home loans, supposedly happily paying interest on those mortgages. It is that interest that finds its way to the holder (investor) of the CDO. So a CDO is supposedly an income stream.

Now if that explanation makes your eyes glaze over then I have bad news for you: that’s supposed to be the easy part. The reality is that the CDO’s are actually extremely complex things. They can be backed by residential property, commercial property, something called mortgage backed securities, corporate loans – essentially anything that someone is paying interest on can find its way into a CDO that someone else buys into, to get the income stream from the interest paid.

To provide "assurance" that these CDO’s are "safe", ratings agencies give them a mark that investors rely upon when making their investment. So a "AAA" CDO is supposed to have been given the tick of approval by experts in debt instrument style finance.

Here’s the rub about rating agencies. Below is a news article from earlier in the year with some great quotes

http://www.nytimes.com/2008/03/23/business/23how.html?pagewanted=print

Credit rating agencies, paid by banks to grade some of the new products, slapped high ratings on many of them, despite having only a loose familiarity with the quality of the assets behind these instruments.

Even the people running Wall Street firms didn’t really understand what they were buying and selling, says Byron Wien, a 40-year veteran of the stock market who is now the chief investment strategist of Pequot Capital, a hedge fund. “These are ordinary folks who know a spreadsheet, but they are not steeped in the sophistication of these kind of models,” Mr. Wien says. “You put a lot of equations in front of them with little Greek letters on their sides, and they won’t know what they’re looking at.”

Mr. Blinder, the former Fed vice chairman, holds a doctorate in economics from M.I.T. but says he has only a “modest understanding” of complex derivatives. “I know the basic understanding of how they work,” he said, “but if you presented me with one and asked me to put a market value on it, I’d be guessing.”

What do we see here? How many people really *understand* what’s going on underneath the complexity?

Of course, we now know that many of the mortgages backing these CDO’s were made to people with poor credit history, or with a high risk of not being able to pay the loans back. Jack up the interest rate or the cost of living and people foreclose or do not pay the mortgage. When that happens en masse, we have a glut of houses for sale, forcing down prices, lowering the value of the assets, eliminating the "income stream" that CDO investors relied upon, making them pretty much worthless.

My point is that the complexity of the CDO’s were such that even a guy with a doctorate in economics only had a ‘modest understanding’ of them. Holy crap! If he doesn’t understand it then who the hell does?

Thus, the current financial crisis is a great case study in the relationship between complexity and risk.

Consequences of complexity (IT version)…

One thing about doing what I do, is that you spent a lot of time on-site. You get to see the IT infrastructure  and development at many levels. But more importantly, you also spend a lot of time talking to IT staff and organisation stakeholders with a very wide range of skills and experience. Finally and most important of all, you get to see first hand organisational maturity at work.

My conclusion? IT is completely f$%#ed up across all disciplines and many will have their own mini equivalent of the US $700 billion dollar haemorrhage. Not only that, it is far worse today than it previously was – and getting worse! IT staff are struggling with ever accelerating complexity and the "disconnect" between IT and the business is getting worse as well. To many businesses, the IT department has a credibility problem, but to IT the feeling is completely mutual 🙂

You can find a nice thread about this topic on slashdot. My personal favourite quote from that thread is this one

Let me just say, after 26 years in this business, of hearing this every year, the systems just keep getting more complex and harder to maintain, rather than less and easier.

Windows NT was supposed to make it so anyone who could use Windows could manage a server.

How many MILLION MSCEs do we have in the world now?

Storage systems with Petabytes of data are complex things. Cloud computing is a complex thing. Supercomputing clusters are complex things. World-spanning networks are complex things.

No offense intended, but the only people who think things are getting easier are people who don’t know how they work in the first place

Also there is this…

There are more software tools, programming languages, databases, report writers, operating systems, networking protocols, etc than ever before. And all these tools have a lot more features than they used to. It’s getting increasingly harder to know "some" of them well. Gone are the days when just knowing DOS, UNIX, MVS, VMS, and OS/400 would basically give you knowledge of 90% of the hardware running. Or knowing just Assembly/C/Cobol/C++ would allow you to read and maintain most of the source code being used. So I would argue that the need for IT staff is going to continue to increase.

I think the "disconnect" between IT and Business has a lot more to do with the fact that business "knows" they depend on IT, but they are frustrated that IT can’t seem to deliver what they want when they want it. On the other side, IT has to deal with more and more tools and IT staff has to learn more and more skills. And to increase frustration in IT, business users frequently don’t deliver clear requirements or they "change" their mind in the middle of projects….

So it seems that I am not alone 🙂

I mentioned previously that more often than not, SQL Server is poorly maintained – I see it all the time. Yet today I was speaking to a colleague who is a storage (SAN) and VMware virtualisation god. I asked him what the average VMware setup was like and his answer was similar to my SQL Server and SharePoint experience. In his experience, most of them were sub-optimally configured, poorly maintained, poorly documented and he could not provide any assurance as to the stability of the platform.

These sorts of quality assurance issues are rampant in application development too. I see the same thing most definitely in the security realm too.

As the above quote sates, "it’s increasingly harder to know *some* of them well". These days I am working with specialists who live and breathe their particular discipline (such as storage, virtualisation, security or comms). Those disciplines over time grow more complex and sub-disciplines appear.

Pity then, the poor developer/sysadmin/IT manager who is trying to keep a handle on all of this and try to provide a decent service to their organisation!

Okay, so what? IT has always been complex – I sound like a Gartner cliche. What’s this got to do with SharePoint?

Consequences of SharePoint complexity…

SharePoint, for a number of reasons, is one of those products that has a way of really laying bare any gaps that the organisation has in terms of their overall maturity around technology and strategy.

Why?

Because it is so freakin’ complex! That complexity transcends IT disciplines and goes right to the heart organisational/people issues as well.

It’s bad enough getting nerds to agree on something, let alone organisation-wide stakeholders!

Put simply, if you do a half-arsed job of putting SharePoint in, you will be punished in so many ways! The simple fact is that the odds are against you before you even start because it only takes a mistake in one particular part of the complex layers of hardware, systems, training, methodology, information architecture and governance, to devalue the whole project.

When I first started out, I was helping organizations get SharePoint installed. However lately I am visiting a lot of sites where SharePoint has already been installed, but it has not been a success. There are various reasons;I have cited them in detail in the project failure series, so I won’t rehash all that here. (I’d suggest reading parts three, four and five in particular).

I am firmly of the conclusion that much of SharePoint is more art than science, and what’s more, the organisation has to be ready to come with you. Due to differing learning styles and poor communication of strategy, this is actually pretty rare. Unfortunately, IT are not the people who are well suited to "getting the organisation ready for SharePoint."

If that wasn’t enough, then there is this question. If IT already struggle to manage the underlying infrastructure and systems that underpin SharePoint, then how can you have any assurance that IT will have a "governance epiphany" and start doing things the right way?

This translates to risk, people! I will be writing all about risk in a similar style to the CFO Return on Investment series very soon. I am very interested in methods to quantify the risk brought about by the complexity of SharePoint and the IT services it relies on. For me, I see a massive parallel from the complexity factor in the current financial crisis and I think that a lot can be learned from it. SOX was supposed to provide assurance and yet did nothing to prevent the current crisis. Therefore, SOX represents a great example of mis-focused governance where a lot of effort can be put in for no tangible gain.

A quick test of "assurance"…

Governance is like learning to play the guitar. It takes practice, and it does not give up its secrets easily and despite good intent, you will be crap at it for a while. It is easy to talk about, but putting it into practice is another thing.

Just remember this. The whole point of the exercise is to provide *assurance* to stakeholders. When you set any rule, policy, procedure, standard (or similar), just ask yourself: Does this provide me the assurance I need that gives me confidence to vouch for the service I am providing? Just because you may be adopting ITIL principles, does *not* mean that you are necessarily providing the right sort assurance that is required.

I’ll leave you with a somewhat biased, yet relatively easy litmus test that you can use to test your current level of assurance.

It might be simplistic, but if you are currently scared to apply a service pack to SharePoint, then you might have an assurance issue. 🙂

Thanks for reading

Paul Culmsee

www.sevensigma.com.au

I am working on an essay about IT complexity at the moment, and one thing that sprung into my mind while thinking about this, is the fact that many of my clients seem to think I am some sort of SQL Server guru.

There are two sad realities inferred by this.

Firstly, I am far from a SQL Server god. Yes I have experience with it, but the only reason people think I’m any good at it stems from the general lack of knowledge that they have about the product. Often all I have to do is waltz in with my Michael Buble like smooth charm and recommend a maintenance plan be set up and I am instantly the guy to talk to in all things SQL.

The truth of the matter is that I’m not fit to lick the boots of a skilled DBA. But like all former system administrators/infrastructure managers who have had to deal with the pressure and consequences of downtime, irrespective of the product, I developed a reflex to learn what I need to to cover my butt. Often I didn’t care less how a product operated from the end-user perspective. All I cared about was how it hung together so I could recover it when it inevitably failed in some way.

Continue reading “SQL God? No… I just know how to do a maintenance plan”

One SharePoint book on my bookshelf is "Essential SharePoint 2007 – Delivering High Impact Collaboration", by Scott Jamison, Mauro Cardarelli and Susan Hanley.

Continue reading “Book Review – Essential SharePoint 2007”

Hi

This is one of those nerdy posts in the category of "look at me! look at me! look at what I did, isn’t it cool?". Normally application developers write posts like this, demonstrating some cool bit of code they are really proud of. Being only a part-time developer and more of a security/governance/compliance kind of guy, my "aint it cool" post is a little different.

So if you are a non developer and you are already tempted to skip this one, please reconsider. If you are a CIO, IT manager, Infrastructure manager or are simply into ITIL, COBiT or compliance around IT operations in general, this post may have something for you. It offers something for knowledge managers too. Additionally it gives you a teensy tiny glimpse into my own personal manifesto of how you can integrate different types of data to achieve the sort of IT operational excellence that is a step above where you may be now.

Additionally, if you are a Cisco nerd or an infrastructure person who has experience with monitoring, you will also find something potentially useful here.

In this post, I am going to show you how I leveraged three key technologies, along with a dash of best practice methodology to create an IT Portal that I think is cool.

The Premise – "Passive Compliance"

In my career I have filled various IT roles and drunk the kool-aid of most of the vendors, technologies, methodologies and practices. Nowadays I am a product of all of these influences, leaving me slightly bitter and twisted, somewhat of a security nerd, but at the same time fairly pragmatic and always mindful of working to business goals and strategy.

One or the major influences to my current view of the world, was a role working for OSI Software from 2000-2004, via a former subsidiary company called WiredCity. OSISoft develop products in the process control space, and their core product is a data historian called PI. At WiredCity, we took this product out of the process control market and right into the IT enterprise and OSISoft now market this product as "IT Monitor". I’ll talk about PI/IT monitor in detail in a moment, but humour me and just accept my word that it is a hellishly fast number crunching database for storing lots of juicy performance data.

An addition I like to read all the various best practice frameworks and methodologies and I write about them a fair bit. As a result of this interest, I have a SharePoint IT portal template that I have developed over the last couple of years, designed around the guiding principle of passive compliance. That is, by utilising the portal for IT various operational tasks, structured in a certain way, you implicitly address some COBiT/ISO27001 controls as well as leverage ITIL principles. I designed it in such a way that an auditor could take a look at it and it would demonstrate the assurance around IT controls for operational system support. It also had the added benefit of being a powerful addition to disaster recovery strategy. (In the second article, to be published soon, I will describe my IT portal in more detail).

Finally, I have SQL Reporting Services integrated with SharePoint, used to present enterprise data from various databases into the IT Portal – also as part of the principle of passive compliance via business intelligence.

Recently, I was called in to help conduct a demonstration of the aforementioned PI software, so I decided to add PI functionality to my existing "passive compliance" IT portal to integrate asset and control data (like change/configuration management) along with real-time performance data. All in all I was very pleased with the outcome as it was done in a day with pretty impressive effect. I was able to do this with minimal coding, utilising various features of all three of the above applications with a few other components and pretty much wrote no code at all.

Below I have built a conceptual diagram of the solution. Unfortunately I don’t have Visio installed, but I found a great freeware alternative 😉

I know, there is a lot to take in here (click to enlarge), but if you look in the center of the diagram, you will see a mock up of a SharePoint display. All of the other components drawn around it combine to produce that display. I’ll now talk about the main combination, PI and SQL Reporting Services.

A slice of PI

Okay so let’s explain PI because I think most people have a handle on SharePoint :-).

To the right is the terminator looking at data from a PI historian showing power flow in California. So this product is not a lightweight at all. It’s heritage lies in this sort of critical industrial monitoring.

Just to get the disclaimers out of the way, I do not work for OSISoft anymore nor are they even aware of this post. Just so hard-core geeks don’t flame me and call me a weenie, let me just say that I love RRDTool and SmokePing and prefer Zabbix over Nagios. Does that make me cool enough to make comment on this topic now? 🙂  

Like RRDTool, PI is a data historian, designed and optimised for time-series data.

"Data historian? Is that like a database of some kind?", you may ask. The answer is yes, but its not a relational database like SQL Server or Oracle. Instead, it is a "real-time, time series" data store. The English translation of that definition, is that PI is extremely efficient at storing time based performance data.

"So what, you can store that in SQL Server, mySQL or Oracle", I hear you say. Yes you most certainly can. But PI was designed from the ground up for this kind of data, whereas relational databases are not. As a result, PI is blisteringly fast and efficient. Pulling say, 3 months of data that was collected at 15 second intervals would literally take seconds to do, with no loss of fidelity, even going back months.

As an example, let’s say you needed to monitor CPU usage of a critical server. PI could collect this data periodically, save it into the historian for later view/review/reporting or analysis. Getting data into the historian can be performed a number of ways. OSISoft have written ‘interfaces’ to allow collection of data from sources such as SNMP, WMI, TCP-Response, Windows Performance Monitor counters, Netflow and many others.

The main point is that once the data is inside the historian, it really doesn’t matter whether the data was collected via SNMP, Performance Monitor, a custom script, etc. All historian data can now be viewed, compared, analysed and reported via a variety of tools in a consistent fashion.

SQL Reporting Services

For those of you not aware, Reporting Services has been part of SQL Server since SQL 2000 and allows for fairly easy generation of reports out of SQL databases. More recently, Microsoft updated SQL Server 2005 with tight integration with SharePoint. Now when creating a report server report, it is "published" to SharePoint in a similar manner to the publishing of InfoPath forms.

Creating reports is performed via two ways, but I am only going to discuss the Visual Studio method. Using Visual Studio, you are able to design a tailored report, consisting of tables and charts. An example of a SQL Reporting Services Report in visual studio is below. (from MSDN)

The interesting thing about SQL Reporting services is that it can pull data from data sources other than SQL Server databases. Data sources include Oracle, Web Services, ODBC and OLE-DB. Depending on your data source, reports can be parameterised (did I just make up a new word? 🙂 ). This is particularly important to SharePoint as you will soon see. It essentially means that you can feed your report values that customise the output of that report. In doing so, reports can be written and published once, yet be flexible in the sort of data that is returned.

Below is a basic example:

Here is a basic SQL statement that retrieves three fields from a data table called "picomp2". Those fields are "Tag", "Time" and "Value". This example selects values only where "Time" is between 12-1pm on July 28th and where "tag" contains the string "MYSERVER"

SELECT    "tag", "time", "value"
FROM      picomp2
WHERE     (tag LIKE '%MYSERVER%') AND ("time" >= '7/28/2008 12:00:00 PM') AND ("time" <= '7/28/2008 1:00:00 PM')

Now what if we wanted to make the value for TAG flexible? So instead of "MYSERVER", use the string "DISK" or "PROCESSOR". Fortunately for most data sources, SQL Reporting Services allows you to pass parameters into the SQL. Thus, consider this modified version of the above SQL statement.

SELECT    "tag", "time", "value"
FROM      picomp2
WHERE     (tag LIKE '%' + ? + '%') AND ("time" >= '7/28/2008 12:00:00 PM') AND ("time" <= '7/28/2008 1:00:00 PM') 

Look carefully at the WHERE clause in the above line. Instead of specifying %MYSERVER%, I have modified it to %?%. The question mark has special meaning. It means that you will be prompted to specify the string to be added to the SQL on the fly. Below I illustrate the sequence using three screenshots. The first screenshot shows the above SQL inside a visual studio report project. Clicking the exclamation mark will execute this SQL.

Immediately we get asked to fill out the parameter as shown below. (I have added the string "DISK")

Clicking OK, and the SQL will now be executed against the datasource, with the matching results returned as shown below. Note the all data returned contains the word "disk" in the name. (I have scrubbed identifiable information to protect the innocent).

Reporting Services and SharePoint Integration

Now we get to the important bit. As mentioned earlier, SharePoint and SQL Reporting Services are now tightly integrated. I am not going to explain this integration in detail, but what I am going to show you is how a parameterised query like the example above is handled in SharePoint.

In short, if you want to display a Reporting Services report in SharePoint, you use a web part called the "SQL Server Reporting Services Report Viewer"

After dropping this webpart onto a SharePoint page, you pick the report to display, and if it happens to be a parameterised report, you see a screen that looks something like the following.

Notice anything interesting? The webpart recognises that the report requires a parameter and asks for you to enter it. As you will see in the second article, this is very useful indeed! But first let’s get reporting services talking to the PI historian.

Fun with OLEDB

So, I have described (albeit extremely briefly) enough information about PI and Reporting services. I mentioned earlier that PI is not a relational database, but a time series database. This didn’t stop OSISoft from writing an OLEDB provider 🙂

Thus it is possible to get SQL reporting services to query PI using SQL syntax. In fact the SQL example that I showed in the previous section was actually querying the PI historian.

To get reporting services to be able to talk to PI, I need to create a report server Data Source as shown below. When selecting the data source type, I choose OLE DB from the list. The subsequent screen allows you to pick the specific OLEDB provider for PI from the list.

Now I won’t go into the complete details of completing the configuration of the PI OLE DB provider, as my point here is to demonstrate the core principle of using OLE DB to allow SQL Reporting Services to query a non-relational data store.

Once the data source had been configured and tested (see the test button in the above screenshot), I was able to then create my SQL query and then design a report layout. Here is the sample SQL again.

SELECT    "tag", "time", "value"
FROM      picomp2
WHERE     (tag LIKE '%' + ? + '%') AND ("time" >= '7/28/2008 12:00:00 PM') AND ("time" <= '7/28/2008 1:00:00 PM') 

As I previously explained, this SQL statement contains a parameter, which is passed to the report when it is run, thereby providing the ability to generate a dynamic report.

Using Visual Studio I created a new report and added a chart from the toolbox. Once again the purpose of this post is not to teach how to create a report layout, but below is a screenshot to illustrate the report layout being designed. You will see that I have previewed my design and it has displayed a textbox (top left) allowing the parameter to be entered for the report to be run. The report has pulled the relevant data from the PI historian and rendered it in a nice chart that I created.

Conclusion

Right! I think that’s about enough for now. To sum up this first post, we talked a little about my IT portal and the principle of "passive compliance". We examined OSISoft’s PI software and how it can be used to monitor your enterprise infrastructure. We then took a dive into SQL Reporting services and I illustrated how we can access PI historian data via OLE DB.

In the second and final post, I will introduce my IT Portal template in a brief overview, and will then demonstrate how I was able to integrate PI data into my IT portal to combine IT asset data with real-time performance metrics with no code 🙂

I hope that you found this post useful. Look out for the second half soon where this will all come together nicely

cheers

Paul

Now, readers would know that I really lay on the pop culture references pretty thick. I find it works well and makes ordinary, sometimes mundane, topics much more interesting and easy to explain. I’ve used Brittany Spears, Ikea, Kung Fu, Death metal, Dr Phil and countless others.

But I have never used Star Wars references in my post and probably never will. Why? I would like you to take some time to have a good read of this blog. I am having trouble finding the words to convey how brilliant it is.

http://sithsigma.wordpress.com/

My own company is a play on words on the much hyped/maligned Six Sigma methodologies, but this is so much more clever!

On this blog, both Darth Vader and Darth Sidious offer advice on strategy, project management and general business leadership and management topics. Some absolutely brilliant content there too, all set against the backdrop of what it takes to manage an evil empire. When you think about it, a Death Star is a pretty serious undertaking and to build it on time and on budget takes some pretty impressive management talent. So, despite whether you are an Empire kind of guy, or prefer being rebel scum, you have to concede that Vader and Sidious know how to manage a team. Sure, they made some mistakes (certainly their disaster recovery and risk management strategy were definitely flawed), but most organisations have a misfocussed attitude to security.

Aside from laughing hysterically when reading their material, I am certain that both Sith lords read the same strategy and management books that I do.

Here are some classic quotes..

In this essay on how performance metrics impact employee behaviour, Darth Sidious cites a recent example

…if your compensation system is based on rewarding people for speed, but product or service quality is severely lacking for some reason – even though you’ve mandated quality, it doesn’t make a difference what you mandate if what you’re measuring doesn’t support that goal (or even worse, is opposite to it).

That may seem like an obvious example, but it’s more common than you think. For the Clone Wars we ordered 100M Clones, and we wanted them ready in time to trick Obi Wan, so the Clone factory sacrificed on quality and what we ended up getting was 35% of the Clones being totally useless.

Now *that* is a real-world example that I can relate to!  Here is another gem from Sidious, explaining how the empire maintains a skills inventory to help them understand a team’s strengths and weaknesses.

Say you’re in a team that specializes in using the Force to electrocute captured rebels, or run a Network Engineering team. When it comes to hiring your instinct is to focus on the obvious and primary skill of the team.

Need to fill in an electrocutioner position? Then you’re probably looking for someone who’s learned how to channel the powers of the Force into electricity. Need to fill in a Network engineer position? You probably are looking for a hardcore networking/router/firewall guy.

Probably my favourite article is the Sith version of my "Project Fail" series where Darth Sidious offers advice on strategy, vision and goals. He breaks it down to:

• Vision
• Corporate objectives – eg "Increase delivery time of star destroyers by 10% over the next 12 months"
• Nested Objectives
• Alignment of Projects
• Executive/Sith Lord Sponsorship – "if an executive sponsor, Sith Lord, finds out you spent a large amount of galactic credits and it didn’t pay off, now you’re in deep water with no one to support you. A Sith Lord is liable to feed you to a Panna Monster in such a case"
• ROI

I could go on and on, but I could never do the site justice. The thing I really like about whoever authors this site is that they have managed to find the perfect balance between entertainment value with really insightful and clever messages behind the humour. It is a goal I have been trying to attain in my writing also, but I have to take my hat off to Sith Sigma for nailing it perfectly.

If they would have me I’d write on that site about collaboration under the pseudonym of Jar-Jar Binks 😉

Go take a look now. Tell em Jar-Jar sent you 😉 .

Paul

Article originally published for EndUserSharePoint.com reproduced here.

Greetings, my cleverworkarounds kung-fu students. Paul here again to talk once more about Zen and the art of SharePoint. Now I don’t want to appear all arrogant and pretentious, but for this post you can all call me "sifu" :-). I don’t deserve the title in the slightest but since I am writing it you are all forced to live in my fantasy world for a while :-).

I have previously written extensively on SharePoint project failure. In some ways that particular series is just as much about "thinking SharePoint" as this series, but I really do not want to rehash the content there. At the same time, I must confess I was trying to think of a way to round off this particular series of articles with a nice logical conclusion and was lost for awhile. But after watching Kung Fu Panda, I realised exactly how I can end it. So this post is the last in this series – for now anyway.

The thing about using pop culture references as I tend to do is that there is always a risk that some readers may not have seen the movie or heard the album that I refer to. So, if you haven’t seen Kung Fu Panda yet, I want you to visit this website and watch the trailer. http://www.kungfupanda.com/. Having done that, I now want you to read this article, and picture my voice as one of those old kung fu dudes with the long wispy beards offering riddle-like advice that makes no sense. If you can’t picture that, use Yoda instead.

Continue reading “Thinking SharePoint Part 4 – Lessons from Kung Fu Panda”

Recently, I came across the blog of Dux Raymond, a Project Manager, forthcoming author and trainer who looks at SharePoint from a project management perspective. Being rather interested in that area myself, I read his "Empowered by SharePoint" post.

He wrote about the theme of user empowerment that SharePoint provides and made this quote:

Typically, if a project manager wanted a collaborative platform (other than email) to facilitate sharing of project documents, schedule, contacts, and status updates, he or she would need the IT/IS department’s intervention and assistance to set it up. In addition to this, IT/IS would need to define the appropriate access privileges to limit who has access to these project information. Now, realistically, do you think IT/IS will get it done ASAP?

Dux went on to describe the features of SharePoint that can be used to empower users to be more efficient and productive.

The problem with this ideal (which I wholeheartedly agree with by the way) is that there is the problem of the corporate immune mechanism that likes to get in the way of any ideal that disagrees with its own. I wrote about the corporate immune mechanism in my kung-fu themed "You’re not ready" post (check the cool youtube clips of Jackie Chan, Jet Li and Tony Jaa 🙂 ). In that post, I defined the corporate immune mechanism as "the living embodiment of human nature’s resistance to change".

Now you might rightly ask me, "What the hell are you talking about? Why would users resist being empowered?"

The answer is that they are not! In fact, the users are not the problem. Sorry to disappoint you nerds reading this post. The corporate immune mechanism, in many cases, is the very department likely to be pushing the business down the SharePoint path in the first place… 

(cue the suspense music from the movie Jaws)

It is the IT Department!!! Nooooooo! How can these sweet, innocent looking people below be perpetrators of the corporate immune mechanism?

Shocked? Appalled at my statement? I can hear the indignant comments now…

• "What! Us? We are the ones who understand technology" (Luddite IT Manager)
• "What pills are you taking? – We are the innovators" (VB6 Developer)
• "Use linux ‘cos Microsoft suck" (Technical Geek)
• "Shut up and reboot" (Helpdesk Guy)
• "No, you can’t do that because it’s insecure and I said so" (Security Guy)
• "Users simply cannot be trusted" (System Administrator downloading mp3s on emule)

20 Years of users

Like everything else in this world, IT departments are a product of the experience of the team members and the culture of the organisation. Dealing with users is sometimes not fun. IT pretty much sees the user population as a bunch of rebellious, yet naive teenagers. Leave them alone and they will soon run amok and someone will get hurt. If it happens often enough, the teenagers are grounded and not allowed out of the house, except in controlled circumstances.

So, imagine dealing with rebellious teenagers for 20 years. Is it any wonder IT people are a little messed-up? 🙂

If the information worker revolution and the empowerment that comes with it means the IT administrators are out of the loop, then many IT administrators will push back to ensure that they are in the loop. They can’t help this because it has become a control reflex that I call it the "Mother Hen" reflex.

The mother hen reflex should be understood and not ridiculed, as it is often the user’s past actions that has created the reflex. But once ingrained, the reflex can start to stifle productivity in many different ways. For example, for an employee not being able to operate at full efficiency because they are waiting 2 days for a helpdesk request to be actioned is simply not smart business.

Worse still, a vicious circle emerges. Frustrated with a lack of response, the user will take matters into their own hands to improve their efficiency. But this simply plays into the hands of the mother hen reflex and for IT this reinforces the reason why such controls are needed. You just can’t trust those dog-gone users! More controls required!

So, if you think SharePoint is going to empower you, then you either ensure that the business takes ownership of it, with a sponsor senior enough to take on IT, or you had better start getting really friendly with your IT administrators. Many IT departments would positively have a heart attack, allowing end users the ability to say, modify the look and feel of a SharePoint site, use SharePoint Designer to create a workflow, modify permissions on items in a library, create a sub-site, create lists, modify lists with additional columns and the like.

I think it is a fully justifiable point of view when IT is looked at in isolation to the rest of the gears and pulleys that make up the organisational "machine". In IT’s mind, they are doing the right thing, yet they may very well be doing the organisation and SharePoint a disservice. They are scared that users are going to screw it all up and they will be left with picking up the pieces. But does the cost of IT’s compensation measures justify the real risk in terms of dollars and cents?

A recent example of the mother hen reflex completely going off the rails where inefficiency turned into real-life risk occurred in San Francisco with complete lockout of a fibre optic network by one rogue Cisco administrator. http://www.infoworld.com/archives/emailPrint.jsp?R=printThis&A=/article/08/07/18/30FE-sf-network-lockout_1.html. This is an example where in the administrator’s mind, he is being security-conscious, yet ultimately he was the biggest security risk of all.

Closer to SharePoint home, there was a thread on a SharePoint mailing list a month or so ago about managing SharePoint security groups, and the general consensus was that the groups should be set up and managed in Active Directory and then added into SharePoint. I am of the opinion that it is not as clear cut as this. IT generally controls Active Directory so group membership changes would remain in the perpetual 2 day turnaround that is typical of helpdesk SLA for the enterprise organisation.

But consider this. If for example, a project team has a project administrator who is trusted to manage access to all paper records, HR and payroll systems, then I have no problem delegating them the rights to manage a project sub-site or add/remove visitors to the site without having to wait 2 days for the request to get through IT’s helpdesk system. SharePoint provides the necessary audit trails, versioning and recycle bin recovery and the accountability can be pushed out to the project team. A win-win in my book.

Out of rehab

I’ll admit, a few years back I had a scary mother hen reflex. But later I realised that while I did a lot of security policy and compliance work, I was accountable for the IT service, not the information assets provided by that service. If I kept the service running, backed up and provided assurance as to the recoverability, then accountability for the information lay elsewhere.

Sadly, SharePoint does not make any of this easy. Complexity breeds confusion and it is exceptionally difficult to know *everything*. Fear of the unknown also breeds the mother hen reflex too. So, for that reason I am completely sympathetic to why IT departments tend to be very controlling, yet I recognise that it is too inward facing and can actually be damaging to organisational productivity and innovation too.

Unfortunately I don’t have any answers on where the line should be drawn either. That’s a function of many factors. However, what I can tell you is that empowerment is not always guaranteed.

Thanks for reading

Paul

My third post on "Thinking SharePoint" for www.endusersharepoint.com reproduced here.

Hi all

[Quick reference: Part 1 and Part 2]

If you have followed the first two articles in this series, I have been attempting to talk about SharePoint "head-space". In other words, SharePoint success is so much more a people issue than a technical or architectural one. As a result, it can be a little difficult to write about!

As a MOSS2007 product specialist and architect, I have slowly developed a kind of spider sense that allows me to pick out likely problematic implementations fairly early in the process. This spider sense is most definitely not along the lines of "oh these guys know nothing about application development/security/collaboration/[insert word here]". Often there are excellent, really knowledgeable staff on hand with exemplary credentials. It is instead a feeling that I previously described as "organisational maturity". Want a better explanation than that? How about something like the "oh they are *so* not ready for what they are getting themselves into" factor.

In Part 2, I’ve touched on the potent combination of differing personality types and the different stages of learning along with all of the new SharePoint features and options at your disposal. If you did not read part 2, then I strongly suggest you do so before continuing with this article because I am going to revisit the learning types stuff here.

Another way to describe the "unconsciously incompetent" stage of learning (that sounds much less insulting 😉 ) can be summed up as "you don’t know what you don’t know". The "Ikea guy" example in the last post is a perfect example of low organisational maturity. In my example, the poor unloved Ikea guy turns up at a house to install an Ikea modular storage solution and has to satisfy the conflicting requirements of a family so dysfunctional that the Simpsons seem pretty tame by comparison. It is clear from an outside perspective, that they have called in the "Ikea guy" way too early in the piece and in fact he is completely the wrong guy to call anyway! Wrong guy? Who should we be calling then?

Who you really need is someone like Carson and the boys from "queer eye for the straight guy" – Either them or Doctor Phil. They might come on a bit strong at first, but they work by winning your trust, building your respect and slowly but surely give you the confidence to change your old, bad habits. Before long the dysfunctional family have turned a corner, to the amazement of yourself and those around you. As an added bonus, you had a lot of fun along the way and your dress sense has improved as your stress levels have dropped 🙂

You still need the Ikea guy, but at least now the family no longer argues so much over which drawer your socks should be stored in!

Of course, the ultimate SharePoint consultant is this mythical person. can deal with your emotional issues *and* install the system! 🙂

Workshops, workshops!

Where possible, I always undertake SharePoint engagements in an advisory capacity before any time and cost estimates are made. Why? Because invariably, many/most clients start from a position of unconscious incompetence. Not just in term of the product itself, but in terms of a shared understanding of the problem with their colleagues and co-participants. Anyone who has been to a Microsoft sponsored SharePoint seminar and thought that SharePoint is the answer to their prayers is definitely in the first stage of their learning. In fact, when a client wants to skip the advisory stage and get straight into the "just tell me how much it costs", my spider senses tingle…

Thus, I run *plenty* of workshops. I don’t believe that "IT Integrators" who, for example, specialise in Exchange, Cisco networking and firewall type security are overly well suited to perform SharePoint implementations. Equally, I’m not convinced that a "Web Design House" is also particularly suited either. Yes, there is a big technical/architectural component (Ikea guys), but most of the work is in the facilitation, dialogue and requirements gathering stage of the process (Carson/Dr Phil guys). In other words, getting people from that "unconsciously incompetent" phase to "consciously incompetent" stage of learning.

I tend to keep the workshops to no more than two hours in a single day, with a break after an hour for everyone to recharge their brain cells with a jolt of caffeine :-). I also keep the workshops to 4 people or less and split into multiple workshops if there are more than 4 participants.

My goal in these workshops are threefold.

• Teach some product basics, answer common questions and set the scene
• Get participants thinking talking about what SharePoint means to them, and what they want to get out of it
• Assess the personality/competency/maturity level among participants ("unconsciously incompetent" versus "consciously incompetent’)

Achieving these goals usually takes two to three workshops and it is unwise to pack all of those goals into one workshop anyway. The first workshop is all about the product basics (goal 1 above). I do not go into massive detail, just enough so that participants are not flying completely blind with their understanding of the product. Signs of success of this workshop are the shared realisation from participants of the huge potential of the product in certain areas, and an appreciation of the fact that there are a lot of organisational issues that will affect success, and thus it is much more than just whacking in the CD and running SETUP.EXE.

Politics, politics!

I prefer to wait a day or two before the second workshops, as it gives participants a chance to take in the content of the first. When we meet for the second time, I do a quick recap on workshop 1, and then we start talking through requirements, issues, constraints and risks. One sure sign of organisational maturity among participants is how long this workshop takes. This is a factor of the scope of the perceived "problem" to be solved, but more importantly, often this is the first time the participants have actually *talked though* a problem together (aside from previously all agreeing that it is sub-optimal in the first place). It is very easy for these workshop to go over time, or to finish unresolved.

Additionally in this sort of workshops, you can fairly quickly assess the political dynamic of the group (goal 3). Participants always have different agendas or belief on what needs to be done to solve organisational problems. Often participants have locked horns with each-other way before SharePoint came on the scene, and it doesn’t take long to see where the dynamics lie. Understanding this dynamic allows you to tailor your facilitation and teaching approach and build trust and respect among all of the participants.

This can be a frustrating stage among participants, especially while a shared understanding is still being developed. But right here is the root of project failure – not just SharePoint.

What I will do now is tell you briefly about two different client engagements that I was involved in some time back. Both of these client engagements happened at around the same time, and each client happened to be in the same vertical market, although they had nothing to do with each-other. Both were ultimately successful projects in terms of delivery, but one was much more successful in terms of laying a foundation for future projects. If any aspect of these two tales resonate with you, please send a comment through at the end of this article.

Client 1

The first client was a tender that had a fixed time constraint (spider-sense goes gangbusters at this point). However the client had attended one of my seminars where we talked about how to approach a SharePoint project. (The subject matter being a more distilled version of my various posts such as this one). Thus, I had the chance to sit down and have a long chat with the client in an informal environment and felt the theme of our seminar had resonated with them and they had a solid appreciation why we approach SharePoint projects the way we do. 

Despite the very tight time frame I was able to conduct a couple of workshops in two groups and we were able to agree on deliverables that were realistic and achievable. However the workshops were an interesting experience. There were too many people and the group dynamic was clearly political in nature and there was open, sometimes rigorous debate, about specifics of the deliverables. The skill levels varied, as did the agendas. This client also outsourced IT support, so was somewhat light on the ground in terms of infrastructure and application development skills. Thus, we made a conscious decision to stick to SharePoint designer and go out-of-the-box for this initial engagement as we felt that the timeframe and process maturity constraints meant that we would be better served using tools that were easy to make modifications to. We had made this clear (or so we thought ) to the client when we responded to the tender.

By the end of the project two deliverables had expectation mismatches in their functionality. A couple of sticking points were actually how SharePoint was architected as a product and the miscommunication stemmed from a lack of understanding of how the product worked in particular regards. To change the behaviour would require disproportionate custom development work that would very likely be redundant fairly quickly, once users started using the product. Additionally, custom application development for SharePoint adds to governance and they were not yet ‘ready’ to make that leap.

Now it is important to note here that the client was not really at fault. You can hardly blame someone when they "don’t know what they don’t know". The failure was on my part, in that I did not do enough to ensure that we had a shared understanding and full awareness of the constraints of our approach. At the time I thought that we had achieved this milestone, but looking back, it as clear that principally due to the very tight time-frames that we had to operate under, we under-invested in this part of the project.

Fortunately in this case, we were able to agree on workarounds that got the project over the line on-time, made logical sense and did not have any major impact on either party. But the major "lesson learnt" from this project is that we never actually guided the client properly to the "consciously incompetent" stage of their learning.

Client 2

Client 2 was an interesting case. They attended the same seminar as Client 1, principally because a competing integrator had sold them the idea of using SharePoint for their Internet site. Upon seeing the high cost of the licensing, the competing integrator then showed them "all of the other great features" that they would get from investing in SharePoint and overloaded them on recycled Microsoft "6 pillar" marketing material. The client liked all of these new features of course, and thus broadened the scope of the deliverables to help justify the cost.

Result? Even more confusion (and at this point they still had not actually *used* SharePoint). So they attended my seminar for some direction and I was subsequently engaged in an advisory capacity to help them make sense of it all.

I used the workshop approach as described above, and the first workshop was heavy going, because it took a while to sort out all of the marketing fluff from reality. They had been the victim of one too many PowerPoint slide decks and thus jumped around from topic to topic. I answered as best I could, occasionally having to use geek-speak but mostly was able to keep it pitched at the right sort of level. The client then had to reconcile the reality of SharePoint against this overly broad scope that they had created for themselves. It was frustrating for them, and I really felt for them. I even went as far as to offer to discuss things over a beer. (It’s amazing how much more progress you can make over beer 😉 .

A week went by, and the client called me back in. That week they had spent a lot of time soul searching and debating where, when and how SharePoint should be tackled. In the end they had re-examined the corporate strategy, which was a high level, 3 year plan that had been signed off by the organisation previously. They then examined the IT department’s 3 year plan which was developed to support the organisational strategy.

They came to the conclusion, that their external web site was not the place to start, for various reasons. Instead, they identified a much smaller scope project that slotted in perfectly with both the IT department strategy and more importantly, the organisational strategy. They asked me for feedback and I was very enthusiastic in how well they had done, considering the hard-slog workshops from the week before.

At this point, the transition from "unconsciously incompetent" to "consciously incompetent" was well underway

I met with them a few days later. Since the entire team was behind the agreed project, they had talked to the organisation stakeholders, mapped out and documented the process before I had arrived. They also were eager to learn SharePoint, and since the scope of this project was not large and the shared understanding was high, we were able to use this project as the training exercise to learn various concepts from Farm Administration, libraries, lists and columns, SharePoint Designer workflow and InfoPath Forms Services. When we hit an obstacle, we collectively were able to find creative, yet simple ways to get around them.

That smaller scope project was successfully delivered, and the benefits were significant. The team now has a much better understanding of the product, its constraints and limitations. It was now much easier to plan for and tackle the more significant project of web content management (Internet site) as there was a much greater level of shared understanding between participants. They felt more confident in their knowledge of the product, and now feel confident that they would be able to manage the expectations of the organisation.

All in all, it was a great engagement and I came away with a huge respect for that client. More importantly, the relationship continues to this day.

Conclusion

I wonder if the story of the first client is a familiar one to readers, either as being and end-user or being involved in the project itself? 

Certainly the second client had frustrations at the start, as they realised that SharePoint was not the panacea they were looking for, they stopped, took stock and co-operatively reassessed the situation. Unconstrained from a fixed time deadline, they realised that more thought was required. That action potentially saved them a lot of stress and heartache which they would have experienced had they ploughed on ahead with an ambitions project. It has now given them a great foundation to build upon for the future.

Thanks for reading

Paul Culmsee