Archive for the ‘Business’ Category

Last-chance confirmed

Sunday, November 9th, 2008

(Reminder that this ‘last chance’ is only about the Enterprise Architecture series on the Tetradian Books website - not the Alternate Realities series such as Disciplines of Dowsing.)

Received the e-book publishing contract yesterday, and is dated to begin 10 November (Monday - i.e. tomorrow). To comply with that, I’ll be preparing stripped-down versions of the existing e-books during today, and will replace the existing complete ones at about 9am GMT tomorrow morning. So today is your last chance to download complete free versions of the following e-books:

The links will still work: but they’ll point to PDF files of sample-chapters, not the whole content.

Full details of where and how to purchase the e-books to follow in a future post: but I believe the price will be around £25.00 per copy, the same as the respective printed books.

At present you’ll still be able to download complete free e-books in the other series (Alternate Realities, Social Challenges and General Books). From now on, though, all books in the business-oriented Enterprise Architecture series - such as the upcoming The Viable Enterprise: enterprise architecture and the service-oriented enterprise - will go straight to full-price e-book as well as printed book.

Last chance to download?

Friday, November 7th, 2008

Some very good news from my side: I’ve had a preliminary offer by a well-known IT-industry publisher to market and sell the print and e-book editions of the books in my Tetradian Books ‘Enterprise Architecture’ series. The catch for you is that once the deal goes ahead, in the next week or so, you’ll no longer be able to download for free the whole book-content from the Tetradian Books website. There’ll continue to be sample-chapters on the site, but not the whole book.

Still awaiting confirmation, but this will probably affect all the following titles:

  • Real Enterprise Architecture: beyond IT to the whole enterprise
  • Bridging the Silos: enterprise-architecture for IT architects (yes, I know it still isn’t complete, but it’s almost ready now, and will go on release as soon as it is)
  • SEMPER and SCORE: enhancing enterprise effectiveness
  • Power and Response-ability: the human side of systems

(It won’t affect any of the other books, such as the new Disciplines of Dowsing - it’s just the enterprise-architecture series.)

So if you want a free PDF of any of those books above, better download it quick: this next few days may be the last chance you get. :-)

Wolfed

Sunday, November 2nd, 2008

Still recovering somewhat from a thoroughly nasty run-in with a guy named Wolf, on an on-line list about future vision for enterprise-architecture. (For obvious legal reasons, I’d probably better not give any more details than that.) To give some idea, he proudly claimed to be “a man of science”, but amidst a stream of insults - “whining”, “hapless”, “technophobic” - and sarcastic put-downs - “poetic wailing”, “now, for everybody who is still capable of independent rational thinking” - this was what he apparently considered to be a rational argument about the process of enterprise-architecture:

Keep dreaming Tom, and if your dreams also bring you some pay checks, I honestly envy you. Beware, though of the bad economy: less and less bosses are willing to pay for dreams.

He’d started off in the wrong direction anyway, because whilst we were talking about developments in how to do architecture at the whole-of-enterprise scale, his vision for EA, he said, was cloud-computing - in other words, a minor subset of content, not process. It became clear very quickly that whilst he certainly knew his stuff about technical-architecture and IT-based process-modelling, he was completely out of his depth in anything else - particularly business-architecture, whole-of-enterprise architecture, the process of visioning, and in some ways even the process of science. What he did manage, and manage well, was a startling degree of pseudo-scientific arrogance:

I have founded this group for those EAs who feel themselves rather a part of scientific community, using exact terms of scientific discipline to create exact solutions and extrapolate them to the future, rather than part of the order of augurs that make gibberish predictions because they not only cannot foresee the future but are unable to understand the present.

As any real practising scientist would know, we cannot predict ‘the future’: we can sort-of predict ‘a future’ for something which operates only within a defined set of premises, but the real world won’t confine itself within any such convenient constraints. And this, for example, was his ‘First Postulate’ for his ’scientific’ enterprise-architecture:

