I’ve found people can be surprisingly approachable about discussing things you may wish to achieve as long as you have enough material to talk about and believe in what you’re trying to do.

I think communication is a trick some people do miss which causes problems long term in business and in one’s personal life. Even if you’re not the most confident of individuals, discussing something on the internet can be a useful tool. Sometimes you can reach the exact types of people you’re looking for to discuss something on the internet, although of course the opposite is also the case (but even this might help you to decide that perhaps your target audience differs to the audience you originally envisaged).

So there’s a bit of food for thought for anyone thinking of developing their ideas into something productive; its worth approaching and discussing them with the relevant people, after all you’ve nothing to lose.

However there appears to be many businesses out there which seem to value style and the grandeur of pure ambition over conveying meaning and providing assurance of what they can offer. This is particularly evident in small ‘web and software development’ companies, as well as technology based consultancies. People may be initially drawn in by the customer pulling power of sleek design and an attitude that says “we’re so modern we wear trendy clothes in our office, we advocate ‘blue sky thinking’ and we have a mass following on twitter”. However closer inspection often reveals that many of these development companies are in fact largely visual design companies instead, and a lot of technology consultants aren’t in fact sure what services they are offering and to whom.

I’m not bashing the services which such organisations may provide, merely their online marketing strategy. I don’t pretend to be a business and PR expert, but I feel that many businesses such as those described above are misdirecting their time spent on their online image. A slick visual approach to enticing customers may work for end-user oriented services, that is – those which are available through the site itself. But a customer base of business users are instinctively more deliberative about their perusal of who you are and what you can offer, so this needs to be tailored to their expectations.

Interestingly SWI-Prolog has many libraries making it pretty much ready for use in a distributed environment, and it wouldn’t seem to hard to implement a form of web-service using the Prolog engine to make logical deductions. In fact I’m working on a specification for a system which would make knowledge/intelligence based software more accessible to end-users, potential business adopters and software developers alike.

It will be interesting to see how things pan out with this development, I hope to be able to have a demonstrable system which can show the potential of intelligence based software architecture.

My take – brilliant; put yet another spanner in the works delaying Oracle’s acquisition of Sun and therefore jeopardise all of Sun’s products including Java which put simply seems to me much more important than MySQL.

At the end of the day business decisions are all about compromise, sometimes you have to sacrifice certain things in order to save others. In an uncertain economical climate the more the buy-out of Sun by Oracle is delayed the more damage could potentially occur. To take it to an extreme Oracle may never actually complete the purchase of Sun and then the future is bleak for all Sun technologies which would be a very bad thing indeed.

Ultimately the evidence (empirical and anecdotal) seems to point towards the fact that outsourcing work does not in fact save money in the long-term! Shock horror!

The main reason cited for this is the clear communication problems that can occur when work is outsourced to a development organisation in a foreign country. This communication barrier is due to a combination of factors, and I believe is far more complex than one might assume by face value alone. It seems that systems analysis and design techniques are relatively sophisticated these days with the inclusion of detailed Object Oriented class diagrams. It is also true that developers in foreign countries often do have qualifications that should indicate they are capable and skilled programmers and it is also true that many have qualifications that are supposed to assert their aptitude at carrying out work outsourced to them from another country.

You would think with this combination of design skill on the outsourcing side and development skill on the ‘outsourcee’ side that these projects would be really rather successful.

However as I have already mentioned this is often not the case, with the company paying for the outsourcing often also having to pay for large amounts of quality assurance (QA) in order to check and fix poor quality coding. All the factors to blame here seem to essentially come down to this communication problem: That these people are not working together in the same office, with the same level of understanding of language, cultural and business paradigms. As a result all manner of misinterpretations occur and cannot be resolved due to the lack of easy clarification of problem areas.

This leaves both sides quite able to hold their hands up and say: wasn’t my fault this didn’t work out!

I do not presume to be so clever to present a solution to this problem. Sometimes outsourcing software development is successful. But it seems clear that currently the software industry is still not a universal language-independent industry. With software different people work in different ways on different problems. While some applications of software development are common and proven, such as many e-commerce solutions for shops that wish to sell their stock online, many more applications of software development are so hugely varied and often previously unexplored.

Anyway I’m rambling on now. From a programmers perspective it is curiously appealing to think of software development as  a bit of a mysterious art, from a business’ perspective it is probably hugely frustrating.  However when skilled people are working together collaboratively in the same environment – both analysts and developers – it is a very creative and productive atmosphere. Under these circumstances people are much more effective at establishing a clear design and implementation pattern that works for them.

In short the most important tool to use in the specification of a software system still seems to be verbal communication in person. This allows discrepancies to be clarified and the project as a whole to be managed in a consistent manner.

While I’ll refer in particular to the Java Enterprise Edition based (J2EE) solutions, the principles of structuring an application are the same in other development platforms.

So from a high level perspective, the following components are common to most web apps:

Server Side Components

Permanent data store: Most usually a relational database (RDBMS), which can be interacted with through SQL. This can take any form of interaction; from other parts of the application simply manually connecting and running SQL statements to quite complex persistence management components which automatically update and query the database using the objects in the system.

Data model: An abstraction of the information that the application needs to manipulate, generally always defined as classes in an Object Oriented manner in the relevant programming language. They may for example mirror members of a particular web-site and their member details, or items in a catalogue. These model classes take varying levels of complexity; in Java they may be Plain Old Java Objects (POJOs) or more complex Enterprise Java Beans which can directly linked to the database using a persistence management component.

