Tom Graves / Tetradian

One of the more subtle problems in enterprise-architecture – in English-language, anyway – is the distinction between values (plural) and value (singular, but often used as plural). The Enterprise Canvas frame provides several useful methods via to disentangle an existing values-mess, and prevent getting into that kind of mess in the first place.

In Enterprise Canvas, we assert that everything is or represents a service. Ultimately, each service serves the overall vision or purpose of the shared-enterprise, which often extends far beyond the boundary-of-control of the organisation itself.

The values of the shared-enterprise derive from and express that vision or purpose. Hence these are values that the organisation must respect if it is be and remain in business within that shared-enterprise. For example, the TED vision of “ideas worth spreading” is expressed in practice through values such as responsibility, respect, clarity, connection, engagement, passion for ideas and production-quality – values that can be seen in practice in just about everything for which TED has either direct responsibility or oversight (such as the independent TEDx conferences).

In the sketch-notation for Enterprise Canvas, we typically model these as the ‘vertical axis’ through the service, connecting intent to real-world results:

In detailed practice and implementation, the values are expressed in more actionable form as principles. (See Chapter 23 ‘Principles’ in the TOGAF 9 specification for a good summary of how to define and structure actionable principles.) Principles are used to guide decision-making in the face of uncertainty at every level of abstraction, from strategy to tactics to real-time operations.

Value is what is passed around the enterprise, as exchanges between services, in order to achieve the overall aims of the shared-enterprise. In effect, exchanges of value within the enterprise align with and contribute to the values of the enterprise.

In the sketch-notation for Enterprise Canvas, we typically model most of these exchanges of value as the ‘horizontal-axis’ through the service, connecting with other services before, during and after each main-transaction. We would sketch a simple supplier-self-customer supply-chain model – such as is typical in Business Model Canvas – in a format somewhat like this:

To make better sense of that ‘horizontal’ flow of value, we often partition the service into a three-by-three matrix of ‘child-services’ – the matrix being formed from a time-dimension (before, during and after) and an orientation-dimension (inbound [service-consumption], self [value-creation] and outbound [service-provision]):

Often in modelling with Enterprise Canvas we’ll use generic labels for each of these clusters f ‘child’-services. For our purposes here, the cluster we need most to focus on is value-governance, which acts mostly (though by no means exclusively) on the back-channel, the ‘after transactiuon’ flows:

The service also needs to connect to other guidance-services, to help keep the flow of value on track to the enterprise-values. The guidance-services include:

• direction-services - the strategic, tactical and operational forms of classic ‘management services’
• coordination-services - guiding end-to-end connection of processes that intersect with multiple services, often across or between organisational silos
• validation-services - services that assist in building awareness, capability and action, and verifying and auditing that action, on ‘pervasive’ value-themes such as knowledge-management, health, safety and environment, efficiency, reliability, security and financial probity

In Enterprise Canvas sketch-notation we’d typically show the guidance-services like this, tagged with the respective symbol:

Of the guidance-services, probably ‘direction-services’ connect must strongly with the ‘Value Governance’ cluster of child-services, though by definition all of the guidance-services must connect with every part of the service.

So far so good: value connects to values.

Yet there’s another set of service-relationships that we must not overlook: the relationships with investors and beneficiaries. In Enterprise Canvas sketch-notation we’d usually show them like this:

Investors provide forms of value that are different from the forms of value that flow ‘horizontally’ around the shared-enterprise, but may be needed in order to start up, operate and maintain the service. The obvious example is financial investors, where the value of the investment is usually described in monetary terms. Yet there are many other forms of value that may be involved: for example, a community invests trust and, often, hope in an organisation doing business in its locality; families of employees may invest very real energy to keep them working there, and so on.

Beneficiaries receive some of the returned-value from the service, typically diverted from the flow in the backchannel, as a ‘dividend’ or suchlike. Again, the obvious example is value in monetary form, but again there are many other possible forms of value: civic pride, for example, or the shared pride of employees’ families.

Yet there are two fundamentally important traps to note here.

