Play a new role as Enterprise Architect

Somebody once asked “What kind of people become EAs?” and I blurted out: “EAs are like CTOs, but without the Charisma!” – and I could have added “… or responsibility”.

In my experience, inspiring and motivating Enterprise Architects (EA) are few and far between – but this really shouldn’t be the case.

What an Enterprise Architect could be like

Agile has been on the move for quite some time, and the glory days of corporate enthusiasm and attention for Enterprise Architecture are long gone. Role descriptions like this one from SAFe® focus on a number of things you are responsible for, but less about how to do it.

As a consultant/contractor architect, I get to work on both solution/program level and enterprise/portfolio/line level, so I see the EA role from different perspectives. I will try to list some of the things I would like to see in EAs from the viewpoint of a Solution / System / Program architect. I hope you may be inspired by these thoughts.

Be a Guide: Inspire and motivate – based on deep professionalism.

The EA must be able to inspire people to join the Quest for Right Solutions. Tell us the Why instead of the How. What are the principles and underlying assumptions that are most important?

Please be our guide and mentor – don’t prescribe or dictate. If you can’t motivate people in the teams, then you won’t get results by demanding or shouting either. If you can’t convince management to make the right decisions – then our quest is doomed from the outset.

Communicate the vision for the portfolio. Aggregate and distribute information instead of hogging it. Speak in front of crowds. If this is uncomfortable to you or you are highly introvert or like to analyse things in detail, then consider branching off to specialist architect roles – maybe BI, Business Analysis or infrastructure? Or maybe you can proclaim yourself ‘Proud Defender of the Comprehensive Enterprise Canonical Data Model’, which should leave you in peace from people on quests 🙂

An EA should be positive and motivating. Do this by demonstrating a deep professional understanding and convince with WISdom – not INTelligence. Simplistic Positive Thinking and Contentless Coaching won’t get far with software professionals, who tend to base decisions on facts and experience. We don’t want the ‘you-can-be-anything-you-want-to-be’ BS, but we all need to be reminded to do the right thing for the common good. Inspire to build in quality, automate more, learn from feedback etc and to constantly improve our ways of working.

“Don’t be yourself – be better than that!”

Don’t improve for your own sake – but do it for your peers. See ‘Stand Firm: Resisting the Self-Improvement Craze‘.

These principles also apply to the whole enterprise. We don’t need to have all processes completely ‘Managed’ or ‘Defined’ (as required in CMMI) in order to start continually optimising. Any process should incorporate built-in optimisation through feedback loops from the start – as all brilliant Game Masters know.

Be our Umbrella: Shield us from Bad Stuff from above!

You need to be able to influence business people and work proactively with them in order to avoid bad stuff coming our way. Don’t focus solely on the formal lines of communication, forums etc, but interact directly with business people. That implies you shouldn’t go all-out on Non-functional Requirements, technologies and the usual tech architecture stuff, but leave room for the functional needs as well. Enterprise Architects work on strategy with Line/Portfolio Management. In SAFe this will include working on Strategic Themes, Portfolio Canvas. We need that, but we also need you to hunt down and engage with those business people who come up with the crazy, undoable ideas (and good ones too). We need you to guide, steer, influence and circumvent all those business initiatives that are bad, because IT hasn’t been thought into the solution. Find the good alternatives and present them to business before they start demanding it.

In SAFe this means you need to get your hand on all Epics – not only Enablers. Try to tweak the Epics so they also make sense from a software architecture and development perspective.

Visit the Mortal Realm from time to time

You’re working in the higher layers of the organisation, so you should of course be able to communicate and collaborate with ‘Management’ and ‘Business’. You also need to be able and willing to work all the way down to the teams. Here you need to stop trying to command and control, and start suggesting and guiding. You need to be able to listen and actively seek feedback from your peers and underlings.

