Call 0844 800 6610

YOU ARE HERE: Home›SOA, Web Services & Enterprise Integration › Case Studies

Evaluation Centre is the UK’s No. 1 guide to software, services and technology – dedicated to saving you time and money in selecting your next software solution. This Centre provides independent advice on SOA, web services and EAI software. Simply search and select from our list of software vendors and stay up-to-date with our growing range of white papers, case studies and advice articles by SOA, web services and EAI software experts. REGISTER NOW to get help with your project

SOA, Web Services & Enterprise Integration

When coding is not enough: John Colley, (ISC)2

Good security practice has become a business imperative, forcing companies to make a significant investment in their systems infrastructure. But as a result, the people who want to exploit the systems are moving up the systems stack to the application layer. The opportunities here are abundant. Organisations need open connected relationships. So sensitive customer and business data and the applications that house it are now available to privileged third parties, including contractors, outsourcers, business partners, supply chain nodes, and the increasingly mobile employees who regularly access their systems from outside their corporation’s secure perimeter. This all adds up to a very hostile environment for the applications, yet the development community remain focused on usability and functionality – the priorities that guided their agenda when applications were developing for closed environments.

Building an architecture: Mark Couzens, SELEX SI

Why should companies use an enterprise architecture (EA) strategically? Primarily, it’s because large systems integration and engineering projects frequently involve upgrading or replacing mission-critical business information systems. Yet these systems have often emerged in an organic, tactical manner to solve local business problems, and may represent significant organisational internal investment. Unfortunately such a development lifecycle often creates a ‘disintegrated’ system or system of systems when viewed from the strategic perspective. In order to mitigate business risks and provide a foundation for delivering future strategic change, businesses need to develop a detailed, concise and robust description of their own organisation – and an effective and industry-proven method of doing this is via an enterprise architecture.

Many hands...: John Abram, Monetical

An increasing number of software development heads are finding they are managing a highly distributed organisation – not as a result of any operational objective but as a consequence of commercial mergers and acquisitions, increased partnership activities, or enforced short-term cost reductions. The result is often a dramatic reduction in enterprise development performance caused by two significant changes: decline in performance capability; and erosion of development expertise. Combined, these two problems greatly impact an organisation’s ability to identify and introduce the right changes to its development environment to reverse the performance decline. So how do you find the best performance turnaround solution for your business? The first step is to quantify your company’s current performance capability and the complexity of your environment. This will prove highly valuable when developing a business case for investment and measuring the return on investment following performance turnaround, as well as demonstrating to executives the underlying reasons for any decline in performance.

Is SOA meaningless?: Graham Berrisford, Avancier

In the same way that an architect designs buildings and superintends their construction, so an enterprise IT architect designs technology systems to support a business, and superintends the construction of those systems. In recent years, service oriented architecture (SOA) has been regarded as a key technology to help IT architects perform this role. But what exactly does a service oriented architect do that is new or different? In my view, ‘SOA’ is used so ubiquitously and variously, to mean everything and to mean different things, that the term has become a hindrance to discussion of corporate IT architecture. Depending on who you’re talking to, SOA can mean many different things…architecture, modular design, client/server layering, object oriented design, distributed objects, message oriented architecture, event-driven architecture, programming to an interface, and the ad-hoc use of web services. This article examines the various meanings people give to SOA.

An elusive goal: Bob Jarvis, Systems Advisers

Enterprise integration sounds easy, doesn’t it? Just bring a couple of organisations together, streamline some business processes, re-organise a few workgroups, join up a system or two, and standardise your hardware and software platforms. Job done… Were that it were so! The snag is that enterprise integration means many things to many people and individual views of a requirement don’t necessarily take into account – or are even aware of – the bigger picture or the downstream effects of change. The tasks described above are closely interrelated. Typically, you can’t change one without disrupting the others. For example, a change in organisational structure usually means changes to business processes; a change in technical platform usually requires changes to application software; a change in application software often means a modification to a business process, and so on. This network of modifications and changes has to happen quickly and in sync to respond to evolving business objectives and goals, especially in times such as these.

SOA slow: Cliff Mills, NCC Research

