Welcome to Business Analysis New Zealand

Featured

Welcome. This site is built for businesses that require business analysis work, and for business analyst that work in New Zealand. Our ambition is to create a central resource center for one of the most important and wanted subject matters in New Zealand – business analysis, with focus on IT businesses and mainly on internet and web systems.

This site is updated on a frequent basis, while currently we work to publish document templates for free download: requirements document, detailed requirements, project initiation document, risk analysis, release management template and other templates that we have collected after years of experience in IT.

So check us again soon and please don’t forget to leave feedback!

Cheers

Random numbers – how to do it?!

Randomizing numbers, with a computer program, is always an issue – this is because most functions use the computer clock, and thus don’t generate a “real random” number. The following idea is to feed the monster with its own tail, i.e. feed the random function with the system clock, to generate a better random number.

The math behind the idea is:

1) Choose 2 numbers, in between the two numbers you want to generate -

MINIMUM — NUM1 —- NUM2 —- MAXIMUM

2) Now choose two random numbers between 0 and 3. For each set, randomize it again, so – for example if the set is (0,1) then choose a random number between MIN and NUM1 but if the set is (0,2) then choose a random number between MIN and NUM2, etc.

The following PHP function will do the work for you, I simplified it so it is easy to debug it even for PHP beginners. Enjoy it :-)

function generate_random($start_num,$end_num)
{
if ($start_num >= $end_num)
{
$the_number=$start_num;
}
else
{

$numA = rand($start_num,rand($start_num,microtime()*$end_num*10000))%$end_num;
$numB = rand($start_num,rand($start_num,microtime()*$end_num*10000))%$end_num;
do {
$numB = rand($start_num,rand($start_num,microtime()*$end_num*10000))%$end_num;
} while ($numB==$numA);
$num['0'] = $start_num;
$num['1'] = min($numA,$numB);
$num['2'] = max($numA,$numB);
$num['3'] = $end_num;
$dnum1 = rand(0,3);
$dnum2 = rand(0,3);
do {
$dnum2 = rand(0,3);
} while ($dnum1==$dnum2);

}
$the_number = rand($num[min($dnum1,$dnum2)],$num[max($dnum1,$dnum2)]);

return $the_number;
}

“Web Standards” vs. “Web Strategy”

“Standards” are specific and detailed requirements derived from the web strategy and aimed to act as a guideline for building web systems. The department of internal affairs has already published technical web standards, but those are touching only the front-end side of web systems.  Our team has felt the need to extend those set of web standards to other areas of expertise such as the technologies, frameworks, databases, release process, security and more – as outlined below. The schematic picture below is describing the flow of thought and planning from our “web mission statement” to “web standards” through the suggested structure of “web strategy”.

What is a “Client-Server” application?

Almost every web service[1] is based on an internet connection between clients – these are the “users’ computer stations” – to a server(s) – this is a central[2] computer which is answering the users’ requests and serving them with the appropriate information. A static website is the most common example of a client-server application: the client (the users’ browser) is requesting a HTML page from the server, which is sending the page’s content back to it.

Client Server Applications

 

[1] P2P (Peer to Peer) applications are an example of a web service which does not necessary use a server, even that most of them are using a server to store user information / protocol information to establish the connections between the peers.

[2] The general case is simplified here to a case of a centralized system. Some systems are dis-centralized and using many servers located in different geographical locations with a protocol that swaps the data between the servers according to pre-defined set of business rules.

What is “Web Strategy”?

1.1    What is “strategy”?

“Strategy”, by a dictionary definition, is “a plan of action or policy designed to achieve a major or overall aim”. We highlight the word “overall” not because it is highlighted in the dictionary, but because people tend to confuse “strategy” with “tactics”: strategy should not go to the level of detailed plans, but to leave enough space for several detailed plans to fit with the same strategy.

As an example we can look at a “Recession Strategy” to “Save Resources” or to “Create five new resources” or “Multiply our income by 120%/year”. The strategy is not stating the detailed plan how to achieve those goals, but is definitely setting goals. The “plan” (or the “tactic”) will set the agreed steps to achieve those goals.

1.2    What is “web strategy”

Searching “Web Strategy” over the web would gain results mainly in relation to the “web presence” of companies on the internet, mainly – how companies should improve their presence in the web, or in other words – how to use the web as a  marketing tool. Unfortunately not a lot is published out there about an overall strategy, which to our definition – is how organizations should aim ahead in the web territory, maybe 5 years ahead by saying “this is where we want to be”. Searching for “government web strategy” gains a bit better results – one of the highlights is the “Web strategies” chapter of the “New Zealand e-Government Programme”, but this paper is not an e-government strategy for itself but written as a guideline for government agencies “how to develop web strategies” with a high-level requirement originated from the legislation to maximize the ability of the public to access information over the internet (“Government departments should make information available easily, widely and equitably to the people of New Zealand”).  This high level requirement is the e-government “mission statement” which is setting the high level goals, as part of our demonstration how to develop your organizational web strategy.

[will be continued in the next posts]

 

Proper release process

A task release of one of my team members has failed, and as a consequence of that I have received an Email from the vendor (one of the leading IT companies in New Zealand), trying to track the origin of the issues and learn a lesson for the next time. Process improvement is of course the right attitude, but when I looks at the vendors’ email I found out that a fundamental release standard has not been fulfilled: it looked like the release package included a SETUP.XML file which failed in the TEST ENVIRONMENT (the test server), so prior to releasing the package to PROD environment (the live server), the vendor has fixed the files. He complained that my team member has failed in fixing the SETUP.XML file before releasing it to PROD, and asked us to do it properly in the next release.

