Questions

ID Risk factors in migrating from closed arch to SOA?

Tags:
+
0 Votes
Locked

ID Risk factors in migrating from closed arch to SOA?

gallen6
My organization is in the process of looking at migrating from closed modeling and simulation architectures to a SOA based architecture. This means bringing legacy systems (some 20+ years old)into SOA. Given that situation what are the significant risk factors underlying this migration effort?
  • +
    0 Votes
    Tony Hopkinson

    insignificant ones would be hair colour, and accent..
    Seriously a job this big, I doubt there is an insignificant factor.

    Identify a useful piece of your system, decouple it (if necessary). Knock something together to consume the request and respond. Insert it into the architecture.

    Pick something meaty but not too closely coupled, see what you learn.

    The risk over and above under resourcing, is not identifying 'application'. Think of it like the 'old' mainframe batch file processing days.

    You passed a file or three to a process, it ran a sequence of file processing operations chained to gther by intermediate files and the last one (given everthing worked) gave you the result. SOA can have better granularity, a disk (or maybe even tape back then ) isn't the only thing you can pass.
    But first you decouple, then you do SOA, it won't work the other way round.

    That's where most SOA initiatives fall down, the choose an inappropriate target, and then mestasize over the entire system, in a vain effort not to look like they've screwed up big style. So you end up with one 'application' hooked into your process in tens of places, and no usful clues who wanted to do what with what when it was meade, never mind executed.

    +
    0 Votes
    gallen6

    We are setting up a pilot project where two M&S architectures will access a service that provides weather data. Normally the weather capapbility would reside in both architectures and draw on the data internally with no guarentee that the weather would be the same in both cases.

    Your point of the need for a service single point of entry in to the enterprise is well taken - tks

  • +
    0 Votes
    Tony Hopkinson

    insignificant ones would be hair colour, and accent..
    Seriously a job this big, I doubt there is an insignificant factor.

    Identify a useful piece of your system, decouple it (if necessary). Knock something together to consume the request and respond. Insert it into the architecture.

    Pick something meaty but not too closely coupled, see what you learn.

    The risk over and above under resourcing, is not identifying 'application'. Think of it like the 'old' mainframe batch file processing days.

    You passed a file or three to a process, it ran a sequence of file processing operations chained to gther by intermediate files and the last one (given everthing worked) gave you the result. SOA can have better granularity, a disk (or maybe even tape back then ) isn't the only thing you can pass.
    But first you decouple, then you do SOA, it won't work the other way round.

    That's where most SOA initiatives fall down, the choose an inappropriate target, and then mestasize over the entire system, in a vain effort not to look like they've screwed up big style. So you end up with one 'application' hooked into your process in tens of places, and no usful clues who wanted to do what with what when it was meade, never mind executed.

    +
    0 Votes
    gallen6

    We are setting up a pilot project where two M&S architectures will access a service that provides weather data. Normally the weather capapbility would reside in both architectures and draw on the data internally with no guarentee that the weather would be the same in both cases.

    Your point of the need for a service single point of entry in to the enterprise is well taken - tks