I spend some time each week looking at research and communities of practice discussing all things architecture - in particular enterprise architecture. Whether the articles or "insight" comes from industry research, linked-in architecture groups, webinars or other events the challenge is always the same:
- Why can't business leaders and even those in IT see the value that we can bring as enterprise architects?
- Why is it so difficult to get a seat at the table?
- Why, despite the many decades of material does no-one understands what we do?
I've concluded that it's because A. no-one cares and B. no-one cares!
What business and change leaders care about is getting stuff done. Making a business more profitable, more agile, more competitive; adding some kind of benefit to their organisation. They don't care about value streams, landscapes, roadmaps, capability models, principles, standards etc - the outputs of architecture teams - they care about what it means, for them, now.
That is not to say that these outputs don't have a use, they do, just not in a means to themselves - this is where a lot of architecture practioners fall over - the constant tinkering and refinement of models, views and artefacts that by themselves have limited use. It’s how they are used in the conversations with stakeholders and change agents across the business (and IT) that count.
Ask business questions
We’ve worked in architecture teams in retail, manufacturing, healthcare, legal services and luxury goods, to help mature their capabilities and actually start delivering real outcomes for their customers (internal and external). It's only until these teams start to truly understand their business, by asking questions and actively listening, that positive change occurs.
Change doesn't occur by showing a commercial director in a retail organisation a picture of their application landscape and confusing integration diagrams - but by asking "What does a 10% increase in online sales means to your business revenue? What is your conversion ratio between your highest and least performing product lines? Can we help identify products or services that have a higher conversion rate than others?"
or in a law firm, asking a Head of Practice : "What services in your practice are most profitable and align with the firm's expertise? Can we make those services more profitable or consider expanding across other practices? Can we identify similar client services but make them more efficient?"
or in a hospital setting, asking Clinical leads: "What is the impact of preventative care or community health programs being integrated into our hospital strategy? Would we see a reduction in demand for beds and see significant improvement in patient hand-off and through put?"
EA’s just need to make sure they don’t fall back on their repository of artefacts as the means of engagement. Have effective business conversations, connect, build relationships and actively listen. Run workshops, help build bridges between teams, continually ask for feedback and ask questions!
Once you have established a connection and some degree of trust, the other area I see EA’s struggle with is the delivery of change. There is, in my mind, a disconnect here – with the perception of the Enterprise Architect sitting on their TOGAF throne dispensing sage advice to the minions who actually get the work done: and then Enterprise Architects get upset when they are ignored! It is equally important that the architect gets involved with delivery teams, becoming a useful and important cog in the wheel – normally in agile teams.
Agile doesn’t mean chaos
Plenty of organisations have decided to incorporate design thinking across the whole enterprise. This inevitably leads to the creation of everyone being in “agile” teams with the typically uninspiring lexicon of “break things, fail fast, fix forward, change is the only constant etc”. In this way of thinking architecture is a dirty word because it implies order, control, planning and forethought - not very cool when you just want to break things – who wants to be told how to break things in a particular way?
Now don’t get me wrong - I really do get it – you want to experiment, get feedback quickly, continually learn and hopefully deliver things rapidly and who knows actually create an innovative service. But you can’t do these things without some idea of what you are trying to achieve – what does your customer want? how does the business generate value? How do you know if you’ve succeeded or whether priorities have changed? These are the things enterprise architects can bring to the table, not to stop the agile party but to enable it and even accelerate it.
Don’t talk about enterprise architecture
Until enterprise architects begin to have conversations about business performance and truly try to understand what value means to their customer, we will find ourselves continually on the outside looking in. The first rule of enterprise architecture should be - don't talk about enterprise architecture. Focus on the business, focus on the problem, focus on the outcome - and then use EA techniques to help shape the right solutions and guide change teams in how best to deliver those solutions.
So the point of enterprise architecture is NOT enterprise architecture - the point is to unearth benefit and delve into real problem statements. Only then does the drawing board come out (hidden of course!), the blueprints and plans created which can help solve those problems and make a real impact.
If you are interested in how Enterprise Architecture can be used to positive effect then please reach out to one of our consultants to discuss how we can help.
