From business-model to enterprise-architecture

Okay, I think I’m finally getting somewhere, on looking for a way to connect a business-model to enterprise-architecture, to provide a full link between top-down intent and bottom-up real-world constraints.

This specific part goes from the business-model downwards, from Business Model Canvas to Archimate, and thence to BPMN, UML and other detail-layer models. (There’s another part needed to link upward, connecting that work back up through Business Motivation Model and the like to the core shared-enterprise, but I’ll have to deal with that in another post.)

As you’ll see, I’ve had to twist Archimate somewhat in a few places, to provide workarounds for its current IT-centrism, but otherwise everything exactly follows the existing standards. The keys that enable and to some extent validate those adaptations are two assertions:

  • everything is a service (an assertion supported explicitly by the design of Archimate itself)
  • everything is recursive (a principle that enables pattern-based modelling, such as the concept of ‘layers‘ used in Archimate, TOGAF etc)

The ‘how-to’ that follows after the break is the current outcome of a lot of exploration over the past weeks, months and years, a lots of posts and conversations on this blog and elsewhere, and a lot of in-person discussion with a lot of people, many of whom have explicitly asked to remain anonymous. I do believe it’s in a usable state right now, but it should still be regarded as ‘in beta’ at best: use with some caution, and please send me any feedback and suggestions.

In parallel with both Business Model Canvas and Archimate, this may be considered to be under a Creative Commons licence. It’s probably not yet stable enough to attach to a CC license-type in a formal manner, but for now please assume non-commercial, share-alike and attribution-requested for the parts described here.

More after the ‘Read more…’ break, anyway.

Step 1: Develop a business-model

The term ‘business-model‘ here means a semi-detailed overview of what the organisation does in its business with others, and the offers and value-types that are exchanged. A strong recommendation that the model should be developed in the Business Model Canvas format, using the associated methods described and/or summarised in the book Business Model Generation. (The book is currently available in at least 18 languages.)

Here’s an example Canvas from an earlier post:

Identify the flows that take place between the various entities in the model. This example (from the same earlier post) shows only the connections, but also identify and record what would traverse these flows in order to enact the intent of the model:

All of this would typically be developed in a workshop context, or in a cafe-type setting with a notepad or a software toolset such as the BMTBox app.

Step 2: Re-map the overall business-model as related services

Split the Canvas into a core for the organisation that executes the business-model, and separate entities for each of the Customer Segments and Key Partners:

In Enterprise Canvas, each of these would be mapped as nodes (services) in a value-network, all in relation to each other and the the overall vision for the shared-enterprise:

The Business Model Canvas typically shows only the immediate links in the supply-chain or value-network, but in Enterprise Canvas we could also extend the node-relationships as required:

In Archimate, at the highest level, the organisation and its combined business-model can be represented as a single Business Service; the [BMC] Customer Segments and Key Partners can be represented as Business Actor entities, each of whom takes on one or more Business Role positions, and connect to the service presented by the organisation via Business Interface relationships:

Step 3: Expand the detail of the overall business-model

From previous work, we can cross-map the Business Model Canvas onto Enterprise Canvas:

The Archimate specification indicates that a unit exposes functionality externally as a Business Service, but represents internal functionality as a Business Function. In essence, this is a simple recursion: structurally, they are the same – the difference is in in where and how the interface is exposed, for example whether or not the related Business Interface requires an explicit Contract.

The simplest summary is that the overall functionality and relationships represented via a single Enterprise Canvas entity would be depicted in Archimate as a Business Service; but the constituent ‘cells’ within that Enterprise Canvas would be depicted as Archimate Business Function entities:

The Archimate Business Process entity literally does not come into the picture at this level. A business-process is best understood as a pattern of activities that make use of services in some form of choreographed sequence: it is somewhat misleading to describe it as a structure in the same sense as other Archimate entities such as Business Service or Business Interaction, because in essence it’s a structure in time only. The term ‘business process’ tends to be misused as a kind of variant of ‘service’ or ‘function’ or ‘capability’, and all of these terms seem to be used in an arbitrarily interchangeable manner, leading to much confusion in modelling and even in business practice: instead, precise taxonomic distinctions are essential here. In that taxonomy, a service is a combination of function and capability, but for these purposes we can allow ‘service’ and ‘function’ to in effect be synonymous, as summarised above.

