jump to navigation

Three core skills of an enterprise architect April 27, 2010

Posted by Chris Eaton in architecture, EA, people.
Tags: , , , , ,
1 comment so far

as ever the most stimulating questions come from the populus at large. In response to a question of what skills does an enterprise architect need by Lisa I posted this response

In my mind there are three core dimensions for the skills of an architect:

– Leadership ability
– Technical ability
– Business ability

For leadership – As you become more senior then leadership skills become more important, displacing deep specialist technical skills. Leadership is often defined as the ability to get things done through others which i think is a reasonable take on matters.
Leadership is more about knowing what to do and how to approach problems, achieve buy in and make them happen, than a deep understanding of a subject. Personally in terms of leadership i am very dependant on prior experience on successful projects to guide me as to what to do, and also role models – what would my role model do?

For technical ability – broadly (and matching togaf) you can categorise architects into:
– Application Architecture
– Data Architecture
– Infrastructure Architecture
– Business Architecture
and some might argue integration architecture as it’s own area because middleware is so prevalent and a particularly important area to have good architecture.

Within these domains it is important to have a good level of expertise and have some level of expertise in the others. An application architect with no understanding of data wouldnt be much use.

For Business ability – deep knowledge of a business area or areas and the related business processes is a must for delivering strong business centric solutions


EA and project management January 16, 2009

Posted by Chris Eaton in methodology, methods.
Tags: , , , , , , , , , , ,

i love architecting stuff, my raison d’etre perhaps. Project managers though, they are my antithesis – they are full of difficult questions inhibiting my creative juices, how long will it take? whats the deliverable? what other resources are needed? any risks? what will it cost? ARG!!!! just let me draw my diagrams 🙂

but lets not forget project management altogether, actually applying project management discipline is really important to defining what you want to achieve, what resources are needed to achieve that goal and the plan and execute to make it all happen.

One brilliant tool i will take away from my IBM days is the Project Definition Workshop and the associate deliverable of a Project Definition Report (or project charter) – this sets out right at the start exactly what you are trying to achieve and what it will need to do it, crucially this is held in a workshop format with an independent facilitator with the key stakeholders – this can be a tricky matter to arrange! . The Structure is usually something like this:

  • Goal – one paragraph on the goal of the project i.e. what it is trying to achieve
  • Objectives – things that the project needs to achieve
  • Sponsor and key stakeholders – who are we doing this project for and who needs to be involved
  • Deliverables – what things the project will deliver
  • Tasks – brainstorm all the task needed to achieve the goal
  • Management System / Communications plan
  • Risks/Issues/Assumptions/Dependencies

others agenda items can be added as needed

I have always found this hugely productive and never heard a bad word about the day. It gets everyone on the same page and geared for action

Game Theory and IT Strategy November 20, 2008

Posted by Chris Eaton in EA, methodology.
Tags: , , , , , , , , , , , , , , , , , , , ,
1 comment so far

I am currently reading the selfish gene by Richard Dawkins, it is a fascinating book not least because the thesis draws on research which combines (what i believe to be) previously unconnected analysis techniques like Game Theory with genetics with animal behaviors (ethology).

This really got me thinking how techniques from other fields of science could be used in Information Technology (if you consider IT science, perhaps it is an art!) Coincidentally I work in the field of IT strategy and at university my Computer Science dissertation on the card game of Bridge used aspects of Game Theory to formulate the best strategy for any given hand or game, although I can only consider myself, at best, a ham amateur in all of these fields.  (I am curious now why i never quite put IT strategy and Game Theory together before now, and a quick google search suggests that whilst game theory has ben applied to other areas of IT there it has yet to be applied to IT Strategy which is rather surprising)

Wikipedia defines Game Theory as follows ‘Game Theory attempts to mathematically capture behavior in strategic situations, in which an individual’s success in making choices depends on the choices of others.’

actually I would adjust this to be ‘Game Theory attempts to mathematically capture the outcomes of behaviour in strategic situations…’ I maybe saying the same thing as the Wikipedia definition but i want to stress that the analysis of outcomes are key in game theory not part of trailing secondary sentence, albeit that the analysis can only be as good as the model you construct.

My question is could a model be built which would could analyse different IT strategies and allow decisions to be made based on the outcomes (presumably the best outcome) – crucially Game Theory analyses the strategy in the context of other competitors and their strategies, the implication being that an strategy is only as good as the strategies of your competitors – if their strategy is better you are going to lose.

