So first up, just because I get asked this all the time, the book is definitely *not* “A humble tribute to the leave form – The Book”! In fact, it’s not about SharePoint per se, but rather the deeper dark arts of team collaboration in the face of really complex or novel problems.

It was late 2006 when my own career journey took an interesting trajectory, as I started getting into sensemaking and acquiring the skills necessary to help groups deal with really complex, wicked problems. My original intent was to reduce the chances of SharePoint project failure but in learning these skills, now find myself performing facilitation, goal alignment and sensemaking in areas miles away from IT. In the process I have been involved with projects of considerable complexity and uniqueness that make IT look pretty easy by comparison. The other fringe benefit is being able to sit in a room and listen to the wisdom of some top experts in their chosen disciplines as they work together.

Through this work and the professional and personal learning that came with it, I now have some really good case studies that use unique (and I mean, unique) approaches to tackling complex problems. I have a keen desire to showcase these and explain why our approaches worked.

My leanings towards sensemaking and strategic issues would be apparent to regular readers of CleverWorkarounds. It is therefore no secret that this blog is not really much of a technical SharePoint blog these days. The articles on branding, ROI, and capacity planning were written in 2007, just before the mega explosion of interest in SharePoint. This time around, there are legions of excellent bloggers who are doing a tremendous job on giving readers a leg-up onto this new beast known as SharePoint 2010.

So back to the book. Our tentative title is “Beyond Best Practices” and it’s an ambitious project, co-authored with Kailash Awati – the man behind the brilliant eight to late blog. I had been a fan of Kailash’s work for a long time now, and was always impressed at the depth of research and effort that he put into his writing. Kailash is a scarily smart guy with two PHD’s under his belt and to this day, I do not think I have ever mentioned a paper or author to him that he hasn’t read already. In fact, usually he has read it, checked out the citations and tells me to go and read three more books!

Kailash writes with the sort of rigour that I aspire to and will never achieve, thus when the opportunity of working with him on a book came up, I knew that I absolutely had to do it and that it would be a significant undertaking indeed.

To the left is a mock-up picture to try and convey where we are going with this book. See the guy on the right? Is he scratching his head in confusion, saluting or both? (note, this is our mockup and the real thing may look nothing like this)

This book dives into the seedy underbelly of organisational problem solving, and does so in a way that no other book has thus far attempted. We examine why the very notion of “best practices” often makes no sense and have such a high propensity to go wrong. We challenge some mainstream ideas by shining light on some obscure, but highly topical and interesting research that some may consider radical or heretical. To counter the somewhat dry nature of some of this research (the topics are really interesting but the style in which academics write can put insomniacs to sleep), we give it a bit of the cleverworkarounds style treatment and are writing in a conversational style that loses none of the rigour, but won’t have you nodding off on page 2. If you liked my posts where I use odd metaphors like boy bands to explain SharePoint site collections, the Simpsons to explain InfoPath or death metal to explain records versus collaborative document management, then you should enjoy our journey through the world of cognitive science, memetics, scientific management and Willy Wonka (yup – Willy Wonka!).

Rather than just bleat about what the problems with best-practices are, we will also tell you what you can do to address these issues. We back up this advice by presenting a series of practical case studies, each of which illustrates the techniques used to address the inadequacies of best practices in dealing with wicked problems. In the end, we hope to arm our readers with a bunch of tools and approaches that actually work when dealing with complex issues. Some of these case studies are world unique and I am very proud of them.

Now at this point in the writing, this is not just an idea with an outline and a catchy title. We have been at this for about six months, and the results thus far (some 60-70,000 words) have been very, very exciting. Initially, we really had no idea whether the combination of our writing styles would work – whether we could take the degree of depth and skill of Kailash with my low-brow humour and my quest for cheap laughs (I am just as likely to use a fart joke if it helps me get a key point across)…

… But signs so far are good so stay tuned

Thanks for reading

Paul Culmsee

www.sevensigma.com.au

                      

Technorati Tags: Book, Beyond Best Practices

Hi again

This article is the second half of a pair of articles explaining how I integrated real-time performance data with an SharePoint based IT operational portal, designed around the principle of passive compliance with legislative or organisational controls.

In the first post, I introduced the PI product by OSIsoft, and explained how SQL Reporting services is able to generate reports from more than just SQL Server databases. I demonstrated how I created a report server report from performance data stored in the PI historian via an OLE DB provider for PI, and I also demonstrated how I was able to create a report that accepted a parameter, so that the output of the report could be customised.

I also showed how a SharePoint provides a facility to enter parameter data when using the report viewer web part.

We will now conclude this article by explaining a little about my passively compliant IT portal, and how I was able to enhance it with seamless integration with the real-time performance data stored in the PI historian.

Just to remind you, here is my conceptual diagram in "acoustic Visio" format

The IT portal

This is the really ultra brief explanation of the thinking that went into my IT portal

I spent a lot of time thinking about how critical IT information could be stored in SharePoint to achieve the goals of quick and easy access to information, make tasks like change/configuration management more transparent and efficient, as well as capture knowledge and documentation. I was influenced considerably by ISO17799 as it was called back then, especially in the area of asset management. I liked the use of the term "IT Assets" in ISO17799 and the strong emphasis on ownership and custodianship.

ISO defined asset as "any tangible or intangible thing that has value to an organization". It maintained that "…to achieve and maintain appropriate protection of organizational assets. All assets should be accounted for and have a nominated owner. Owners should be identified for all assets and the responsibility for the maintenance of appropriate controls should be assigned. The implementation of specific controls may be delegated by the owner as appropriate but the owner remains responsible for the proper protection of the assets."

That idea of delegation is that an owner of an asset can delegate the day-to-day management of that asset to a custodian, but the owner still bears ultimate responsibility.

So I developed a portal around this idea, but soon was hit by some constraints due to the broad ISO definition of an asset. Since assets have interdependencies, geeks have a tendency to over-complicate things and product a messy web of interdependencies. After some trial and error, as well as some soul searching I was able to come up with a 3 tier model that worked.

