IDC has released a new study that profiles ten relatively small, emerging software companies in Canada that it deems particularly worthy of note. These companies have overcome internal challenges, and have successfully contended with the ever-changing ICT industry, evolving regulations and standards, and large competitors with even larger marketing budgets. They have the potential to impact the ICT market in Canada and beyond.

We are listed as one of the ten companies !

http://www.idc.com/getdoc.jsp?containerId=prCA20741607

As the Software Process Engineering Metamodel (SPEM) version 2.0 moves towards adoption as an available specification, I wanted to share some background on SPEM in general and version 2.0 in particular. SPEM 2.0 is currently available as a final adopted specification and is expected to be finalized as an available specification by end of 2007.

Osellus was one of the earliest adopters of SPEM. Realizing early, the value of a standard process meta-model that results in interoperable process models across methodologies and mixed-technology enactment environments, its flagship product IRIS Process Author is built on SPEM 1.1. Most organizations adopting SPEM 1.1 move forward from a “no-standards” approach to modeling to a methodology agnostic industry standard approach to modeling. As process mature organizations started adopting SPEM 1.1 they uncovered many areas of improvement in the metamodel. Many of these deficiencies became the basis for a SPEM 2.0 RFP - re-using process elements and process workflow, support for process enactment, support for process metrics, better explanation of terms used in the metamodel. The final adopted specification has been able to address many of these areas of improvement and is expected to attract a wide industry support.

As I understand Osellus is committed to making IRIS Process Author SPEM 2.0 compliant as soon as the specification is finalized as an available specification. Currently available as a final adopted specification, SPEM 2.0 is expected to be finalized as an available specification by end of 2007.

Osellus plans to support SPEM 2.0 and go beyond it. In adopting SPEM 2.0, Osellus will choose to redress the concerns around the over-complexity and the lack of enactment in the metamodel. This will result in a wider participation and successful adoption by process practioners as well as support mixed-technology environments such as Microsoft VSTS and IBM Jazz.

Rather then forcing users to struggle with over-complicated terminology and unnecessary packaging such as the concept of method plugins, configurations and the variability mechanisms, IRIS Process Author will abstract this complexity through a simple user interface. IRIS Process Live will provide full enactment support for the modeled software processes enabling successful delivery of software projects. As I have noted in the past, it is not possible to come up with a sustainable process definition without enacting it in real projects. Unless project teams try to enact the defined processes, they cannot uncover process gaps. It is during process enactment that teams would uncover what is missing in their processes. Lessons learned as part of a successful or unsuccessful implementation would provide rich data to improve these processes and institutionalize the lessons across the enterprise. Compliancy reporting would mean teams can self-audit how far/away are they from meeting the compliance points as laid out in the defined process. Finally, with data-based process interventions and the empowerment of project practioners the chances of project success keep getting higher with successive implementations.

Ajoy has blogged about our participation at the IBM Rational Conference and our solution allowing enactment of RUP in VSTS.

http://blogs.msdn.com/ajoyk/archive/2007/06/10/visual-studio-team-system-and-rup.aspx

I hear a lot from folks who are interested in enacting RUP and OpenUP/Basic in VSTS. Here is my earlier post that discussed our approach on enactment in a mixed-technology development environment using IRIS Process Live. IRIS Process Live is built on top of the Team Foundation Server.

In my opinion Jazz is the star of this years rational conference. Take a look at some of the pictures from the conference and the keynote introducing jazz. Erich Gamma did an excellent presentation on jazz during the keynote and later during a dedicated technology session on Jazz.

Me next to the Jazz Live poster

The Jazz show begins…

(From left to right) Chandra, Payman and Dave

(From left to right) Dave, Payman, Me, Chandra

There were many exciting things I saw that vindicated some of our fundamental beliefs in the software process automation domain. First with Microsoft’s VSTS and now with IBM Jazz there is overwhelming evidence that low-fidelity software development process models are the cornerstone of collaborative friction-free process enactment. This enactment is not only helpful (just-in-time, just-enough) for developers and other project practioners but is also essential for compliance requirements as well as ultimately, feedback to improve processes. The end goal is “continuous”, successful project delivery. Although there are still a lot of unanswered questions on the Jazz strategy, one thing that is clear is that it is a fundamental shift in the way IBM rational has been building and deploying its developer tools.

We are getting ready to participate at the IBM rational software development conference 2007 in Orlando from June 10-14th, 2007.