Modern Enterprise cannot run its Business Model without computing means;

Which is fair enough, in a sense - but it’s not science. There’s no rationale behind it: it’s just a religious-style Great Truth, floating in mid-air, without context and without anchors into the real world - where, in disaster-recovery, ‘Modern Enterprise’ may suddenly find it’s physically lost those ‘computing means’, and has to find a way to run its ‘Business Model’ without them. I was trying to explain that that is what an extended EA would need to cover - but he would have none of it at all. Cloud-computing was it: nothing else mattered.

And in effect, he did the classic TOGAF trick of thinking that the label of ‘business architecture’ in itself resolved all the issues about how to handle ‘all the architecture stuff that’s outside of my area of interest’:

EA has evolved and now includes, among others, distinct disciplines of Enterprise IT Architecture (EITA) and Enterprise Business Architecture (EBA), both well-formalized disciplines. EBA includes EITA plus to business-specific acumen like Accountability (people) and others. Everyone can just google or wiki Business Architecture and learn its definition.

Your ‘EA’ somehow includes ‘everything’ (do not know how - no definition) but does not include BPM, which is the common basis of and the bridge between EBA and EITA. For me all this makes the professional level of this discussion very low. It is a warning.

Apart from, again, the startling aggression and arrogance, real EA practitioners would notice the error here: he’s blurring high-level strategy, human factors such as accountability, and low-level process-mapping (BPM) all into the same randomised ‘EBA’ - the classic ‘business-architecture = everything not-IT’, without any means to separate out all the distinct interfaces and interdependencies. As for the comment “Everyone can just google or wiki Business Architecture and learn its definition”, it was obvious he’d never done so himself: if you try it, you’ll find that there are a near-infinity of would-be definitions, most of which seem to be mutually contradictory. :wrygrin: Far from being a “well-formalized discipline”, as Wolf claimed, the whole field of enterprise business architecture is still a disorganised shambles - a fact that anyone actually in the trade would admit straight away. Getting some sense of order into that mess is part of what the whole-of-enterprise architecture project is all about.

At first his aggression was directed solely at me; but then he realised that the other contributors weren’t joining in on the attacks, but instead were agreeing with what I’d said, and then adding further examples of their own (which was, indeed, what I’d hoped the discussion-thread would do). After he found that attacking them too didn’t work either, he pulled out the ‘I’m the boss here’ tactic:

I, as a specialist and the manager of this group, have said enough. Those who have ears, will hear. From now on, I will observe this discussion, as I do with others, unless I am explicitly asked by any participants to express my mind. Your right to express whatever weird views you want is limited by my right to end a discussion if I see it as compromising the group goals.

Metaphorically speaking, I could see a small boy, pouting in petulant rage at not getting his own way in some game, saying “it’s my bat and ball and I’m taking them and going home and then you won’t be able to play any more, so there!!” Which he did: he killed the thread, and, unsurprisingly, also my membership of ‘his’ list.

The whole affair has left a thoroughly nasty taste in the mouth:  I haven’t met that level of aggressively unprofessional conduct since dealing with a group of self-styled ‘pro-feminist’ men in a social-work context in the early ’90s. Though the same overall problem, I notice: the same obsession in asserting that the one very small subset of an issue - the subset that they (somewhat) understand and for which they purport to have ‘the answers’ - is the whole of the issue, combined with violent personal attacks on anyone who inadvertently threatens that quasi-religious belief. Odd; yet in some ways quite dangerous, especially for others.

But despite that, at least the thread did produce a lot of good ideas, and the interactions with the others in the discussion - particularly a guy called Richard, from Siemens - were definitely worthwhile. Since the content has been killed in its original source, I’ll put some of it up here in subsequent posts.

More later, then.

Architecture versus design

Tuesday, October 28th, 2008

