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.
|
|
|
|
|
|
|
|
|
|
| |
|
|
|
