TOGAF – well I finally did it ( here’s the summary)

TOGAF
I couldn’t find a readable short summary anywhere so I decided to bear the pain, skim read the dull text and write a summary for any unfortunate person trying to get a quick overview of a new framework in an industry he/she already knows well.
My conclusion after a few hours of wading through the treacle is that it is well put together, if horrendously poor in it’s presentation.
A slight contradiction is that parts are already a bit outdated in that it pays too much attention to things like portability in a world where interoperability is the buzz word and the “cloud” and “tower of babel” are the modern metaphors, nevertheless any slight shortcomings can easily be overcome by intelligent people using it.
A sharp warning though is that; even more so than the ubiquitous Prince2 for project management, TOGAF won’t make an architect of you, you have to bring all the skills to the table and then it helps you get things in the right order, but even that is up for interpretation, so you really must know your stuff and have integrity
It is not therefore a reliable hiring tool in it’s own right and I see it as definitely a team game.
TOGAF calls itself a Framework, but the main body of it is ADM which is in fact a process for doing architecture.
It follows the usual pattern of breaking up enterprise architecture into four logical steps (steps because it is a process)
The technical architecture uses a method closely allied to the idea of inheritance in OOD whereby the patterns and principals are inherited from more generic ones and you then build something more specialised on top of all that.
E.G.
Organisation specific ( This is the innovative bit)
Industry specific ( This is common to all organisations in a specific industry and saves a lot of time)
Common Architecture ( This varies little from one organisation to another therefore requires a little more effort than foundation, but saves much effort)
Foundation architecture ( This doesn’t vary much from one organisation to another therefore requires little, or no effort)
They call this idea the “Enterprise continuum”
Questionable ideas
Things I would question:
1.The Foundation architecture specifies knowledge bases that you need to develop such as a set of standards and a Technical reference Model. This part is potentially futile in that:
a.constant change often makes last years standards out of date, but nobody ever updates these things
b.notwithstanding the previous comment, experience suggests that few people ever refer to them even in some big name software houses.
2.Developing business processes and storing them away gets mixed reactions.
a.Many processes are defined by and governed by the existing productivity systems and in any case may even have no scope for change, so what will you gain from low level process views?
b.The speed of change is such that keeping recorded process up to date will be more of a chore than a benefit in many businesses.
c.If you can set this at a high enough level such as business goals and strategy it is very useful, but then the benefit depends on the audience who will access it, or ignore it. The jury is out.
d.The right place in my view for business process analysis is Opportunities and solutions phase and the key to this is JIT (as per the Agile principal) if you want relevance and accuracy. In my opinion,  nobody in their right mind would invest a large sum on a solution based on old archived process diagrams at least not any experienced business analyst.
e.Finally new systems generally herald a new process, or new approach to the goal and therefore brand new processes. As-Is modelling is only an exercise to extract the business rules in order to build a better process against them, otherwise, who needs a history level in a manic business world?
3.I don’t see a Zachman like illustration that lets a business stakeholder engage with it on a business level without struggling with the gibberish. If I am right about this, then it could be a downfall, because it will end up just a techie thing behind the doors of IT and the business stakeholders look skywards at the mention of it. This is very common and would negate most of the effort.
You only have to attempt to get some sense out of the Open Group website to see what I mean. If reluctantly, at least I was able to suffer it and get a glimpse of the big picture, I can’t see anybody form a business background touching it with a bargepole. I think the implementation needs to be aware of this and cover up for the shortfalls.
4.It’s a techie invention and although pretty good once you uncover it, it was “not invented here”.
5.The Migration Planning function is a potential route to serious friction. Modern business won’t stand for an IT function that wants to “wag the dog”. When they want it in three months because it is important, no amount of processes will stop them and I have seen many big rows break out over this. I recently saw a head of projects and a director resign within two weeks of each other over rows based on this function.
ADM
The process looks something like this:
The colour coding is a suggested classification based on my interpretation and my own experiences, but I fully expect to be contradicted as I did spend a only a few hours on this and concluded the following:
Pale Blue box – CTO/CIO/Technical architect and/or Enterprise architect.  Plenty of sign-off seems to be the order of the day.
Black box Technical architect’s role but very much in collaboration with the IT function, who will have to implement it and keep it running. Often the ITIL process sits between the black boxes and the rest of the process.
Red box  – Business focused business analyst and I would say a lot of verification needed to make sure the techies don’t build a toy when nobody is looking.
Green box  – Data analyst and systems analyst
Purple box –  Business analyst role working with the business to identify opportunities, develop business cases and priorities shortlists
Blue box –Test, or QA manager and UAT signed off by  Business Analyst and UX manager.
As a rough guide the phases look something like this:
Framework and principals
1.define the scope of the project,
2.adapt the ADM process to your situation
3.identify constraints, document the business requirements, and
4.establish high-level definitions for both the baseline (starting) architecture and target (desired) architecture.
Business architecture
1.business modelling,
2.highly detailed business analysis, and
3.technical-requirements documentation.
Information systems architecture
1.develop baseline data-architecture description
2.review and validate principles, reference models, viewpoints, and tools
3.create architecture models, including logical data models, data-management process models, and relationship models that map business functions to CRUD (Create, Read, Update, Delete) data operations
4.select data-architecture building blocks
5.conduct formal checkpoint reviews of the architecture model and building blocks with stakeholders
6.review qualitative criteria (for example, performance, reliability, security, integrity)
7.complete data architecture
8.conduct checkpoint/impact analysis
9.perform gap analysis
Technical architecture
The infrastructure necessary to support the proposed new architecture.
Opportunities and solutions
Evaluates the various potential solutions and prioritise the ones that deliver most.
This is about business cases and stage gates and good financial analysis, but it is also about good business instinct and gut feel and requires business people to make the decisions in possession of the best possible information.
Migration planning
This is mostly programme management in that it involves acting on the outputs of the previous step to plan the flow of project through system taking into account opportunity and dependencies.
Implementation governance
This is most closely aligned to QA functions in project and programme management
It sets the acceptance criteria
Architectural change management
This is about updating the change management documents with details of new additions. For me, this is better handled by ITIL and as a PM this normally means an agreed handover to IT as part of the implementation and rollout plans.
Once in place
After the first implementation, I interpret it that the business will engage with the Opportunities and Solution function which triggers a quick iteration of the previous steps of ADM to make any required adjustments and the new solution progresses through the remaining stages.