Been re-reading Len Fehskens’ presentation “Re-thinking architecture” [may require login] at the last TOGAF enterprise architecture practitioners conference in Munich. His intro [public] indicates at last a fundamental shift in thinking about enterprise architecture, away from the inane IT-centric world towards a real architecture of the enterprise:

Most thinking about IT architecture as a discipline has been shaped by the ideas of the software architecture community, which in turn grew out of the software engineering and structured programming initiatives of the late ’60s and early ’70s.  Increasingly, though, IT architecture is less about programs and more about solutions and enterprises, of which software is only a part.  Does this shift in the focus of IT architecture require a corresponding shift in the way we think about architecture?  Many practicing solution and enterprise architects believe it does, and this session will re-examine the role of architecture from this perspective.

Gratifyingly, or perhaps worryingly, there were several slides which were all but identical in mood, if not content, to my own presentations at TOGAF Paris, eighteen months ago (“Unpacking TOGAF’s Phase B: business transformation, business architecture and business buy-in” - just discovered it’s not up on the Tetradian site, an oversight which I must remedy Real Soon Now :-) ) and at TOGAF Glasgow earlier this year (“Enterprise architecture and the service oriented enterprise” [PDF] - and that one is up on the Tetradian site!). He even included one slide which used exactly the same New Yorker cover to illustrate the limitations of an IT-centric perspective.

