In many organizations the need for EA shop comes and goes. Usually a new CIO wants to make a mark by invoking a transformation initiative that needs EA to plan a roadmap. Sometimes a push into new technology like cloud adoption requires some EA work to consolidate the CSPs. Starting and restarting the EA division is a reoccurring theme in the discussions.
The common understanding is that, regardless of the prescribed by the EA framework the structure and roles of EA shop, every time it is going to be different. The needs and budget are different, and Chief EA is different and has personal subjective view on how to run the shop, etc.
Here is a structure of the EA shop that I discovered after working in different agencies. It never explicitly like that. But the flows of work done do follow that structure. I call it the implicit architecture, which is unconsciously followed.
The Chief Architect is getting architecture work requests, and conducts EA marketing, develops some sort of EA Plan and makes a decision about the EA Framework to follow. Here come also different ad-hoc “hot potatoes” and “fires”.
EA PMO is getting “killed” by Agile and Kanban. The lack of planning is compensated by the mediocre budget and minimum resources.
Most EAs perform EA Development tasks: defining EA model dimensions, identifying data sources, collecting data, cleaning the data, and visualizing it. Most of work is AS-IS discovery. Some architects trying to focus on a single domain, others are cross-domains. Security domain and network architecture are the most specialized.
Some architects help IT projects, provide guardrails, talk to the vendors, work with developers. In some orgs such work is a big deal, in others not so much. It comes with the common confusion of EA with the Enterprise-wide Solution Architecture which is much easier to understand because it is tangible.
One interesting role is to support the EA Repo. It can include running the hosting VM to making the customizations or even writing custom reports. In most cases this is a developer role, but sometimes there is no explicit EA Framework, so the EA Repo Admin is the real EA job, deciding on the metamodel changes. For some reasons many people view the EA Repo as a EA itself that magically does all the data work by “automation”.
Pretty much everyone in EA shop provides EA Data Call reports from time to time. The idea of a dedicated EA Service Desk is implicit. No case management, usually.
The big deal is to hire consulting services like Gartner to do some real work. In the worst case scenario the vendor provides the roadmap with own technology to sell. The delegation of work further complicates roles and responsibilities. It also undermines the confidence in EA members competence.
The proposed EA shop structure helps to make invisible visible, and plan ahead for the future work and roles, including negotiating EA budget. The flexibility and adaptability of an EA shop does not mean there is no stable architecture behind it.