Persistence manager – A layer which acts as a middle-man between the data model classes and the data source.

Interaction controller: The controller manipulates the data model based on the interaction the user carries out in the user interface. This can be a very thin layer, but it’s existence is important to act as the entry point to the server side components – seperating business/application logic from the user interface. In Java web development this is usually a servlet.

Client Side Components

User interface: A full blown application or website that is run on the client machine, most often in a web browser. There are a variety of technologies which may be used here. It could simply be a HTML page using HTML forms or it could incorporate an AJAX-style language that uses javascript, or converts its code into javascript. The primary reason for using javascript as a client side run time technology is the convenience provided by the incorporation of javascript interpreters into nearly all web browsers, meaning users needn’t first download anything to use the application. Often as far as a user is concerned a web-app is simply another web-page offering more interactivity than is usually available. The complexity of this layer depends on the complexity of the UI components required.

The separation as to where certain code and features of an application should go is an important business issue, as there are certain issues relating how thin the client side is. Generally it should be as simple as possible, as it is harder to maintain client side code and carry out complex processes there.

Anyway that’s a very straightforward summary of the common structure of web applications. The specific technologies used to implement web app solutions vary incredibly and there is no right or wrong mixture of technologies. It is important not lose sight of the overall architecture of web apps and not get bogged down with doing too much with one very specific technology and try to do everything in that space (which you might do if your very familiar with it or like it better than another). The fact is that development is a process of breaking down problems into ever smaller chunks which often require different approaches to solve.

Essentially all I’ve done is kept in the most important parts of traditional ‘SSADM’ style analysis: defining the organisation in terms of data flowing through system processes, and assessing the possibility of improving these business processes. The former stage I have referred to as system data flow and the latter I have redefined as business development decisions. The final stage I propose is called technical development decisions. The reason for defining these stages as ‘decisions’ is because that is predominantly what the process of analysis is itself – making decisions with valid justifications.

My version of systems analysis I have tentatively named systems analysis distilled.

You may be wondering: Why did I bother? Well, as described in the previous post, my reservation with traditional systems analysis is that it does not relate well to the technical implementation of solutions. Likewise simply using an Object Oriented approach when carrying out systems analysis doesn’t cover the business considerations. There are also issues with the scalability of traditional methods – there is too much padding (in terms of drawing diagrams and ‘logicalisation’) certainly not relevant to smaller organisations, and if we are honest some are not relevant to any organisation today.

More than this though, my motivation is actually to clear up the confusion about how the analysis as a whole fits together, and how this fits in with the entire development lifecycle; from analysis to design and implementation.

So for those that may be interested, assuming there are any, behold systems analysis distilled

(I don’t expect the diagram to convey everything I am trying to explain, but it should give an idea)

Please bear in mind all work on this blog Creative Commons licenced

adverts that are for products I have no interest in or products that I in fact dislike the very idea of, are where the frustration lies. Unfortunately that’s a subjective thing, and makes me think that perhaps much or all of current internet advertising should be axed or at the very least better targeted to the user

So I found it interesting that groups such as the Centre for Digital Democracy are building a movement against targeted advertising on the grounds of privacy.

However as I explored in my last post the alternative to adverts that are not targeted is shoving adverts that bear no relation to the user in their face. Mike Zaneis, vice president of public policy for the Interactive Advertising Bureau told the BBC that

…the beautiful thing is they don’t have to click on that advert, or pay attention to it or do anything.

This statement aggrovates me just about as much as inappropriate advertising does because most online advertising demands you do pay attention to it, especially if it is animated. I defy anyone not to at least notice moving advertising on an otherwise static page, particularly if the advert obscures the content you are trying to read.

I fully understand the need for advertising to support online business, however I feel that people on both sides of this argument are missing the mark. There needs to be a compromise between privacy and how appropriate the advertising is to the user. And the visibility of internet advertising has gone way too far, with adverts even imitating common parts of the websites they appear on and sometimes requiring user interaction to minimise them otherwise they take over large parts of the page. In my view this is a borderline adware tactic.

Internet advertising needs to evolve in a more intelligent way otherwise it may suffer the fate of many ‘pushy’ sales techniques in alienating the potential customers and therefore websites declining to opt for it in fear of losing their user base. In my opinion there is nothing ‘beautiful’ about internet advertising in its current state, and simply saying it can be ignored is just the same as saying television and printed media advertising can be ignored. The difference is a computer is the domain of the user, they like to have control of what they are viewing and the world of the internet has the technical infrastructure to make this possible and could be a sophisticated medium for subtle and acceptable advertising. At the moment it is simply yet another annoyance built into our technology among many that will eventually fall prey to technological natural selection.

• Giving consideration to integrating the new system with existing systems
• The complexity of some processes that to the end user may look like a simple action. For example sending a request from a particular supermarket store to their supplier; you must handle various problems such as validating stock, allocating stock, updating status and passing the order between various parties involved – do head office nead to know about it? How do I talk to the supplier’s system? etc..

Obviously here we’re thinking about broad architectural decisions involving large organisations, which is unlikely to be in the remit of your average development job. However they do have a knock on effect in terms of the technologies implemented that developers will end up using to put together their particular area of the system. Additionally it has made me realise there is more to the world of business software over the internet than meets the eye.

Clearly solutions must be scaled depending on the business’ requirement of the software, and simple solutions are very appropriate in many circumstances. But it has been interesting to see what lies on the other end of the spectrum of system requirements.

… And I’ve surprised myself with how removed from specific technical issues or pretty UI screens that post was!