The range of projects undertaken in today’s world presents Business Analysts with many challenges. One challenge we need to consider is how to represent and analyse more than one information type.

During the seventies there was a lot of research into representation for information or knowledge types. This area grew rapidly in late 1980s onwards providing guidance when and how to use knowledge representation techniques for solving particular problems.

This research has shown there are only two major classifications of information

• domain-related information – informationabout the area of interest, its terminology anrules
• task-related knowledge – the general reasoning mechanism or pattern of logic used as part of the task to solve a particular problem

Work in Domain knowledge is very familiar to us as BAs, and has led to the development of a hierarchy of concepts within a domain, using a shared vocabulary to denote the types, properties and interrelationships of those concepts. They provide a structural frameworks for organizing information. The creation of domain ontologies is also fundamental to the definition and use of an enterprise architecture. As such these form the basic language of the domain, with different techniques required by the BA to analyse the domain knowledge at different levels.

Work in Task knowledge is less familiar. This has led to a series of re-useable problem-solving patterns evolving. There is now a series of standard approaches to common problem-solving tasks – with a number of different representations involved.

A number of classifications of tasks have been produced over the years. All variants on a theme, looking at the types of task we typically carry out. The most popular and straightforward (and therefore useable) classifications splits tasks into Analysis operations and Synthesis operations, and subtype tasks in a hierarchy within these.

Analysis tasks are usually the best known, these generally involve a good understanding of the domain, such that if you know a certain amount of information you can work out the missing pieces. The solution or answer pre-exists, is known and can be articulated. Typical analysis tasks include interpretation, classification, identification, prediction, assessment and control, monitor and diagnosis.

As a BA we might use techniques which represent logic flow and decision making such as decision trees, decision tables, flowcharts and business rules perhaps – activity diagrams are particularly good for this.

Synthesis tasks are less well known and are typically more complicated. In these tasks information is combined, usually under a series of rules and constraints, to create a solution. The inputs and constraints are known, the output is not, it is generated.

These tasks combine elements to form solution with constraints applied via rules. Typical tasks include construction, specification, design, assembly, configuration, planning & scheduling.

It is more difficult to specify techniques for a BA to use here. The reasoning is constraint-based and this is not something we often major on. It’s a “propose and refine” type of activity – UML activity diagrams have been used here. We might again use techniques such as decision trees, decision tables, flowcharts and business rules perhaps to represent these tasks. For advanced planning and scheduling problems we may use genetic algorithms or other fancy stuff.

In our normal BA work we probably don’t think about task knowledge very much. Well not explicitly. As BAs when we are looking at how someone performs a task, we are in fact analysing the reasoning pattern or logic or business rules used to carry out the task. Very often the same “type” of activity is performed over and over again in different domains, using different domain knowledge – but the same reasoning is followed. In all probability we won’t recognise this and as a result we won’t recognise where common re-useable patterns exist. In order to do this we need to apply a level of abstraction to our analysis – again something we don’t do often. This area represents part of the toolkit available to us that we seldom use nowadays and could, perhaps, consider more.