I would suggest that IT strategy and investment planning today probably does consider alternate investments and their likely outcomes but only in the context of the organisation itself and not the competitors. I suspect the vast majority of organisations call this analysis a business case . The measure of a business case is almost always a definite dollar return like headcount reduction which is convieniently provides a very definite and measurable outcome. However this excludes strategies which may bring a competitive advantage based on probabilistic outcomes (which I will call a ‘soft benefit’ which are outcomes like a probable increase to sales).

My experience is that any CFO is very unlikely to fund a project based on a soft benefit return not because CFOs are closed minded, but because the claimed return of soft benefits has wholly inadequate research and justification. The CFO is making a judgment call on the probability of an investment making the claimed return. In my experience soft benefits are frequently (always?) overstated, they are often highly speculative based on gut feel, they rarely (perhaps never) have good analysis and research behind them which backs up their claims. By using game theory the accuracy of the benefits and probability of a particular strategy success can be improved, perhaps to an extent where a CFO might take a chance.

so in conclusion, and a very unsatisfactory conclusion at that, i would like to build, or see a model built which could do this analysis. Perhaps on the train tomorrow i can think more on this and the likely parameters. At the weekend maybe i will search my loft for some of my forgotten economic textbooks.

Whats the value of TOGAF certification? August 27, 2008

Posted by Chris Eaton in EA, mentoring.
Tags: , , , , , , , , , , , , , , ,

A mentee wrote to me with the following questions on whether TOGAF certification is worthwhile and where it might lead, here is my take on what he asked about…

  • How do I become TOGAF certified?
  • What kind of insight you will be able to give in terms of the Return on investment of TOGAF certification?
  • If I take the TOGAF exam right away what kind of opportunities should I look for and who are the potential employers?
  • At this stage what would my typical work profile be if I get a EA job?

How do I become TOGAF certified?

There are two routes to TOGAF certification, the first is simply to sit the exam, the second is to attend a TOGAF certified course which takes 4 or 5 days to go through all of the TOGAF material and results in certification and there is no exam.  I have TOGAF certification through the course. I have read that the exam is relatively straightforward but like all exams preparation is key and a decent knowledge of TOGAF is needed Take a look at the Open Group website for TOGAF Certification

What kind of insight you will be able to give in terms of the Return on investment of TOGAF certification?

For me TOGAF certification has been a great investment. I achieved certification by taking the certification approved course and I should add that the course was paid for by IBM. My own situation is about to change and I am about to leave IBM to work for another multinational based here in the United Kingdom. My new employer has checked my TOGAF certification credentials and I believe this gives an indication that they considered this very important. I also want to add that holding TOGAF certification alone is not likely to convince a potential employer that you can work as an Enterprise Architect. Some work experience in the Enterprise Architecture area is likely to be very desireable. This leads into the question how do I find my first EA role?  That is a great question, one not easily answered and perhaps the subject for a future post 🙂

If I take the TOGAF exam right away what kind of opportunities should I look for and who are the potential employers?

EA remains a relatively specialised field, it is likely that most work will be with larger organisations. In my mind Enterprise Architecture is very much about the optimisation of available IT spend to ensure that available investment money is directed to strategic IT systems rather than wasting money investing in short term or legacy systems. Larger organisations are more likely to have problems with these aspects of investment since often they have disparate IT offerings and duplicate systems resulting from a lack of coordination across companies and countries or because they are making acquisitions who have made their own IT which may or may not match the IT of the buyer.
In terms of potential employers there is tremendous interest in EA at the moment in all sorts of organisations. You can either look to work directly for organisations like banks, manufacturers, retailer etc, or look for work in an Enterprise Architecture consultancy. If you wanted to move into EA consultancy then most of the large consultancies have EA practices. I know IBM, HP, Cap Gemini all have EA practices and are recruiting at the moment and I am sure there are other smaller or specialised companies in the EA space.

At this stage what would my typical work profile be if I get a EA job?
This is a really good question. EA is very broad in its scope, and the EA means different things to different people and organisations. The major interest area tends to be creating strategic ‘to-be’ architectures which often (always?) includes looking at the as-is architecture and what exists today and making decisions on what the strategic architecture should look like in future. A huge part of EA in general is communicating and selling your ideas and vision.  The main area that I work in is the evaluation of IT offerings against the business processes and business requirements and selecting the strategic applications and middleware to meet those requirements. I would call this Enterprise Application Architect. In my mind there are four technology specialties which coincidently match how TOGAF splits EA into Business, Applications, Infrastructure and Data. In no particular order they are:

  • Enterprise Applications Architect, as described above this looks mainly at creating strategic architectures focussed on software, both applications and integrations
  • Enterprise Infrastructure Architect looking at hardware, networks, operating systems, server locations and capacity etc, and within this further specialization would be Security and Networking.
  • Enterprise Business Architects, looking specifically at business processes design and optimization
  • Enterprise Data Architects looking at data requirements, placement, maintenance and reporting

