Can anyone share their Enterprise Architecture Journey? The ignition steps, the pitfalls, the roles and processes that are needed to implement it?

Often it's an organisation's scale and complexity that drives a need to start using models to articulate messages consistently and with simplicity and clarity: capability models, application portfolios, application and infrastructure models, roadmaps.  If these hit the mark with the executive team, that's the point of ignition - and agreement that principles are required, with governance to apply them.
One can create such models in isolation initially: showing the relationship between them from the beginning is important, even if you're just using Visio and Excel.  The relationships will lead to defining the processes, where EA fits into the existing operating model and where enhancements or changes are needed.

First get clarity on what EA means to your organization, and secondly be specific in the role and responsibility. Part of this is to ensure Enterprise Architecture scope, role of Solution Architecture , a grid that shows the deliverables - strategic vs tactical, ownership of Technology Governance.

Most importantly, get feedback from the CIO/CTO/VPs within IT and Business Stakeholders what value means to them and their expectations of EA.

EA will take ownership for the Technology Principles, Plan, Policy , engagement model in the Strategy planning, recommendations etc. 

Keeping it simple, it started with recognizing that we needed an Enterprise Architecture shop. There were too many tactical point solution decisions being made with no one responsible for keeping "the big picture" in mind, creating technology stack policies and point-in-time standards, etc.

After that, we started building out the team and looking for a leader, not just an "alpha nerd." Someone that could forge a bunch of high-performing domain architects into a cohesive team focused on transforming business capabilities through technology, but not just for technology's sake.

The team started, of course, in "firefighting" mode as primarily a "commando / tiger" team functioning as the CIO's personal make-this-problem-go-away capability, but spent maybe 10% of its capacity on deciding things like modeling itself as an Internal Management Consultancy, creating and socializing the "tag line" of "Yes, but in alignment with the strategic technology stack vision," to avoid being "The House of No," and creating a DRAFT Charter with a diagram of how the EA team fit in with the Strategic Business Plan, Strategic IT Plan, technology stack policies to be created, architectural review function closely tied to the Project Management Office's new Intake Process, etc.

It's been 90% tactical and 10% strategic this first year, but it's slowly shifting towards 80% tactical and 20% strategic. We figure it'll take about three years total to get out of mainly "firefighting."

This is an excellent resource to get started.  Enterprise Architecture on a Page (eaonapage.com)

Prior Business for me:
While you can engage Business Management and Executives their attention span is short.  So once you have sold the Business Case, you get the SME's engaged, you start a long process where you analyse the SWOT.   SME's get all happy that you do not want to get rid of processes that are working, as do Business Management.   Executives may start saying 'How long will this take'   First Warning.    Executives line in an area where all successes have their name on it.

The first business proposal has all of the successes that are in place, and the shortfalls of other pieces.   The Core systems are well known and the current systems even the faulty ones have processes that limit the dangers. 

Suddenly there are big ticket items for things most users believe are running well, even if one business group spends an inordinate time resolving issues once a month or so.   
then the business reality of evaluating options for replacement, configuring the system, running in parallel with the SMEs for the business fully engaged with the new system.  Then comes the message that to not have customer impact during the changeover, will require a fair bit of overtime to change over with minimum impact!
The execs or board start getting twitchie, Tech managers start talking of minimising the changes. 

The final signal might be a feeding a cranky app hand built to identify and resolve issues that breaks , or it might be an internal audit result for an application that everyone thinks is bedded down and behaving.   Techs and SME's are no longer believed or so it seems.

Success has many fathers, Failure is an orphan, but exposing a managed mess in the business requires a witch/wizard to be sacrificed.