An organisation’s application portfolio consists of many varied systems that have been built up over several years, ranging from bespoke solutions to standalone packages and integrated ERP systems. Add in a merger or acquisition along the way and you soon have an assortment of applications and systems that may have little in common. In the longer term, service oriented architecture (SOA) holds out the promise of providing a more adaptable and flexible architecture, but this is still some way off. So enterprise application integration solutions will be in demand for a considerable time yet and suppliers need to continually refine their offerings to address the growing integration requirements of organisations. In previous surveys, when we’ve asked respondents about their biggest challenges in software development, the number one issue by some way has always been ‘linking legacy systems to new applications’.

Twins separated at birth: Tony Baer, Ovum

One of the main purposes of service oriented architecture (SOA) is to slice through software silos in order to help organisations grow more agile in automating their business processes. Effective governance is essential if SOA is to deliver on this promise. However, in their zeal to manage SOA, many organisations are at risk of spawning yet another new governance silo that becomes a ‘special case’ for the software development lifecycle (SDLC) portion of the application lifecycle. The uniqueness of SOA is attributable to the fact that, while it requires skills for working with common programming languages and platforms, it also demands specialised architectural skills or awareness and, in some cases, specialised tools or processes that parallel or fork from the SDLC. In the long run, relegating SOA to the software development organisation as a special case creates the very duplication that SOA itself was supposed to eliminate. Mainstreaming SOA as a realistic option for enterprise software developers requires that SOA be reconciled with the SDLC and full application lifecycle, rather than run as a parallel special case.

Testing times: Richard Terry, Sogeti UK

Have you ever gone to see a film that you’ve heard is good, only to be disappointed when it failed to live up to your expectations? It’s a horrible feeling, isn’t it? For many business managers, IT can provoke the same reaction. Business managers invest so much time and money into applications and technology, that they are disappointed if and when their chosen systems don’t live up to expectations. A recent Sogeti survey on software testing turned up a startling statistic: 93% of the software experts questioned said there is a communication gap between what business managers need from IT and what technology actually delivers. This gap occurs because the IT department lacks an understanding about the needs of the business world, and the business world doesn’t understand the intricacies and complexities of IT. The key way to narrow the gap is through better communication. Rather than just accepting the requests of the business side, IT departments need to truly understand them.

Making SOA pay: Paul Heaviside, PA Consulting

Just a few years ago, amid much fanfare and vendor activity, service oriented architecture (SOA) burst into the hearts and minds of IT departments across the globe. As suppliers invested heavily to release new products – or at least ‘SOA-enable’ their existing offerings – they convinced IT departments to buy and thus reap the rewards SOA promised. Now some years on, it is safe to say these investments have met with varying degrees of success. Focusing on their ESBs and XSDs, many IT departments have failed to deliver the promised returns from SOA. And the reputation of the technology has suffered. Yet in most of these cases, it is not SOA that has failed, but the application of SOA. Like a dotcom boom or a financial bubble, even some of the most experienced IT professionals forgot some basic principles when it came to their ‘SOA investment’ – it’s all about the business!

On a needs to know basis: Shantanu Bhattacharya, Siemens

One misconception about service oriented architecture is that the service part means ‘web services’. In a real-life scenario, this can lead to building ‘a bunch of services’ (ABOS) rather than developing a true SOA. This article explains what constitutes a service, and describes the various needs of an SOA solution and how to identify those needs for your SOA scenario. This approach puts the focus of the SOA initiative firmly on the benefits and the specific phases of the SOA solution. A service is a piece of code that can exist independently. It’s usually identified independently for composition with other services and is called independently for execution. Therefore, it’s not essential for a service to be a web service, which is only one type of service.

Adopting agile: Dorothy Tudor, TCC

Agile development has evolved since the mid-1990s as a reaction against ‘heavyweight’ methods such as the waterfall model of development. An agile approach is one that delivers business-focused results quickly and effectively. It should do this reliably, predictably and within a tightly constrained budget and a specific timeframe. An agile method generally promotes incremental development and delivery. It will advocate simplicity, it should be easy to learn and use, and sufficiently well-documented to be teachable and repeatable. It should also be adaptive, allowing for changes in requirements occurring during the development cycle whilst still controlling ‘scope creep’. It should offer a set of best practices that allow for rapid delivery of high-quality product; a leadership philosophy that encourages team work, empowerment and accountability; a team-based approach, requiring close customer/developer collaboration; and a business-focused approach that aligns development and delivery with customer needs and company goals. Finally, it should also promote a sustainable pace of working and visibility of progress.