(Likewise Business Architecture lead Dave van Gelder’s intro to the session, and Open Group Fellow Walter Stahlecker’s presentation “The quest to apply architecture holistically” (summary and PDF [may require login]) often seemed to be echoing what I’d presented at those conferences and discussed with them in person: “…the implications of addressing architecture of an entire enterprise … possible adaptations of TOGAF for use with the whole enterprise…” and so on, with again some of the text and diagrams that could easily be said to be drawn from my previous presentations. Gratifying in one sense, yes, and all of them nice guys, earnest and honest and genuinely committed to what they do; yet it’s still a trifle galling that I didn’t get any acknowledgement for it at all. A passing reference to “builds on work by … the TOGAF Business Architecture Working Group”, perhaps, but that was it - a ‘working group’ which they’d offically excluded me from last year, and asked me to join this year, but then in effect asked me to pay them several thousand pounds to be ‘allowed’ to correct the disastrous mistakes in TOGAF’s design, and hadn’t bothered to contact me since. So yeah, I will admit I’m more than a bit miffed about it all: be nice to get some acknowledgement for all the work I’ve done, and even - though I’ll accept I ain’t holdin’ my breath for this - ‘twould be nice to actually be paid for some of it too… :-( Hey ho…)

But there was one slide in Len Fehskens’ presentation, ‘Architecture vs Design’, which to me was new, and which gives a very useful tabular comparison of the differences between architecture and solution-design. A handful of examples:

  • Architecture: about the entire entity in its environmental context; Design: about components and subsystems of the entity
  • Architecture: a different architecture implies a different mission; Design: different designs may address the same mission
  • Architecture: defines a class of acceptable solutions; Design: defines a single specific solution
  • Architecture: role of the architect is mostly to make correct inferences; Design: role of the designer is mostly to make correct decisions

The last item triggered a fair bit of discussion: Len was trying to show that architecture and design are fundamentally different, but wasn’t quite getting his point over - especially to some of the non-English speakers, for whom ‘inference’ and ‘decision’ seemed essentially to be the same. It was only later that I realised that the critical difference there is around a linkage between two other themes that Len had mentioned, about ‘values’ versus ‘business-value’, and architecture as ‘upstream’ requirements versus design as implementation of ‘downstream’ requirement. So here’s my suggested addition to that list:

  • Architecture: explores the values of the business to derive its structure and logic; Design: uses the structure and logic of the business to derive business-value

Design operates within a logic; architecture creates that logic. By definition, logic cannot assess the validity of its own premises; it needs an alogical process outside of itself to do so, and that’s the real service (or one of the key services, at least) that architecture provides. To many people in business, and perhaps even more in IT, architecture often seems vague and blurry and indefinite - but that’s what an alogical assessment of values will need, from which to derive the business logic which the designers can use.

Something to think about, anyway.

And yeah, for the reference to the Open Group folks in general: please note that you did see it here first? Oh well… the joys of the Outsider again, I guess…

TOGAF Munich

Wednesday, October 22nd, 2008

As mentioned in a previous post, I decided at the last moment to go to the TOGAF Munich enterprise-architecture conference. Kind of a wild one-day dash - up at 3:30am; 100kms there and back to Stansted; two hours each way on Ryanair to Salzburg; 300kms there and back Salzburg-Munich; back in Colchester at just before 1:00am - and not exactly cheap (a whopping £170+tax conference-fee for what was in effect just one afternoon), but I hope will be worth it in the long run. If nothing else, it was very good news to see a big shift in perspective about the nature and role of enterprise architecture, such as in these almost throwaway remarks by Len Fehskens, the Open Group’s ‘VP, Skills and Capabilities’:

The conventional wisdom is rapidly becoming that Enterprise Architecture is more than Enterprise IT Architecture.

  • There’s a lot more to an enterprise than its IT; IT budgets represent about 2% of revenues.
  • An increasing number of enterprise architects believe that the rest of the enterprise, often generically referred to as “the business”, should be architected as well.

To address the architectures of things outside the domain of IT, we need a concept of architecture that is not technological, and that is expressed in nontechnical language.

(Full link to Len’s talk Re-Thinking Architecture is here, but may require login.)

Considering how much so many people in ‘the trade’ (though not Len himself, I’ll hasten to add) have put me down, mocked me and a whole lot worse, for saying such things over the past few years, I’ll admit it is perhaps a little galling to see this now described as “the conventional wisdom”… But hey, the message is getting through. At last. At last.

So can now we actually get down to doing this, as a profession? Can we at last get the tool-vendors to give us some tools that will actually work for this purpose? And perhaps can those of us who’ve been stuck out there on ‘the bleeding edge’ for so damn long now get some help and support in doing so? - and perhaps, just perhaps, even some respect for the work we’ve had to do to get this profession to break out of its utterly inane IT-centric rut? :bleakwrygrin:

A slightly wary sigh of relief: hey ho. But yeah, good news. Worth the trip for that alone.

Updated ‘Silos’ draft

Monday, October 20th, 2008

Just a quick note to say that I’ve posted an updated version of the Bridging the Silos e-book on the Tetradian Books website. Still only a draft - sorry! - in fact still some six chapters to complete; but there is quite a bit more content completed than in the previous version.

Hope to have a final version out within the next three to four weeks, anyway. Have been slightly delayed again by the rush over to Munich for the TOGAF conference, and also by an academic paper on archaeology and archaeography that I’ve been asked to co-author - more on that in another post.

Revised-ADM reference-sheet available

Sunday, October 19th, 2008

I’ve now posted on the Tetradian Books website a two-page (single-sheet) reference-sheet on the revised TOGAF ADM that I use for whole-of-enterprise architecture.

The sheet is an extract from the ‘Methodology’ chapters in my still somewhat delayed book Bridging the Silos: enterprise architecture for IT-architects, where each step of the adapted ADM is described in a lot more detail.

Share and Enjoy, as usual?

Off to Munich

Sunday, October 19th, 2008

I hadn’t intended to go to TOGAF Munich this week, but a chance email from Jos van Oosten (the lead for the SqEME process framework, over in the Netherlands) got me glancing at the conference agenda - and what I saw there sent me scurrying to search the web for suitable flights. It was previously advertised as being solely about system security - which isn’t my bag at all - but the Tuesday sessions suggest that they’re at last breaking out of the IT-centric rut and getting to grips with whole-of-enterprise architecture - which would be very good news if so… So yup, I’s headin’ there kinda quick to find out, and see which way that wind is blowing.

One side-effect is that I’ve rather hurriedly ’staked my claim’ to the rework I’ve done on adapting the TOGAF Architectural Design Method (ADM) for use at the whole-of-enterprise scope, with a two-page / single-sheet reference-sheet now posted up on the Tetradian Books website. (Doing this before their conference presentations should verify that I did indeed get there first. :-) ) More on that in the next post. Some time in the near future I’ll also post an equivalent ‘cheat-sheet’ for the revised Zachman framework for whole-of-enterprise architecture.