One is that the Investors and Beneficiaries may be different people. For example, an ‘externality’ occurs whenever one or more groups invest their own forms of value, but another group extracts all or most of the available value in one preferred form only, damaging or destroying most or all other forms of value. Again, the obvious example is financial: the community and employees invest their energy and their time, but the shareholders – as nominal ‘owners’ – claim the ‘rights’ to possess all of the returned-value, which somehow must also be converted to monetary form. A key role of value-governance is to identify such mismatches, and to bring them back into some form of balance that is acceptable to all parties – otherwise the service will fail over the longer-term.

(Somewhen I’ll have to write a post about anti-clients, anti-value, anti-Investors and, especially, anti-Beneficiaries. But that, as they say, is another story for another time!)

The other trap is that whilst the Investors’ and Beneficiaries’ forms of value may be needed by or deliverable by the service, the values of the Investors and/or Beneficiaries may not align with those of the service’s shared-enterprise. In enterprise-architecture we do need to respect the drivers and needs of Investors and Beneficiaries, but it may be essential to keep the value-systems separate. If we don’t, we risk ending up with the kind of lethal mess where, for example, attempts are made to measure everything in monetary terms, blocking the actual forms of value that traverse ‘horizontally’ across the enterprise-space.

Michael Porter described one form of this trap as“the obsession with shareholder-value is the Bermuda Triangle of strategy, in which companies sink without trace”. There are many forms of this trap, though: look around at much of mainstream politics and politically-motivated regulation these days, or the sad disaster-area that is the ‘rights’-discourse… It’s definitely a real challenge for any enterprise-architect.

In short:

• values guide decision-making and appropriacy of choices within the shared-enterprise
• value is what flows around, through, to and from each service in the shared-enterprise

So in each architectural context, be clear what values and forms of value you’re dealing with, and how and where and why – and don’t mix them up!

Nice to see that even the ‘big fish’ are finally ‘gettin’ there’ on the real scope of enterprise-architecture…

A month ago we saw Open Group begin to re-frame their previous IT-centred approach to EA into a new style of ‘enterprise transformation’. (The conference was still more IT than anything else, of course, but at least it’s a solid move in the right direction.)

Then a couple of weeks back it was academic and EA-luminary Jeanne Ross making clear her opinion that enterprise-architecture does not belong in IT, under the CIO. To quote her interview in CIO.com, “companies need to acknowledge that ‘architecture says everything about how the company is going to function, operate, and grow; the only person who can own that is the CEO’”.

And now it’s Gartner, at this year’s Gartner Enterprise Architecture Summit in London earlier this week. I wasn’t able to get there this time, as I’m currently ensconced in central-America working on a bunch of EA-related projects; but fortunately the indefatigable Gerold Kathan was there, sending out a whole stream of useful tweets:

• gkathan: #entarch has no value until it is acted upon – deliverables should not be confused with value #gartnerEA
• gkathan: customize and adapt your #entarch framework – industry frameworks should be used for inspiration, not perspiration #gartnerEA
• gkathan: bringing something new like #entarch into top level management is hard: they will treat it as enemy in the beginning #gartnerEA
• gkathan: “EDD” is impacting application lifecycle: “executive deficit disorder” – short term focus and irrational decisions #gartnerEA

But what really caught my eye was this little beauty:

• gkathan: you have to reach out the 4 walls of your organization – extended enterprise includes e.g communities #gartnerEA

To which I can only sigh ‘Hooray!’…

I’ve no idea which of the Gartner consultants it was who said it; and since Gartner itself seems to have a policy of not crediting ‘outsiders’, I’ve also no idea if that comment has any link to the various conversations I’ve had with Gartner folks over the years. But just for the record, here’s my version of the full scope that an organisation’s EA must address, all the way out beyond the market to communities and more:

I’ve used a few variants of that in my EA presentations over the years – such as ‘What is an enterprise?‘ and the very-popular ‘The enterprise is a story‘ – but that’s the core idea, anyway. Nice to see that Gartner too is at last officially acknowledging that kind of scope for EA.

