|
|
|
|
|
| Management Briefings
|
|
|
|
|
|
When coding is not enough: John Colley, (ISC)2 (April 2010)
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Is SOA meaningless?: Graham Berrisford, Avancier (January 2010)
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Testing times: Richard Terry, Sogeti UK (July 2009)
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
On a needs to know basis: Shantanu Bhattacharya, Siemens (May 2009)
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The pillars of agile development: Jon Collins, FreeForm Dynamics (March 2009)
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Challenging the sacred cows: John Good, Serco Consulting (January 2009)
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Application security: the final frontier: Fran Howarth, Quocirca (October 2008)
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
| |
|
|
|
|
|