The pillars of agile development: Jon Collins, FreeForm Dynamics

What will technology historians make of the decades just before and after the start of the third millennium? Whatever they conclude, they will have the superlatively useful benefit of hindsight on their side, whereas those of us living the technological revolution are forced to make it up as we go along. This is as true for what can be done with IT, as how it should be done – each advance prompts us to rethink how we approach building systems, developing software and maintaining service levels. So in considering your company’s approach to software development, it is important not to get too stuck in any particular mode of thinking. Over time, of course, the pain of having to unlearn and relearn different methods is reduced by the comfort of knowing that underpinning all such approaches lie a common set of principles which, once learned, will generally continue to apply.

Dodging the recession: W Emmerich & C Bröcker, Zuhlke Engineering

An economic downturn has many effects on companies’ IT strategies in general, and their enterprise integration in particular. There is an increased focus on cash preservation through reducing inefficiencies in organisations. Companies may also need to reorganise quickly and close business divisions, services and product lines. In addition, the rate of mergers and acquisitions is accelerating as a result of share price falls that enable stronger organisations to acquire weaker ones. Organisations may also have to respond to the liquidation of companies, for example by adjusting their supply chains. In a recent article in the Financial Times, Donald Sull argued that a period of economic hardship is “an ideal opportunity to implement change and instil better practice”. In light of this, a modern enterprise integration approach can help organisations in addressing such change. It can in fact provide an IT system architecture that reduces manual integration work, supports internal reorganisations as well as mergers and acquisitions, and helps organisations to adjust their supply chain. So how can this be done?

Challenging the sacred cows: John Good, Serco Consulting

One critical decision businesses face is how to integrate the myriad of application systems in the enterprise. You may face this question for a number of reasons, such as rationalising your applications, de-risking the enterprise away from outdated technology, integrating systems acquired through an acquisition, or simply responding to a revision of your IT strategy. A key consideration is whether to deploy a hub-and-spoke model or retain point-to-point interfaces. Whilst it is not the same decision, this is often also bound up with deciding whether or not to purchase an Enterprise Service Bus (ESB), which would sit at the hub of the architecture and provide a common technology platform delivering integration capability (although it is recognised that the use of an ESB does not of itself require a hub-and-spoke architecture). This decision is widely portrayed as resting on a comparison between the respective total costs of ownership (TCO) … and the received wisdom is that hub-and-spoke is cheaper.

Living legacy: Shantanu Bhattacharya, Siemens

Many companies want to introduce a service oriented architecture (SOA) into the organisation to make their processes flexible, adaptable and supple. But they already have a set of systems in use for their business processes. So how do you integrate SOA with your legacy applications to get more value out of them? This article takes you through the steps you need to make it happen – and the pitfalls to avoid. It’s clear that legacy systems form the base from which an enterprise can continue to improve on its existing processes. So any strategy to bring in value without incorporating legacy systems will have limited success. Some legacy systems can be integrated with SOA relatively easily, others with more difficulty.

Application security: the final frontier: Fran Howarth, Quocirca

Organisations today are increasingly reliant on software applications to run their businesses. But at the same time, those applications are increasingly being web-enabled to facilitate collaboration and commerce with business partners and customers. In order to do this, many companies are relying on newer network architectures, such as service oriented architectures (SOAs) or dynamic Web 2.0 applications that provide a greater degree of interactivity among users. But whilst these new application development and delivery techniques provide a richer experience and are key drivers in expanding collaboration capabilities, they can also place organisations at greater risk of attack as more applications are exposed to users over open business networks, including the internet. This danger has not been lost on hackers, who are refocusing their attention on the vulnerabilities and flaws contained in those applications. A recent survey by Quocirca, commissioned by Fortify Software, has looked at how organisations are tackling these challenges, including the processes they have in place for ensuring applications are developed securely.

Transformation trilogy: Nigel Devenish, Altkon

