Legacy Transformation

Legacy ... or is it?

The Macmillan dictionary has two suitable/interesting definitions for legacy in this context:

• something such as a tradition or problem that exists as a result of something that happened in the past; and/or
• something that someone has achieved that continues to exists after they stop working or die.

Generally when people in the IT business refer to legacy they are referring to an older generation application or system that: should be replaced as it is can't meet current business requirements or is technically outdated (costly/difficult to maintain).  I have also heard the term legacy applied to infrastructure (networks, platforms etc) but this is less common as most technologists tend to focus on application.

What I hope to capture here are some thoughts and ideas regarding legacy (or enterprise application) transformation.  The internet is full of methodologies and approaches for achieving this, and I won't bore myself by regurgitating this, but rather capture some key ideas and challenges.

Utopia

So here it is ... the Utopian view of "legacy" transformation.

1. Build an integration layer (whichever suits your fancy ... or a combination of ... service oriented-architecture, message oriented middleware, enterprise services bus, message brokering, ...).
2. Define the business (transactional and structural) and technical services.
3. Insulate the "legacy" and deliver the service.
4. Build a few additional services, perhaps extending the legacy function.
5. Build a business process management layer (with associated workflow).
6. Orchestrate the services.
7. Link into a new shiny user interface, partner or other channel..

And if you achieve this you can renovate "behind the service" allowing you to replace legacy systems, as and when required.  The service is therefore a mediator or facade.

"Everything changes"

The biggest problem with this answer (assuming there is a question) isn't the solution but rather how people tend to go about realising it. There is a fundamental mindset that the past is wrong and that the people that built those solutions were naive or bad at what they did; and that we now know the answer and will build the future.  Brilliant! or not, as I am fairly sure (having spoken to several senior engineers) that they felt similar in the past.

If there is one thing that I have learnt that is more important that all other lessons, it is that everything changes.  An application implemented today is soon relegated to legacy.  A methodology that is guaranteed to improve quality/productivity/value will be modified or replaced in the future.

Therefore, smart organisations are those organisations that focus on building a core capability that enables them to adapt to change.  Subsequently these organisations will manage those assets that are important irrespective of the underlying technology.

Service Imperfect

Defining perfect business services is as much an art as it is a science.  Service granularity is a topic that promotes a lot of intellectual debate ... so I won't get into it.  However, irrespective of what services you specify you soon find yourself in the very real problem of realising/building those services.

Therefore a magic (the art) middle-ground exists between what business want and need and what you can deliver.   Can the enterprise applications deliver the function that matches that service or does the service need to be "course" and meet the availability of function?

Do you spend a lot of money renovating the enterprise applications to meet your requirements or do you deliver what is available?

Can you break into the middle of a legacy workflow or do you have to trigger the start of it and accept the outcome?  Can you monitor/report on the status of the legacy workflow?

The mythical enteprise business process layer

Looks phenomenal on a layered application architecture diagram.  However this is really difficult (read expensive) to achieve.    One of the big challenges relates somewhat to my ramblings on services.  The reason for this is that many legacy and/or enterprise applications have workflow and business process included within the application.  Unpicking this is very costly and seldom, if ever, delivers the business value need to fund the project.

So assuming that you have to deal with multiple process/workflow/bpm engines you need to figure out if it makes sense to promote one of these to enterprise level.   If so, how will you manage transactions and will you need to "integrate on the desktop" using portal technology?  How will you monitor status across these engines especially with long-running transactions?

A possible solution

Ultimately if you protect what is important and externalise as much of this as possible you will find yourself in a good place.  This includes data/information, business rules and calculations.

Solution components and patterns that help address this include canconical message models, meta data management, master data management, rules and calculation components/engines.

However, achieving this level of enterprise-wide harmonisation (even for a single component) is expensive and few achieve it.  Rather applying domain architecture principles and tackling those areas that you can control is infinitely more achievable. 

Applied this means determining which area you control (start, stop, change direction) when it comes to designing and implementing a solution and then focussing on that.  This could be a vertical (department for example) or a horizontal within the enterprise.   

Now the big downfall is that enterprises have to contend with multiple standards, formats etc.  However, because this is a known it means that it can be managed by design.  Bridging/translating data formats (for example) becomes a core capability and by default the organisation learns to manage change.  Interfacing between partners and applications falls into a similar bucket ... you get the idea.

The big "gotcha" is investment - it does mean that the investment case needs to be realised on a smaller business scope; but the reality is probably closer to this than those business cases that have an enterprise wide adoption assumption.

So what does the architecture look like?

Well this is where it gets really fun.  If you are focussing on the management of change and your response to it, then you can begin to imagine what this looks like.    Think domains.  Think service delivered and contracts.  Think measurement and reporting.  Think blackbox and component paradigms.

Ideally select a domain where you can slice deep into the organisation whilst keep it as narrow as possible.  This will allow you to touch on as many solution elements and layers and therefore tackle risk sooner rather than later.  However, take a horizontal domain or component domain works as well.

But more on this later.