Plan to fulfill the expectations of those who created or sponsored the EA group. After all, they pay the bill. So ask them what they expect.
In my experience, they would want to know how to select technology, what are the options, how to justify choices in order to minimise the cost and risk of IT. For that, they want you to come with principles and technology guidelines.
They would also want you to create a board to review solution architectures employing the principles. They would want you to provide an integrated IT view and standardise standardisation. They would like an IT roadmap and strategy. But not least they would like you to come with a reference EA. Here is a Linkedin discussion on this topic.
They do also IT strategy and roadmapping. They usually come with a few principles which pass the practice test only occasionally.
But they seldom come that with an EA reference model which is in fact the prime task of an EA without which no one should call himself an EA architect. Without the EA any solution review is subjective and roadmapping and strategy are patchy. Without it in fact, this work is performed as it was before the advent of EA.
The problem is how to do the modeling in an integrated manner. You need a framework that integrates the parts. Today's frameworks don't do that. The design should also start from the big picture, top-down, from a single page architecture cascading down to detailed domain architectures. I, personally, have seen no such architecture model till now.
Nevertheless, without the big picture of the business architecture, the technology architecture has little meaning since there is no indication of how it serves the business purpose, of how it delivers the products, how the business strategy maps to IT etc.
* your architecture models to fit in the integrated and coherent EA whole
* a generic business architecture that supports the IT architecture design
* architecture templates that helps you jump start the EA modeling.
In the first 100 days, an EA should come up with the EA framework and an one page architecture (covering both business and technology).
The EA should also plan the next steps, so that the stakeholders know what to expect.
At the six months milestone, a strategy and roadmap should be proposed.
Tasks to be accomplished in the 100 days should be
* organise EA team
* establish EA governance (including principles)
* create EA site
* propose tool, if any (for EA repository)
* liaise with stakeholders to discover expectations and sell EA
I would procure and use the cheapest EA tool available, a free open source one, or none in the beginning, because they are taking your focus away from the EA.
Tools may be a hindrance if you don't know what you are doing yet. They need training. More often than not, they still look surviving from another IT era. Besides, the internal metamodel is seldom complete or right. You have to come with your own which may be hard, costly or impossible to implement in the tool. Tools are hard to maintain, upgrade and costly to license annually, in particular when you use them little, as it is the case much too often.Archimate, for instance, is counter intuitive. It jumps directly to detail. It does not come with an intuitive framework so you can see the parts and the whole. The diagrams discourage the business audience.