Given this, we can re-map the Business Model Canvas  / Enterprise Canvas [EC:] cross-map into Archimate (italics) entities as follows:

  • The Value Proposition (EC: value-proposition) is represented by one or more Product entities, with related Value entities.
  • We have already mapped the Key Partner and Customer Segment entities as Business ActorBusiness Role / Business Interface entities.
  • All of the Enterprise Canvas cells are mapped to Business Function entities with appropriate names (default: same names as in Enterprise Canvas); these also represent in part the Key Activities cell of the Business Model Canvas.
  • All of the Enterprise Canvas interface cells (customer-relations, customer-channels, value-return; supplier-relations, supplier-channels, value-outlay) also include Business Interaction entities (which may optionally replace the respective Business Function entity), each linked to a Business Interface entity, representing the channels and other interfaces to the overall service.
  • Each of the six channels (Business Interface entities) links to one or more Business Object entities, which in turn link to the Business Interface of a Customer Segment or Key Partner; each Business Object may optionally be linked to a Meaning entity.
  • Each Business Object entity attached to a customer-channel Business Interface should also be linked to one or more Product entities; the same may optionally apply to Business Object entities attached to the supplier-channel Business Interface.
  • The Business Object entities associated with a supplier-channel and value-outlay, or customer-channel and value-return, should be linked by a Contract entity, representing the required relationship between the respective Enterprise Canvas main-channel and back-channel (e.g. Business Model Canvas linkage between Value Proposition, Customer Channel. Customer Segment and Revenue Stream).

In essence, using the suggested sort-of layers described in the previous post ‘Rethinking the layers in enterprise-architecture‘, this represents the content for the ‘Why’ layer, which Archimate describes as the ‘Business’ layer. To a significant extent, the ‘Key Activities’ cell of Business Model belong in the ‘How’ layer (which Archimate at present describes only as the largely IT-centric ‘Applications’ layer), whilst much if not most of the ‘Key Resources’ cell belong in the ‘With-What’ layer (which Archimate at present describes only as the exclusively IT-centric ‘Infrastructure’ layer).

More on that in the next steps. In the meantime, we can summarise the mappings as follows – from the Business Model Canvas for one class of offer (Value Proposition, or Product):

Then to the equivalent Enterprise Canvas for that segment of the overall business-model; and thence to a high-level (‘Business’ layer) Archimate model. [Apologies - I started work on these diagrams, but realised they would probably take an entire day each, and need a blog-post each of their own as well: leave this until later, perhaps?]

Note that this is for one category of offer only, from six categories shown in this overall business-model. The complete business-model for all of the offers in context would be a much larger and more complex Archimate model, even at the ‘Business’ layer only.

Step 4: Expand the Key Activities to Archimate ‘Application’ detail

In Archimate, each Business Function or the like in the Business (‘Why’) layer is supported by (realised via) one or more Application Service entities within the Application (‘How’) layer. We also have the same symmetry on the ‘active structure’ side, with an Application Interface entity underpinning or implementing each Business Role; and, on the ‘passive structure’ side a Data Object representing a more real-world form of a Business Object.

(cc) Open Group

The first point that this tells us is that each of the Enterprise Canvas cells and interfaces and flows will be represented by one or more Application-layer entities in Archimate. That part is straightforward enough.

But here we hit a problem with Archimate, because it assumes that activities at this level will only be enacted by IT. In the current structural assumptions in Archimate, activities that are enacted by real people are pushed upward into the Business layer, whilst activities enacted by non-IT technology (i.e. physical machines) are apparently deemed not to exist at all, or else shoved down into the Infrastructure (‘With-What’) layer.

In principle, every activity could be implemented by any conceivable combination of ‘manual’-process, physical-machine and/or IT. Each of these categories of implementation – human, IT and machine – need to be assessed here as if at the same level, so as to identify the trade-offs between different implementations. We also need to be able to view as if ‘the same’ in development and in disaster-recovery, where – for example – we would switch back and forth between a paper-and-pencil versus an IT implementation of what is functionally the same business-process. But Archimate at present doesn’t allow us to do that trade-off assessment: instead, it assumes that everything can be implemented only by IT. In effect, each of the Archimate entities in this layer is an IT-specific specialisation of a generic entity that does not exist. This is a fundamental flaw in the design of Archimate – and one that we need to resolve before we can use Archimate for the kind of true enterprise-scope assessments needed in reviewing the architectural implications of business-models.

