Look in various business and technology architecture forums on LinkedIn and you will see hundreds of attempts to define enterprise architecture. The debate rages about whether business architecture is part of EA, what it takes to be an architect, and whether architects can even rightly use a title that is hard-earned by the ‘real’ architects in the construction industry.
Our professional community remains desperately fragmented.
It’s ironic. For a role that is supposed to bring clarity and order to business investment planning, as a community, we can appear as a motley crew. I’m often told that it seems anyone can slap the title “architect” on their business card and attempt to add a meaningful percentage to their asking salary.
Having spent the last 10 years assessing the performance of hundreds of architects in different parts of the world, I believe it’s time we brought this issue to a head. What can we do to formalise the enterprise architecture profession?
One key step is educating organisations that they should demand a formal qualification of their architects prior to letting them loose inside the organisation. While TOGAF® certification on its own won’t make an architect; it certainly helps get the basics understood before we press ahead.
So what is an enterprise architect? Here’s what I think.
Architects draw together and synthesise information from subject matter experts to provide informed and balanced recommendations for management decision-making – most commonly supporting business technology investment planning, program and project delivery.
The job family of enterprise architecture, which will usually include business architects, enterprise architects, data and information architects, application architects, infrastructure architects, and solution architects, all abide by this description. However each role has a very specific set of prerequisite capabilities and experience required to be able to run the process and produce the right type of deliverables and advice.
For instance a business architect requires deep business domain knowledge to credibly interact with business stakeholders. Similarly infrastructure architects require suitable technical know-how to understand how to shape an infrastructure investment roadmap that will support applications, data and business requirements. And solution architects must understand how to identify and communicate the trade-offs between functional and non-functional requirements by bringing together a host of technical and non-technical considerations.
This is not substantially different from the role of the architect in the construction industry (I started out in ‘traditional’ architecture before pursuing a career in IT), where the architect must work with construction engineers, lighting specialists, builders, quantity surveyors, electrical engineers and town planners to synthesise a suitable design solution for their client.
My point is, when it comes to the various roles in the enterprise architecture job family, there are several things an architect must have in her armory. Most importantly, the architect must be able to interact effectively with domain specialists and understand the opportunities and impacts of various design decisions; and produce and communicate the relevant architecture work products required by managers to make effective decisions. This is where the rubber hits the road when it comes to taking enterprise architecture from a hit-and-miss initiative to a high-impact and effective decision support capability.
After 10 years of developing enterprise architecture teams I am sympathetic to those who continue to make these mistakes as one size does not fit all when it comes to building an architecture practice. However, as is often the case, without a clear understanding of the key jobs to be done by architecture, the architecture operating model, the architecture services and capabilities required, and a detailed understanding of the prerequisite knowledge and capabilities required for each of the roles, it’s no wonder why some organisations feel short-changed with the value they receive from their architecture investments.
If an enterprise architect, or any of the roles in the EA job family, can create that ‘light-bulb moment’ for their customer, by bringing the right information to the table, in the right language, at the right level of detail, and truly engage them with a clear case for a way forward – we have a winner. The customer wins, the architect wins, the brand of architecture in the organisation wins, and more broadly our almost-profession is on the road to becoming truly professionalised, where all organisations will come to demand a recognised qualification that ensures this kind of capability is put to effect every time.
In the world of physical building
Anyone in the UK can call themselves an Architect
However
Putting the word Chartered along with Architect is different
I recently passed some exams and I worked hard to do so
A colleague asked me what passing the exam proved
My reply was ‘nothing’
Time at the coal face and living with the consequences of your actions are the real world teachers
Just so long as you stay humble and keep striving something not too shamefull will emerge as a design worthy of building
Something worthy of debate is how the design process educates and illicitls formal feedback on Change proposals across all parts of an organisation.
Design as an educational tool for organisations is of value
I enjoyed your blog and the views of the commentators
Thanks
Ken
Hi Hugh!
As a hard-nosed, assembly-level game developer, I actually sympathise with this, even if it is foreign to me in the terms you use.
Basically, what you’re saying is that there is the cache controller, the DMA controller, the GPU, the CPU, and the various other components (hard-, firm-, soft-, and wet-ware) that all go together to making a good and efficient platform that can and should be used by people to make their lives (businesses) richer.
And hey I agree. And I am no enemy of abstraction. I understand that “architects” come in all shapes and levels of perversions, from circuit layout dudes to what are called “software astronauts”.
I guess you’re just talking about the vagaries at the top-end, where money is made (gleefully and quickly), rather than at the coal-face, where reality is made (slowly and painfully).
Unfortunately, never the twain shall meet. You seem to be arguing for a way to ‘formalise and regulate’ what is necessarily a soft-science: business, with what is necessarily a hard-science: technology.
At the bottom end, the tech side, are still struggling to figure out how to make software and hardware that works for a while without breaking or being broken by external forces.
I do hear you, and understand your plight, but you cannot succeed in any attempt to formalise such an abstract thing as “enterprise architecture” while the underlying reality of things – the software and hardware and even form factors and connectivity – is in a constant state of flux.
For instance, you go away and spend your $180k/yr on suited a “EA” dude that speaks the speak and and create a UML diagram. Then they get blind-sided by the next tech in 2014, say an update to .Net, or a new web technique, or whatever – and you’re toast because you can’t interface with Google Glass or Tesla Cars because your entire source based is based on .Net 4.0 and uses a proprietary over-the-wire protocol based on SOAP or something.
Same for things like spending umpteen millions on local servers only to be blind-sided by cloud, only to realise that you don’t have the bandwidth for cloud, only to realise 18 months later that now you do, when you’re halfway into a company-wide IT refactor to reduce bandwidth.
Basically, it’s a mess and you can’t control it.
You want stability and formal standards that can be used to make judgements based on past performance and regulatory standards? Get back into physical construction. Because we are no where near that yet for software, and I doubt we will ever be.
So you my dear friend are stuck in-between the ignorant money-men and the arrogant coders.
ProTip: Never trust a coder in a suit, irrespective of their ‘qualifications’.
@Christian – great to hear from you.
Enterprise architecture is not about regimented control, it’s about understanding and shaping the systems that exist to make the organisation function and deliver value. IT systems are a big part of this challenge but by no means the only part.
A fair analogy can be found in town planning. A town planner worries about whether there will be enough services to support a community. A civil engineer worries about whether the bridges will sustain the traffic. An architect worries about whether the school auditorium will be built to budget and still create the experience for the students. An audio-visual technician will think about the best placement of the sound system and future technologies that willl need to be supported… Like architects in the enterprise architecture job family all of these roles design solutions across inter-related systems. However you wouldn’t ask the audio-visual guy to set policy for the number of schools in a suburb any more than you’d ask the planning minister to reprogram your TV.
So – if we agree we need a suitable level of design thinking to evolve an optimal business/ organisation – the real question is – which architect (role) should stay awake at night worrying about which problem – and what do they need to know (and be qualified in) to reliably resolve it?
I have recently spent almost four years and a global organisation (as Head of Architecture Capability & Performance) to define, establish and operationalise a License to Work approach for the Architecture & Design Profession, which included over 250 staff, both enterprise and solution architects.
To become “licensed to work” TOGAF 9 practitioner certification was required, as well as a number of other internal training courses on organisational-specific architecture standards, processes and methods.
For the past 2 years, a licensed to work lead architect has been mandatory for all architecturally significant programs, and a quarterly global report was published on this.
Don’t underestimate the effort and time required to achieve this (definition: easy; transformation: very difficult!).
By all accounts, this (alongside other initiatives to increase the maturity of the architecting capability) dramatically repositioned how the profession was perceived by key stakeholders.
Furthermore, we used this as a differentiator to hire the best available talent.
@Vincenzo This is a great story. We’d love to hear more… do you have a case study or slide deck that explains the transformation journey?