I changed the use of the word "asset", and split it into three broad asset types. Devices (eg Server, SAN, Switch, Router, etc) IT Services (eg Messaging, Databases, IP Network, etc) Information Assets (eg Intranet, Timesheets,

The main thing to note about this model is to explain the different between an IT Service and an Information Asset. The distinction is in the area of ownership. In the case of an "Information Asset", the ownership of that asset is not IT. IT are a service provider, and by definition the IT view of the world is different to the rest of the organisation. An "IT Service" on the other hand, is always owned by IT and it is the IT services that underpin information assets.

So there is a hierarchical relationship there. You can’t have an information asset without an IT service providing it. Accountabilities are clear also. IT own the service, but are not responsible for the information asset itself – that’s for other areas of the organisation. (an Information Asset can also depend on other information assets as well as many IT services.

While this may sound so obvious that its not worth writing, my experience is that IT department often view information assets and the services providing those assets as one and the same thing.

Devices and Services

So, as an IT department, we provide a variety of services to the organisation. We provide them with an IP network, potentially a voice over IP system, a database subsystem, a backup and recovery service, etc.

It is fairly obvious that each IT service consists of a combination of IT devices (and often other IT services). an IP network is an obvious one and a basic example. The devices that underpin the "IP Network" service are routers, switches and wireless access points.

For devices we need to store information like

• Serial Number
• Warranty Details
• Physical Location
• Vendor information
• Passwords
• Device Type
• IP Address
• Change/Configuration Management history
• IT Services that depend on this device (there is usually more than 1)

For services, we need to store information like

• Service Owner
• Service Custodian
• Service Level Agreement (uptime guarantees, etc)
• Change/Configuration Management history
• IT Devices that underpin this service (there is usually more than 1)
• Dependency relationships with other IT services
• Information Assets that depend on this IT service

Keen eyed ITIL practitioners will realise that all I am describing here is a SharePoint based CMDB. I have a site template, content types, lists, event handlers and workflows that allow the above information to be managed in SharePoint. Below is three snippets showing sections of the portal, drilling down into the device view by location (click to expand), before showing the actual information about the server "DM01"

Now the above screen is the one that I am interested in. You may also notice that the page above is a system generated page, based on the list called "IT Devices". I want to add real-time performance data to this screen, so that as well as being able to see asset information about a device, I also want to see its recent performance.

Modifying a system page

I talked about making modifications to system pages in detail in part 3 of my branding using Javascript series. Essentially, a system page is an automatically generated ASPX page that SharePoint creates. Think about what happens each time you add a column to a list or library. The NewForm.aspx, Editform.Aspx and Dispform.aspx are modified as they have to be rebuild to display the new or modified column.

SharePoint makes it a little tricky to edit these pages on account of custom modifications running the risk of breaking things. But as I described in the branding series, using the ToolPaneView hack does the job for us in a safe manner.

So using this hack, I was able to add a report viewer web part to the Dispform.aspx of the "IT devices" list as shown below.

Finally, we have our report viewer webpart, linked to our report that accesses PI historian data. As you can see below, the report that I created actually is expecting two parameters to be supplied. These parameters will be used to retrieve specific performance data and turn it into a chart.

Web Part Connection Magic

Now as it stands, the report is pretty much useless to us in the sense that we have to enter parameters to it manually, to get it to actually present us the information that we want. But on the same page as this report is a bunch of interesting information about a particular device, such as its name, IP Address, location and description. Wouldn’t it be great if we could somehow pass the device name (or some other device information) to the report web part automatically.

That way, each time you opened up a device entry, the report would retrieve performance information for the device currently being viewed. That would be very, very cool.

Fortunately for us it can be easily done. The report services web part, like many other web parts is connectable. This means that it can accept information from other web parts. This means that it is possible to have the parameters automatically passed to the report! 

Wohoo!

So here is how I am going to do this. I am going to add two new columns to my device list. Each column will be the parameter passed to the report. This way, I can tailor the report being generated on a device by device basis. For example, for a SAN device I might want to report on disk I/O, but a server I might want CPU. If I store the parameter as a column, the report will be able to retrieve whatever performance data I need.

Below shows the device list with the additional two columns added. the columns are called TAGPARAM1 and TAGPARAM2. The next screen below, shows the values I have entered for each column against the device DM01. These values will be passed to the report server report and used to find matching performance data.

So the next question becomes, how do I now transparently pass these two parameters to the report? We now have the report and the parameters on the same page, but no obvious means to pass the value of TagParam1 and TagParam2 to the report viewer web part.

The answer my friends, is to use a filter web part!

Using the toolpane view hack, we once again edit the view item page for the Device List. We now need to add two additional web parts (because we have two parameters). Below is the web part to add.

The result should be a screen looking like the figure below

Filter web parts are not visible when a page is rendered in the browser. They are instead used to pass data between other web parts. There are various filter web parts that work in different ways. The Page Field filter is capable of passing the value of any column to another web part.

Confused? Check out how I use this web part below…

The screen above shows that the two Page Field filters web parts are not configured. They are prompting you to open the tool pane and configure them. Below is the configuration pane for the page field filter. Can you see how it has enumerated all of the columns for the "IT device" list? In the second and third screen we have chosen TagParam1 for the first page filter and TagParam2 for the second page filter web part.

Now take a look at the page in edit mode. The page filters now change display to say that they are not connected. All we have done so far is tell the web parts which columns to grab the parameter values from

Almost Home – Connecting the filters

So now we need to connect each Page Field filter web part to the report viewer web part. This will have the effect of passing to the report viewer web part, the value of TagParam1 and TagParam2. Since these values change from device to device, the report will display unique data for each device.

To to connect each page filter web part you click the edit dropdown for each page filter. From the list of choices, choose "Connections", and it will expand out to the choice of "Send Filter Values To". If you click on this, you will be promoted to send the filter values to the report viewer web part on the page. Since in my example, the report viewer web part requires two parameters, you will be asked to choose which of the two parameters to send the value to.

Repeat this step for both page filter web parts and something amazing happens, we see a performance report on the devices page!! The filter has passed the values of TagParam1 and tagParam2 to the report and it has retrieved the matching data!

Let’s now save this page and view it in all of its glory! Sweet eh!

Conclusion (and Touchups)

So let’s step back and look at what we have achieved. We can visit our IT Operations portal, open the devices list and immediately view real-time performance statistics for that device. Since I am using a PI historian, the performance data could have been collected via SNMP, netflow, ping, WMI, Performance Monitor counters, a script or many, many methods. But we do not need to worry about that, we just ask PI for the data that we want and display it using reporting services.

Because the parameters are stored as additional metadata with each device, you have complete control over the data being presented back to SharePoint. You might decide that servers should always return CPU stats, but a storage area network return disk I/O stats. It is all controllable just by the values you enter into the columns being used as report parameters.

The only additional thing that I did was to use my CleverWorkArounds Hide Field Web Part, to subsequently hide the TagParam1 and TagParam2 fields from display, so that when IT staff are looking at the integrated asset and performance data, the ‘behind the scenes’ glue is hidden from them.

So looking at this from a IT portal/compliance point of view, we now have an integrated platform where we can:

• View device asset information (serial number, purchase date, warranty, physical location)
• View IT Service information (owners, custodians and SLA’s)
• View Information Asset information (owners, custodians and SLA’s)
• Understand the relationships between devices, services and information assets
• Access standards, procedures and work instructions pertaining to devices, services and information assets
• Manage change and configuration management for devices, services and information assets
• Quickly and easily view detailed, real time performance statistics of devices

All in all, not a bad afternoons work really! And not one line of code!

As i said way back at the start of the first article, this started out as a quick idea for a demo and it seems to have a heck of a lot of potential. Of course, I used PI but there is no reason why you can’t use similar techniques in your own IT portals to integrate your operational and performance data into the one place.

I hope that you enjoyed this article and I look forward to feedback.

<Blatant Plug>Want an IT Portal built in passive compliance? Then let’s talk!</Blatant Plug>

cheers

Paul Culmsee

OSISoft addendum

Now someone at OSISoft at some point will read this article and wonder why I didn’t write about RTWebparts. Essentially PI has some web parts that can be used to display historian data in SharePoint. There were two reasons why I did not mention them.

1. To use RTWebparts you have to install a lot of PI components onto your web front end servers. Nothing wrong with that, but with Report Services, those components only need to go onto the report server. For my circumstances and what I had to demonstrate, this was sufficient.
2. This post was actually not about OSISoft or PI per se. It was used to demonstrate how it is possible to use SharePoint to integrate performance and operational information into one integrated location. In the event that you have PI in your enterprise and want to leverage it with SharePoint, I suggest you contact me about it because we do happen to be very good at it

                      

No Tags

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

                      

No Tags

Hi

Well, here we are at part 8 in a series of posts dedicated to the topic of SharePoint project failure. Surely after 7 posts, you would think that we are exhausting the various factors that can have a negative influence on time, budget and SharePoint deliverables? Alas no! My urge to peel back this onion continues unabated and thus I present one final post in this series.

Now if I had my time again, I would definitely re-order these posts, because this topic area is back in the realm of project management. But not to worry. I’ll probably do a ‘reloaded’ version of this series at some point in the future or make an ebook that is more detailed and more coherently written, along with contributions from friends.

In the remote chance that you are hitting this article first up, it is actually the last of a long series written over the last couple of months (well, last for now anyway). We started this series with an examination of the pioneering work by Horst Rittell in the 1970′s and subsequently examined some of the notable historical references to wicked problems in IT. From there, we turned our attention to SharePoint specifically and why it, as a product, can be a wicked problem. We looked at the product from viewpoints, specifically, project managers, IT infrastructure architects and application developers.

In the last article, we once again drifted away from SharePoint directly and looked at senior management and project sponsors contribution. Almost by definition, when looking at the senior management level, it makes no sense to be product specific, since at this level it is always about business strategy.

In this post, I’d like to examine when best practice frameworks, the intent of which is to reduce risk of project failure, actually have the opposite effect. We will look at why this is the case in some detail.

CleverWorkarounds tequila shot rating..

    For readers with a passing interest in best practice frameworks and project management.

For nerds who swear they will never leave the "tech stuff."

Wicked problem or wicked process dogma?

The last major topic area I will cover, is really a manifestation of wicked problems as described in part 1. As an example, let’s say our SharePoint project has completely gone off the rails. Scope creep is rampant, requirements are unclear, time and budget has blown out, users hate it, the project team is dejected, the sponsor has disowned the project and senior management are very unhappy.

Is that example extreme? Not really – although I’m using SharePoint as an example here, the same story commonly afflicts many IT projects.

But what I have noticed is that the more acute the wicked problem symptoms are, the more likely that significant blame is lumped at the "process" level, rather than the wicked problem at the root of it all. For sure, I agree that process issues are a big factor. However, the inevitable outcome of blaming the process, is that you spend all of your time and energy looking at solutions for the process, in some belief that more formal, standardised process-steps would have helped solve the problem. The reality is, however, the project team likely did not have a shared understanding of the problem.

It is very easy to see how this happens. "We are so far over time and budget, we must have not used a strict process to nail down scope and requirements". Thus, best-practice frameworks suddenly come into the mix as after all, they are a best-practice, right?

My observation here is that the team or organisation still may not realise that they are dealing with a wicked problem. Therefore, there is a crucial factor here that is often overlooked in this situation. In reality, it doesn’t really matter which best practice you pick (and there sure are plenty to pick from). My experience is that as the problem "wickedness factor" increases, the more the "panacea effect" kicks in for the chosen best practice framework. The panacea effect (which I defined in part 3) is a reflection of how badly a project has gone bad, since the worse the fallout, the greater the pressure there is to get things on track and therefore anything with "best practice" sounds positively dandy.

As a result, the implementation of a best practice is itself doomed to fail for very similar reasons that your original project failed!

Why? Once things get bad, relationships are strained and communication is poor. If your team was not able to gain a shared understanding of the original problem to solve, what makes you any more likely to gain a shared understanding of how to implement a best practice framework? Those frameworks also require deeper understanding too!

When frameworks bite back!

Anyways, as I write this post, the immediate analogy that summarises the theme of this last post is one of those dodgy ‘reality’ shows like "when animals attack", or "when household appliances go bad". You know those shows that tend to get broadcast during non ratings periods? Well, I have an idea for a pilot. Do you think the TV networks will take it up?

The pitch of my new reality show is to show reel after reel of emotionally shattered project teams, with dramatic re-enactments of the incidents set against those music scores that build tension – I’m thinking Mike Olfield’s "Tubular Bells" here (that creepy piano piece used on the movie "the exorcist"). To host the show, I’m thinking either Scott Baio or Mr T would suffice.

Each episode will tell a harrowing story of an initial, well-intentioned effort to use a best-practice framework to improve some aspect of the business. Buy-in and motivation are initially high among participants, but is quickly and fatally derailed due to misplaced expectation, over-zealous, rigid interpretation style implementations that result in increased red tape for little measurable gain.

Imagine the "60 minutes" style voice over during the opening credits…

"…they thought it would just be a routine project, but little did they know of the horror that was about to change their lives forever…"

Introducing the All Star Cast

As you can see in my mythical DVD cover, there is a bit of an all-star cast of frameworks there. But really, it only scratches the surface of the variety of methods, tools and alternatives in the realm of the ‘framework’. If you were going to break them down into broad categories (which can be tough because of significant overlap amongst them), my suggestion is to have a look at the webcast by Lynda Cooper of Fox IT. This is an excellent presentation that breaks down various frameworks into decent groupings and relates it all back to IT governance for business.

Although this series is not directly focused on IT governance as such, the webcast above is a great reference to put it all into perspective and I intend to write more on this topic in a SharePoint context.

Lynda lumps all of these frameworks into 3 broad categories: Best Practice Guidelines, Standards and Recognised Measurement Techniques.

Best Practice Guidelines

Examples: PMBOK, Prince2, COBiT, ITIL

Best practice guidelines tend to have wide recognition within their industry, but generally an organisation does not certify against them (individuals however can do so). The guidelines tend to be created and maintained by a consensus of a cross-section of industry experts who develop the reference material. The key point in relation to best practice guidelines is that they can be selectively applied – i.e. take the good bits!

Standards

Examples: ISO9001, ISO27001, BS25999

Standards are more mandatory than best practice guides. They are published by standards organisations, both regional and international. They are widely recognised and an organisation can be independently certified to and regularly audited against. Generally here it’s all or nothing – if you do not satisfy the various controls within the standard, you are non compliant.

Recognised Measurement Techniques

Example: CMMI, Six Sigma

Recognised measurement techniques seem to fall in between best practice guidelines and standards. They tend not to be developed by a standards body, instead often being developed by an organisation and over time see wider adoption. Wide industry recognition is important here, and like standards, an independent auditor can assess the organisation as to their compliance. The logic here though is that these measurement allow you to rate yourself against your competition, since you are all using the same metrics.

Which framework to pick on today?

For the purpose of this post and the topic at hand, I am going to pick on PMBOK only, but please bear in mind that the same arguments can be pretty much made with any of the other frameworks.

Now if any geeks have read this post thus far, and are used to religious wars based around your favourite operating system, you ain’t seen nothin’ yet when it comes to best practice frameworks. Just like the great platform wars of Microsoft vs *nix, there are similar schools of thought as to which framework is "better" than the other. A practitioner of one framework will commonly poo-poo another framework. Also like the platform wars, there is always considerable criticism of the more popular frameworks like Six Sigma, ISO9001 and PMBOK because they are more widely used and therefore, subject to more (mis)interpretation, dogma, certification waving and the like.

Before I particularly pick on PMBOK however, the inevitable question from an organisation perspective is, "Which framework is right for me?"

Hmm – I wonder if that innocent question is a wicked problem in the making?

Not many people have read all frameworks in depth, because no matter which framework you pick, you are setting yourself up for a fairly dry read. For some insane reason I like them and while everyone else downloads porn, I actually read these things! Most of them are several hundred pages of material that will cure even the most vicious case of insomnia. In my opinion the most readable one is COBiT, but given that it’s pitched at management, it has to have lots of nice pictures

The reality is that you’re either going to ask a consultant to tell you what to adopt or start a heck of a lot of reading. Only a true pragmatist would do the latter, because they by nature don’t trust the consultant No matter how you decide a framework is for you, you will quickly come across some academic telling you that you have to actually combine them to achieve "full governance". Sheesh – so many books., so little time

History of "Waterfall"

So, let’s get back to picking on PMBOK. In software development, and the project management around it, the term "waterfall" is a bit of a dirty word these days. The term originates from a paper written by Dr. Winston Royce around the time of Horst Rittel (1970). For reference, his paper is available online.

The basic idea I’m sure is very familiar to you. Anybody remotely connected to software development or project management will be familiar with this approach.

Gather data -> Analyze data -> Formulate solution -> Implement solution

PMBOK basically has the following "Process Groups" that are logically similar.

Initiating -> Planning -> Executing -> Controlling -> Closing

For many years,  conventional wisdom in project management and software development was to follow an orderly and linear process based on Royce’s philosophy. The term “Waterfall model,” comes from the image a waterfall as the project “flows” down each of the discrete steps.

I find it interesting that Royce’s paper managed to establish itself as the underlying philosophy for many prevailing project management and software design methods. Rittell’s work on the other hand, did not receive the same coverage and has largely been ignored by comparison.

It is little wonder then, that many PMBOK practitioners have the waterfall model so ingrained into their thinking. Although I believe that it is misguided, PMBOK and many other frameworks are associated closely with waterfall. I have worked within a much-vaunted PMO (Program Management Office) environment at two different organisations, and in both cases, the PMO was based on an extremely rigid interpretation of the PMBOK and waterfall philosophy.

Waterfall – Predicated on false assumptions?

For this next section, I have to offer my sincere thanks to Chris Chapman, who made me aware of a subtle yet important fact with the waterfall model. He wrote a brilliant post entitled "Observations on the Rigor of Waterfall", and referred to a post from David Christiansen. Both authors do a great job in systematically pulling apart some of the misconceptions of the waterfall model (and I urge you to read both brilliant posts). Probably the most interesting thing is the following statement diagram and quote from Royce’s paper…

I believe in this concept, but the implementation described above is risky and invites failure… The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input/output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. The required design changes are likely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modified, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a 100-percent overrun in schedule and/or costs.

So Royce in his original paper actually recognises that the waterfall model is risky and invited failure! Why hasn’t this important fact been mentioned, made it into the standard theory of any best practice framework?  To be fair on Royce though, he does go on to say:

I believe the illustrated approach to be fundamentally sound. The remainder of this discussion presents five additional features that must be added to this basic approach to eliminate most of the development risks.

Has Waterfall been misrepresented? You be the judge.

How we really solve problems…

Conklin observed that when faced with a novel and complex problem, we humans do not naturally start by gathering data about a problem. instead, understanding of a problem can only come from the thought process of creating solutions, and relating them back to the original problem. The green line in the chart to the left illustrates this. Conklin also notes that understanding continued to evolve all the way through the experiment. He concludes that "understanding" is something that evolves continually. the "real issue" is sometimes a moving target.

Is there a place for the linear approach?

You might get the idea in this post that I am dumping on waterfall completely. That is not the case at all. In my case, I feel that I don’t have enough experience to make the call, but it doesn’t take too much googling to find some great opinions. I highly recommend reading Mike Bianchi, Dave Nicolette and Abrachan Pudusserry. Additionally, one really excellent paper by David Longstreet takes a very six-sigma style approach (in God we trust, all others bring data) to criticise agile type methods.

In my experience, certainly in infrastructure projects that I have been involved in, phased approach has served us well. To understand why is a whole separate post, but I feel that certain types of problems lend themselves to the waterfall philosophy, but some may not. Obviously the trick is understanding the type of projects that have a natural leaning towards waterfall as opposed to the alternatives.

When I look at successful infrastructure projects, they tend to work because the requirements are fairly static. Take Exchange server as an example. Once you know how many sites, how many users, the communications infrastructure to site, the mailbox requirements and the like you can pretty much develop a project plan with reliable estimates of cost and time. If you ask me to plan a SharePoint farm from planning, sizing, infrastructure, governance and training I could also give you an answer with a fair degree of confidence as I’ve done many times. But then by definition, we are not talking about a wicked problem are we?

Dave Nicolette’s article in particular takes a really good look at the characteristics of waterfall versus agile and I agree completely with his summary.

It is little surprise that the left side of the above table is typical of wicked problems and the right are not. As a result, all of the criteria that he lists on the right side of the above table results in the green line in Conklin’s chart fairly evenly matching the red line. You do not need to skip between problem to solution anymore and aligns relatively closely with the red line. Each successive time you do the same implementation reduces the spikiness of the green line.

But unfortunately for us all, many SharePoint projects have a big product development phase in there as well. More often than not, that little green line starts to spike again.

SharePoint Projects = Fluid Requirements

We spent several posts on SharePoint considerations from the Microsoft effect, the panacea effect, point vs platform, the new product factor, buzzword abuse, product complexity, organisational maturity, product skills, infrastructure complexity, information architecture complexity, governance complexity, developer skills, junk product DNA, branding, etc.

That is a lot of considerations! Therefore, a lot of soul searching, dialogue and shared understanding among stakeholders is required!

Is it little wonder then, that people aren’t sure what they want?

Is it little wonder then, that people do not have a shared understanding of the truth?

Is it little wonder then, that people have a propensity to jump into a new product before they have fully appreciated the complexity of what they are getting themselves into?

More importantly still..

Is it little wonder then, that PMBOK in its rigid, phased approach is going to make any significant impact on the the above problems? No, in fact it can make it worse and set up the project for failure from the very beginning.

PMBOK – Just misunderstood…

Earlier in this post, I observed that the more popular frameworks like ITIL, PMBOK and Six Sigma attract criticism about their success rate. Six Sigma, in particular, has a running joke that its success rate is around two sigma. Aside from the fact that implementing a framework is a project in itself and therefore subject to many of the same issues that a SharePoint project encounters, I believe that a big factor in this criticism stems from applying a very rigid, "one size fits all" approach to the implementation of the framework.

Thus, despite what this post may imply, I am in no way saying that all of these frameworks are bad. To the contrary, I believe that every one that I have studied has a lot to offer and the problem is all in the assumptions and execution of the given framework. (Wicked problem fodder!)

So, in defence of PMBOK, and for that matter most of the methodologies that I have read, is that the best practice frameworks specifically encourage practitioners to apply the guidelines in a manner that best suits their circumstances. Probably one of the best write-ups to illustrate this in relation to PMBOK and Agile software development, was a 4 part series written by Michele Sliger.

Specifically, on page 20 of the PMBOK, the text states "There is no single best way to define an ideal project life cycle". Furthermore, the PMBOK goes on to state "The project manager, in collaboration with the project team, is always responsible for determining what processes are appropriate, and the appropriate degree of rigor for each process, for any given project".

To all the PMBOK practitioners that skim this article and think that I am dumping on that framework, please don’t misunderstand. I like PMBOK a lot, I just dislike dogmatic interpretation of what it offers. The same applies to pretty much every other framework too, including the agile ones. In a project like SharePoint, where it should now be very clear that requirements are often (but not always) fluid and understanding among stakeholders definitely varies. Assuming that the root of all problems would be solved via a framework is likely misguided.

It’s the "problem", not the "process"

If you take anything away from this article, here are the key points:

• Do not mistake a lack of understanding of the problem by faulting the process used. It usually isn’t the root cause.
• Do not assume that improvement frameworks are the panacea to cure previous failures.
• Do not assume that improvement frameworks must be implemented in their entirety and in a standard way,
• Consider that SharePoint projects by their nature have characteristics that do not lend themselves to improvement frameworks that are implemented with a strict philosophy,
• Consider that implementing an improvement framework is a project in itself. How likely is its implementation going to suffer from the same problems as your original failed project?

Summing Up

So, here we are. After 8 posts I am finally spent with this topic. There are other project failure topics, but I fear that to keep going would start to bore people to tears.

What would be most satisfying to me is that somewhere in the world, someone has found this series of posts, recognised that the symptoms I described are affecting their projects and was able to use the content to help your project in some way before things became terminal. Like many afflictions in life, one of the main factors on the road to recovery is shared recognition of the problem. If you can get to that point then you are halfway there.

I sincerely hope that you have found this series useful. I really had little idea when I started the first post, that it would end up being one of eight. Nor did I really have much idea of the direction it would take. But I am pretty pleased with the outcome and along the way I’ve been able to meet and chat to some really brilliant minds out there and I have gained a hell of a lot personally from writing it. To all who have provided feedback or written nice things about this series, a huge thanks and if you ever are in sunny Perth, then beers are definitely on me.

Thanks people!

Paul

                      

No Tags

I hope that you had a bit of fun with my first “choose your own adventure” story. (Do yourself a favour and read that first!)

Writing that one was most fun. Did you suddenly think of the names of current and former colleagues as you read it?

Anyway, now it is time for you to sit on my virtual knee and listen to the moral of that story because believe it or not, I actually had a really important point to get across.

The two catalysts…

Recovering CPA Mike shares similar views to me in a lot of areas. He wrote about possible reasons why SharePoint initiatives rarely have any decent form of ROI analysis performed on them. He talks, among other things of a ‘first wave’ of technology buyers, not used to ROI analysis. He also mentions the whole “must have” mentality of popular technology.

He’s dead right on both counts and my additional take on it is this.

Right now, there are only two types of SharePoint projects I seem to be working on. Those that are initiated via the IT department, or those that are initiated because a new CEO or senior manager is a previous SharePoint user and wants it.

I suspect that for the next 6-12 months, these two will be quite predominant catalysts.

The latter is actually my preferred scenario, but it does cause me some short term pain. In this scenario, the IT department usually is caught “on the hop”, to some extent, as they have usually very little SharePoint exposure or awareness.

The short term pain is based around me having to fast-track SharePoint product understanding at at infrastructure, application and governance level. This has to be performed among all the different IT department hearts and minds. This is not as straightforward as it may seem. Often IT people can actually take longer to ‘get it’ then non IT. As I demonstrated in the light-hearted version of this post, there are various different hearts and minds that have to be won over in different ways. (Some will never be won over).

But the nice thing about this scenario is buy-in is generally assured. When CEO’s say they want something, it generally gets done and I get to skip a lot of long, boring meetings with little outcome.

I’ve seen this scenario screwed up also, but that is for another post. This article is all about the other scenario – the one that carries more risk, despite best intentions.

If You Build It, They Will Come?

So here we are, no matter how it came to be, the IT department has seen SharePoint and likes it. (Well, not everyone in IT but those who have a say in it .

[ Snip the many meetings, arguments, dogmatic agendas and general whining to get to this point ]

The strategy for moving forwards seems to be oriented around the proposition of that Kevin Costner movie, “Field of Dreams”

“If you build it, they will come”

(Oh god ! Now I have admitted I watched a Kevin Costner movie! Please don’t worry as I am cool – I listen to Opeth )

What I mean by  the “If you build it, they will come” mentality, is the commonly adopted premise that if you can demonstrate how IT uses a tool like SharePoint to improve how it goes about managing its affairs, then it is a shoe-in to sell to the rest of the organisation, right?

I beg to differ, for many reasons. But let’s take a closer look on why this approach is so often used right now.

Products, Products, Products (and some definition of terms)!

I.T departments are service providers. They operate, manage and are accountable for IT Services. IT Services are provided by IT infrastructure and the governance of that IT infrastructure.

IT Infrastructure is all of the “products” that combine in various ways to provide the IT services. Examples of infrastructure include your physical servers, network devices, storage area networks and UPS. Examples of infrastructure include also applications like Microsoft Exchange, SQL Server, Apache webserver and operating systems such as Windows 2003 and *nix.

IT departments are good at this stuff (in theory anyway) because they tend to see the IT world as the management of products that provide service. They look at how these products interact and have a very good understanding of the dependencies, risks and day-to-day management of these products. My former world used to be Cisco networks, Active Directory, SQL Server, Exchange, Redundant storage, backup agents, etc. I cared little for the Information Assets being provided by these IT Services because I was rarely a user of those Information Assets!. If the IT services were available, then I knew that the information assets they facilitate were available and that’s all I was accountable for!

So is SharePoint is just another product then? Let me ask you this? How many IT departments do an ERP install by themselves? Not many!

Information Assets

Aha! I just used a new term before. “Information Asset”. I originally came across the term in when I worked with ISO17799/27001 a few years back. However I don’t quite think the ISO definition is ideal because it also uses the “Asset” term for IT products and services as I have defined them in the previous section. (I have always found this much harder to explain to people when calling everything an “Asset”).

So instead, we will stick to my previous definitions of IT Services and IT Infrastructure and use this definition for Information Asset which I like much better.

“An Information Asset is a definable piece of information, stored in any manner which is recognised as ‘valuable’ to the organisation”

The above definition you will note does not talk about information assets in terms of the services that provide it. Instead it is focused on it’s intrinsic value. Below are 3 characteristics of information assets with intrinsic value

• Information assets are recognised to be of value to the organisation.
• Information assets are not easily replaceable without cost, skill, time, resources or a combination.
• Information assets form a part of the organisation’s corporate identity, without which, the organisation may be threatened.

The I.T Department and Intrinsic Value

IT departments are generally inward facing in that they often know the least about the information assets that have real intrinsic value to the organisation. They know all about the IT Services and Infrastructure that provides those services however.

But for many other sections of the organisation it is the other way around. They have no significant understanding or appreciation of the IT services or infrastructure.  Nor should they – it’s your job! The majority of non IT staff are accountable for increasing the intrinsic value of the organisations information assets. So long as you in IT ensure the confidentiality, integrity and availability of the IT services that support the information assets, you are doing your job. ( Nobody will appreciate it, but you are still doing your job )

A Tool Looking for a Problem

So back to my premise. The IT department likes SharePoint, sees its potential and thinks it could be good for the organisation. So let’s use it for our own internal use, and then use this as a showcase of how it can be used elsewhere in the business to improve the way things run in the business.

Improve what? By how much and how soon? What is current the problem that is resulting in operational wastage and therefore reduced earnings per share? How much is it costing us per annum? What percentage of improvement can we expect by this investment and how much confidence do you have in your estimates?.

I’m sure you can answer this in terms of internal IT service performance via quantifiable evidence like frequency and reason for helpdesk calls, number of helpdesk staff over time, staff retention rates, backup/restore stats, etc. But you are exceedingly unlikely to be able to answer it from anywhere outside of IT.

So what problem do you want to solve for the business? At a macro level its easy to say, “SharePoint has this wonderful feature X that does this and it will solve so many problems”, but it’s not enough… not by a long shot

and who are you to talk anyway?

IT Departments also more often than not, do not exactly have the sort of quality control and organisational efficiency that they would like to have. If your helpdesk queue has 167 outstanding jobs, with poor clearance rates and turnaround time. Your existing infrastructure is poorly documented, change control and configuration management is questionable. Staff are unhappy, turnover is a problem and politics/dogma gets in the way of progress.

So, you are not exactly setting an example here. Will yet another tool solve a bunch of problems that essentially people/process in nature?

More importantly, will the business take you seriously? What is your track record like?

Improving the approach (you can still fiddle a bit )

So fine, use SharePoint in IT. (I’m not against it – I’m just cautioning against the ‘typical’ IT approach of the tool before the problem.). But do yourself a favour and define a problem to solve first. The problem MUST, MUST, MUST be a measurable one and it can’t be trying to bring about world peace. So instead of writing

“We need a change control process” or “We need a new helpdesk system”

define a quantifiable goal such as:

“Reducing helpdesk calls per day from the current average of 140 per day to a goal of 70 per day in 4 months (50% reduction)”, thus saving us $1,240,000 per annum”

Don’t pull the savings estimate out of your rear end either! State your assumptions on how you came up with this figure. Gut feel almost always is not good enough. (For what it’s worth, I have blogged a little on doing this last year, but a lot more is to come!)

Now you have a clear goal to achieve and you can discuss how to achieve it. You will have to do an analysis/measurement phase, where you mine your data (or embark on a collection phase if you have none), to determine the causes of the high cost . You will examine the processes and systems that have allowed this to happen and slowly weed out the candidate causes until you hit the one or two that have the most impact on the problem.

Interestingly, using our helpdesk example, you may find that the root cause is not the helpdesk per se, so putting resources into tracking helpdesk calls in SharePoint is of less value than optimising the flawed process causing the calls. That process may not be an IT owned process - interesting eh! It may be that you use it for a non-IT business process problem after all!

Anyhow, the goal is that you will be able to provide a re-engineered and optimised process. With the help of a tool like SharePoint, along with training and a degree of cultural change, you can work to achieve this goal. Chances are, the SharePoint bit takes less time than the analysis/data gathering/data mining and process optimisation phases.

So after 4 months, you can easily quantify whether you achieved your goal and if you did, you utterly rock and the entire team can go to the pub for the afternoon!

Conclusion (Now we are getting somewhere!)

Now you are in a much better position to go back to the business with a SharePoint proposition, demonstrating how in 4 months, you were able to use it to help you optimise a business process that has saved/made money.

This is what business wants to hear! In addition, this now gives you the sort of springboard and model that can be used to examine other problem areas of the business. You have also kicked a goal via your departmental staff learning how to manage the SharePoint IT ‘service’, and its various infrastructure components. That is one less cost you have to factor in with your financial models

Phew! I think I am just about done!

My personal interest in process optimisation stems from my interest in improving the bridge between financial justification of technology and the technology itself. I intend to write more on techniques for process optimisation in further blogs and how I went about setting up an IT portal based on elements of ISO and ITIL. For those of you that find this information useful (probably not so much the tech guys , please let me know.

regards

Paul

                      

No Tags

That is Governance!

May I start by quoting from that wise band “Faith No More” and their first hit “We Care A Lot”, who in 1987 were of course thinking of collaborative document management when they wrote..

“We care a lot about the gamblers and the pushers and the geeks
We care a lot about the crack and smack and whack that hits the street
We care a lot about the welfare of all the boys and girls
We care a lot about you people cause we’re out to save the world

And it’s a dirty job but someone’s gotta do it”

Now, we are only going to talk about governance in relation to branding here, which is really a pimple on the butt of the overall governance of SharePoint. In saying that though, much of the philosophical basis from which I write this article is pretty much applied to the other areas of SharePoint governance anyhow.

So, what are we trying to do anyway? If you go and google or wikipedia the subject of governance, you can pretty much summarise the academic definition as “cover your ass”! Whether you are answerable to the CEO of a blue chip with a billion dollar market cap, or to the CEO of a 25 user small business, if you are going to take the fall, you want to make sure you take a few others with you, right?

Therefore, one of the first governance issues to deal with is the fact that we need a team with well defined roles and responsibilities. Each team will cover off different areas of SharePoint governance that can broadly be grouped into a few different categories:

• Project Management
• Infrastructure
• Development/Design
• Operation
• Training

Now, you may group things a little differently then me, but you get the idea. I have deliberately NOT listed design (and with it branding) separately because it depends on the type of SharePoint project being implemented. If it is a web content management oriented project (like an internet site), then design probably warrants its own category. However, if it is a collaborative project, then design is quite likely part of development process.

I think this point deserves further consideration.

WCM vs Collaborative Sites

SharePoint is a multipurpose beast. It can be used as a straight out CMS system and compete with the likes of Joomla, Drupal, RedDot and EpiServer. It can also be used as a document management system, management reporting tool, project tracking system, collaboration platform and so on and so forth…

When used as a CMS only, it’s pretty good, all things considered. There are some pretty snazzy examples of WCM sites that make you stop and think, “wow – is that SharePoint?”. But the typical visitor to a WCM based SharePoint site will not likely be using many of the other goodies that SharePoint offers. In these type of sites, there are a few content authors, but mostly the people using the site are visitors consuming the web content. Really, that’s about it.

But if you have been reading this series of articles, I spent the first three talking about how much of a pain the core.css and application.master issue is on corporate branding. If you haven’t, I suggest taking a look.

The issue is that many aspects of collaborative functionality use parts of SharePoint that is tough to brand. Cameron Moll has written a brilliant article on this issue and I consider it mandatory reading. Many collaborative functions are based on a central master page called APPLICATION.MASTER. Therefore, if you have made a well branded master page for your content, the user experience will be inconsistent when they perform certain administrative type tasks.

Cameron nails the issue perfectly here: “This is all perfectly fine in the CMS scenario, as only an infinitesimal fraction of your users will switch between published screens and admin screens. However, in the collaboration scenario, nearly any user can, and will, switch between published screens and admin screens to complete tasks. Because your skinning won’t be reflected in the admin, what should otherwise be a continuous visual flow for users instead becomes a jarring transition from your beautiful theme to SharePoint’s vanilla theme and back again”.

Now this entire series of articles has been based on the ‘other’ side of SharePoint (i.e. *not* WCM). In my opinion, in a purely collaborative SharePoint implementation, branding should be one of the last things you do. Your time is better spent refining collaborative functionality. However if you are doing WCM, it should be one of the first things to do.

You can imagine then, that the worst case scenario for all involved in a SharePoint project is mixing WCM and collaboration. It carries with it the exact same type of problems and risks that I outlined in my article on collaborative document management vs records management. Try and do both, and you will not only dilute the benefits of each, but you end up with an over time/budget process with plenty of pissed users and stakeholders.

Moral of the story? Decide what you want to be!

So let’s move on.

Best Practice Standards

A while back, I posted a series of articles on best practice methodologies and the laws around compliance. For many areas of governance, much of the work is done for you by these best practice standards. Certainly, aspects of the ITIL books on ICT change management, deployment management, design and planning and operations management will factor in branding governance.

I hope for people who have read those articles wondering why I included my four articles in a SharePoint oriented blog, you should see it all start to come together now. They are your philosophical starting point to approaching SharePoint governance

For what it’s worth, although ITIL is currently flavour of the month for many IT departments, I think that you can get a lot out of ISO27000/27001 and COBiT as well. ITIL is very inwards facing in a lot of its subject areas. What I mean by that is that non IT Senior management and board level tend not to give a crap about ITIL, but are likely to have more of an interest in COBiT, particularly in the US (not just because it has prettier pictures either). COBiT is a much “higher level” standard than ITIL, and is a better philosophical starting point than ITIL which is more prescriptive. In reality the standards well complement each other, but if you are wondering which one to start on, I’d go with COBiT. (Another much more detailed post on SharePoint governance against these standards is in the works).

It’s a dirty job but someone’s gotta do it

So let’s start with some high level governance principles for branding a collaborative SharePoint site. Here is what we need to define and document.

• A management structure for supporting the development and deployment of branded MOSS Sites
• Key roles and responsibilities within this structure
• Policies, standards, guidelines, and decision processes required to support the deployment of branded SharePoint Sites

What are the rationales for setting up a framework to assign accountabilities?

• Knowing who is responsible for making decisions
• Knowing how decisions are made
• Knowing who is responsible for implementing decisions

In addition to this, branding governance aims to:

• Consistently provide a high quality user experience by ensuring that the branding governance plan is followed
• Establish clear decision making authority and escalation criteria so that issues are resolved on a timely basis
• Ensure compliance with established corporate style guide

Roles and Responsibilities

ISO27000/27001 puts a big emphasis on accountability. Without a strong culture of accountability, it is very difficult to adopt governance without it getting out of hand. One organisation I worked for had mapped out their process for dealing with the service desk and it was too big for an A4 sized page. It had to be printed on poster size and was the ugliest flowchart you have ever seen. This is a common symptom when clear lines of accountability do not exist. There is safety in complexity and ambiguity.

Thus, it is vitally important that the right roles are assigned the right responsibilities and people are fully aware of where their accountability lies.

The following table is a typical example of the roles and responsibilities of personnel involved in the governance of the MOSS branding. Depending on the size of your organisation, consolidate the roles and positions to suit. I’ve put the responsibility definitions into cleverworkarounds’ plain english to make it more interesting, but you may want to formalise these a little more if you use this

Role	Position	Responsibility
Steering Committee	Senior Divisional Heads Marketing Manager IT Manager SharePoint Architect	The buck stops here! If it all goes to hell, these are the guys who get burned! (but have no doubt they will apportion the blame all round)As a result of that prospect, they tend to like to signoff on all branding things! (and everything else too)Oddly enough, they also therefore believe that they provide vision and direction to the MOSS branding
Business Owner	Board Level Project Sponsor	The person who writes the cheques! They are who the steering committee answers to. Thus, people are generally very nice to them!They get to set the direction of what they want, even if their branding taste is dodgy (If they try and mix WCM and Collaboration try and tactfully dissuade them)
SharePoint Support Team	Application Support Manager SharePoint Administrator SharePoint Designer SharePoint Developer	These guys take all the vision stuff from the Business Owner and Steering Committee and actually designs and develops the corporate MOSS brandThis team also resolves operational issues and enforces best practice in relation to the MOSS branding solution
Site Collection Owner	SharePoint Administrator	Activation of branding features is performed by the site collection owner
Infrastructure Operations Team	Farm Owner Site Collection Owner Infrastructure Owner	These guys keep the support team honest. They ensure that branding is packaged up according to policy and install those features/solutions to the farm. This ensures the technical integrity of the branding development

Policies and Standards

So now we have defined who is responsible for what, we can now put it all into policy.

Corporate Style Guide

The first thing you need to do is define a corporate style guide, or locate the existing one and refresh it via the steering committee. The style guide houses all relevant standards, requirements, and recommendations surrounding corporate brand. It is not a technical document, as it covers the tone, presentation and all implementation aspects, specifications, attributes and elements, summed up to present a brand consistently throughout all media.

This guide changes over time and its owner is likely the marketing division of the organisation and not just the SharePoint branding steering committee. It is best to engage with the division or individual that owns this guide, to ensure that the steering committee is in the loop during periods of review and updating.

Once you have an approved style guide, you can now apply it to SharePoint components.

Master Pages

If you adopt the principles of my earlier posts in this series, you may not need to have more than a single master page for your entire farm. A well defined master page with clever use of CSS override techniques allow you to offer different branding, yet using a single master page. If this is a realistic prospect for you, then it makes sense to enshrine in policy that you will only maintain one corporate master page.

Best to leave the master page in the master page gallery for the site collection. That document library has versioning and content approvals enabled. Thus, it eases change and configuration management, as well as packaging and deployment.

The master page should be named according to a consistent convention. I personally like to prepend the company name to the master pages, as well as layout pages as then it is very easy to see what components are customised from what is build in. I enshrine this in the branding policy as a mandatory requirement.

That master page should be well documented with all of the modifications made to it. Typically, if you have modified say, DEFAULT.MASTER, you will have to document modifications like

• Any assembly references added to the master page (see this post if you want an explanation)
• Any hard-coded links to other CSS files and the definition of new styles
• Modification of the HTML structure of the master page (e.g. Adding left and right borders to the default master page)
• Any examples of non-compliance with the corporate style guide

Layout Pages

A collaborative style SharePoint site may require additional layout pages. The rules pretty much apply as per master pages.

• Name them consistently with master pages (eg prepend company name)
• Document their setup, where it is used and why it was required

Styles

Corporate style sheet guidelines should be documented and these are a direct translation from the corporate style guide. Logo’s, fonts, formatting, colors, backgrounds, etc are documented either as mandatory standards or recommended guidelines in the CSS style guide.

In addition, CSS style sheets should be both well documented within the CSS file using comments, as well as documentation around the implementation of the style. If you have overridden say, some of CORE.CSS, then mention it in the comments for the style why it was done.

CSS styles should live in the Style Library for each site collection. Unless you have an exceptional reason, there is no point in reinventing the wheel and putting them anywhere else. Naming of CSS sheets should also be consistent with the master pages and page layouts. So if I was writing a governance policy for ABC corporation, I would use something like

• ABCDefault.master
• ABCWelcomeSplash.aspx
• ABCDefaultStyle.CSS

Site Templates

Although I didn’t cover site templates in this series on branding, the concept is simple. Once you have set up a site the way you want it, you can save it as a template that can be re-used for other sites. Certainly, it is common for project oriented companies to create a project site template with a particular combination of lists, web-parts, workflows, event handlers and libraries. Each time a new project is initiated, a site is created for that project based on the template.

This helps us to achieve the governance of a consistent user experience, as well as improving change and configuration management.

The process of creating a site template is potentially complex as the amount of collaborative functionality provided grows over time. Therefore, guidelines for the development of site templates must be developed to ensure they meet minimum standards. Potentially, site templates will be used by different organisational groups, with their own unique requirements. You will need to find a balance between overall site/branding consistency versus the costs and overheads of accommodating unique requirements.

Therefore, a formal approval process culminating with steering committee approval should be in place to manage the ongoing management of every corporate site template. The corporate style guide will also very likely influence the look and feel of custom site templates.

For each template, you also need to determine which parts of the template may be changed by site owners, and which may not. This can be enforced by security settings, but you still need the official policy to fall back on if tool based controls do not give you what you need.

Having said all of this, much of the governance around site templates is focused on non-branding considerations such as security, audiences, functionality and the like. We will not discuss this here as it is not really a branding consideration.

The point is, site templates have similar branding governance requirements to master pages, page layouts and styles.

Operational Management

In the previous section I looked at the governance requirements of branding from a SharePoint building block point of view. Now lets take an ITIL oriented perspective

Change management and approvals

With change management, go straight to ITIL and get what you need as far as process is concerned. ITIL defines the objective of change management as:

“The objective of Change Management in this context is to ensure that standardized methods and procedures are used for efficient and prompt handling of all changes to controlled IT infrastructure, in order to minimise the number and impact of any related Incidents upon service.

ITIL defines a CAB or change authority board that advises the ‘change manager’ prior to change approval. For my money, the steering committee will delegate the CAB function to the other groups who assume *custodianship* of the process. For example, the steering committee still bear ultimate accountability over the deployment of branding, but once the policy has been set, they delegate the validation of the deployment to the IT Infrastructure Operations Team.

Now bear in mind, we are talking about branding only here, and ITIL in the wrong hands can create ridiculous amounts of red tape.

But in relation to change management, this is the sort of stuff that should be considered.

• Change justification. Have we recorded the request (who and why)?
• Assess the impact of the change (cost vs benefit)
• Test the change. Any branding changes require comprehensive testing on a non production environment. You never know how various web-parts render, and a formal testing methodology must be defined to ensure that say, your latest snazzy style turns out to make the calendar view look crap.
• Packaging and deployment. Updates to branding should be packaged and deployed in accordance with corporate policy. The goal here is to ensure efficient, consistent deployment with easy means of rollback. We will delve more into packaging and deployment in a moment.
• Implement the change, update documentation and logs
• Conduct post implementation review of the change

Packaging and deployment of branding

Well, unless you are reading this series backwards, I think you should have a fair idea by now that I recommend that all branding should be implemented as a SharePoint solution. Check article four, five and six for more info. For me personally, I consider that if an application developer does not comply with this requirement (or whines about having to comply), then they have no serious idea about the importance of governance. That for me is a risk that I would prefer not to live with.

You will need to ensure that if 3rd party developers are doing your branding, that they are aware of all your other branding requirements, such as naming conventions so that the content packaged up inside the solution follows your governance standard.

When branding is packaged up into a SharePoint solution, we have a single file than can be easily deployed to the farm, upgraded and rolled back. In a disaster recovery situation, re-applying your branding is literally as easy as installing the solution and activating it.

Source control

On a large scale site, you may opt to use source control like Subversion for your branding components, especially if you are writing custom event receiver assemblies as I described in article six.

But then again, SharePoint itself is actually a great platform for implementing a governance site. You can make use of version enabled document libraries to hold your packaged solutions, procedures, standards and guidelines and other related content. Plus, you can use a calendar list+workflow for scheduling and notifying stakeholders of updates or changes, a task list for logging and tracking issues and infopath+workflows for automating the change management process.

Furthermore, I have found Colligo Reader to be very useful for SharePoint governance sites, as it alleviates the chicken-egg risk of storing all of your governance and change history in the same tool that you are governing. Often I am asked, “what if SharePoint is down, how can I get to my documentation?”.

Colligo allows you to have a full offline sync of all your governance lists, documents and views, thereby significantly reducing this risk and that barrier to adoption. I also suggest that you buy a copy of this product and add to your governance policy that you will always keep an up to date sync of your governance site offline.

Summing Up

So finally it ends. I originally thought I’d cover it all in 3 articles but in the end it took 7 large articles. But I’ve now gotten to the end of this arduous task of attempting to cover SharePoint branding from end-to-end. I hope that you have found this series of articles of use, and I appreciate you for sticking with me. If these articles were of help to you, please drop me a line and let me know. If you really want to show your appreciation, and you live in Perth, West Australia, I’m quite partial to Hoegaarden (but if its your buy I’ll drink anything! )

over and out

Paul

                      

No Tags

For part 1 of this presentation, view this post, part 2 this post and part 3 here.

ISO17799/27001

• Started life as BS7799-1 and 2
• BS7799-1 became ISO17799. BS7799-2 is recently ISO27001
• There is an Australian version "AS/NZS ISO/IEC 17799:2006"
• Internationally recognized standards for best practice to information security management
• High level and broad in scope
• Not a technical standard
• Not product or technology driven

ISO 17799 is a direct descendant of part of the British Standard Institute (BSI) Information Security Management standard BS 7799. The BSI (www.bsi-global.com) has long been proactive in the evolving arena of Information Security.

The BS 7799 standard consists of:

• Part 1: Information Technology-Code of practice for information security management
• Part 2: Information security management systems-Specification with guidance for use.

BS7799 was revised several times, and by 2000 information security had become headline news and a concern to computer users worldwide. Demand grew for an internationally recognized information security standard under the aegis of an internationally recognized body, such as the ISO. This demand led to the "fast tracking" of BS 7799 Part 1 by the BSI, culminating in its first release by ISO as ISO/IEC 17799:2000 in December 2000.

In 2006, adoption of BS 7799 Part 2 for ISO standardization was completed and now forms ISO27001.

ISO17799 vs. ISO27001

• ISO17799 is a code of practice – like COBIT it deals with ‘what’, not ‘how’.
• ISO27001 This is the ‘specification’ for an Information Security Management System (ISMS). It is the means to measure, monitor and control security management from a top down perspective. It essentially explains how to apply ISO 17799 and it is this part that can currently be certified against

Unlike COBIT, ISO17799 does not include any maturity model sections for evaluation. (incidentally, nor does ISO9000)

ISO 17799 is a code of practice for information security. It details hundreds of specific controls which may be applied to secure information and related assets. It comprises 115 pages organized over 15 major sections.

ISO 27001 is a specification for an Information Security Management System, sometimes abbreviated to ISMS. It is the foundation for third party audit and certification. It is quite small because it doesn’t actually list the controls, but more a methodology for auditing and measuring. It comprises 34 pages over 8 major sections.

ISO17799 is:

• an implementation guide based on suggestions.
• used as a means to evaluate and build a sound and comprehensive information security program.
• a list of controls an organization "should" consider.

ISO27001 is:

• an auditing guide based on requirements.
• used as a means to audit an organizations information security management system.
• a list of controls an organization "shall" address.

ISO17799 Domains

• Security Policy
• Security Organization
• Asset Management
• Personnel Security
• Physical and Environmental Security
• Communications and Operations Management
• Access Control
• System Development and Maintenance
• Business Continuity Management
• Risk Assessment and Treatment
• Compliance

ISO17799 divides up security into 12 domains.

Within each domain, information security control objectives (if you recall that is he same terminology as COBIT) are specified and a range of controls are outlined that are generally regarded as best practice means of achieving those objectives.

For each of the controls, implementation guidance is provided.

Specific controls are not mandated since each organization is expected to undertake a structured information security risk assessment process to determine its requirements before selecting controls that are appropriate to its particular circumstances (the introduction section outlines a risk assessment process

ISO/IEC 17799 is expected to be renamed ISO/IEC 27002 in 2007. The ISO/IEC 27000 series has been reserved for information security matters with a handful of related standards such as ISO/IEC 27001 having already been released and others such as ISO/IEC 27004 – Information Security Management Metrics and Measurement – currently in draft.

We will examine Asset Management domain as an example of ISO17799.

ISO17799 in relation to ITIL

• ISO 17799 only addresses the selection and management of information security controls.
• It is not interested in underlying implementation details. For example:
• ISO 17799 is not interested that you have the latest and greatest logging and analysis products.
• ISO 17799 is not interested in HOW you log.
• Product selection is usually an operational efficiency issue (i.e. ITIL)
• ISO 17799 is interested in:
  • WHAT you log (requirements).
  • WHY you log what you do (risk mitigation).
  • WHEN you log (tasks and schedules, window of vulnerability).
  • WHO is assigned log analysis duty (roles and responsibilities).
• Satisfying these ISO 17799 interests produces defensible specifications and configurations that may ultimately influence product selection and deployment. (feeds into ITIL)

ISO17799 Example: Asset Management

• 7.1 Responsibility for assets:
  • Objective:
  • To achieve and maintain appropriate protection of organizational assets. All assets should be accounted for and have a nominated owner.
  • Owners should be identified for all assets and the responsibility for the maintenance of appropriate controls should be assigned. The implementation of specific controls may be delegated by the owner as appropriate but the owner remains responsible for the proper protection of the assets.
• 7.2 Information Classification
• Implementation guidance is offered for all controls

Domain: Asset Management

7 Asset management

Control 7.1 Responsibility for assets

Control Objective: To achieve and maintain appropriate protection of organizational assets. All assets should be accounted for and have a nominated owner. Owners should be identified for all assets and the responsibility for the maintenance of appropriate controls should be assigned. The implementation of specific controls may be delegated by the owner as appropriate but the owner remains responsible for the proper protection of the assets.

7.1.1 Inventory of assets

Control

All assets should be clearly identified and an inventory of all important assets drawn up and maintained.

Implementation guidance

An organization should identify all assets and document the importance of these assets. The asset inventory should include all information necessary in order to recover from a disaster, including type of asset, format, location, backup information, license information, and a business value. The inventory should not duplicate other inventories unnecessarily, but it should be ensured that the content is aligned. In addition, ownership (see 7.1.2) and information classification (see 7.2) should be agreed and documented for each of the assets. Based on the importance of the asset, its business value and its security classification, levels of protection commensurate with the importance of the assets should be identified

Other information

There are many types of assets, including:

• information: databases and data files, contracts and agreements, system documentation, research information, user manuals, training material, operational or support procedures, business continuity plans, fallback arrangements, audit trails, and archived information;
• software assets: application software, system software, development tools, and utilities;
• physical assets: computer equipment, communications equipment, removable media, and other equipment;
• services: computing and communications services, general utilities, e.g. heating, lighting,power, and air-conditioning;
• people, and their qualifications, skills, and experience;
• intangibles, such as reputation and image of the organization.

Inventories of assets help to ensure that effective asset protection takes place, and may also be required for other business purposes, such as health and safety, insurance or financial (asset management) reasons. The process of compiling an inventory of assets is an important prerequisite of risk management

7.1.2 Ownership of assets

Control

All information and assets associated with information processing facilities should be owned2 by a designated part of the organization.

Implementation guidance

The asset owner should be responsible for:

• ensuring that information and assets associated with information processing facilities are appropriately classified;
• defining and periodically reviewing access restrictions and classifications, taking into account applicable access control policies.

Ownership may be allocated to:

• a business process;
• a defined set of activities;
• an application; or
• a defined set of data.

Other information

Routine tasks may be delegated, e.g. to a custodian looking after the asset on a daily bsis, but the responsibility remains with the owner.

In complex information systems it may be useful to designate groups of assets, which act together to provide a particular function as ‘services’. In this case the service owner is responsible for the delivery of the service, including the functioning of the assets, which provide it.

7.1.3 Acceptable use of assets

Control

Rules for the acceptable use of information and assets associated with information processing facilities should be identified, documented, and implemented.

Implementation guidance

All employees, contractors and third party users should follow rules for the acceptable use of information and assets associated with information processing facilities, including:

• rules for electronic mail and Internet usages (see 10.8);
• guidelines for the use of mobile devices, especially for the use outside the premises of the organization (see 11.7.1);

Specific rules or guidance should be provided by the relevant management. Employees, contractors and third party users using or having access to the organization’s assets should be aware of the limits existing for their use of organization’s information and assets associated with information processing facilities, and resources. They should be responsible for their use of any information processing resources, and of any such use carried out under their responsibility.

The term ‘owner’ identifies an individual or entity that has approved management responsibility for controlling the production, development, maintenance, use and security of the assets. The term ‘owner’ does not mean that the person actually has any property rights to the asset.

ISO17799 Example: Asset Management

• 7.1 Responsibility for assets:
• 7.2 Information Classification
  • Objective:
  • To ensure that information receives an appropriate level of protection.
  • Information should be classified to indicate the need, priorities, and expected degree of protection when handling the information.
  • Information has varying degrees of sensitivity and criticality. Some items may require an additional level of protection or special handling. An information classification scheme should be used to define an appropriate set of protection levels and communicate the need for special handling measures
• Implementation guidance is offered for all controls

7.2 Information classification

Objective: To ensure that information receives an appropriate level of protection.

Information should be classified to indicate the need, priorities, and expected degree of protection when handling the information.

Information has varying degrees of sensitivity and criticality. Some items may require an additional level of protection or special handling. An information classification scheme should be used to define an appropriate set of protection levels and communicate the need for special handling measures.

7.2.1 Classification guidelines

Control

Information should be classified in terms of its value, legal requirements, sensitivity, and criticality to the organization.

Implementation guidance

Classifications and associated protective controls for information should take account of business needs for sharing or restricting information and the business impacts associated with such needs. Classification guidelines should include conventions for initial classification and reclassification over time; in accordance with some predetermined access control policy (see 11.1.1). It should be the responsibility of the asset owner (see 7.1.2) to define the classification of an asset, periodically review it, and ensure it is kept up to date and at the appropriate level. The classification should take account of the aggregation effect mentioned in 10.7.2. Consideration should be given to the number of classification categories and the benefits to be gained from their use. Overly complex schemes may become cumbersome and uneconomic to use or prove impractical. Care should be taken in interpreting classification labels on documents from other organizations, which may have different definitions for the same or similarly named labels.

Other Information

The level of protection can be assessed by analyzing confidentiality, integrity and availability and any other requirements for the information considered.

Information often ceases to be sensitive or critical after a certain period of time, for example, when the information has been made public. These aspects should be taken into account, as over-classification can lead to the implementation of unnecessary controls resulting in additional expense.

Considering documents with similar security requirements together when assigning classification levels might help to simplify the classification task.

In general, the classification given to information is a shorthand way of determining how this information is to be handled and protected.

7.2.2 Information labeling and handling

Control

An appropriate set of procedures for information labeling and handling should be developed and implemented in accordance with the classification scheme adopted by the organization.

Implementation guidance

Procedures for information labeling need to cover information assets in physical and electronic formats.

Output from systems containing information that is classified as being sensitive or critical should carry an appropriate classification label (in the output). The labeling should reflect the classification according to the rules established in 7.2.1. Items for consideration include printed reports, screen displays, recorded media (e.g. tapes, disks, CDs), electronic messages, and file transfers. For each classification level, handling procedures including the secure processing, storage, transmission, declassification, and destruction should be defined. This should also include the procedures for chain of custody and logging of any security relevant event. Agreements with other organizations that include information sharing should include procedures to identify the classification of that information and to interpret the classification labels from other organizations.

Other Information

Labeling and secure handling of classified information is a key requirement for information sharing arrangements. Physical labels are a common form of labeling. However, some information assets, such as documents in electronic form, cannot be physically labeled and electronic means of labeling need to be used. For example, notification labeling may appear on the screen or display. Where labeling is not feasible, other means of designating the classification of information may be applied, e.g. via procedures or meta-data.

Benefits of Best Practices

• Avoiding re-inventing wheels
• Reducing dependency on technology experts
• Increasing the potential to utilize less-experienced staff if properly trained
• Making it easier to leverage external assistance
• Overcoming vertical silos and nonconforming behavior
• Reducing risks and errors
• Improving quality
• Improving the ability to manage and monitor
• Increasing standardization leading to cost reduction
• Improving trust and confidence from management and partners
• Creating respect from regulators and other external reviewers
• Safeguarding and proving value
• Helps strengthen supplier/customer relations, make contractual obligations easier to monitor and enforce

There are also some obvious, but pragmatic, rules that management ought to follow:

• Treat the implementation initiative as a project activity with a series of phases rather than a ‘one-off’ step.
• Remember that implementation involves cultural change as well as new processes. Therefore, a key success factor is the enablement and motivation of these changes.
• Make sure there is a clear understanding of the objectives.
• Manage expectations. In most enterprises, achieving successful oversight of IT takes time and is a continuous improvement process.
• Focus first on where it is easiest to make changes and deliver improvements and build from there one step at a time.
• Obtain top management buy-in and ownership. This needs to be based on the principles of best managing the IT investment.
• Avoid the initiative becoming perceived as a purely bureaucratic exercise.
• Avoid the unfocused checklist approach.

Free Information: Aligning CT , ITIL and ISO 17799 for Business Benefit: http://www.itgovernance.co.uk/files/Aligning%20ITIL,%20CobiT,%2017799.pdf

• IT best practices need to be aligned to business requirements and integrated with one another and with internal procedures.
• COBIT can be used at the highest level, providing an overall control framework based on an IT process model that should generically suit every organization.
• Specific practices and standards such as ITIL and ISO 17799 cover discrete areas and can be mapped to the COBIT framework, thus providing an hierarchy of guidance materials.

                      

No Tags

The content of this blog is essentially material I compiled for training sessions that I ran last year. It was originally PowerPoint, but I hope that this blog version is useful. Some of the legislative stuff is probably now out of date, and it was for an Australian audience – moral of the story is to do your own research.

For part 1 of this presentation, view this post and part 2 this post.

IT Infrastructure Library (ITIL)

• To facilitate Quality Management of IT Services
• To improve efficiency, increase effectiveness and reduce risk
• To provide codes of practice in support of Total Quality
• ISO9000-compliant

The Information Technology Infrastructure Library (ITIL) is a framework of best practice approaches intended to facilitate the delivery of high quality information technology (IT) services. ITIL outlines an extensive set of management procedures that are intended to support businesses in achieving both quality and value for money in IT operations. These procedures are supplier independent and have been developed to provide guidance across the breadth of IT infrastructure, development, and operations.

The IT Infrastructure Library (ITIL) is so named as it originated as a collection of books each covering a specific ‘practice’ within IT management. After the initial published works, the number of publications quickly grew (within ITIL v1) to over 30 books. In order to make ITIL more accessible (and affordable) to those wishing to explore it, one of the aims of the ITIL v2 project was to consolidate the works into a number logical ‘sets’ that aimed to group related sets of process guidelines for different aspects of the management of Information Technology systems, applications and services together.

Specifically, the goals of ITIL are to:

• To facilitate Quality Management of IT Services
• To improve efficiency, increase effectiveness and reduce risk
• To provide codes of practice in support of Total Quality

As a side note, ITIL is ISO9000-compliant

How does ITIL Work

• Provides guidance on strategic, tactical and operational management of IT infrastructure
• Provides a systematic, process-based approach, supported by procedures
• Suggests implementation strategies
• Acts as a training aid
• Vendor Independent
• Complies with requirements for ISO9001 quality standards

Vendor Frameworks based on ITIL

• Microsoft MOF : http://www.microsoft.com/technet/itsolutions/cits/mo/mof/default.mspx
• IBM IT Process Model: http://www-1.ibm.com/services/us/index.wss/offering/bcs/a1002395
• HP ITSM Reference Model: http://h20219.www2.hp.com/services/cache/78360-0-0-225-121.html

ITIL is not vendor specific but many vendors base their own IT service quality on ITIL.

"The Microsoft Operations Framework (MOF) provides operational guidance that enables organizations to achieve mission-critical system reliability, availability, supportability, and manageability of Microsoft products and technologies. With MOF guidance, you’ll be able to assess your current IT service management maturity, prioritize your processes of greatest concern, and apply proven principles and best practices to optimize your management of the Windows Server platform."

ITIL Overview

• ITIL is published as a series of books, each covering a major IT discipline
• Service Support
• Service Delivery
• ICT Infrastructure Management
• Application Management
• Security
• Each of these books break these disciplines down into sub areas. They define concept, goals, scope and relationship to other ITIL disciplines
• Planning and implementation of each discipline
• These are supported by three books which support the practical implementation of ITIL.
• The Business Perspective
• Planning to Implement Service Management
• ITIL® Small-scale Implementation

The current version (Version 2) of ITIL is published in a series of books, each of which covers one major discipline in IT:

• Service Support
• Service Delivery
• ICT Infrastructure Management
• Application Management
• Security

These are supported by three books which support the practical implementation of ITIL.

• The Business Perspective
• Planning to Implement Service Management
• ITIL® Small-scale Implementation

As a quick example we will examine the "Service Delivery" Book

ITIL Example: Service Delivery

• Service Delivery consists of 5 disciplines
  • Service Level Management
  • Capacity Management
  • IT Service Continuity Management
  • Financial Management for IT Services
  • Availability Management

Service Delivery consists of 5 disciplines

Service Level Management ensures that agreed services are delivered when and where they are supposed to be delivered.

There are a number of business processes that form part of Service Level Management. These are:

• Reviewing existing services
• Negotiating with the Customers
• Reviewing the underpinning contacts of 3rd party service providers
• Producing and monitoring the Service Level Agreement (SLA)
• Implementation of Service Improvement policy and processes
• Establishing priorities
• Planning for service growth
• Involvement in the Accounting process to cost services and recover these costs

Capacity Management is the discipline that ensures IT infrastructure is provided at the right time in the right volume at the right price, and ensuring that IT is used in the most efficient manner.

These are inputs into the following Capacity Management processes:

• Performance monitoring
• Workload monitoring
• Application sizing
• Resource forecasting
• Demand forecasting
• Modeling

From these processes come the results of capacity management, these being the capacity plan itself, forecasts, tuning data and Service Level Management guidelines.

ITIL Example: Service Delivery Continued

• Service Delivery consists of 5 disciplines
  • Service Level Management
  • Capacity Management
  • IT Service Continuity Management
  • Financial Management for IT Services
  • Availability Management

Continuity Management / Disaster Recovery / Business Continuity. Continuity management is the process by which plans are put in place and managed to ensure that IT Services can recover and continue should a serious incident occur. It is not just about reactive measures, but also about proactive measures – reducing the risk of a disaster in the first instance.

Continuity management is so important that many organizations will not do business with IT service providers if contingency planning is not practiced within the service provider’s organization.

Continuity management involves the following basic steps:

• Prioritizing the businesses to be recovered by conducting a Business Impact Analysis (BIA)
• Performing a Risk Assessment (aka Risk Analysis) for each of the IT Services to identify the assets, threats, vulnerabilities and countermeasures for each service.
• Evaluating the options for recovery
• Producing the Contingency Plan
• Testing, reviewing, and revising the plan on a regular basis

Availability Management is the practice of identifying levels of IT Service availability for use in Service Level Reviews with Customers. All areas of a service must be measurable and defined within the Service Level Agreement (SLA). To measure service availability the following areas are usually included in the SLA:

• Agreement statistics – such as what is included within the agreed service.
• Availability – agreed service times, response times, etc.
• Help Desk Calls – number of incidents raised, response times, resolution times.
• Contingency – agreed contingency details, location of documentation, contingency site, 3rd party involvement, etc.
• Capacity – performance timings for online transactions, report production, numbers of users, etc.
• Costing Details – charges for the service, and any penalties should service levels not be met.

IT Financial Management is the discipline of ensuring IT infrastructure is obtained at the most effective price (which does not necessarily mean cheapest), and calculating the cost of providing IT services so that an organization can understand the costs of its IT services. These costs may then be recovered from the Customer of the service.Costs are divided into costing units:

• Equipment
• Software
• Organization (staff, overtime)
• Accommodation
• Transfer (costs of 3rd party service providers)

The costs are divided into Direct and Indirect costs, and can be Capital or Ongoing.

Drilldown: Service Level Management

• 4.1: Why, goal, scope and concept
• 4.2: Defined process to implement – benefits, costs, problems
• 4.3: Planning the SLM process
• 4.4: Implementation of SLM (service catalogue)
• 4.5: Ongoing monitoring and reporting
• 4.6/7: KPI and performance targets
• Annex 4A: Roles and requirements of SLM
• Annex4B-D: Examples

4.1.1 Why Service Level Management?

Service Level Management (SLM) is essential in any organization so that the level of IT Service needed to support the business can be determined, and monitoring can be initiated to identify whether the required service levels are being achieved – and if not, why not.

Service Level Agreements (SLA), which are managed through the SLM process, provide specific targets against which the performance of the IT organization can be judged.

4.1.2 Goal for SLM

The goal for SLM is to maintain and improve IT Service quality, through a constant cycle of agreeing, monitoring and reporting upon IT Service achievements and instigation of actions to eradicate poor service – in line with business or cost justification. Through these methods, a better relationship between IT and its Customers can be developed.

4.1.3 Scope for SLM

SLA’s should be established for all IT Services being provided. Underpinning Contracts and Operational Level Agreements (OLA’s) should also be in place with those suppliers (external and internal) upon whom the delivery of service is dependent.

4.1.4 Basic concept of SLM

Service Level Management is the name given to the processes of planning, coordinating, drafting, agreeing, monitoring and reporting on SLA’s , and the on-going review of service achievements to ensure that the required and cost-justifiable service quality is maintained and gradually improved. SLA’s provide the basis for managing the relationship between the provider and the Customer.

When the first ITIL SLM book was published in 1989, very few organizations had SLA’s in place. Today most organizations have introduced them – though with varying degrees of success. This version includes some coverage of the common causes of failure, and guidance on how to overcome these difficulties.

What is an SLA?

A written agreement between an IT Service Provider and the IT Customer(s), defining the key service targets and responsibilities of both parties. The emphasis must be on agreement and SLA’s should not be used as away of holding one side or the other to ransom. A true partnership should be developed between the IT provider and the Customer, so that a mutually beneficial agreement is reached, otherwise the SLA could quickly fall into disrepute and a culture of blame prevent any true service quality improvements from taking place.

In the next part of this series, we will examine ISO17799

For the last post of this topic, consult this post.

                      

No Tags

The content of this blog is essentially material I compiled for training sessions that I ran last year. It was originally PowerPoint, but I hope that this blog version is useful. Some of the legislative stuff is probably now out of date, and it was for an Australian audience – moral of the story is to do your own research.

For part 1 of this presentation, view this post.

Framework Strengths

• COBIT is strong in IT controls and IT metrics (measurable). But it does not say how
• ISO17799 is strong in security controls but also does not say how
• ITIL is strong in IT processes (i.e. the how)

COBIT is based on established frameworks, such as the Software Engineering Institute’s Capability Maturity Model, ISO 9000, ITIL and ISO 17799. However, COBIT does not include process steps and tasks because, although it is oriented toward IT processes, it is a control and management framework rather than a process framework.

COBIT focuses on what an enterprise needs to do, not how it needs to do it. Across many aspects of an organizations activities, the board really doesn’t care about the ‘HOW’, they just want to see the ‘need’ addressed. Thus, target audience for COBIT is senior business management, senior IT management and auditors.

ITIL is based on defining best practice processes for IT service management and support, rather than on defining a broad-based control/measurement framework. It focuses on the methods and defines a more comprehensive set of processes.

Due to its high level and broad coverage and because it is based on many existing practices, COBIT is often referred to as the ‘integrator’, bringing disparate practices under one umbrella and, just as important, helping to link these various IT practices to business requirements.

ISO17799 is a more similar to COBIT than ITIL in that it is control driven, not process driven. However it is applied specifically to the area of IT security and thus drills down to a lower level than COBIT. The audience is also more focused from senior management/executive to IT and business unit management.

COBIT

• Business orientation is the main theme of COBIT
• 34 high-level control objectives
• Grouped into four domains:
• Plan and Organize
• Acquire and Implement
• Deliver and Support
• Monitor.
• IT governance guidance is also provided
• 318 Detailed control objectives (not today!)
• Maturity models, CSF, KGI, KPI

Business orientation is the main theme of COBIT. It is designed to be employed not only by users and auditors, but also, and more important, as comprehensive guidance for management and business process owners. Increasingly, business practice involves the full empowerment of business process owners so they have total responsibility for all aspects of the business process. In particular, this includes providing adequate controls. This basically means if the board is going to go down, they will take others with them!

The COBIT framework provides a tool for the business process owner that facilitates the discharge of this responsibility. The framework starts from a simple premise:

To provide the information that the organization needs to achieve its objectives, IT resources need to be managed by a set of naturally grouped processes.

From this premise, the framework continues with a set of 34 high-level control objectives, one for each "IT process". These are grouped into four domains:

• Plan and Organize
  
• Acquire and Implement,
  
• Deliver and Support
  
• Monitor
  

By addressing these 34 high-level control objectives, the business process owner can ensure that an adequate control system is provided for the IT environment.

(note my use of the term *owner* – this theme is consistent across a lot of the frameworks)

IT governance guidance is also provided in the COBIT framework. IT governance provides the structure that links

• IT processes
• IT resources
• Information

to enterprise strategies and objectives.

"IT governance integrates optimal ways of planning and organizing, acquiring and implementing, delivering and supporting, and monitoring and evaluating IT performance. IT governance enables the enterprise to take full advantage of its information, thereby maximizing benefits, capitalizing on opportunities and gaining competitive advantage."

In other words, it ensures accountability rests where it should. We will see a practical example of this in a later slide.

The governance guidelines further enhance and enable enterprise management to deal more effectively with the needs and requirements of IT governance.

The guidelines are action-oriented (activity goals) and generic, and they provide management direction for getting the enterprise’s information and related processes under control, monitoring achievement of organizational goals, monitoring performance within each IT process, and benchmarking organizational achievement.

In addition, corresponding to each of the 34 high-level control objectives is an audit guideline to enable the review of IT processes against COBIT’s 318 recommended detailed control objectives to provide management assurance and/or advice for improvement. So for example, one of the 34 high level objectives is "PO10 – Project Management." That has 14 detailed control objectives defined.

Finally, COBIT provides maturity models for control over IT processes, so management can map where the organization is today, where it stands in relation to the best in class in its industry and to international standards, and where the organization wants to be. Critical success factors (CSF’s) define the most important management-oriented implementation guidelines to achieve control over and within its IT processes. Key goal indicators (KGI’s) define measures that tell management—after the fact—whether an IT process has achieved its business requirements. Key performance indicators (KPIs) are lead indicators that define measures of how well the IT process is performing in enabling the goal to be reached.

COBIT’s enables management to answer the following types of questions:

• How far should we go and is the cost justified by the benefit?
• What are the indicators of good performance?
• What are the critical success factors?
• What are the risks of not achieving our objectives?
• What do others do?
• How do we measure and compare?

• Business requirements translate into IT Processes
• IT Processes provide information to the business
• IT Processes are controlled by control objectives
• Control objectives are implemented with control practices
• Control objectives are translated into audit guidelines
• IT processes are audited by the audit guidelines
• IT processes are made effective and efficient with activity goals
• IT processes are measured by KPI’s for performance, KGI’s for outcomes and Maturity models for maturity

Each control objective will list the criteria that help organizations define their current ‘maturity model’ in accordance with COBiT definitions. We will see an example of this in future slides

COBIT Control Example

• Control AI3: Acquire and Maintain Technology Infrastructure
• AI = Acquire and Implement
• AI3 has 4 detailed control objectives
• AI3.1 Technological Infrastructure Acquisition Plan
• AI3.2 Infrastructure Resource Protection and Availability
• AI3.3 Infrastructure Maintenance
• AI3.4 Feasibility Test Environment

High level objective: AI3

Organizations should have processes for the acquisition, implementation and upgrade of the technology infrastructure. This requires a planned approach to acquisition, maintenance and protection of infrastructure in line with agreed technology strategies and the provision of development and test environments. This ensures that there is ongoing technological support for business applications.

AI3.1 Technological Infrastructure Acquisition Plan

Produce a plan for the acquisition, implementation and maintenance of the technological infrastructure that meets established business functional and technical requirements and is in accord with the organization’s technology direction. The plan should consider future flexibility for capacity additions, transition costs, technical risks and the lifetime of the investment for technology upgrades. Assess the complexity costs and the commercial viability of the vendor and product when adding new technical capability.

AI3.2 Infrastructure Resource Protection and Availability

Implement internal control, security and auditability measures during configuration, integration and maintenance of hardware and infrastructural software to protect resources and ensure availability and integrity. Responsibilities for using sensitive infrastructure components should be clearly defined and understood by those who develop and integrate infrastructure components. Their use should be monitored and evaluated.

AI3.3 Infrastructure Maintenance

Develop a strategy and plan for infrastructure maintenance and ensure that changes are controlled in line with the organization’s change management procedure. Include periodic review against business needs, patch management and upgrade strategies, risks, vulnerabilities assessment and security requirements.

AI3.4 Feasibility Test Environment

Establish development and test environments to support effective and efficient feasibility and integration testing of applications and infrastructure in the early stages of the acquisition and development process. Consider functionality, hardware and software configuration, integration and performance testing, migration between environments, version control, test data and tools, and security.

I have only listed 2 of the maturity models here but it gives you an idea of what is required even at the basic levels. Where does your employer fit here?

This where the accountability comes in.

• R: Responsible
• A: Accountable
• C: Consulted
• I: Informed

Accountability defines what activity goals exist for a high control and who has what accountability. For example:

"Define strategy and plan maintenance for infrastructure" understandably does not involve the CEO or CFO. The CIO is accountable – or the owner of this activity. Responsibility (custodianship) is shared between the roles of:

• Head Operations
• Chief Architect
• Head of Development

Compliance, Audit, Risk and Security personnel are to be informed of the activity goals.

In the next part of this series, we will examine ITIL and then ISO17799

For the next post of this topic, consult this post.

                      

No Tags

The content of this blog is essentially material I compiled for training sessions that I ran last year. It was originally PowerPoint, but I hope that this blog version is useful. Some of the legislative stuff is probably now out of date, and it was for an Australian audience – moral of the story is to do your own research!

Here is our agenda:

• IT Compliance introduction
• US, Australian and EU laws
• Introduction to Best Practice Frameworks
• Introduction to COBIT with example
• Introduction to ITIL with example
• Introduction to ISO17799 with example
• Making them play together

IT Compliance – Why bother?

• Companies want a better ROI on IT investments
• Concern over increasing IT expenditure
• Regulatory regulations. E.g. Sarbanes Oxley
• Global outsourcing
• Increasing IT risk (security threats)
• Growing maturity of international best practice frameworks like ISO17799
• The need to benchmark and assess performance against standards and peers

There has been a huge increase in the adoption of IT best practices in the last few years. There are a few reasons for this, but fundamentally its driven by a requirement for to improve the quality and reliability of IT in an organization which in turn is in response to a growing number of regulatory and contractual requirements.

IT best practices are important because:

• Management of IT is critical to the success of enterprise strategy.
• They help enable effective governance of IT activities.
• A management framework is needed so everyone knows what to do (policy, internal controls and defined practices).
• They provide many benefits, including efficiency gains, less reliance on experts, fewer errors, increased trust from business partners and respect from regulators.

IT Governance – Costly?

• It has the potential to be costly
• You need to keep it current (avoid shelfware)
• You need to train staff
• If you don’t understand *why* it is needed, you will fail
• Without board level buy-in, it will probably fail (then they will ask for it within 1 week)
• Should not be treated as technical guidance, but business guidance

There is a danger, however, that any implementation of these potentially helpful best practices will be costly and unfocused if they are treated as purely technical guidance.

Standards and best practices are not a panacea, and their effectiveness depends on several factors.

Firstly they have to be kept up to date. Implementing these standards is not a once off operation that is set and forget. In a lot of organizations it requires a high level of commitment, a change of mindset and importantly a change of habits. To deliver this, staff need the appropriate level of training and sometimes IT departments need to re-organize.

Note: IT departments historically are not well experienced with implementing IT best practice standards, however many other departments within an organization are. We will get into why this has to change (and is changing) further into the presentation.

Standards have to be applied within the business point of view, with the focus on where their use would provide the most benefit to the organization. That primarily is driven by financial considerations, which we will look into a little later.

Note: IT Departments generally are becoming more business focused, despite the relative inexperience when it comes to IT Compliance standards.

So for best practice standards to be effective, all the levels from business management, IT management, auditors, compliance officers, infrastructure and operational staff need to work together to make sure that IT best practices actually lead to cost-effective and well-controlled IT delivery.

The only way to get that level of buy-in and commitment often requires board or senior management level sponsorship. In this model, management have the clout to ‘make it happen’.

Best practice standards are most useful when applied as a set of principles and as a starting point for tailoring specific procedures. To avoid practices becoming ‘shelfware’, management and staff must understand what to do, how to do it and why it is important.

Any implementation of best practice should be consistent with the any existing risk management and control framework. For example many engineering service companies certify to ISO9000/9001 for quality process. We do not want apply principles or practices that are not compatible with this.

You *will* be asked

• It is often not IT dept choice.
• Most likely it will come from board level based on business investments that have legislative requirements
• Its amazing how interested company directors become in compliance when they realize their personal liabilities!

More often than not, IT departments have best practice standards thrust upon them. This is particularly true for US and UK companies, but increasingly for Australian and EU companies as well. This is the often the least ideal situation, since the scope is probably bigger than you expect, the timeframe is less than you expect and the likelihood of a poor implementation is increased.

The main driver for this trend has been legislative and legal requirements put upon organizations. Often these requirements explicitly define Company directors liability.

Another big driver is competitive advantage. I have personally had two occasions where a client asked for implementation details of ISO17799. In both cases, we were completely unprepared for this and management naively thought I could knock it out in a couple of days!

In the next section we will look at the US legislation that has had the biggest impact on compliance standards in the last few years.

Sarbanes Oxley (SOX)

• Board level accountability in the wake of Enron/Worldcom type scandals
• Who’s affected: USA corporate subsidiaries, appointed auditors or financials advisors to these companies in Australia or Australian companies listing on the USA markets or those that have joint projects with US companies.
• Requirement that companies evaluate and disclose the effectiveness of their internal controls as they relate to financial reporting
• Directors directly liable for the companies they control.
• SOX recognizes COBIT as the methodology for assessing IT control effectiveness

The Sarbanes-Oxley Act is a significant piece of US federal legislation that was signed into law by President Bush on July 30, 2002 in response to corporate failures such as Enron, WorldCom and the many other corporate accounting scandals that have plagued the US in recent years. It is already having far reaching effects on US public companies, their management, auditors and procedures relating to reporting protocols to US regulatory authorities. The Act also applies to Australian companies and nationals with US parents or who have a significant business-to-business relationship with a publicly owned US company. Compliance to the act is compulsory and has significant repercussions for CFO’s, CEO’s, Board members and Directors of Australian companies. http://www.austrade.gov.au/australia/layout/0,,0_S2-1_1zg-2_2-3_PWB110371167-4_main-5_-6_-7_,00.html

The Sarbanes-Oxley Act’s major provisions include:

• Creation of the Public Company Accounting Oversight Board (PCAOB)
• A requirement that public companies evaluate and disclose the effectiveness of their internal controls as they relate to financial reporting, and that independent auditors for such companies "attest" (i.e., agree, or qualify) to such disclosure
• Certification of financial reports by chief executive officers and chief financial officers
• Auditor independence, including outright bans on certain types of work for audit clients and pre-certification by the company’s Audit Committee of all other non-audit work
• A requirement that companies listed on stock exchanges have fully independent audit committees that oversee the relationship between the company and its auditor
• Ban on most personal loans to any executive officer or director
• Additional disclosure
• Enhanced criminal and civil penalties for violations of securities law
• Significantly longer maximum jail sentences and larger fines for corporate executives who knowingly and willfully misstate financial statements, although maximum sentences are largely irrelevant because of the ability of judges to declare consecutive sentences under the Federal Sentencing Guidelines

COBIT was developed before SOX, and was given higher prominence when the SOX legislation recognized COBIT as the means to provide the assurance for IT internal controls.

It’s a US law, we are not affected!

• The European Union has been considering SOX type controls prior to US adoption of SOX (FSAP)

"Even with, or perhaps so, the three tiers of regulatory bodies in Europe, there are no pan-European requirements for specific internal controls. Given this fact, EU demand for SOX equivalent IT solutions is currently more limited than the US. Over the next three to five years, however, as member states fully embrace EU directives and regulations, the demand for country-compatible or regional IT compliance solutions is expected to grow. And, as Europe strives for higher investor confidence, there is the likelihood of additional, and perhaps more specific, requirements to come.

While EU codes are not as prescriptive as US laws, all of the guidance represents common bottom line goals. Companies will benefit if they can leverage internal experience with SOX by speaking to the benefit of technology in achieving compliance goals; that is, how specific applications and systems increase transparency, lock down network security, protect sensitive information, shore up financial reporting and ultimately improve all of the other business processes that support and justify investor confidence.

http://www.itcinstitute.com/display.aspx?id=466

EU Financial Services Action Plan (FSAP)

In June 1998, the Cardiff European Council invited the European Commission to table a framework for action to develop a single market in financial services. In May 1999, the Commission published a Communication containing a Financial Services Action Plan, which the Lisbon European Council endorsed in March 2000.

The FSAP is a set of 42 measures intended to fill gaps and remove barriers to create a legal and regulatory environment supporting the integration of EU financial markets by 2005. It has three aims:

• the creation of a single EU wholesale market for financial services and products;
• the creation of an open and secure financial retail market; and
• implementation of state of the art prudential rules and supervision

EU Law continued..

• The EU additionally has very strict privacy laws (Data Protection Directive 1998)
• Sector specific compliance: HIPAA, BASEL II

EU Data Protection Act

Personal data are defined as "any information relating to an identified or identifiable natural person ("data subject"); an identifiable person is one who can be identified, directly or indirectly, in particular by reference to an identification number or to one or more factors specific to his physical, physiological, mental, economic, cultural or social identity;"

The notion processing means "any operation or set of operations which is performed upon personal data, whether or not by automatic means, such as collection, recording, organization, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, blocking, erasure or destruction;" (art. 2 b)

Principles

Personal data should not be processed at all, except when certain conditions are met. These conditions fall into three categories: transparency, legitimate purpose and proportionality.

Transparency

The data subject has the right to be informed when his personal data are being processed. The controller must provide his name and address, the purpose of processing, the recipients of the data and all other information required to ensure the processing is fair. (art. 10 and 11)

Data may be processed only under the following circumstances (art. 7):

• when the data subject has given his consent
• when the processing is necessary for the performance of or the entering into a contract
• when processing is necessary for compliance with a legal obligation
• when processing is necessary in order to protect the vital interests of the data subject
• processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller or in a third party to whom the data are disclosed
• processing is necessary for the purposes of the legitimate interests pursued by the controller or by the third party or parties to whom the data are disclosed, except where such interests are overridden by the interests for fundamental rights and freedoms of the data subject

The data subject has the right to access all data processed about him. The data subject even has the right to demand the rectification, deletion or blocking of data that is incomplete, inaccurate or isn’t being processed in compliance with the data protection rules. (art. 12)

Legitimate Purpose

Personal data can only be processed for specified, explicit and legitimate purposes and may not be processed further in a way incompatible with those purposes. (art. 6 b)

Proportionality

Personal data may be processed only insofar as it is adequate, relevant and not excessive in relation to the purposes for which they are collected and/or further processed. The data shouldn’t be kept in a form which permits identification of data subjects for longer than is necessary for the purposes for which the data were collected or for which they are further processed. Member States shall lay down appropriate safeguards for personal data stored for longer periods for historical, statistical or scientific use. (art. 6)

Basel II

Basel II, also called The New Accord (correct full name is the International Convergence of Capital Measurement and Capital Standards – A Revised Framework) is the second Basel Accord and represents recommendations by bank supervisors and central bankers from the 13 countries making up the Basel Committee on Banking Supervision to revise the international standards for measuring the adequacy of a bank’s capital. It was created to promote greater consistency in the way banks and banking regulators approach risk management across national borders. The Bank for International Settlements (often confused with the BCBS) supplies the secretariat for the BCBS and is not itself the BCBS

The Australian Perspective

• Australian government has recognized the business cost of SOX type compliance and does not want to follow the US model
• DOCIT produced a "IT Security and Governance" whitepaper
• Corporations Act 2001. Uphold Due Care
• Privacy Act 1988 Protecting Information
• ATO 2005/9 Income Tax Record keeping
• ASX Principles of Good Corporate Governance
• AS 4360 Risk Management Framework

"SOX is seen by many organizations as a major cost to profit and manpower" (http://money.cnn.com/2006/03/21/news/companies/compliance_complaints/index.htm)

"A global study from European accountants Mazars, found that close to 20% of EU companies are planning to de-list from the US market to avoid complying and more than half feel the costs outweigh the benefits" http://www.laywersweekly.com.au/articles/9D/0C043D9D.asp?Type=53&Category=853

However this has the potential to impact on the cost of credit for such companies as warned in July 2006 by Moodys. "The cost of capital for public companies in countries that choose not to implement US Sarbanes-Oxley (SOX) type corporate governance rules may soon increase to reflect the additional risk premium resulting from companies and their auditors concealing the true level of audit risk"

At present the Australian government is not planning to introduce SOX type legislation, instead believing that the current regulatory provisions are adequate. Major legislation includes: Corporations Act 2001. Uphold Due Care, Privacy Act 1988 Protecting Information, ATO 2005/9 Income Tax Record keeping, ASX Principles of Good Corporate Governance, AS 4360 Risk Management Framework.

The Department of Communications, Information Technology and the Arts (DOCIT) on behalf of the Information Technology Security Expert Advisory Group (ITSEAG) engaged KPMG to produce a report on the governance of IT and information security matters for the corporate governance needs of Australian companies.

They identified 3 main observations to the risk landscape of ICT.

• There is a growing gap between the rate of technology adoption and the rate of controls adoption
• Convergence of technologies has led to a convergence of risk, greatly increasing the the potential impact to the business
• Increased dependences on technology has greatly increased the potential impacts in the event of failure.

They identified 3 main categories representing the greatest threats to critical infrastructure

• Human Error
• System Failure
• Malicious Software

They then define security governance as "implementing a culture of accountability in order for effective security management to take place". They refer to the ISO17799 as the model for their "Enteprise Security Architecture Model".

Note the use of the term accountability. It is a recurring theme across all best practice standards.

Why stop at one!

• COBIT v4
• ISO17799/ISO27001
• ITIL
• PMBOK
• SEI CMM
• COSO ERM

We have established that there are legislative/business reasons for best practice. But where to start?

• ITIL—Published by the UK government to provide best practices for IT service management
• COBIT—Published by ITGI and positioned as a high-level governance and control framework. COBIT stands for Control Objectives for Information and related Technology. IT Controls, measures, and processes
• ISO/IEC 17799—Published by the International Organization for Standardization (ISO) and International Electro technical Commission (IEC) and derived from the UK government’s BS 7799 to provide a framework of a standard for information security management Code of practice for information security management . It Security Best Practice
• PMBOK – Project Management Body of Knowledge . Project Management best practice (PMP certification)
• SEI CMM – Software Engineering Institute (SEI) Capability Maturity Model. Software Development Life Cycle
• COSO ERM – Committee of Sponsoring Organizations of the Treadway Commission. Enterprise risk management — Integrated Framework.

Framework Interaction

• The frameworks complement each-other
• Frameworks are vendor agnostic – no focus on tools
• Most frameworks are geared toward a specific subject
• PMBOK – Project Management
• SEI CMM – Software Engineering Maturity
• ISO17799/ISO27001 – Security Best Practice
• COBIT is a high level and considered the ‘umbrella’ connecting the others.
• We will look at COBIT and its relationship with ISO17799 and ITIL. PMBOK and SEI CMM will not be looked at

For the second half of this topic, consult this post.

                      

No Tags