The simplest solution here is to go back and recreate the ‘missing’ generic entities of which the existing Archimate entities in this layer are the IT-oriented specialisations. Given that this layer is about the activities that enact business-functions and business-services, these generic entities could be labelled with an ‘Activity’ prefix:

  • Activity Object – generic of Data Object
  • Activity Service – generic of Application Service
  • Activity Function – generic of Application Function
  • Activity Interaction – generic of Application Interaction
  • Activity Interface – generic of Application Interface
  • Activity Module – generic of Application Component
  • Activity Collaboration – generic of Application Collaboration

An Activity Object could perhaps be more accurately described as an ‘Activity Subject’, since it’s the subject of all activities, the entity which will be created, accessed, updated and/or destroyed through the respective activity. Again, note that this is the generic: this entity would usually be specialised in the model, to describe a physical object being worked on, a business-relationship being developed, a data-item being accessed or amended, and so on.

An Activity Module is a somewhat arbitrarily-bounded ‘chunk’ of functionality, described in structural terms (‘active structure’) rather than the action itself. For IT, this would typically be described as a ‘component’ or (somewhat misleadingly) as a ‘service’. For a manual process, a typical ‘chunk’ would be as described in a Work-Instruction (in ISO-9000 terms), or possibly a somewhat more abstract Procedure. For a machine-based process, a more typical ‘chunk’ would be the defined work within a given process at a single machine or workstation or cluster of workstations.

The types of relationships that Archimate permits between these more-generic entities (and hence between their derived specialisations) should remain essentially unchanged.

It may also be useful to include links and references to location – physical, virtual and/or relational. There is no Location entity in the current Archimate standard, but it is expected that one will be included in the upcoming Version 2, so there should be no problems with compatibility there.

A strong recommendation here to use the distinctions between Function and Capability as described in the extended-Zachman model used in conjunction with Enterprise Canvas. A function is a metaphoric ‘place’ where an Activity Object will be accessed or changed, and that summarises the changes that will take place; whereas a capability is the competence and skill-level brought to bear on Activity Objects in order to enact the required changes. In most IT applications, these two aspects are merged together into the one item of functionality, hence the distinctions between them may seem too subtle for some people to notice; but for machines and, especially, for human processes, the distinctions are much more explicit, and very important. The function aspect relates to activity, and hence belongs in this layer, whereas the capability is in effect a type of ‘resource’, and hence belongs more properly in the equivalent of the Archimate ‘Infrastructure’ layer. More on that when we look at the Key Resources section of the business-model, anyway.

I won’t go into more detail here of how to develop the model itself. Instead, refer to any of the Archimate reference-materials – such as the formal Archimate standard, the documentation from the Archimate Foundation, or the free Archi toolset for Archimate – and then adapt using the generics and re-specialisation of entities as summarised above.

Each of the activities summarised in the Key Activities cell in the Business Model Canvas should be represented somewhere in this layer of the adapted-Archimate, linked appropriately to the services in each of the cells in the matching Enterprise Canvas.

Step 5: Expand the Key Resources to Archimate ‘Infrastructure’ detail

We now go down one more level in the architectural recursion.

In Archimate, each Application Function or the like in the Application (‘How’) layer is supported by (realised via) one or more Infrastructure Service entities within the Infrastructure (With-What’) layer. We also have the same symmetry on the ‘active structure’ side, with an Infrastructure Interface entity underpinning or implementing each Application Component; and, on the ‘passive structure’ side an Artifact representing the full concrete form of a Data Object.

(cc) Open Group

The implication here is that each of the Key Resources in the Business Model Canvas should be represented in some way within this layer. But here again we hit up against the current limitations of Archimate, because it assumes that the only relevant resources are those that can be described in terms of IT: devices, networks, system-software and so on. In the current structural assumptions in Archimate, the competencies and skills of real people are somehow pushed upward into the Business layer, whilst any other non-IT technology or physical resources, capabilities and infrastructures are apparently deemed not to exist at all. To be blunt, this is IT-centrism running wild, and presents serious problems for modelling at this layer.

