jump to navigation

Why do we need architects anyway? February 10, 2013

Posted by Chris Eaton in architect, architecture, architecture method, artitecture, careers, communications, competitive strategy, EA, Enterprise Architecture, IT Architecture, IT strategy, methodology, methods, people.
Tags: ,
add a comment

I recently spent a very interesting day with IBM and the Corporate Executive Board on the future of architecture. Very interesting, very thought provoking. On the back of this, i have put together this paper Why do we need IT architects anyway?

‘The pervasive nature and continual improvement of technology in daily life presents vast opportunity but it is not always easy to see it. Armed with the right skills, methods and tools the IT architect can help you see the possibilities and exploit them’

Thoughts and comments are welcome. And i am very interested in how you live up to this vision…

new and updated TOGAF tests August 24, 2012

Posted by Chris Eaton in Uncategorized.
Tags: , , ,
add a comment

courtesy of Manuel de Toma -> Theopenarch.com

online TOGAF test May 8, 2012

Posted by Chris Eaton in Uncategorized.

Manuel sent me a link to an online TOGAF test ->  togaf.altervista.org

i have to admit i havent tried it, as i already have togaf certification 🙂

im a techy now, how do i become an architect? March 30, 2012

Posted by Chris Eaton in architect, careers, people.
Tags: , , , ,
I am lucky enough to receive the odd email from readers who ask for advice on architect careers. The most common theme is from developers and operations staff asking how to move into an architect role.
Here is my tuppence:
  • Bank your deep technical specialist skills and broaden your technical knowledge
  • Get comfortable with busking!
  • Tell everyone you want to be an architect! If they don’t know that they cant help you
  • In the long term, focus on soft skills and business understanding, this will pay a huge dividend and this is the only way to the most senior roles
Bank your deep technical skills and broaden your technical knowledge
If your a developer you probably know more than any architect will ever need to know about your specialist subject. Bank that you’ll never need to know deep techy details as an architect. If you want to be an architect you are going to have to give up the comfort of deep narrow technical knowledge for a broader, shallower knowledge of many technologies. I went through this myself it feels uncertain at the start but soon it become more comfortable.
Get comfortable with busking!
A challenge to technical experts is they understand that to be a true expert you can only be focussed on a few technical skills through a large investment of time and knowledge. Your only the expert when you wrote the book or the open standard. Credibility with other true technical peers is hard won. However, engage with 99.999 of the populace on technical matters they will consider you an expert even when you know your knowledge is pretty superficial.
Just think when you helped your mum fix her PC you just did standard stuff that anyone can do but she thinks your a hero because she had no idea what to do and never would have resolved it without you help. She thinks your the expert even when you know you not.
Thats busking!
As an architects you need the experience to spot what’s good, bad and indifferent and cram on any given subject to become a mini expert as well as use wider expertise to make good decisions but you cant possibly be the expert in everything
Tell everyone you want to be an architect
Who know you want to be an architect? is it 0,1 maybe 2 people? you need to tell everyone! only then can people help you achieve your aims. I learnt this lesson the hard way after many years of feeling suppressed in a role I started to be more directive about what I wanted (i.e. do this or im going to leave) and it worked and it has continued to work – dont be shy. Peers and managers are not mind readers! You need to tell people you ambition and they can and will help you achieve it.
In the long term, focus on soft skills and business understanding
In the long term peak your head above technology and concentrate on consulting and people skills. I started off as a pure technologist and indeed avoided touchy feely courses on stakeholder management, communication, performance management, team effectiveness and all that in preference to technology courses. Eventually i was ‘made’ to go on courses like this. These were the most important courses i ever went on. Now I only go on courses like this and use conferences and experts to give me enough information on technical matters so that I can credibly busk.
In summary
Finding a first architect role is tricky. In fact in my IBM days there was a specific study into how to create first time architect roles because upcoming talent expressed a difficulty in understanding how to move from developer and designer roles to architects. The conclusion was that specific effort was needed by the organisation to make this happen and create first time architect role and once in role give the assistance required to help first time architects succeed, typically through mentoring and coaching.
Demonstration of pure technology skills can only get you so far. I am currently recruiting for a couple of senior enterprise architects. The majority of CVs i get are very technology focussed. XML, SAP PI, basis, j2ee etc. That is useful, however,what is really important is demonstration that you are able to engage, persuade, leverage and lead a larger architect brain to solve a problem – that means solving problems of greater and greater significance by leading and leveraging others either inside or outside of your organisation. Show that is in a CV and you will go much further than a pure play technology CV
hope this helps

Business operational architect February 6, 2012

Posted by Chris Eaton in architecture, Enterprise Architecture, methodology, methods, people, profession.
Tags: , ,

funny how time flys…200+ days since i made a post. Hard to believe it!  t’has been a busy time

One idea I have become very interested in recently is the idea of a Business Operations Architect (better names may exist!).

Let me explain this role. I am very interested if this role exists in organisations already and what i might learn from them

My starting hypothesis is:

  • most architects are working on project delivery, architecting new solutions or upgrades to existing ones. Typically they introduce new functionality to end users (business, application or functional architect)
  • some architects design infrastructure (technical or infrastructure architect)
  • some architects are working on Enterprise Architecture; they plan the future IT landscape of applications and infrastructure

No architects are looking at current applications, their functionality, infrastructure, incidints, problems and supporting environment such as monitoring, capacity, performance, etc .

