Paul Homan's Weblog

EA and Engineering

Paul Homan — Mon, 14 Feb 2011 10:49:37 +0000

Recently I have had the pleasure of getting back to my roots and work in an Engineering organisation. Doing EA. One of the things that was most interesting to me is just how much those early career experiences had influenced my latter day thinking.

Whilst I worked in IT (or Management Services as we called it then) – I was surrounded by Engineers, Engineering and all that goes with it.

A *well-engineered* system equates to a *well-architected* system in my book… and in this world of quick wins, rapid change, fleetness of foot… we could do far worse than remember the disciplines, rigour and structure that we need in place to facilitate this ever increasing agility that we need.

You can’t just build a big plane or boat quickly by simply doing the same as before but a bit quicker… you have to design the product so that it can be built quicker.

EA and Twitter

Paul Homan — Fri, 07 May 2010 09:17:38 +0000

Architecture for the Enterprise in a world of Tweets

So, I joined the tweeting world recently. Addictive it is, useful?… still waiting to see on that one. I can be found under @homanp on Twitter – on occasion.

The question I’m enjoying juggling now is this…

How does the world of Twitter (& the like) change the world of EA?

In truth, it seems to connect people with like minds, shared interests in EA… I for one don’t seek out to follow people who I disagree with… which is actually a concern really. All I am doing at times it could be said is seeking reinforcement of my own views, and disregarding the rest.

As for the practice of EA, I haven’t seen any impact nor can I imagine any that are more relevant than any other ‘solution building block’ – after all, that’s all it is isn’t it?

Exemplars

Paul Homan — Wed, 11 Nov 2009 10:15:26 +0000

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

Paul Homan — Thu, 17 Sep 2009 09:15:58 +0000

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?

Paul Homan — Mon, 10 Nov 2008 00:59:18 +0000

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

Paul Homan — Mon, 07 Jul 2008 14:31:14 +0000

‘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!!

[contact-form]

So ‘strategically’.. is the way…

Paul Homan — Tue, 10 Jun 2008 18:07:17 +0000

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

Paul Homan — Fri, 02 May 2008 15:46:16 +0000

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

Paul Homan — Fri, 11 Apr 2008 16:10:27 +0000

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…

Paul Homan — Thu, 20 Mar 2008 11:34:28 +0000

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!).