transforming legacy into soa based environment

From legacy to SOA environment A short case study on transforming fairly complex legacy system to a modern, SOA

based environment

4. iSAQB Architekturtage, 14.-16. Oktober 2014

Davor Čengija, CROZ, Croatia, Senior Consultant

Gerd Sauermann, ARS, Key Account Manager

© ARS Computer und Consulting GmbH 2014 2

ARS Kurzprofil

Mittelständisches Systemhaus, gegründet 1992

60 Mitarbeiter

Schwerpunkte:

Java/Web Anwendungsentwicklung

Beratung / Schulungen:

Software Architektur » Zertifiziert nach den Standards des iSAQB

Einführung von Entwicklungswerkzeugen

Unsere Kunden

U.a. im öffentlichen Bereich und Industriekunden

Intensive Zusammenarbeit mit CROZ im

ServicebereichGarmisch-Partenkirchen

MünchenWartenberg

Dresden


Background

Croatia joined European Union in 2013.

But the accession process

is not only political.

There‘s a quite complex

technical component, as well.


Take the Taxation and Customs business

Large amount of information has to be exchanged

between the member states Import, export, transit, tariffs, VAT etc.

Statistics, common services, meta data

Everything goes through

Common Communication

Network and Common

System Interface (CCN/CSI)

We needed to connect the state-specific IT system to EU


IT’s 2007 and we started a project…

Adapt and connect the existing customs system to EU 20+ years old IT system based mainly on IBM mainframe (so: CICS, PL/I, 3270 green screens

and so on)

Regularly updated

Working very well for one country needs

It has to be adapted to cover New legislative

New processes

New data

And of course we had to Protect the prior investment

Re-use as much as possible

Adapt it “just a little bit”


Project setup

State agency for IT Supports customs, taxes, elections, …

Excellent domain knowledge

40 years of experience

Running system which really works

CROZ Extensive knowledge in system integration and transformation

Great programming skills from various domains

Government, banking, telco…

Leaders in methodology (SOA, RUP, etc.)

Several smaller subcontractors To cover independent tasks


It sounded really easy

We already have more or less everything in place All customs processes are already implemented

Smaller adjustments will be needed

We’ll re-use the existing applications and adapt them There are various converters for old applications

You can always deploy the old apps as the web services

Green screens can be converted to HTML

We have enough time The launch date is well known

Everything goes into production at the same time


Long story short

Yes, we did transform the old legacy system into a

modern, SOA based environment It works without problems from day one

But it was far from easy It took us 25.000 man-days (that’s 100 man years) from 2007 to 2013

Even more now

We discovered a number of antipatterns I.e. Looking at the technology as the investment to protect is wrong; protect the domain

knowledge

But also we have learned a lot I.e. Iterative deliveries should really be organized around delivery dates, not feature sets


So what exactly we discovered?

Antipattern #1: The existing code base is the investment you should protect

The value of the code and running applications diminishes through time

New programming languages and runtime environments make implementation faster and easier

Lesser and lesser programming effort is needed for the same results

Domain knowledge and data are the investments you should protect!

Their value increases over time

Document the domain knowledge and data structures, not the source code



Antipattern #2: If there’s a technology for something, you should use it

Goes along with Antipattern #1

Usually related to “convert to web services” technologies

Legacy systems are not designed with services in mind

We ended up with 200+ web services for the first business process only!

Just don’t do it! Design the web services in a proper way

“Service lakmus test” is a good start (see Service Oriented Modelling and Architecture)

Maybe call the old apps through some connector when needed

But think twice before you start



Antipattern #3: Each business domain should have a

separate, independent project Business domains (export, import, transit etc.) are fairly independent, so the implementation

projects and project teams can be independent too

But those overleap each other by 60-70%

Each domain communicates with the external entities (business, government, EU)

Each domain needs to control access rights

Each domain needs logging and auditing and so on

Well, it shouldn’t. It’s a one big system

