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 and integrated IT view and 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 seldom pass the practice test.
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 EA 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 seldom do that, if any. 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. As such, there is a small audience for the IT architecture alone. Not to mention that it is patchy failing to cover many business domains and end to end processes, which normally would be described by a business architecture.To realise a proper EA, I use own framework. I also found that most EA frameworks look like EA development processes, which describe common and known good practices, rather than coming with frameworks that enable
* 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, they look like coming from another IT era more often than not. 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 annually license, in particular when you use them little, as it is the case much too often.