How do we start to realise the potential of an SOA style architecture? A great start would be modernisation of existing legacy systems, to expose functionality that can be potentially consumed in composite applications or mashups.
Because of the large capital investment in legacy systems, it is preferable to
find a satisfactory migration path from the legacy system environment to modern
SOA (Service Oriented Architecture) environments.
Somewhat contentious, would be to decommission existing systems in favour of a SaaS service or to use a packaged COTS application. The following discussion is for when this is not an option.
Legacy applications need to be modernised in a
fashion that automates the majority of “eyeball” type work. Current
best practices suggest a Model Driven Development approach with appropriate
I’ve identified three high level options for migration of legacy applications into a SOA environment, with some identified advantages/disadvantages.
Option 1 – do-nothing
Staff retention – people no longer wish to work on legacy applications
– bad career choice for future
Attraction of new talented staff – old generation technology, staff want
to work on Projects utilising modern development tools and methodology
High cost to change to adapt to new business processes
Expensive runtime licenses in addition to licensing for new environments
Unable to meet business expectations to respond in a timely manner
Difficult to integrate with other systems, very rigid in purpose
Large sites, have many generation of technolog needing specialist
knowledge of each generation
Unable to change platform of choice for middleware and databases
Option 2 – manual
Labour intensive due to the need to eyeball code and document
specifications for new systems
Open to error, security problems and inconsistent coding
– Offshore code factories, whilst reducing some short term costs do not
solve architectural issues and still retain the other problems associated with
Often insufficient budget to achieve the targeted strategic architecture
for the business
Unable to reengineer, without a complete rewrite – often the original
analysts and designers are no longer available to assist
Timeframe are usually long >1 year for projects, resulting in a
freeze of all change and hence responsiveness to business
Option 3 – tools
Reduces 85% of the eyeball work required
Reduction in timeframe target. In general, it is expected to achieve, a
quarter of the timeframe for manual methods
Through using a model driven approach ability to refactor components for
Ability to introduce new elements such as Web Services to comply with
the strategic architecture
Reduce overall project costs and the number of staff required to
As the majority of code is generated, it ensures code conforms to Best
Practices and Design patterns. Thus reduces coding errors.
Improves security, through consistent code generation of high quality
code (no shortcuts taken by developers to meet timeframes)
If appropriate tools are selected, they can also be used for new
Improves dramatically the ability of IT to help facilitate changes in
business processes through the use modern paradigms such as SOA.