Starting up with EA

Hi all!
I work for a company where we have agreed on starting up initial work on EA. Our problem is that we don´t have support from senior management yet and it looks like gaining their support will take a lot of selling effort and quite a bit of time.
In the meantime we are planning to implement a process and framework for EA and the reasons for this are mainly two. The first is that we need to learn how to work with EA on a broader basis so we are ready when we get a GO from senior management. The second is that we believe that working with EA will eventually give us more real world arguments that will help us in selling EA to senior management.
To get a jump start we´re thinking of just grabbing TOGAF and start out with that, without doing any evaluation at all. The basis for that descision is that we think we need to get started more than we need to do it exactly right.
Any comments on our approach?

Popular White Paper On This Topic

Hi
Just doing something to go through the learning experience is a very good
way to get started and to learn. TOGAF is at this moment is the most widely
accepted framework and the buzz of the moment. I would however strongly
recommend that you focus more on Zachman in the early stages. TOGAF is more
complex and more difficult to implement. Zachman is an excellent thought
framework without making it too complex and can be mapped back to TOGAF. It
is important to keep in mind that the ultimate objective should be something
like TOGAF.
Good Luck
Francois

Hi.
I would strongly recommend that you get the Senior management buy-in before
you start spending time, effort and money in this direction due to mutliple
reasons.
Firstly, the project you are undertaking is extremely strategic in nature
and hence it is imperative to take the top-down approach rather than
bottom-up here. The Senior management has to take the decision whether they
want to go down the EA road and agree to support it in all aspects
end-to-end. Your first statement "I work for a company where we have agreed
on starting up initial work on EA" has confued me a little bit. Immediately
after this sentence you mention that the Senior management's buy-in is not
there and that it might take a lot of time to get that. In that case, who is
the 'We' that you refer to in the first statement? What sort of power and
influence can they excercise in your organization?
Secondly, if your is a global organization, it is important for you to speak
to Senior management before oing ahead on your own because it could be that
a similar effort is already underway by some team in another global location
of your organization. Maybe there are smaller project being executed
elsewhere, the effort of which can be combined towards acheiving the final
goal of EA. Senior management always has the top view of activites going on
and hence they will be able to guide you at the very early stages such that
it will save you a lot of effort.
Last but not the least, getting a buy-in from the management will help you
in justifying the effort and time that you are spending in EA related work.
If they appreciate the high priority of EA and also that you can play a
crucial role in implementing it in your organization, they will ensure that
you are not unnecessarily burdened with other BAU tasks or other operational
roles so that you can concentrate on this project.
In my limited experience, the success rate of projects (irrespective of
their potential) initiated without Senior management's buy-in, has been very
low (~ 10%) and the ones that have been sucessful have typically been the
low-budget, low-impact sort of projects, which EA certainly is not.
Responses are more than welcome,
Cheers
Ashish

TOGAF and ZF are chalk and cheese.
You can make either as simple or as complex as you like.
TOGAF has the advantage of being free to read and use for your own purposes.

TOGAF has the disadvantage of being written by a collective.
I suspect ZF users are more likely to disappear from view up an ivory tower.
Whatever framework you want to use, you need to get on a proper training
course it.
.
I try to explain levels and facets of architecture description at
http://avancier.co.uk <http://avancier.co.uk//> .
My guide to TOGAF is accessible there to those who follow conditions of use.

My guide to scoping deliverables, which airs limitations of the ZF, is not
accessible.

I was in same situation few years ago. I've learned 3 lessons:
1- Start from the problem and provide fast solutions to the most urgent problems regardless how technically-good is it. This will raise your value and credibility with senior management.
2- Understand your business well so that you know it better than the operational people. You are supposed to provide them solutions of thier problems and talking in thier langauge. They don't care about EA or any technical issue.
3- Set your goal precisely and be business oriented and pragmatic.
4- Consider the formal EA methode as a tool rather than a goal and be prepared to make your own framework if you need. So study the EA frameworks well but tailor your own own.
At last, don't put the cart before the horse.
Thanks
Ahmad Khalafallah

Do a google search on these three documents. They will help you get your own head around the task and help you set expectations with the business leadership. "7 Essential Elements of EA" by David Baker, "Four Stages of EA" by Galen Gruman, and the Infosys' EA Survey titled "Enterprise Architecture is Maturing" The bottom line is you are going to need a good enterprise suite of tools to support your efforts eventually (I represent one for large enterprises) but there are many things you need in place before you take that step.
In the mean time you might want to search for another document titled "IT Architecture Capability Maturity Model" or the NASCIO "Enterprise Architecture Maturity Model" These document could help you with the step by step approach to building an EA practice.