Skip to main content
I'm interested in contact from any current K2.NET user/manager on the subject of best practices and procedures--specifically things like

:?: staffing and organization: how many people for how large an operation? what job breakdowns? project team composition? How has, or ideally how should, K2.NET affect your IS/IT structure?

:?: development SOPs / methodologies
What internal procedures have you found you need to manage source code? Do you have standard procedures documented for design standards, development milestones, user interaction, project selection or estimation, etc.? How do you, or ideally how should you, plan and implement a K2.NET solution?

:?: map/resource organization
Once processes are running, how do capture lessons learned, extract to process templates, manage re-usable code libraries, etc? How do you, or ideally how should you, manage existing K2.NET processes as a business resource, and prevent continual one-off re-development?

bobD
Hi Bob,

Just a couple of notes, more form experience than from any formal method.

K2.Studio allows you to develop your own templates for all the types within the system (processes, events, rules, etc.). I have developed a couple of solutions that entail the tempating of processes only while I know that the first steps and the last steps will always be the same. For interfacing with a known subsystem I have built event templates that expose the underlying API as discrete events. On top of this I have built general event templates that accomplish simple assignments that K2.Studio lacks.

Once completed I have placed the K2 projects under source control and built Setup programs that install each of the utilities into the K2 Studio environment.

This is a rather large investment, I know, however, I have standard components which users can drag and drop like any other standard type within K2.Studio. Thereafter, the philosophy is to develop using a standard OO approach to the above.

Hope this helps

Graham
Hello Graham--

"only while I know that the first steps and the last steps will always be the same. For interfacing with a known subsystem..."

Sounds very much like an OO-style modularization of a larger process. Do you displace sub-processes into their own maps, called from a higher level map? If not, why not?

"I have built event templates that expose the underlying API as discrete events. On top of this I have built general event templates that accomplish simple assignments that K2.Studio lacks."

That's very interesting. You have a simple example you could share?

"Hope this helps"

Yes--good food for thought.

Thanks,
bobD
Hi Bob,

My background is very much an OO background. Although in the case I mentioned ther are basically three layers of processes. There I completed a higher level abstraction of the overall business processes, a middle layer that dealt with the "getting things done", i.e. the specific business tasks at the user level.

The third and bottom layer interfaced to the production machinery itself. Here there was a considerable amount of repetition and therefore I could build the stub processes as templates to be selected in Studio as required.

The templates I mentioned are built using the SDK provided by SourceCode and available from your local representative. Without this SDK anything I post would be just lines of code. However, once you have the SDK I can then help you with an example. If you are looking for examples in the meantime, you could look in the online help as there are the threads of an example used to describe the K2 APIs.

Regards
Graham

Reply