Technology Consolidation

Hello Ramesh,

On a recent engagement, I focussed on business consolidation and rationalisation. I noticed that the technology stacks simply followed across, and the decision making became much easier. To put it plainly, it is very difficult to choose between potatoes and onions. But, once you know what the end goal is, your decision becomes much easier.

However, many organisations are driven bottom-up rather than the top-down approach used above. In that case, your technology consolidation might end up driving business consolidation. Good luck, in that case! If you don't end up with any business consolidation, I see no business benefits from technology consolidation. IT, in this case, is a white elephant needing to be sorted on its own, or thrown out!

Technology roadmaps from vendors or suppliers are very helpful to understand the cost/benefits of remaining with any particular technology. Throw out any technology which continues to increase in annual costs, without any corresponding increase in business benefits.

Evaluate from a business perspective, whether it might be worthwhile outsourcing, if your business finds it very difficult to make IT decisions. But, the key to successful outsourcing is in having a business partnership, rather than a pure technology supplier relationship. A totally different topic... :-)

Explore the potential of the cloud... another topic on its own! But, something to be considered, if you are evaluating your options. Get a cost-analysis done, and present to your business owners, rather than to IT. This option is best suitable for startups, or organisations going through a radical overhaul. Sounds like yours might be one!

Best regards,
Joseph

_______________
Joseph George
+44 (0)78250 15480
http://uk.linkedin.com/in/josephg

On Jul 12, 11:29 pm, ramesh appat wrote:

> Hello,

> Do any of you have a process or methodology that you have used/executed in
> your company or with a client to help them arrive at technology
> consolidation? Any material pertaining to this will be helpful.

Architecture Consolidation

Dave,

One of the goals of EA is consolidation. However, not everything can be consolidated or even fit for this consideration. Some are very obvious, others not so. It is the job of the EA to identify this difference. One of the outputs from EA might be to advise on what to consolidate, what not to, and what to discard.
But, we don't take consolidation out of the EA requirements.

However, I do agree on your viewpoints.

Regards,Joseph

On Oct 3, 12:28 pm, davidcbaker
wrote:

>Joseph,

> My response was a challenge to the premise of the first question, not
> an attempt to answer it.

> "1. How can Enterprise X plan to have Architectural Consolidation so
> that all its child organization follow same Architectural framework "

> My response was to suggest that the first step should be to figure out
> if (or to what degree) "architectural consolidation" is needed at all.

> If Enterprise X, as we now know from Benjamin's latest post, has grown
> thru acquisition, is there any synergy from consolidation? Where does
> Enterprse X want to be on the continuum of integration - none? Or
> possibley full absorption of the business processe of each
> acquisition?

> These are the first Enterprise Architecure questions I would want to
> have answered before launching into any detailed EA efforts.

> Dave Baker

> On Oct 1, 4:30 am,JosephGeorge southern.co.uk> wrote:
> > dave> All these responses seem way to tactical and doomed to failure

> > I suspect you haven't gone through "All these responses"! And how does
> > your own response answer any of the initial questions asked by the OP?
> > You seem to be advising him on how to create his Enterprise
> > Architecture, and restart all his work from scratch. That would be a
> > waste of time and money, plus a wasting what they have already done.
> > They "are following certain Architecture framework and have
> > implementation using the defined architecture", which suggests to me
> > that their Enterprise Architecture is defined for each of their
> > businesses as per a standard framework.

> > PS: Quotes are not mine.

> > On Sep 30, 2:30 pm, davidcbaker
> > wrote:

> > > All these responses seem way to tactical and doomed to failure -
> > > analysis paralysis.

> > > You have to start with the business - you have to define the operating
> > > model for the Enterprise X. Check out the book "Enterprise
> > > Architecture as Strategy" from the MIT Center for Information Systems
> > > Research. They describe a four quadrant model to help businesses
> > > identify their operating model - Replicated across BUs, Diversified,
> > > Coordinated or Unifed. The two dimensions of the 2x2 are:

> > > - degree of business process standadiation across BUs
> > > - degree of process integration across BUs

> > > Working with the business to define he operating model is an excellent
> > > way to start your enterprise architecture efforts. Many architecture
> > > decisions will flow from this operating model decison, including:

> > > - amount of infrastructure sharing across BUs
> > > - amount of data sharing across BUs
> > > - amount of application sharing across BUs
> > > - EA organization - central versus distributed versus federated

> > > Don't get embroiled in framework, protocols, and standards wars - pick
> > > something that the operating model requires to be shared, and dive
> > > into that single area. Example: Perhaps the BUs only require
> > > coordination (high degeree of integration but low degree of process
> > > standardization). In that case, your EA group should focus on some
> > > sort of integration backbone for the BUs.

> > > Don't get distracted. Don't boil the ocean.

> > > Dave Baker

Architecture Consolidation

dave> All these responses seem way to tactical and doomed to failure

I suspect you haven't gone through "All these responses"! And how does your own response answer any of the initial questions asked by the OP? You seem to be advising him on how to create his Enterprise Architecture, and restart all his work from scratch. That would be a waste of time and money, plus a wasting what they have already done. They "are following certain Architecture framework and have implementation using the defined architecture", which suggests to me that their Enterprise Architecture is defined for each of their businesses as per a standard framework.

PS: Quotes are not mine.

On Sep 30, 2:30 pm, davidcbaker
wrote:

> All these responses seem way to tactical and doomed to failure -
> analysis paralysis.

> You have to start with the business - you have to define the operating
> model for the Enterprise X. Check out the book "Enterprise
> Architecture as Strategy" from the MIT Center for Information Systems
> Research. They describe a four quadrant model to help businesses
> identify their operating model - Replicated across BUs, Diversified,
> Coordinated or Unifed. The two dimensions of the 2x2 are:

> - degree of business process standadiation across BUs
> - degree of process integration across BUs

> Working with the business to define he operating model is an excellent
> way to start your enterprise architecture efforts. Many architecture
> decisions will flow from this operating model decison, including:

> - amount of infrastructure sharing across BUs
> - amount of data sharing across BUs
> - amount of application sharing across BUs
> - EA organization - central versus distributed versus federated

> Don't get embroiled in framework, protocols, and standards wars - pick
> something that the operating model requires to be shared, and dive
> into that single area. Example: Perhaps the BUs only require
> coordination (high degeree of integration but low degree of process
> standardization). In that case, your EA group should focus on some
> sort of integration backbone for the BUs.

> Don't get distracted. Don't boil the ocean.

> Dave Baker