If you are at the conference, please do stop by our booth (#427) to see some of the second generation tooling we are going to be demonstrating.

We will reach Orlando Monday afternoon (11th June) and I will be blogging live from the conference on all the exciting action.

In my experience I have seldom come across large enterprise organizations that mandate the use of a specific IDE while putting a blanket ban on any other IDE. Even within the same sub-organization, different development teams may have own their favorite IDEs. Moreover, the decision to use a particular IDE is often tied to the platform on which the application is being developed. For example if building a .NET based application one is likely to use Visual Studio. If developing a J2EE application one may choose to use the eclipse as the IDE.

Having made a considerable investment of time and money in coming up with a process model – whether using COTS methodology such as RUP or your own in-house methodology – you would like all projects, irrespective of the IDE they use, to follow this process. This also includes getting access to the lessons learned across all projects enacting this process model.

All of this makes the already tough task of enacting software development processes in this mixed-technology development environment even more difficult. Rather than trying to convince developers to leave (step out to another interface) or at worse abandon (in favor of another IDE) their IDE simply to follow a process, it would make more sense to build process awareness into the tool they decide to use. The lack of a low-overhead process enactment interface should not become an excuse in not enacting the chosen process model.

The IRIS Plugin for Eclipse injects this process awareness into the eclipse IDE. Developers can now access the relevant process content without needing to leave the eclipse environment to dig through cumbersome process documentation. More importantly this information is available in a just-in-time manner when the project work items assigned to the developer are ready to be started. This means that there is zero additional overhead on part of the developer to lookup the process guidance associated with a project work item they are executing. In fact, if the process author has chosen to build a low-fidelity model prescribing a workflow based on activity state or work product state change events, the developers even get notifications when their work items are ready to be started. Developers see all project work items (with status) assigned to them and are able to distinguish pending work items. If needed they can create related work items as they progress in executing the work items assigned to them. When finished they can assign the work items to the next developer or other practioners that are part of the project being enacted using the defined process model.

IRIS Process Live acts as a unifying enactment platform across the enterprise. Here is an example of how with IRIS Process Live at the backend, the same process model can be used by developers and other practioners in disparate environments. In Figure 1a and 1b, the eclipse environment to view all project work items as well view a process links tab for one of the work items is shown. In Figure 2a and 2b, the same information is provided in a Visual Studio environment. Finally in Figure 3a and 3b, the same information is presented in a web view that may be used by practioners who don’t have desktop IDE clients on their machines.

Figure 1a - Eclipse

Figure 1b - Eclipse

Figure 2a - Visual Studio

Figure 2b - Visual Studio

Figure 3a - Web view

Figure 3b - Web view

The investments made in commercial methodologies such as RUP are realized by providing the rich method content to its intended audience. This low-impedance way to access process guidance - such as steps, guidance documents such as templates, best practices and patterns - without leaving the IDE environment increases the chances of project success.
The Osellus team is ready to share the work it has done in this area at the upcoming rational conference in Orlando. Come see us at booth 427 from 11-13 June 2007.

In my last post, I talked about the concepts of flexible process enactment as illustrated by the scientific research findings by John Noll et al. in this domain. Our first generation tooling for process enactment has already implemented these concepts that have been commercially offered for more than three years now. We have received numerous lessons learnt and other feedback from process mature organizations that have tried to implement this tooling in their development teams. Based on that we have come to a conclusion that flexible process enactment (as explained by John Noll et al.), although an essential first step needs to be further augmented for a successful process enactment in real-life projects.

There are two key aspects in our approach that incorporates the idea of a flexible instantiation of a process model. First, the model being followed is kept separate from the project work item instances which represent the instances of the process. That is, even though practioners have a view into the process model they are following, the project work items they are executing are handled independently by the tool. Second, practioners have a view into the model and the flexibility to create as many instances of whole/part of the process model as the project progresses.

Let me take an example to illustrate this approach. The left hand side of Figure 1 shows a work breakdown structure that has been created in a process modeling tool. Our first generation enactment tooling would have created a single instantiation of this process model resulting in a 1:1 mapping of process model elements and project work items. This is similar to a straightforward object-oriented modeling approach of instantiating a class. Unfortunately this also results in an unrealistic single monolithic instantiation of the complete process model that is unsuitable in a dynamic project environment consisting of knowledge workers as practioners.

Figure 1

In our new approach, the process model would serve as a reference to create project work items on the fly. This would need to address both – known unknowns and unknown unknowns. For example to handle “known unknowns” such as instantiating iterations, a practioner would simply instantiate those process elements that are needed at a given point of time in the project. In our example only the “Determine Requirements” work definition has been instantiated as part of “Iteration 0” in the first series or thread. Later on, practioners have opened another series that has instantiated “Iteration 0” complexly. Next, they have chosen to instantiate “Iteration 1..n” as part of two series. At any time, practioners can double click the process work breakdown element on the left hand side to study published process guidance for that element. Another scenario could have been where a change control workflow is triggered each time a change request is entered into the system. Again this is a known unknown since the model cannot predict how many times the change request is raised but it can define a reference workflow that may be triggered in complete or in part depending on the nature of every change request raised. The series or threads would facilitate concurrency in the project environment as these threads could be executed simultaneously.

Figure 2

The “unknown unknowns” are handled by allowing practioners to create additional project work items that do not map to any process element (since that knowledge was not known at time of modeling). For example as shown in Figure 2, I can create a related activity that although not defined by the process model is needed as part of the project and follows the activity “demonstrate the architecture”. The enactment system would enable us to track and log how these instances are created. One use of this information would be to act as lessons learned to improve the process models for other projects that are being implemented in a similar environment as this project.

I have come across an interesting set of papers from John Noll et al. talking about their research in the area of process enactment. The paper on “Flexible Process Enactment Using Low-Fidelity Models” brings out some important points.

Examining the reasons behind the lack of success of conventional workflow execution approaches in “dynamic, knowledge intensive activities” Noll contends that “In part, this is due to the dynamic nature of such activities: actors in knowledge-intensive environments continually adapt their activities to reflect increasing understanding of the problem at hand, which results from performing the knowledge-intensive activities.”

Software development is an excellent example of this “dynamic, knowledge intensive” environment and I agree with the lack of success in trying to adopt the traditional workflow approaches in software development projects. In fact in my opinion this is why tools designed for portfolio management, project management or business process execution have not been successful in the software process execution domain.

Noll then introduces the concept of “low-fidelity process models”. “These models specify a nominal order of tasks, but leave actors to carry out their activities as their expertise and situation dictates” he continues. “A low-fidelity process model does not seek to capture every detail and nuance of a knowledge-intensive process; rather, it documents the major activities of a process and the primary sequence in which they are performed”.

Noll then illustrates the benefits of the low-fidelity process model:

“
Low-fidelity models are easy to specify, and can be generated rapidly.
A low-fidelity model still captures the essential facets of a process, especially the resources consumed and artifacts produced by a given set of activities.
Because they seek to represent only high-level detail, low-fidelity models are relatively stable; that is, they continue to be accurate descriptions of the high-level process, even as the details of process activities evolve in response to knowledge and experience gained with the problem.
”

Again, I am in full agreement with the concept and benefits of low-fidelity process models. With our practical experience in implementing SPEM-based process models for software development we have seen that processes that can now be characterized as low-fidelity have resulted in wide uptake by practioners. Often, teams have been able to construct these low-fidelity process models from scratch from internal home-grown methodologies or by blending their internal best practices with commercial methodologies such as MSF, RUP, Macroscope and so on.

Noll then defines as enactment “driven by events, which are classified as either process events or resource events…. A predicate in the process description specifies the state that the required resources must satisfy before the activity can proceed. Process events signal action initiation and completion, and are generated directly by actors as a consequence of performing tasks. Resource events reflect changes in the environment, such as creation, deletion, and modification of resources, and time events such as deadline or alarms….. The enactment mechanism enables flexible enactment through the way it handles process and resource events.”

Again, I am in complete agreement with this view of enactment. Unfortunately SPEM (SPEM 2.0 is currently under finalization) does not go as far as we had hoped in supporting this concept. Without this support for concepts of states and state machine, process models built using SPEM 2.0 will remain un-enactable. This also implies that methodologies such as RUP and OpenUP that use the underlying SPEM meta-model would be un-enactable.

In my experience adding support for enactment is not an un-surmountable task. Our first generation enactment system, IRIS Process Live v1.0, already fully supported the above by providing activity and work product state-machines as well as pre-condition and goal. IRIS Process Live detects and triggers task and or work product state changes and sends notifications based on the work-flow relationships, assisting in implementing the process.