***Republished courtesy of Suren Pillay. Orginally published here: https://www.linkedin.com/pulse/enterprise-architecture-dead-long-live-agile-ea-suren-pillay/

*** Join Suren at Future Enterprise Systems Africa 2019, 16-17 October, Focus Rooms Sunninghill, Johannesburg (www.fes-africa.com)

There are two kinds of Enterprise Architects - those who understand binary and those who don't. Smarter people than me call this bimodal.

As organisations move from waterfall delivery and inside out thinking into the perfect storm of Digital, Agile, DevOps, Data, Client Centricity and Innovation the difference between the two kinds becomes ever more significant.

The first kind of EA tends to live high above the mucky muck, in a castle made of clouds poring over highly abstract capability models and spreadsheets achieving limited value. From this perch, they trouble deaf heaven with their bootless cries about “proving the value of EA”. 

Despite having an enterprise-wide sight or scope, very often they lack the basic insights to make effective decisions. Ironically, these tend to be very I-shaped people having been suckled in such outworn creeds such as EA methodologies, EA modelling and waterfall delivery methods that have little immediate relevance in the eyes of those actually charged with building, running or changing a business. They are the only ones in an organisation who know what the phrase "Primacy of Principles" means and can use it in a sentence.

They lack the mandate or the ability to stabilize and co-ordinate an organization turning and turning in the widening gyre of agile projects and disruptive innovation that has become commonplace in organizations likely to survive the next 5 years.

The second kind usually do not call themselves EAs. You will find T-shaped, holistic or integrated thinkers in many areas of these organizations. Some are those who keep their heads as part of an organization’s innate leadership structure (C-suite through to middle management). Conversely, some charge once more unto the breach in depths of delivery, change, technology or operations. Some are part of the control functions of a business (e.g. Risk, Compliance, Legal). Ironically most of the Architects that I work with also mostly fall into this category.

The reality is that EA is no longer exclusively practiced by people bearing the job title of “Enterprise Architect”. In a purpose driven, agile organization, nobody is an EA.

But at the same time, everyone is an EA.

In my personal journey, as a graduate new-hire at a consulting firm, I naively aspired to be the first kind. Through observing both effective and ineffective teams throughout my career, I arrived at a truly jarring realization. The first kind had become irrelevant (if it ever was) and the future lay elsewhere. A single human mind is simply not big enough to be the grey-bearded fountain of wisdom that knows all things.

A frost came in the night and stole my world.

Since then, amid this flounce and filigree of death, the discipline of EA and my understanding of it has undergone a real transformation, moving away from the old-world view towards the second kind. This is essentially Agile EA.

To put it in a way that first type EAs will understand, I’ve found that Agile EA is not a structural element, it is a behavioral element (to use the Archimate parlance). 

More aptly, for second kind people like me, it’s not a Squad so much as it is a Guild (to use the Spotify agile teams model). In short, the best recipe to fail at Agile EA is to have an EA team sat in an ivory tower staring at spreadsheets. In reality, a successful Agile EA capability is a guild that draws people that are already present and empowered in your organisation into an effective community with a unifying purpose.

But guilds at this scale are incredibly hard thing to do effectively. It could just as easily turn into a meeting of the worrier’s guild where the problems of the earth are to be discussed at length, which more something you would expect from the first kind.

The glue that makes an effective architecture guild is not really someone with the title of Chief Architect. In reality, it is more about open and easy lines of communication and collaboration. It is more about people than process or methodology.

There are A basic practices that, in my view, are essential to creating this. Use them if they serve you:

0x1.             Get out of the Box: Very often architecture work happens within a project. In reality a fair portion of the work should live outside of projects, hand-in hand with strategy to decide what projects or initiatives should be pursued, in what sequence, to what effect. This is essentially defining the roadmap. Roadmaps don't live inside projects.

0x2.             We are All Part of the Business:  You should have only one strategy – a business strategy that envelops all moving parts (including technology, operations, marketing, etc). You should also have one shared roadmap to realize it across those parts. Separate strategies (e.g. a separate technology strategy) in separate presentations create needless waste and friction between your smartest people who should rather spend that time working to deliver the roadmap and realize your strategy. This is not to say that each area should not exhibit strategic thinking for its part of the organisation - on the contrary. The overall strategy should draw together a single picture of coherent approaches within each area, but above all ensure that they are coherent with each other and realized through a clear roadmap.

