Archive for February, 2009

… thinking about the future

Steve Clayton is a legend (CW IT Blog award winner 2008), and he’s gone and done it again with another post about the future!

Read his post, and traverse the links to see what the future might bring us.

I particularly like the presentation material produced by Steven Elop, President of the Microsoft Business Division.

Here are a few of my favourites:

Amazing stuff! Check out the slide deck: here


By SpittingCAML in Random  .::. (Add your comment)

K2 [BlackPoint] - A simple meeting agenda review process in InfoPath… that can even store the completed InfoPath form

Well, I say simple… It is simple to me, as I’ve knocked it up using the Meeting Agenda template (free with InfoPath 2007) with a slight addition of a task action field, and I’ve then knocked together a simple approval and rework based workflow.

Figure 1: The finished workflow (I’m not going to teach you guys how to suck eggs by going through the creation of it… unless you’d like me too … another time perhaps?)

Figure 1 shows the finished article… I’m not suggesting that this is perfect example of an approval and rework workflow…  it is simply here to demonstrate a point.

Figure 2: Destination Form Library for the creation of the InfoPath form that starts the workflow

I’m using a standard MOSS 2007 form library to store my InfoPath forms as shown in Figure 2. When ‘New’ is clicked, you see Figure 3.

Figure 3: The InfoPath form created when ‘New’ is clicked in Form Library (FormLibrary001)

Figure 4: The K2 Worklist (which just happens to be in the Process Portal (K2 Management)) showing the new task for destination user ‘Administrator’

As you can see in Figure 4, a task is added to the administrator user task list.

Figure 5: Clicking on Open will take the user back into InfoPath, or the Actions option will allow the user to action the task bypassing InfoPath - this might be useful if you want people to bulk action things. In this example I should really disallow this option. You can do this as part of the InfoPath client event outcomes.

Figure 6: Shows the opening of the InfoPath form from the K2 BlackPoint runtime services… I’ve configured this on port 8080 (just so you know). This gives me a clue that unlike K2 BlackPearl, InfoPath forms only exist in K2 Server, and not in the form library… which confused me somewhat… or perhaps I’ve got the wrong end of the stick on that.

Figure 7:  User is able to select an outcome from the task action field as you’d expect

Figure 8: Shows the final resting place of the InfoPath form - this is because of the SharePoint document event I placed in the final activity. I assumed the form would be saved by default, but it doesn’t seem to work that way… but it certainly did in K2 BlackPearl.

So how did I get the InfoPath form to be stored in the Library at the end… well the next screen shots and explanations will tell you how! I must admit, I thought it would do this automatically, but both the Beta 2 and RC versions of K2 [BlackPoint] behave in this way…

As you may have noticed in Figure 1, I added a SharePoint document event to the end of my workflow. This is also shown in Figure 9.

Figure 9: Shows the SharePoint document event on the final activity that saves the InfoPath form. I’m using the Upload Document Event Action.

Figure 10: Shows that I’m going to be creating this uploaded file from a K2 Field. This is very important, as K2 BlackPoint is now being told that the file stream is not from a disk, but from the database

Figure 11: When selecting the K2 Field, be sure to select the Root node of your InfoPath form. The Root node will be the name of your Template (in most cases). My Template XSN was called MeetingAgenda001.xsn before it was integrated into the workflow.

Figure 12: I am building the Filename of the output file using the meetingTitle field from my InfoPath template

Figure 13: To ensure an unique filename, I utilise the Process Instance ID

Figure 14: Be sure to space out your dynamic fields, I’ve used a hyphen. Also be sure to add the extension to the end. For InfoPath, the extension required is ‘.xml’ (well, of course it is!)… You then end up with files named like they are shown in Figure 8

Of course, you may not have to do all this stuff… I might have an incorrectly set-up version of K2 [BlackPoint], but thinking about it, it does make sense to me.

  1. InfoPath forms are ‘protected’ from unauthorised modification as they are stored in the database
  2. InfoPath forms are only stored in the library when they are in a complete state (because you decided when they would be stored!)

This is definitely an improvement on how BlackPearl handles them, as they are editable (through other means… e.g. text editor) when they are mid workflow, and it was a concern of the customer.

Anyways, I hope this helps others understand how to do this sort of thing. Post a comment if you want more explanation on anything, but of course, check out K2 Underground first!


Why can’t/don’t software developers design

It’s nothing new… you’ve got a team of excellent software developers, but when you try to put anything on paper, they scurry out of the room as if they’d had the promise of extra strength coffee in another place.

This leads me to point out the following articles:

Enjoy :-)


Software Development Lifecycle - which one do you choose, and why?

Having spend most of this afternoon racking my brains for some sort of holy grail of software development lifecycle that will ensure success in every possible scenario… I quickly remembered my Software Design lecturer words…

"If you can read, understand and interpret the ISO 12207 (International Standard of Software Lifecycle Processes) document then you are well on your way to being as confused about things as everyone else seems to be"

The document, unless you want to read all 18 pages of it, is basically an overview of what needs to happen in a Software Development Lifecycle… My favourite quote from it is:

"The standard is flexible and usable with: any life cycle model (such as, Waterfall, incremental, evolutionary, Spiral, or other); any software engineering method (object-oriented design, structured coding, top-down testing, or other); or any programming language (Ada, assembly, machine, or other). These are very much dependent upon the software project and state-of-the-technology, and their selection is left to the user of the standard."

