Another collection of Tweets from the Open Group Boston conference, mostly from Day 3 (21 July 2010), and variously on business-architecture, the EA profession, cloud-computing and a few miscellaneous themes. As before, a few additional comments from me in italics.) Thanks again to everyone who Tweeted, especially Aleks Buterman (@aleksb6) and @rsevero.
A collection of Tweets from and/or about the Open Group conference in Boston. A few references to Day 1 – particularly the ‘unconference’ – but mainly about Day 2, where the Jeanne Ross keynote was obviously the highlight.
I’ve split this into sections, mainly around the current speaker. I’ve also added occasional comments of my own at the end of some tweets, shown in italics.
Many thanks especially to Dana Gardner (@Dana_Gardner), Brenda Michelson (@bmichelson), Aleks Buterman (@aleksb6), Lisa Melsted (@lmelsted) and @rsevero (apologies, I don’t know the proper name), who provided the bulk of the Tweets here.
Here’s the slidedeck for “Enterprise-architecture on purpose”, my presentation to the Open Group conference in Rome, April 2010. It’s a slight departure from my usual slidedecks in that there’s no embedded script in the ‘Notes’ view; instead, I’ve used more slides in a more visual way and tried to make it more self-explanatory.
As one wag put it on Twitter, “Better than EA by accident”, but actually the “on purpose” bit in the title was more about the importance of purpose and vision in resolving executive-level problems in a whole-of-enterprise architecture. It includes two brief real-world examples (mildly modified for confidentiality-reasons): a social-services data-quality problem, and a bank’s problem of lost trust and respect.
See my other presentations on Slideshare for other aspects of whole-of-enterprise architecture practice.
This is a fairly full collection of tweets over the past few days from the Open Group enterprise-architecture conference over the past few days – more detail on the conference-programme here. It lists most items posted under the #ogrome hashtag: I’ve left out a few RTs (re-tweets) and administrative items, but otherwise it’s pretty much all there.
There’s also a lot of it – at least a couple of hundred tweets – so it’s best to put in a ‘Read more…’ link at this point:
Just received from Open Group the usual stream of invites to the next TOGAF enterprise-architecture conference, this time in Rome, in late April.
Perhaps it’s just spring or something (which it isn’t here, of course – ‘here’ being cold, damp, grey England), but there’s a real sense of change in the TOGAF air. This time, amazingly, there’s barely a Cloud in the sky: instead, at last, almost all of it is enterprise-architecture. Real enterprise-architecture.
As Enterprise Architecture matures there are many challenges which face the fledgling profession, but perhaps the most troublesome is how to find a way to communicate effectively with the business.
EA is fast becoming a business activity and is leaving behind the safe haven of IT. Language and communication now stand front and center as the current and most critical element of EA but how do we go about overcoming what, for many enterprise architects, is arguably our greatest challenge?
This event provides an ideal opportunity for EA professionals to better understand the overriding need to more closely align the practice of EA with the requirements of business decision-making at ‘board room’ level. It will better prepare all EA professionals to make real and significant contributions to the development of business strategy.
“Communicate with the business”, we might note – not “to the business”, which has been the arrogant attitude of IT for so many years. And being explicit that we need to be “leaving behind the safe haven of IT” is a very important step indeed.
But wait: it gets better:
Evolving EA from IT to Business
Plenary theme (Monday)We all know that EA is evolving and that gives enterprise architects a problem, because it implies that we have to evolve too.
We also know that we need to get closer to business, to make IT-business alignment a thing of the past. It simply isn’t enough for there to be IT-business alignment, there should only be business with IT being as much a part of the business as finance, sales, marketing or operations.
At this conference we will seek to open up the discussions that we, as enterprise architects need to develop to move forward and embrace the future of EA. Attendees can learn about our key challenges in this field, the different approaches to success and can be guided by those who have overcome the challenge of successfully crossing the divide.
And as a key enabler of this change in focus, EA Professionals need to change the language of EA, from “techie speak” to a much more business-oriented language that relates directly to the organization’s key business functions. The conference will explore a future in which enterprise architects engage in meaningful conversation in the Board Room as a matter of course, and in which the enterprise architecture itself constitutes a key enabler of corporate decision-making.
In other words, that crucial shift from ’strategic planning’ to ‘strategic conversation‘. At last.
But wait: it gets better still, in business-architecture terms at least:
Extending EA to the Enterprise
Plenary theme (Tuesday)The Business Architecture is a key component of any Enterprise Architecture, proving the direct linkage between other, IT-related components of the EA and the key strategic drivers and imperatives of the business. It is the key enabler by which Enterprise Architecture can truly extend its reach to the heart of the enterprise.
Those working in the field of Business Architecture are uniquely positioned to establish tomorrow’s best practices. In this session thought-leaders and leading practitioners in Business Architecture will present the critical success factors for today’s Business Architect.
TOGAF is an industry consensus framework and method for enterprise architecture that is used by organizations around the world. TOGAF is a live framework, continually evolving to accommodate best practices. At this conference we will show how TOGAF can be used today to present Business Architecture in a meaningful way to the business.
In other words, for the first time, business-architecture is described by Open Group as a distinct discipline in its own right, separate from but interrelated with IT-architecture. That’s a huge shift: in the TOGAF 9 specification, released barely a year ago, business-architecture was still in effect described as a jumbled-up grab-bag of “everything not-IT that might impact on IT”.
The only point I’m wary of here is that, in escaping from IT-centrism, this version of EA still risks falling straight into the next trap, that of business-centrism or organisation-centrism. No doubt business-folks might prefer us to do that, but in the long run it’s actually as dangerous as IT-centrism. It’s true that business-architecture should be centred round the needs of the business itself – but just like IT-architecture, that’s not enterprise-architecture either.
An organisation is bounded by agreed rules, or, in the case of a business, by legal obligations; but an enterprise is bounded by feelings and values – which is not the same at all. Without a grounded awareness of its extended-enterprise – the surrounding ecosystem within which it operates – business-architecture risks becoming self-centred, literally narcissistic, and guaranteed to fail in the longer term. An architecture that has a broader scope than the business itself becomes essential to guide the architecture of the business – and that’s what a true ‘architecture of the enterprise as enterprise’ will provide.
Even so, the description of this upcoming conference is very good news: a real sign that we’re at last getting closer to a true enterprise-architecture. At last. At last.
Better write up some of my notes and memories from the TOGAF Hong Kong conference before I forget them!
Like every TOGAF conference there were some of the same ‘usual suspects’ (including me, of course! 
) with their current version of the same developing themes for enterprise-architecture – such cloud-computing, security, TOGAF itself, and (in my case) expanding out beyond IT. But what made this conference special for me was the unique Chinese perspective on what has historically been a somewhat Anglo and technology-driven construct.
This difference in perspective was highlighted especially in presentations that came from three contrasting aspects of Chinese business: a large software-development and training house, a major university, and the Chinese arm of a large US-based multinational.
(Another long post, so continues after the ‘More’ link…)
A good Twitter exchange with John Polgreen (thanks John!) set me thinking yet again about the future of TOGAF (The Open Group Architecture Framework).
At present, TOGAF is just about the standard for the enterprise-architecture (EA) field, and the recent Version 9 release has further cemented that position. The catch is that the Open Group is an IT-standards body; and as EA at last starts to expand outward to a true ‘architecture of the enterprise’, that history is beginning to be a problem. Possibly a serious problem. Quite possibly serious enough, in fact, to kill the future usefulness of TOGAF for enterprise architecture. Not good… Hence, right now, TOGAF is facing a crossroads.
Up until the latest version, it prided itself on its detail: it provided detailed reference-models, a detailed methodology, and so on. In Version 8.1, the ‘Technology Architecture’ section provided 50 distinct steps to assess the architecture of an IT infrastructure. It was all too evident, though, that everything was grounded in that low-level technology: business, applications and data were all glossed over (8-9 steps each, compared to ‘Technology Architecture’s 50 steps), because they were relevant only inasmuch as they impacted on the technology infrastructure. Which was fair enough, given the Open Group’s history as a standards-body for IT.
But although many, if not most, people with an ‘enterprise architect’ job-title still believe that enterprise-architecture is an IT-specific discipline, there’s an increasingly urgent need for something that really is ‘an architecture of the enterprise’, rather than solely of the enterprise IT. That shift in awareness has been growing fast over the past couple of years, as I’ve commented about recent EA conferences such as TOGAF London and EAC2009. So there are two fundamentally different perspectives about EA:
TOGAF Version 9 tried to reconcile those two views, by bringing its descriptions of its ‘four architectures’ (technology, data, applications and business) into better balance, and adding new tools such as its Capability-Based Planning section. The result, unfortunately, is a classic compromise: in trying to satisfy all needs, it ends up satisfying none. It’s now doubled in size, to just under 800 pages – way too big to be usable – and even so it’s lost too much of the applicable detail, especially in ‘Technology Architecture’, which achieves a balance with the other ‘architectures’ by rounding down to the same eight steps. The same applies almost everywhere else: the sections on iterations, on security, on services, all present skimpy overviews that summarise the issues but fail to provide enough detail to be actionable, yet also give little or no indication as to how to derive that detail for any given context. In ISO-9000 terms, each section is stuck somewhere between an actionable work-instruction and an abstract procedure to derive work-instructions, satisfying neither need. And whilst TOGAF’s inherent IT-centrism still made some degree of sense in information-centric industries such as insurance, banking and finance, in other industries it constrains the ‘enterprise’ architecture in a dangerously blinkered way, often trying to enforce IT-based assumptions in areas where they make no sense at all. Hence, unsurprisingly, a lot of frustration…So it seems to me that TOGAF is now caught on a double-dilemma:
It can’t do all of these: that much is certain.
If it goes for the detail, it will need continual update: a new release every year as a minimum, and probably more frequent than that. Practical realities will mean that going for the detail will also force a narrowing of scope, probably right back down to low-level technology-infrastructure again.
If it goes for the abstract, the scope can be broader; but it will need detailed examples of how to derive actionable practices from the procedures, otherwise – as is close to the case already – the material will be unusable in practice.
If it stays with the IT-centric view, it’s a more comfortable fit with the Open Group’s history; but it risks being left behind – other than as a tool for a narrow niche market – as the EA industry, of necessity, moves outward to cover the true whole-of-enterprise scope. Trying to promote an IT-centric architecture as ‘enterprise architecture’ will guarantee that business-folk will reject it, worsening the already notorious ‘IT/business divide’; to resolve that, EA practitioners will be forced to use alternatives to TOGAF, leading to a wasteful ‘reinventing the wheel’ for the entire industry.
If it aligns with the industry trend, there’s a real risk that too many of the Open Group architecture-forum members could be forced too far out of their comfort-zone: as John Polgreen put it in one of his ‘tweets’, the Open Group members collectively tend to be very strong on IT-architecture issues, but “[perhaps] not enough good minds with real business architecture experience”. This in turn risks causing a split in TOGAF, or even within the Open Group itself – neither of which would be a good outcome.
What it can’t do is all of these. TOGAF is at the crossroads: it has to find an appropriate balance in this double-dilemma.
The ‘obvious’ solution is for TOGAF to retreat back to its roots: concentrate on IT only, and attempt to clean up and control the detail. At first glance, that would seem to be the best fit with the Open Group’s legacy and charter, and it would fit well with the fact that most of the big players in this not-so-open group are focussed on selling IT systems, software and services. And it would work, for a while, but in reality it would be the start of a spiral into angry irrelevance as the industry itself moves on – something I’ve seen happen several times with overly IT-centric ‘enterprise architecture’ teams out in real-world EA practice.
A far better solution would be to apply lessons-learned from other frameworks such as ISO-9000 and ITIL.
The early versions of the ISO-9000 quality-systems standard were a disaster-area: at best useless, at worst a bureaucratic nightmare, drowning in the detail of a pointless paper-trail. But someone, somewhere made the essential observation that, unlike IT-boxes, people don’t follow the rules, because the real world doesn’t follow the rules either: to make things work, people must adapt ‘the rules’ to the specific details of the specific context. So in ISO-9000:2000, everything changed: instead of an obsessive emphasis on compliance to predefined work-instructions, there was an explicit layering from work-instruction (live practice) to procedure (how to define new work-instructions) to policy (how to define new procedures) to vision (to guide new policies). The predefined work-instructions thus became worked examples of how to use procedures to define contextual ‘work-instructions’ for live practice; and so on up the audit-trail all the way back to vision, which (in principle, at least), would always remain the same. The standard itself doesn’t properly explain how this works in practice; but the guidance-notes do explain it, and so do all the better training-courses. Applied wrongly, as a means of ‘control’, ISO-9000 still creates a pointless paper-trail; but applied right, as a context-aware framework, it enhances every aspect of quality-management throughout the enterprise.
So to ITIL (IT Infrastructure Library), the IT service-management standard. Up until Version 2, ITIL was much like TOGAF today: literally with IT on one side, business on the other, and IT service-management uncomfortably straddling the gaping void between the two. But in Version 3, everything changes: instead of being focussed almost exclusively on IT issues – again, much like TOGAF today – the standard presents a generic service-management model, using IT as its worked-example of how that generic model is used in practice. Anecdotal evidence suggests that for many IT service-management folks there isn’t enough detail in that worked-example: too much was lost from the previous version, they say – much like the detail lost from ‘Phase D: Technology Architecture’ between TOGAF’s Versions 8 and 9. But again, the guidance-notes do explain it, and so do all the better training-courses. Applied right, as a context-aware framework, ITIL can be used for any service-management need.
If we look at how TOGAF needs to develop, several themes become clear:
We can resolve all of these as follows:
The real core of TOGAF is the ADM (Architecture Development Method); and as I’ve explained elsewhere – such as in my books Bridging the Silos and Doing Enterprise Architecture – the amendments needed to make the ADM usable for any architecture scope are almost trivial, and still remain compatible with existing TOGAF architecture and practice. It’s all doable, and we could do it today if need be: all that’s needed now is the courage to change, and the will to do so.
I won’t be able to go to the next TOGAF conference, in Toronto next month, but I hope others will be able to champion these suggestions there. Because if we don’t, we risk losing TOGAF itself over the next few years – which would not be a good outcome for the EA industry…
Let’s be blunt about this: TOGAF Version 9 was a lost opportunity, the wrong kind of compromise, and we dare not let that happen again. TOGAF at the crossroads: it’s up to us to make it work.