Microsoft, often maligned for adhering to a strict ‘Windows everywhere' ethos, is taking a slightly different approach to the agile business. The company, says Gordon Smillie, director of Microsoft UK's enterprise group, is embracing open standards and adopting the mantra "any time, any place, any device".
"I talk to a lot of CIOs," he says, "and they say, ‘A couple of years ago, it was great. We could deliver a Microsoft system to everybody [within our organisation]'." But now, says Smillie, they are under pressure: they must provide corporate data to employees out on the road or in remote offices, as well as integrate their systems with those of other companies, "be they customers or suppliers".
Microsoft's .Net platform is the embodiment of the company's web services strategy. Clients devices can come in any variety, be they PCs running Windows or mobile devices such as Pocket PCs. These clients then access either Windows 2000 servers with .Net libraries installed on them, or one of Microsoft's forthcoming .Net servers.
The power of .Net lies in both its adherence to web services standards and the rapid development times the .Net libraries offer programmers, says Mark Greatorex, director of the .Net developer group at Microsoft UK. Using Visual Studio .Net, the company's collection of web services-enabled development tools, a programmer need only add a few lines of code to a program to let it take advantage of the .Net libraries.
Once deployed on a .Net-enabled server, the program can then offer its capabilities over the Internet as a web service.
The much-touted interoperability of .Net, however, is limited by Microsoft's usual "embrace and extend" approach – that is, the company adopts a standard, and then builds upon it using proprietary technology. The .Net libraries, for example, are only available for Windows servers. So if programmers write a .Net application, they are only able to deploy it on a Windows server and are not easily able to port that application to a non-Windows-based system.
By contrast, most other web-services systems only require a server that can run infrastructure software compliant with the J2EE (Java 2 Enterprise Edition) standard. While Java is not a truly open standard, its development process is relatively open and its inventor, Sun Microsystems, does not have sole control over Java specifications, unlike Microsoft and .Net.
Microsoft is, however, partnering with open source software specialist Covalent to produce a module for the Apache web server – the most popular on the Internet – to enable it to support .Net applications. Moreover, a group called the Mono project is developing an open source version of .Net that will run on the Linux open source operating system. So the issue of lock-in could disappear relatively quickly.
That still leaves one burning issue: if .Net becomes a de facto standard for web services, the control over the standard afforded to Microsoft could be as great as the control it exerts over the desktop through Windows.
Greatorex, however, argues that .Net is the most open environment in terms of application support, and he argues that the ‘write once, run anywhere' claim made of Java by its proponents is a fallacy. "Most J2EE applications have to be re-written for different environments. It's more like ‘write once, run once'," he says. He also points out that J2EE applications have to be written in Java but that, by contrast, "Visual Studio .Net lets you write web-services applications in 22 different languages, including Java. You can even mix and match languages in the same application. Our approach is more open."
One of those 22 languages is Microsoft's C#, a composite of C, C++ and Java optimised for web services and .Net. Greatorex says that development with C# is much faster than with Java. "We implemented Sun's own J2EE best practices blueprint application, the Java Pet Store, using C# and .Net. The exact same application functionality took just a quarter of the code using C# and it performs over 10 times faster," claims Greatorex.
The .Net platform offers much to enterprises looking to become an agile business: rapid development time via Visual Studio .Net using whatever language the enterprise's development team prefers; an authentication system for secure use of web services; and an easy way to integrate applications together so they can exchange data in an open way. But organisations will have to trust Microsoft to fulfil its promises – and many developers do not want to go down the same road they trod with Windows.
XML is the only way forward for an agile business, according to Lothar Lasinski, vice president of corporate marketing at Software AG. "What does every enterprise revolve around? Documents. There are sales proposals, contracts, project plans, bids, web pages, price lists, receipts, product manuals, parts lists."
If a company is to be truly real-time, it needs to be able to move documents around the organisation – and process the data they contain – seamlessly. Software AG's native eXtended Mark-up Language (XML) database, Tamino, says Lasinski, offers all would-be agile businesses these capabilities.
"Electronic business is about dealing with documents electronically. Systems need to be able to send and receive documents automatically, triggering business processes as necessary, with only the exceptions being dealt with by people," he says. "Unless the enterprise can automate its document-handling, it will never have real-time capabilities." The important thing about XML is that it allows documents to be self-describing, convertible, easy to understand, machine readable and, using digital signatures, hard to forge.
By storing documents as XML, says Lasinski, an enterprise can attach meaning to plain text and allow machines to ‘understand' it. For example, invoices marked as overdue payments might trigger a process that notifies the accounts department to authorise payment as soon as possible.
And if two partner companies each know how the other marks up data, the two can exchange documents and activate business processes without any need for human intervention.
Many relational database systems are now XML-enabled and claim to be able to handle XML data as easily as normal text, but Lasinski says they offer few of the capabilities of a truly native XML database. "There are high development costs because of the extra time needed to map XML fields to [relational database] table columns; reduced performance as XML is converted to a relational format and back; data integrity is jeopardised as the document is broken up for storage; and maintenance is difficult because of file size and the problems of accommodating changes to data structure," he says.
A native XML database such as Tamino, says Lasinski, enables high-speed searches of XML documents; maintains document integrity (and therefore audit trails); and can be a single-source for data publishing – XML separates content from presentation so that the same text can be displayed radically differently in different media with no change to the document.
Furthermore, style sheets provide information on how to display the same kind of text (such as a title or a subheading) in a presentation, letter, web site or internal application for instance, without anyone needing to amend the document.
For Lasinski, the evidence that Software AG has the superior approach to XML data storage comes from a test comparing the time it took to set up an XML document schema in Microsoft's SQL Server relational database system, compared to setting up the same schema in Tamino. "It took an hour to set up Tamino. It took a week to set up SQL Server," he says. But scepticism abounds – will the XML database prove to be the same technological dead-end as the object-oriented database system, which promised similar capabilities, or does the technology have a truly promising future?
Enterprise resource planning (ERP) market leader SAP does not want to be left out in the cold. One of the selling points of ERP systems is their tight internal integration of accounting, supply chain management, human resources, customer relationship management and other vital business processes. But how does a company then integrate its ERP system with the diverse range of systems residing in its remote offices or at partners' sites?
The imperative for SAP is clear: its customers need a way to integrate their mySAP.com systems with other enterprise applications as tightly as mySAP.com is knitted together. "We understand our customers' integration needs are more than having application A interface with and pass data to application B. Their needs incorporate their entire infrastructure," explains Pascal Brosset, vice president of innovation and strategy at SAP. "SAP has had to get rid of anything proprietary in its architecture and start to expose all of its major interfaces to the web."
The company's tentative steps towards easier integration started with mySAP.com, its portal system for providing a single window onto all the back-end systems.
But for the truly agile business, says Brosset, integration needs to take account of front-end applications. "It's not about back-office efficiency. It's not about planning. It's about adapting – planning less and executing more." And that, he says, is where web services come in.
The company's first step towards web services was to put Java on a par with its ABAP (Advanced Business Application Programming) language, so that developers can access all the SAP applications using a standard language. Future upgrades to the SAP Web Application Server will provide web service interfaces to mySAP.com application components. A web services-enabled version of mySAP.com will then be able to access not only SAP's own application components but those residing in partners' systems, giving a central, real-time view of the enterprise's supply chain and other business processes.
But even with web services threatening to undermine ERP's unique selling point, Brosset insists: "You will still need the good old workhorse that will enable you to gain greater and greater efficiencies, faster and faster return on investment." By presenting mySAP.com to customers as the backbone of the real-time supply chain and a hub to all other systems, SAP hopes the integrated applications suite is here to stay.
Tom Ilube, CEO of Lost Wax, says the shift to the agile business will require not just a shift in technology, but a shift in the way applications are developed.
"Traditional IT is like neoclassical painting. These paintings were one-off masterpieces, planned in minute detail, and painted in laboratory conditions. Lots of people were needed to produce them, they were often paid for upfront by a wealthy patron, they took a long time to do, and they all look the same."
Similarly, traditional IT development tries to create ‘perfect' solutions, meticulously planned, mostly paid for in advance, and developed "away from users behind shut doors".
But, he says, "We don't have the luxury of time any more". With budgets cut and development times dropping, new techniques are needed. "Agile IT development is like impressionist art. It tackles real life, not fantasy. It's often painted outdoors – close to the subject. It's less expensive to produce, often reuses the best bits. And the effect matters, not the details."
Rather than trying to develop the "perfect" application, agile developers work closely with users to capture as much of the essence of their business processes as possible, developing applications on-the-fly to create software that may not be 100% right, but is close enough to produce the right results. It can then be modified over time to produce better and better results and to take account of changes in practice and technology. "Part of building the solution helps you understand the problem," Ilube argues.
Ilube first encountered agile development when he became programme manager for the initial launch of Egg, the online bank and credit card. "We couldn't possibly have known what the requirements were. We were doing stuff that hadn't been done before, and we didn't know how the market was going to react to it. The only thing we could do to build our systems was ask, ‘What is it we're trying to do? What is it we're about?' It was the first place I've worked where the IT community would have discussions about the essence of the brand."
Ilube says that Lost Wax's agent technology supports agile development, in that agent technology creates smart, adaptable applications that are particularly suited to complex, changing environments. Lost Wax, for example, counts the Baltic Exchange, an online shipping and cargo market centred in London, as one of its customers. In the future, a participant company in the Baltic Exchange could invoke the software agents of Lost Wax's e-Commerce Platform to carry out autonomous contract negotiations concerning price or volume with cargo suppliers, says Ilube.
The key to agile development, he says, is the underlying mindset. "When you hire an IT organisation, you don't ask yourselfif they fit in with your brand. But in an organisation embracing agile development, you need to ask those questions. You need to have the IT community absorbing the brand, understanding the difference between a Virgin Atlantic system versus a British Airways system, for instance."
Agile development is not always appropriate, but is best suited to complex environments that are constantly changing. "The biggest risk sometimes is having the perfect solution – that then stays the same for the next 50 years. And that means your business stays the same too."