0

I work for a large financial company that manages money for thousands of clients. This company has very complex business processes and they operate in a very dynamic environment.

This is a fairly old company and over the years they have implemented many heterogeneous systems to automate processes within the company.

There are rumors in the company that there may be an effort to move to "a system" (re-written from scratch) that consolidates the many disparate systems in place now.

Debate has arisen that questions the value of such a move:
One side claims a single system is easier and cheaper to maintain due to greatly reduced redundancy i.e. properly factored business logic, unified data model, reusable UI components, etc.

Other side claims that the company, clients, and products (financial instruments) are too complex and too dynamic to be pigeonholed by one system. Single system will risk breakages in one component when another is modified. There is no way and no reason to consolidate business logic because it is too client- and product-specific. Time to implement changes will increase because multiple higher level components will be affected by changes to lower level components.

Question: Should the company seek to invest time and resources in creating a unified data model, factoring business logic and creating reusable code at all layers? Or should they "copy and modify" in order to speed development time, reduce the chance of regression, and reduce complexity? Is there a false dilemma presented here (i.e will there be a net change one way or the other and does one answer necessarily preclude another)? To be clear, this really a matter of long term goals and priorities, not about a specific product design. The company will never eliminate a certain amount of redundancy and it would not be desirable for them to do so.

  • 5
    This is virtually impossible to answer in such general terms and will probably get closed as "Not a real question". But I'll give you a hint: look at prior examples of "unification drives" of this magnitude. What ratio of them have succeeded? Do you think this organization is substantially smarter than average? – Kilian Foth Mar 27 '13 at 16:25
  • 2
    Agree this will probably get shut down quickly as not a real question. Unfortunate, because its very relevant. Yes the details are general but the question is specific. I'm aware there are many answers and the answers are right or wrong for very specific reasons. I am interested in hearing the experience of others. I have an opinion on this question but I'm not going to state it because if I get any good replies I will share them with my colleges. – Sam Mar 27 '13 at 16:36
  • 3
    It is the job of the people investigating whether or not to build the integrated system to decide whether or not it's feasible. It is not our job. – user16764 Mar 27 '13 at 16:40
  • I disagreed with the closure of this question and decided to reopen it. I feel that there are only a few constructive responses to such a question and any good answer requires addressing both viewpoints on the issue. – maple_shaft Mar 27 '13 at 23:27
  • @maple_shaft thank you very much! I think it is good question I hope some experienced persons contribute. I am looking forward to comparing with with viewpoints from my colleges, many of whom have differing answers to this question. – Sam Mar 27 '13 at 23:43
2

Your comparisation seems to be wrong. You are talking about:

1 big system handling everything in the business

multiple systems handling all seperate parts of the business

Now the issue with this is very simple: That one big system won't be ONE. It will very likely be a group of libraries, models, etc. which combined show like a single application maybe. But the internals won't be ONE big thing.

Now to answer:

Single system will risk breakages in one component when another is modified

If you have two systems communication together you have the same. In one application it's even easier (interfaces and integration tests) to be sure this does not happen.

Should the company seek to invest time and resources in creating a unified data model, factoring business logic and creating reusable code at all layers?

Sounds impossible. Maybe when the world stood still it might be possible to wrap it all in code. In real: That won't succeed. You will have some parts more nice than others. Which goes to your next question:

Or should they "copy and modify" in order to speed development time, reduce the chance of regression, and reduce complexity?

This is a business case which you should define per case. If you can make a million by having a copy-paste-solution next week it might be worth it. You can always refactor it further in the future.

Generally: You ask for a choice which is not the real choice. What I would expect if I read the story is: Start with this project from the start. So with the business goals in mind. Based on that see which result the current tools give. Which data they share. Then compare the options to integrate them or replace them. It's likely that replacing all is very expensive so maybe a hybrid solution is better. Keep the complex but good tools, integrate the rest. And then link the existing complex tools to the general platform.

I'm not mentioning anything about writing from scratch, enough research on that available.

  • >>>Sounds impossible. Maybe when the world stood still it might be possible to wrap it all in code. In real: That won't succeed. You will have some parts more nice than others. Do you mean that large integrated enterprise systems such as Oracle, Siebel, Epicor, Peoplesoft, and thousands of others are "impossible" and dont actually, really exist?? Is that what you are saying???? Have you ever even written code for a large ERP system?? Do you know how they are designed and built??? – Sam Mar 27 '13 at 22:37
  • 1
    Thanks for the comment, good point. In general you see in ERP scene that there will be custom development (or configuration as you could also call it) which allows the flexibility. Some ERP even have their own programming languages for it. In the case where a company does this on itself (so not as an ERP supplier but as the ERP client/user) it's not likely to develop a fits-all system. The layers of abstraction implemented in ERP are useful because lots of different enterprises use them. They cannot be tailored. – Luc Franken Mar 28 '13 at 16:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.