#entarch Following my blogpost on EA and the Big Picture, @carlhaggerty asked does it matter if EA disappears into a core C-Suite competency?
Clearly it matters to some people, especially those who have committed themselves and their careers to the idea of enterprise architecture (EA) as an independent practice. If EA were to disappear, some people would be upset, and some organizations would need to find a new mission or fold.
@carlhaggerty agreed that some people might be upset but thought if it is in the best interests of the enterprise surely it would be the best thing to do.
Well perhaps. I am certainly not a defender of the current position of EA as a defacto knowledge silo, because this offends against the principles of EA itself. (See my post on A Value Proposition for Enterprise Architecture.)
But I have two problems with making a judgement about "the best thing to do" purely on the basis of "the best interests of the enterprise". The first problem is who shall speak for the best interests of the enterprise. C-level executives are often driven by extremely short-term considerations, such as stock market prices, as well as their own personal advantage. Merging enterprise architecture into C-level management might mean that EA would be forced to adopt this perspective to the exclusion of any other perspective. The second problem is that there have always been enterprises that are based on a corrupt business model - flawed or unethical - and there is clear conflict between the best interest of these enterprises and the best interests of society as a whole.
Ultimately, this comes down to the possibility of designing a complex organization to produce behaviour that is effective, intelligent and ethical. @carlhaggerty would rather see EA being done whether or not an EA exists in an enterprise, and he personally doesn't care who ;) I agree with him up to a point - I don't care who does EA, but I do want to see an organizational design giving a strong independent voice to an EA-like perspective.
Friday, December 31, 2010
Wednesday, December 29, 2010
Special Powers of the Architect - Getting The Big Picture
Does the Enterprise Architect have special powers?
Some people think that what uniquely characterizes enterprise architects is that they are the ones who
If this is true, it is because EAs have differently wired brains to the rest of humanity, or because their position and practices give them a different perspective on the enterprise? For a summary of a Twitter debate on this topic, see my blogpost Getting the Big Picture.
The next question is what this implies for the relationship between EAs and the rest of the enterprise. If EAs have these special powers of perception, do other people find this threatening? And how much of the Big Picture can be communicated? For a summary of a Twitter debate on this topic, see my blogpost Selling the Big Picture.
When I raised this question on the Enterprise Architecture Network group on Linked-In, Graham Berrisford thought this was a bit tautologous.
But it is only a tautology if that's how you define enterprise architecture and if you only recognize one kind of
To the extent that enterprise architects have a single set of lenses for viewing the enterprise (e.g. Zachman), their claim to have THE big picture is disputable. (Hence my interest in lenscraft - the use of multiple lenses providing alternative perspectives.)
Tuomo Stauffer suggested that the big picture comes from the board. In which case EA's job is not to
But my question wasn't just whether the association between enterprise architecture and big-picturehood was true, but also what this association would imply (a) for the recruitment and development of EA skills and (b) for the (possibly threatening) relationship between EAs and the rest of the management world.
See also
Some people think that what uniquely characterizes enterprise architects is that they are the ones who
get the big picture.
If this is true, it is because EAs have differently wired brains to the rest of humanity, or because their position and practices give them a different perspective on the enterprise? For a summary of a Twitter debate on this topic, see my blogpost Getting the Big Picture.
The next question is what this implies for the relationship between EAs and the rest of the enterprise. If EAs have these special powers of perception, do other people find this threatening? And how much of the Big Picture can be communicated? For a summary of a Twitter debate on this topic, see my blogpost Selling the Big Picture.
When I raised this question on the Enterprise Architecture Network group on Linked-In, Graham Berrisford thought this was a bit tautologous.
Enterprise Architecture is the big picture, therefore Enterprise Architects are the ones who have the big picture.
But it is only a tautology if that's how you define enterprise architecture and if you only recognize one kind of
big picture. Stock market analysts and venture capitalists might have an entirely different
big picture.
To the extent that enterprise architects have a single set of lenses for viewing the enterprise (e.g. Zachman), their claim to have THE big picture is disputable. (Hence my interest in lenscraft - the use of multiple lenses providing alternative perspectives.)
Tuomo Stauffer suggested that the big picture comes from the board. In which case EA's job is not to
getthe big picture but to codify it.
But my question wasn't just whether the association between enterprise architecture and big-picturehood was true, but also what this association would imply (a) for the recruitment and development of EA skills and (b) for the (possibly threatening) relationship between EAs and the rest of the management world.
See also
Thursday, December 23, 2010
Methodological Syncretism
Discussion originally posted to Enterprises-As-Systems group on Linked-In. http://www.linkedin.com/groups?gid=1327957
There are two versions of this post. The first version was originally posted to Amplify in December 2010. Amplify has disappeared, and I have only just managed to find an archived copy. Note that all URLs in this section refer to the archived pages.
Back in November 2008, Dave McCoy defined methodological syncretism as “The process by which two or more methodologies are blended to create an über-methodology that uses the best of each donor methodology.” Dave's particular interest is in BPM, so he added "... toward a more effective delivery of process excellence". Methodological Syncretism, BPM, and Whale Pie
I thought the term “methodological syncretism” was a good one to apply to the way systems thinking is being practised by many consultants – combining bits of Checkland and Zachman and Maturana and Stafford Beer and whoever, so I started a discussion in the Enterprises-As-Systems group.
Matthew K Hettinger replied
I thought this was highly problematic.
Sally Bean (@Cybersal) pointed out that Checkland's original diagram of his process contained a blob labelled 'Other Systems Thinking' which feeds into the Conceptual Model-building process (step 4). Thus despite the fact that Beer and Checkland had very different epistemologies, she did successfully apply a blend of these approaches to her Open University course project, and continues to mix and match techniques and methodologies in practice.
Tom Graves (@tetradian) challenged me for some details and examples.
I admitted I didn't have any easy answers either.
Tom continued to challenge me.
I tried to avoid the challenge as follows.
There are two versions of this post. The first version was originally posted to Amplify in December 2010. Amplify has disappeared, and I have only just managed to find an archived copy. Note that all URLs in this section refer to the archived pages.
Back in November 2008, Dave McCoy defined methodological syncretism as “The process by which two or more methodologies are blended to create an über-methodology that uses the best of each donor methodology.” Dave's particular interest is in BPM, so he added "... toward a more effective delivery of process excellence". Methodological Syncretism, BPM, and Whale Pie
I thought the term “methodological syncretism” was a good one to apply to the way systems thinking is being practised by many consultants – combining bits of Checkland and Zachman and Maturana and Stafford Beer and whoever, so I started a discussion in the Enterprises-As-Systems group.
There are many methods and frameworks and approaches in this space. Some that have already been mentioned in this group include Soft Systems Methodology (Checkland), Enterprise Architecture (Zachman) and Viable Systems Model (Stafford Beer). There are many others I could add to the list, including things like System Dynamics (Forrester, Meadows), Autopoiesis (Maturana & Varela, Luhmann), Cynefin (Dave Snowden), ...
I think all of these have something to offer, but I also have some reservations about most of them. My question is this. Does it work to pick and choose stuff from these disparate methods? Can we each produce our own customized approach to thinking about enterprises-as-systems? Does this make sense? Is there an alternative?
Matthew K Hettinger replied
All of these approaches in some way, either implicitly or explicitly, make use of the fundamental principles, concepts and theories of the systems family of disciplines (some of which I have mentioned in the description of this group). One approach to "unifying" these approaches is to take each approach as it is and somehow combine them. Another approach is to go back to the system family of disciplines and "unify" them into a single coherent knowledge domain grounded in a systemics ontology(-ies) and meta-model(s). Then map these approaches onto the result of the "unified" discipline. ...
Please note that "unified" is in quotes signifying that I do not mean a grand unified model, but a set of models that have associated mappings and metamodels - consistent with Boulding (General Systems Theory).
I thought this was highly problematic.
I'm not convinced that all of these methods agree on what "the fundamental principles, concepts and theories of the systems family of disciplines" actually are. For example, what Checkland means by "soft" is absent from a lot of other methods, and Checkland can therefore be read as a critique of what he would call "hard" methods. Meanwhile, there are some ideas in Maturana that can be used to critique Checkland, and so on. So I shall be interested to see your underlying model.
Sally Bean (@Cybersal) pointed out that Checkland's original diagram of his process contained a blob labelled 'Other Systems Thinking' which feeds into the Conceptual Model-building process (step 4). Thus despite the fact that Beer and Checkland had very different epistemologies, she did successfully apply a blend of these approaches to her Open University course project, and continues to mix and match techniques and methodologies in practice.
Tom Graves (@tetradian) challenged me for some details and examples.
Given your critiques of so many different theorists, I'm left wondering how you yourself resolve this issue of 'methodological syncretism' in your own personal business practice?
What tools and methods do you yourself use in practice? What practical applications do you have for systems-theory tools and frameworks in your business consultancy, and in what business contexts, with what success (or otherwise, as, for example, David Hudnut described on another thread)?
I admitted I didn't have any easy answers either.
Perhaps what is common to all these system thinkers - yes, even Zachman - is that they are each saying something like "a system is not just this, you need to pay attention to that". I don't see any problem in principle in composing the first (negative) parts - "the system isn't just this, and it isn't just that either". So one possibility for a systems practice drawing on many different systems thinkers is to assemble a diverse collection of questions and pay attention to a rich collection of stuff.
In my view, the problem comes when you try to combine the different (positive) accounts of what a system actually is. Many of these systems thinker have proposed some kind of framework, but trying to use more than one framework at the same time strikes me as trying to build something using some combination of K-Nex and Lego and Meccano - not necessarily impossible but inelegant and probably unstable.
For example, one system principle I use a lot is Stafford Beer's #POSIWID principle - "the purpose of a system is what it does". I have a light-hearted blog based on this principle and probably enough material for a book. http://posiwid.blogspot.com/ As you will see if you look at the range of examples on the blog, the POSIWID principle is a good heuristic for finding alternative ways of understanding what is going on as well as seeing why certain classes of intervention are likely to fail. However, the moment you start to think of POSIWID as providing some kind of Truth about systems, you are on a slippery slope to producing conspiracy theories and all sorts of other rubbish.
Tom continued to challenge me.
Richard - yes, agreed - but what _practical_ applications for this do you have in the _enterprise_ context? How do _you personally_ resolve the 'methodological syncretism' in your business practice? For example, do you use a particular base-model (such as Stafford Beer's work, perhaps) and then use differtent tools as appropriate that base? Or do you literally apply POSIWID and use whatever comes to mind, without any kind of consistent or systematic frame?
I ask because that issue is certainly something I've been struggling with in my own practice. (And emphasis again on _practice_ rather than only on the theory - the theory is relatively easy, frankly.)
I tried to avoid the challenge as follows.
Why would I want to resolve the contradictions between the various frameworks? Only if I wanted to go into a client situation with a reasonable coherent composite framework under my arm. But I don't want to.
Christopher Alexander (who has inspired several generations of IT methodologists from Yourdon and deMarco onwards) once wrote: "If you call it ‘It’s a Good Idea to Do’, I like it very much; if you call it a ‘Method’, I like it but I’m beginning to get turned off; if you call it a ‘Methodology’, I just don’t want to talk about it."
Experts on presentation such as Garr Reynolds talk about Naked Presentation. This means you don't hide behind a set of tedious bullet-pointed slides, but you engage authentically with your audience.
http://presentationzen.blogs.com/presentationzen/2005/10/make_your_next_.html
So my ideal for working with organizations would be something like Naked Systems Thinking. In other words, not hiding behind some framework, but engaging directly and openly with the situation. From Jerry Weinberg's writings (@jerryweinberg), I get the impression that he is pretty good at this. I may not always get it right, but that's what I'm always striving to achieve.
So to me the various frameworks are a valuable source of understanding and awareness rather than something I actually want to use.
Afterwards, I can try to make sense of what has happened, but these situations are always complex and I don't find it easy to extract simple stories for publication. Maybe that's yet another skill I need to develop.
Here is a second version, which I produced when the Amplify version was not available to me.
There are many methods and frameworks and approaches in this space. Some that have already been mentioned in this group include Soft Systems Methodology (Checkland), Enterprise Architecture (Zachman) and Viable Systems Model (Stafford Beer). There are many others I could add to the list, including things like System Dynamics (Forrester, Meadows), Autopoiesis (Maturana and Varela, Luhmann), Cynefin (Dave Snowden), ...
I think all of these have something to offer, but I also have some reservations about most of them. My question is this. Does it work to pick and choose stuff from these disparate methods? Can we each produce our own customized approach to thinking about enterprises-as-systems? Does this make sense? Is there an alternative?
(In response to the suggestion that these methods can be "unified", and a claim that a unified model exists.)
I'm not convinced that all of these methods agree on what "the fundamental principles, concepts and theories of the systems family of disciplines" actually are. For example, what Checkland means by "soft" is absent from a lot of other methods, and Checkland can therefore be read as a critique of what he would call "hard" methods. Meanwhile, there are some ideas in Maturana that can be used to critique Checkland, and so on. So I shall be interested to see your underlying model.
(When asked how I resolve the question of syncretism in my own practice, and how I resolve the contradictions.)
I don't have any easy answers either.
Perhaps what is common to all these system thinkers - yes, even Zachman - is that they are each saying something like "a system is not just this, you need to pay attention to that". I don't see any problem in principle in composing the first (negative) parts - "the system isn't just this, and it isn't just that either". So one possibility for a systems practice drawing on many different systems thinkers is to assemble a diverse collection of questions and pay attention to a rich collection of stuff.
In my view, the problem comes when you try to combine the different (positive) accounts of what a system actually is. Many of these systems thinkers have proposed some kind of framework, but trying to use more than one framework at the same time strikes me as trying to build something using some combination of K-Nex and Lego and Meccano - not necessarily impossible but inelegant and probably unstable.
For example, one system principle I use a lot is Stafford Beer's POSIWID principle - "the purpose of a system is what it does". I have a light-hearted blog based on this principle (http://posiwid.blogspot.com/) and probably enough material for a book. As you will see if you look at the range of examples on the blog, the POSIWID principle is a good heuristic for finding alternative ways of understanding what is going on as well as seeing why certain classes of intervention are likely to fail. However, the moment you start to think of POSIWID as providing some kind of Truth about systems, you are on a slippery slope to producing conspiracy theories and all sorts of other rubbish.
In any case, why would I want to resolve the contradictions between the various frameworks? Only if I wanted to go into a client situation with a reasonable coherent composite framework under my arm. But I don't want to.
Christopher Alexander (who has inspired several generations of IT methodologists from Yourdon and deMarco onwards) once wrote: "If you call it ‘It’s a Good Idea to Do’, I like it very much; if you call it a ‘Method’, I like it but I’m beginning to get turned off; if you call it a ‘Methodology’, I just don’t want to talk about it."
Experts on presentation such as Garr Reynolds talk about Naked Presentation. This means you don't hide behind a set of tedious bullet-pointed slides, but you engage authentically with your audience.
So my ideal for working with organizations would be something like Naked Systems Thinking. In other words, not hiding behind some framework, but engaging directly and openly with the situation. From Jerry Weinberg's writings, I get the impression that he is pretty good at this. I may not always get it right, but that's what I'm always striving to achieve.
So to me the various frameworks are a valuable source of understanding and awareness rather than something I actually want to use. Afterwards, I can try to make sense of what has happened, but these situations are always complex and it isn't always easy to extract simple stories for publication. Maybe that's yet another skill I need to develop.
Wikipedia: Syncretism
Thursday, December 16, 2010
Complexity and Power 2
#entarch #orgintelligence In an earlier post, I pointed out the architectural trade-off between Complexity and Power. There may be a choice between a simple-but-inefficient solution and a more sophisticated solution, and this choice has important structural implications. The architectural design of a large enterprise involves any number of these choices.
Furthermore, a given organization has a finite capacity for managing sophistication and complexity, and a limited willingness to invest in the management costs and overheads that may be required to extract the full benefit from more powerful systems.
There are two agendas that each appear to address opposite sides of this situation. The first is the simplification agenda, advocated most persuasively by my friend Roger Sessions, which addresses the problem that most organizations and their support systems (including IT) are riddled with unnecessary complexity.
The second is the maturity agenda, which suggests that an organization can extract more benefit from certain systems and practices and technologies by becoming more sophisticated. Maturity models are typically arranged as a series of maturity levels, and should be derived (although I suspect many of them aren't) from a robust theory of organizational change and technology adoption.
There are some subtle and usually ignored issues in the interaction between these two agendas, but I don't want to go into these issues here. Instead, I want to point to a couple of critical questions
The first question looks like a simple engineering question, which should be bread-and-butter for requirements engineers. The need for complexity and power is driven by some set of demands, together with an economic argument that links cost to value (possibly but not necessarily expressed in financial terms).
The second question is clearly an architectural question. Two things are intuitively obvious about the design of complex machines: not every component needs the same amount of power and complexity; however, some components need proportionality of power and complexity. (It doesn't make sense to put a massive engine in a tiny car, and a fast car needs more powerful brakes than a slow car.)
Power and complexity are higher-order examples of so-called non-functional requirements. Architects need to be able to reason about the composition and decomposition of non-functional requirements.
The enterprise is a sociotechnical system, so I'm not just talking about technical components here. A racing car needs a driver whose reaction speeds are matched to the speed of the car, and a maintenance team capable of rapidly diagnosing and fixing all the minor technical problems that could occur during the race.
Similarly, an enterprise needs a set of management capabilities whose intelligence is matched (proportional) to the power and complexity of the operations and operational systems - thus we have an architectural view of the enterprise as an intelligent sociotechnical system, with an appropriate balance of power and complexity.
I don't want to hear that the complexity has been completely removed from the technical systems, because I then fear that the necessary complexity has been merely displaced onto the people inside the organization - or worse, onto the customers.
Conversely, I don't want to hear that the complexity has been completely embedded inside the technical systems, because I then don't trust the people inside the organization to fully manage this complexity.
What I want to hear is that there is just enough complexity and power in the technical systems AND at least enough intelligence in the human systems to manage this complexity and power properly. And I expect the enterprise architect to be responsible for maintaining this proper balance.
Furthermore, a given organization has a finite capacity for managing sophistication and complexity, and a limited willingness to invest in the management costs and overheads that may be required to extract the full benefit from more powerful systems.
There are two agendas that each appear to address opposite sides of this situation. The first is the simplification agenda, advocated most persuasively by my friend Roger Sessions, which addresses the problem that most organizations and their support systems (including IT) are riddled with unnecessary complexity.
The second is the maturity agenda, which suggests that an organization can extract more benefit from certain systems and practices and technologies by becoming more sophisticated. Maturity models are typically arranged as a series of maturity levels, and should be derived (although I suspect many of them aren't) from a robust theory of organizational change and technology adoption.
There are some subtle and usually ignored issues in the interaction between these two agendas, but I don't want to go into these issues here. Instead, I want to point to a couple of critical questions
- how much complexity and power does a given enterprise need (requisite variety)
- how should this complexity and power be distributed and connected
The first question looks like a simple engineering question, which should be bread-and-butter for requirements engineers. The need for complexity and power is driven by some set of demands, together with an economic argument that links cost to value (possibly but not necessarily expressed in financial terms).
The second question is clearly an architectural question. Two things are intuitively obvious about the design of complex machines: not every component needs the same amount of power and complexity; however, some components need proportionality of power and complexity. (It doesn't make sense to put a massive engine in a tiny car, and a fast car needs more powerful brakes than a slow car.)
Power and complexity are higher-order examples of so-called non-functional requirements. Architects need to be able to reason about the composition and decomposition of non-functional requirements.
- Let P be some property of systems and components - say performance or quickness or reliability or security or throughput or whatever. If the components of a system have properties P(1) ... (Pn), what can we say about the composite property P of the whole system?
- Conversely, if we have a requirement for the whole system to have property P, what can we say about the properties P(1) ... (Pn) of each component?
The enterprise is a sociotechnical system, so I'm not just talking about technical components here. A racing car needs a driver whose reaction speeds are matched to the speed of the car, and a maintenance team capable of rapidly diagnosing and fixing all the minor technical problems that could occur during the race.
Similarly, an enterprise needs a set of management capabilities whose intelligence is matched (proportional) to the power and complexity of the operations and operational systems - thus we have an architectural view of the enterprise as an intelligent sociotechnical system, with an appropriate balance of power and complexity.
I don't want to hear that the complexity has been completely removed from the technical systems, because I then fear that the necessary complexity has been merely displaced onto the people inside the organization - or worse, onto the customers.
Conversely, I don't want to hear that the complexity has been completely embedded inside the technical systems, because I then don't trust the people inside the organization to fully manage this complexity.
What I want to hear is that there is just enough complexity and power in the technical systems AND at least enough intelligence in the human systems to manage this complexity and power properly. And I expect the enterprise architect to be responsible for maintaining this proper balance.
Wednesday, December 15, 2010
An Architectural History of Social Networking
@ruskin147 is in California to meet the networking pioneers, including Stewart Brand.
In 1985, Stewart Brand was one of the founders of an online community called the Well. As Rory reports, the Well provided "inspiring stories of the power of online communication, as its members used its forums to share their lives, their thoughts, and their passions - whether it be for obscure technology questions or discussions about the meaning of life".
In 1994, Brand wrote a brilliant and controversial book about architecture, How Buildings Change, which among other things contained a theory about evolutionary change in complex systems based on earlier work by the architect Frank Duffy and the ecologist Robert O'Neill. The theory was then known as Shearing Layers; Brand now prefers to call it Pace Layering. If there is a difference between the two, Shearing Layers is primarily a descriptive theory about how change happens in complex systems, while Pace Layering is primarily an architectural principle for the design of resilient systems of systems.
In the original Shearing Layers theory, the slowest-moving layer is known as Site. In the context of physical buildings, this is the geographical setting, the urban location, and the legally defined lot, whose boundaries and context outlast generations of ephemeral buildings [via Wikipedia].
An interesting question for Brand then is whether social networking continues to occupy the same "Site" as early initiatives such as the Well. In other words, the boundaries and context outlasting generations of ephemeral technology.
Brand told Rory that he saw some of the same principles in Facebook that had governed The Well: "I'm really impressed at a lot of the instincts that Zuckerberg has had. Taking non-anonymity as an absolutely fundamental value of his company and thereby beating off the competition. A Facebook identity is one of the most valuable things his company offers. The lack of anonymity is what gives it value." [Friendster, Facebook and the Well]
But that's not quite the same as asserting a historical path from the Well to the present day. The critical question here is not how aware Zuckerberg and his associates were with the history of social networking, but to what extent this history directly or indirectly influenced their actions and choices. For example, our collective understanding of "anonymity" is coloured by the past couple of decades of internet and pre-internet activity. Zadie Smith (a near contemporary of Zuckerberg at Harvard) talks about Zuckerberg's idea about what a person is, or should be, and worries that her own idea of personhood is nostalgic, irrational, inaccurate [New York Review, 25 Nov 2010]. And of course ironic.
Where exactly did Zuckerberg's idea of personhood come from? There may be a sense in which echoes of the Well may persist in Facebook through the way such concepts are understood and managed. And although we wouldn't necessarily take Brand's opinion of this at face value (or for that matter Zuckerberg's) there can be few people whose opinion would be so interesting and well-informed.
See also
Roger Hudson, The Evolving Web - A Pace Layering view of the development of the Web and the W3C (March 2008)
Howard Silverman, Panarchy and Pace in the Big Back Loop (originally published on People and Place, March 2009, republished on Solving for Pattern, Oct 2012)
Matt Webb et al, Twitter thread discussing the provenance of the Shearing Layers concept (April 2021)
I have written several other posts on this blog discussing various aspects and applications of pacelayering.
Links updated 11 January 2018, 23 April 2021. Inserted reference to O'Neill.
Tuesday, December 14, 2010
Conceptual Architecture
Interesting article today about Andrew Zambelli, former aide to Mario Cuomo and now appointed aide to his son Andrew Cuomo, describing him as a "conceptual architect" [Capital New York, 14 December 2010]. He will be responsible for the oversight and strategic integration of the communications, inter-governmental, legislative and constituency efforts of the Office of the Governor.
Zambelli has been working for a consultancy (Strategic Frameworking) that describes itself as a Corps of Conceptual Architects and defines conceptual architecture as follows.
But perhaps the most interesting insight into Zambelli's role as aide to Cuomo senior comes from a Time article reporting Governor Cuomo's decision not to run for President in 1992. Cuomo's political advisers were "sticklers for order and slaves to planning" and wanted to know his decision ahead of time, but he refused to decide until the last possible moment. [Michael Kramer, Politics At Last: A No-Go From Mario (Time, 30 Dec 1991)] Even the uncharacteristic extravagence of an unnecessarily chartered plane to New Hampshire wasn't enough to persuade the Governor to show his hand. As top assistant, Zambelli was therefore required to prepare for something that in the end never happened. But I guess that's what conceptual architects often have to do.
Zambelli has been working for a consultancy (Strategic Frameworking) that describes itself as a Corps of Conceptual Architects and defines conceptual architecture as follows.
We create strategic frameworks for business development based on significant insight regarding the evolving needs of consumers and customers. ... Heavily steeped in psychological exploration to uncover the true essence of “brand,” SFI’s proprietary approach to brand building — what we call “conceptual architecture” — has produced some of the most touted and far-reaching brand strategies over the past quarter century for clients such as PepsiCo, Anheuser-Busch, Tricon (Taco Bell, KFC, Pizza Hut), Hershey, Microsoft, Colgate-Palmolive and Kraft Foods.
But perhaps the most interesting insight into Zambelli's role as aide to Cuomo senior comes from a Time article reporting Governor Cuomo's decision not to run for President in 1992. Cuomo's political advisers were "sticklers for order and slaves to planning" and wanted to know his decision ahead of time, but he refused to decide until the last possible moment. [Michael Kramer, Politics At Last: A No-Go From Mario (Time, 30 Dec 1991)] Even the uncharacteristic extravagence of an unnecessarily chartered plane to New Hampshire wasn't enough to persuade the Governor to show his hand. As top assistant, Zambelli was therefore required to prepare for something that in the end never happened. But I guess that's what conceptual architects often have to do.
Monday, December 13, 2010
Can Single Source of Truth work?
@tonyrcollins asks if any healthcare IT system can provide a Single Source of Truth (SSOT)? In his blog (13 December 2010), he discusses a press release claiming that an electronic healthcare record system from Cerner Millennium Solutions is a "single source of truth", citing the Children’s Cancer Hospital Egypt 57357 (CCHE) as a success story (via Egyptian Chamber).
My first observation is that even if we take this success story at face value, it doesn't tell us much about the possibilities of SSOT in an environment such as the UK NHS that is several orders of magnitude more complicated/complex. I'm guessing the Children’s Cancer Hospital Egypt 57357 (CCHE) doesn't have as many different types of "truth" to manage as the NHS.
My third observation is that single-source of truth may be a bureaucratic fantasy, but responsible doctors will always strive to get best-truth rather than sole-truth. People in bureaucratic organizations don't always stick to the formal channels, and often have alternative ways of finding out what they need to know. So perhaps the Egyptian doctors at CCHE have managed to preserve alternative sources of information, and the "single source of truth" is merely a bureaucratic illusion.
See my previous post What's Wrong with the Single Source of Truth?
My first observation is that even if we take this success story at face value, it doesn't tell us much about the possibilities of SSOT in an environment such as the UK NHS that is several orders of magnitude more complicated/complex. I'm guessing the Children’s Cancer Hospital Egypt 57357 (CCHE) doesn't have as many different types of "truth" to manage as the NHS.
- one type of patient (children)
- one type of condition (cancer)
- a single building
My third observation is that single-source of truth may be a bureaucratic fantasy, but responsible doctors will always strive to get best-truth rather than sole-truth. People in bureaucratic organizations don't always stick to the formal channels, and often have alternative ways of finding out what they need to know. So perhaps the Egyptian doctors at CCHE have managed to preserve alternative sources of information, and the "single source of truth" is merely a bureaucratic illusion.
See my previous post What's Wrong with the Single Source of Truth?
Friday, December 03, 2010
Embedding Intelligence into a Business Capability
In some recent posts, I have talked about embedding different forms of intelligence in a business process. Intelligence may make the process more powerful, or it may merely make it more internally efficient. But in the examples I've looked at so far, the essential purpose of the process remains the same.
In this post, I'm going to look at something more radical. Prompted by a blog on the Death of Market Research from Tamara Barber of Forrester, I'm going to show how a basic business capability such as market research can be transformed into something else by introducing new forms of intelligence.
Barber's basic premise appears to be that in a complex world, it isn't enough for market research merely to gather information to be fed into business strategy and tactics. Instead, market research needs to be fully engaged in the intelligence loops of business decision-making and innovation. The challenge is not collecting information - there is already more than enough raw data - the key value-adding activity is in interpretation and insight.
In terms of organizational intelligence, this means extending from information gathering into active participation in the intelligence loops - from sense-making and decision-making to experimentation and learning. Barber defines this new role as follows.
There have been many criticisms of intelligence organizations such as the CIA whenever they have apparently failed to "connect the dots", and there are probably some useful lessons here for civilian organizations as well. One of the common problems appears to be a bureaucratic separation between the information gathering, sense-making and policy-making activities, which may cause insight to be fragmented or lost. It is surely better to build business capability around the whole intelligence loop, rather than chop it into separate pieces and hope that it all somehow works.
Places are still available for my Organizational Intelligence Workshop on December 8th.
- Embedding Intelligence into the Business Process
- Embedding Intelligence into the Business Process 2
- Joined-up collaboration
In this post, I'm going to look at something more radical. Prompted by a blog on the Death of Market Research from Tamara Barber of Forrester, I'm going to show how a basic business capability such as market research can be transformed into something else by introducing new forms of intelligence.
Barber's basic premise appears to be that in a complex world, it isn't enough for market research merely to gather information to be fed into business strategy and tactics. Instead, market research needs to be fully engaged in the intelligence loops of business decision-making and innovation. The challenge is not collecting information - there is already more than enough raw data - the key value-adding activity is in interpretation and insight.
In terms of organizational intelligence, this means extending from information gathering into active participation in the intelligence loops - from sense-making and decision-making to experimentation and learning. Barber defines this new role as follows.
"This role will be responsible for collecting and analyzing both internal and external sources of data, analyzing it, and presenting a unified view of the truth on customer/consumer wants and needs, as well as the market conditions and health of the brand within that market. In order to do this, leaders of today’s market research departments will need to consider how they can organize their teams, scope their capabilities, and collaborate with internal teams (customer intelligence, anyone?) and external vendors in order to come to the table with relevant insights and recommendations — all based on business objectives."
There have been many criticisms of intelligence organizations such as the CIA whenever they have apparently failed to "connect the dots", and there are probably some useful lessons here for civilian organizations as well. One of the common problems appears to be a bureaucratic separation between the information gathering, sense-making and policy-making activities, which may cause insight to be fragmented or lost. It is surely better to build business capability around the whole intelligence loop, rather than chop it into separate pieces and hope that it all somehow works.
Places are still available for my Organizational Intelligence Workshop on December 8th.
Wednesday, December 01, 2010
Joined-Up Collaboration
@inmagic 's Phil Green suggests an Enterprise 2.0 Best Practice: Unite Internal Collaboration with External Communication (CMS Wire Nov 29, 2010)
As he points out, internal and external are often disconnected. Clearly, different tools are appropriate for different kinds of collaboration. As Phil acknowledges, "external collaboration ... has usually taken the form of activities such as blogging, tweeting, Facebooking, Flickring, YouTubing, etc. with customers and communities outside the firewall".
In advocating unification, Phil appeals to the following two facts.
Phil describes a scenario where he thinks there is a plausible case for some kind of collaboration spanning internal and external.
Frankly, I don't think this is a very good example. It looks to me like a highly conventional product development process, with a narrowly constrained chunk of customer consultation in the middle. I'm guessing that the customers are not given seamless access to all the internal product ideas and issues, merely to a top 50 list which is a separate knowledge artefact, possibly constructed solely for this purpose. In which case, the word "seamlessly" here merely refers to the fact that the top 50 list and the full list happen to reside in the same software tool. (A tool, by the way, which looks suspiciously like the one Phil's company sells.) A paper questionnaire might have been more trouble to administer, but it might have been just as effective in terms of customer feedback and customer relationships.
In order to create a more convincing example, one should start not from the desire to sell a particular software tool, but from the business desire to collaborate more intelligently and intensively with the customers all through the product development cycle. The product management process would probably need to be radically changed, and we might not even need a separate marketing campaign. We probably need to think about organizational unification (radically new kinds of collaboration) long before we bother with platform unification (Phil's Social Knowledge Network).
Places are still available for my Organizational Intelligence Workshop on December 8th.
As he points out, internal and external are often disconnected. Clearly, different tools are appropriate for different kinds of collaboration. As Phil acknowledges, "external collaboration ... has usually taken the form of activities such as blogging, tweeting, Facebooking, Flickring, YouTubing, etc. with customers and communities outside the firewall".
In advocating unification, Phil appeals to the following two facts.
- Both internal and external collaboration are based on relationships.
- Each kind of collaboration should contribute to the organization’s collective goals.
Phil describes a scenario where he thinks there is a plausible case for some kind of collaboration spanning internal and external.
- A business unit that is gearing up for a new product development cycle.
- A list of possible product enhancements is maintained in an internal E 2.0 tool.
- The organization uses the E 2.0 tool "to seamlessly expose the top 50 internal product ideas to customers and receive feedback and reactions".
- The product management team analyses the customer feedback and initiates further investigation into features identified as high customer priority, including internal search for relevant R&D as well as focused research on competitor products.
- Following this investigation, they set the product strategy and start building a marketing campaign.
Frankly, I don't think this is a very good example. It looks to me like a highly conventional product development process, with a narrowly constrained chunk of customer consultation in the middle. I'm guessing that the customers are not given seamless access to all the internal product ideas and issues, merely to a top 50 list which is a separate knowledge artefact, possibly constructed solely for this purpose. In which case, the word "seamlessly" here merely refers to the fact that the top 50 list and the full list happen to reside in the same software tool. (A tool, by the way, which looks suspiciously like the one Phil's company sells.) A paper questionnaire might have been more trouble to administer, but it might have been just as effective in terms of customer feedback and customer relationships.
In order to create a more convincing example, one should start not from the desire to sell a particular software tool, but from the business desire to collaborate more intelligently and intensively with the customers all through the product development cycle. The product management process would probably need to be radically changed, and we might not even need a separate marketing campaign. We probably need to think about organizational unification (radically new kinds of collaboration) long before we bother with platform unification (Phil's Social Knowledge Network).
Places are still available for my Organizational Intelligence Workshop on December 8th.
Subscribe to:
Posts (Atom)