Deploying or improving governance processes like architecture review boards, IT spend planning and change management is also likely to be part of the work.

So in summary you could be doing anything in the EA space 🙂

IT Architecture Diagrams July 17, 2008

Posted by Chris Eaton in communications, EA, IT Architecture, methodology, methods.
Tags: , , , , , , , , ,

we are coming to the second wave of a major project i am working on which is deploying to over seventy countries. I asked my architecture team to go an find out about the existing architecture of the next set of countries, and some bright spark asked what tool and standards we should use to document this.

For the wave 1 countries I invented an architecture diagramming standard using powerpoint *update* I have written a full detailed explaination of his notation -> here. The major thrust of the architecture work is integration oriented. I’m afraid UML is too detailed, and does not have constructs which show the logical flow – you have to go down to integration diagrams for this. In my mind UML diagrams =  the domain of an application architect and possibly an integration architect. It is not the domain of an enterprise architect or even a chief architect.

I know from prior analysis that there isnt a standard for this higher level diagram. In IBM method terms this is called an Architecture Overview Diagram. In essence  an Architecture Overview Diagram is a diagram which shows an architecture for a specific audiance and/or purpose. In my case the audience is other architects, with the purpose of talking about all of the significant components and all integration points within our direct control, and integrations with systems we have a dependency on; either to retrieve data from them or send our data to them.

In my model each major component is named on the diagram and uniquely numbered. a component could be something large like SAP, or even an abstraction and a collection of components – again SAP is like this, you have the GUI, the backend, you will probably bucket the database as SAP even though it isnt really SAP (in my case DB2).Or, it could be something very granular like a single service. The level of detail in the diagram is dependant on the audience, but none the less powerpoint is the tool of choice 😦

IBM itself uses Qualiware to document its own ‘to be’ Enterprise Architecture. I am not keen on this tool personally.  Maybe it isnt so much how the tool works perhaps it is the way we use it. I can argue that we mix business flows with integration flows and there is variation in the level of detail and what is shown amongst the various business units who document their as-is architectures.

In summary, there needs to be a standard for architecture charts. There needs to be a standard for enterprise architects, there needs to be a standard for chief architects, there needs to be a view for application/integration/infrastructure/network/data architects. It is astonishing that powerpoint is the major tool of choice. There needs to be referential integrity between these diagrams. Today this is manual, it is not enforced by the tooling.

is someone listening and fixing? 🙂 i can only hope!

EA communications plan July 11, 2008

Posted by Chris Eaton in communications, EA, IT Architecture, methods, people.
Tags: , , , , , , ,
add a comment

Communications planning I feel is an oft forgotten part of an EA, even a mature EA. Often, communications is an ad-hoc affair, but planning who you communicate to, what to tell them, when to tell them and then executing against that plan *should* be a substantial part of a good EA practitioner. After all, communications in one form or another is what you are going to be doing 90% of the time.

Communications can take different forms, it could be a regular monthly email, or regular calls to disseminate information, a one on one call, a group call focused on a particular decisions or a website for individuals to find the information themselves. The audience of a particular communication is very important, a is the timing of the communication.

Who, What, When – A communications plan says WHO you are going to communicate with,  WHAT you are going to tell then, and WHEN you are going to tell them.

WHO says that different roles and people need to hear and know about different information. Classic best practices say that executives for instance need to hear and know about different things from solution architects and again there are further role like project managers who should be aware of aspects of the EA like standards and will need to ensure compliance but don’t necessarily understand how the technology needs to work for that compliance

WHAT says what you are going to tell them based on their role, a CIO probably expects a monthly high level update in less than one hour, a solution architect, or group of solution architects may need a one hour meeting to discuss just one new standard which you have introduced, other roles like project managers who own project which need to comply to EA only an awareness.

WHEN says that communications need to arrive at different frequencies for different roles, monthly, weekly, yearly? When can also be triggered, for instance if a requirement changes, or a major event takes place which alters, or could alter, the EA such as a merger of your company or of a competitor, or a change in business strategy, or perhaps even a Black Swan.