In principle, every activity could be implemented by any conceivable combination of ‘manual’-process, physical-machine and/or IT- which means that we need the respective resources and infrastructures to match and underpin each implementation. As in the ‘How’ layer, each of these categories of implementation – human, IT and machine – need to be assessed here as if at the same level, so as to identify the requirements and trade-offs between different implementations, including those needed for special-cases such as development and disaster-recovery.

But again, Archimate at present doesn’t allow us to do that trade-off assessment: instead, it assumes that everything can be implemented only by IT. Some of the entities in this layer are sort-of generic – Infrastructure Service, Infrastructure Interface, Network, Node, Artifact – but they’re kind of incomplete relative to the full infrastructure/resource set, and it’s clear that, as in the Application layer, they’re intended more to represent IT-specific specialisations of generic entities that aren’t available in the Archimate specification. This is another fundamental flaw in the design of Archimate – and one that, once again, we need to resolve before we can use Archimate for its purported purpose as an enterprise-architecture notation.

Because the IT-centrism here is more implied than overt, resolving this is not quite as straightforward as in the Application layer. Probably our best option here is to re-assess the whole structure from the perspectives of the expanded-Zachman used in Enterprise Canvas: Asset, Function, Location, Capability, Event and Decision. These are mostly self-explanatory, though note that each of these itself expands to cover the full ontological scope:

These categories apply everywhere, yet there are also distinct emphases in each of the Archimate-style layers: Decisions, Events and, to a lesser extent, Functions in the Business layer; Functions and, to a lesser extent, Events, in the Applications layer; and Assets, Locations and Capabilities in this layer.

An Asset can be defined simply as a resource for which the respective service is responsible and can put to use as required. (In this context, there’s no real difference between assets and liabilities, other than in terms of availability, because in essence they’re variations on a theme of resource and responsibility.)

A Capability is the ability to work on specific types of Asset using a specific level of competence and skill. Note that in general, physical-machines can only work at a rule-based skill-level, IT typically at an algorithmic level, but in most cases only humans can act at guideline or principle-based skill-level. Also that almost by definition, physical-machines and IT are unlikely to be much use for working on relational or aspirational assets – a point that is often forgotten in the design and operation of many IT-based CRM systems…

A Location is a node within some type of location-schema. These may be of any asset-type or resource-type, or any combination of these: for example, a room in a building will have both a physical location and a virtual location-identifier; an IT network-node will typically have an IP-address or equivalent, but also at a physical location; an organisational hierarchy is also a relational network; and so on. And whilst time is often referred to as an ‘asset’ or a ‘resource’, it can’t be changed or transformed in the same way as for other assets, and hence is best understood as a type of Location rather than a resource. (An Event may be considered to occur in time, but is not in itself of time: the distinction may seem subtle, but can be very important in practice.)

A network is a schema that describes a set of Location nodes, specific relationships between those nodes, and, often, the types of Assets than can be transferred on pathways of connection between those nodes.

What we could term an infrastructure is thus a clustering of Assets, Capabilities and Locations, often in network-relationships.

This schema enables us to identify how the existing Archimate entities in the Infrastructure layer are somewhat-arbitrary IT-specific specialisations of the underlying generics:

  • The Archimate Artifact entity is specified as a virtual-Asset, but can be repurposed to represent any type of real-world Asset.
  • The Archimate Infrastructure Service entity can be repurposed to represent the exposed available behaviour (Capability) of any cluster of related Assets, Capabilities and Locations, linked to any Activity Function in the Application Layer.
  • The Archimate Infrastructure Interface entity can be repurposed to represent the exposed interface for an Infrastructure Service, as linked to any Activity Interface in the Application Layer.
  • The Archimate System Software entity is merely one very specific example of a generic Capability entity.
  • The Archimate Device entity represents a type of Asset that can be used in and for specific activities, as ‘active structure’: a hammer, a power-drill, a fork-lift truck and an ordinary ‘dumb’ telephone are each likewise a Device in this sense.
  • The Archimate Network, Node and Communication Path entities respectively represent a schema for connections between Location nodes, a node within that schema, and a connection-path through which specific types of Asset may be transferred between nodes.

As in the Application layer, the types of relationships that Archimate permits between these more generic entities and their derived specialisations should remain essentially unchanged.

