Replay
The Question: Do IT executives ever *READ* IT management magazines?
Are these self-described "SOA" proponents, as the IT managers in 60% of fortune 500 companies claim to be, really looking at the implementation processes and lessons learned from the mistakes and successes of their peers?
I would think, based on the staggering cost of organizational restructuring, Service Management tools, not to mention the advice of consultants & contractors with my skillset..... you would think IT execs would pay VERY close attention to the major mistakes other companies make in transitioning to a service-oriented framework.
The answer, it appears, is an emphatic *NO!*
Once again, I*(It should be pointed out, considering the issue, that this SOA project is not mine, and I am not working on it. The mother conglomerate of my sweet, little adorable business is the one running this program, so they just asked me to check it out. I anticipate this will actually flop long before my company comes under the focus of this global project, but fear the fallout of those processes affected with the "mother-ship" in the interim.) I find that a company that has purchased a tool to "organize themselves," without going through a fullscale training and planning process, developing *practical* requirements and analysis for global implementation, and without *really* even understanding exactly what they have just purchased. (Yeah, like... we just bought this tool, and um.. its supposed to fix us.. we just put all the info in there.) In many cases, certainly for the specialty line business sector I work in, they haven't even begun to baseline the current infrastructure yet.
Wylie E. Coyote Syndrome: closing their eyes to the *obvious*.
The most frustrating issue, IMHO, is that this mistake is highlighted, articles headlining, advice proffered over, in every SOA/ ITIL/ Framework/ Consolidation/ IT Management whitepaper, publication and specialty consultant media available. The drive for immediate cost-savings results (let me get in a quick dig here and say how *male* of them) comes at a massive cost: employee frustration and "jadedness," lack of definable procedures, loss of major knowledge sources, in short: (usually *another*) restructuring failure.
Change for the long-term can take a long time!
True cost-savings and business benefit in SOA restructuring typically becomes tangible in years 2-3 (and gradually inclines) in a 5-7 year implementation plan.
Year 0-6 mo: Success is facilitated in the framework training and process planning for ALL upper and middle management, and the only money spent is consultant fees (and possibly, but not necessarily, travel) during the first 6 months to a year.
Month 7-18 It is out of this informed dedication and brainstorming that a practical, solid, comprehensive and ACHIEVABLE IT framework, one that supports the business model and goals, is developed. THEN the tool (or usually tools) can be considered while providing best practice training to IT techs and admins in order to ensure they will be developed in synch with the documented business case requirements/needs. The first (and possibly two) years usually carry additional headcount, because the planning is happening in tandem with the normal "business as usual" operational activities.
Year 1-2: It is not until this has been COMPLETED, the end of (at least) that first year when training and support of management and global procedures have been defined, and by that you will start to have measurable momentum in the maturity models of the first few processes - normally incident and problem. Then you start configuration (asset management) and change control (together - otherwise change isn't changing any CMDB, and configuration/asset management info goes bad without change control to keep it updated.
Years 3-5: Finish each process (or process set, such as change & config) implement, deploy, rinse and repeat with next process.
At any rate... the same mistakes are commencing here, taking off in a direction (for the asset portion, at least, saying "oh lets jump right in and take on too much without proper planning") as so many large corporations before them.
The desire to deliver FTE savings at the onset actually doubles (and possibly more, if said "removed" FTE's were single point of knowledge) the cost of transition after the first year. Its the same results every time: by year 2 the process will have become mute, then halted (with a few false starts) due to a lack of clear and/or enforceable policies and procedural change tracking. Even just the cost of BAU Operations rises, due to the extra headcount to manage the knowledge loss and employee "apathy to change" in the operational environment.
Accessing and Assessing Available Data!
The incomprehensible part, as far as I am concerned, is this: THE PROOF IS OUT THERE! All the arrows saying *Don't do THIS* and *Don't make THIS mistake* THIS way ALWAYS fails* *KEEP OUT* ... like painted wooden warning signs from cartoons.
It is is a tried and true, tested and documented fact across the board, and the fact that it keeps happening any... its sort of like taking medication to help keep your weight down but still going to McDonald's every day... sure, you might see an initial weight loss due to the ephedrine or WHATEVER pumping into your heart... In the end you are hurting the bottom line - your health. In the case of SOA shortcuts... the damage is to the health and profit of the organization.
Oh well.... its not *my* project, so I can just rant a bit and let go of it... and, hey! At least I'm in Chicago for 2 nights instead of the UK for 2 weeks!
;)
~Psyche
Are these self-described "SOA" proponents, as the IT managers in 60% of fortune 500 companies claim to be, really looking at the implementation processes and lessons learned from the mistakes and successes of their peers?
I would think, based on the staggering cost of organizational restructuring, Service Management tools, not to mention the advice of consultants & contractors with my skillset..... you would think IT execs would pay VERY close attention to the major mistakes other companies make in transitioning to a service-oriented framework.
The answer, it appears, is an emphatic *NO!*
Once again, I*(It should be pointed out, considering the issue, that this SOA project is not mine, and I am not working on it. The mother conglomerate of my sweet, little adorable business is the one running this program, so they just asked me to check it out. I anticipate this will actually flop long before my company comes under the focus of this global project, but fear the fallout of those processes affected with the "mother-ship" in the interim.) I find that a company that has purchased a tool to "organize themselves," without going through a fullscale training and planning process, developing *practical* requirements and analysis for global implementation, and without *really* even understanding exactly what they have just purchased. (Yeah, like... we just bought this tool, and um.. its supposed to fix us.. we just put all the info in there.) In many cases, certainly for the specialty line business sector I work in, they haven't even begun to baseline the current infrastructure yet.
Wylie E. Coyote Syndrome: closing their eyes to the *obvious*.
The most frustrating issue, IMHO, is that this mistake is highlighted, articles headlining, advice proffered over, in every SOA/ ITIL/ Framework/ Consolidation/ IT Management whitepaper, publication and specialty consultant media available. The drive for immediate cost-savings results (let me get in a quick dig here and say how *male* of them) comes at a massive cost: employee frustration and "jadedness," lack of definable procedures, loss of major knowledge sources, in short: (usually *another*) restructuring failure.
Change for the long-term can take a long time!
True cost-savings and business benefit in SOA restructuring typically becomes tangible in years 2-3 (and gradually inclines) in a 5-7 year implementation plan.
Year 0-6 mo: Success is facilitated in the framework training and process planning for ALL upper and middle management, and the only money spent is consultant fees (and possibly, but not necessarily, travel) during the first 6 months to a year.
Month 7-18 It is out of this informed dedication and brainstorming that a practical, solid, comprehensive and ACHIEVABLE IT framework, one that supports the business model and goals, is developed. THEN the tool (or usually tools) can be considered while providing best practice training to IT techs and admins in order to ensure they will be developed in synch with the documented business case requirements/needs. The first (and possibly two) years usually carry additional headcount, because the planning is happening in tandem with the normal "business as usual" operational activities.
Year 1-2: It is not until this has been COMPLETED, the end of (at least) that first year when training and support of management and global procedures have been defined, and by that you will start to have measurable momentum in the maturity models of the first few processes - normally incident and problem. Then you start configuration (asset management) and change control (together - otherwise change isn't changing any CMDB, and configuration/asset management info goes bad without change control to keep it updated.
Years 3-5: Finish each process (or process set, such as change & config) implement, deploy, rinse and repeat with next process.
At any rate... the same mistakes are commencing here, taking off in a direction (for the asset portion, at least, saying "oh lets jump right in and take on too much without proper planning") as so many large corporations before them.
The desire to deliver FTE savings at the onset actually doubles (and possibly more, if said "removed" FTE's were single point of knowledge) the cost of transition after the first year. Its the same results every time: by year 2 the process will have become mute, then halted (with a few false starts) due to a lack of clear and/or enforceable policies and procedural change tracking. Even just the cost of BAU Operations rises, due to the extra headcount to manage the knowledge loss and employee "apathy to change" in the operational environment.
Accessing and Assessing Available Data!
The incomprehensible part, as far as I am concerned, is this: THE PROOF IS OUT THERE! All the arrows saying *Don't do THIS* and *Don't make THIS mistake* THIS way ALWAYS fails* *KEEP OUT* ... like painted wooden warning signs from cartoons.
It is is a tried and true, tested and documented fact across the board, and the fact that it keeps happening any... its sort of like taking medication to help keep your weight down but still going to McDonald's every day... sure, you might see an initial weight loss due to the ephedrine or WHATEVER pumping into your heart... In the end you are hurting the bottom line - your health. In the case of SOA shortcuts... the damage is to the health and profit of the organization.
Oh well.... its not *my* project, so I can just rant a bit and let go of it... and, hey! At least I'm in Chicago for 2 nights instead of the UK for 2 weeks!
;)
~Psyche
posted by Psyche at 2:02 PM
7 Comments:
First of all... see other comment. ;)
Second of all... how "male" of them? well, i suppose i don't have any legs to stand on there, so i acknowledge that there is some truthiness in that statement. but, it does appear we're doomed to repeat the mistakes of history in all fields, disciplines, and general events, so this is another convincing demonstration of that foible in mankind. the problem is the belief in the silver bullet. "if i buy this, then all of this will be fixed. ain't i just a great mgr? can i be promoted now?" [somebody else can implement in the long run and clean up the mess... kinda what i've been doing for the past 12 mos (and what you had the glorious privilege to partake in for almost 2 years!)] Q: incident and problem before config/change? hmm... i need to ponder that order. of course, nothing happens with such rigid temporal linearity (there's a pretentious phrase, i'll file that one away). still thinking... all of the areas are very inter-related. can you do incident without problem? probably. just not as effective, but incident management is the real core anyway, all of the rest of this is meant to give a more orderly understanding. this is getting academic in my head, which is no good, i'm going to bookmark this conversation.
Third of all... they should hire me, i'll bet i could meet their savings targets with my usual financial wizardry (there is a small tint of chicanery, but that's the game). oh, and i'm not half-bad at this stuff. ;) i need to follow up and see if i'm going to be doing that policy workshop in october.
oh, forgot one... executives can't read. [lobotomy]
pretty colors!
Umm.. BRIO - (Though I don't know about that last comment.. not sure who left it) but STOP POSTING ANON... ! I get it that you don't want to link to me for fear you will be denounced and defrocked by the gods (little G) of political Mayhem in the UK... but when posting here? Have some BALLS! PUNK!
~Psssyche
I agree with your synopsis, why don't you manage this transition, then? You obviously understand how SOA works and doesnt. How many years have you been working with frameworks? How old are you, you don't look old enough to be a manager. When are you planning to move to Colorado, and to what area? Where have you worked and what size are these companies? We have over 3000 heavy IT users, and a department of 400 tech in North America. We are looking at service models, Fort Collins. Do you have a resume posted?
wow.
hater. :)
ok. you're bashing SOA without having ever implementing an SOA project or initiative?
I'll have you know that it can be done and can influence the bottome line in less than one year. I've done it. I've done it in a Fortune 50 company.
And no, I'm not saying that because I speak at the Executive SOA forums or because I am an executive in a SOA specialized company.
In fact, your post is most reassuring to me. It reaffirms my career choice as there are plenty of SOA bashers out there that can't find the path because they spend their time hatin. :) Then, those companies will call in my company and we'll do it right and train folks like you along the way.
I guess, in life, there are those that have done it and those that haven't.
And yes, SOADoneWrong can cost more and be another Corba nightmare, where you wake each morning to many empty promises and find years later you've wasted so much good time on a bad idea.
But, the truth is that anything done wrong costs money and most of SOAGoneWrong is at the process and service granularity level because the developers and the business don't sleep in the same bed each night.
But, SOADoneRight is immediately gratifying and rewarding.
It can be done, Grasshopper. Have some Hope.
wow.
hater. :)
ok. you're bashing SOA without having ever implementing an SOA project or initiative?
I'll have you know that it can be done and can influence the bottome line in less than one year. I've done it. I've done it in a Fortune 50 company.
And no, I'm not saying that because I speak at the Executive SOA forums or because I am an executive in a SOA specialized company.
In fact, your post is most reassuring to me. It reaffirms my career choice as there are plenty of SOA bashers out there that can't find the path because they spend their time hatin. :) Then, those companies will call in my company and we'll do it right and train folks like you along the way.
I guess, in life, there are those that have done it and those that haven't.
And yes, SOADoneWrong can cost more and be another Corba nightmare, where you wake each morning to many empty promises and find years later you've wasted so much good time on a bad idea.
But, the truth is that anything done wrong costs money and most of SOAGoneWrong is at the process and service granularity level because the developers and the business don't sleep in the same bed each night.
But, SOADoneRight is immediately gratifying and rewarding.
It can be done, Grasshopper. Have some Hope.
Post a Comment
<< Home