Exemplars

When researching into exemplars of EA models recently… I found that there aren’t really any in the public domain that everyone (or at least most!) would say were good examples of a particular model view…. whether this is because people don’t want to share them or whether they havent followed a standard model view from one of the recognised frameworks (e.g. Zachmann, TOGAF, FEAF, DODAF, MODAF etc) or whether more scarily because they don’t really exist is a puzzle….

Enterprise Architecture Artefacts

Do we really know what artefacts we have…

So many times I have found that people believe they have a wealth of information – making statements like

 

“we have lots of good information”

“we did all that last year/ year before”

“so and so developed it for us”

 

Or finding all the senior management referring to the ‘golden rules’ or ‘Big 7’ etc…

 

BUT

 

So many times I have never actually seen these/ been able to get hold of this mountain of information. 

 It is either ‘not quite signed off’ or ‘bit out of date now’ or (scarily more common) inaccessible/ lost

Scars or Smiles?

What is more useful as a lesson.  I have recently just been working with some people who were very keen to hear the lessons I’d learnt from my time both as an Enterprise Architect inside an organisation, as well as those I’d picked up as a consultant since.

It led me to think… which were the most potent learning exercises?

Personally, those which were either difficult solutions in their birth (the solution took significant effort and focus) or we had several attempts at before getting it right, seem to have had the greatest impact on me.

However, what I have found is the need to consider both the difficult ones (above) and those that were resolved more easily or adopted very quickly when I was personally looking at them – just because the answer seemed obvious or straightforward at that time, in that context, to that audience – doesn’t demote the importance of the lesson.

I am hoping to write some entries in the future on these ‘EA lessons learnt’…

Green EA

‘Go Green’ is now a common business strategic imperative, and there a quite a few disparate initiatives springing up in organisations delivering small green improvements in various projects and operational systems. This ‘apes’ a common IT problem space…!

 

For years, EA has been the missing layer in delivering IT Strategy… the problem being that a top-down strategic intent was provided, and many disparate projects and systems all did their own little bit, in their own way, locally interpreting what was needed – often storing up wider problems elsewhere… and our answer has been Enterprise Architecture…giving….

1)     Models & Principles to work to

2)     Governance to control with

3)     Transition Roadmaps to show the way forward

4)     All supported by Organisational Capability

 

Comparison to GREEN

If you allow point solutions, project by project, system by system… there will be observable benefits in the area being looked at… but at best genuine overall enterprise-wide or even cross-enterprise-wide) benefits may be missed or worse case, the overall effect is negative.  For example, if we look to replace old technology with new more efficient machines… looks like an energy saving BUT… what about the recycling of the old kit?  Or the change of supply of certain components may supply lower carbon use footprints but if the sourcing requires greater transportation…

 

Isn’t this holistic style problem what EA has been designed to address?

 

So I say… don’t ‘Go Green’… Go GrEAn!!

 

Name (required)

Email (required)

Website

Text only. No markup allowed.

 

 

 

So ’strategically’.. is the way…

Again, it seems to be the ‘route to becoming an EAer’ that provokes most interest… the words ’strategy’ appear quite a lot in the responses I’ve received. And I wouldn’t disagree.  In fact, I fully concur!

However, it still leads me to the same old problem.

How do you become an EAer… ?  How then, if we say (for arguments sake) that in order to be an EAer you have to have had 2 or more domain experiences and an architectural ‘foundation’ … do you start to do things ’strategically’…. ?

By definition, to demonstrate the ability – you must have worked on something that required it… as working strategically on a solution would not necessarily be the right approach…. or is that what being an Architect is all about?

My reason for this growing set of posts is that I’m worried that in the ‘early days’ of EA… you could almost self-declare your arrival as an EAer (I exaggerate to make the point).  Since then, a lot of effort has gone into the ‘profession’ of EA across the industry… this is excellent but… its now a bit liek getting an equity card.  You cant work as an Actor until you have an equity card,… and you can’t get a card until you’ve worked as an Actor…    

Starting as an Enterprise Architect

I gave a presentation on leading Enterprise Architecture at a conference last week, and got asked a question about how does someone start being an Enterprise Architect – in what domains?

 