Okay, so the joke is on me.. the document doesn’t really give me anything that I didn’t already know… As a software team leader or software project manager it is down to you to make the difficult decision as to which approach to adopt.

Right, so I reckon you can decide based on:

  1. Software Engineering Method (OO, Structured etc.)
  2. State-of-the-technology used on the project (e.g. workflow technologies, AJAX, C++)
  3. Past experience
  4. Company ethos
  5. Delivery timescale

1 and 2 are basically driven by your user and system requirements… as you can’t build what you want in any way you like, you need to pick a selection of technologies that can deliver your project in the required timescale… well, I guess you could do it any way you liked if it was a student project, or you had a ridiculously big budget, or if it was part of the project to work out the most effective solution in every conceivable technology.

3 only applies if you’ve ‘been there and got the T-shirt’… It wont give you much if all your projects have been run in the same way, as you don’t have the visibility of other methodologies… so more than likely you’ll adapt your current way of thinking and tweak it to improve efficiency. This is not necessarily a bad thing.

4 is more down to the organisation you work in… are there rigid corporate standards to adhere to? … do you have to talk to twenty people to get a slight change to policy approved? Can you really decide how you wish to develop your product? If you can… then if it all goes well, a hero you will become… I hate to think about the price of failure when a new development strategy is adopted.

5 is really important, and I think it is not really considered in enough detail… so you want to adopt a certain development strategy… how does this impact your development team, and more importantly your stakeholders… does your customer insist that you follow a certain strategy? are you tied down to a contract that means you cannot perform a true iterative approach?

Hmm… so all I’ve done so far is to help stir up the murky waters a little more.

Is change for the point of change a bad thing?

The development strategies (that for the purposes of this argument are the ones under consideration)

  1. Waterfall, and for those in a comedy mood: waterfall 2006 conference :-D
  2. Agile (e.g. Scrum, Lean etc.) … I’m also going to group iterative or incremental development into this category
  3. Automated Software Synthesis - you need ACM access to read the full article, but you can search for free results :-)

The waterfall model has many critics… many of the criticisms are valid, however don’t be too quick to ignore that it has to offer, if you know what you are building, and the requirements are 90% stable, then it might be exactly what you are looking for. In terms of fixed price contracts, I think that the waterfall model has a great deal to offer, the future can be planned, and progress can be measured in deliverables rather than other intangible means

Agile development is (IMHO) the new word for a structured, defined and industry standard of iterative or incremental software development. To be honest with you, if it wasn’t for the reading of Andrew Woodward’s blog, I wouldn’t have had the foggiest idea about what it could offer. I also cast eye over Hillel Glazer’s Agile CMMi blog… since my organisation is a CMMi level 3 operation now :-). Where to begin with Agile… well it is a daunting task for any PM for Software Team Lead to take in all the information I’ve just been though… and getting your development team to adopt a new way of thinking will just as daunting as the learning.

"Although there are some evidences that CMMI and Agile can coexist, the overall impression of people dealing with process improvement is that there are still important cultural differences between the two communities" - from CMMI: Less Hyped Than Agile but Equally Popular on

Oh boy have you got an uphill battle if you, like me, are in a CMMi ordained organisation… or perhaps not, it depends on how you approach the change.

Automated Software Synthesis is something I had never considered until I utilised K2 [blackpearl] and K2 [blackpoint]. Essentially your design when using those particular technologies is a high level business process that you wish to implement. You can’t really go about doing a detailed UML model of how each of the classes in the system will work - because it engineers itself through the tools provided, be it K2 Studio or Visual Studio. Yes you can write your own code, but it forms a small part of your development if you can utilise the technology to your advantage. You still need to gather requirements though… which is really important! Other such examples include rapid application development tools that can write your code based on a detailed design… I’ve got no experience of these.

I’m still none the wiser, and the deadline looms in the distance… and upper management are after those darn estimates.

…. SpittingCAML

Documenting Workflow

You may have customers who let you decide what they want, as they don’t know themselves! This is not necessarily a bad thing as pretty much whatever you deliver will be an improvement on what they’ve got (something, in the place of nothing)… however increasingly you’ll come across an intelligent (In their eyes) customer. Intelligent customers like to tell you what the solution is before you’ve even produced a requirements document, you wont be able to get any requirements from them because all they want to do is sit behind the development team pointing and shouting at what they want them to do. Okay, so how do you make the most of an intelligent customer?

In terms of workflow, you can enable customers to document their workflow in a meaningful way.

By meaningful, I mean, in the place of twenty poorly described and wooly requirements, a picture of how the system needs to work, essentially and pictorial requirement… perhaps you can even let your development team see it! :-)

The first thing you need to do, as an organisation or department is to choose a notation, that you can use on the whiteboard, use in PowerPoint slides… and more importantly can train others to produce and understand.

Two common notations spring to mind,

  1. Business Process Modelling Notation (BPMN)
  2. Unified Modelling Language (UML)

Before you make your choice between these two, or another of your favourites, it’s very much worth having a read of:

  1. Process Modeling Notations and Workflow Patterns by Stephen A. White, IBM Corp.
  2. Advanced Unified Modelling Language (UML) Tutorial - Workflow Model
  3. UML Activity Diagrams as a Workflow Specification Language by Marlon Dumas and Arthur H.M. ter Hofstede

Happy modelling


You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.