TOGAF

I couldn’t find a readable short summary anywhere so I decided to bear the pain, skim read it and write a summary for any unfortunate person trying to get a quick overview.

My conclusion after a few hours of wading through the treacle is that it is well put together, if horrendously poor in it’s presentation.

A slight contradiction is that parts are already a bit outdated in that it pays too much attention to things like portability in a world where interoperability is the buzz word and the “cloud” is the modern metaphor, nevertheless any slight shortcomings can easily be overcome by intelligent people using it.

A sharp warning though is that; even more so than the ubiquitous Prince2 for project management, TOGAF won’t make an architect of you, you have to bring all the skills to the table and then it helps you get things in the right order, but even that is up for interpretation, so you really must know your stuff and have integrity. It is not therefore a reliable hiring tool in it’s own right.

TOGAF calls itself a Framework, but the main body of it is ADM which is in fact a process for doing architecture.

It follows the usual pattern of breaking up enterprise architecture into four logical steps (steps because it is a process)

The technical architecture uses a method closely allied to the idea of inheritance in OOD whereby the patterns and principals are inherited from more generic ones and you then build something more specialised on top of all that.

E.G.

Organisation specific ( This is the innovative bit)

Industry specific ( This is common to all organisations in a specific industry and saves a lot of time)

Common Architecture ( This varies little from one organisation to another therefore requires a little more effort than foundation, but saves much effort)

Foundation architecture ( This doesn’t vary much from one organisation to another therefore requires little, or no effort)

They call this idea the “Enterprise continuum

Questionable ideas

Things I would question:

1.The Foundation architecture specifies knowledge bases that you need to develop such as a set of standards and a Technical reference Model. This part is potentially futile in that:

a.constant change often makes last years standards out of date, but nobody ever updates these things

b.notwithstanding the previous comment, experience suggests that few people ever refer to them even in some big name software houses, so only do it if you can enforce it.

