WBISCT Pty Ltd – Enterprise Architecture Consulting and Training

What should an Enterprise Architect be like?

By Axel Dancoisne for WBISCT.net

I have been fortunate enough to work in Enterprise Architecture for many years, and more recently I even specialised in sharing such love by training a lot of new and existing architects over the past 5 years Australia-wide but also in NZ and even all the way up to Hong Kong, Kuala Lumpur and Singapore.

During such time, I have noticed three types of (aspiring) architects. Some were very technical from their original background or current roles, others were very astute at reading their enterprises’ business needs, as a lot of them came from the purely business side of things and then became architects either by need or want… I got to also meet the “third kind”; those amazing individuals from all horizons of life with a great mix of both skill-sets within the same person. Needless to say that the latter ones generally fare better in the course than the two other types… well, most of the time.

The technical Architects tend to have more problems adapting to new concepts especially if those are abstracts, like in TOGAF for instance. They have a tendency, from experience, to back themselves up with the “known” quantities of the world that they master. The business oriented architects tend to have a more holistic approach to TOGAF and they show more ease in dealing with the concepts of the course, but as we get into the practical (read technical) side of things during Day 3 and 4, their technical lacunas start to often hinder their ability to apply the rules learned during Day 1 and 2. There are always exceptions of course, but those are the general observations I could make over the 100+ courses I have delivered on such subject matter to thousands of delegates. The more balanced individuals tend also to move faster through the course and finish early, if they don’t even take the lead of their group, during workshops…

Needless to say that when I have all 3 types in my courses, I am in heaven; for such diversity creates an amazing synergy of thoughts and lead generally to passionate discussions, which to my great despair, I have to sometime conclude on way too early or face the risk of rushing through some examinable content of the course, which I need to cover in class.

A lot of time, I am pleased to give one of those “balanced” architects the “mic” so he/she can explain how they understood their business needs on some occasion, and effectively and efficiently linked their company’s business strategies to their initiatives and their relevant architecture model(s). And when asked how they realised their architecture vision into the shape of a deliverable S.M.A.R.T roadmap, they told us how they easily translated their abstract building blocks into a technical solution, which linked their architecture modelling into detailed and agile requirements and user stories for optimal delivery.

So in effect, as I was listening to those amazing people and comparing with my previous experience in the field during all those years, I kind of realised what a top Enterprise/Business Architect could look like and I tended to agree with a common set of skills a few EA gurus out there like Daniel Lambert have already defined over time.

1. Focus on delivering a customer-driven architecture design.

Because the essence of a good Architecture design is to ensure proper alignment of business mechanisms like processes etc. with its supportive infrastructure to which ICT systems also belong, a customer centric approach is key to delivering the proper value for architects to succeed. this is also where customer experience takes all its sense as perceived value is paramount to the acceptance of an Architecture deliverable.

2. Know how and what to prioritise and get the value proposition just right via consensus.

Choose your battles, don’t step on Solution and Project specialists’ toes. If it does not need to be architect-ed then… leave it be! Sometimes we want to do too much and become the jack of all trades and we become master of none… Certain methodologies are clear about what will benefit from being an architecture project and what will not. Know the difference…

3. Be a great communicator, with all your stakeholders.

Because Architecture is a consensus, finding the win-win in every situation is not the end of it, you also need to sell it! By selling, I mean, here, that architects must convince and therefore choose their communication style carefully and apply the right fit of governance in that aspect using a communication plan that will reflect how they respectfully managed their stakeholders from the word go!

4. Refrain from (re)modelling at all cost, everywhere, all the time…

Jumping to your cutting edge EA modelling tool straight away is what a lot of architects are guilty of. They often miss important pieces of the puzzle by rushing the early engagement sessions they should have with the client/stakeholder(s). Hence their Baseline is wrong and everything coming down from it will probably go in the wrong direction too. And remember the first rule of efficient Architecture, reuse as much as often and wherever possible before reinventing the wheel. Hence favour a fit for purpose repository rather than the biggest, ensure it has a structure you can work with in the most user friendly manner. Keep your access control of it tight and secure and observe an error free version control every repository stakeholder understands and masters.

5. Remember that if you can’t measure it, you can’t value it.

What is it that you are aiming for to deliver is the most important question of all, to keep in mind, throughout the entire architecture process. What (if any) are its’ strategic values (i.e. alignment), tactical values and/or governance values (i.e. maturity improvement)?

Are those your KPI and CSFs that you are looking at or the client’s? Defining measurements/KPIs can be challenging. Good KPIs must have a target value and a way to be accurately measured and reported. Ideally, good KPIs should include the following characteristics:

  • Aligned—with the specific organisation vision, strategy and objectives.
  • Optimised—the KPIs should be focused on providing organisation-wide strategic value rather than on non-critical local business outcomes. The use of the wrong KPI can result in counter-productive behaviours and sub-optimised results.
  • Measurable—can be quantified.
  • Realistic—must be cost effective, coherent with the organisation culture and constraints and achievable within a given time frame.
  • Achievable—requires targets to be set that are observable, achievable, reasonable, and credible under expected conditions as well as independently validated.
  • Clear—clear and focused to avoid misunderstandings.
  • Understood—business and IT stakeholders and relevant organisational units should know how their behaviours and activities contribute in achieving the targeted objective measured by the KPI.
  • Predictive—the KPI may be compared to historical data over a reasonably long period of time so that trends can be identified.
  • Agreed on—all involved stakeholders should agree and share responsibility for achieving the KPI target.; and
  • Reported upon—regular reports should be published to all relevant stakeholders, so they know the current state of the enterprise and business architecture model element and take corrective action(s) if required.

6. Focus on the end result, the business Mission Statement and its dependencies.

There are several schools when it comes to what to focus on. Some want to design a target first, despite no legacy constraints for technology. They are generally those “consulting” places that want to draw a dream vision they can easily sell regardless of the client’s ability or readiness to get to, due to a Baseline that is light years away from that ideal Target; and no Business Transformational Readiness Assessment to get there either… But the consulting agency probably does not care about it, as long as they get their win right? Alignment with the business’ Mission Statement/Vision, qualitative long term Goals and quantitative short to mid term Objectives, is paramount to a successful Architecture endeavour.

7. You architect it, you support it…

Business and enterprise architects’ job does not stop at producing roadmaps and assisting corporate management in the selection of an optimal scenario. Digital transformation projects often fail short of their objectives and drag far too long because the coordination and architectural bridges between business and IT stakeholders are none existent. Once a consensus has been reached over a solution, its delivery needs to be monitored closely by the EA and its life cycle also scrutinised so that the EA capability can fine tune its productive process and ensure that the delivery promise is consistently achieved over time.

In summary, good and appreciated architects are very customer-driven, they excel at finding value for their organisation and its stakeholders, they communicate well with all stakeholders no matter which ones, they are not architecture modelling freaks, they know measurement techniques inside out, they meet their organisation goals and objectives and they aren’t afraid to roll up their sleeves by getting involved with the delivery of roadmaps and even throughout their solution’s entire life cycle.

So are you one of those business/enterprise architects?

Was this article helpful?
Yes Definitely!Not Sure...