Building a Successful IS Architecture

Step One: Keep it Simple

We have managed to consolidate our information systems onto three main platforms: our document management system, the ERP used to support our core back-office processes, and the database supporting our bespoke front-office systems. All run on Oracle databases. Three main systems (with a few minor exceptions) is not bad for an organisation of 800+.

This degree of consolidation has several huge advantages:

• Fewer user interfaces for the organisation to learn;
• Fewer interfaces required;
• Fewer systems to support means less support staff;
• Fewer systems to learn means we can get a deeper understanding of each.

The main downside is that by not adopting "best of breed" solutions the organisation may be missing out on the most innovative products, or those that may have a better business fit.

I believe that the deeper understanding that we have of our core systems allows us to address both these areas by supplementing the standard product with a few small, simple tools. So far this approach has been very successful and well received. People like it that they can continue to use the systems they know yet can do the other things using a tool that works in the same way as all our other in-house applications.

Step Two: Keep it Simple

Almost all our bespoke applications share a single database schema (the main exception being our GIS applications). We are one organisation after all, and it is important that we have, to use the Oracle phrase, a "single source of truth". We work hard to stick to the "store once, use many times" principle by carefully working out where in the organisation ownership for information truly rests. We can then make sure that we don't build duplicate data stores for this information that would allow other versions of the information to be created.

We extend this to our ERP and document management system through the use of database links and APIs (our developers only have one database schema and two sets of APIs to learn).

Step Three: Keep it Simple

In the past it was acceptable to build applications that people needed to be trained to use. Now everyone is able to order their groceries, book a holiday and manage their finances online. All without the aid of a single training course or manual. Of course there are phone lines available as well for support and eventualities when the online system can't handle a complex request, but by keeping them simple the designers of these systems have made them accessible to all.

I believe we should be doing the same with our business systems.

To achieve this, we firstly try to ensure that the business processes are simplified as far as possible. By this I mean that we reduce things to their core essentials, and not get caught up in debates about what could happen in scenarios that may never occur. For example, a number of processes are started when a customer contacts us and we record some information about the customer and what they need. Every time we need to record customer details we will use the same interface. That way the organisation gets familiar with the interface, and we only have one to support. We can spend more time on it and make it better and easier to use. Oh, and all the customer information ends up in the same tables.

We also work hard to ensure that whatever development tool we use (Application Express, Oracle Portal or JDeveloper) the user interface is as similar as we can make it. This means that everyone gets quickly familiar with the interface and when faced with a new system they immediately feel at home and know where things should be.