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.
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”
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.
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.
2.highly detailed business analysis, and
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
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.
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.
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.