0x3.             Communication above Meetings:  Your architecture guild is only really effective if the lines of communication work naturally outside of your guild meetings (i.e. people natively reach out to each other for help, guidance or alignment without any guild intervention). This takes two key things – a culture of empowerment and collaboration and a shared body of knowledge and intellectual property. Note I didn’t say “repository”. If your knowledge is reposing in a presentation somewhere, it’s aging rapidly and not being put to work.

0x4.             One Flow and One Place to Go: Often, organizations tend to have multiple review & governance committees to ship a piece of work. This is unnecessary bureaucracy. Collect all the approvers & control tribes into a single process focused on flow. Your guild members serve as drivers and guides through this flow. This allows teams to ship quality products to clients quickly, evolve your roadmap rapidly and satisfy your control objectives at the same time. That is the real job your organization is hiring your guild to do.

0x5.             Come Early Come Often: Despite that, a guild meeting that encompasses peer reviews and lean governance are useful things if done in the right way. Too often, these reviews are done too late in the life cycle to have any material effect (i.e. the project budget is already burnt, so what now?). You should encourage guild members to share problem statements and ideas very early in the life cycle (with as little prep as possible). This drives early alignment, collaboration and optimal re-use.

0x6.             Iterative Planning rather than Annual Planning: Annual planning ceremonies have their place, but in reality a year is 26 sprints. The agile world moves too fast for conventional planning processes so have a transparent, open roadmap that looks several years in advance and which is continuously updated as delivery evolves. Your annual planning ceremonies will be easier as a result and when you have a major enterprise “pivot moment” you won’t start with months of running around trying to collect data and information to figure out what to do. You will pivot faster.

0x7.             Manage Your Traffic: An effective guild probably works more like an ad agency than a first kind architecture function. Pieces of work need to be shipped to the right people at the right time, you need the right eyes to look at things at a point in time, and most critically your artifacts really need to be shipped to some form of accessible collaboration portal for future re-use (and in doing so, ensure that your organization natively converges and evolves a single roadmap rather than needlessly forking). Go steal a smart, adaptable traffic manager from an Ad Agency to help you do this, if you must.

0x8.             People are the Platform: Invest in your people across the organization (not just the Guild members) and equip them with the right tools. This could vary from effective virtual collaboration capabilities to advanced training for those who need it. Hire people with the depth of expertise and experience and empower them to do their jobs and make good calls with minimal friction. This is not about EA modelling tools. They could add value, but if your people are not empowered and collaborative a tool won't save you - in fact it will probably just worsen your ivory tower syndrome.

0x9.             Have an Identity: Your guild members should have a sense of belonging both to the guild and to the teams that they are a part of. There are varying ways to do this, but this is what we did

• visual storytelling (we used the “MasterBuilder” concept from the Lego movies to define how we would work together and create a unifying purpose)
• creating a mantra that serves to remind the guild of why it really exists and don’t be afraid to change or evolve it it (our current one is “#Win at change”). 
• we adopted the theme of Superheroes for each of our Architecture portfolios and Guardians of the Galaxy for our enablement team. We even had the Chief Architects in the group dress up as superheroes for one of our off-site sessions. I went in a business suit (dressed as Bruce Wayne). Everyone still thinks I was Dr Evil. Nobody knows I'm secretly Batman :-)

0xA.        No clean hands: To avoid ITS (Ivory Tower Syndrome), everyone except the traffic manager has to have a day job that is not really part of the guild. In the context of T-shaped people this is their specialization or their depth and it is this that allows them to bring value as a guild member. Guild members who lack depth create an ineffective and bloated guild (and even a bloated organization)

I have a pet peeve about the first kind of EAs… their blog posts and documents are too long and verbose. So I’ll stop before it's too late.

My thanks to my colleagues Andrew Moore, Manoj Puri and Jaco van Wyk from whom I shamelessly borrowed (read: stole) some ideas in this post.

PS: The links in this post are from poems/lyrics. If you are familiar with them then I hope you got a dry chuckle out of it.