Copyright Avancier Limited. All rights reserved.
To oversimplify only a little, TOGAF 9 contains TOGAF 8 which contains TOGAF 7. That is mostly a good thing.
TOGAF 9 focuses even more on business capability and business change. It talks more about business strategy, business structure and business change - as well as IT strategy, structure and change.
The big challenge is editorial control. Different authors, writing at different times use the same words in different ways. Not all of them are good writers. Not all of them fully understand the material they are extending. New contributions are not fully coordinated and integrated with the old. Sometimes new authors don’t appreciate how their contribution should integrate with older contributions. Sometimes the editors don’t realise they need to update older contributions. The result is a tough read, not entirely consistent.
1) Human activity systems are treated as scaled-up software systems. Every level of system decomposition is described using the same highly generalised entities: function, service, capability etc.
2) Concept are defined in 1:1 and 1:N relationships, despite the fact that hierarchical decomposition of those concepts makes these statements untrue.
3) Authors seem not to distinguish system decomposition (into components) from process decomposition (into steps).
4) Authors use many synonyms, or appear to:
“Business services are specific functions”. P99
“The term ‘‘function’’ is used to describe a unit of business capability.” P359
So Business service = Business function = Business capability.
“… a business service to be a unit of business capability” p244
“A business capability can be thought of as a synonym for a macro-level business function.” p86.
So again, Business service = Business capability = Business function.
5) The term function is used inconsistently for system and process.
6) The term service is used inconsistently for the interface to both a system and a single process.
The new and explicit meta model contains 25 entities, 74 relationships and some challenging puzzles.
1) Of the 120 relationships listed, many are reverse-phrasing relationships. But 4 of those reverse-phrasings are missing and unaccounted for.
2) The explicit meta model differs to some extent from the implicit meta model – revealed by analysis of the text of ADM, Business Scenarios and III-RM.
3) The explicit meta model is missing some entities and relationships that appear significant in the text. Possibly missing entities: Business Domain, Business Requirement, Technical Requirement, Principle, Standard, Network. An obvious missing relationship: Organisation Units Are Given Goals.
4) 24 of the relationships are recursive, and not shown in the meta model diagram.
5) 16 of the 25 entity types are recursively decomposed in a hierarchical structure. Again, some authors give definitions of the entities that conflict with these hierarchical decompositions.
6) 9 of the 25 entity types (e.g. Event) are not decomposable, but they should be.
7) Entity is ambiguous - can be either a data store or a data flow.
8) Goal and objective would surely better be merged into one hierarchically decomposed entity type.
9) The explicit meta model separates the logical and physical versions of three and only three entity types: Data Component, Application Component and Technology Component. You might argue there is a fourth, since Business Function and Organisation Unit are logical and physical versions of the same entity type. Why divide any? Why only these three or four?
10) The explicit meta model does not contain logical and physical versions of other entity types (e.g. Business Service, Capability, Event). This makes it difficult to draw the right relationships. E.g. The meta model says we map business service to business function, but if the business service is a real one, then the correct mapping is the one declared in the text – that is, business service to organisation unit.
11) Capability and Work Package are related to nothing but each other.
A tabular meta model often (usually?) has the form: plurals - relate to - plurals. Meaning the relationships are N to N.
The TOGAF 9 meta model has the form: singular - relates to - singular. Obviously, they cannot all be 1 to 1!
Pages 98, 99, 244, 247, and 359 appear to be the ones where you would hope the cardinalities become clear, and the meta model is applied.
I have listed below what the text implies. I haven’t checked against the meta model yet.
GOOD
Some of the text is in accord with TOGAF 8 and traditional understanding, leading readers to draw these correspondences.
1 Business function = N Organisation units
1 Organisation unit = N Business functions
1 Organisation unit = N Business services
1 Business service = 1 Business capability.
1 Business service = 1 Interface = N Consumer contracts.
IN NEED OF SKILLFUL INTERPRETATION
There are some specifically misleading statements, but it is relatively easy to deal with them
The bigger challenges lay where readers can draw these various conclusions from the text.
1 Business function = 1 Business service.
1 Business function = N Processes.
1 Business service = N Processes.
1 Business service = 1 Function.
1 Function = 1 Process.
1 Business service = N Functions.
1 Business service should not need > 1 Application component. (Which contradicts the III-RM of course.)
I’m not sure the authors (or more importantly the editors) have fully appreciated how hierarchical decomposition (of systems into subsystems, and of process flows into sub processes) undermines attempts to draw 1-1 or 1-N relationships between concepts in the different hierarchies.
GOOD
|
Page 98 |
|
|
Structured Analysis: Identifies the key business functions within the scope of the architecture, and maps those functions onto the organizational units within the business. |
Yes. That is what TOGAF 8 implies. We map the (logical) business functions to the (physical) organisation units. Both are hierarchical system decomposition structures. |
|
Page 104 |
|
|
Business services — the services that the enterprise and each enterprise unit provides to its customers, both internally and externally. |
Yes. That is what TOGAF 8 says. |
|
Page 244 |
|
|
… a business service to be a unit of business capability supported by a combination of people, process, and technology. A business service may be: n Fulfilled by manual processes, or may be fully automated n Fulfilled within an organization, or outsourced to a partner n Exposed to any combination of employees, customers, partners, and suppliers n Fulfilled at the point of use, at a divisional level, or as a corporate competency center. |
Yes. That is compatible with TOGAF 8. |
|
Page 247 |
|
|
Business Service: A business service is a thing that a business does that has a defined, measured interface and has contracts with consumers of the service. A business service is supported by combinations of people, process, and technology. |
Yes. That sounds like TOGAF 8. |
|
Information System Service: An information system service is a thing that a business does that has a defined, measured interface and has contracts with consumers of the service. Information system services are directly supported by applications and have associations to SOA service interfaces. |
Yes. Though not all information systems are software, so strictly it should be are usually supported. |
IN NEED OF SKILLFUL INTERPRETATION
|
Page 98 |
|
|
Use-case Analysis: The breakdown of business-level functions across actors and organizations allows the actors in a function to be identified and permits a breakdown into services supporting/delivering that functional capability. |
No. The purpose of use case analysis is to identify the services (use cases) that users (actors) require of a system, and to define the step-by-step process flow of each use case. You start with the actors. But the term actor in use case analysis is normally what TOGAF calls role. |
|
Process Modeling: The breakdown of a function or business service through process modeling allows the elements of the process to be identified, and permits the identification of lower-level business services or functions. |
1 Business function = 1 Business service. 1 Business function = N Processes. 1 Business service = N Processes. No. You don’t use process modelling to “break down a function”. You use functional decomposition to do that. You use process modelling to define the end-to-end flow of a process that may or may not cross between business functions. The two approaches are orthogonal to each other. They only come together at the bottom level of decomposition, where the elementary steps of a bottom level process appear as the elementary functions of the business function hierarchy. |
|
Page 99 |
|
|
Business services are specific functions that have explicit, defined boundaries that are explicitly governed. |
1 Business service = 1 Function. Might be OK but contradicted by the next paragraph. |
|
The functions are split as follows: micro-level functions will have explicit, defined boundaries, but may not be explicitly governed. macro business functions may be explicitly governed, but may not have explicit, defined boundaries. |
The “mays” in this leave little or nothing of the above definition intact. |
|
Page 359 |
|
|
Some of the key relationship concepts related to the core metamodel entities are described below: |
|
|
Process should normally be used to describe flow A process is a flow of interactions between functions and services and cannot be physically deployed. |
No. Of course a process can be deployed. What on earth can he/she be thinking of? |
|
All processes should describe the flow of execution for a function and therefore the deployment of a process is through the function it supports; i.e., an application implements a function that has a process, not an application implements a process. |
1 Function = 1 Process? A workflow application can and does implement a process. |
|
Function describes units of business capability at all levels of granularity The term ‘‘function’’ is used to describe a unit of business capability at all levels of granularity, encapsulating terms such as value chain, process area, capability, business function, etc. Any bounded unit of business function should be described as a function. |
OK apart from value chain, which is a very high-level process, not function. |
|
Business services support organizational objectives and are defined at a level of granularity consistent with the level of governance needed |
OK but see below. |
|
A business service operates as a boundary for one or more functions. |
1 Business service = N Functions? A real business service has to be pinned to a (physical) organisation unit, not a (logical) business function. |
|
The granularity of business services is dependent on the focus and emphasis of the business (as reflected by its drivers, goals, and objectives). |
OK. Though not very meaningful or helpful. |
|
A service in Service Oriented Architecture (SOA) terminology (i.e., a deployable unit of application functionality) is actually much closer to an application service, application component, or technology component, which may implement or support a business service. |
Yes. Better call that an application service then. |
|
Business services are deployed onto application components |
Yes |
|
Business services may be realized by business activity that does not relate to IT, or may be supported by IT. |
Yes |
|
Business services that are supported by IT are deployed onto application components. |
Yes |
|
Application components can be hierarchically decomposed and may support one or more business services. |
Yes |
|
It is possible for a business service to be supported by multiple application components, but this is problematic from a governance standpoint and is symptomatic of business services that are too coarse-grained, or application components that are too fine-grained. |
1 Business service should not need > 1 Application component. Surely flies in the face of the III-RM? |
|
Application components are deployed onto technology components |
Yes |
|
An application component is implemented by a suite of technology components. For example, an application, such as ‘‘HR System’’ would typically be implemented on several technology components, including hardware, application server software, and application services. |
An application component is supported by or run on technology components, not implemented by them. |
Also:
|
TOGAF 9 text |
Critique |
|
Page 73 |
|
|
The significance of systems is that it brings together the various domains (also known as People, Processes, and Material/Technology) to deliver a business capability. |
Really? (Aside from the grammatical error.) The significance of a system is the value it delivers by production of outputs (products or services). There is no reason to define that value or those outputs as being a single capability. If you do then you compound the conflation of concepts described above. |