database

In-House Developed Software

by

Overview

A significant amount of in-house developed software is often created by the in-house IT area.  A key symptom is a proliferation of Microsoft Access databases. 

Although the positive results can be significant from developing in-house software, and this approach often removes the need to purchase very expensive software (and software in some cases that does not exist), several issues should be taken into account before developing in-house software.

Technical Issues

The use of Access databases may not always be technically appropriate. In particular, it becomes difficult to integrate Access databases and maintain software application versions across a network without affecting network speeds .

Stepping Outside the Budgeting Process

Often, the systems developed appear to be undertaken as requests from end users for software that cannot be funded from the budget. Software may be developed that address the required business functionality, meet the users’ needs, and save significant up-front investment costs. However, the application of resources (i.e. a staff member’s time) is not allocated according to a business need – the IT area spends its own resource (time) for another department to save resources (budget).

It is often difficult (but not impossible) for an internal application development team to consider the issues objectively and to act in accordance with the enterprise’s best interests. As part of the same enterprise, they can face internal pressures to develop information systems that would not be developed were the arrangement at arms’ length (as would be the case with a third-party software developer that must charge fees to be economically viable).

Uncertainty of Outcomes

When software is built in-house, the cost of doing so may initially appear to be less, as there is no profit component included and any overheads are considered to be ‘sunk’ costs.

However, the likelihood of achieving the benefits is less certain. Therefore, the benefits should be reduced by this risk factor when considering in-house systems for development (or alternatively, the costs of the project can be increased by the risk factor) in order to consider properly the business case of the application development. It is not appropriate to say “this database will save $10,000 on the cost of a new off-the-shelf system”. The potential benefit needs to be discounted by the risk factor that applies.

Additionally, the long-term support and maintenance of the developed information system is often not given proper consideration in the business case. Once the application is developed, there is a need to provide support and maintenance for that system in the long term and, without an extended user base (i.e. other businesses to share the costs with – as is the case with a packaged solution), the costs can be considerable.

Staff Retention

Linked with the issue of support and maintenance is the difficulty of attracting and retaining in-house application development staff. Application development staff generally prefer to develop new information systems rather than maintain existing systems. Retaining that corporate experience with the information system over the life of that information system with an in-house application development team can be difficult if the ability to challenge and extend the skills of the internal staff is limited.

In this case, a single person has created a significant number of database software applications. Although the software development environment chosen may be relatively mainstream (e.g. Java, Microsoft Access, Microsoft.Net), the risk exposure remains that future maintenance and development will fail due to staff turnover, or at least of the limits on that staff member’s available time.

Software Development Lifecycle

When a packaged application is purchased, it is expected that the software developer will carry out future research and development such that new technologies will over time be integrated into the product. With an in-house application, this is unlikely to occur – rather the system will tend to be redeveloped or have new technologies integrated only when the functionality loss is too much to bear, or at crisis points in the system’s lifecycle (e.g. when it suddenly stops working).

Risk-Adjusted Cost/Benefit Analysis

For all of the preceding reasons, there should be reservations that the benefits of in-house application development can be achieved.

Accordingly, it is suggested that any consideration of an in-house application development project take the approach of a Risk-Adjusted Cost/Benefit Analysis. Here, the business case for the development of a new in-house application solution for member management needs to incorporate a risk-adjustment factor in consideration of the costs and benefits, and provide a range of costs/benefits for consideration. That is, the uncertainty of actual costs and the uncertainty of actual benefits being realised is factored into any consideration of an in-house application development project.

Strategic Grid

Consideration of the following strategic grid in evaluating new information systems for external purchase or internal development may be of assistance:

Important questions for consideration include:

  • Identifying existing in-house applications;
  • Identifying existing applications that are appropriate (and developing technical documentation for these applications); &
  • Migrating from existing applications that are not appropriate to new solutions.

It is often valuable for a business to develop a policy for the development of in-house application development of software solutions that takes into account the strategic grid outlined, and the risk-adjusted cost/benefit analysis.

IT Governance Day: Is IT governance just for geeks?

by

Well if it’s Monday – and it isn’t (at least not in Australia) -  that means it is IT Governance day at the blog.  I could start with a fundamental overview of the world of IT Governance and set out an agenda of blog entries for the next few weeks – but I won’t.  That would probably be too ambitious – so I’ll start with a fundamental flaw in, apparently, just about everyone’s thinking.

Tying this post back to the subject line, not only is IT Governance not just for geeks, it isn’t for geeks.  IT Governance is ensuring that the entirety of the IT system works towards achieving business aims and strategy.  It relates to ensuring that the portfolio of IT people, processes, and technologies is in balance.  That role absolutely has nothing to do with IT speak.  And yet I have been approached by journalists and clients alike in the past with the absolute underlying assumption that IT is very technical and that it cannot be managed without an understanding of the technicalities below that threshold. That is absolutely not true and in fact the opposite is true – it is probably less-than-helpful at a Board and committee level  to have that technical understanding of IT.  You do not need to be an IT geek to be on the Board and governing IT operations.  All members of the Board are equally responsible for IT Governance, not just a board member with technical expertise. 