SOA – service oriented architecture. BPM – business process management. EDM – enterprise decision management. These three technologies have all been developed separately as business improvement tools. But bring them together and they form the basis for sound governance, risk and compliance at all levels of an organisation, creating a powerful ROI argument. In fact, the return is even better than it might first appear. The ROI model is not so much the sum of the parts – eg, SOA + BPM + EDM = ROI. It is more the multiplier SOA x BPM x EDM = ROI. Whether the motivation is compliance, efficiency, productivity, profitability, management and control – or combinations of all these – it is a powerful message. But when should companies integrate these three approaches and how? The promise offered by the combination of SOA, BPM and EDM is partly down to market maturity. These tools have all been available to early adopters, but until now the costs for the individual technologies have been out of reach for all but the Tier-1 organisations.

EDA versus SOA: Steve Craggs, Lustratus

The concept of an event driven architecture (EDA) has recently been the subject of some controversy when considered in the context of the general adoption of service oriented architecture (SOA). In particular, there has been a high degree of confusion around whether the two architectures are compatible or competing and whether EDA combined with SOA forms what some analysts have referred to as SOA 2.0. Dispelling this confusion, it becomes clear that the term EDA is being used in three different ways within the SOA context. Associated with each of these is potentially significant, but different, value for any organisation grappling with SOA deployment. The most significant usage in terms of long-term benefit is the application of EDA to the problems of control and refinement of the deployed SOA network through management by exception as well as business process optimisation. But unsurprisingly, the diverse interpretations of EDA make it difficult to understand the vendors’ strategies and product offerings; to clear this confusion, this article compares the strategies of the EDA products in the context of these three interpretations.

Future perfect?: Peter Boggis

The continued global consolidation of industries and the accelerating competition from emerging economies are driving significant change in the businesses we used to understand how to manage. As one global CIO recently said to me: “The future is clearly no straight extrapolation of what’s worked in the past. We must stop trying to drive the car through the rearview mirror. What’s made us successful in the past is no longer sufficient to make us successful in the future – radically different capabilities are required of us as leaders for the future.” One way of navigating towards a future state which may be very different from the past or present is through an enterprise architecture or ‘target operating model’ for the company. Within global, multi-company groups, the desire to demonstrate that ‘the whole is greater than the sum of the parts’ has led to a quest for synergies across geographies, products/services, business processes, infrastructure and technology solutions. For many organisations this is not a new journey – companies such as Cisco, Kraft General Foods or GE have all been active in this area for a number of years.

EA made easy: Richard Noon, Atos Consulting

Enterprise architecture is a hot topic. A range of organisations from retail banks to government departments are exploring how they might create an internal enterprise architecture capability. One reason for this is that all these organisations essentially share the same problems: lack of clarity as to how their IT strategy is going to meet the strategic direction of the organisation; reduced agility, due to a lack of traceability from the company’s initial business objectives and vision, through its business architecture, to the actual technology components which are (ideally) business enablers; an inability to understand the impact on the business of rationalising enterprise components, again due to a lack of traceability; projects overrunning because their impact and scope are not fully appreciated before commencement; and ‘as-is’ data not captured in a consistent way – meaning the organisation has to embark on frequent discovery phases. The data gleaned from these phases is not often re-useable or consistent with other programmes.

BPM: beyond technology II: Neil Ward-Dutton, MWD

Business process management is a hot technology. But, as I explained in my first article, thinking about BPM purely in terms of technology is a sure way to confusion and, ultimately, failure. That first article explained the role of BPM technology – this follow-up focuses on how BPM can be applied to solve business problems. Business processes exist at a number of levels within organisations: operational processes which handle particular units of work within a business activity – for example, researching a report or designing an automotive part; management processes, which manage groups of instances of execution processes in order to report on process status, or allocate resources to individual process instances and schedule them efficiently – for example, research scheduling or automotive production line optimisation; and strategy processes, which work above the level of management processes – for example to set the overall policies and priorities for management processes which will in turn manage execution process instances; or indeed to create entirely new execution or management processes, or tune existing processes.

BPM: beyond technology: Neil Ward-Dutton, MWD