On the other side, I ought to acknowledge another ‘big fish’ that sort-of got there quite a long time ago. I was trawling through my downloads on this little-used netbook, and came across a report from Infosys – ‘Enterprise Architecture Expands Its Role In Strategic Business Transformation‘ [PDF] – from way back in 2008. It seems that even back then, the IT-centrism that still dominates ‘the trade’ was beginning to be challenged a lot more than most of the ‘big fish’ would be willing to admit:

Architecture steps out of the scope of IT and becomes part of planning and implementing strategy. In 22% of responding organizations, architectural processes are already being used for general business transformation.

And there’s this in the report, too:

Transformation is implemented in multiple streams within multiple units and functions of the firm. Today’s approach of architecture – looking at everything outside of IT as ‘the business’, and trying to access it through fairly generic, coarse-grained models – is bound to fail. A future enterprise-architecture will be ‘the architecture of the enterprise’. It will need to address the whole organization and each of its functions through appropriate models which are meaningful to the specialists of each area, and help them drive transformation. This means that it will have to provide structured models to represent architectures for production, research, finance and HR – much as it has for IT.

There’s a subtle trap in that that view is still centred around the organisation – ‘inside-in’ or ‘inside-out’, rather than the essential ‘outside-in’ view indicated in the Gartner quote above –  but at least it’s a lot broader than the obsessive IT-centric view that predominated then, and is still all too common even now. Credit where credit’s due – and worth reading the rest of the interestingly prescient report, too.

Gettin’ there, anyway – slowly, perhaps a bit too slowly for comfort still, yet we are gettin’ there. Feels good.

The real art of enterprise-architecture, and perhaps its hardest challenge, is in presenting the right level of detail. Not too little, not too much, but just enough.

Just Enough Detail.

To which people will, of course, immediately ask, “Okay, but how much detail is ‘Just Enough Detail’?”. And I’ll have to admit that there isn’t a simple. certain, predefined answer. You just have to kinda know when enough is enough, you know? – which is why it’s more art than science, I guess. And why experience – usually gained by not getting it right… – is so important here.

One thing I do know is that one of the most-quoted answers is usually just plain wrong for this. John Zachman has always said that we need to document everything in ‘excruciating detail’. In a sense, yes, he’s sort-of right, especially if you hold to his metaphor that enterprise-architecture is essentially the same as engineering an aircraft. (I happen to believe that that’s a seriously-misleading metaphor, but that’s another story.) Yet in the real world – even in aircraft-engineering, as I know from much first-hand experience – much of the detail won’t stay the same for long enough to make that ‘excruciating detail’ requirement achievable in practice. Tricky…

Reality is that everything changes, everything moves. And the more they change, the more the demand for ever-more-detail becomes a trap. And when the pace of change itself is accelerating fast – as is definitely the case in most enterprise-architecture contexts right now – the more dangerous that ‘too-much-detail’ trap becomes, and the more we risk falling into it.

Yet on the other side, not enough detail means we won’t have enough of an anchor for meaningful sensemaking or decision-making – so we risk making bad decisions on the basis of too many arbitrary assumptions. That’s not a good idea either.

Hence Just Enough Detail.

The point is that that ‘just enough’ of Just Enough Detail varies all the time, from context to context, depending on who we’re with, what we’re doing, what we’re aiming to do, the type and rate of change, and all manner of other factors. Take this example from one of my favourite ‘show this to clients’ books, Matthew Frederick’s 101 Things I Learned In Architecture School:

There’s actually not much detail in that image. There’s no detail at all of the wall – and yet that’s still enough detail to make out that it is a wall (and probably a white-plaster wall at that). Other than the outline, there’s almost no detail of the woman, or her clothing – and yet it’s enough to get a good sense of who she is, what she looks like. There’s a bit more detail of the church and its dome – enough to tell that it is Brunelleschi‘s masterpiece in Florence – and of the townscape around it. Not much detail, then – and yet that’s all the detail it needs to tell the story. Not too much; not too little; Just Enough Detail.

So, over to you: how much or how little is Just Enough Detail in each part of your enterprise-architecture? How do you show that Just Enough Detail to whoever needs to see the story?

How much does Just Enough Detail change between different layers of abstraction, between different audiences, between backbone versus edge?