In summary most communications should (must) be planned for a specific audiance, of course there are times when the unexpected happens and communications takes the form of hastily scheduled calls or meetings, but the vast majority in a mature EA should be planned.

TOGAF ADM / IBM Enterprise Architecture method comparison June 26, 2008

Posted by Chris Eaton in EA, IT Architecture, methodology, methods.
Tags: , , , , , ,

There was alot of interest in the IBM Enterprise Architect Method post so I am going to expand some more on it. Just to note there is a copyright on the IBM EA method so I cant post actual material unfortunately.
This is a comparison against the TOGAF ADM (the crop circle diagram) since i am thinking this is the framework most people will be familiar with, and the IBM EA Neighborhood model (often referred to as the cyclone diagram). The neighborhoods are akin to the phases in the TOGAF ADM.

Togaf Phase IBM EA Neighborhood
Architecture Vision – outlines the value of Enterprise Architecture The is no direct comparable phase as such in the IBM EA method, but ‘selling’ EA is recognized as a significant part of an EA practitioners job. By selling I dont mean selling with a view to signing contracts, I mean convincing everyone to ‘do’ EA takes buy in across an entire Enterprise, and that is a sizable task.
no direct comparison Strategy – this is very new idea, but says that a organisation has top line strategy of what it wants to achieve, where it wants to be and how it thinks it can get there
Business Architecture Business Architecture – very similar to the TOGAF definition, focuses on business processes independent of technology. Also focuses on organisation structures, business capabilities, business scenarios similar to TOGAF but business scenarios but not at the same level of depth. Also looks at other dimensions of the organization like Roles and Locations
Information Systems Architecture Information systems Architecture – similar to the TOGAF definition focusing on the functional aspects of the current and to-be architecture
Technology Architecture Technology Architecture -again very similar to the TOGAF definition, focusses on meeting non functional requirements like performance, availability, monitoring, disaster recovery, etc. This is my own opinion but i feel this is often treated in at an EA level as a commodity.
Opportunities and Solutions no direct comparison
Migration planning Wrapped into Governance
Implementation Governance Governance – Governance should be articulated through a work product/deliverable (misleadingly) named the Application Management Framework. This defines four things. The to-be architecture, the roadmap and stageposts to the to-be architecture, the governance processes including frequency of architecture review boards, what is reviewed, when something needs to be reviewed, the roles and responsibilities of the Architecture team, and lastly a communication plan – I think this is an interesting placement of a communications plan and it is actually the most critical aspect in my opinion of the AMF. If no-one knows what your doing or why you may as well go home now…
Architecture Change Management Covered within Governance

Referential integrity of architecture artifacts June 18, 2008

Posted by Chris Eaton in EA.
Tags: , , , , , ,
1 comment so far

continuing on yesterdays post i have been thinking some more about how architects could follow a CAD model to constructing software. In this vision a solution architect would drag and drop artifacts from the EA on their architecture solution model. Everything in the solution model must be referenceable to the EA.

This drag and drop model is easy to conceptulise when thinking about creating a diagram of an architecture – an architecture overview diagram – you could drag and drop user types, or business locations, or existing components, et cetera.

However quite alot of architecture artefacts are not diagrammatic models like this. For instance, Architectural Decisions – that is a document detailing the reasoning for doing something one way rather than another is not something I have ever seen put on an architecture chart or model – but it could be – I am thinking that a reference to the architectural decision could be placed on a diagrammatic representation of an architecture. Different elements like architectural decisions could be switched on and off to suit the type of user who would be looking at that version of the diagram.

I took a stab at the key requirements for delivering a CAD solution – and eventually we would want CAM too.

1 – we would need to agree what EA artifacts exist and are needed for solution architecture.

2 – We would need to agree a list of architecture solution artifacts which are needed. Some would be mandatory others optional.

3 – In building architecture diagrams there are conventions which allow architects and builders to understand what is to be built, we would need similar conventions too – UML is in this space but it is at a more detail level than I envisage.

4 – referential integrity between the EA and solution architecture must be maintained. Whilst developing a solution architecture changes may be needed to the EA through genuine change or finding an omission.

5 – There needs to be referential integrity between the artifacts at the solution architecture level – change one and the other is updated too.

6 – It must be possible to (easily) drag or reference items from the EA repository in the solution diagrams. The solution architect will refine these to the next level of detail, but the stereotype or template must come from the EA.

7 – It must be possible to allow exceptions to the EA where there is approval to not follow the EA for some good reason

8 – any diagram should support switching off or on different notations and ‘things’ on the diagram.

I am sure there are others…