Hammer & Champy’s seminal book Re-engineering the Corporation may now be an old and dusty volume, but business processes are once again a fashionable thing to talk about. Business process management (BPM) is hot, hot, hot – every IT vendor seems to have some kind of initiative or offering that is related to it. But thinking about BPM purely in terms of technology is a sure way to confusion and, ultimately, failure. It’s better to think about BPM as an approach to thinking about a business, and relating the resources that support the business to that ‘thinking tool’. Yes, technology does play a role: both in helping to automate BPM activity, and in providing some of the resources which support business processes. But the role of technology in BPM is complicated and you must understand it before embarking on a BPM initiative. These articles aim to help.

Perfecting process performance: PG Rule, Software Measurement Services

Lean management is about maximising the value delivered to customers, by reducing waste and re-work. Lean processes cannot be implemented effectively without judicious use of objective measures, visible to the creative and customer-facing staff. The purpose of gathering metrics is to inform decisions – so to be useful, measures must be visible to those in a position to react to the feedback provided. These principles can be applied to the software development process. But developers need to assess what measures can be used to inform decisions and behaviour around the new software at all levels; to understand how to go about putting these measures in place; and to understand how to make sure they are visible – and therefore applied – to the value-creation process. “Measure, assess, calculate, compare and commit to victory” were the principles of good generalship identified by Sun Tzu over two and a half thousand years. These same principles apply equally to software development projects.

SOA: the good and bad news: Rob Hailstone, Butler Group

The good news is that an IT architecture built around loosely coupled services is so adaptable that it can be used to deliver a wide variety of business benefits. The bad news (or at least the bit that’s missing from most ‘how to do SOA’ articles) is that the same approach to adoption doesn’t necessarily give the best results in each case. SOA is mostly described from the strategic perspective of establishing an IT infrastructure that is adaptable and responsive to changing requirements. This is a long-term strategic commitment that demands a sound methodology if it is to be successful. However, most of the deployments we see do not fit this pattern – at least in their initial implementations. SOA is far more likely to find its way into an organisation for a much more pragmatic reason that only makes sense if it can be delivered quickly.

True fiction: Jon Collins, Freeform Dynamics

What exactly is service oriented architecture? In an IT industry which sometimes seems to take pleasure in making things more complex than they need to be, it can be difficult to tell. The high-tech sector has frequently been compared to the motor industry, with all of its innovation, commoditisation and general impact on the world at large. Just as valid perhaps is to compare IT to the earlier days of the pharmaceutical industry, before such obligations as clinical trials and actually proving a drug could do what its manufacturer said it could do. For all the flashing lights, our illustrious business has retained its fair share of snake oil salesmen (and nobody is immune to this – just remember Y2K). Against this background, it is perhaps inevitable that such complex constructs as SOA should be castigated as over-hyped and under-achieving.

SOA: saviour or chimera?: Clive Longbottom, Quocirca

The mantra of the last few years has been that service oriented architecture (SOA) is another silver bullet for solving all known IT problems, enabling IT to fulfil its dream of being the great White Knight galloping over the hill to save the day every time there is a problem. But just how is SOA faring in the big bad world out there? And is it just another passing fad? I for one certainly hope not, having firmly nailed my colours to the SOA mast. In the past I have said that SOA is the only sensible way forward for organisations wishing to remain competitive in the medium to long term. But even I have to admit that SOA is struggling to deliver on its promise – and I’d like to examine why this is so.

EA: rights and wrongs: Neil Ward-Dutton, MWD

Enterprise architecture, or EA, has been around as an idea for quite some years. But what is it exactly? Although there appears to be general agreement that EA is something to do with IT system design ‘in the large’, and involves considering the business context for systems, there’s no real consensus regarding a definition of EA. Indeed, there’s no real agreement as to whether ‘architecture’ is a practice you conduct, or an artefact that you create (or both). That means, of course, that any meaningful discussion of EA has to start with a declaration of perspective. In this article, I’ll be working to the following (high-level, subjective) definition: Enterprise architecture is a practice which comprises two parts. Firstly, it’s the practice of discovering and documenting the capabilities and activities of an organisation; how they are currently supported by IT systems; and how they should optimally be supported by IT in order for the organisation to achieve its strategic goals, within the constraints of business reality (including issues like financial constraints and short-term business needs).