And although I’m still some weeks away from completing Bridging the Silos, I’ll also post an updated draft on the publishing website, to include the material I’ve slowly been adding over the past few months. Apologies that it’s taken so long, but I’s been kinda distracted… :-)

Business-architecture frameworks

Friday, October 3rd, 2008

Diana Stobart Wild’s other question on the LinkedIn business architecture forum was about frameworks:

What is Business Architecture? What does a Business Architecture Framework look like?

I think of Business Architecture as a subset of Enterprise Architecture that describes the business from the Strategy down to the enterprise business models (process, data, business rules, etc.). Business parts of the Zachman Framework? Thoughts? Comments?

My response was as follows:

I’d agree that Business Architecture is a subset of Enterprise Architecture, as long as you don’t fall for the TOGAF-style trap of thinking that enterprise-architecture is only about IT!

Business-architecture proper is the strategy layer (Zachman row-2 and upward, also bridging down into row-3).

The jumbled mess of what’s otherwise called ‘business architecture’ only exists because TOGAF and the other IT-centric ‘EA’ frameworks essentially used the term as a generic dumping-ground for ‘everything not-IT’. Instead, think of the remainder of what TOGAF calls ‘business architecture’ as two distinct layers: the logical or integration layer - the equivalent of TOGAF’s ‘Information Systems Architecture’, Zachman row-3 to row-4 - and the physical or implementation layer - the equivalent of TOGAF’s Technology / Infrastructure Architecture, Zachman row-4 to row-5.

Zachman’s structure of layers still works fairly well for this - the only essential change is an extra ‘row-zero’ for compatibility with the Vision layer of ISO-9000:2000. But it does need some serious rework on the columns: for a start, there’s an entire dimension missing, to handle distinctions between physical assets (things), virtual assets (data etc), relational (what your CRM is all about!), aspirational assets (morale and the like), and abstract (such as the financials that your business people do want in their models!); the same for locations (physical, virtual, relational etc) and so on. Still a month or a so away from finishing my book on this, “Bridging the Silos”, but see the ‘Framework’ chapters in the current draft at http://tetradianbooks.com/2008/04/silos/ .

One point that Zachman did get right, but most of the EA-toolset vendors seem to have forgotten, is the key distinction between primitives and composites. As Zachman says, architecture is about primitives (TOGAF’s ‘Architecture Building Blocks’, or ‘ABBs’), whilst solutions come from composites or patterns (TOGAF’s ‘Solution Building Blocks’, or ‘SBBs’). The Zachman Framework is a taxonomy of primitives - root-level entities, some of them fairly abstract; composites are structured collections of primitives that straddle the columns, making up patterns for re-use.

Composites are usable to the extent that they’re architecturally ‘complete’ - i.e. straddle all of the columns - but are re-usable to the extent that they’re incomplete: for example, a BPMN process-model says nothing about ‘Where’ or ‘Why’, so can be re-used in different locations and (in principle) for different purposes. At the mid-layer of the framework, you need to be able to describe a process in abstract terms, to identify KPIs and CSFs and so on; you’d define different SLAs as you go down towards different implementations - manual, machine, IT, etc, but they should all use the same KPIs etc. This is important because if you’re not able to anchor the detail-layer composites into their component sub-composites, all the way down to their root-primitives, you won’t be able to see options for redesign, such as for disaster-recovery or process-reengineering. Think of the classic IT-centric blunder of assuming that every problem must always have an IT-based solution… your only way to avoid that trap is to use a non-IT-centric framework that covers the true whole-of-enterprise space.