No-one expects a board member to understand how the engines in the fleet of delivery vehicles work – and, news flash, the modern vehicle is fairly complex!  Yet information technology instantly draws shudders of revulsion from some quarters and dark murmuring of witchcraft, magic smoke, and database normalisation (all of which are the blackest of black magic and therefore clearly evil and not to be understood by anyone).  The role of the board member in IT Governance is, in my view at least, to focus on the portfolio of activities, require monitoring and feedback regarding the performance of IT, and to provide direction in the allocation of resources.  Certainly this requires advice from IT professionals – particularly around the area of resource allocation – but good IT Governance does not require that the mechanic be at the board table just because he or she knows how to rebuild an engine.  .

I think the situation that we have has come about because in the past IT professionals have been guilty of portraying IT as some form of dark magic rite, as that was felt to give power and direction over IT.  There is certainly a danger for IT professionals in comjmunicating only half the story behind IT to the board.  I have met with more than a few IT professionals in the past who complain that their IT budget has been slashed because they opened up and tried to explain to the board what was needed.  In most casese, the board listened, heard mutterings of dark magic, and then found a language they could understand – the language of the bottom line.  Which, with great glee, the board slashed – with little regard for what that meant to business outcomes.  The danger here is that IT is seen as a cost rather than a benefit – and the lesson for IT in dealing with the board and those responsible for budget allocations is to focus on the benefits of IT rather than just the costs.

There is a great publication that I was involved with two years ago through CPA Australia called IT Governance:  A Practical Guide for Company Directors, and it is a very accessible and usable publication with great ideas for implementing IT Governance.  It can be purchased here and is something that any company should consider purchasing if they are serious about seeing value from IT. 

I will use this guide as a framework for my future posts around IT Governance.  I will make the note here and now that, as chair of the ITM CoE for CPA Austrralia, there is a publication focussed on the business management of information technology in the pipeline, and a publication of the IT Governance Guide aimed squarely at SME’s.  These will be interesting future publications – probably coming out in the second half of 2007 and first half of 2008 respectively.

Getting IT Right!

by

This is an article that was written for the February issue of the Queensland Business Review.  It is partly promoting an upcoming ‘Getting IT Right!’ seminar to be held at BDO Kendalls on 21 February 2007.  More information is available on the BDO website www.bdo.com.au.

Introduction

Stories of failing information technology (IT) projects, IT teams that just ‘don’t understand’, lost spreadsheets that contain critical business data, and critical applications that seem to crash for no apparent reason are all too common scenarios. Information technology promises a great deal to all businesses, but often fails to live up to expectations.

These problems cause frustration for all concerned. Unfortunately ‘getting IT right’ cannot be achieved with a simple wave of a magic wand. The current skills shortage shows no signs of abating, and it is important for a business to use its staff effectively. Good business support from information technology is one of the keys to unlocking this effectiveness. Four essential business tactics exist that can assist:

  1. Understand the business strategy
  2. Have the right people
  3. Use standard processes
  4. Use the right technology

These tactics will have a positive impact on the success of your business in the context of the support received from information technology.

Understand the business strategy

An understanding of the business strategy, and the involvement of business in IT decisions, is necessary to avoid an IT team working on the unnecessary projects.

This common problem usually stems from a lack of understanding of the goals and vision of the business when it is tempting to implement technologies that seem to be the correct decisions at the time. Sometimes these decisions are right; frequently, they are not.

A business’s main strategy can be focussed upon product innovation, customer relationships, or operating excellence. Identifying the predominant strategy removes trivial distractions for the IT team. There is little point to significant investment in a customer relationship system where the main focus of the business is upon delivering the best products at the best price. Conversely, for a business focussed upon customer relationships, the priority will be to deliver and operate a customer relationship system.

