Butterfly Effect - IT and SOA

[prateek]

What's that? Are we sure we are on SCN?

Yes is the answer. Butterfly Effect is a phrase which demonstrates that a small change in the initial condition could change the course and outcome of a scenario. Literally speaking, it meant that a ripples created by one butterfly could generate certain atmospheric changes that could in turn even change the direction of a tornado. (I am sure many of you must have watched the movie series too.)

Ok. Good. So? What does that definition doing here on SCN?

IT world doesn't behave much in a dissimilar way. For your various projects, how many times have you found yourself saying: "We should have thought about this earlier" or "Why didn't you inform me when I was beginning the assignment" or "Lets not include this, client won't come to know" 🙂

Well, being in IT, I guess most of us must have faced similar situations at some point of time. And then we start following Oscar Wilde - "It's not whether you win or lose, it's how you place the blame." Taking a sharp turn towards the real time projects, let us see what are the factors that I feel had avoided this Butterfly Effect to turn out to be positive.

• This requirement will be handled later. (And later we find that to incorporate it, we have to actually modify the basic design of our landscape)
• This shouldn't be part of this phase of project. (This point has two sides. If the requirement actually doesn't involve the implementation of business process, then it is quite logical to move it to other phase of projects. However, it is very important to have an initial understanding of the dependencies across the phases. It should be ensured that when we move some functionalities out of scope, then adding it in later point of time doesn't prove out to be a nightmare)
• Do you really think client will pay for this? (Even if they don't, we have to make sure that if out of blue they are ready to loosen their pockets, we are ready to welcome them)
• Complete it for the time being, we will add it later. (Believe me, that Later won't ever come.)
• This client has troubled us a lot. Let's design it poorly and trouble his future. (Well, no comments!)

Talking in terms of SOA solutions, what could be mistakes made in childhood stage of planning that could ruin or at least negatively influence the future of projects:

• As our SOA design gets complicated, we would start adding the Governance strategies. (I included this as the first point as in my opinion Governance should begin with Day One as soon as the SOA thought is seeded in the mind. If missed initially, adding a new strategy won't be impossible, but definitely rework to some extent. Eventually, it could cause costly maintenance and delays)
• I know a company which has implemented SOA successfully. The Standards used by them were perfect. (Don't follow other blindly. SOA does not have one specific standard. Therefore standards utilized by one organization may not be that relevant to your organization. Choose them as it suits to your Business Process)
• Let's invest. Design all the processes as enterprise service and we are through. (This initial thought could cost you heavily in future if later it is discovered that few of these service would never or occasionally be reused. The efforts you applied for designing and developing service for a process turns out to be far more than its worth)
• SAP is already providing many enterprise services. Let's implement them one by one. (It is possible that the services directly suits your needs but instead of directly absorbing all, why not check your landscape about the most widely utilized process and mark it as the first milestone to reached)
• Everything should pass through PI. (Although PI is the long term strategic integration solution for you, don't make everything mandatory to be passed through PI. As mentioned in the first point, there could be processes that actually would not be reusable enough or could be made obsolete in near future. If they perform well without a middleware, then they shouldn't be migrated. PI as an ESB provides the loose coupling across the landscape but if a system is happy enough being tightly coupled, let it live its life on its own)

I agree that few of the things could be very much debatable and there are several factors affecting the decisions e.g. your influence level in the project or the available time and resources. However, the points mentioned should not be completely ignored. I am sure you readers must have encountered the same problem with various faces.