Many computer users kicking off a new project will have faced the decision of whether to buy in a package that might only do 60% or 70% of what they want, or develop something bespoke that matches their needs precisely.
In a white paper published last month (see box), Ovum notes that applications developed in the 1980s and early 1990s were inflexible. This resulted in organisations having to modify the application's source code to fit their specific requirements. Looking at one area of the packaged applications market - corporate financial systems - Ovum feels modern systems have been designed to meet most companies' financial requirements. It says such packages have facilities which allow organisations to customise an application's menus, screens and reports. Some, the report says, even allow users to modify processes - a function often provided by workflow.
But, the white paper warns, flexibility has a price tag. In order to configure these systems, specialists and costly expertise is often required.
Ovum believes this has led to a considerable increase in implementation timescales. Furthermore, it notes that developers with a regular upgrade policy often insist that existing hardware is also upgraded, which can be very costly.
Cost is certainly an issue. But alone it is not the deciding factor on whether a firm buys or builds. According to Ian Meakin, product marketing manager at Compuware, which manufactures the Uniface development tools, the question to ask is, simply, "Does the software give you a competitive edge?" He adds: "If it's just automating functions such as accounting, buy an application. If it's going to do something unique, build it yourself."
In fact, there are also a whole range of shades between the two extreme options. What it comes down to is how much the function relates specifically to your business. If it is common, like finance and accounting, or even OLAP, you buy it in. If it relates to your industry you may be able to buy a package that can be customised for a better fit. But if the function is part of your unique business proposition, such as a customer asset management system, build it yourself. Consider this: you wouldn't want a competitor getting a copy of the same packaged software you purchased in order to solve a problem unique to your business, would you?
Now, thanks to a programming revolution variously called business objects, modules or components, these three propositions are no longer mutually exclusive. Combined with older technologies that are only now gaining widespread respectability, like rapid application development (RAD), businesses are gaining the ability to build and buy, mixing and matching technology to best suit their needs.
"Component-based development means buying standard functionality and plugging it into the bigger framework that's unique to your organisation," says Meakin. "The theoretical idea has been around for a long time, but it's never really come to fruition. This year will be the year of the component builders."
An organisation needs to respond quickly to changes in the business environment, and it is simpler to change component-based systems than it is to get involved with function calls and low-level programming. Components can be fitted together like building blocks to make up a larger application. These can then be reused in other applications, using object standards such as CORBA (Common Object Request Broker Architecture) or OLE.
This is object-based technology, not object-oriented programming, which entails a lot more work. "The time taken to do real object-orientation is seldom worth the buck," asserts Chris Howegego, director of the Powersoft division of Sybase. In his view, what is important is compatibility with object standards and the Internet, a drag and drop GUI front-end, and a client-server operation.
"Applications are rarely cost-effective for more than 24 months," he says, "because by then someone has invented a new GUI, or the business has changed." Howegego points out that the modular approach avoids this problem because new modules can be added and the database redesigned to cope.
Even the vendors of bread-and-butter applications, such as accounts systems, are adopting this approach. "The language you write in is just not relevant anymore. Just that you make use of reusable components and take advantage of industry-standard interfaces," commented Jim Stone, product marketing director at Systems Union, the company responsible for the SunSystems financial software.
SunSystems is just one of many packages that are actually suites of modules, each addressing a different aspect of the business process. Such modules can be used as-is or customised, and they can be used on their own or in combination with other modules and bespoke applications.
Stone's view is that for the core functions that don't directly contribute to a business's competitive edge, buying off-the-shelf modules for standard functionality is the best route. "Technology is the best reason not to write it yourself," he explains. "Large companies make their living getting it right for the customer. Do you want to be part of a user-base of one or 13,000, in terms of keeping the application going? It takes us years to develop an accounting application and keep it up-to-date. What will you do about the Year 2000 problem, for example?"
Testing is another issue. Users might think that only bespoke applications will need extensive - and expensive - testing and validation. However, each business is unique, so alterations or customisation have almost always been needed, bringing problems of their own.
"For example, people used to buy an accounts package, a payroll system and an inventory system, and the IT department would write interfaces between them," comments David Harrison, managing director of software testing tool supplier Mercury Interactive. "Then they upgraded one system and the interface stopped working."
This problem doesn't go away just because the packages all come from one supplier. Packaged applications are not a single piece of software, like a desktop word processor, but complex client-server systems. Even with a broad-based application like SAP's R/3 - or perhaps, especially with a broad-based application like R/3, every installation is slightly different. The situation is further complicated by the fact that the application software has to run on the existing hardware set-up, which will vary considerably.
"Realistically, no-one uses SAP out of the box," says Harrison. "When you have a package and customise it, it becomes unique, so you've still got to test it to make sure it works.
"With the advent of RAD tools such as Powersoft's PowerBuilder," he adds, "the developer can change the look and feel of an application overnight.
Development has become trivial but testing has become more complex."
The use of rapid application development (RAD) is an important part of the move towards frameworks and business objects. If modular software techniques are to make the organisation more flexible and reactive to changes in the business environment, they need to develop the customised modules that make its total system uniquely competitive as quickly as possible. The bespoke modules can then be plugged in alongside bought-in modules supplying standard functionality.
Yet until relatively recently, RAD did not have a particularly good name, as Barry Zigner, technical director at RAD tool supplier Magic Software, freely admits. "In the US, RAD became synonymous with quick and dirty," he says. "The reason was that most tools were aiming for the low end, and the result was that a lot of applications were inefficient."
Although some midrange computer users adopted similar tools, such as fourth-generation languages (4GLs) back in the 1980s, when the PC revolution came along, the practice did not really spread to the PC market. As with RAD tools, 4GLs acted as intermediary layers, relieving developers of the need to deal with raw program code and focusing more on the structures and processes that the application required.
"Most of the market is very traditional, especially in the UK, and RAD was too extreme for what people were used to," says Zigner. "Only now are organisations looking at adopting new tools because the nature of business is changing, with companies being forced to provide more products and a faster time to market." He added that in the early days, RAD was too wild and unstructured, but has now matured into a more ordered form.
Compuware's Meakin agrees, pointing out that it is crucial that RAD be allied with a strong business modelling approach. "The Visual Basic developer chucking screens together quickly is not what we're after," he says. "We're talking about RAD in terms of iterative prototyping, a more formal approach."
This means you need a methodology for RAD, or some kind of formal approach to designing systems that will be built using RAD tools. The one that many are promoting is DSDM, or Dynamic System Development Methodology.
This is the first formalised RAD approach, and was put together by a UK consortium including the Butler Group and British Airways. Meakin feels DSDM is a "quality" method that includes the good practices of RAD and the business process model approach. "It's better for systems that might have to be changed quickly."
Business process modelling means analysing the business and how it works to see what processes are involved. These processes can then be further analysed and so on, until you reach the level at which you can define a module or business object. This is the reusable chunk of code that is slotted together with others to perform the business process in question.
How easily that can be done is another matter. "The current IT infrastructure is not equipped to define and automate the complexity of business rules," comments Peter Preston of USoft UK. Traditionally, business rules have only been defined in various analytical and design documents. These are then buried deep in procedural code making them difficult to access and the systems difficult to adapt, he addsx.
Different RAD tool suppliers have different solutions to this problem. For example, USoft's is to use iterative RAD and object methodologies, while Zigner says that Magic is designed for system analysis, and concentrates on the business logic.
As businesses struggle to keep their systems up-to-date, the use of object-based modular techniques can only grow. But it has to do so in tandem with business analysis to define the roles of those modules. Future RAD tools can only generate OCX, ActiveX or CORBA objects if the logic has already been created for them to work with.
OVUM: A GUIDE TO CORPORATE FINANCIAL SYSTEMS
- CA-Masterpiece is the most portable solution evaluated, but its traditional modular flat-file structure spoils its client-server option.
- CODA-Financials uses a standard three-tier client server architecture.
It is a portable multi-platform solution using industry standard methods of communication.
- Geac SmartStream utilises a heavy client in a co-operative client server architecture. It is constrained by the Powersoft-Sybase environment, although a Microsoft SQL Server version is planned.
- IBS-ASW is a traditional host-based AS/400 solution. New client server modules have been developed outside the main application.
- JBA System 21 has reviewed its planned client server offering. System 21 is a host-based or Unix suite of applications with an intelligent screen scrapper, thin client or dumb terminal front-end.
- JD Edwards OneWorld architecture offers the most flexible solution available. It is still in the early stages of implementation and should soon be fully referenceable.
- Lawson Insight has developed a multi-layered architecture with the application code generated by its own multi-platform application development tool, Universe. This generates RPG for AS/400 and Cobol for Unix and NT.
- Oracle Financials release 10.7SC supports dumb terminals as well as PC-based Windows and Web browser interfaces. It offers, SmartClient, a heavy partitioned client which has scalability problems in a co-operative client server configuration.
- PeopleSoft Financials advanced client server architecture has been its mainstay but it needs to address the tin client requirements of the Web.
- SAP /R3 uses a traditional first generation client server architecture but it has proved very reliable. It is ideal for the emerging NC market.
CASE STUDY 1: THE PASSPORT AGENCY
When the government created the Passport Agency in 1991, the new organisation was faced with implementing commercial accounting procedures within two years.
To achieve this, the agency turned to a modular packaged application, SunSystems from Systems Union.
"A number of other government agencies had already started using SunSystems, and we determined it had everything we needed and commissioned it on that basis," says Alistair Cook, the agency's deputy head of finance. He added that the modular approach meant the agency could start with purchase order processing and the general ledger, and add separate impressed and fee accounts ledgers at a later stage.
It also allowed the accounts system to be distributed, with two PCs at each regional office, one running a general ledger and the other running the impressed and fee accounts. These then transfer their data to headquarters overnight, though some bespoke work was needed to interface them to the secure Government Data Network. "It was easy to put an off-the-shelf package in each office, and having two PCs allowed people to work in tandem on different ledgers," Cook noted.
"The resource accounting requirement in government agencies means reasonably standard accounting rules and policies, so I think there's a lot out there that can be bought off the shelf," says Cook. "It's cheaper, simpler and easier to update that way. Even a bespoke application only matches your needs at one point in time. A modular approach allows add-ons and changes over time."
CASE STUDY 2: SOUTH STAFFORDSHIRE WATER
At South Staffordshire Water, different systems have been implemented in three different ways. For its accounts, the company uses Oracle Financials; for works management it added elements to an off-the-shelf package; and when it came to customer services, a bespoke approach was needed.
"For works management, we involved people in the user areas and found nothing suitable on the market. But we could use the core structure of a package and focus on adding modules," explained computer manager Frank Hall. "With customer services, I reckon we've done it cheaper than buying in. Customer service systems for the utility industry are very expensive, because there's not many utilities to buy them and they are big systems."
He is sceptical of the fit offered by many packaged applications because, he says, they focus too much on functions and too little on business processes.
"A process is a sequence of functions, and is very much left to the user to sort out," he adds.
South Staffordshire Water has spent 18 months using the Progress database and tools to develop a three-tier client-server customer services system.
The database runs on a central Unix server from Sequent, while the process logic runs on PCs linked in via Novell Netware and Compaq network servers. The system is vital because in such a strictly-regulated industry, South Staffordshire Water needs to offer good value for money compared to other water companies.
"The key is whatever you do, you've got to be clear about why you're doing it for the business, so the people using the system have to be involved," Hall says. "We like user representatives to lead projects, if possible - the project champion is a good way to success."
AMD's Zen chip roll-out continues with the focus on high-power embedded applications
And becomes the team's executive chairman to boot
'Whatever the causes of political polarisation today, it is not social media or the internet,' claims Dr Grant Blank
Tesla founder leaves OpenAI group - while Valve Software's Gabe Newell joins