As I was not in class, I will discuss something I noticed about the reading. Breaking up services into modules can be a very efficient way of doing business. However, I think it also deserves a note of caution when you automate business functions beyond the functional capabilities of the individuals doing the work. For example, if you automate a mortgage issuance, the person issuing the mortgage will think less critically about the outcome. On the other hand, a person who does not use any automation will need to do the analysis themselves and will have a better understanding of the consequences of default. I think this was part of the problem with the mortgage crises in that people thought that the models were to be trusted and did not take the personal responsibility of issuing the mortgage. We should not make the same mistake in other applications of service technology.
I think that technology is a wonderful thing, but as we have reiterated many times in class, it must be where technology and business intersect. I found it very interesting that the two top drivers for the SOA projects were "need for change" and "competitive pressures." Neither of these seem to be matching the technology to the business application. Rather, they both seem like managers of the firms are looking for quick fixes to either gain a competitive edge or because they feel they need more technology. Firms should choose the technology based on how that technology can help their business practices or improve their business practices. This seems to be the reasons behind the other drivers (collaboration, demand) because those deal with communication and computation. In sum, I'm not really sure what was the reason behind those firms choosing SOA projects, but hopefully they're doing it for the right reasons.
No comments:
Post a Comment