Rob Gillen's WebLog

Isn’t it Time for 64Bit?

I’m getting frustrated with application vendors and their support for 64-bit O/Ses. I’d admit that a year or two ago the consumer-level device support for 64-bit O/Ses was a bit weak, but considering I can now walk into Best Buy and pick up a consumer-grade laptop that runs Vista 64, the major software vendors really need to get their act together. In the last few weeks I’ve been bitten by a “we don’t support 64-bit” story a number of times and it feels ridiculous… Maybe i’m an edge case, but every Vista Machine I own is 64-bit (work laptop, home desktop, my wife’s laptop, etc).

• I was writing code this AM attempting to integrate with QuickBooks 2008 and was forced to go back and re-compile with the processor-specific x86 switch due to the fact that their SDK doesn’t support 64-bit O/S.
• I had purchased a 3-computer license to ETrust Anti-Virus (Computer Associates) and upon recently replacing my home desktop and my wife’s computer I had to throw away those licenses and replace them with another vendor’s product because CA can’t figure out how to build an AntiVirus app for 64-bit Vista
• At work, I am forced to run a 32-bit Vista Virtual Machine because the tool provided by our workflow vendor for designing business processes doesn’t run on 64-bit (they claim they’ve been working on a 64-bit version and it should be out “any time”… but that was February…)
• At work we’ve been working on an electronic records system and are fighting with the vendor because they don’t support 64-bit OS on the server… seriously? An enterprise-scale server-based product that has been around for a few years doesn’t yet support 64-bit? I’m amazed…

Thinking the Cloud…

I’ve been talking quite a bit with a co-worker about “the cloud” and how organizations can and will leverage it over time, and how application development/design may change as a result. Microsoft’s Sql Server Data Services (SSDS) is only one example of a major paradigm shift in the industry away from internal-only systems to treating certain things as commodity-style resources.

I’ve been thinking through a problem for a non-profit that I work with wherein they needed to share approximately 7.5 GB worth of corporate documents amongst a geographically dispersed team. We’ve been facilitating this by using a WSS site hosted on a little box at my house for the last year or so, but have had increasing frustration with normal home-hosted issues (power blinks, server goes off while I’m out of town, etc.) so I’ve been researching how to solve this problem inexpensively but also well enough to “make the problem go away”. Because of the other discussions my co-worker and I have been having recently, I naturally looked for a “cloud-based” solution.

Here’s the list of things I reviewed:

