Monthly Archives: September 2015

A short answer to a Bank Manager about Software as a Service and SOA

Recently, I met an executive of a top bank who was trying to roll his head around the notion of software as a service and service oriented architecture. He intimated to me that these two terms are the only things he hears from software development vendors and the internal Information Technology team. I offered an explanation that went as follows.

Software as a service represents a shift in the way software is developed and used. In traditional software development, the software executable or program  code is installed on the users computer. This requires a copy of the same software for each user creating challenges in updating, maintenance and licensing.

SaaS allows software to be installed and used over the Internet or Intranet. It allows a single copy of the same software to be used by different users from a single location through the network, which may be  intranet or internet. Even when multiple copies are deployed, they provide redundancy rather than a copy for each user. Under SaaS, access to the software is strictly through external Application Programming Interfaces (API). To encourage loose coupling, the mode of communication is usually message passing. Because the software is used through an external interface and most often owned by a different party,  this is sometimes referred to as consuming a service.

An architecture that is based on consumption of different capabilities of software programs by way of external interfaces is called a Service Oriented Architecture (SOA). With SOA, solutions can be built faster because we rely on existing SaaS functionality and add only what is missing. Incase of failure of one SaaS provider, it is possible to switch to other providers. Moreover,   most SaaS vendors allow consumers to pay for only what they consume.

He appeared to understand and promised to get back to me, and will give feedback as soon as I hear from the manager.

2,708 total views, no views today

Problem Solving – Analyse/Understand the Problem

The goal of problem analysis is to gain better understanding of the problem being solved before development begins. It is import to know why the problem is occurring, when and how often. Try to understand the first cause of the problem. Root cause analysis is a systematic way of uncovering the root, or underlying first cause of an identified problem or a symptom to the problem. Tools such as fishbone diagram or pareto chart can help visualize the problem.

Identify stakeholders – understand needs of users or other stakeholders. A stakeholder is anybody affected by the implementation of a new system or application. Probing questions include

    • who are the users of the system?
    •  who is the customer?
    • who else will be affected by the system?

Define a solution boundary- the solution boundary divides the world into two parts, your system and the rest of the things that interact with your system. The system boundary defines the border between the solution and the real world that surrounds the solution. A boundary is an interface between the system and the environment or other system. All interactions with the system occur via interfaces between the system and the external world.

Understand what is involved in solving the problem. This is involves a identifying what is information is needed and what information is available.

Identify constraints to be imposed on the system – a constraint is a restriction to the degrees of freedom we have in providing a solution. Constraints may be political, economical, environmental, technological, materials and resources as described below
Economical

  • What financial or budgetary constraints apply?
  • Are there costs of goods sold or any product pricing considerations?
  • Are there any licensing issues?

Politics

  • Do internal or external political issues affect potential solutions?
  • Are there any interdepartmental problems or issues?

Technology

  • Are we restricted in our choice of technologies?
  • Are we constrained to work within existing platforms or technologies?
  • Are we prohibited from using any new technologies?
  • Are we expected to use any purchased software packages?

Systems

  • Is the solution to be built on our existing systems?
  • Must we maintain compatibility with existing solutions?
  • What operating systems and environments must be supported?

Environment

  • Are there environmental or regulatory constraints?
  • Are there legal constraints?
  • What are the security requirements?
  • What other standards might restrict us?

Schedule and Resources

  • Is the schedule defined?
  • Are we restricted to existing resources?
  • Can we use outside labor?
  • Can we expand resources? Temporarily? Permanently?

3,449 total views, 1 views today

Problem solving -Define the problem

“Until the problem is well defined and articulated it is impossible to arrive at a solution”

The first step to solving any software engineering problem is to define the problem. Articulate the problem and eliminate all unnecessary terminologies and jargons. Start by reading the problem completely at least twice. Read and establish the context of each key word. If time allows, research about the problem.

Ensure that there is agreement on the problem to be solved. Try to restate the problem in you own understanding.  Find out from the person who posed the problem whether the restated problem is the same as the original problem. Identify instances of the problem and see it is possible to solve an instance or example problem A solution to the example problem may lead to insights about how to solve the general problem or bring about any remaining misunderstanding.

Look at the problem from multiple perspectives. Each perspective may reveal additional information about the problem. The problem should be distinguished from its symptoms such that the root cause properly identified and stated.

The output of this step is a well-defined and articulated problem that focuses on what is required for its solution.

1,552 total views, 1 views today

Software programming and problem solving

Programming is the process of planning a sequence of steps called instructions for the computer to follow. The fact that you are reading this post you already know that computers lack common sense and cannot make any judgment. So the computer will do as instructed by the programmer through the computer program. Programming is more about problem solving than coding.

A problem is the difference between things as perceived and things as desired. A solution will move the situation from the things as perceived to the things as desired.

Programmers are problem solvers and need to improve the art and science of problem solving. On one hand problem solving involves an element of art in that experience, judgment and common sense can help deliver smart solutions. On the other hand problems solving is a science involving scientific means of arriving at solutions. Overall, there are several steps to be taken to solve problems

  • Define the problem
  • Analyse the problem
  • List/Identify  alternative solutions
  • Select the best solution
  • List instructions that lead to the solution using the selected solution
  • Evaluate the solution

in the next post, more details on each step shall be discussed

1,393 total views, no views today