Again, I won’t go into more detail here of how to develop the model at this layer: instead, refer to the Archimate reference-materials, and adapt that to the generics and re-specialisations of entities as summarised above.

Each of the items summarised in the Key Resources cell in the Business Model Canvas should be represented somewhere in this layer of the adapted-Archimate, linked appropriately to the services in the Application layer, and thence the services and interfaces and the like in each of the cells in the matching Enterprise Canvas.

Step 6: Apply enterprise-architecture disciplines to review the business-model

What we have, as the outcome of this modelling exercise, is a full ‘to-be’ description of the implemented architecture for the business-model. Which means that we can now turn to all the usual enterprise-architecture tools and techniques – TOGAF ADM, VPEC-T, requirements-modelling and the rest – to evaluate and rethink what works and what doesn’t, and what’s needed to make it all work together well.

The question at the initial Business Model Canvas stage was whether the ideas made sense at the business level. The questions here are more about whether it would work in real-world practice, such as:

  • What structures, capabilities, skills, equipment does this business-model need?
  • What exactly passes between each party in each flow – what are the Business Objects that are transferred and/or changed or exchanged? At what points in each process do these transfers take place? What mechanisms and functions are needed to ensure complete balance across the whole ‘Before’ / ‘During’ / ‘After’ cycle of the whole transaction?
  • What structures and so on do we have already for this? What equipment and configurations and the like would need to be repurposed? What impacts would that have on existing operations and existing business-models?
  • What kinds of changes do each of the requirements demand – incremental, step-change or breakthrough? Has adequate allowance been made in the risk-assessments for the feasibility or achievability of any required breakthroughs?
  • Has sufficient attention been paid to the human aspects of the required business-model, including skills-development, retraining, redeployment and cultural change?
  • What intermediate stages would be required, in the transition from ‘as-is’ to ‘to-be’? Has sufficient attention been paid to the probabilities that ‘there’ may not in reality be the same as we expected when we aimed to get there?
  • Over what timescales could these changes be implemented? What timescales must apply if the business-model is to be viable?

And so on: the usual stuff, really. :-)

(There are some planned extensions to Archimate to deal with versioning and projects and the like, but I’ll cover that in the next part, that deals more with looking ‘upward’ in the enterprise from the business-oriented view in Business Model Canvas.)

The point here is that this kind of modelling process enables us to do an iterative assessment and reassessment of the idea of the business-model and its real-world feasibility, implications and its implementation, bouncing back-and-forth between top-down (the ‘Why’ of the Business Model Canvas) and bottom-up (the ‘How’ and ‘With-What’ of Archimate’s Application and Infrastructure layers). This is also where enterprise-architects would be directly engaged in the development of business-strategy and its real-world implementation – the ‘seat at the table’ at the CxO level of the organisation that so many EAs seem to desire! :-)


So: that’s a suggested pattern and process for direct ‘translation’ between Business Model Canvas and a more whole-enterprise adaptation of Archimate, using Enterprise Canvas as an intermediate layer. There’s another ‘how-to’ to come, going in the other direction, to link Business Model Canvas ‘upward’ to the shared-enterprise, but that’s it for now.

Many thanks for sticking with it this far, anyway. And over to you, if you would?