How do you know when it’s too much detail, or too little? How do you know when it’s just right? – when it’s Just Enough Detail?

How do you learn this delicate, ever-changing balance of ‘just enough’? From where and in what ways do you learn that balance – without causing too much damage whilst learning it?

Just Enough Detail, always. An interesting challenge, yes?

At least he was open about it, I guess. “Tell you what I’ll do”, he says to my colleague here in Guatemala, “I’ll find you a client, then I’ll sit in, learn everything you do, and then I’ll apply it in my own business. How does that sound to you?”

Uh, no. Not a good idea. Not just because it’s a really bad deal from our perspective, but much more that Reality Department really doesn’t work that way: there’s no short-cut to experience.

Yes, it all looks simple enough – in fact that’s the whole point. A lot of simple visual summaries, and surprisingly simple-seeming methods, too. Yet it only looks simple because we’ve been through a heck of lot of hard work to make it that way. Hard-won experience, won the hard way through years and years of practice in many, many different contexts, getting it ‘wrong’ time and time again, in many, many different ways in order to get it right.

The real trap is that these simple-seeming ideas and methods aren’t simple rules, prepackaged sense-making and decision-making that will always work in every context. These are simple principles, simple guidelines, the kind of easy-to-memorise information that helps decision-making in real-time, in circumstances that are subtly different every time. (See my SCAN posts for more on these distinctions.) If you try to use them as ‘rules’ for inherently-uncertain contexts, without understanding why those principles apply, or how they need to be tweaked every time to match each different context, you’re going to be in real trouble – along with everyone else around you. Not a good idea…

The same often applies even to things that really are ’rules’. Take that example of perhaps the greatest simplification ever made: e=mc². All the core information you need to build a nuclear power-station is right there in that equation: but there’s a heck of a long way – a heck of a lot of engineering-experience – to go from that one equation to building a nuclear-power station that actually works.

Same with everything else, really: simplification is essential, but can also be deceptive – especially when people mistake ‘simple’ for ‘easy’…

Which is also why I get a bit hot-under-the-collar about the current proliferation of ‘certification-schemes’ in enterprise-architecture and elsewhere. Some of them are genuinely valuable, but others – to be blunt – are little better than money-spinning scams, in terms of the actual value that they (don’t) deliver. And the crucial distinction revolves around the role and recognition of experience.

For example, the TOGAF Foundation and Archimate Foundation certifications have real value. They verify that the respective person has a credible command of the terminology and language – a requirement that matters a lot for communication across a dispersed and disparate team.

Likewise the ATAC certifications should have real value, because each explicitly tests practical experience in the respective area.

But unless they’ve changed it in the past year or so, the full TOGAF certification is delivered through the absurdly-inappropriate mechanism of a multiple-choice test. And to my mind, that’s not merely useless, it’s actually worse than useless, because it’s exactly how not to test for the kind of experience that that type of competence requires. (When I did the TOGAF 8 exam some years back, I almost failed because I answered several key questions correctly in terms of real-world experience, rather than the theory-based wrong-assumptions that the test thought were ‘right’.) The result of that kind of pseudo-test is a bevy of people who can wave a certificate around, but have no idea how to do the work in any real-world context.

A good training-course can make all the difference, and the better training-providers do take up some of the slack here. (I’ll wave a flag at this point for John Polgreen at Architecting The Enterprise, who’s been doing sterling work for years on adapting TOGAF for the US-government context.) Yet none of that competence carries through anywhere into the actual test: so unless we know each of the training-providers, we have no way to tell whether a candidate does actually know what they’re doing, or merely that they have a piece of paper to prove that they know just enough to get into real trouble, but not enough to get out of it again.

In effect, right now, the full TOGAF certification is of less real-world value than the Foundation certification – which is both bizarre and sadly pointless. And I’ll hasten to add that I’m using TOGAF here merely as one example amongst many: it may well be that most of the so-called ‘certifications’ in this field are even more meaningless than that. And the results can be seen everywhere in the trade…

In short, it’s a mess.