Over the past few years I’ve done quite a bit of work on a ’service oriented enterprise’ framework, based on the classic Stafford Beer ‘Viable System Model’ - see the Wikipedia summary at http://en.wikipedia.org/wiki/Viable_System_Model . We extended this at Australia Post and elsewhere to include support for quality-systems, security-management and so on. Again, there’s still some way to go, and the book is probably at least six months away, but there’s a summary in my article on the service-oriented enterprise in the current itSMF “IT Service Management Global Best Practices” book (see http://www.vanharen.net ) and in my presentation to the TOGAF Glasgow conference back in April (see PDF at http://www.tetradian.com/download/togaf_ea-soe_apr08_FV.pdf ).

Business-architecture tools

Friday, October 3rd, 2008

Been following a ‘business architecture’ thread on LinkedIn, and came across a couple of discussion-questions by Diana Stobart Wild, who seems to be an enterprise architect somewhere in the north-east US. Thought it might be useful repeating here what I wrote there, as it’s all fairly generic but does summarise my current approach to business-architecture.

Her first question was on business-architecture tools:

Which tools are in the Business Architect’s toolkit?

to which I replied as follows:

If you come from an IT-centric architecture background, the first need is to realise that the standard EA view of business-architecture is a mess - it’s essentially a random grab-bag of ‘everything not-IT’. So you need first need to sort it into the business equivalents of TOGAF or FEAF’s three layers, such as:

  • strategy and policy (real meaning of TOGAF’s ‘Business Architecture’ - Zachman row-3 and above)
  • tactics and system design (equivalent of ‘Information-systems Architecture’ - Zachman row-3 to row-4)
  • process implementation (equivalent of ‘Technology Architecture’ - Zachman row-4 to row-5 [and, in past tense, row-6])

For the strategy layer, one obvious tool is BRG / OMG’s Business Motivation Model [PDF]. It has some flaws - particularly its dangerous mishandling of ‘Vision’ - but it’s a good starting-point. Several EA toolsets implement the BMM, though sometimes under different names: for example, IBM/Telelogic System Architect calls it the ‘Enterprise Direction’ model.

For the middle systems-layer, to be honest, I don’t know: we’ve been doing a lot towards modelling that space - see my book “Real Enterprise Architecture: beyond IT to the whole enterprise”, at http://tetradianbooks.com/2008/04/real-ea/ and the current draft of “Bridging the Silos: enterprise-architecture for IT-architects”, at http://tetradianbooks.com/2008/04/silos/ - but there’s still a fair way to go yet. Troux’s ‘Metis Enterprise Architecture Framework’ covers [covered? it may not still exist…] a lot of the space, but as usual ends up being too IT-centric for real business-architecture use. Even so, Troux is probably the best bet at present: in my experience, to be blunt, most of the other well-known EA toolsets are so obsessively IT-centric that for business-architecture they often seem more of a hindrance than a help.

At the process level, there are plenty of tools and models available, many of which are not inherently IT-centric, such as all the IDEF and TQM and Six Sigma toolkits. Some IT-centric tools can be re-used in a non-IT-centric way, too: you can use BPMN for implementation-layer business-architecture modelling, for example, once you realise that the Process entity doesn’t care how it’s implemented unless you really need to translate across to BPEL; and the ‘Data Object’ entity doesn’t need to be data, but can actually be any type of asset - physical, virtual, relational or whatever.

Another tool I’ve found invaluable for understanding complexity in business-architecture, and the boundaries between what can and can’t be handled by IT, is Cynefin - see the Wikipedia summary at http://en.wikipedia.org/wiki/Cynefin , also Snowden, D & Boone, M “A Leader’s Framework for Decision Making” Harvard Business Review November 2007.