We recently formed a small enterprise architecture team of three people in IT. One oversees infrastructure, another oversees data, and the third oversees applications and integrations. We have three vertical teams in IT: Infrastructure, Data, and Integrations. Now, how can we best align these three verticals with the EA team so that they will follow EA principles and practices? Also, what kind of artifacts will make this process efficient? 

1. the EA needs to create a strategy for their domain. This needs to link to the CTO strategy (if one exists) and also the company strategy. This needs to provide material, practical, relevant guidance to the architecture community.
2. There need to be actual principles written that link to the domain strategy
3. Big design decisions and technology selections need to align with the strategy and be underpinned by their own process, such as a (templated) decision document and tech selection doc
4. EA's need to be practical and approachable to gain the respect of the designers/architects rather than behaving like untouchable high priests of technology (or else they will be ignored)

This is all about setting expectations from the outset. 

You need a full Architectural Topology and associated Models for Infra, Data, Apps, EUC & Integrations, which align to the IT Strategy, to ultimately support the Business Strategy.  Keeping an eye on the reason that IT exists – for the benefit and support of users / the business – should remain prevalent in the mind, to help give / keep focus. 

Having value-add metrics, measurements, KPIs and reporting is imperative, otherwise you can’t measure what you have [or haven’t] achieved…  ITSM should provide a Governance Service to IT, defining, managing, implementing, monitoring and reporting on Policy and Compliance, for any new change and also, and more importantly, BaU. 

I would say at a minimum, you’ll need [using ITIL4 as the framework] the following Governance in place, to ensure smooth running of IT, insomuch that everything interacts and works seamlessly with each other:

Incident Management
Change Enablement
Service Request Management
Problem Management
Compliance Management
Demand Management – managing the resource is vital
Service Design & Transition
Event Management
Deployment Management
CI / CD – if you have developers

Any team’s Roadmap should link with / use the EA, to ensure that work planned and undertaken actually meets the requirements of the Business.

Don’t forget that BaU is more important than anything, and this should take precedence – keeping the lights on while change is happening can be difficult to juggle and manage.  However, unless you have a solid base, adding Services that are fit for proper Support & Maintenance, just creates chaos.

Our method is to simply require the other teams to include and engage with our architects for all new projects.  This way they can map out any new architecture as needed as well as vet the technical plans to ensure everything will work within our existing architecture or point out the costs associated with architecture changes.
We develop Reference Architectures (RA) for our engineering/implementation teams to use going forward in support and enhancement activities.  Those RA's can be used long-term to aide in future projects when considering new technologies etc. and are helpful for new staff.  
Ideally the other teams require a sign-off from the architecture team before moving forward on any new implementation/project which impacts company architecture.