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
> > 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
No comments:
Post a Comment