My first Enterprise Architecture (EA) Operating Model blog was about two key things EA has to do. So we’ve got the following two
Keeper of your current IT state and your IT standards
Drive the target state architecture for major business transformations
Now you can add whatever EA services make sense to the list above. Some popular ones are:
IT Architecture Governance - This is a popular one so I’ll dedicate a future blog or two on this one.
Architecture analysis - By this I mean things like defining a cloud strategy or networking strategy, etc… I would actually classify these projects in the bucket of major business transformations (bullet 2 above). Why do you need a cloud strategy? Hopefully to achieve some business goal. There’s got to be some productivity, flexibility, cost, … goals to look at cloud options. So EA gets engaged to see if and how cloud capabilities should be used to achieve those goals.
IT Roadmaps - This could be many things to many people so be clear what roadmaps EA helps develop. Why they are needed. And who has which role outside of EA to develop roadmaps.
Solution architecture support on minor pursuits or for project execution. Do you have the bandwidth to do this successfully? Does this distract your overall team from more important projects?
I’m sure you can think of plenty of other services EA could provide. Last time I checked, Gartner listed 30 EA services.
Not only do you have to be clear what services EA provides but also for what scope. For example, do you want your EA team to only engage in sales, new digital services and customer facing business activity as that is the most important to you? Is it every business capability that EA should cover? Are there specific business units you don’t want the central EA team to get involved in? Do I create an EA team by business segment vs being centralized?
Clarifying your services is a crucial step in building an effective EA team. What those are really depends on how your company operates and what you can afford to do (to staff). My simple advice is similar to one of my most important architecture principles. Keep it as simple as you can while meeting the most important (business requirements) EA goals.