We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Enterprise Architecture Matters

Adrian Grigoriu

The Enterprise Architect's key traits from a recruitment perspective

user-pic
Vote 0 Votes

The core requirement (the "Must") for an EA architect is a candidate that knows how to uncover the structure of systems, use the proper methods to document the enterprise operation, link parts into the whole, and understands architecture roadmapping and strategy.

An EA architect will see the whole (forest) without neglecting the parts (trees).

This comes only with experience in "various business and technology fields" and  training. 

But more important is the mindset, or better a personality trait, for analysis and synthesis. Not everybody enjoys or can do that, that is, dealing in abstraction, discovering patterns, designing etc. This is what you should be looking for.

Would the employers rather have another specialist in a business field (of which there should be enough already in their business), or would they rather have someone who has the capacity to analyse and strategise and approach problems of all sorts encountered at the confluence between business and technology, someone who fits the parts together?


In plain terms, what a recruiter and employer should be asking for, "do I want another specialist or a generalist the architect is? The EA architect should be the universal man of the business. The Renaissance man. This is what you should be looking at.

Ask yourselves or your clients this question, because that determines your EA candidate selection. Your rarely can get both at the price of one that is, at the quality you demand for the price you pay. Employers have to balance the EA with the specialist demands. If you go on asking for both you would probably end up with a specialist with TOGAF or Zachman training. Beware. 


In practice, such a practitioner with with ready solutions to your problem domain is hard to find and dear to keep, for a few reasons, at least. One of them is the architect's slim job satisfaction in a narrow domain. Another one is that specialisation prevents progress in the EA career.

Most EA architects would employ elements of existing EA frameworks. But none of them is good enough. Without a framework, you will not get the integrated whole of parts EA, that is, the business, technology components and describing artifacts all interconnected.

Very few EA architects would be able to create their own framework able to link the disparate parts of your business in a big picture. This is what you ideally want.  But it's hard to find. You'll discover a lot of show off, ranting and hype.

You'll have to make sure that the architect understand how business parts and designs fit together in a blueprint or set of them. Ask them to show you a sample integrated blueprint.

The architect may document and design for you the many parts of an enterprise. But if you put them together would your enterprise fly same as an airplane does when you fix the parts together? 

Having placed your designs in a Zachman matrix, have you gotten an EA blueprint? Certainly not. Having followed all the TOGAF steps and prescribed outcomes have you  obtained an EA? Indeed not. But that's what you will usually get.  Populated frameworks not EA. People often populate one framework or another (for example Zachman or TOGAF) but that does not mean that they do EA. In fact that contributes to the downfall of EA. 

Ask them the EA definition and purpose. If they talk about many but a blueprint then you should look elsewhere. EA, once designed, can be employed by any stakeholder (rather than EA architect) for own purpose: fix parts and operation, to do strategy, manage complexity, control change etc.

But because EA is often associated with transformation, your EA architect should be able to do strategy and in particular roadmapping. Ask them how they did and do it.


Leave a comment

Adrian Grigoriu blogs about everything relating to enterprise and business architecture, SOA, frameworks, design, planning, execution, organization and related issues.

Adrian Grigoriu

Adrian is an executive consultant in enterprise architecture, former head of enterprise architecture at Ofcom, the spectrum and broadcasting U.K. regulatory agency and chief architect at TM Forum, an organization providing a reference integrated business architecture framework, best practices and standards for the telecommunications and digital media industries. He also was a high technology, enterprise architecture and strategy senior manager at Accenture and Vodafone, and a principal consultant and lead architect at Qantas, Logica, Lucent Bell Labs and Nokia. He is the author of two books on enterprise architecture development available on Kindle and published articles with BPTrends, the Microsoft Architecture Journal and the EI magazine. Shortlisted by Computer Weekly for the IT Industry blogger of the year 2011.

Recently Commented On

Monthly Archives

Blogs

ADVERTISEMENT