|
|
|
|
| Management Briefings
|
|
|
|
|
|
EDA versus SOA: Steve Craggs, Lustratus (June 2008)
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EA made easy: Richard Noon, Atos Consulting (April 2008)
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Perfecting process performance: PG Rule, Software Measurement Services (Jan 08)
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
True fiction: Jon Collins, Freeform Dynamics (November 2007)
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EA: rights and wrongs: Neil Ward-Dutton, MWD (July/August 2007)
|
|
|
|
|
|
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).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
What's in a name?: Cliff Leach, The Project Factory (March 2007)
|
|
|
|
|
|
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’.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Make do and mend: Mike Thompson, Butler Group (January 2007)
|
|
|
|
|
|
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 (January 2007)
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Curing desktop schizophrenia: Richard Hall, Avanade (September 2006)
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
All in good time: Yvonne Genovese, Gartner (July 2006)
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Planning to be agile: Mark Collins-Cope, Ratio Group (March 2006)
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Joining the SOE army: Andy Mulholland, Capgemini (May 2006)
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The best way to SOA: Jason Powell, Enterprise Architecture Solutions (Jan 2006)
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Is EAI overpriced for mid-sized companies?: Mohan Kondral, Avanade (November 05)
|
|
|
|
|
|
A recent project engagement of mine was working with a mid-sized company that needed to integrate a new ERP
implementation with existing systems whilst at the same time integrating systems acquired from a takeover. The client
had the choice of integrating the new ERP interfaces using point-to-point technology, or buying an EAI product and
using EAI tools.
The EAI solution cost five times the point-to-point implementation, which prompted the client to pose the question: what
do I get paying five times more if I use EAI? The biggest barriers to EAI in mid-sized companies are the upfront costs
and putting forward a strong cohesive justification to the CIO. This article examines point-to-point and EAI, putting EAI
benefits under the spotlight to help provide a business case. It also explores other EAI features such as flexibility as the
business adapts to change.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Escaping Jurassic Park syndrome: Alan Woodward, Charteris (April 2005)
|
|
|
|
|
|
Remember the movie Jurassic Park? If you’re running a business, the scene that is most
likely to have really horrified you is not when the T-Rex launches its attack but rather
when poor Richard Attenborough, the billionaire genius behind the dinosaur theme park,
discovers that once his plump, treacherous and debt-ridden computer expert has flown
the roost (unintentionally to end up as dinosaur dinner), nobody else in HQ knows how
to get Jurassic Park up and running again.
That, for today’s business leaders, is the true nightmare – finding that your computer
resources, on which you have expended so much effort, thought, heartache, anxiety and
hard cash, are not really your own.
It’s not much fun to discover you are totally reliant on a third party – and often an expensive, not-always-available third
party – if you have a problem with your computer system or want to enhance it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The RUPle effect: Richard Tanner-Tremaine, Dunstan Thomas Consulting (Feb 05)
|
|
|
|
|
|
The acronym RUP (Rational Unified Process) can strike fear into the hearts of even the
bravest souls in software development. Indeed, any mention of using a ‘process’ in
software development projects can make the finance department hide the chequebook,
send development managers into a panic over time wasted on over-exhaustive
documentation, and start developers thinking about the best way to word their
resignation letters.
Yet processes were designed to aid software development, so why the unease? Much of
the resistance to process stems from a natural fear of change, but the perceived extra
administration and paperwork is certainly the biggest factor – everyone just wants to get
on with their jobs. And as RUP is the godfather of process, it’s only natural that it triggers the most intense resistance.
|
|
|
|
|
|
|
|
|
|
| |
|
|
|
|
|