Business domains are just specific processes of that system

Introduce project portfolio management



Antipattern #4: Establish only the projects with visible

business outcomes; ignore the projects with tech-only

activities Result of the Antipattern #3

“The technology will settle down by itself!”

It won’t

But the tech-only activities are equally important! Start from the very beginning

Assign the sponsorship to the highest ranking stakeholder


But we managed to get back on track

Event driven approach was that quantum leap we were

looking for Stop thinking about the end users starting processes, the process is started by an external

event

Allow the information to flow, and design the processes around that principle

Introduce business process management (BPM) as the design concept

End users should join the processes when appropriate

Thanks to BPM this was fairly easy to implement



Iterative approach is a must It’s a common sense, of course

Even EU requires regular checkpoints

Don’t define the deliveries based on features

For a large project portfolio, planning the features to be delivered at the same time is nearly impossible

Somebody is always late and that holds down the complete portfolio

Define the deliveries on a fixed date (e.g. once a month)

Whatever is finished goes into the delivery (to the test system)

Organize the development to have small enough chunks of features ready for delivery

And you’re never late



Adopt the Agile software development principles To have clear vision of the project status by all members of the project

Yes, Scrum really helps

RUP is too slow and restrictive

Waterfall is a self-signed death sentence

Monthly deliveries are always on time

Weekly portfolio coordinations navigate the project to the right direction

Daily dev. team meetings provide instant status insight



Involve the end users from the very beginning They’ll need extensive education

Mostly due to old habits

But it’s a small price to pay

Because the new system will do (almost) the same things, but in a different way

So to avoid surprises



Find the common ground and build on top of it Every business domain has the same non-functional requirements

Security, Identity mgmt.

Logging, auditing

Archive

Common services calls from external systems

Isolate those into a Common Infrastructure Layer (CIL) Expose those features as Web services

Strictly define the rules of the game (i.e. how to access those services)

Adhere to those rules!

Establish it as an equally important project as the

business ones It was hard to explain why is it so important

But you have to, CIL won’t happen by itself!


So, we’ve transformed this…


… into this


Benefits of the new architecture

Better project portfolio mgmt. It is one big system, not a set of independent applications each covering specific business

needs

Much faster time to market (30-50%) Because a number of functionalities is already in the Common Infrastructure Layer

And because we deliver what’s really needed

Benefits of the end users involvement and frequent planning

The new system is really extensible Business-related features are independent from the tech-ones

Upgrades on the Common Infrastructure Layer automatically promote to all business projects

Changes in the business domains don’t affect the rest of the system

Much better system monitoring Unified logging and auditing, resource usage, performance tuning

Much easier forensics


And along the way we have learned

How to manage a multi-year project How to eat an elephant? One bite at a time.

How to perform the Big Bang Roll-out on time It simply was Yet Another Monthly Delivery

First public test was much more stressful than the production date

Agile project portfolio mgmt. How to manage 10+ parallel projects

With 50+ involved people at the peak time

Number of new principles and technologies Event driven architecture

Business process management

Web service decomposition

System optimization

Inter-disciplinary coordination

Davor Čengija

@davorcengija, [email protected]

CROZ d.o.o., [email protected]

Lean/Agile/Scrum consulting

Custom SW development

System integration, SOA, EntArch

Cross-brand IBM SW and Mainframe

Education

200+ employees

Croatia, Serbia, Slovenia, UK, Germany

Banking, Insurance, Telco, Government

International projects

www.croz.net


Contact information

Contact

ARS Computer und Consulting GmbH

Ridlerstraße 55

80339 München

http://www.ars.de

CROZ d.o.o.

Lastovska 23

10000 Zagreb

Croatia

http://www.croz.net

http://www.ars.de/

http://www.croz.net/

transforming legacy into soa based environment

Technology

old legacy system

existing customs system

system integration

years old

domain knowledgebut

complex legacy system

old apps

eueach domain needs