Money Saving Tip #1
The only beneficiaries of creating a model of the as-is enterprise architecture are the consultants you hired to create it! Please note, I'm an enterprise architecture consultant.
I was on a sales call the other day and we were chatting with our prospective customer about IT strategy and they wanted some help defining and describing their strategy and lots of help with enterprise architecture. When I asked them where they were in the process, they replied that they were just starting to document the as-is architecture and were following the classic path of as-is, to-be, gap-analysis, etc. and wanted to know how we could help them out. I replied that they needed to choose one of two answers, either the consultant-as-staff-augmentation or the consultant-as-adviser model. When asked what the difference was, I replied "Several hundred thousand dollars."
Naturally, they wanted the less expensive option and I stated if that were really what they were interested in, why do they want to start the process with the as-is architecture? Instead, they could save a truckload of money by starting with what everybody wants to know, the to-be architecture.
You could have heard a pin drop if if were not for the furious typing of the sales rep sending me some rather unflattering IMs questioning my sanity, legitimacy, etc.
"You mean we should not take a comprehensive approach?" asked the CIO.
"Let me put it this way," I replied, "when you go on vacation do you start with a complete survey, inventory and appraisal of your house?"
"Of course not," replied the CIO, "but you didn't answer my question."
"Well, you actually asked 3 questions," I countered. "First, start with your target and then work backwards. Second, only go into as much detail as necessary to make substantial progress. Third, this is unlike most other approaches but unlike others, it won't have the same high chance of failure."
"Thank-you very much, you have given us a lot to think about," was his response.
Much to the shock and surprise of the sales rep, we have been invited to attend some in-depth discussions with several other team members and stakeholders. I anticipate having a discussion about tools, approaches, etc. that will look a lot like this thread in the Enterprise Architecture Network.
Once again, that money saving tip is: "The only beneficiaries of creating a model of the as-is enterprise architecture are the consultants you hired to create it!"

1 comment:
Interesting point. But I'm not sure which is the best approach.
The point is related to what kind of "to be" is better:
1- and "ideal to-be" not conditioned from the "as is" but surely unaffordable.
2 a realistic "to-be", achievable in a 2-3 years roadmap
Sometimes the customers consider the "ideal to-be" has no value for them.
To create an "achievable to-be" you need to consider the "as-is" during the definition of the to be.
I think there are to ways:
1- "as-is"-> "realistic to-be"-> "achievable gap"
2- "ideal to-be"-> "as-is" ->"unaffordable gap" -> "realistic to-be"-> "achievable gap"
So in general I think that the "as-is" is a good point to start.
Salutacions / Saludos / Kind Regards
Post a Comment