Zeev
Some weekend material. I encourage you to read it.
Building blocks for the future
By Simon London
Published: January 26 2005 07:49 / Last updated: January 26 2005 07:49
"This is the industrial revolution for software," says Toby Redshaw, vice-president of information technology strategy at Motorola, the US electronics group. He is talking about the rise of "service oriented architectures" (SOAs) a method of building IT systems that relies not on big, integrated programs but on small, modular components.
The analogy is a good one. Industrialisation led to huge productivity gains but also impoverished craftsmen whose skills were no longer valued. The emergence of service-oriented software will also cut both ways: cheaper, more flexible computer systems combined with a painful adjustment for artisan-programmers who get left behind.
Moreover, Luddite-style resistance is futile.
"SOAs are going to happen. You can't say: ‘We won't do that.' It is inevitable," says Daryl Plummer, a research fellow with Gartner, the market research and consulting group.
The forces driving change can be seen in every IT department: systems that are rigid, inflexible and costly to change, chief information officers under pressure to do more with less.
The City of Chicago spent five years updating its IT systems. It bought an enterprise resource planning system, a revenue management system, a customer relationship management system and a host of other software packages designed to speed the work of city government.
Everything worked well until city managers started asking for information that required dialogue between two or more systems. Building links between systems required weeks of work by $200-an-hour programmers. The average cost of linking two systems was $100,000.
To Chris O'Brien, a former management consultant who is now the city's chief information officer, this seemed hopelessly inefficient: "What's the point of having all that data if you can't bring it together in a way that the average manager can use?" he says.
The story is typical. Most organisations run on a hodge-podge of departmental systems accumulated over many years. Building bridges between these "islands of automation" is slow and expensive.
Increasingly, this is a headache for CEOs as well as CIOs. In a recent poll by The Conference Board, the business research group, nearly 90 per cent of business leaders said their top priority was increasing organisational speed, flexibility, and adaptability. But how can they achieve this when IT systems are set in concrete?
In Chicago, Mr O'Brien and his team have taken their first tentative steps towards a more flexible world by creating a dozen or so modular services. Each has standard interfaces and can be used by any of the city's systems.
For example, the city's website includes a facility for paying parking tickets online, supported by software that checks the amount you owe, charges your credit card and routes the money to the appropriate municipal bank account. Realising that this could be used by other city departments, the CIO asked his team to turn it into a service.
The programmers first had to decide how much of the software could be reused in different contexts and how much was specific to its existing function.
Once this was accomplished, the reusable part was wrapped in a layer of Extensible Mark-up Language (XML), an industry-standard system of tags and labels that can be understood by any computer system.
The result is a service that can be used by any of the city's computer systems. Instead of writing near-identical software every time they need a payments engine, developers can simply plug into the service over the city's computer network. "It took us two weeks to build and it has been reused at least seven times," says Mr O'Brien.
Motorola is further ahead. It has developed 108 services so far and envisages a day when the company's entire IT infrastructure is based on thousands of similar modules interacting over the network.
Changing the system to accommodate new business processes will then become a drag-and-drop exercise requiring no programming skills. Mr Redshaw envisages a day when tasks that now require weeks of software development can be carried out in a few hours by a new breed of "business process analysts".
As every historian knows, however, revolutions rarely run as planned. There is a huge difference between building a few modular services and moving to a full service-oriented architecture.
"As every historian knows, revolutions rarely run as planned and there are plenty of technical hurdles to be overcome"
First, there are technical hurdles to be overcome, such as deciding what constitutes a service. Include too little functionality and a service is unlikely to be useful. Include too much and it may be unusable outside the context for which it was originally written.
Bear in mind that the software industry has tried modularity before. Object-oriented programming - all the rage in the 1990s thanks to the rise of languages such as C++ and Java - is based on similar ideals: flexibility, ease of maintenance, reuse of code.
But the "objects" in an object-oriented software program were too obscure to be understood by non-programmers. Software remained the province of specialists. In contrast, the "services" in a service-oriented architecture should be recognisable even to the uninitiated.
service should be something that a user can understand, such as a query or "A a transaction," says Steve Bass, CIO at the New York Board of Trade, the commodities exchange that is also moving towards an SOA.
Mr Plummer at Gartner makes the distinction between "atomic services" that do one thing ("check temperature" or "check credit authorisation") and "composite services" that involve a number of steps. The City of Chicago's payments engine falls into this latter category.
He adds: "Moving to an SOA is not just a technology initiative, it is a business initiative. What services do you need to run your processes? Where are you going to get them from? What happens if a service goes down? How long would it take you to recover?"
These are questions that the average application developer is hardly qualified to answer. Developing an SOA will therefore require close co-operation between IT departments and business units, often a tricky proposition.
In addition, while XML in theory provides a lingua franca that any computer system can understand, communication is impossible without shared meaning. This means agreeing on standard definitions throughout the company.
When a service is asked to look up the "list price" of an item does it need net of tax or gross? Inclusive or exclusive of shipping? Good until what date? There are no short cuts, warns Mr Redshaw: "We recruited a world-class data architect to drive all of this but, even so, with hindsight I wish we had started a lot earlier."
Even when these gritty details have been worked through, a fully-developed SOA will require rules and, therefore, more software governing access rights to services, security, quality of service and more besides.
It is this architecture that differentiates an SOA from a mere collection of modular services.
The software industry has been quick to sense an opportunity. Big software companies such as BEA Systems, IBM, Oracle and Microsoft jumped on the bandwagon last year. They have been joined by a host of start-ups offering products to help manage SOAs.
Examples include Systinet, which offers a central registry to keep track of the services available; Amber Point, which monitors service levels; and Infravio, which among other things offers load-balancing, services management and security tools.
Companies serious about moving to an SOA will need these or similar products. CIOs will have to explain to their bosses why, in these penny-pinching times, another handful of software vendors should be added to their roster.
Says Mr Plummer, wryly: "I said this was going to be more efficient. I didn't say it was going to be simpler."
This is a fair point. Developed economies have become massively more productive since the dawn of the industrialisation, but they have also become more complex. Software may now be facing the same transition as big, integrated applications are broken into smaller, more flexible modules.
Yet the biggest pitfalls on the road to a service-oriented world could be behavioural rather than technical. Turning existing applications into modular services requires programmers to change habits formed over years of education and practice.
"When you build an application you look at it in isolation. When you build a service you have to look at who will use it and how they will use it. It requires new skills and a new mindset," says Tom Erickson, Systinet's CEO.
The emergence of SOAs will also shift the balance of power between IT departments and business units. When new applications can be built easily by business process specialists, what is the role of the programmer, the systems architect or even the CIO? Notes Mr Redshaw: "We are trying to get people to embrace things that could make their jobs go away."
WHAT IT ALL MEANS: ACRONYMS AND KEY TERMS UNTANGLED
Loose coupling: The friction-free linking enabled by web services (or any SOA). Loosely coupled services, even if they use incompatible system technologies, can be joined together on demand to create composite services, or disassembled just as easily into their functional components.
Service-oriented architecture: a system for linking resources on demand. In an SOA, resources are made available to other participants in the network as independent services that are accessed in a standardised way. This provides for more flexible loose coupling of resources than in traditional systems architectures.
Web services: automated resources accessed via the internet. Standards-based web services use XML (Extensible Mark-up language) to interact with each other, which allows them to link up on demand using loose coupling.
Source: www.looselycoupled.com, an online resource founded by Phil Wainewright for early adopters of SOAs.
BAT steps up to new platform
By William Knight
A company's geographical dispersal can cause problems for IT, but British American Tobacco (BAT) is implementing a service oriented architecture (SOA) to gain a consistent platform for its global systems, without constraining local regions which retain significant autonomy.
With more than 300 brands, BAT covers 180 markets with 87 factories in 66 countries, and building IT infrastructure is an ongoing task. Kevin Poulter, application technology manager with worldwide responsibility for application infrastructure and technology components, says BAT was disillusioned with "traditional" methods.
"Momentum in our organisation has come from people finding integration expensive and difficult," he says. "The approaches we were using were too expensive and too slow."
BAT's SOA project began nearly three years ago and has progressed incrementally by consultation and by winning the hearts and minds of technicians and management.
SOA can be a daunting concept and Mr Poulter says gradual introduction served to keep personnel on side and ensured the business units were fully engaged.
Even for technical staff, an SOA might represent a considerable shift in philosophy, and he stresses the need to take matters slowly. "There is an interesting tension because you have people used to traditional packaged applications. The hurdles have been getting the right level of understanding about what it [SOA] means."
The project accelerated as benefits emerged. "We are trying to do it incrementally; put in place the right infrastructure components to let us manage and control it, and still deliver results from an incremental investment," says Mr Poulter. Infrastructure components deployed include Blue Titan Software for registering and managing services and Cast Iron Systems' Cast Iron Application Router as an integration tool for creating services.
The company has just reached the stage of implementing services - using Skyway Software's development environment - and this serves to illustrate that, when implementing an SOA, results do not necessarily come quickly. While admitting they have more work to do before they have a "full blown" SOA, Mr Poulter says the Australian and South African business units have delivered integration solutions more efficiently and with lower development costs than previously.
BAT is encouraged to move forward with the project, "A full SOA is a natural consequence," says Mr Poulter. Such is the strength of the SOA model that BAT's original architectural vision has remained intact. "A few things evolved, but we haven't changed much in three years," he says.
BAT's determination to implement a consistent infrastructure upfront has created an excellent platform for the future, and the company can now apply SOA to business solutions on a broader basis. "We are working with SAP [the big German enterprise software company] very closely on this and have a strategic relationship in place to work on a common SOA vision," says Mr Poulter.
He aims to create a growing registry of software services that the business units can utilise and build on. "Demand will come from local and global projects and their business requirements, not the central strategy team," he says.
Mr Poulter believes SOA is an inevitable technology that all companies will eventually embrace. He sees BAT's move to SOA as the first steps to an "infrastructure of the future," providing stronger integration between system level, application layers and business processes.
Market Data 
Markets 
AI