I’ve been in a situation, where the EA and I had a friendly meeting, where we both really tried to understand each other, but we simply had to conclude our worlds were so far apart, they might as well be alternate realities, and we just couldn’t agree on a common ground. The consequence was that the directives from the EA became an order of the impossible. I was forced to respond that I would comply as soon as time permitted and the work was prioritised by program management. Effectively, this event would coincide with drastic climate changes in the nether realms (i.e. when Hell freezes over).

Some architects tend to observe the world through their perspective, constantly thinking ‘How well does reality fit my model?’ instead of trying to really understand what motivates others (esp team members) and how their view of the world is put together. Sometimes it’s healthy to try thinking

 “I accept your reality and substitute my own”

… at least for a while.

Work Sideways: Engage with people across Domains in the enterprise – not just up and down

We need you to connect us with people from other business domains, whenever we need to integrate, share UI, contribute to shared business processes etc. Please pair us up with the people in other domains, who are their real Heroes and Do’ers, and don’t send us into the grasp of their gatekeepers.

Stay Gold: Don’t be a victim – and don’t blame Agile either

I attended an EA professional network meeting a few days ago and noticed a shift in mood as soon as someone started complaining about quality. It was the usual lament on how the Business is pushing bad solutions that increase technical debt, and how developers do as they please and hurt the architecture, trespass domain boundaries etc. Instantly half the room was singing along and many joined in on the new verse about how Agile makes teams focus solely on throughput, forgetting quality, strategy and enterprise needs.

It is true that Business in the form of Product Management and Product Owners in Agile can disregard quality if they choose to ignore all the inherent and underlying principles of Agile and Lean. The need for quality is deeply ingrained in all Lean-Agile methods “… deliver the maximum customer value in the shortest sustainable lead time while providing the highest possible quality to Customers and Society as a whole*.

But this is hardly news. Agile yields the same opportunity for short-sighted feature production that we had in the Dark Age of Waterfall projects. Neglecting quality is not very visible in either approach, but maybe there is a change of Actors. Some of the loud old up-front fights for quality between Architects and Project Managers might now be delegated to discussions in the teams, where quality can be compromised more silently and less transparently.

To counter this mechanism, SAFe includes capacity allocation for enablers in order to ensure adequate investments on the tech side.

Do Good and walk away from Evil.

Many Enterprise Architects are apt to feel victimised and neglected by both Business, Management and Teams. I catch myself joining the ‘poor me’ or ‘poor Enterprise’ chorus from time to time, but I try hard to break the habit and start focusing on making changes and improve conditions wherever possible. I strive to work with the people who actually want to change and who appreciate the need for building in quality in the form of good architecture and design. Obstinate POs, managers and developers may be persuaded if you can present solutions that achieve the same goals, and also last longer and don’t hurt the architecture and design. If those people are not in a frame of mind to listen to reason, persuasion or make compromises, then you simply can’t help them.

Walk away from Lost Causes and use your time on the places, where you can make a positive influence, but stop whining about how evil the world treats you. You may have some formal powers on your Character Sheet, but they are usually not worth much when push comes to shove. You must learn to exercise informal power and roll well on your Charisma check.

The same goes for the old Country song about the Slick City Consultants, who only have short-term goals and leave a mess of bad quality in their wake. You should either challenge the business people or managers who have instructed the consultant, or discreetly appropriate some of the consultant’s time and lead them in the right direction. As a consultant/contractor, I meet EAs who understand how to use me to offload their grunt work, so they can focus on e.g. strategy, or collaborate with me to influence the outcomes. I also meet a lot of EAs who actively ignore me. Sometimes it works for them, and sometimes they render themselves redundant.

Other tracks

To improve your character you will get a lot of inspiration from this brilliant article on changing your mindset as Enterprise Architect: ‘The Role of an Enterprise Architect in a Lean Enterprise’. This will help you transition alignment from ‘Lawful Good’ to ‘Chaotic Good’.

Copyright Notice

SAFe® and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.