Architecture Consolidation

lol, Brian! We are all fools... None of us knows everything... We all know somethings about nothing... We all know nothing about somethings...
:-j

On Oct 15, 1:56 am, Brian K Seitz wrote:

> I agree. The old adage still applies. A fool with a tool is still a fool. Tools, especially I.T. tools are good for storing and calculations, but very poor at thinking.

> I started out with simple set of diagrams and a spreadsheet, when nature of the data and the problem became more than a whiteboard could contain I switched to building my own EA Portfolio management database out of MS Access and the office suite. While not as fancy as a shrinkwrap, it gets the job done fast and efficently. The nice part about using a database is the ability to create links as needed. The bad part is creating links as done as opposed to as desired. Like anything measure twice cut once :-)

> Brian K Seitz

> -----Original Message-----
> >From: Joseph George
> >Sent: Oct 14, 2008 10:54 AM
> >To: The Enterprise Architecture Network
> >Subject: Re: Architecture Consolidation

> >Benjamin,

> >Just to make it clear, my post in no way was a recommendation for any
> >particular tool. My personal opinion is that tools are very useful
> >when your "requirement becomes complex". But, tools are no good, if
> >you don't know how to do it otherwise. Tools are no good, if you don't
> >know how to use the various power features offered by your tool.

> >Just a simple example: If all I want to do is write a letter and print
> >it, do I really need MS Word (and I am not advocating this tool
> >either)? Only when my requirement becomes complex enough, that I might
> >want to use a tool. If I didn't know how to fully use MS Word, how
> >useful and advantageous might this be to me in publishing a set of
> >huge master documents, sub-linked to various other documents? I might
> >as well do it in WordPad and not do anything different, if I only
> >needed to do it once. Far simpler and cheaper!

> >I also find that overtime, many EA tools have matured significantly.
> >Having said that, I still personally prefer to use the whiteboard, and/
> >or paper & pencil for all initial work, and then transfer them online.
> >You don't need to use a sledge-hammer every time, even if you have one
> >ready and available.

> >I think the second part of your question deserves to be in its own
> >thread. I'm sure many others might be eager to contribute too.

> >Best regards,
> >Joseph

> >On Oct 03, 06:22 pm, Benjamin wrote:

> >> Joseph,

> >> Nice to see that you are using Casewise as a tool. But don't you think
> >> that tools as such when requirement becomes complex are unable to
> >> handle. I did scantily used casewise long time back - but eventually
> >> it turned out to be diagram mess.

> >> Which all framework have you used for Business, Enterprise & Data
> >> Architecture.

> >> Thanks;
> >> Benjamin

> Thank You
> Brian K Seitz

Response: Better plan meets plan A

Better plan meets plan A, Ian Marchant blog post dt 08/03/2010

Feedback in response to Ian's Blog

Post Title - Better plan meets plan A
Date Posted - 14/10/2008
Name: Joseph George
Department: Technical Solutions
Location: Havant
Comments:

He, he... Ian!

All I will say about M&S pants and underwear is Jeremy Paxman. Aunty says - (read all about it!)

"Their pants no longer provide adequate support"
http://news.bbc.co.uk/nolpda/ukfs_news/hi/newsid_7199000/7199696.stm

Paxman goes to war with M&S: 'Their pants no longer provide adequate support'
http://www.mailonsunday.co.uk/news/article-509330/Paxman-goes-war-M-S-Their-pants-longer-provide-adequate-support.html


Best regards,
Joseph

From: ian.marchant.net@scottish-southern.co.uk
Date: 20/10/2008 12:32
Subject: Re: Better plan meets plan A
To: Joseph George

Joseph

Well I still wear them!

Regards

Ian

Architecture Consolidation

Benjamin,

Just to make it clear, my post in no way was a recommendation for any particular tool. My personal opinion is that tools are very useful when your "requirement becomes complex". But, tools are no good, if you don't know how to do it otherwise. Tools are no good, if you don't know how to use the various power features offered by your tool.

Just a simple example: If all I want to do is write a letter and print it, do I really need MS Word (and I am not advocating this tool either)? Only when my requirement becomes complex enough, that I might want to use a tool. If I didn't know how to fully use MS Word, how useful and advantageous might this be to me in publishing a set of huge master documents, sub-linked to various other documents? I might as well do it in WordPad and not do anything different, if I only needed to do it once. Far simpler and cheaper!

I also find that overtime, many EA tools have matured significantly. Having said that, I still personally prefer to use the whiteboard, and/or paper & pencil for all initial work, and then transfer them online. You don't need to use a sledge-hammer every time, even if you have one ready and available.

I think the second part of your question deserves to be in its own thread. I'm sure many others might be eager to contribute too.

Best regards,
Joseph

On Oct 03, 06:22 pm, Benjamin wrote:

> Joseph,

> Nice to see that you are using Casewise as a tool. But don't you think
> that tools as such when requirement becomes complex are unable to
> handle. I did scantily used casewise long time back - but eventually
> it turned out to be diagram mess.

> Which all framework have you used for Business, Enterprise & Data
> Architecture.

> Thanks;
> Benjamin

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