autoRefresh() usage in webMethods Composite Application Framework (CAF)

When working with webMethods Designer CAF Development, consider enabling autoRefresh() properties during design-time.

Why? Because reference data or static data that used to populate drop-down options on the UI, enabling autoRefresh() return the results from cache. The underline attributes worked the same as caching in flow services - when the input data changed, only then that the service will invoke the web service connector for the updated result set.

The effect is streamlining the user experience and making navigation between screens alot more responsive.

This property is available in webMethods Designer, My webMethods perspective, under the Bindings tab.

Briefing on Issue Management

I have not found the time to attempt the ITIL V3 Foundation certification. But from time-to-time I advised customers on ITIL principles:

Issues can be identified directly or they can eventuate when risks are realised. Issues that cannot be resolved within tolerances (budget, time, quality, scope, etc) may lead to Change Requests.

Step	Responsible Role (Group / Title)	Required Output	Key Steps
1. Identify	All	Issue created on issue log, Status set to "Raised"	It is the responsibility of everyone to identify issues that are impacting a project. Identified issues are evaluated with the relevant Project Manager to determine if a true issue exists. Project Managers then log unresolved issues to the issue log. The status of the Issue should be set to "Raised"
2. Analyse	Project Managers Risk & Issues Manager	Issue log updated Priority assigned Status set to "Assessed"	The full analysis of each issue should occur within one week of the issue being recorded on the issue log. Ensure a full description of the issue is captured in the issue log. An initial assessment of the impact of the issue will be made and a priority will be assigned. Issues impacting business as a whole will be escalated to the Risk and Issues Manager. The status of the Issue should be set to "Assessed"
3. Action	Project Managers Risk & Issues Manager	Issue log updated Priority re-evaluated Issue Owner assigned Action Plan defined Status set to "Assigned"	Each issue is assigned to an appropriate project resource (Issue Owner). Issue impact and priority is re-evaluated with the Project Manager and stakeholders directly impacted by the issue. Actions that are considered appropriate to resolve the issue, are defined and an owner for each action is appointed with an appropriate due date for the action. The action plan must be agreed with the relevant Project Manager and stakeholders. The status of the Issue should be set to "Assigned"
4. Resolution	Issue Owner (Project Team Member)	Execution of action plan Status set to "Resolved"	Issue action plan is executed and progress is reported to the relevant Project Manager (and Risk and Issues Manager) via updates to the issue log and weekly meetings.
5. Monitor & Control	Project Managers Risk & Issues Manager	Issue detail included in status report	The monitoring and reporting of issues is an ongoing multi faceted process, this process is defined further in the section below.
6. Close	Project Manager (project-level issues) Risk & Issues Manager (program-level issues)	Status set to "Closed"	Once an issue has been fully resolved it should be closed within the issue log. The originator of the issue must confirm that the issue is resolved before it can be closed. When issues are closed a risk may need to be raised if the issue has the potential to reoccur. The status of the Issue should be set to "Closed"

Virtual scaling pattern

While reading into software architecture to support high dynamic scalability and high availability I stumbled upon on a well-written article, The Impact of Virtualization on Software Architecture by Nishant Thorat and Arvind Raghavendran.

Scalability and high availability has been one of the painful realisation for one of my customer. Three months after go-live they starts to find performance issues and the solution struggling to process large number of business transactions. Amongst the 41-page recommendation report, as a tactical (short-term) resolution I recommended the customer to go with virtual scaling pattern to ease their immediate pain.

Figure source: The Different Paths to Virtualization, Issue 24, The Architecture Journal

What I learn from the Virgin Blue IT incident

There are three major factors determine the quality of a product: the people that
develop a software system, the technology that is employed by them, and the organisation of the process of development. In today's ever growing size and complexity of software projects, steering committee are investing into processes cope with the business stakeholders demand.

High cost project, late delivery, resource dependence are all symptoms of lacking processes.

The role of IT is to deliver software products to the business with minimal disruption. As a customer, I experienced the disastrous go-live of Navitaire New Skies ticketing system at Virgin Blue.

Here is a Release Management process I've developed for many clients to introduce "quality gates" into their SDLC. You may have notice that this process have emphasis on the Quality Assurance Testing phrase, from experience solid testing will yield good outcomes.