What we need to be testing for is genuine understanding of a context, and the ability to adapt for uniqueness. And that calls for much, much more than can be covered in a crude multiple-choice test delivered through a mindless machine. Sure, that kind of test is cheap, and relatively easy to administer: but it’s also all but meaningless for anything than foundation-level rote-knowledge. It really does take years of painful practice to develop the experience needed to do this work well: and if this trade is to gain the credibility that it needs, we need to stop pretending that we don’t need to test for that experience.

Time to re-think how we do this, and how we respect this, too: there’s no short-cut to experience.

Enterprise-architecture is dead – long live enterprise-transformation! Or so it would seem, from the description of the current Open Group conference at Cannes.

Yet is all as it seems? I’d have to admit that the conference-programme does worry me a bit. Despite the presence of a fair few people with a broader view than just IT – Alex Osterwalder, Len Fehskens and Stuart Boardman, to name just a few – so much of it still seems to be the same-old search for the ‘next big thing’, the next soon-to-fail IT-based magic-bullet: currently ‘Big Data’, mobility, cloud, cloud and more cloud. Oh well.

A bit of history might be relevant here. Back at the start of the 20th century, the electric motor was the great ‘next big thing’. Huge excitement! – huge hype! – the electric motor will solve everything! No doubt that it transformed industry: freed at last from that terrifying tangle of belts and pulleys, machines now placed wherever fits the workflow, smaller, more compact, more convenient. A whole new infrastructure to power it, control it, monitor it, measure it, manage it.

(Sounds familiar, perhaps?)

And finally, when electric motors were literally everywhere, embedded in almost everything, the realisation that although the electric-motor is an important enabler, it’s only an enabler: isn’t the enterprise itself.

The enterprise isn’t solely about machines, or information, or ‘making money’: it usually includes all of those things somewhere within the overall picture, but first and foremost it’s about the hopes and desires and aims of people. If we ever forget that fact, there’s no space for enterprise – and hence nothing against which enterprise-architecture, or enterprise-transformation, could ever make sense.

As Simon Sinek puts it, any enterprise-scope work must always start with ‘why’: the ‘how’ and ‘with-what’ come later in the story. And for enterprise-architecture that ‘why’ must always be about the whole of the scope – not solely about some arbitrarily-selected subset. Open Group’s TOGAF is excellent for enterprise IT-architecture; yet its rigid focus on IT (as defined in sections B, C and D of its Architecture Development Method) renders it problematic at best for anything else in the enterprise-architecture space. It’s fixable, as I’ve explained at various Open Group conferences and elsewhere over the past five years or so: yet still that kind of update has not been applied to the ADM, and in that sense TOGAF 9 represented a sadly-missed opportunity. As a profession, we need to do better than that.

To give some idea of what I mean by ‘the enterprise’ – and hence its architecture and its transformation – take a look at some of the projects I’m exploring at present in Latin America:

• a medium-sized brewer needing to resolve problems with internal theft
• a large manufacturer addressing multi-way ‘cultural translation’ between Asian ownership and executive, US management and methods, and Latin engineers and workforce
• a government department working with a film-producer to use social-media to break the cycle of mutual distrust between police and schoolkids and teenagers in the slum-districts
• an NGO wanting to use the ubiquity of cell-phones as a means to improve health-care in widely-dispersed indigenous communities

It’s likely that in each of these contexts, an enterprise IT-architecture will play some important part: but the IT itself is not the sole focus of the overall task. To make any of those transformations work, we need to start from people, not IT – start from enterprise as enterprise – and keep that whole enterprise in mind at every moment.

It may well be that enterprise-architecture is dead – but if so, it was killed by inanely inappropriate IT-centrism, in Open Group and elsewhere. As we move to a nominally broader-based enterprise-transformation, could more effort be made to ensure that we do not repeat the same IT-centric mistakes? Please?

A great Tweet from Oscar Berg this morning:

• oscarberg: IMO #socbiz is primarily a mindset&way2see business in increasingly connected & digital age

I think he’s exactly right there: in essence, ‘social business’ is a different mindset about the way a business relates with others, and also with itself (as in the now seemingly-all-but-forgotten ‘Enterprise 2.0′).