This reminded me of the ‘junior’ EAer post I gave a while ago.  I recalled the feedback I got from that – thanks – it was very challenging & interesting.  And I found myself wondering that as EA covers a number of ‘domains’ or ‘disciplines’ in this sense… i.e. Business, Data, Technology, Applications.  Do you have to have done them all BEFORE you are an EAer or are you an EAer if you have done just 1 in a certain way (more holistically?), or is it if you have done a combination of 2 or more…

 

My own thinking is that EA is not the lowest common denominator of these domains, so an EAer can’t have only needed to do one to ‘qualify’ – but neither do you have to have done them ALL as a prerequisite.  So, IMHO I think to be an Enterprise Architect, you have to have worked in 2 or more domains AND ‘in a certain way’…. And it is trying to define/ clarify that ‘certain way’ that could start endless debates!

The ART of (W)AR-chitecture

As part of a presentation I’ve been preparing to give, I have been considering various aspects of EA Leadership.

 

One of the lessons I took from my time leading EA teams was for the need to not just stay on top of technological and EA developments but also to be well informed on leadership skills and thinking.  To this end, I was introduced to ‘The Art of War’ – Sun Tzu’s classic document on Military Strategy.

 

It may at first seem a little tangential – after all, how can Military Strategy be akin to EA?

However, I read a translation and (somewhat for my own amusement) decided to apply it to the world of EA. It actually gives some very useful insights and guidance on how to lead a successful EA ‘campaign’.

 

The serious point behind this is that learning about leading an EA function does not come from learning about EA.  It can come from many other (often tangential) sources.  So, look outside & take time to reflect!

No EA…

In a previous blog I mentioned the 4 ‘states’ of EA (namely No EA/ Poor EA/ Wrong EA / Right EA). 

Simplistic as it seems, the reason for the ‘states’ is (I contend) that each state requires a different EA leadership style. So let’s look at ‘No EA’.   

Here we need to get the initiative going.  We will either have no team or have a newly formed team and can assume that the wider organisation may only ever (or possibly never!) have really heard of EA, or may be vaguely curious about EA, or maybe know of it but doubt its benefits.  The leadership task here is about getting the organisation genuinely interested in the topic… this is really hard and I personally would turn it round and try something different from just ‘selling EA’ (as per my previous blog).  

What I mean by this is to go for the points of pain (or shiny bits) that EA could help the organisation with – without ever mentioning EA.   So if an organisation has major problems with controlling IT projects or has an overly prolific set of infrastructures to support (or development methods or application skills etc)… then that’s the ‘way in’ to use ‘an architected approach’ to sort the problem out.  For example, I have ‘branded’ this in the past as ‘Gaining Control of IT’. By identifying that IT costs are way too high, that there are too many IT projects ongoing, or that outsourced suppliers seem to be calling all the shots… I have been able to tap into something that concerns the business execs and then give them the possible answer as a need to ‘Gain Control of IT’… and then do this using an ‘Architected Approach’… (using good EA practices!).

Chief of the Architects

A few years ago, my youngest asked me what job I had, and when I responded I was a Chief Architect, they looked at me wide-eyed and gawped… ‘Wow.. Chief of the Architects!’. 

I enjoyed this at the time as a funny mistake… but it kept coming back to me as a really poignant comment. Whilst my Job Title was Chief Architect – was my role to be the a Chief Architect much in the same way as a Chief Scientist or was it to be a ‘Chief’ of a team of Architects, in the mode of a Chief Executive or Financial Officer. 

I am not trying to compare the relative importance or otherwise… I simply like to think of the role (and recall a funny family moment) of leading a team of Architects as being the ‘Chief of the Architects’ rather than the Chief Architect. 

How to Sell EA

How to Sell EA.

 

Don’t explain EA!

It’s critical not to try and explain what EA is, why we as EAers are so passionate and excited about it, and why the whole world are idiotic if they can’t see its elegance, effectiveness and efficacy.

 

Sell a solution! (Not a concept)

We need to sell a solution to a problem(s) that EA addresses – not EA itself.

Clearly obvious point but so often neglected in EA-land.

Make it Specific (not Generic)

It has to be relevant to the specific business situation, and where we are with respect to past & present EA efforts. It has to be recognisable as tailored specifically for the organisation rather than it being a generic ‘one size fits all’ solution.

 

These points may sound blatantly obvious… but that doesn’t make them any the less valid!