2.Developing business processes and storing them away gets mixed reactions, I suspect that this should be built up over time as and when you have occasion to look at particular areas of process.

3.I don’t see a Zachman like illustration that lets a business stakeholder engage with it on a business level without struggling with the gibberish. If I am right about this, then it could be a downfall, because it will end up just a “techie” thing behind the doors of IT and the business stakeholders look skywards at the mention of it. This is very common and would negate most of the effort.

You only have to attempt to get some sense out of the Open Group website to see what I mean. If reluctantly, at least I was able to suffer it and get a glimpse of the big picture, I can’t see anybody from a business background touching it with a bargepole. I think the implementation needs to be aware of this and cover up for the shortfalls.

4.It’s a techie invention and although pretty good once you uncover it, it was “not invented here”.

5.The Migration Planning function is a potential route to serious friction. Modern business won’t stand for an IT function that wants to “wag the dog”. When they want it in three months because it is important, no amount of processes will stop them and I have seen many big rows break out over this.

ADM

The process looks something like this:

ADM process
ADM process

The colour coding is a suggested classification based on my interpretation and my own experiences, but I fully expect to be contradicted as I did spend a only a few hours on this and concluded the following:

Pale Blue box – CTO/CIO/Technical architect and/or Enterprise architect.  Plenty of sign-off seems to be the order of the day.

Black box Technical architect’s role but very much in collaboration with the IT function, who will have to implement it and keep it running. Often the ITIL process sits between the black boxes and the rest of the process.

Red box – Business focused business analyst and I would say a lot of verification needed to make sure the techies don’t build a toy when nobody is looking.

Green box – Data analyst and systems analyst

Purple box –  Business analyst role working with the business to identify opportunities, develop business cases and priorities shortlists

Blue box –Test, or QA manager and UAT signed off by  Business Analyst and UX manager.

As a rough guide the phases look something like this:

Framework and principals

1.define the scope of the project,

2.adapt the ADM process to your situation

3.identify constraints, document the business requirements, and

4.establish high-level definitions for both the baseline (starting) architecture and target (desired) architecture.

Business architecture

1.business modelling,

2.highly detailed business analysis, and

3.technical-requirements documentation.

Information systems architecture

1.develop baseline data-architecture description

2.review and validate principles, reference models, viewpoints, and tools

3.create architecture models, including logical data models, data-management process models, and relationship models that map business functions to CRUD (Create, Read, Update, Delete) data operations

4.select data-architecture building blocks

5.conduct formal checkpoint reviews of the architecture model and building blocks with stakeholders

6.review qualitative criteria (for example, performance, reliability, security, integrity)

7.complete data architecture

8.conduct checkpoint/impact analysis

9.perform gap analysis

Technical architecture

The infrastructure necessary to support the proposed new architecture.

Opportunities and solutions

Evaluates the various potential solutions and prioritise the ones that deliver most.

This is about business cases and stage gates and good financial analysis, but it is also about good business instinct and gut feel and requires business people to make the decisions in possession of the best possible information.

Migration planning

This is mostly programme management in that it involves acting on the outputs of the previous step to plan the flow of project through system taking into account opportunity and dependencies.

Implementation governance

This is most closely aligned to QA functions in project and programme management

It sets the acceptance criteria

Architectural change management

This is about updating the change management documents with details of new additions. For me, this is better handled by ITIL and as a PM this normally means an agreed handover to IT as part of the implementation and rollout plans.

Once in place

After the first implementation, I interpret it that the business will engage with the Opportunities and Solution function which triggers a quick iteration of the previous steps of ADM to make any required adjustments and the new solution progresses through the remaining stages.

I remember having very similar thoughts about Pricne 2 when I first tackled it, so I wont be put off.

Perhaps I am one of the stronger proponents of Enterprise Architecture as a means to avoiding meltdown, avoiding waste and keeping the IT funciton focused on value added activities. For this reason I have decided to suffer the pain and see this through.
Maybe I will then get the courage to write a consumable version of this to win back the many talendted and desperately needed people who surely must have been alienated form the profession by the manner in which this is presented.

 

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.