White PapersThe alignment between IT departments and the business goals of their parent organisations (or lack of it) is likely to be one of the key issues facing organisations today. There is a growing consensus that, whilst delivering projects against requirements, on schedule and within budget is challenging enough; IT still needs to aim higher.
Traditionally, many IT departments avoid the politically risky area of demand management, and concentrate on supplying and operating whatever software the business demands. They are content to be passive order-takers, without worrying whether the applications they create will further the organisation's goals. If requirements are wrong, or if projects are assigned inappropriate priority levels, that is too bad - but it is someone else's concern. Like a team of builders calmly handing over a three-storey house with no staircase, due to an architect's oversight, IT merely delivers what it is asked for.
If companies wish to optimise both the agility with which business-critical applications are built, and the cost-effectiveness of their IT infrastructures, they will have to explore new organisational approaches. Above all, they must find ways of breaking down the communications barrier between business and IT, so that they can work smoothly together to choose the right applications as well as implementing them in the right way.
Demand and Supply in ITBy Tom Welsh, Senior Consultant, Cutter ConsortiumCommissioned by CompuwareReview of the McKinsey & Gentle ModelsWHITEPAPERUntitled Document1Contents 1.Executive Summary2.Mckinsey s Model3.Real World Examples4.Considerations for Putting Supply and Demand into Practice5.The Problem of Investment and Return6.The Problem of Requirements7.Gentle s Model8.Conclusion: A Step in the Right Direction9.About the Author9.About the Cutter ConsortiumExecutive Summary The alignment between IT departments and the business goalsof their parent organisations (or lack of it) is likely to be one ofthe key issues facing organisations today. There is a growingconsensus that, whilst delivering projects against requirements,on schedule and within budget is challenging enough; IT stillneeds to aim higher.Traditionally, many IT departments avoid the politically risky areaof demand management, and concentrate on supplying andoperating whatever software the business demands. They arecontent to be passive order-takers, without worrying whetherthe applications they create will further the organisation's goals.If requirements are wrong, or if projects are assignedinappropriate priority levels, that is too bad - but it is someoneelse's concern. Like a team of builders calmly handing over athree-storey house with no staircase, due to an architect'soversight, IT merely delivers what it is asked for.If companies wish to optimise both the agility with whichbusiness-critical applications are built, and the cost-effectivenessof their IT infrastructures, they will have to explore neworganisational approaches. Above all, they must find ways ofbreaking down the communications barrier between businessand IT, so that they can work smoothly together to choose theright applications as well as implementing them in the right way. Compelled to achieve closeralignment with company needs andbusiness demands, IT has onceagain entered a time oftransformation. Where once IT solelyhelped support the business, now itmust help define the business. - Reinventing IT: From Supporting Player toStrategic Partner, Ellen Fanning,Computerworld, February 19, 2007.Untitled DocumentMcKinsey's ModelA recent paper by David Mark and Diogo P. Rau of McKinsey &Company proposes a structural solution. It is entitled Splittingdemand from supply in IT 1. The authors sum up their thesis as follows: Companies can get more productivity from their IT investmentsby setting up demand organizations that coordinatedevelopment requests between business and IT suppliers . They argue that companies are trying to get better value fortheir IT investments, largely by centralising infrastructure servicesand - increasingly - application development and businessprocess management. These resources are intrinsically shared,and the problem is to get the most responsiveness and valuefrom them.Mark and Rau suggest splitting the IT department into twocomplementary parts. For consistency's sake, we shall call thesethe demand group and the supply organization. (The former iscalled a group because it is much smaller than the supplyorganization)." The supply organization comprises virtually all of the conventional IT department. Its job is to design, build,test, deploy, and perhaps operate applications, as well asdeciding on architectures. The requirements and funding fornew applications come from outside - they are someone else'sconcern. The supply organization may be a single centralgroup, or it may be split across several business groups toserve each of them more responsively." The demand group is the real innovation. Rau compares itsmembers to financial controllers who are embedded withinbusiness units, but report solid line to the CFO with a dotted line to the business unit manager. Similarly, thedemand group provides each business unit with one or morepeople who report solid line to the CIO, and dotted line to theunit. Thus, although they work within the business unit andbecome thoroughly familiar with its people and processes,their first loyalty is always to IT. This keeps them impartial, andprotects them from being unduly influenced by business unitmanagement. The demand group are the business units' personal shoppers - finding out exactly what their clientsneed (not just what they want), and then making sure theyget products of sufficient quality at the best possible price.In McKinsey's model, demand groups have at least threeimportant roles to play.1. The first role cuts in at the funding stage of projects. Thedemand group handles portfolio management, whichinvolves choosing which projects to invest in, and alsomaking sure that the winners deliver the promised ROI.Essentially, this is a way of maintaining a financial overview.According to Mark and Rau, it introduces internal marketdiscipline by providing the business units with expertbuyers-tech-savvy managers who combine an intimateunderstanding of client needs and a familiarity with thesupply market .2. The second role consists of supervising the supplyorganization while it builds software for the business. Thedemand group represents the business' interests, forinstance by taking care of requirements acquisition andmanagement. There is a sense that requirements capture istoo complex and specialised a job to be left to businesspeople who are amateurs in that particular role. Instead ofthe traditional approach, in which a business (or systems)analyst elicits requirements, then tosses them over thewall to IT, the demand group maintains continuousongoing contact with both the clients and the developers.Meanwhile, the developers (or at least some of them) are inthe loop right from the project kick-off.3. The third role entails deciding which providers are best forparticular projects. The providers chosen may be theinternal supply organization, or external agencies such asconsultancies, system integrators, or outsourcing specialists.All three of these roles promise to deliver significant benefits.Portfolio management results in doing the right projects. Projectmanagement means doing those projects right. And vendormanagement promises to reduce costs and deliver the requiredlevel of quality.But how easy will it be to find the right people to perform thischallenging set of tasks? The job description that Mark and Raugive for demand managers is almost frighteningly ambitious. Demand managers should have a deep knowledge of theircustomers' processes and a solid understanding of applicationdevelopment. The ideal background for such a managerincludes experience as an application developer and a desire to 1 http://www.mckinseyquarterly.com/article_abstract.aspx?ar=18492Untitled Document3pursue a management career track. The development of thesemanagers should involve ongoing training in general-management skills or practices, such as Six Sigma, projectmanagement, and developing a business case . The division between demand and supply groups helps withplanning, because it ensures greater transparency. The twogroups communicate through a well-defined formal process,which makes everything clearer and less ambiguous, as well asbeing a matter of record. A major benefit is said to be that IT - in the shape of thedemand group - unequivocally takes ownership of businessprocesses. This is necessary because, to put it bluntly, otherwisethey cannot be guaranteed to work right. Businesspeople tendto want control of certain critical aspects of their processes, butthey do not want to be responsible for masses of routine work.For a business process to work reliably, however, every tinydetail must be exactly right. Besides, much of the work ofdefining and building business processes can only be carried outby people with IT skills and experience.McKinsey admits that by no means all organisations need tointroduce demand groups. The sweet spot, at the moment, ismostly big organisations that use a lot of IT, but without anyunusual need for exceptional agility or the lowest possible cost.According to Mark and Rau, Creating a demand organizationrequires patience and persistence, and it isn't for everycompany; those with highly stable business needs or a singlecore business, for example, may not need this model .Mark and Rau describe a real company that gained advantagefrom introducing a specialist IT demand organization. At amajor financial institution, business users felt that IT wasresponsive, but developers were spending too much timeimplementing low-value enhancements, and no one had beenlooking at the larger issues of how the institution's technologyinvestments should evolve. The company solved these problemsby creating an IT demand organization, which improved itsability to plan a technology path and to track the commitmentsbetween IT and each of the business units .Interviewed by The McKinsey Quarterly,2Volkswagen CIOKlaus-Hardy M hleck reveals that his company - one of theworld's leading automotive manufacturers - has already movedquite a long way in the direction indicated by Mark and Rau.The key to M hleck's innovations lies in the realisation thatVolkswagen, like so many other big organisations today, couldnot function without the support of IT. As he notes, It's nolonger possible to talk about designing automobiles ormanufacturing facilities without IT's input, because the vehiclesand the factories are all based on digital models . A fortiori, ITis the key to accelerating product development and streamliningthe business It's no longer enough just to involve IT; innovationmust be driven by IT .M hleck pointed this out to the leaders of critical departmentssuch as finance, product creation, order fulfilment, sales andmarketing, and human resources. As a result, they all agreed tocollaborate closely with IT to improve their operations. A newpost was created, that of PIO (project information officer) - arole analogous to Mark and Rau's demand group. The PIOs'responsibilities include working closely with their counterparts inthe various business departments to design new architecturesand processes to enable innovation . Simultaneously, they facethe other way, bringing IT people up to speed with thebusinesses in which they are embedded.M hleck claims that in the short period we've had thestructure in place , Volkswagen has moved from 18% to 30%of IT effort going into new projects, while actually decreasingthe total IT budget. He concludes that the new structure hasresulted in focusing investment on innovation.Real World Examples2 http://www.mckinseyquarterly.com/article_page.aspx?ar=1846&l2=13&l3=13&srid=85&gp=1Untitled DocumentConsiderations for Putting Supply and Demand into PracticeA natural reaction to Mark and Rau's thesis is to ask why IT has tobe split up in order to attain the benefits described. One logicalexplanation might be that businesspeople will never take ITseriously unless it is re-branded and moved bodily inside thebusiness organization. In order to establish effective two-waycommunication with the business, IT people must adopt protective coloration and make themselves accepted within thebusiness community. The organisation chart provides a convenientand efficient way of doing so.A more down-to-earth concern is how the proposed model wouldmesh with existing processes for gathering requirements andobtaining user feedback. Mark and Rau imply that the demandgroup will become virtually the only bridge between business and IT.In his book IT SUCCESS! - towards a new model for InformationTechnology (Wiley, 2007), Michael Gentle instead predicts that wecan expect to see analysts and developers having more and closercontacts with their ultimate clients, the business end-users.There is the potential that a supply-demand structure would incursome of the same problems that have dogged the UK's NationalHealth Service (NHS). Seduced by visions of free enterprise andcompetitive efficiency, successive British governments establishedan internal market that was meant to uncouple demand fromsupply. Unfortunately, they failed to foresee the very considerablefriction and overhead thus introduced into the system; transactionsthat had previously been arranged quickly and informally suddenlydemanded an elaborate array of procedures that ate up time,money, and effort. In earlier days, if a matron found dirt on one of her wards, theshortcoming would be set right immediately. Under the NHS,however, a senior nurse would have to report to hospitalmanagement, who would (in due course) negotiate with themanagement of the cleaning contractors, and finally a cleanermight be sent out a few days later. Worst of all, once at thehospital, the cleaner might or might not do the necessary work toan adequate standard. It is easy to imagine corresponding delaysand inefficiencies in the IT environment, unless the new jobstructures and responsibilities are fully understood, accepted, andinternalised by all concerned.Moreover, the formal separation of demand and supply ispredicated upon a particular model of software development.Mark and Rau seem to assume that the older waterfall modelwill always be used, which assumes that specifications can bedrawn up in isolation from the developers who will subsequentlytranslate them into lines of code. That model doesn't reflect thetheory and practice of agile software development.In a waterfall process, each phase of development must befinished and closed before the next can begin (Figure 1). Awaterfall project would go through some (or possibly all) of thefollowing phases:1. Feasibility study.2. Requirements elicitation and documentation.3. Analysis.4. Design.5. Coding and debugging.6. Testing.7. Deployment.8. Maintenance.4DefineRequirementsDesignDevelopTestDeliver/ImplementService/SupportFigure 1 - The Waterfall Model of Software DevelopmentMark and Rau write that Typical projects go through fivephases: envision, design, build, test, and deploy . While simpler than the eight phases listed above, this is stillclearly a waterfall process. In agile development, however, testsare usually written before coding takes place. And one of agile developers' b tes noires is Big Design Up Front , about whichtheir feelings are summed up by the acronym YAGNI ( You ain'tgonna need it ). Mark and Rau's envision and design phases both look like examples of Big Design Up Front , andas such would not sit well in a classic agile project.Untitled DocumentThough the waterfall lifecycle has been routinely criticised, itmust be stressed that agile methods are by no means alwaysbetter. It is a matter of horses for courses .The waterfall is a good way of proceeding when requirementsare voluminous, relatively objective, and unlikely to changequickly. Nobody would dream of using an agile process todevelop avionics software, for instance. The laws of nature donot change their minds, so there is little need to changerequirements after they have been finalised. The McKinsey model is quite compatible with any waterfallprocess, and thus should suit the many organisations that stilluse such processes. It will be interesting to see how it fares inagile environments - still in the minority today - although with good will and some ingenuity viable solutions will nodoubt be found. What must also be considered is the dire shortage of peoplewho are competent in both IT and business, and who arewilling to combine those skills in their day-to-day work. Inpractice, as the rewards of business are so much greater, mostemployees who meet that description migrate, sooner or later,to the business side of the fence. That may pose considerablepractical obstacles to finding and retaining qualified staff of theappropriate calibre for IT demand groups.Perhaps the greatest practical merit of McKinsey's suggestion isthat, as a result of being hosted by the business, the demandgroup may attain greater credibility in the eyes of businessmanagers. It is a clich that bankers prefer to deal with peoplewho resemble themselves - that is, those who wear smart suits,crisp shirts, ties, and well-polished shoes. Businesspeople, too, arehappier talking to people who look like them and share theirvalues, skills, and assumptions. Thus the demand group may takeon the role of a kind of IT embassy to the business side .There is, of course, some risk that the embassy may sooner or later go native , losing many of its IT skills and coming to think moreand more like its hosts. If that should happen, the IT departmenthas lost some of its most valuable members, and the quest tomatch demand with supply has to begin all over again.Presumably it will be necessary to make recruitment to thedemand group an ongoing activity, with prospects being identifiedand prepared well in advance.Mark and Rau have stated that many organisations are stumblingupon the idea of infiltrating IT relationship managers into thebusiness side. In the world of commerce, however, this is standardpractice (among successful vendors, at least). Consider the salesstrategies of two rival computer manufacturers in the 1980s,Digital and IBM. Digital salespeople, by and large, tended to keeptheir customers informed and then wait for orders. On the otherhand IBM salespeople, accompanied by their systems engineersand other helpers, actively climbed around inside customerorganisations to see what opportunities they could conjure up.Notice which of these two vendors is still a world leader today!By adopting the sales strategies of industry leaders like IBM,Microsoft, and Oracle to their own internal communication andplanning needs, far-sighted executives may be able to reap similarrewards in future.5Volkswagen's M hleck points out that In many companies andin a lot of industries, you will find that IT isn't a corecompetency& management views it as a cost centre . Thedichotomy of cost centre versus profit centre is really at theheart of IT's perceived problems. After all, no successfulcompany does anything that does not contribute to its success.So what does it really mean to say that IT is viewed as a costcentre? Simply that, while its costs are obvious for all to see, thebenefits it generates are much less obvious. So unobvious, infact, that they do not appear on the balance sheet at all. But does that mean they do not exist? Of course not: if IT reallyconferred no benefits, the company would not continue to payfor it! Like manufacturing or human resources, IT helps thecompany to be profitable - but not in any easily measurable way.The Problem of IT Investment and ReturnFigure 2 - The Simple Demand Curve33 http://en.wikipedia.org/wiki/Demand_curveUntitled DocumentThe economists' demand-supply equilibrium diagram (Figure 2) isa useful intellectual tool, but as far as IT is concerned it is astarting point rather than a finishing line. The answers that itgives are useful (to some extent) in simple scenarios, such as thepricing of chocolate bars or bricks. In the business/IT environment,however, it is useful mainly as a source of further questions.Among these would be:1. What is the product? What should it be? Who is best placed tosay what it should be?2. How much will the product take to create, to operate, and tomaintain, as a function of time?3. How long would the various possible products take to create?4. What benefits will the product generate? Can these benefitsbe expressed in financial terms, and if so with what accuracy?How will the benefits be distributed through time?5. Whatever products have been selected for creation, are therealternative choices that promise a better benefit/cost ratio?6. If a certain selection of products is made, and productioncommences, will it be possible to change course and createother products instead?7. Once a product has been created and paid for, over how longa period should its asset value be written off?Whereas supply normally depends to some extent on demand,the relationship tends to work the other way round in IT. Thebusiness will only demand a given application after it has becomeaware of its feasibility and the benefits it will bring. Experiencebears this out: organisations that develop stronger ties betweenbusiness and IT often report a surge in demand for strategicsoftware, which has to be compensated for by a correspondingcutback in routine activities.The routine work of operations, maintenance, and low-valueenhancements has not become any less important. All that hashappened is that the business has suddenly caught a glimpse ofthe gold at the end of the rainbow - the strategic advantages thatIT can confer, if only a way could be found of agreeing exactlywhat applications are required. Once the people are put in placeto help define those applications, the table of priorities is upendedand tasks that yesterday seemed important are demoted to thelevel of must do sometime, but not just yet .The most that can reasonably be asked of the IT department is towork closely with business to elicit requirements, estimate the ROIand other benefits of proposed projects, and assign prioritiesbased on these estimates. The ultimate responsibility for keystrategic decisions must rest with business management.6The hardest task of all, in principle, is deciding on requirements.It has two main aspects:1. Choosing which projects to pursue.2. Deciding which features to include in each project thatreceives investment.The crucial difficulty lies in the fact that traditionally businesspeople and IT people have different concerns, expertise, andawareness. This means that neither group can hope to solve theproblem of requirements without a lot of help from the other.How can businesspeople tell IT what applications they need, ifthey do not know what IT is capable of delivering? And howcan IT tell the business units what it can do for them, withoutknowing what problems and opportunities are most deservingof attention?Consider the example of Amazon. If Jeff Bezos and hiscolleagues had not had a lively awareness of the capabilities ofWeb storefronts, they would never have conceived of a purelyWeb-driven bookshop in the first place. No amount ofconventional business acumen would have told them thatcomputers could actually allow consumers to buy products thatweren't there yet from a shop that didn't exist, pay for themelectronically and have them delivered promptly.On the other hand, any number of programmers andWebmasters knew very well that an operation like Amazon wastechnically possible. But most of them neither knew nor caredwhether it could be made commercially viable; nor were theyinclined to incur the very large risks of finding out. To this day, it is unlikely that communication between businessand IT figures high on Amazon's list of concerns. After all, thecompany's very existence has depended, right from the start, onthese two supposedly irreconcilable groups working smoothlytogether. Perhaps most important of all, Bezos knows very wellthat one small mistake by IT could stop Amazon from tradingaltogether. For that and other reasons, his IT people will alwayshave his attention whenever they need it. Indeed, it is probablethat he seeks them out just as often as they come to him.The Problem of RequirementsUntitled DocumentGentle s ModelAs we have seen, the relationship between IT and the business ispoorly articulated. Several major problems can be readily identified,for which there are no obvious solutions. Perhaps the hardest jobof all is deciding how to allocate investment, since this depends onso many independent factors. Even once investment has beenallocated, there is the difficulty of gathering requirements andmaking sure the finished application really meets the users' needs.All this has to be done with insufficient facts and figures, against abackground of political expediency and short-term decision-making. Last but not least, the whole process is bedevilled bysuspicion between IT staff and business people.Most attempts to resolve these interlinked problems have beenundertaken at too low a level. A more ambitious, yet plausible,approach is described by Michael Gentle in his book ITSUCCESS! The key to his approach lies in its comprehensiveness;instead of tackling parts of the overall problem piecemeal, he firstexplains the big picture and then suggests ways to fix everythingthat has been going wrong.Rather than being the fault of CIOs, IT staff, or even the way inwhich IT is traditionally run, Gentle suggests that whole model ofinternal IT pricing and charging is fundamentally inadequate. Inspite of the very large sums spent on IT, neither the costs nor thebenefits of applications are properly measured. Consequently, it isimpossible to do any kind of accurate cost-benefit analysis.Gentle points out that the normal laws of supply and demand donot hold in this particular case. IT appears to be essentially free to users in most companies, because it is centrally funded from thecorporate budget as a cost centre. When the effective cost ofanything is zero, demand will soar. (Another striking parallel withthe NHS). Attempts to set up a pricing mechanism throughchargebacks have often failed, and may sometimes be actuallycounterproductive. Users reason that, since they are paying for theservice anyway, they might as well ask for as much as possible. ITtherefore ended up as a black hole in which the rest of thebusiness could pour work requests at will, and whose volumewould always exceed its capacity to deliver .To fix this deficiency, Gentle argues, IT must measure the preciselifecycle costs for each system that it delivers and operates.Meanwhile, the business should measure the precise benefits of thesystems they order and use. Amazingly, he remarks, somebusiness users even expect IT to do this - which would be theequivalent of an airline asking the maintenance teams in thehangars to track the business benefits of the aircraft it uses .It is particularly vital to go on continuously tracking costs andbenefits after the first flush of enthusiasm - indeed, all the wayfrom a project's cradle to its grave. This permits continuousaccurate cost-benefit analysis - something that Gentle asserts ishardly ever accomplished today.Having laid the basis for his argument, Gentle now moves in forthe kill. A standard client-vendor relationship is impossible for in-house IT, he reasons, because the product is too complex and theclient doesn't have enough expertise to understand it. Consequently, the client cannot possibly define exactly what isrequired! Moreover, requirements for many business systems aremoving targets. They cannot be captured by static documents; andthe more detailed the requirements, the longer it takes to collectthem, and the sooner they will be out of date. In any case,specifying a complete and consistent set of requirements is notsomething that comes naturally to most human beings. Either theymention a few highlights, and expect the rest to be interpolated forthem, or they just say yes or no to what they are shown.The conventional model has other weaknesses, too. Gentle pointsout that operational demand - the ongoing cost of runningapplications after they are delivered - usually has far too littlevisibility. Everyone wants to be associated with big, new, shinyinitiatives. No one wants to pay for operating costs and upgrades,even if they are essential to keep business-critical systems working.Another tricky syndrome is the commitment conundrum .Detailed, accurate costs can only be worked out by a team ofpeople working over a number of weeks - which in itself requiresfunding! One way around this is to have a dedicated team withthe right skills - such as McKinsey's demand group - permanentlyavailable, thus improving the accuracy of cost estimates. 7Untitled DocumentIn Gentle's view, all demand should be systematically filtered(see figure 4). Requests are fed into a pipeline or funnel, wherethey are sanity checked and then methodically assessedagainst objective criteria. This involves cost-benefit analysis, riskmanagement, and allocation within a previously-agreedportfolio of investment categories.A basic set of investment categories might include:" Keep the lights on;" Generate revenue;" Reduce costs;" Regulatory compliance;" Strategic initiatives.If each category is given a budget quota, the demandmanagement team can guarantee that no categories are eversqueezed out by expensive vanity projects . Risk should bespread across the portfolio and, like cost-benefit analysis, riskshould be assessed continuously - not just when a projectcommences. Figure 5 illustrates one way of gaining insight intohow balanced a given portfolio is.Gentle's recommendations have much in common with theideas put forward by Mark and Rau. However Gentle takes theargument much further forward, and provides many morespecific details of how the link between business and IT shouldwork. Mark and Rau envisage the demand group as a sole pointof contact between the business and the supply organization,whereas Gentle is a convert to agile methods and wants to seedevelopers and other IT staff interacting with many businessusers on a regular basis.8Figure 5 Analysing Portfolio BalanceEvaluate investment by clientConclusion: A Step in the Right DirectionIn reality, people matter more than organisational charts. Ifyou have the right people, things tend to go well. If youdon't have them, no amount of shuffling desks or job titles isgoing to help much. Mark and Rau acknowledge this,admitting that &the new organization should be structuredcorrectly and must get the right type of talent into theimportant new roles . The introduction of formally-recognised demand groups coulddo much to alleviate that chronic cause of failing IT projects -company politics. All too often vital investment decisions aresettled on the basis of who owes whom a favour, or evenwho shouts loudest (what Gentle calls decibelmanagement ). Once a demand group is in place projectevaluation, resource allocation, and especially futurecommitments should be carved in stone for all to see -making them harder to change or ignore.If, as seems likely, both Gentle and McKinsey are broadlycorrect in their analysis and recommendations, we may beapproaching the end of decades of confusion and inefficiencyin the corporate exploitation of IT. That is something forwhich we should all be profoundly grateful, and everyonewho helps to apply these ideas in practice deserves all thesupport we can offer.Figure 4 Filtering DemandUntitled DocumentAbout the AuthorTom Welsh is an independent consultant specialising in softwareengineering, middleware, and enterprise architecture. A seniorConsultant with Cutter Consortium, he edited Cutter s WebServices Strategies and has authored in-depth reports on XML,SOA, Web Services, Distributed Sortware Security, Open Source,CORBA, and Model Driven Architecture. Tom was previously Senior Analyst at ComputerWire, where heedited Client/Server Tools Bulletin , Object-Oriented ToolsBulletin and Internet Tools Bulletin . His articles have appearedregularly in MiddlewareSpectra, The Register and otherpublications, and he has spoken at many conferences andseminars. Tom can be reached at twelsh@cutter.comAbout Cutter ConsortiumCutter Consortium is a unique IT advisory firm, comprising agroup of more than 125 internationally recognized experts whohave come together to offer content, consulting and training toour clients. These experts are committed to delivering top-level,critical, and objective advice. They have done, and are doing,groundbreaking work in organizations worldwide, helpingcompanies deal with issues in the core areas of softwaredevelopment and agile project management, enterprisearchitecture, business technology trends and strategies, riskmanagement, metrics, business intelligence and sourcing. Cutter offers a different value proposition than other IT researchfirms: We give you Access to the Experts. You get practitioners'points of view, derived from hands-on experience with the samecritical issues you are facing, not the perspective of a desk-boundanalyst who can only make predictions and observations onwhat's happening in the marketplace. With Cutter Consortium,you get the best practices and lessons learned from the world'sleading experts. For further information please visitwww.cutter.com9