• Microsoft Office Live Small Business – http://www.officelive.com – this looked to be a very interesting option… you sign up, get some custom domain mail accounts, a little website if you’d like, and some private space which is essentially a highly-tailored/restricted WSS platform. $15/month for 5GB of space. I contacted their helpline, they assured me I could add to that to meet my 7.5 GB requirement so I started uploading… after 4.9 GB (and a LOT of time – my poor cable modem…) I went to add another 5GB only to have the control panel deny me that option. Another call to customer service and the nice-but-feature-ignorant customer service representative told me “I sure thought you could do that but I guess not”. Cancelled the account and threw away the upload time… oh well… (UPDATE: I’ve since been called back by another rep who assured me that it was, in fact, possible and that all would be well, but the ship has sailed…)
• Microsoft Office Online (http://www.officeonline.com) – this is the full-blown version of Hosted SharePoint… would have been great however it is currently in beta and has no prices listed. Based on the target audience and the pricing for their hosted live meeting service, my gut tells me it is going to be too pricey for the non-profit to swallow so I moved on…
• SkyDrive – this would be great… it’s exactly what I needed… but I need 7.5 GB… not 5… I couldn’t find any way (even offering to pay) to get more than 5 GB… on to other options…
• <Insert your favorite file share here>: Found a bunch of services that might work… some of which I had heard of before, others I wasn’t sure of, some looked too good to be true, some I wasn’t convinced would be around long enough for me to get my data uploaded much less 4-5 years from now…

Then, a friend recommended I look at Amazon S3 and I’m pretty glad he did. Amazon offers “Object Storage” in the cloud for very cheap prices… and expose a series of XML Web Services to interact with the service. It takes almost nothing to get setup, and there’s a number of code samples available on CodePlex (http://codeplex.com) to illustrate working with it. I’m currently playing with a share-ware tool called BucketExplorer (~$50) that works as a file client for the service and, besides being a resource hog, is workign fairly well. The best part about this solution is that it is incredibly cheap ($0.15/GB/Month!) and I can integrate it directly into our existing admin control panel without the staff knowing that the actual data “lives someplace else”. The Internet storage has become a commodity – something that I can just assume is available… pretty slick if you ask me.

Stop (re-)Inventing the Wheel!

This is more a personal reminder than anything else…

In my “day job”, I’m working with an organization wherein we are coaching a group of about 80 developers to view opening Visual Studio as their last viable option when looking to solve a problem. This doesn’t mean coding is bad (I certainly hope not… if so, I think I’d be out of a job soon), but rather represents a mind-set that recognizes that we have an enormous collection of functionality/tools already available to us (we are building on top of MOSS 2007) and we need to fully vet the OOTB functionality prior to deciding we need to “roll our own” anything. Directly tied to this approach is the theory that using OOTB functionality and/or configuration of such (rather than raw coding) leads to better long-term maintainability and upgrade-ability, not to mention helping to avoid “hit by a bus” syndrome.

However, sometimes the “preacher” needs to look inwardly and I found myself doing that this weekend. I was working on a project for a non-profit organization I work with, and found myself looking at what I had amassed for solving the problem of site-wide search and was displeased. I immediately reverted to my “code first” tendencies (something I think every developer is born with) and began (mentally) listing the discrepancies with the current solution and designing a “right” solution. Thankfully, prior to actually writing any code, I was kicking around some blog posts and something in one of them (honestly don’t remember what/which) got me thinking of the various “existing” search engines and the fact that they often provide site-specific, nearly OOTB search dialogs that you can embed into your site. I kicked a couple of them around, and settled on one (ended up with the live.com search using the XML web services API), and, rather quickly had a fully-functioning search platform on my site…

The “purist” in me immediately thinks of a couple of reasons why this solution “isn’t as good as what I would have built” (i.e. less control over the actual search results/order, less “immediacy” to updating the index, etc), but then my more realistic side kicks in and I realize that I’m not a search engine expert… not even close… Some might argue as to wether or not those at live.com are either :), but I can guarantee you that they are more so than I, and that the solution “they delivered” is much more accurate and flexible than I would have built…

I found myself reminding myself to focus on where I can add value, and to leave the rest to others… that’s the only way to consistently deliver adaptable solutions in an environment where the surrounding technology is changing so quickly…

Finally back where I want to be...

It's frustrating to me to find myself redoing things that I've done before or re-solving problems. Over the years at Planet I've been involved with different software teams each with different levels of rigor, however most all of them have had, at minimum, an automated build process of some sort (at least for the past 4 years or so). Some of these systems were elaborate msbuild driven systems while others were a cobbling together of batch scripts or PowerShell linking msbuild, Vault, FogBugz and Community server.

The customer I've been working with for the past 16 months has "bitten off" the entire TFS tree and I've been the prime developer responsible for implementing it and getting it going... all, of course, while doing "real work". Further, (nearly) all of the work we've been doing has been SharePoint focused (custom list event handlers, web parts, site definitions, etc) which means any build must generate properly formed SharePoint Solution (*.wsp) files and the approaches to doing this and handling the installation/upgrade of such are pretty varied.

This weekend I finally completed a build on a project that meets my "minimum requirements" for being a properly formed build. I'm pleased that I was able to, in relatively short order, apply it to another project verifying repeatability. Here's what we're doing:

1. All build scripts are handled by TFS 2008 (using OOTB functionality)
2. Solution manifest files and DDF files are maintained both in dev and production build by a customized version of stsdev v1.3 (http://codeplex.com/stsdev)
3. An "installer" is provided as part of the build (<buildRoot>/Install) that allows the back office team to simply double-click and go. We use the SharePoint Installer (http://codeplex.com/sharepointinstaller) tool/framework to provide this function
4. All required web.config settings are handled via the feature receiver allowing them to be properly installed/removed on activation/deactivation
5. Developer-level documentation is provided for the build based on the /// comments in the code. We use Sand Castle (http://codeplex.com/sandcastle) to do the core generation and Sand Castle Help File Builder (http://codeplex.com/shfb) to assist with the build script integration (I tried DocProject - http://codeplex.com/docproject - but it pooched vs 2008 and never worked as described - hopefully it will be more stable when it exists beta).
6. Passed Style Cop (MS Source Analysis) rules
7. Passed Code Analysis rules

I still have a ways to go prior to reaching my "nirvana"...

1. Build should automatically run code analysis (this is certainly possible, I've simply not gotten it implemented yet)
2. Build should automatically run source analysis (this is possible, I've simply not gotten it implemented yet)
3. Full testing (unit and system) on build completion - Ideally it would spin up a VM, deploy the appropriate code, execute the test battery, clean up and report on the results.

Even so, it felt good to get a respectable build out the door and to know that it was process driven and repeatable.

What I'm looking for...

In a number of the posts I've been writing on the SOA/BPM conference I've referred to the applicability (or lack thereof) of a given approach to "the problem set" that I'm currently working on. I thought it might be good to describe what it is that I'm looking for and a little bit as to why.

I'm working at an organization with roughly 4,000 employees that is in the process of "drinking the MSFT Koolaid". We are deploying nearly every MSFT product and working hard to bring consistency to the platform both from a services aspect as well as the development paradigm. We are focusing on SAP backend, SQL data store, and SharePoint/Office Suite front-end.

We are also focusing on bringing a consistent story to the workflow problem, and, by "workflow" I really mean (well, at least for the purposes of this post) business process. We have business processes in SAP that have workflows behind them and use various means of interaction to keep it moving (i.e. nag-mails, etc.). We have similar workflows in SharePoint for document approval processes and the like. We also have a third set of workflows (business processes) that are either not automated at all, or not in any sort of consistent interface. It is this last set processes that I'm trying to "fix".

I have a couple of "rules":

1. The interface must live in SharePoint (at least the end-user facing portion)
2. The "workflow" aspects of the system should utilize one of the two existing execution engines we have running (SAP or WF in MOSS)
3. The workflow designer should be comfortable for a business analyst to use, and preferably an extension to a tool they are already using (i.e. Visio add-in).
4. The workflow designer should be able to map actual requirements to the steps in the process (where applicable) and serve as a documentation source of sorts.
5. The process execution system must provide a webparts (or at least the ability to expose the data as webparts) for the following scenarios:
   1. Overall health of the system
   2. Current user's workflows currently in action
   3. Visual representation of a given workflow process
   4. Analysis relative to the execution stats for each workflow instance and type
      1. i.e. X step of workflow Y is over the planned duration without having completed. Some indication should exist that this process is out of line
      2. i.e. Workflows of type X average Y days with the minimum being Z days and the maximum being T days. (and trends over time)
6. There must be a hard link between process definition and process execution. The File | Print approach is not sufficient
7. The system should be standards-based. Meaning, I should be able to import/export the workflow definitions (at least at some level of granularity) to an industry standard such as BPEL or BPMN in order to be able to share or compare that process with other organizations.
8. The system should be able to provide governance over the models.
9. In all aspects possible, the system should provide a consistent story WRT the development paradigm we have selected (MSFT .NET, ASP.NET, Windows Workflow, SharePoint, etc.).

Reality...

1. I'm not exactly certain I'm ready to back down on any of the items above, however I'm coming to the conclusion that there may be a need for a "third" execution engine - meaning, all of the vendors that I saw that had platforms that did what I wanted, either used their own custom execution engine or hosted their own instance of WF separate from MOSS. Even MSFT pushed BizTalk as the "main" process execution engine for *serious* workflows.
2. If reality point #1 is in fact true, the process execution platform should be based on WF allowing the developers to have a consistent development paradigm.

MSFT/BPM/SOA Session 6

The sixth session I attended was entitled "Next Generation Business Applications" and was presented by Mike Walker of the Architecture Strategy Team (MSFT).

This presentation dove-tailed nicely with the one I had attended earlier that day on the human aspects of SOA/BPM. The real gist of this session was to challenge the user to reconsider the requirement to write distinct user interfaces for each of the applications he/she is tasked to build. In much the same vein as the earlier talk, he was encouraging us to think of ways to expose the user-facing aspects of our applications in the context of applications that the user is already familiar with, such as using the OBA approach and embedding the application in a common productivity tool such as Word, Excel, or PowerPoint. The point being, that the less you force you user to "learn" in order to use your application, the more likely they are to use it. Further, the user doesn't really give a hoot if your application is fully SOA compliant and uses your best-of-breed enterprise service bus, and blah, blah, blah... They care about, does it work. What do I have to do in order to do my job. Tell me that, let me do that, and then leave me alone. and... that's not altogether a bad view of things.

The point is not that OBAs, or "Composite applications" are the only way to go, but rather that it should definitely be on our "radar" and should be considered (at least) prior to beginning to build a full UI.  Another take-away from this session was the fact that the more consistency you can drive in your applications (or, more importantly across your applications), the better off you are. Building a "unique" or "fully custom" user experience is not likely a good thing.

MSFT/BPM/SOA Session 5

This session was titled: "The Human-Facing SOA: Realizing the Value of Web Services with Microsoft Office SharePoint Server 2007" presented by Hugh Taylor (Senior Marketing Manager, MSFT)

So, reading the title of this session, I assumed it was a technical presentation focused on SharePoint web services.... however, that was not the case. Rather, it was a business-focused presentation that centered completely on the "users" of any given SOA. While not being exactly what I expected, it was a very good session and well worth the time to sit through it.

As with the other sessions, it's a little easier for me to simply comment on poignant comments from the speaker than to attempt a proper summary, so here goes:

• People are often the missing ingredient for SOA business value
• If you are trying to measure the ROI of your SOA project, you'll likely be disappointed. Some common reasons are:
  • slower than anticipated uptake
  • training takes more time than planned
  • various Governance and security hang-ups
• One of the factors in all of this is a lack of a familiar interface
• We, as technologists and system designers MUST learn to focus on the user, rather than the technology. Hugh Macleod has a comic that aptly puts what I want to say here:
  
  
  
• We seem to get so wrapped around the axle with respect to how the system interacts with itself or the technology deployed within the system that we fail to realize that without a user, our system is useless.
• He stressed the importance of accurate communication at all levels of the SDLC. Often business drivers and technologists are "talking past" each other.
• He noted that as software developers and coders we often underestimate the power of habit, organizational norms, etc. Just because it's "better" doesn't mean that it's "better".

At this point he started talking specifically about the MSFT platform and the talk became less interesting to me :)

All in all, one of the best, most thought-provoking sessions I attended.

MSFT/BPM/SOA Session 4

The fourth session I attended was titled "BPM Best of Breed: Accenture, Avanade, IDS Scheer, and Microsoft - Delivering Closed Loop BPM and was presented by Brian Wilkinson (Accenture), Altan Enginaleve (IDS Scheer) and Dana Kaufman (Microsoft).

The objective of this session was to do a "deep-dive" into the demo that these same folks presented during the keynote earlier that day (which was very interesting).  What I had feared was the case, worked out to be, in fact, reality - the demo was a bit more duct-tapped together than I had hoped. The intent of the project was to illustrate to us and their customers what could be done ("paint the picture" if you will).

I have to admit that the ARIS platform was very intuitive and interesting, although I found myself a little turned off by the extensive use of Java and JDBC connections (I know, I know, but I bleed blue...). As with many of the sessions, the speakers made some general comments/points that I thought were interesting...

• Many organizations have very well documented business processes, however, those rarely reflect reality (no direct impact on execution)
• They (as consultants and based on their experience) encourage people to avoid "as-is" process modeling and focus more on "target" process modeling. In their experience, it is not uncommon to find that upwards of 80% of the "process" that existed was not tied to true requirements, but rather historical, or "just because that's how we do it" reasons. Simply focusing on what *really* needs to happen (almost ignoring for a little while how it is currently being done) can be a great source of improvement to efficiency.
• As often is the case, the starting point is processes - processes can be documented, metrics can be understood - this is not a technology problem. These (both processes and the metrics that you want to collect about those processes) must be worked out prior to any "silver technology bullet" "fixing" things.

Think Big, Start Small, Scale Fast.

MSFT/BPM/SOA Session 3

The third session I attended was a lunch session sponsored by K2 (http://www.k2.com). I was looking forward to this presentation as I've heard quite a bit about K2, and they've been doing workflow in SharePoint long before MSFT was.

During this session, they focused on their "Black Perl" product which is the current release. Based on the demo, a quick summary of the product is as follows:

- Middleware platform that provides workflow and reporting based on the concept of "business entities"

- They have a concept of a "SmartObject" which is mechanism for creating, what I would call a composite object/view of a singe entity within the organization regardless of the data source. This means, I could create a smartobject which represents an "employee", for which some of its attributes/values are derived directly from SAP, others from AD, and maybe still others in a custom built SQL DB. This object abstracts for the user all of the complexities of interacting with the data sources on the backend. In the demo, the showed creating a smart object for which the data resided in SAP and then exposed that "entity" in a number of different places (SSRS report, workflow, etc.).

All in all, the demo was pretty interesting and there is some applicability to the problem set I'm currently working with, but I had a hard time imagining a non-developer using their "non-developer" focused tools. I'm certain that it would come with time, but seemed like a higher barrier to entry than I was looking for.

That being said, as mentioned before, their demo focused specifically on the Black Perl product and, having spent some more time on their web site since, there are clearly other products/updates to existing products in the works that might make the entire platform much more of a "fit" for the scenario we are trying to fix.

MSFT/BPM Session 2

The section session I attended was entitled "People-Read Processes with SharePoint Workflows and Forms Services" and was presented by Christian Stark, a Senior Product Manager for Microsoft.

The presenter gave a survey at the beginning and hinted that, if you met a certain criteria (which I did) that you may not want to sit through the session as it would likely be familiar material. In retrospect, I should have listened and looked for another session. The presentation wasn't wasted, just not full of "new" material.

Christian divided the session into two main sections - the first of which was slides and discussion while the second half focused on demos.

During the theory section, he mentioned a few things that seemed to resonate with me (presented below in no particular order):

• Most end-users want to "do their job" without being "encumbered" (or, at least not overly so) with processes
• Most IT users have the exact opposite desire... we want to lock users into a very specific process so we get accurate, consistent data and can properly execute the workflow
• A successful implementation will be (at least partially) characterized by:
  • IT successfully exposing the workflow endpoints directly in interfaces that the end users are already comfortable with (i.e. MS Word, Excel, PowerPoint).
  • Making the processes task-driven rather than email-driven --> takeaway: if you are going to send nag mails as part of the workflow, make sure that the email is directly actionable (i.e. includes a link, form, or button against which the user can immediately execute).

Objectives/Responsibilities on IT

• Simplify the human interactivity aspects of the workflow
• Simplify the data collection
• Simplify the participation
• Simplify the process management and monitoring