TOGAF 9 Certification Scenario Questions October 7, 2009
Posted by chriseaton in togaf 9.Tags: TOGAF, togaf 9, togaf 9 bridge exam, togaf 9 bridging exam, togaf 9 certification, togaf 9 certification question, togaf 9 sample questions, TOGAF certification, togaf certification questions, togaf questions, togaf sample questions
1 comment so far
following on from the example multiple choice questions here are two scenario questions.
I will endeavour to write a few more but these should give you a sense of the question format and what the exam is looking for in terms of the ranked answers
download the sample scenario questions
download the multiple choice questions
TOGAF 9 Certification Multiple Choice Questions August 24, 2009
Posted by chriseaton in Uncategorized.Tags: Certification, togaf 9, togaf 9 certification, togaf 9 certification question, togaf 9 exam questions, togaf 9 multiple choice questions, togaf 9 sample questions, togaf certification questions
5 comments
there has been a lot of requests for TOGAF 9 questions so here is a set I made up for the multiple choice sections of the Certification and Bridging exams. I have not taken the exam yet but i have seen some of the example test papers
*** update*** download the TOGAF 9 part 2 exam examples – these are the scenario questions
enjoy!
I should be taking the exam myself in the next couple of weeks, just as soon as our overdue baby arrives…
TOGAF 9 July 14, 2009
Posted by chriseaton in EA, IT Architecture, architecture, architecture method, artitecture, methodology, methods, people.Tags: architecture, enterprise architecture, TOGAF, togaf 9
1 comment so far
the last 2 days i have been attending a TOGAF course run by cap gemini who have made the majority contribution to the latest version of TOGAF
The good
so i learnt that many of my criticisms of TOGAF 8 have been addressed. Specifically it adds:
The Architecture Content Framework which is a library of prior architectures to stimulate reuse and reuse of best practice rather than reinventing the wheel
A meta-model which includes specific artifacts which result from each of the phases i.e. what you should produce and when, this was absent from TOGAF 8
An architecture capability framework which recognised that good architectures result from consistently trained architects with a high level of education and experience. At the end of the day your architectures will only be as good as the people who developed them
TOGAF is now more obviously applicable to solution architecture, when previously i saw it much more in the enterprise/strategic architecture space
The bad
the vapourware of the enterprise continuum remains this is still poorly described and arguably redundant. The continuum was always poor conceived and in-specific now it is super seeded by the Architecture #Content Framework, It is a such a shame the open group cannot shed this kind of legacy and have much stronger editorial process.
The Architecture Development Method still does not split out data and application architecture, this is stil bucketed under Information System Architecture,. Other areas of the open group like the IT Architect Certification recognising that these are separate significant activities. Again it seems the open group is so wedded to the ADM crop circle diagram it cannot, or will not, move forward and improve on prior thinking
The ugly
well nothing was that ugly to be honest, togaf version 9 is is definitely a step forward
how do I become an enterprise architect? May 14, 2009
Posted by chriseaton in EA, architecture, artitecture, mentoring, methods, people.Tags: architect, architect skills, breadth, careers, enterprise architect, how do i become an enterprise architect, IT specialist, skills, skills roadmap, spheres of influence, technical depth, technology
1 comment so far
in a recent discussion with a mentee the question was raised ‘what is the difference between solution and enterprise architect?’
My standard answer to this is to talk about the difference between cityplanners who think about city wide infrastructure and future objectives (enterprise architects) and architects of individual buildings who think about how the house is laid out, how strong roof supports need to be and whether their plan will fit to the city planners constraints.
the next question was, ‘ok how do i become a city planner?’
interestingly the city planner/building architect planner analogy does not answer this question, it simply states a comparison of job roles. So after a little thought here is my answer:
Specialists
in essence as a developer (a specialist in IT) you know lots about a specific IT subject matter. For instance you know how to write J2EE applications, test the code, deploy this into a container, use an integrated development environment and so on. Detailed stuff. In terms of exposure to different types of technology the experience is fairly narrow, working with specific technologies and probably with little care whether the solution is in a Human Resources, Finance, Supply Chain, Procurement and so on.
As a specialist you have some understanding of a particular business area but little thought or care for business strategy.
This growth in business and technical exposure leads to a point where there is a choice: remain specialised or loss the specialism and become more broadly focused – become an architect orchestrating the build but not directly building (rule of thumb says if your write code regularly you are probably not an architect).
Your sphere of influence is your code and immediate team.
Interpersonal skills are not so important as long as the code works!
Architects
Within the architect space the breadth of technical experience grows, but the hands on technical experience is shallow. On occasion deep dives return you to the specialist space.
You have the experience and credibility from the specialist experience to generalise, relate and guide specialists without ever having to have directly worked with the technology.
The trick here is to use specialists for their specialist skills, and bring this together at the solutions level.
In business terms you have probably medium to deep understanding in one or two or perhaps more business areas.
In strategic terms you probably have thought about business strategy within a business area i.e. Finance or Supply Chain, but probably not in a true enterprise sense.
Your sphere of influence is the other architects and technicians on your immediate project. You act as a consultant to key business and project management staff on your assigned project
Interpersonal skills are becoming increasingly important to communicate your ideas and sell them to your immediate project team.
In my own experience moving from a specialist to an architect I clearly decided my time with code was done, and i had a great model who i strong thought ‘i want to be like him and do the job he does’ I still count this role model as one of my best friends
The transition to an architect did stretch me, it was difficult to give up the security of specialisation but it was a decision i never regretted.
Enterprise Architect
you have very broad and shallow exposure to all kinds of technology and business area with depth in some areas. You have a good understanding of technology and technological concepts but the detail isnt of significant interest but the impact it can make is very interesting particularly how it could reduce the cost of doing business or differentiating the business in market.
In strategic terms, and for me this a key differentiator for Enterprise Architects, you have a good understanding of business strategy models (i.e. Porter), think in broad business and IT terms and can apply this knowledge to sell a vision of the future, the benefits of the future vision and how it can be realistically achieved.
Interpersonal skills become a critical success factor especially negotiation and influencing. Selling is probably the most important skill. It is required to achieve buy-in for visionary ‘to-be’ solutions at all levels of the business
Your sphere of influence is to aim for company wide impact through process or IT change and influence people who didnt even know they needed influencing!
My own experience of moving from architect to enterprise architect was similar to my transition from specialist to architect, i felt i was giving up a comfort blanket in business and technology architect specialisation for a very broad, perhaps somewhat inspecific role with an emphasis on strategic and inter personal skills, and not too emphasis on technology expertise – something which i had always seens as a personal strength and passion – but again i never regretted the move it was right at the time and i really enjoy the influencing aspects to my EA roles.
In summary, I hope it is clear that business, technology breadth and strategic business thinking is way to become an Enterprise architect, it will take work, it will take opportunity and a good dose of sponsership but in my view it is well worth it.
Architecture method template work products / artefacts March 24, 2009
Posted by chriseaton in IT Architecture, architecture, architecture method, artitecture, methodology, methods, total lifecycle thinking.Tags: building IT solutions, architecture, solution architecture, technology, IT Architecture, application architecture, integration architecture, infrastructure architecture, architecture method, solution architecture method, non functional requirements, architecture risk, architecture decisions, systems lifecycle, technical architecture, architecture framework, data architecture, component architecture, nfrs, solution scope, architectural risk, IT Architect, solution design, architecture diagram, architecture methods, software architecture design methods
add a comment
Following on from previous posts below are links to all the work products in the artITecture architecture method. The work products contain suggested formats and advice for completing them. The templates are intended to be just that; templates, customiseable to your own use.
| Work Product Name | Download Link |
| Architecture Decisions | Link |
| Architecture Overview Diagrams | Link |
| Architecture Risk and Mitigation Plan | Link |
| Architecture Scope and Context | Link |
| Change Cases | Link |
| Component Architecture | Link |
| Data Architecture | Link |
| Decision Model | Link |
| Functional Requirements | Link |
| Infrastructure Architecture | Link |
| Integration Architecture | Link |
| Non Functional Requirements | Link |
| Technology Assessment | Link |
Architecting for the complete systems lifecycle March 5, 2009
Posted by chriseaton in IT Architecture, architecture, architecture method, artitecture, methodology, methods, total lifecycle thinking.Tags: architecture, technology, IT Architecture, architecture method, method, waterfall, systems lifecycle, it-it gap, service delivery, artitecture, total liifecycle thinking, technical architecture, architecture methodology, architecture framework
add a comment
Architecture is often focused on the implementation of a successful solution and it is easy to understand that the immediate concern of an architect and the project itself is to successfully go live.
I suspect that few (perhaps even zero!) architects or indeed project managers are incented on the long term success of the implementation and success of a solution over a number of years. The following diagram is my own version of the waterfall model.
The model looks pretty close to any other version of the waterfall model, but includes linkage to IT Strategy and Enterprise Architecture, and at the tail end to Service Delivery, Service Management and the eventual decommission of the system. The architectural thinking should included all these phases. The later end is often forgotten with little consideration to how Service Delivery/Service Management will run, diagnose, recover and ensure the solution meets the required service levels. This is often referred to the IT-IT Gap, where the implementation project does not talk to the service delivery/service management world, and at handover from project to run… there are issues which could have been avoided by total life cycle thinking.
The artITechiture solution architecture method makes explicit reference to each phase in the recommended documentation, the documentation should be considered both a formal document but also a prompt for thinking about all aspects of the systems life-cycle.
artITechitecture Solution Architecture Method March 4, 2009
Posted by chriseaton in IT Architecture, architecture, architecture method, methodology, methods.Tags: architecture, solution architecture, technology, architecture diagrams, risk, architecture method, architecture methodlogy, method, architecture overview, change cases, solution architecture method, project lifecycle, waterfall, non functional requirements, architecture risk, architecture decisions
add a comment
Today I am publishing the artITecture architecture method. This is a complete architectural method to think about and document a solution level architecture. An overview of the artITecture method can be found in this presentation.
All work product descriptions and templates can be downloaded from this page.
This is the first draft, comments are corrections are welcomed, i am certain it is not error free nor that I have managed to consider every aspect of solution architecture – more minds will improve it.
I am particularly interested in contributions to data and infrastructure architecture, i will credit any contribution but it must be given freely and without any copyright implication.
EA and project management January 16, 2009
Posted by chriseaton in methodology, methods.Tags: EA, enterprise architecture, methods, planning, project charter, project definition, project definition document, project management, risks, sponsor, task, technology
3 comments
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
my hearing is going? November 24, 2008
Posted by chriseaton in Uncategorized.Tags: misheard, misspoke, phraseology, pint
add a comment
i dont usually do personal posts, but two oddities in one day forced my hand, although I cannot decide if it was clever phraseology or wishful mishearing…
on an advert reading a phone number out the reader got to 411 and instead of say ‘four, double one,’ said ‘four double fun’
and on the train some guys drinking a few tinnies posed the question ‘is there a pint of no return?’
Game Theory and IT Strategy November 20, 2008
Posted by chriseaton in EA, methodology.Tags: business strategic, business strategy, CFO, EA, economics, enterprise architect, enterprise architecture, game theory, hard benefits, investment, investment planning, IT strategy, mathmatical analysis, opportunity, portfolio planning, probability, risk, selfsih gene, soft benefits, technolgy, technology
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.

