Many thanks for the questions. The answers quite long so I’ve done it as a new post, at
http://weblog.tomgraves.org/index.php/2008/07/02/togaf-and-soa/ – hope this helps?

Best etc
- tom g.

My foucs is on extending TOGAF to include SOA.
My apporach was to add SOA as a cross-cutting architecture (cutting across BA,ISA,TA & also the governance of TOGAF (since SOA also needs SOA governance).

Rolland has also suggested a nice approach above of having SOA in place of IA and making IA a horizontal.

How do you guys compare these 2 approaches and is there any other way around for customizing TOGAF for SOA ?

Zachman doesn’t have a columns suited presentation/interfacing – because it developed in 1987 (when systems had a very different audiences, purposes and mechanisms for systems and user interfaces). These problems become increasingly acute as ICT systems become increasingly communications oriented, multimodal, ubiquitous and interconnected. Issues arise even in ICT design when using Zachman e.g. NW/platform design resides in the where column (this was valid when the major costs of ICT systems were CPU, bandwitdh and memory – but now platform design is driven by other things i.e. not predomintly by location). Ironically location is becoming more important for other reasons. Likewise the who column is used for most of the control mechanisms (oriented around security) – because in 87 many forms of attacks where essentially not possible on the closed systems of the day.

TOGAF’s audience and adherents are usually oriented at ICT and don’t usually purport to go beyond it. TOGAF illustrates its orientation by looking a lot like a CASE method (Cf. RUP), and not very much like a business planning method. What TOGAF fails to do most critically is put the control of the primitives and composites under their natural owners (who are almost always not the people doing the EA work) i.e. it doesn’t focus on establishning mechanisms to allow the EA knowledge to be naturally accrete
with out any additional cost to the enterprise (which is how successful knowlege bases operate). This requires adjustments to processes that produce/consume the knowledge. The result of EA is not an aftefact/document (Cf. Encyclopedia Britannica) – it is really a library (a knowledge base Cf. Wikipedia).

A related issue is that none of the knowledge above can be managed in documents (Word, Powerpoint, Visio, stone slabs or papyrus etc.). It may be presented as/in documents – but that is a different issue. In well over a decade in this area I have never seen an organisation achieve an EA using documents that is: maintainable, accessible, current, accurate, affordable, etc. No one would today attempt far simpler modelling tasks i.e. with 3-4 primitives e.g. ER modelling, project planning – without the benefit of a knowledge modelling system. Zachman et al suggest not 3-5 primitives (as per project plans) but 30-50+. Another issue is that one uses the term architecture and in all other areas of complex design (PCBs/electronics, planes/trains/cars, cities/buildings, organisations/processes etc.) the need for visual representations is well recognised.

So in summary – one find the right solution unless one:
- gets a common definition of EA (i.e. that extends beyond ICT)
- accepts that Zachman is a useful construct (a taxonomy, primitives, composites) but is out of date.
- recognizes EA is not CASE (or CASE like) i.e. it is knowledge management and therefore needs to focus on how know accretes (but it must relate to CASE tools, and other tools/knowledge bases)
- knowledge (e.g. models consisting of aggregates of inter-related primitives) can’t be managed on paper.
- getting people to share knowledge has its own intrinsic challenges.

Phase B: ‘Business’ – high-level strategy, policy and structure (primarily Zachman rows 1 and 2)

Phase C: ‘Common’ (i.e. your “cross domain architecture”) – concept and design-level views across the whole architectural space (primarily Zachman rows 3 and 4)

Phase D: ‘Detail’ – the detail-level descriptions of implementation and run-time (primarily Zachman rows 5 and 6)

Doing the cut this way, we end up with a clean way to handle non-IT aspects of cross-domain architecture and implementation – which TOGAF 8 bundles in its entirety into ‘Business Architecture’. Data-architecture and application-architecture become just two of many examples of cross-domain architectural logical and physical designs; as you say, service-architecture (How + Who etc) is another, as is security-architecture (How + Why etc), information-architecture (What + Why etc) and so on.

But I abandoned that cut, for two reasons.

The first was that, with this cut, we can only do the kind of massive six-month-plus “review the whole damn architecture of the whole damn enterprise” effort indicated by the standard approach to TOGAF. What we dealt with in architecture practice was often much smaller: often all we needed was a half-hour scan through the repository to assess the impact of some minor change or failure. I wanted a methodology that could be used consistently for every variation of architecture assessment, and that would also align with standard project/programme governance methodologies such as PRINCE2. By rethinking Phase A, as setting the scope for the cycle, and then using Phase B, C and D as as-is, to-be and gap-analysis respectively to assess the architecture of that scope, we end up with something much more flexible, and much more aligned to governance. Service-architecture, security-architecture and so on then change from something we only look at in design-time (your version of Phase C) but become perspectives into the _whole_ architecture, consistently, right the way through all the Zachman levels from ‘universals’ to run-time.

The other reason was, again, for alignment with PRINCE2. If we do the standard TOGAF cut, we end up with a separate stakeholder-review for the as-is, to-be and gap-analysis in _each section of Phases B to D: that’s a minimum of _twelve_ stakeholder-reviews, often with the same stakeholders. To be blunt, that ain’t gonna fly in any real-world business environment: no-one has that amount of time to spare. With the cut I’ve suggested, we end up with just three reviews, one at the end of each of Phase B to D; and in effect, governance forms the boundary between each Phase. A heck of a lot cleaner; a heck of a lot easier to ‘sell’ to business.

That’s just my opinion and experience, though: any suggestions on this?

My statement is change Togaf Phase C in Enterprise Service Architecture and position information architecture as a cross domain architecture much like security. Please don’t mix my statement with SOA as a technological thing. I mean enterprise services , the service portfolio that serves and fits strategically with the business architecture.

If this phase C would be replaced Togaf aligns with more modern languages like the Archimate language that also adopts the service concepts between architectural layers.

Regard
Roland Ettema, Management Consultant LogicaCMG

And yes, I’d agree that “does the client understand it?” is an important criterion – but not the only one. “Does it work as architecture?” is also important…

What I’m aiming for here is to find some way to reuse all the investment (financial, intellectual and otherwise) in Zachman and TOGAF and the like, in ways that will actually work at the full enterprise-wide scope – because as they stand at present, they don’t work for anything other than a pure IT-centric scope (and not all that well even at that, anyway). My point is that architectural analysis should not be about IT-centric academia (your ‘paper generators’), but should always start and end with business-oriented questions, for example:
- “what is the impact of this change in strategy / legislation / policy etc?” – i.e. top-down strategic analysis
- “what is the business impact of this component fails?” – i.e. bottom-up risk or failure analysis
- “how can we reduce costs?” (or, better, “how can we improve overall effectiveness”? – i.e. side-to-side analysis
- “how can we resolve this business pain-point?” – i.e. start-anywhere-and-spiral-out analysis

I’d agree that the original Zachman and TOGAF are nearly useless for business questions such as these. But a reworked, non-IT-centric Zachman-type structure really does help in framing the content , context and scope of the analysis, and in drawing the key distinctions between primitives (on which we should base compliance) and composites (on which we shouldn’t, because we would enshrine temporary constraints as permanent requirements). And the reworked TOGAF provides the discipline of governance-frameworks in which to do the analysis and then put it into business practice.

Once we’ve done the architectural analysis at that abstract level, yes, we do need to translate back into the specific terms and views of the respective audience-group – often many times over, for very different audiences. But we only do that translation when the analysis is complete – not before – otherwise we’ll get completely lost trying to maintain all the different views at once.

The part I still haven’t fully worked out is how to get any of the damn toolsets (and, for that matter, their vendors) to understand that there is no such things as a fixed ‘future-state’: the world is dynamic, not static. But that’s another story for another post. In the meantime, thanks again for your engagement in this one!

-tg

Best regards, Michiel