Therefore: a new role is needed: the Business Operations Architects: they ask and answer the following questions:

  • Are users happy with the functionality? what needs to change to improve user experience and function?
  • What incidents have happened, how can they be prevented in future?
  • What problems exist in the current solution and how can we solve them with future releases?
  • Is the supporting operational infrastructure fit for purpose (monitoring, alerting, hardware type/age, software age/support arrangements and if not, what changes are necessary?

They would also play an assist role:

  • are new solutions fit for purpose; functionally and operationally? they would lead or participate in architecture reviews
  • ensure changes are accurately reflected to documentation such as system scope diagrams, interface specifications, architecture diagrams – these often are out of date relating to atrophy of design
  • provide expertise to support incidents and help restore service

is this a good idea, is anyone performing this role, does anyone have a better name for it!



who makes architectural decisions and a TOGAF rebellion June 30, 2011

Posted by Chris Eaton in architecture, architecture method, methods.
Tags: , , , ,

so i am a fan of the idea of architectural decisions – an architectural decision is the consideration of a problem which needs a soltion (most likely an it solution) and deciding and agreeing what to do

In my opinion, solving problems like this is the very essence of why architects exist because these problems do not often have obvious answers and there are multiple options to solving any particular given problem.

In the last month or so at work I have been looking at who decides which applications are strategic and which are not

I assumed this was a decision the Enterprise Architects made

Much to my suprise in over half of my organisation this decision is not made by people who call themselves architects at all. Instead this decision is owned by IT staff who have come from the business and now are in IT, and by Application Portfolio Managers / Application Managers.

Application Portfolio Management is a role not oft spoken of in the realms of architects but one everyone should be aware of. Application Managers typically own the operational running of a set of applications i.e. incidents, the projects, the cost and customer satisfaction of those applications. This this usually means they talk to the business very frequently about outages, incidents, projects, etc

Therefore adding on an accountability to determine whether an application is strategic or not is a very nature addition to this role. This is probably in consultation with architects but ultimately takes this decision away from the architect, if they every owned it in the first place

I have found this answer rather challenging

I had an assumption that architects would normally own this decision. They are typically technical experts with depth in one or more business domains. The most logical home for this decision

However, on reflection placing the accountability with an APM seems like a more natural home.
– they have a more holistic view of the application, its operational issues, projects in flight, customer satisfaction, cost
– they probably control the project and operational budget and can more easily make a more realistic determination about the ability of the organisation to make an investment or replacement of an existing application
– they do not need deep expertise, they can call on other expertise, most likely architects, to help with the decision but ultimately as the owner of a portfolio are the people who will have to deliver it. This gives a very healthy dose of reality and objectivity

if i put the TOGAF crop circle in front of an application manager, would they have the faintest clue what i was showing them or talking about?

the answer is almost certainly no

if i put the TOGAF crop circle in front of a business person, would they have the faintest clue what i was showing them or talking about?

absolutely not

so a togaf rebellion…

if I changed TOGAF to about analysis of requirements, design options, costs, benefits, value, implementation time, functionality, usability, and risks would they know what i was talking about?

yes they would

and so i am concluding that TOGAF is a method designed for architects by architects using an abstract and inaccessible language useful only to architects

in my opinion a new method is needed which business people can understand. They can understand that there are specific considerations to determining whether one IT solution versus another is better or not

im afraid terminology like Architecture contract, preliminary phase, and migration planning will never be part of a discussion with the business which i ever have

and perhaps thats why application managers are better placed to have accountability for architectural decisions than architects

is anyone interested in creating a method like the one i suggest, i cannot do it alone…

another set of free togaf question March 30, 2011

Posted by Chris Eaton in Uncategorized.
add a comment

Udayan Banerjee has posted a set of TOGAF 9 multiple choice questions they can be found here ->


togaf 9 certification guide March 29, 2011

Posted by Chris Eaton in Uncategorized.
add a comment

from Nik Ansell


great guide to TOGAF certification January 19, 2011

Posted by Chris Eaton in certification, togaf 9, Uncategorized.


ITIL and Togaf, and a certification on the way November 22, 2010

Posted by Chris Eaton in Uncategorized.
Tags: ,

a couple of weeks ago i did a three day course on ITIL (the IT Infrastructure Library) culminating in the ITIL Foundation exam.

ITIL is a set of high level processes for managing IT from Strategy through delivery, to operations. With a focus more towards Operations than the Strategy end of the spectrum

If you havent heard about ITIL I would strongly encourage you to find out more. It is very quickly gaining traction as the standard for best practice in operating an IT estate.

The exam frankly was straightforeward and I am glad to say I passed (hooray!).

Before the course i was aware of the basic concepts and after attending the course i have a much better appreciation and interest, in ITIL. It is very coherent as a whole. For me, it is an interesting contrast to TOGAF.

ITIL has gone through a radical change from version 2 to version 3 where strong editorial governance has ensured that version 3 overcomes its heritage and makes a clean break from prior versions to successfully make a wholesale restructuring of its content. In all it makes a coherent whole and the individual books makes for a well integrated method spanning strategy to operations

Unlike TOGAF… which seems to have a very weak editorial practice and as a result it a hybrid of new, high quality content from Cap Gemini in version 9 intermingled with weak legacy content from prior editions. In particular it seems wedded to the ADM ‘crop circle’ with redundant phases like Opportunities and Solutions and Migration Planning and meekly justifying their existence.
Other esoteric concepts like the Enterprise Continuum persist (a phrase like this only belongs on Star Trek) when a stronger editorial hand would have done away with all of these concepts several editions ago

i am not sure where i am going with this 🙂 other than to praise ITIL and hope that the open group takes a strong editorial stance in version 10