But there’s a real booby-trap there that it’s essential to avoid (and that too many people did fall into with ‘Enterprise 2.0′). And that’s that this is not about the technology: it’s about the connections.

Okay, we’ll be fair about this, and agree the new digital technologies are important, as enablers of connections that would otherwise be hard (but not impossible) to set up via other means. As Andrew McAfee once put it, we’d have to agree that “it’s not not about the technology”.

Yet in social-business the connection is what matters: the ways we connect are always of secondary importance relative to that core focus.  If we ever lose sight of the fact that the technology is merely an enabler of connection, and not the connection itself, we’d be in real trouble real quick, with no way to see why we’re in trouble. Oops…

Something always to keep in mind here, please?

[A collection of notes that I made somewhen around May 2010 that I don't seem to have published before, and seem to be relevant now as I explore my own business-model. (Not an April-Fool joke, by the way. ) ]

A culture [enterprise-culture] is a set of prioritised values and goals – usually ill-expressed, conflicting, a muddled-mixtures of tacit and explicit. (Can be revealed by POSIWID – ‘the purpose of the system is what it does’.)

An enterprise begins with a vision.

A vision is a single emotive idea (a ‘parti‘, in architectural terms).

Values are used to identify what is and is not aligned to the vision.

The vision is the heart of a story; the enterprise is that story.

The organisation does not define the story - the enterprise does.

The organisation can choose which story to serve, and its role in serving that story.

The values of the enterprise provide a means to identify [and measure] alignment to the story.

The organisation can change its choice of enterprise to serve; yet doing so may (will) disrupt the values and prioritisation of values on which the organisation at present depends.

The story is the journey itself – there is no ‘final destination. (If there is a goal, the story will end, and likewise the reason for the organisation’s existence; so if there is a goal, plan from the start as to what will happen when the story ends.)

The structures and strictures of the organisation are a means to serve the story.

If you change the choice of story, you’re asking every person in the organisation whether they want to be [remain] in the organisation – to reconsider their ‘reason to be’, in relation to the enterprise and organisation. Not a trivial change!

Every person is ‘in’ multiple enterprises – prioritises which story (or stories) they serve.

To be successful, an organisation provides a clear prioritisation of stories.

The enterprise determines quality - what quality is. The vision is the ultimate anchor of quality (as per ISO-9000).

In the market-model, markets are:

• transactions (physical)
• conversations (virtual)
• relationships (relational)
• purposeful (aspirational)

Markets are all of these things, all together. (There’s a crosslink to here to effectiveness: for example “cheap, easy, gets all the shopping done in one go” etc.)

Market-sequence or market-cycle:

• reputation (also crosslink to vision); trust and respect (relational dimension)
• brand is ‘pre-packed reputation’
• attention and conversation (shift to virtual dimension)
• is often the preferred starting-point in the cycle (hence advertising, pre-brand)
• transaction (physical dimension), profit as ‘extracted value’
• transaction-only is (overly-simplistic) machine-model of the market
• needs full completions – customer, market, shared-enterprise – to complete the cycle and (re)affirm reputation

Hence ‘cost’, ‘profit’ etc are multi-layered – determined by the values of the enterprise.

[A possibly-useful item from the archives - hope it's of some value to someone, anyways.]

I have at last found a viable workflow to produce e-books of my various books and blogposts, via Leanpub.

There’s one significant constraint in this form of publishing: Leanpub uses Markdown text-files for input, which is a fair bit more limited in its formatting than my books normally use. But that constraint fits well with the very tight limitations of .MOBI (Kindle) files – the cause of so many of my conversion-nightmares prior to finding Leanpub – and it also works well with automated import and conversion of blog-posts, which is something I’ve needed for a very long time.

Leanpub also presents e-books as a ‘package deal’, with EPUB, MOBI (aka AZW, for Kindle) and portrait-formatted PDF formats all included in the one price. They also support an automated means to sell via Apple iBooks (for iPad etc) and Amazon (for Kindle), but doing that costs a fair bit and it’s a much lower royalty, so I’ll only be able to do that for books for which there’s a sizeable demand. For everything else, Leanpub is simple enough and cheap enough to make it worthwhile to publish a lot more of my material that way.

A key theme at Leanpub is publish early, publish often. If you buy a book, you not only get all three file-formats, but you also maintain access to all future updates – Leanpub send you an email to let you know whenever a new update is available.

See my home-page at leanpub.com/u/tetradian for the current status of each item – published or in-development – and, if published, the current content.

—-

I’ll be doing three types of e-book publications: books, practice-notes, and anthologies of posts from the weblogs.

Books (Tetradian Enterprise Architecture series)

These are straightforward e-book versions of my existing books, though in some cases with additional content from the blogs. The aim is that these should also move out to Amazon (for Kindle) and probably Apple (for iBooks). Once published, the content should not change – in other words, the same as for a conventional printed book.

Pricing will be a lot less than for the respective printed book.

Already published on Leanpub:

• The enterprise as story - same as for the printed book
• Mapping the enterprise - with an additional appendix on the simplified notation for Enterprise Canvas
• Everyday enterprise-architecture - same as for the printed book

Conversion from Word is not all that simple: each book takes a few days to get ready for publication, so it’ll be a few weeks before all of the existing books are up there. My current priority-order for conversion of the other published Tetradian EA books is:

• The service-oriented enterprise - with some additional notes linking it to Enterprise Canvas
• Doing enterprise-architecture
• Bridging the silos - with some additional notes on working with TOGAF 9.1 and Archimate 2.0
• Real enterprise-architecture
• Power and response-ability
• SEMPER & SCORE

Please let me know if you need my to change that sequence.

(I’ll probably also do all of the books in the other series at some stage, but it’s not so much of a priority.)

Practice-notes (Tetradian EA Practice series)

These will be ‘mini-books’ – typically about half the length of my usual books – that cover a specific topic focused on some practical theme. The content will be based on existing weblog-posts, but will usually be edited quite a bit to make a more consistent structure and story, and there’ll also be a new introduction-chapter to set the context in each case.

These will be updated occasionally, to keep in line with developments in practice, but also to keep the number of updates sent to Apple or Amazon down to a practicable level.

Pricing should be around half that of the full-length e-books.

Titles already in plan include:

• Using SCAN for sensemaking – about sensemaking and decision-making for enterprise-architecture with my SCAN framework
• Modelling with Enterprise Canvas – the simplified notation for Enterprise Canvas, plus model-development methods such as the ‘This’ game
• Backbone and edge - about the architecture trade-offs between slow-changing core and fast-changing edge, waterfall versus agile, and governance to match
• From business-model to real-world practice - conversion from Business Model Canvas to Enterprise Canvas, customer-journey mapping and implementation-layer models such as UML and BPMN
• Modelling service-content - how to use the expanded Zachman-type taxonomy from Enterprise Canvas for whole-of-enterprise modelling
• Whole-of-enterprise architecture - how and why to extend enterprise-architecture beyond its conventional focus on IT

Again, let me know if you want me to add other themes or to change that priority-order – and keep an eye out on my Leanpub page as to when new Practice Notes e-books will be coming out.

Weblog-anthologies (Tetradian EA Topics series)

These will be straightforward anthologies from the Tetradian and Sidewise blogs – the kind of publishing for which Leanpub was initially designed. There’ll be a very simple introduction-chapter, and some minimal clean-up editing, but otherwise each chapter will essentially be the same as on the weblog.

(Note that, for obvious reasons of cross-reference and cross-linking and the like, some blog-posts will appear in more than one anthology.)

The main purpose here is to sort the many posts on enterprise-architecture and related themes (more than 500 posts so far…) into a more usable form, and in a format that’s convenient for offline reading on Kindle and the like.

These will be updated quite often, whenever a suitable set of blog-posts come along – and because of the frequent updates, will probably not go to Amazon’s Kindle-store or Apple’s iBookstore. (You would do a simple file-import to your reader-device instead.) Perhaps the key point is that once you’ve bought the anthology-book, you’ll continue to get all of those updates for free.

Pricing will be minimal – it’s mainly to cover my time for conversion and clean-up. But the price for each book will rise slowly as the amount of content increases – so the earlier you buy the book, the better the deal you’ll get.

Some key topics already identified include:

• Tools and toolsets – including all the discussion around metamodels and the like
• ‘Really Big Picture’ enterprise-architecture – applying EA principles to themes such as economics, sustainability and society as a whole
• The architecture of management – rethinking management and the like from an EA systems-thinking lens
• Story and narrative in enterprise-architecture – the underlying themes behind The enterprise as story

Again let me know if there’s any specific theme upon which you’d like me to develop an anthology.

Comments, anyone?

Also launched at the Integrated EA 2012 conference was my new book ‘The enterprise as story‘:

Full title: The Enterprise As Story: the role of narrative in enterprise-architecture

ISBN: 978-1-906681-34-0

Description:

Most current approaches to enterprise-architecture describe everything in terms of structure. Yet people work better with story than with structure – and people are the enterprise. As we expand the architecture towards a true whole-of-enterprise scope, we need to describe the enterprise as story. Story is everywhere in the architecture – even the enterprise itself is a story.

This ground-breaking book places story at centre-stage for the architecture, itself using a narrative structure to explore the role of narrative in enterprise-architecture. Via business story-structures such as the Market-Cycle, and genres such as We Sell Certainty, it shows how stories underpin every aspect of the enterprise – and how we can use story within the architecture to enhance overall enterprise effectiveness.

Topics covered include:

• how to use story and narrative to assist in sensemaking for architecture
• how to create engagement in the architecture through story
• how to balance structure and story for better business results
• how to identify and use business-story genres to guide overall architecture
• how to change the organisation’s relationships with its ‘anti-clients’ from business-risk to business-opportunity
• how to use story-patterns to identify and resolve strategic business-issues
• how to leverage your own experience to create stronger architecture stories

If you want to create real engagement in the architecture and the enterprise, this is one book you’ll definitely need.

—

You can already order the printed book from Amazon.co.uk or Amazon.com, and presumably most other book-retailers as well.

(Ignore the comment on Amazon about ‘Temporarily out of stock’: Amazon say that for any print-on-demand book that they themselves don’t produce… It’s at most a couple extra days’ delivery-time, that’s all.)

I’ll also be adding it to the book-set deals on Kevin Smith’s Pragmatic EA bookshop: should be set up within the next few days, anyway.

And new - you can now buy the e-book from Leanpub, as a complete set of PDF (portrait-format), EPUB (for iPad, Sony-Reader etc) and MOBI (for Kindle).

I’ll be doing a lot more publishing via Leanpub from now on: not just e-books of the existing books, but also smaller more focussed e-books on topics such as SCAN sensemaking and modelling with Enterprise Canvas. More details on that in an upcoming post, anyway.

‘The enterprise is the story‘ – my presentation from the recent Integrated-EA enterprise-architecture conference in London – is now online on Slideshare:

The slidedeck is just under 80 slides, split into five sequences:

• “What’s the story?” – introducing the idea of story as a way of working within enterprise-architectures, using the example of Carnaval, in Rio de Janeiro
• “A cast of thousands!” - describing the ‘sharedness’ of enterprises and the enterprise-story, again using Carnaval as its example
• “The plot thickens…” - linking story to process and the practical details of the enterprise
• “To be continued…” - exploring the structure of story, and strategic-structures that cause failure of the organisation’s story
• “Every picture tells a story” - a plea for stronger support of story in our enterprise-architecture toolsets

For once, I did a slidedeck that’s more about visuals than words – and it certainly seemed to go down well with the audience, which is always good fun.

The conference is, for me, one of the highlights of the year, because they cover architectures with such an enormously varied scope: most of the attendees are from defence / security contexts or high-reliability areas such as rail-transport or air-traffic control. I put in a a few sort-of visual jokes that I put in specifically for them – which seemed to go down well, too.

I also did a audio-recording, but it’s a bit crackly. I’ll try to clean it up and, if so, attach it to the slidedeck to make a bit more of a standalone presentation.

Share and enjoy, anyway?