The complain looked a bit strange to me, so when I investigated our team member, she has told me that the SETUP.XML file has passed TEST, but failed in PROD. So then she copied the file from TEST to PROD it all worked fine.

Have you notice in this story what I have noticed?? Read it carefully again, before you go on with reading this case study.

Something is the above story didn’t fit – the vendor claimed one thing, and the team member said something else. But what was alerting me is that both the vendor and my team member acknowledged that the release package was different to TEST and PROD. I asked my team member about it, and she said – “In every release we receive from the vendor three release packages – one for DEV (the Development Server), one for TEST, and one for PROD (the live site)”.

Well, this is wrong, and I’m not talking about the wrong usage/terminology of DEV, TEST, UAT and PROD environments (I will write a separated article about that later on) : a robust release process is a process in which the implementer is receiving ONE release package and ONE only. That release package should be released to TEST for system testing, released to UAT for user acceptance testing and then released, if signed-off, to the live environment. Any other process in which you compromise the integrity of the release package, is wrong and exposing your application to problems. It does not matter if the vendor is “the largest IT shop in New Zealand” or if it is just “to play with the code” or “adjust the files” or “re-fix the application” or “re-sync the server”…. It does not matter how nice you say it – what you really do is to misuse the SDLC release process.

To follow a robust release process you need to employ a strong release manager – someone that will bounce back a release package to the vendor, and demand to fix it in DEV, only then to deploy it to TEST again, i.e. to re-start the release cycle.

About “release cycle” and the requirements from a release manager – in one of the next posts.

Yours…. BA from Wellington

GSA (Google Search Appliances) – to use or not to use?

GSA is a Google Search Appliance – a piece of hardware that implements Google search in your organization.

GSA is one of the most brilliant services that an organization could use: you plug this box to the network, define which servers / services to index, and you got a search with full Google capabilities in your organization. There are lots of advantages to use GSA as a search service:

  • Good price: It is fairly cheap in comparison to all other products and services
  • Highly reliable - I never heard of any issues or support calls in regard to it (in contrast to other IT services which usually consume hours and days of support)
  • Google search – is still, unbeatable. The Google ranking method is the best still, even that other search services (like Bing and many small ones) are rapidly improving and may beat Google in the future.
  • KISS (Keep It Simple Stupid) – the administration GUI is simple to use, I would say straightforward. I don’t see any reason for en experienced IT support person to use it without any training
  • Fast – implementation is fast…  it is as fast as your ability to design a webpage that calls the GSA API and returns the results (I would say – if it takes you more than a week to install, check carefully if your IT support vendor is the right one)
  • Customization - great ability of customization and additional services.
  • Format safe: the GSA (like Google search) will index all formats – HTML, PDF, DOC, PPT…. the list is endless.
However, using a GSA considers two major high risks that unfortunately many government organizations in New Zealand and commercial companies do not consider. I saw the GSA entering many agencies and government organizations in Wellington, and in my experience I implemented it in two major Government organizations (major = in the top 10 list of New Zealand Databases).

2 Major risks in using GSA: Privacy, and Security.

1) Privacy act and the GSA: the GSA is a black box – it is closed and the organization is not able to access the hardware or the physical storage in the box. It is almost like having “the cloud” but inside your network. Indeed you can define what SHOULD be indexed, but it does not mean that this is what is indexed in practice, but just what is searchable by the API. According to the privacy act, a person can (at any time) ask an organization to browse / remove all the private information collected on him/her: could you do that AFTER you indexed your information with a GSA? I believe that one day, a random court case to will challenge all the Government organizations that plugged a GSA to the network without considering or managing this risk.
2) Security: Google indeed have the best developers on this planet, and they are creating the most reliable and secured applications ever. However – we are letting the cat guard the cheese when we use the Google Inc to index our internal content: Google is company that makes its income from selling information: advertisements, data mining, data intelligence –  these are the main targets of the Google Inc. Maybe when you implement a GSA, Google is not selling your information directly to third parties, but I doubt they are not using it at all for selling statistical information (like – how many households in NZ have a heat pump – lets not forget the Google planning to resell electricity – this stats could help them!).
The GSA is a black box which (as we said) is indexing content, i.e. replicating (copying) this content to the GSA’s database. So when you implement it, the GSA contact includes the following:
  • The box is closed
  • Only the headquarter of Google in California are allowed to access or connect to the box.
  • In order to receive support, the client is required to open a firewall port allocated for Google California.
So basically what it means is that Google are using the local vendors which are implementing the box, only as a re-sellers.  Even Google Asia and Pacific which headquartered in Sydney, don’t have an access to a GSA box installed in Wellington, New Zealand. Now, you need to add 1+1 to asses the risk:
1. Is your GSA indexing secured information?
1. (the other 1) – The box could not be accessed outside your network, EXCEPT by Google California.
The meaning of it is that if you handle secured information, all your secured information could be accessed by Google Inc. This should be a major factor in making the decision if to implement a GSA or not, either by Government organizations or by commercial companies which own secured information.
I hope I helped :) – Yours – Business Analyst, Wellington, NZ.