Web 2.0: now and into the future II: Martin Berman, Hitachi Consulting

Over the last three years, a series of changes have taken place in the internet which are now being referred to as ‘Web 2.0’. The first evolution of the web a decade and a half ago caught many organisations by surprise. Even giants like Microsoft initially dismissed the internet. Is history about to repeat itself? Are many organisations going to miss the opportunities presented by Web 2.0? Are you? This is the second of two articles. The first encapsulated what Web 2.0 is about. This article explores the multi-faceted ways in which organisations can gain substantial competitive advantage using this latest version of the web. In the midst of all the hype about Web 2.0, many organisations are asking ‘So what – what can it do for me?’ We will attempt to provide some specific answers, and examples, to that question.

Web 2.0: now and the future: Martin Berman, Hitachi Consulting

Over the last three years, a series of changes have taken place in the web which are now being referred to as ‘Web 2.0’. The first evolution of the web a decade or so ago caught many organisations by surprise. Even giants like Microsoft initially dismissed the internet. Is history about to repeat itself? Are many organisations going to miss the opportunities presented by Web 2.0? Are you? This is a series of two articles. This first article will try and encapsulate what Web 2.0 is about. Its basic thesis is that companies have to really understand Web 2.0 and all its implications before they can begin to use it to its full potential. Web 2.0 gives companies a whole new set of tools. However, any tool can be dangerous if misunderstood and mis-used. The second article will explore the multi-faceted ways in which organisations may be able to gain substantial competitive advantage using this latest version of the web.

Gaining business buy-in to SOA: Chris Maxwell, JMG Partners

There is a big problem with SOA. It sounds like a technical topic for technical people. It does not sound like something that the business world could or should spend time on. Service orientation is a concept that comes out of modern ways of thinking about IT. It is of course based on the idea that if you can properly define the essential capabilities (or services) that you need to run your business, then these services can be used and re-used many times, redundant services can be eliminated, disparate systems and technologies can work together – and as a consequence you will have a far more efficient and effective operation than you did before. But whilst service orientation is a concept that comes from the world of IT, in practice it has even greater applicability to business processes and business services. Indeed business service orientation should come before any consideration of technology or systems.

What's in a name?: Cliff Leach, The Project Factory

Semiotic analysis (or semiotics) is the study of signs and symbols and of sign systems. It has its roots in both science and linguistics, and includes the study of how meaning is constructed and understood. And while the connection may not be immediately obvious, it’s a technique that can be used to address complex problems in enterprise data modelling. The problem it tackles is that as organisations grow organically, one of the key tasks of the systems architect is to try and build models of the organisational concepts and the data that support these concepts. Even within the same industry and sector, different organisations use different terms for concepts that are similar or even the same. Yet, however different organisations appear to be, they all share many key concepts in common. These concepts relate to data of a very similar sort and, within a sector or segment of operation, they need processes that achieve similar results and with similar controls. One organisation’s ‘sales order’ is another’s ‘contract build form’.

SOA second sight: Steve Craggs, Saint Consulting

Service oriented architecture (SOA) has become a major focus in the IT industry. The market is developing quickly – and users and potential users need as much help as possible in understanding its future direction. So looking at the SOA and integration marketplace as a whole, what is likely to happen during the rest of 2007? I make six key forecasts: SOA taxes will start to bite; the SOA focus will move to application development, testing and project management; back-door SOA adoption will become prevalent; SOA business cards will emerge; the market for SOA appliances will grow; and the ESB market will consolidate.

Integration: still so important: Cliff Mills, PMP Research

Like death and taxes, the need to integrate applications and data across multiple platforms will never go away – only the most effective way of achieving it will change. Whatever long-term software development strategy is adopted, there will always be short-term expediency, changes in direction and mergers and acquisitions. These can have a profound effect on an organisation’s IT and at some stage the question “How do we link these systems together more effectively?” will need to be addressed. A study by PMP Research on the use of integration software in over 100 major organisations shows that 85% of respondents still see the consolidation and integration of their information systems as a highly important business challenge. On top of this, 84% believe integration software provides real benefits to their organisation – and in general the benefits are seen as far outweighing the associated costs.

Make do and mend: Mike Thompson, Butler Group

