Tom Graves / Tetradian

As the economy shifts ever onward from manufacturing toward services, how do marketing and market-relationships need to change with this shift? And what enterprise-architectures do we need to support this?

[In part this is a follow-on from Dave Gray's excellent Dachis Group article 'Everything is a service': I strongly recommend to read that post first before continuing here.]

As Dave Gray indicates in his article ‘Everything is a service’, many people in and around business are seeing a ‘Great Reset’ – a fundamental shift in the nature of the economy, and with it a fundamental shift in the nature of a viable business: a change in focus from products to services.

In a product-oriented economy, an organisation’s market is built around transactions, exchanges of goods and services. Within this metaphor, services are quasi-products, another type of ‘thing’ to be ‘consumed’ by a passive marketplace of ‘consumers’. Financial services, for example, are packaged as ‘products’; so-called service-organisations sell ‘solutions’ to often-unspecified ‘problems’ that a ‘consumer’ is presumed to face.

Producers produce, consumers consume: the roles are explicit, and explicitly separate and distinct. The role of marketing there is to create a market ‘want’ – often entirely artificial – for whatever product the producers want to sell. The role of enterprise-architecture and the like is to support creation of the maximum volume of product for the minimum necessary effort and cost.

The overall view – perhaps still illustrated best by the implied left-to-right flow in the structure of the Business Model Canvas above – is a linear structure of processes. A supply-chain (‘Key Partners’) feeds into the business-processes of the organisation (‘Key Activities’), the results of which are then sold on to ‘consumers’ (‘Customer Segments’). The sequence ends at the ‘consumer’, or more specifically at the moment that the customer has paid for the ‘product’; and everything is centred around the organisation, as ‘the enterprise’.

This view of the market is also often possession-based, with very unequal power-relationships assumed between the organisation and everyone else: we talk about ‘capturing’ a market, ‘owning’ market-share, and so on. This often leads in turn to a very combative relationship across the market, both between organisations competing for ‘possession’ of market-share, and between an organisation and its customers, employees and broader communities – all of whom, perhaps unsurprisingly, may well object to being treated as possessed ‘objects’ or ‘subjects’ of the organisation.

In business terms, one of the key drivers behind the ‘big reset’ or ‘big shift’ that Dave Gray describes is that this model of the market is rapidly becoming less and less viable. Most markets are either at or approaching saturation-point; the hidden-costs are becoming more visible, and harder to externalise; and the supposed economies of scale of mass-production and mass-marketing deliver steadily lower returns, especially relative to smaller and more adaptable technologies and business-models. And in bald economic terms, there are practical limits as to how much ‘stuff’ we can continue to make and sell on a finite planet – limits which in many cases we’ve already overshot. Some real problems there… – and yet they’re inherent in that model of the business-market.

A service-oriented economy is radically different, in that the market is built primarily around relationships. As Dave Gray put it:

A service is at its core a relationship between server and served. Service is work performed in support of another. At every point of interaction, the measure of success is not a product but the satisfaction, delight or disappointment of the customer.

Within this metaphor, products are best understood as proto-services, typically as part of the means for self-delivery of some service. Everyone in the market is both ‘producer’ and ‘consumer’: the roles blur, and are inherently much more equal or peer-based in nature than in the product-oriented economy.

This view of the market is also based much more on mutual responsibilities: we talk about co-creation, about partnering in a shared enterprise. The power-relationships are much more equal, and necessarily focussed on building and maintaining mutual trust – rather than the combative contracts of the possession-model, which mostly reflect an absence of trust.

The overall model still has transactions and processes and supply-chains, but the perspective is different. As Verna Allee describes it, that linear ‘supply-chain’ is actually one view into a much more nuanced ‘value-network’; and a product- or service-transaction is merely one phase within a much larger market-cycle:

Importantly, the fundamental focus of relationships is inverted, from organisation-centric to customer-centric: as Chris Potts puts it, “customers don’t appear in our processes: we appear in their experiences”. The sales-focus also shifts from ‘push’ to ‘pull’, from manipulating or even forcing the ‘consumer’ into a single once-off ‘the sale’, to building a continuing long-term mutual relationship. All of this requires radically different approaches to sales and marketing, but it can be done – and increasingly, is much more profitable than the ‘push’ model.

[For example, compare your experience of the usual soulless time-driven 'customer-as-product' sales call-centre - such as that which interrupted me just now whilst writing this, and who cut me off in the middle of saying "Thank you, but no" - to an intentionally relationship-oriented call-centre such as that run by US retailer Zappos, which focusses much more on respect and mutual trust. Which approach would you prefer to deal with in your business day? The answer's fairly obvious: which is why the conventional call-centre model is becoming less and less viable, no matter how much pressure is put upon the long-suffering staff.

Another first-hand example: a couple days ago I was looking at cameras in the local branch of a medium-sized national chain of camera-stores. The absence of pressure was really noticeable; and the saleswoman's quiet passion for photography per se shone through. The change in energy of the place was very noticeable, compared to the last time I'd been there, a year or so ago: more like an Apple Store than a 'normal' sales-obsessed high-street retailer.

Talking with her, it became clear that the company had made that crucial shift from product-orientation to service-orientation. The key was that they'd come to understand they made most of their money not from selling cameras as such, but from the ongoing photo-print service. Camera-sales became viewed as a means to support that service: it needed to be profitable in its own right, but it wasn't the primary focus for profit. Hence it became much more important to match the camera to the client's actual needs - and that emphasis on matching real needs itself became a key foundation for mutual trust, and hence for long-term relationships that would be profitable to all parties.

Contrast that with the usual high-street high-pressure retailer, where the emphasis is more likely to be about offloading the highest-margin object that the 'consumer' could afford, then dropping the attention instantly so as to move on to the next 'punter' as quickly as possible. "I worked in a place like that for three months", she said, "and I felt like I aged ten years while I was there. Soul-destroying, for everyone. So I know why I'm working here! - because I want to be here."]

So what kind of enterprise-architecture do we need for a service-oriented enterprise? How does it differ from the conventional product-oriented architectures – particularly in its business-architecture and process-architecture? Probably the key requirement is an awareness of the implications of one simple statement:

A service exists to serve.

But what does it serve? And whom does it serve? Architecturally, those are not trivial questions…

In the highly unequal power-relationships in the conventional product-oriented model, the answers are very clear indeed: there is often a thin pretence of ‘customer-service’, but in reality the ‘consumer’ is deemed to exist solely to serve the organisation and its perceived ‘need’ to sell.

[And the organisation in turn is deemed to exist solely to serve the 'needs' of the stockholders, but that's another story...]

But in a service-oriented enterprise, there are two fundamentally-different types of service going on: and the architecture needs to support both of these.

One type – which we might describe as ‘horizontal’ – is the conventional ‘supply-chain’ structure: the service-producer serves the needs of the service-consumer. The issues here that the architecture needs to support are that:

• the relationships between producer and consumer are essentially peer-to-peer
• the roles of ‘producer’ and ‘consumer’ will often blur or even swap over, especially in the ‘co-creation’ relationships that are common in a service-oriented model
• the overall relationships are built via the self-reinforcing loop of the full ‘market-cycle’, as above

The other type of service is more ‘vertical’: within the context of those ‘horizontal’ supply-chain service-relationships, every player in the shared-enterprise serves the same overall vision and values. The market exists within the context of a broader shared-enterprise, defined by a distinct purpose or ‘vision’ and its associated values.

Remember Chris Potts’ point above, that “we appear in customers’ experiences”: there’s a crucial difference here between the organisation and those with whom it interacts. Architecturally speaking, the organisation chooses the vision and values to which it will align. When customers’ experiences – and, for that matter, suppliers’ experiences – happen also to align with that same vision and values, there is then a basis for a shared connection. Serving the same ends – the same vision and values – creates the basis for mutual trust, which then starts the market-cycle rolling.

So the service is delivered through the ‘horizontal’ connection; but the connection only exists because both parties share ‘vertical’ alignment to the same vision and values.

Note that the customers’ experiences – or even supplier’s experiences – may only align with the organisation’s chosen vision for a brief period: think of a restaurant at lunch-time, for example. But whilst that alignment exists, there is the basis for conversation and connection – and hence the first stage of the market-cycle already in progress.

[Back to the camera-shop. The focus throughout the conversation was photography, what kind of photography I might need to do, about cameras in general. Firstly, there was a conversation - which in some stores doesn't even happen at all; and the conversation didn't have an all-too-obvious undercurrent of 'how can we sell you a high-priced camera that you don't need?' - which I've had all too often in the high-pressure stores. Instead, I felt listened-to, respected, safe, served - all of which increases the likelihood that I'd go back there when I am ready to buy another camera. In other words, that first part of the market-cycle is already in progress; and I feel safe in the belief that the closing 'post-sale' part of the market-cycle would be there, too.

Yet note that I wouldn't go there to buy a sandwich, or clothes, or anything that wasn't about cameras - because that isn't part of their vision or purpose that they present. They're clear about what they do and what they don't do, and demonstrate their vision and values in practice: so I know when to go there, and when not to go there. Sounds obvious, perhaps: but some organisations are so sales-obsessed that they give the impression that they'll sell us anything, whether they have it or not, just to make up their sales-quota - and that's really confusing, for everyone.]

Architecturally, the vision and values are the core of a service-oriented architecture: everything in the organisation needs to be understood as serving that vision.

Hence, for example, the value of a service-viability checklist that explicitly includes tracing of support for each of the values as they touch on every aspect of the enterprise.

Hence also the importance of ensuring that that same vision is carried across any partner- or outsourcing-relationships – especially where key customer-facing connections are handled by outsourced others such as an external customer-service centre.

And hence also the importance of keeping the focus on those shared-relationships overall, such as with Chris Potts’ aphorism above. As enterprise-architect Pat Ferdinandi put it, in a comment on an earlier post here:

That’s a brilliant line by Chris. It’s the corporation’s adjustment between customer service and customer loyalty. Customer service is viewed as a “fix” of problems. Customer loyalty is earned by the customer’s experience with the corporation but not necessarily from the corporation. The experience can be from word of mouse of a trusted friend. The experience can be from reviews by “specialists” in the area.

There’s a lot more on these themes scattered around on this site, and in the various books. For example, take a look at the post ‘Where marketing meets enterprise-architecture‘, or any of the articles here on Enterprise Canvas; and the books ‘The Service-Oriented Enterprise: enterprise-architecture and viable services‘, and ’Mapping the Enterprise: modelling the enterprise as services with the Enterprise Canvas‘. The chapter ‘Step 1: Know your business’ in the book ‘Doing Enterprise Architecture: process and practice in the real enterprise‘ also describes the practical processes needed to set up the initial architecture-models for a service-oriented enterprise. It’s all there: all we have to do is do it.

It’s simple, and straightforward: yet it’s often not easy at all. And the reason why it often isn’t easy is because it does require a real shift in perspective, a paradigm-shift – and no-one should underestimate just how hard those shifts are in real-world practice. Yet also don’t doubt that, as Dave Gray says, it is the way that the business-world is moving: so as enterprise-architects we do have to support our enterprises in that change, in whatever ways we can.

Enough for now, anyway: comments, anyone?

“What would be the smallest service? Did anyone ever look for the/a boundary condition of a service?” – an important pair of questions from Jan van Til in an earlier comment here.

The first question is a bit difficult, because the only correct answer would be that ultimately it’s right down at the sub-cellular level – which isn’t likely to be much help in most business-contexts…

So in practice the way we need to answer that question is actually the same way we would answer the second question: the ‘smallest’ service, and the boundary-condition for a service, is whatever and wherever we choose it to be.

I’m not being facetious here: I’m serious. This is actually a crucial point in all service-design – yet it’s a point that many people seem to miss.

First, another key question: what is a service? The short answer is that a service is ‘something that serves’. Which again might at first seem a bit facetious: but seriously, it’s not, because it encapsulates everything that really matters here. At this level, we need to keep to the abstract: hence we deliberately don’t say what the delivered service might be, but instead focus on the fact – or action - of ‘service’. And a service is a service because it serves: and, usually, that it serves or services the needs of something other than solely of itself.

Yes, very abstract – but actually very important from an architecture perspective, because it provides explicit constraints whilst at the same time keeping everything open.

To give a concrete example, consider a kidney. (Okay, you might prefer not, but it’ll do as an example, surely? ) What does a kidney do? From a services perspective, what does it provide? Assuming a living body, the kidney provides a number of services, such as removing excess water from the system, filtering out impurities, breakdown of certain by-products of digestion, some specific functions for the immune-system, and so on. We can then look at various service-interfaces at that layer (mainly the bloodstream and the bladder), the biochemical protocols and exchanges, whatever. All of this would make perfect sense to someone who’s studied anatomy, physiology and the like.

But notice that we’ve invented an arbitrary service-boundary here. We could go up a level, and bundle all of the functions of the kidney under the heading of ‘digestion services’. Or we could go down a level or two, to the individual services that the kidney provides. We could go down quite a lot further, such as to the ‘containment-services’ provided by certain types of cells that denote and delimit the outer edge of what we would generally think of as ‘the kidney’. Yet there’s nothing concrete or explicit that would always define for us ‘the‘ service-boundary: instead, we choose the level, and the service. The boundary of the service is whatever we choose the boundary of ‘the service’ to be.

So, to bring this back to business: what is a ‘business-service’? What denotes the boundary of a ‘business-service’? In practice, we’ll see exactly the same as with the example of the kidney: a ‘service’ is something that serves in some identifiable way, that we happen to describe as ‘a service’.

That’s it: there is no explicit ‘the boundary’ for ‘a business-service’. Which is why we end up with all sorts of names and terms being used, often interchangeably, for all sorts of different ‘services’ within business, with all manner of intense arguments as to which term fits what and which service is ‘above’ or ‘below’ or contains others, and so on. For example, look at all of the chaos and confusion around the following terms:

• business service
• business unit
• business process
• business function
• business capability

In architecture, each of those terms would have a distinct meaning: for example, in Enterprise Canvas, a service is a conjunction of function (a description of what should be done) and a capability (the ability to do something), whilst a process would chain various services together to deliver an overall effect on something. But in most business-usage they’re just alternative terms for ‘a service of some kind, at some level of abstraction’ – with different terms used almost at random as sort-of-synonyms for each other, at different levels of granularity or abstraction. Hence all the confusion, because that arbitrary scrambling makes it very difficult to work what the heck any of those terms actually mean in any given context…

But the quick solution is to recognise that in practice all of them are ‘services’. And once we accept that we are responsible for choosing ‘the boundary’ of a service, suddenly things can get a whole lot simpler. Choosing a boundary will itself imply the service-interface for that particular view or granularity of service. Identifying the interface then also leads us towards identifying the exchange-content, the interface-protocols, and the probable functions and capabilities that this service would require. And because we have that choice, we can move any or all of these around as appropriate, for better fit to what we have available in our architecture or whatever, simply by choosing a different boundary for the service. The boundary isn’t something that’s fixed, predefined, preordained: it’s our choice.

(By the way, we can see exactly the same kind of thing happening with the ‘mote’ concept in the metamodel-structure that I described in earlier posts. Several people asked “what is the boundary of a mote?”, “how big is a mote?”, “which metamodel layer does a mote sit in?”, and so on. The actual answer is “whatever we say it is”: it’s determined by our choice of the context, not by the structure itself. Technically, the mote-structure is defined at the M3/M4 level, but in fact any mote could be used directly at any layer, right the way down to the M0 model-level. And the size of the mote is “whatever it needs to be”: a tag-mote, for example, is tiny – we could almost describe it as being at the atomic level – whereas an complete model and its entire change-history would also be represented by the full related-mote tree of another single mote.)

Hence we come back to the core theme of a service-oriented architecture: everything is or delivers a service. Again, that applies at every level: in Enterprise Canvas, for example, the ‘service-in-focus’ might be anything from a single line of code to the entire enterprise – there’s no inherent difference other than as determined by context. Everything is a service; and the boundary of a service is what we say it is.

Hope that makes some degree of sense?

[Many thanks to Jan for suggesting the topic - and yes, please do comment on this if you wish?]

An interesting follow-on this afternoon from the themes of the previous post, ‘Rethinking the architecture of management‘.

I was wandering around down town, doing the shopping. Outside this rather nice old traditional-style grocer’s shop, there’s a mob of 20-something students – Swiss, apparently – from the local ‘English as a Foreign Language’ college. Their lecturer is expounding about this shop, telling them in his somewhat condescending upmarket voice that it’s where they ought to buy real English food (??) to take home, and so on. Then he says:

If you see schoolboys walking down the road here wearing purple blazers, they are from the Royal Grammar School. They are the elite, the cream. At age 11 they have to take a special examination in mathematics and English, and only two percent pass that exam.

It’s kinda interesting to apply a services perspective to that assertion. All that the exam tells us is that it selects for ability in mathematics and native-language. Which means that those pupils will, in later life, probably be well-suited to doing tasks that deliver the kinds of services that make good use of those abilities. But that’s all that it tells us. Since every service is ‘just another service’, there’s nothing in there – nothing at all – that indicates that every one of those young students should therefore be described as ‘the elite’.

In service-architecture terms, everywhere and nowhere is ‘the centre’ of the enterprise, and every service is necessary to the viability of the enterprise, hence it makes no sense to describe any category of services – or the people who deliver those services – as ‘the elite’. (Individuals, yes, perhaps; a specific category, no.)

In short, the only reason why those students with that specific set of (proto)-skills in that location would be called ‘the elite’, is because people who are like them and have similar skills want to believe that they themselves are ‘the elite’.

In other words, it’s nothing more than a myth – the kind of circularly self-centric fantasy that’s guaranteed to cause serious dysfunction in a service-oriented enterprise-architecture.

Oops…

And yes, it gets worse! All the way through school, these young students will be told, time and time again, that they are ‘the elite’. That they are entitled to special privilege and special attention because they are ‘the elite’. Which they aren’t, because it’s just a self-aggrandizing fantasy.

Oops…

And wait – yes, it gets still worse! These young people go on to elite universities, elite business-schools, to become elite businessmen, businesswomen. Which they aren’t, because, again, it’s a fantasy.

Oops…

And now, yes, it gets worse again! – because they go on to become ‘the elite of the elite’, the ‘captains of industry’, the managers, who are ‘elite’ because they’re managers.

Yet management is ‘just another service’. There’s nothing inherently ‘elite’ about that set of services at all: every service is ‘just another service’, and every service is, by definition, essential to the enterprise. In a service-oriented architecture, there is no service that is inherently more important than any other: that’s the whole point.

Hmm…

So let’s ask a very simple question – a very difficult, dangerous, politically-explosive question: if every service is ‘just another service’, why is it that as a category, those who deliver the category of services that are called ‘management’ get to control more, and are given more, and paid more – often so vastly much more – than those who happen to deliver a different type of ‘just another service’?

Because as far as I can see it, from a service-architecture perspective, the only reason that they’re paid more is because they purport that they’re ‘the elite’. Which they’re not, because it’s just an arbitrary, self-important fantasy.

A whole load of smoke-and-mirrors to prop up the fantasy, of course – no surprises there. But beyond that there’s nothing of any substance at all: nothing more than a plaintive little chant of “the elite are the elite because they’re the elite”, and kinda hoping beyond hope that we won’t notice how empty that claim really is.

Oops…

Y’know, there might just be a problem there?

—

[And by the way, yes, I did indeed go to that kind of 'elite' school as a child. Which is why I do know, first-hand,  just exactly how vapid, shrill and empty those claims really are... Hey ho...]

One of the more valuable uses of the Enterprise Canvas is as a checklist to verify completeness and viability of services, in any context within the enterprise.

By ‘completeness’ I mean that we check that the service has all the connections and support and flows that it needs to play its full part in the respective layer of the enterprise value-network.

And ‘viability’ here is in the sense described in the Viable System Model, that the interdependencies that the service needs both to operate in the ‘now’ and to change appropriately over time are all in place and in action.

In a service-oriented architecture and and a service-oriented view of enterprise, everything is or delivers or represents a service. Which means that everything in the enterprise will rely on those interlinks and interdependencies. Which is why a model-type such as Enterprise Canvas, which explicitly sets out to model those interdependencies, could be very useful indeed.

So here’s an as-brief-as-I-can-make-it how-to introduction on using Enterprise Canvas for this purpose, creating models with the simplified version of the Enterprise Canvas notation.

Read more…

Over on the Enterprise Architecture list on LinkedIn, Bala Somasundaram asked about the concept of value-trees as a means of tracking compliance to enterprise values, and thence as a means for validating the value of enterprise architecture.

Value-trees are a key theme in the model I’ve used for describing the service-oriented enterprise. More specifically, they are the trails of ‘pervasive services’ that ensure compliance to enterprise values. In effect, they are the vertical, management-oriented analogue of the horizontal value-chains of the enterprise. But whilst the value-chains traverse through a single layer of the enterprise – the operations or service-delivery layer – the value-trees, must, by definition, pervade every part of the enterprise, from top to bottom, from abstract strategy to each individual process-step, each line of code. To give one example, we know from painful experience that quality-based themes such privacy or security or business-continuity cannot be patched on as afterthought once the design is complete: to make it work, we must include them right from the start. A key aspect of the value-tree is the trail of relationships and requirements that devolves downward from the enterprise values, and upward as confirmation that the value-requirements have been met.

In short, value-trees are the means by which the so-called ‘non-functional’ requirements are made functional in a business sense.

For the most simplistic example, assume that the only value in the enterprise is profit. (I did say it was a simplistic example. ) A suite of principles devolve from this value: for example, that the outcomes of value-chain processes shall be measured in monetary terms; that costs of all activities shall likewise be measured in monetary terms (hence Activity Based Costing, for example); and that verifiable mechanisms shall be used to contrast these two sets of measurements, to derive a measurement of the value in its specified terms – i.e. profit, in this example. To do this, we’ll need to aggregate (‘roll up’) all the outcomes and costs; and for management purposes, we’ll probably need to be able to disaggregate (‘drill down’) through the business-units and groups and clusters, all the way back down to individual activities. The connections and transforms for aggregation and disaggregation are the branches for the value-tree.

A classic PDCA (plan, do, check, act) approach to quality-management – i.e. management of the value-tree – means that the tree itself needs to be supported by four distinct types of activities:

• develop awareness of the value itself, and of the need to monitor the value
• develop capability to enhance monitoring of and improvement against the value
• measure compliance of activities against the value
• verify and audit to monitor and enhance compliance and continual improvement

(Note that some of these may be required to be kept separate, by law or other regulation – for example, financial reporting versus financial audit.)

Next, extend the example to a slightly more realistic set of values. This leads us to something like Balanced Scorecard, which defines enterprise value in terms of four distinct themes: together with the existing financial measures as above, we add perspectives for Customer, Internal Business Processes, and Learning and Growth. Each of these themes has its own value-tree. (One reason why Balanced Scorecard implementations sometimes fail to give the desired results is that the value-trees don’t reach down far enough into the enterprise: if we take a service-oriented view of the enterprise, every activity has a ‘customer’, has its own ‘internal business processes’, and its own capability and need for ‘learning and growth’.)

To extend this further, each of the ‘-ilities’ trails of ‘non-functional’ requirements implies a root-value – for example:

• quality (in terms of the delivered business services or products)
• security (in all its multitudinous variations)
• privacy
• trust and reputation
• health and safety
• environment and waste-management
• transparency and ethics
• efficiency and effectiveness

As described well in TOGAF, each of those themes devolves outward via a set of principles, which ultimately need to link to everything. But on its own, a principle does nothing: it must be applied in practice (hence the importance of governance), and needs to be testable – and that testability must likewise ultimately link down to everything. (Testability isn’t described as such in TOGAF’s definition for the structure of principles, but is described well in Volere, the requirements-modelling process recommended in TOGAF.) The requirement-trees are the means by which the ‘develop awareness’ of the value-trees devolves downward; the tests in those requirements form part of how ‘monitor compliance’ of the value-trees rolls upward.

So a value-tree consists of the following:

• explicit value or ‘theme’, as topmost anchor for the respective tree
• principles that express and describe the value in practical terms (upper branches of the requirements-tree)
• requirements and tests, all the way down to the finest-granularities (both goal-oriented [end-point] and mission-oriented [continual / continuing])
• measurements, with tree of transforms and identifiers for roll-up and drill-down
• support-processes (‘pervasive-services’) for ‘develop awareness’, ‘develop capability’, ‘monitor compliance’ and ‘verify’

Each tree is fairly straightforward in itself: the complications arise from the fact that many of them will present conflicting requirements (e.g. security versus trust, safety versus efficiency). Because of this, there needs to be a tree of relative priorities, some of which may be imposed from ‘outside’ (e.g. legal requirement for priority of health and safety before profit). Ideally, there needs to be one single ‘master-value’ which acts as the ultimate arbiter for priorities – hence the importance of an unchanging enterprise vision.

Better stop there for now: but as usual, comments/suggestions would be most welcome!

Mildly amazing – I did meet that deadline.

Another new book in my Tetradian Enterprise Architecture series went off to press yesterday: The Service-Oriented Enterprise: enterprise architecture and viable services. So there’s a good chance it’ll be back in time to take to the TOGAF San Diego conference, which was the real reason for the deadline. Good.

The ‘sampler’ version of the e-book is now up on the Tetradian website; likewise the full version is on the private ‘preview‘ section of the site (as ’9781906681173_services_EB.pdf’), with the same password access-code as usual. Comments much appreciated, as always!

Physical books should be available from Amazon and other retailers from about a week from now. Will post updates on that when they’re available.

Now, back to catch-up mode… a lot of backlog emails to deal with, for a start – apologies to all on that. More later.