The business strategy must be clearly communicated to the IT team. A written statement of the business IT strategy is useful (vision, mission, and objectives, together with supporting initiatives and milestones. Even more useful is a cultural emphasis on the importance of the role of IT in achieving the
business vision. Such a cultural emphasis can be achieved through concrete actions (e.g. declining projects that do not support the business strategy) and regular adherence to and acknowledgement of the IT strategic plan.

Aligning information technology to the business strategy will reduce distractions that arise through not having a clear direction of the role and purpose of IT in supporting business goals.

Have the right people

A common problem facing IT teams is that the staffing ratio is all wrong. The wrong staff are doing the wrong jobs for the wrong reasons. For example, a business that employs four network administrators and only one help desk person will likely have a network that works very well at a technical level. Unfortunately, there will be many frustrated end users not receiving the desktop support they require. The result can be business chaos.

IT roles that do not directly support the business strategy should be considered for removal or outsourcing. IT teams regularly have ‘legacy’ roles from the past that are no longer needed or appropriate. A regular review of the roles in the IT area and their alignment to business strategy is a potentially valuable approach.

In addition, end users need the training and skills to use the technology that is provided. Frequently no training is received by IT teams, or end users in the software on their computers, and – especially in the case of upgrades – continue to use the software as it has always been used, without using new features. Adopting a formalised and documented approach to training can be beneficial, but even recognition of the need for training through ad hoc opportunities will bring benefits to the business.

Use standard processes

Often IT teams have only one person who can resolve a problem. Or worse, each team member will resolve the problem in their own way. When the staff member leaves, no-one else can fix the piece of equipment. The end result is chaos and delays for the valuable staff member.

If the same task must be done more than once, the potential for developing a standard process exists. No IT team should be without good help desk software, and ensuring a discipline around managing problems and documenting resolutions will pay dividends. There are free help desk management tools available (e.g. open source solutions) and new social networking tools (e.g. ‘wikis’) for documenting and storing processes and procedures that are inexpensive, simple to use, and easily maintained.

Reviewing the use of help desk management software, and writing procedures for standard tasks (starting with the most common tasks) will repay the business handsomely.

Have the right technology

Technology that is simply wrong for the task at hand, or obsolete, costs businesses a great deal. Excel spreadsheets will frequently be used for tasks that really require a database. Or many technologies will be used where a single technology product would suffice. It is crucial that the right technologies are used for the task at hand. This does not mean that the ‘latest and greatest’ gadgets and gizmos should be adopted, but for a business that is reliant upon IT, it is necessary to have all technology covered by parts replacement warranties.

Technologies that are still supported by the original developers or manufacturers are fundamental to ensuring that the IT team is effective. Limiting the number of technologies to support will also help. Approaches to ensure that the right technologies are used include a statement of the preferred technologies to be used (e.g. identifying a single preferred database technology such as Oracle compared to SQL Server), maintaining warranties on all important business technology equipment, and limiting the use of customised and in-house developed software.

Conclusion

Effective information technology requires that the IT team be provided with the skills and equipment necessary to deliver upon the business strategy. Likewise, the business needs to provide strategic direction and input into decision-making for business information technology.

There are many more tactics that can be adopted by businesses to ensure that IT can deliver upon its promises. This article has highlighted those tactics that are common to most businesses and will have the most positive results. Nevertheless, there are many other tactics that can be adopted that are unique to individual businesses, and must be considered in light of the specific circumstances of the business.

Microsoft Access to SQL Server

by

I note this little gem from The Register: Migrating Access to SQL made (almost) easy that
documents the trials and tribulations experienced by the author in implementing the new Microsoft Access to SQL Server tool.

There seem to be some fairly basic and fundamental problems here with the tool – converting queries with dates (Access is chock-full of this) and double-quotes instead of single-quotes (again, Access 101, and a major deviation from the SQL standards).

There is also a fundamental issue – this is converting the data built in these internally-developed databases, but in most cases these databases are kludged together – not surprisingly ignoring the fundamental rules of database design! – such that the tables consist of a single flat table (Database Design Aarghs 101) and all the data rules contained in a multitude of forms that tend to do much the same thing.

I remember when I finally saw the light with Access that converting these developed programs and mature approaches into the programming code was ‘interesting’.  Access was in my opinion both the best thing and the worst thing that happened to database management in the 1990s.  It provided the full power of a relational database on the desktop of those that had never seen it before (good), and many many people used it to manage critical information without any design understanding or consideration of the business implications of their approach (bad).

I guess it’s like a gun – databases don’t create bad database design, people do…

Excel Programming 101

by

I had a quick email query from my brother-in-law at Bremer Ford. He had an Excel spreadsheet that he was having trouble understanding how they’d done it (neither of us could find any VBA code behind it, which confused us no end).

Found a spreadsheet with some arcane formula scratchings, like this:

Modify Data
=DIALOG.BOX(DBMain)
=IF(R[-1]C=FALSE,HALT())
=WORKSPACE(,,TRUE)

The answer is that this is the absolutely ancient way of doing macros in Excel, which is what I suspected. It was introduced in Excel V4, and was replaced by Excel VBA. Excel V4, for the record, was issued in 1992. The modern way to do anything remotely approaching this is VBA applications, although I would never recommend that you put actual source data in Excel – it should be in a database (even MS Access) for robustness and backup purposes, and then you would extract that data to Excel for reporting. The link below has more:

http://j-walk.com/ss/excel/faqs/xl95faq1.htm

And so – problem solvered. I suppose, though, it’s testament to backward compatibility that a 14-year-old macro still works in our version of Excel. I guess, if it ain’t broke, don’t fix it.