Although much of the current discussion in the integration market focuses on the new architectural style of service orientation and the closely related technology of business process management (BPM), IT professionals have to bring these to fruition under the strong budgetary constraints that still exist within most organisations. A major influence in the rise of service oriented architecture (SOA) is how it can re-use existing assets – thus extending the ROI of those assets – and at the same time help re-purpose those assets beyond their original intention. This provides for a more flexible infrastructure with a high degree of future-proofing. Unfortunately, too much time is devoted to the idea of SOA and BPM from a green field viewpoint, and this both diminishes the possibilities and ignores the practicalities of the technologies. BPM, especially, is promoted as a layer that will exist across the top of the current technology stack, containing the abstraction of ‘business logic’ and process functions currently implemented at the infrastructure level. The reality is completely different.

SOA: hype or hope?: Clive Longbottom, Quocirca

Service oriented architecture (SOA) is sometimes portrayed as the latest greatest thing that will cure all our technical ills at a stroke, while creating the most flexible and agile support for business processes ever seen. Is this the truth, or just another stage on the hype highway built by the vendors in order to wrest more money out of ever-trusting buyers looking to claw their way out of the chaos of the last greatest thing? SOA is a natural way to go, and it stands a great chance of being far more supportive of a business’ aims than the majority of previous architectural attempts. The reasons behind this are that the standards underpinning SOA have been adopted across the board; these standards work at a high level of fidelity between different vendors; and there is a driving need for something that will enable greater flexibility within the business world.

Plugging into transformation: David Ballard, Northdoor

According to industry analysts Evans Data Corp, .NET and J2EE (Java) are among the most popular development platforms on the planet. A study last autumn showed that 47.9% of developers used Java, while 51.4% developed for .NET. Some developers are clearly so taken with the platforms that they use both. Indeed, many companies have decided that all ‘strategic’ application developments will be conducted using one of these two modern languages. That said, plenty of organisations still have valued applications that are written in legacy fourthgeneration languages (4GLs) such as PowerBuilder, Centura/Gupta, Oracle Forms, Visual Basic 6, RPG and Delphi. However, skills shortages, increasing support costs, inadequate performance and incompatibilities with system-level upgrades are exposing these companies to risks, and increasing the cost of ownership of the legacy software.

SOA basics: benefits to the business: Rob Hailstone, Butler Group

When an IT topic has been centre-stage for a couple of years, it sometimes happens that the original purpose gets forgotten in the heat of the technical arguments. Service oriented architecture (SOA) is at risk of falling foul of this tendency, so let’s revisit the purpose briefly before discussing how it can be exploited. The purpose of SOA is to enable IT to respond more quickly to changing business requirements. This simple statement hides four decades of frustration that IT has become a black box to the business world, with no obvious way of reconciling the time and cost of change requests with the business value that is being sought.

Curing desktop schizophrenia: Richard Hall, Avanade

Previous generations of application development were driven by breakthroughs in the capability of underlying hardware. Green-screen VDUs went beyond the batch job and delivered the first tentative interactive steps from the bowels of the mainframe. The first workstations then conjured up mechanical engineering visualisations with graphical impact for a few privileged engineers. Then the PC put flexible computing in reach of most corporate citizens for personal applications, while the local network connected and empowered entire teams, sharing files and ultimately ushering in the client/server era of pooling data in relational stores throughout organisations.

Architectural power: Martin Berman, Impact Plus

An enterprise architecture (EA) is a blueprint or map of your entire organisation. It is ‘holistic’ in that it encompasses all aspects of your company, such as processes, IT, locations, information and data, organisational structure and business aims and objectives. In particular it links the business and the technology drivers – and the value of an EA arises, at least in part, from an understanding of the linkages between all those aspects. Impact Plus works with large, complex organisations such as the Home Office, Department for Transport, Department for Education and Skills amongst others, and we have found that such organisations benefit significantly from developing and maintaining an enterprise architecture. So what benefits are to be gained? Firstly, it is important to realise that a enterprise architecture in itself has limited value. It is the comprehensive use of the architecture that generates substantial tactical and strategic business value. And the secret to unlocking this value is to be found in the right benefits realisation strategy, coupled with a twin-stream (tactical and strategic) approach.