Tagged with: , , , , , , , , , , ,
Posted in Business, Complexity / Structure, Enterprise architecture, Knowledge
7 comments on “From business-model to enterprise-architecture
  1. Hi Tom,

    Thank you so much for putting so much effort and detail into this explanation. I think the EA and business analysis community is very lucky to have someone who is willing to take the time to explain in detail their approach for performing this kind of business architecture.

    I’ve had a read of the whole post and it’s going to take me some time to digest it in full. Within the context of your previous posts, this approach makes a lot of sense. I may have some more detailed feedback for you later. They also explain in concrete the limitations you’ve described in Archimate, which adds weight to your previous post.

    Well done,

  2. Nick Malik says:

    Hi Tom,

    Your article is rather involved. Good work. I would like to point out that you are not the only person who has tried to deal with this issue. I, too, wanted to include the concepts of Business Model into Enterprise Architecture, and did so in my publication of the Enterprise Business Motivation Model… two years ago. I have been updating that model since, and the most recent version is available on where you can find a metamodel that I derived from a combination of the OMG Business Motivation Model and Osterwalder’s work on Business Models (and about a dozen other influences).

    To whit, I encourage you to take a moment to consider the “Business Model Viewpoint” which you can get to from the left navigation after following the link above. (A direct link is but I expect that link may fail in the near future as I post updates to the model).

    I welcome your input and ideas as the model improves.
    — Nick

  3. Tom G says:

    @Anthony Draffin - Anthony, many thanks indeed. Will look forward to your further comments – especially from the Australian context, which is where many of these ideas initially arose.

  4. Tom G says:

    @Nick Malik - Nick – likewise many thanks (though will admit I’m a bit worried about “your article is rather involved”… :-( )

    Yes, I am well aware that there are a lot of other people working in this space: John Gotze, Jurgen Dahlberg, Marc Lankhorst and Alex Osterwalder himself, of course, just to list a few of the folks I know personally, and I know there are many others as well.

    In my own defence, I don’t know anyone else who’s trying to find a way to cover the whole of this space, all the way upward from the business-model to the drivers for the overall extended-enterprise beyond ‘the market’, all the way down to the fine-detail of implementation and operation and record-capture at run-time, and linking all the way back up again to support continuous improvement or quantum-change. That’s why so much of this may seem “rather involved”: it’s a huge context to cover. But someone has to find a way to link it all together, surely?

    Thanks for the pointer to the updated EBMM. (As you warned, the link you posted for ‘Business Model Viewpoint’ failed on a 404 ‘Page not found’: I’ve taken the liberty of editing your comment to point to the current version, but no doubt that will fail too the next time you change the model?) We’ve talked about the EBMM quite a bit in the past, and I did write a comment on your blog-post on the v3.5 update, but it seems to have gotten lost again in the MSDN comments-system. As I said in the comment, it’s improved a lot – much more usable now. My main concerns are it incorporates the Business Model Canvas’ over-orientation towards for-profit business, without apparent support for other value-models (as in government or non-profit, or even in the non-transaction space in for-profit contexts), and it still retains the fundamentally-flawed organisation-centric definitions of ‘Mission’ and ‘Vision’ used in the original Business Motivation Model. Both of these problems are quite easy to fix, but until they are fixed the EBMM remains too constrained for real-world whole-enterprise architecture, and could in some ways be dangerously misleading – much like the ways in which the IT-centrism of TOGAF and FEAF and the current Archimate makes the resultant architectures too constrained an actively misleading. And without the linkages ‘downward’ – which is what I’ve been aiming to develop over the past few years, as summarised in these posts – the EBMM risks being an island of excellence isolated from anything else: which would kind of limit its usefulness and value?A lot of the other pieces of the jigsaw – or hologram – are coming together now, too, as we’ve seen with Marc’s comments on the future of Archimate: yet we still need those whole-context links…

    Would be very happy to talk about this further, though I suspect that for you it’s still not yet the right time for that? Please do keep in touch, anyways – and thanks again.

  5. Diederik Dulfer says:

    Hi Tom,

    Thanks for the effort you put in describing this. It helps me a lot to know that i am not the only one struggling with Archimate. I recognize the “fundamental flaws in the design of Archimate” that you describe. But I was surprised that you did not refer to chapter 3.2 “Core Concepts” of the Archimate specification. Is there a specific reason that you did not do that?
    Diederik Dulfer

    • Tom G says:

      Diederik – many thanks.

      Re “Is there a specific reason that you did not do that?”, the short answer is probably incompetence on my part… :-|

      In my defence, I did follow this post with a more detailed exploration of the internals of Archimate: see the post Unravelling the Anatomy of Archimate, back on 4 August 2011.

      Hope that helps? – and thanks again.

  6. Diederik Dulfer says:


    Well very good defense;-) I did no read your post `Unravelling the Anatomy of Archimate`. Thanks for bringing that to my attention. That post helps a lot!

1 Pings/Trackbacks for "From business-model to enterprise-architecture"
  1. [...] addthis_options = "google_plusone,twitter,linkedin,facebook,hackernews,email";Laatst las ik deze post van Tom Graves. Het verhaalt over een mapping tussen het Business Model Canvas en ArchiMate, met [...]

Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Books by Tom Graves
Ebooks by Tom Graves