All in good time: Yvonne Genovese, Gartner

Because of the hype surrounding web services and service oriented architecture (SOA), many users are assuming that the ease of integration and agility in composing and recomposing business applications has finally arrived. Business application vendors have been quick to declare victory in defining their products as service oriented, and are pushing users to invest significantly in upgrades or migrations to achieve benefits – benefits that are not likely to appear for many years. One problem is that several forces are colliding in this market: software vendors hyping SOA; users considering large investments in SOA as an option for end-of-life applications and expensive migrations or upgrades; and pressures on organisations for adaptive and dynamic infrastructures that yield greater agility, flexibility, transparency and responsiveness.

Unblocking the EAI pipes: Cliff Leach, The Project Factory

Enterprise application integration (EAI) using a service oriented architecture (SOA) is a hot topic in information technology architecture around the world. Companies from Microsoft to TIBCO and even the UK Government have invested major sums in products to support EAI and SOA. In a nutshell, EAI/SOA architectures can be summarised as: a strong distributed heterogeneous architecture; mostly based on message-handling software backbones; used to deliver widespread, and normally asynchronous, application integration; and driving towards a federated database schema and canonical data model.

Joining the SOE army: Andy Mulholland, Capgemini

Businesses face a wide range of issues that impede their growth and profitability. Chief among them is the need for greater flexibility, driven by factors such as multi-channel strategies, pressure to improve time to market, and the impact of mergers and de-mergers. In particular, many companies have failed to effectively integrate their web-based channels and connect them to their legacy systems. The result is that online systems frequently crash - with high visibility to the public, clients and competitors. At the same time, companies are striving for adaptive cross-functional processes that can connect the silos created by their ERP systems. Many organisations’ systems are linked together with an increasing amount of ‘spaghetti’. The result is that too much budget is devoted to supporting their legacy systems, leaving little room for innovation and investment.

Open space: Paul Bellchambers

The software world is being radically changed by the open source movement. Previously, the creation of global communities that could develop and improve a software product was not considered a practical way to bring quality code to market. Now, however, the impact of open source is everywhere. The concept of open source is often misunderstood, even within the computer industry, so it is not surprising that many software practitioners and business managers are unsure as to how open source could add value to their business and infrastructure. Linux is synonymous with open source, but it is only one of the many software elements that are available in this way. And a key misconception is that open source equals free software. Open source software is not free, not in the sense of being free of cost.

Planning to be agile: Mark Collins-Cope, Ratio Group

Planning an agile, iterative and incremental software development involves many concerns, trade-offs and judgement calls. But there are a number of principles and factors to help you get it right: plan in appropriate detail – in-depth for the short term, in broad strokes for the long term; negotiate over scope – when faced with an imposed deadline; the customer dictates priorities – what should be implemented when; the plan must follow reality – using detailed increment plans; feedback is vital – plan to get feedback to mitigate your risks; use three types of release – internal, investigative and production; plan to refactor when necessary – to stop design rot setting in; trade-off the costs and benefits of incremental development; and consider high-impact design decisions during early increments.

In the loop: Giffin Lorimer, G4h Ltd

Closed loop performance (CLP) initiatives such as balanced scorecard are an important part of enterprise management systems. By focusing on outputs and processes, they allow firms to organise themselves in whatever ways they need to achieve their strategic goals. In theory this should make firms more flexible in adapting to market cycles and to disruptive events such as technology, input costs or regulation. The CLP approach is to break processes into measurable chunks that can be independently improved. Part of any business improvement initiative will be a software development task that automates the business process in order to achieve higher consistency, faster results and lower costs.

The best way to SOA: Jason Powell, Enterprise Architecture Solutions

If the benefits associated with adopting service oriented architecture (SOA) are to be achieved in a cost-efficient and manageable way, organisations must view SOA as a strategic, enterprise-wide, joint initiative between business and IT. However, this should not imply that SOA should be delivered as a single large project. Indeed, with any organisation of scale, SOA should evolve incrementally in a controlled manner. And the introduction of an enterprise architecture (EA) can play a key role in achieving this – providing knowledge management, control and structure in support of a measured approach to SOA adoption.

back to top