The unique contribution of enterprise-architecture
What do enterprise-architects actually do? What unique contribution do they bring to the enterprise?
What triggered this was one paragraph in Len Fehskens’ item on current and future enterprise-architecture, in the Open Group blog ‘2013 Open Group Predictions, Vol.1‘. Here’s the first sentence of that paragraph:
Something I saw in 2011 that became almost epidemic in 2012 is conflation — the inclusion under the Enterprise Architecture umbrella of nearly anything with the slightest taste of “business” to it.
Well, yes. I’ve seen others complain about that too – and there’ve also been more than a few raised eyebrows at some of the things that I’ve associated with the ‘#entarch‘ hashtag over the past year or so. Yet in that blog, Len interprets this ‘conflation’ as a problem:
This has had the unfortunate effect of further obscuring the unique contribution of Enterprise Architecture, which is to bring architectural thinking to bear on the design of human enterprise.
Len Fehskens is one of my EA heroes, yet I’ll have to disagree with him somewhat here: to me it seems he’s missed the crucial point where those themes converge. The seeming conflation “of nearly anything with the slightest taste of ‘business'” into the scope of EA shouldn’t be seen as “obscuring EA’s unique contribution”: it is EA’s unique contribution. The conflation is the architecture: it’s what we need – not what we should avoid.
Yet we do need to look at this in the right way. It’s not that enterprise-architects should attempt to do “anything that has the slightest taste of ‘business’ to it”: that’s micromanagement, not architecture. Instead, what architects do is connect: we join the dots, link between the boxes, build bridges between the silos, get people talking with each other, to help create a clear sense of the whole as whole. As Jurgen Dahlberg put it in a recent tweet:
- RT @greblhad: Unity, not uniformity, is the aim of great Enterprise Architecture. #TheArtOfEnterpriseArchitecture
To be honest, architecture doesn’t do much of anything that’s visible on the surface: and most its deliverables don’t make much sense in those terms, either. Most of the ‘doing’ within an enterprise is the role and purview of domain-specialists – whereas architects are cross-functional generalists whose real role is is to connect between things. Architecture connects: that’s its real purpose.
An architecture needs to be able to connect between anything and everything that’s in scope for the context of that architecture. It doesn’t attempt to do everything that’s in scope: but it does need to understand everything that’s in scope, in just enough detail, and with awareness of what and how it depends on what, in order to unify and connect between everything and everything else that’s in scope for the context of that architecture.
If something’s in scope for an architecture, it’s ‘in scope’ because something else depends on it being there: so if the architecture can’t connect between everything that’s in scope, the architecture as a whole could be placed at risk. To be viable, an architecture must be able to connect everything in scope with everything else in scope.
Or, to put it another way round, if something in an enterprise depends on something else, then by definition that ‘something else’ is in scope for the enterprise-architecture. And it’s the connections that are the real focus of interest for the enterprise-architecture – not necessarily the ‘somethings’ themselves.
To give a concrete example, that Open Group ‘predictions’ blog includes four items:
- ‘Big Data’ (Dave Lounsbury)
- [IT] Security (Jim Hietala)
- Enterprise Architecture (Len Fehskens)
- Cloud (Chris Harding)
On ‘Big Data’, Dave Lounsbury says:
To allow humans to keep on top of this flood of data, industry will need to move away from programming computers for storing and processing data to teaching computers how to assess large amounts of uncorrelated data and draw inferences from this data on their own. We also need to start thinking about the skills that people need in the IT world to not only handle Big Data, but to make it actionable.
Straight away there are architectural issues there: for example, a shift in paradigm from structured ‘control’ to a more free-form inference, and the very different skill-sets needed for the latter paradigm. On security, Jim Hietala talks about much more free-form threats – in essence, the same shift in paradigm, which also means different connections between Big-Data and security. On cloud, Chris Harding explores the need for better means to connect disparate services and disparate forms of access – again, much the same kind of challenge, again needing new types of connections between cloud and everything else. Yet on enterprise-architecture, Len Fehskens somewhat bewails the same thing happening in enterprise-architecture itself – even though it’s just another instance of the same overall pattern.
Architecture connects between everything that’s in scope; so enterprise-architecture connects everything that’s in scope for the enterprise. And there’s a recursion here: architecture is part of the scope of architecture. Once we remember to apply architecture to itself, as well as to everything else, it should be obvious that “the inclusion under the Enterprise Architecture umbrella of nearly anything with the slightest taste of ‘business’ to it” is actually something to celebrate – not a problem, but a real sign of improvement.
Where Len is right to worry is the tendency towards ‘fads’ in enterprise-architecture. For more than a decade, an obsession with organisational-IT was almost ‘the only game in town’ for EA; then three years ago external-IT cloud-services became the ‘fad-du-jour’; two years ago, as Len says, it was a rather blurry notion of ‘enterprise transformation’; last year the big buzz was around an even blurrier notion of ‘business-architecture’; and this year, well, who knows what it’ll be? I won’t make any predictions there, other than that I know it’ll be yet another nuisance for us: it’s the same shallow ‘silver-bullet’ thinking, one crass example after another of the fundamentally-flawed notion of ‘somewhere-centrism’, that some one thing is ‘the centre’ around which all of the architecture revolves.
In reality, everything depends in some way, either directly or indirectly, upon everything else: so the only way that works is to recognise that everywhere and nowhere is ‘the centre of the architecture’, all at the same time. As soon as we make out that some one domain is ‘the centre’ of the architecture, by definition we’ll have broken the unity and symmetry of the architecture – which means we’d have also set it up for failure in some ‘unexpected’ way. In short, ‘enterprise’-architecture that somehow forgets to include the whole of the enterprise: not a good idea…
The unique contribution of architecture is that it connects, helps make whole, helps link strategy to execution, intent to action, action to value – all that kind of stuff. Enterprise-architecture is just another expression of the same idea: architecture at an enterprise scope, architecture whose scope is ‘the enterprise’. Yet specialists will only work within their own specific domains, often without much if any sense of connection with anything else: so the unique contribution of enterprise-architecture is that it can connect everything and anything across all of the enterprise, to create that whole as unified-whole.
Everything and anything in scope for the enterprise is necessarily a part of that enterprise-architecture, yet often only as something to connect, not necessarily always as something to design – a distinction that’s often very important in practice!
And that’s also our value-proposition: we connect, and deliver value through those connections – whereas others often sit only within their own specific boxes.
This, surely, is what it means “to bring architectural thinking to bear on the design of human enterprise”. After all, anything less would not be enterprise-architecture, would it? 🙂
Hi Tom – Good post. If we take the Network paradigm to its logical conclusion – the end of fixed structures silos/hierarchies – connections become implicit and enable increasing levels of self-organization, do the acts of connecting (relating nodes) and design become indistinguishable? For cohesion, you’d still need generalists to interpret and ‘tune’ network activity relative to objectives, mission, values (cross-cutting concerns).
Thanks, Dave. Yep, agreed, the key here is really about scope-awareness: the nature of specialist work is that it tends to focus narrower and ever-narrower, so someone has to hold awareness of how each focus-area fits into an every-changing whole. It can be the same person, of course, but as the organisation and network becomes ever larger, ‘whole-awareness’ itself becomes a specialism in its own right. To me, that’s where enterprise-architects come into the organisation/network picture.
I see less and less need for generalists, because the interconnection between things is happening more and more on detail levels which are incomprehensible for generalists. Therefore I think it is imperative to promote architecture (which is just a form of slow) thinking because we need architecture thinking at all levels…
By the way: architecture doesn’t connect things that is the role of engineering & infrastructure 🙂
Architecture influences and affects behavior: http://www.governingwithcode.org/journal_articles/pdf/How_Architecture_Regulates.pdf
@Peter B: “I see less and less need for generalists…”
I’d have to admit I’m surprised to hear this from you, as it seems almost completely opposite to a lot of what I’ve seen from you in the past.
Yes, in principle there should be no need for generalists, as long as every specialist is aware of every other specialist’s fine-detail. In reality, though, specialists tend to dig deeper and deeper into the fine-detail of their own domain, and dismiss almost all fine-detail (or even coarse-detail) of other domains as ‘somebody else’s problem’. As Gawande makes clear in his book ‘The Checklist Manifesto’, hyperspecialisation is rapidly becoming a (or even the) primary source of complexity: hence there is a fundamental for cross-functional awareness that is simply not there in most professional disciplines. Enterprise-architecture is one of the few disciplines that explicitly sets out to ‘join the dots’ and reduce cross-network complexity to more usable proportions.
I do agree with you that “the interconnection between things is happening more and more on [fine]-detail levels”; however, I don’t agree with you that these are “incomprehensible by generalists”. As I said in the post above, the key is always ‘Just Enough Detail’: the skill of the generalist is knowing how much detail is ‘just enough’.
“I’d have to admit I’m surprised to hear this from you, as it seems almost completely opposite to a lot of what I’ve seen from you in the past.”
Maybe I’m just getting old and wise :-), but I changed the most thanks to Atul Gawande (by his TED speech and the book).
You are right about what Atul Gawande says in his book about the consequences of hyperspecialisation but his solution was not the introducing of a generalist/architect. He borrowed the bottom-up checklist approach from the aviation industry to level the playing field between all team members (all specialists in their own field). Developing, adapting and using checklists is a scalable way to empower a team, a business, an enterprise or even a whole industry to become a generalist as a whole.
That is another reason why I see less need for individual persons who acts like generalists.
Apologies, Peter, but all I can say here is “Yes, and…”. Yes, I’d agree very strongly that generalism is everyone’s responsibility – yet that is still something that happens only rarely in real-world in practice. The reality is that linking across specialisms is a skill in itself – one that many if not most specialists explicitly do not have, in fact in many cases actively seek to suppress both in themselves and others.
Cross-domain generalism is something that every organisation needs, from everyone, at every level. Likewise for a whole swathe of other ‘value’-concerns such as security, probity, ethics, health and safety, environment, knowledge-sharing, efficiency, quality and so on and so on. Hence, just as for those other value-concerns, we need:
— to build awareness of the need for cross-domain generalism
— develop people’s ability to create cross-domain generalism
— execute cross-generalism at the point of action
— verify and review the effectiveness of that cross-domain generalism
…with all of this in iterative, continuous-improvement and suchlike.
As we’ve said, it’s the responsibility of everyone to execute cross-domain generalism at the point of action. Checklists and suchlike are tools that help in this. Yet where are those checklists going to come from in the first place? Who is going to do that work of creating awareness, creating capability, verifying and reviewing effectiveness? The short answer – which for (to me) some unfathomable reason you still seem to miss – is that we need people who will do that kind of work, with the explicit organisational authority to do that work across all the organisational silos and fiefdoms and so on. Those people are what we would describe as ‘generalists’, wouldn’t we?
Ideally, yes, their real task is to make themselves redundant, at the point where everyone else fully acknowledges and enacts their responsibilities for generalism. In reality, I don’t see that happening any time soon. :wry-grin: Hence the very real need right now for enterprise-architects and others who do link across the domains. That’s all I’m suggesting here: nothing more than that.
Tom, as I tweeted I agree on almost everything with the exception on your statement that linking across specialisms is a skill “that many if not most specialists explicitly do not have, in fact in many cases actively seek to suppress both in themselves and others”.
I see (or better, experience) that skill more often emerge from and used by specialists on the work floor than that I see it being used by architects.
I think I see the attitude of specialists change because the company I work for is starting doing agile business projects (not focused on software development but projects that are really game-changing for the whole company). Those projects are almost completely driven by specialists (from the business, risk management, service management, application development and management, infra, suppliers etc.) which are acting on a leveled playing field (in our case the stand-up meetings and before those the design workshops). The generalists only play a minor role at the start and their role is certainly not bigger or more important than the roles of the specialists.
With the improved cross-functional communication I see that specialists start to exchange checklist items voluntarily. At the same time it’s very hard to get checklist items from the enterprise architects. Most of the time they have to refer to specialists before they can give answers that I can use as checklist items. Checklist items that I need to check if the solution is adhering to the architecture standards proposed by those same enterprise architects…
So our experiences are somewhat different.
Another thing is that the aviation industry, also the source for Frank Gehry’s building construction industry-changing way of doing architecture, has implemented the usage of checklists without the help of generalists/(enterprise) architects. It was started by a few pilots (specialists as architects would say): http://www.atchistory.org/History/checklst.htm
Peter: yep, I’d have to agree that “our experiences are somewhat different”. I worked full-time in aviation-industry research for more than a decade, and all I can say there was that skills for linking across multiple-domains – generalism – were conspicuous mainly by their absence. Much the same in medicine: I’ve been knocking around the edges there for the whole of my lifetime – both my parents were GPs (family doctors) and we still get the British Medical Journal here every week – and again the lack of generalist awareness across domains is a well-documented disaster-area (as Gawande likewise makes clear, of course).
I certainly won’t say that enterprise-architects and others are the only ones who do cross-domain linking, but they’re some of the few disciplines who make an explicit point of doing it, and of facilitating others in doing it, too. That’s really all I’m saying here.
Three things
1. Connecting things to show how simple they really are. When more people understand the connections you end up with a successful group.
2. Top 4 labels may be coming to a head now, but are really just relabeled issues, opportunities or product that have been around for a while.
3. As specialists, generalists, leaders and everyone else begin to trust connections and share it – enterprise architecture becomes more valid as a barrier remover. Its like scientists finding more and more symbiotic relationships and all of us understanding this is the norm.
Not the most clearly stated points but the best I can do with the 10 minutes I had before taking the family to the beach!
All good points, Peter T – many thanks for that!
Hi Tom,
I agree with your article. You are an elegant speaker and communicator. That said, while you make a strong case for “the value proposition of EA is to create connection,” there is a perception among business people to place VALUE on the rare and exceptional… in other words, the hyperspecialists.
I am a hyperspecialist in a number of areas. In EA management, in SOA design, in Agile processes, etc. And as a consultant, I have having a difficult time showing people the value of the generalist side of me (I connect across silos) but I have no difficulty at all showing people the value of my hyperspecialist side.
And so we have a conundrum… how do we point out the value of doing, and providing, the one thing that a society of hyperspecialists needs: the value of generalism?
Nick – strong agree with you on the challenge here: I went into it in some depth in my series of posts on “There are no jobs for generalists”.
I don’t see any easy answer to this. It’s also exacerbated by the reality that (hyper)specialism is easy to connect directly to the point of action, and hence what most people can see as ‘value’, whereas generalism by definition is always somewhat diffuse.
In my own work, I regard myself as a (hyper)specialist in the disciplines of cross-discipline generalism: I’m ‘the go-to guy’ if somewhat wants to understand and learn how things connect, how (eco)systems work as wholes, that sort of thing. Despite the implied recursion, it’s a specialist discipline, just like any other. We need to do a better job of ‘selling’ the value of this specialism, perhaps?
In my own case I do have a fallback ‘specialism’ of data-architecture and business-information architecture – but the blunt fact is that I’m neither as good at it nor as experienced at it as the ‘real specialists’, if only because it’s a worked-example of what I really do rather than actually what I really do,
But yeah, it’s a conundrum: what we do has enormous value, but isn’t valued; there’s a huge need for it, but often an even larger ‘anti-want’. Sigh…
First, thank you Tom for your kind words. But you have misunderstood the point I was trying to make, and that is probably because I have made it at greater length in other places and implicitly carried that context into a perhaps overly succinct rendition of the point in the particular blog post you cite.
One of my other Open Group blog posts explores the assumption that enterprise means business. This assumption is nearly universal within the enterprise architecture community, and I urge you to read the three post series “Different Words Mean Different Things” where I address this quixotic concern of mine.
The unique value proposition of EA is not the application of architectural thinking to “business”; that would properly be the domain of business architecture, at least to my obsessive way of thinking that we ought to name things accurately.
The unique value proposition of EA is the application of architectural thinking to “enterprise”. If an enterprise has business considerations that are important to its stakeholders, a competent enterprise architect will address those considerations not because they are necessarily a consideration for all enterprise architecture initiatives, but because the stakeholders for this particular enterprise architecture initiative deem them so; i.e., not all enterprise is primarily about business.
I pretty much agree with everything else you say about architecture, but I note that nothing I said in the blog post you cite, or anywhere else, argues against the integrative value of architectural thinking.
If we’re going to synonymize “business” and “enterprise” and obsess about business, then just as we should have been (and still should be) honest that what most practitioners of EA actually practice is properly called “EITA”, we should be honest and drop the pretense that EA is about enterprise, and just call it business architecture (and correspondingly for the subdomain, BITA).
len.
@Len: “But you have misunderstood the point I was trying to make. … One of my other Open Group blog posts explores the assumption that enterprise means business. This assumption is nearly universal within the enterprise architecture community, and I urge you to read the three post series “Different Words Mean Different Things” where I address this quixotic concern of mine.”
I’d have to say we’re ‘in violent agreement‘ here 🙂 – see, for example, my old slidedeck “What is an enterprise?”, which argues for what is in essence the same separation of ‘enterprise’ and ‘[business]-organisation’ as you do. I very much do not ‘synonymize ‘business’ and ‘enterprise'” – that’s exactly what I don’t do. We’ve talked about this a lot at Open Group conferences, and long since agreed with each other on this: I haven’t changed my views on this, and your recent ‘Different Words’ posts suggest that you haven’t changed your views either, so I suspect that much of your concern above is just the outcome of a misunderstanding.
The only point where I think we disagree is around the ‘conflation’ of everything into enterprise-architecture. And that too is only about how we view it, which again depends on how we view the role of the enterprise-architect. If we were to think of the EA as ‘the great designer of everything’, then yes, the conflation would be absurd: but I don’t think either of us hold that view? If instead we hold the view that the EA’s role is more of a facilitator, to get people to talk together about how to link things together into more of a unified whole across the overall scope, then the ‘conflation’ of scopes does actually make practical sense. That was my key point in the post above.
On business-architecture, I think we’re again ‘in violent agreement’. Breaking out of IT-centrism solely in order to fall straight into business-centrism is not a good idea – see my post “IT-centrism, business-centrism and business-architecture”. To me, business-architecture is best understood as the architecture of ‘the business of the business’: themes such as business-models, financial-architectures, organisational structures and suchlike. It’s just another somewhat-specialist domain, which is part of the overall scope of enterprise-architecture. It’s very definitely not the whole of enterprise-architecture, nor the centre of it: the only way that works is that everywhere and nowhere is ‘the centre’, all at the same time.
The one point where we might have a source of disagreement – and where you might have (mis)interpreted how I view the relationship between ‘enterprise’ and ‘business’ – is that I’d argue that as EAs we’d usually create an architecture about an enterprise but for an organisation. There are two key reasons I argue for this. One is purely pragmatic, namely that it’s the organisation that pays our bills, not the much more blurry enterprise. 🙂 The other is that often what we’re looking for, and exploring, is the tension between the ‘inside-out’ view of the organisation, versus the ‘outside-in’ view from the broader shared-enterprise within which the organisation does its business: the slidedeck “The enterprise is a story” gives a fairly good summary of this. But there are plenty of other ways that EAs can and do work, of course, so it might be a bit of a moot point to push that theme too far.
Overall, I don’t think the disagreement you seem to see above actually exists – or certainly not as much as you suggest there. But maybe I’ve missed something important here? So please, let’s keep talking on this – I really value your advice and experience on all of this.
Many thanks!
Tom replies “I’d argue that as EAs we’d usually create an architecture about an enterprise but for an organisation”
I absolutely agree; this is one of the more compelling reasons for distinguishing between an enterprise and the organization that realizes it.
I have to admit I’m now confused as to what you disagree with me about. In your original post you state:
“The conflation is the architecture: it’s what we need – not what we should avoid.”
I think you’re misconstruing what I mean by conflation. Look it up; see for example the Wikipedia article, which states:
“In logic, it is the practice of treating two distinct concepts as if they were one, which produces errors or misunderstandings as a fusion of distinct subjects tends to obscure analysis of relationships which are emphasized by contrasts”
This fairly accurately represents the nature of my concern.
I’m not saying or implying that architecture is not about looking at everything that is relevant; indeed, I have argued at great length elsewhere that my concept of architecture entails everything that is necessary and sufficient for fitness for purpose, regardless of, for example, how detailed or concrete it is. But that’s not what conflation means.
The conflation of “anything with the slightest taste of ‘business’ to it” with the concept of enterprise architecture is to be avoided because enterprise and business are two distinct concepts, and business is properly within the purview of an enterprise architecture (as distinct from the discipline of enterprise architecture in general) only to the extent that such business concerns are necessary and sufficient to ensure the fitness for purpose of the specific enterprise under consideration. If we conflate business considerations with enterprise architecture as a concept, we also ought to conflate anything and everything that any stakeholder might consider necessary and sufficient for the fitness for purpose of any enterprise, which would render enterprise architecture meaninglessly all inclusive.
The value of enterprise architecture comes not from its attention to business specifically, but from its attention to whatever is relevant to a particular enterprise. Emphasizing business specifically, as far too many peoples’ concepts of enterprise architecture do, obscures this point, risking focusing on business considerations to the exclusion of anything and everything else that is also necessary and sufficient for the enterprise to be fit for purpose. This can be catastrophic for enterprises that are not primarily about business.
You clearly understand this point, as you talk around it in the rest of your comments. You write:
“The unique contribution of enterprise-architecture is that it can connect everything and anything across all of the enterprise, to create that whole as unified-whole.”
Exactly — my point in the blog is that this “everything and anything” is not specifically or solely business, and talking about enterprise architecture as if it were (i.e., conflating
“anything with the slightest taste of ‘business’ to it” with the concept of enterprise architecture) does indeed obscure this point.
len.
Len – yes, I suspect we’re ‘violently agreeing’ yet not quite managing to get there… 🙂
I probably misunderstood your meaning or interpretation of ‘conflating’. To me there does need to be a kind of blurring or melding-together for the architecture to work – there needs to be this sense of ‘everything as a whole’, at the same time as ‘everything separate and distinct (sort-of)’. In that sense, we do need “conflating ‘anything with the slightest taste of ‘business’ to it’ with the concept of enterprise architecture”.
The trap – and I think this is what you’re alluding to? – is that this conflation of “anything with the slightest taste of ‘business’ to it” risks becoming centred around ‘doing business’, or ‘making money’, or suchlike: in other words, ‘business-centric’, in the same way that TOGAF was (and present still is) ‘IT-centric’. To many people it looks ‘obvious’ that we ought to do it that way, and there would be massive pressures on us to do it that way, too: the catch is that it doesn’t work. The only way that does work is when everywhere and nowhere is ‘the centre’, all at the same time.
Which includes ‘the business of the business’, of course: it must do, by definition. Likewise it includes IT: again, it must do, by definition. The architecture includes in its scope anything and everything that is in scope: that’s the functional definition of an architecture.
(And yes, I do know that that’s a circular definition – or, more precisely, a recursive definition – but that’s something we have to live with, isn’t it? 🙂 But that’s where ‘It depends…’ and ‘Just Enough Detail’ come into the picture – and why they come into the picture, too.)
So I think we do agree – we’re just coming at it from somewhat different directions. And hence somewhat different warnings and concerns that arise from at it from those different directions.
Tom replies to me: “So I think we do agree – we’re just coming at it from somewhat different directions”
I agree that we agree. Based on our many face to face conversations, that was pretty much my expectation going into this discussion.
The value to me of exchanges like this is that they surface my unspoken assumptions, and force me to think of better ways to explain my thinking. This often means saying things that I had left unsaid, because they were “obvious”. But obvious to me is not obvious to you, not becuase the ideas are difficult or obscure, but rather because, precisely as you note, we come at these things from different directions.
It now occurs to me that what I was really bemoaning in my Open Group Blog posting was that the failure to distinguish between sometimes, often and always that pervades much thinking and discussion about enterprise architecture.
If the only horse I have ever seen is an Appaloosa, indeed if all the horses I ever seen are Appaloosas, it is easy to conclude that all horses are Appaloosas, and to define “horse” conceptually as if “Appaloosaness” were an integral part of “horseness”. This “intrusion” of the specific details of “Appaloosaness” into the general concept of “horseness” is what I meant by conflation.
Similarly, if all the enterprises I have experienced have been businesses, it is tempting to conclude that all enterprises are businesses, and that enterprise architecture is inherently and essentially driven by business considerations. This is what I meant by “conflation — the inclusion under the Enterprise Architecture umbrella of nearly anything with the slightest taste of “business” to it”.
You write:
“The trap – and I think this is what you’re alluding to? – is that this conflation of “anything with the slightest taste of ‘business’ to it” risks becoming centred around ‘doing business’, or ‘making money’, or suchlike: in other words, ‘business-centric’”.
Yes — that is of course necessarily true (and entirely appropriate) of enterprise architecture as applied to enterprises that are businesses, but it would be largely inappropriate for an enterprise that is not a business as such (e.g., a governmental, academic, military, medical or religious enterprise). Of course, all enterprises must by definition have some business interactions; realizing an enterprise requires the acquisition of resources, and such acquisition almost always entails business (commercial) transactions, but the conduct of businesses by such enterprises is incidental to their raison d’etre, and as such is probably not the driving focus of such an enterprise’s architecture.
That’s what I was trying to get at.
len.
Hi Tom,
Quote:
“Due to environmental changes such as globalization, outsourcing, and virtualization, more and more companies are becoming involved in activities that are outside the boundaries of the traditional company (a single autonomous legal entity). This is typically achieved by entering into collaborative relationships or joint ventures. Such collaborative relationships and joint ventures are referred to in this paper as enterprises , and the management of them is known as enterprise management. The European Commission (2003) defines an enterprise as ‘. . . an entity, regardless of its legal form . . . including partnerships or associations regularly engaged in economic activities’. Therefore, in its most simple form, an enterprise could be a single integrated company. However, this research shows that enterprises can also be made up of parts of different companies, and the structure of the enterprise is contingent upon a variety of different factors. The success of the enterprise as a collaborative venture depends on the ability of companies to intermediate their internal core competencies into other participating companies’ value streams and simultaneously outsource their own peripheral activities to companies that can perrform them quicker, cheaper, and more effectively (Lal et al. 1995). In other words, the peripheral activities of one member-company should be a core competence of another member-company within an overall enterprise. This paper gives an overview of a research project that aims to develop a conceptual contingency framework to guide enterprise managers to make better strategic decisions for the whole enterprise; it specifically aims to investigate suitable enterprise structures for different collaborative settings based on the causality between the prevailing type of core competence and the emergent enterprise structure. An enterprise management perspective has been taken in order to elucidate current developments in operations and supply change management from a relatively new and novel point of view. It uses novel analytical units (the enterprise and its sub-units known as enterprise modules) to give a fresh perspective to emerging issues and provide practical guidance for industrialists who must build and manage enterprises. Using inductive grounded reasoning, a set of tentative propositions has been developed and validated that reveal some critical factors affecting enterprise management. They have been consolidated into a single framework building on empirical evidence from the German automotive industry and existing theory.
:endquote
from Clegg, B. and Binder, M., [Aston Business School], “A Conceptual Framework for Enterprise Management”, International Journal of Production Research, Vol. 44, Nos. 18-19, October 2006.
One of my fustrations with Enterprise Architecture, as a discipline and as a community, is its inward-looking predisposition expressed in the lack of refrence to other management disciplines and prior, often better-quality, research.
That ‘enterprise’ cannot be equated with ‘the business’ or ‘organisation’ is a principle that was established some time ago – it is only the ill-informed or un-educated that would make such an identification.
As to ‘generalists’ – has the EA community noticed the rise in ‘cross-functionalism’ in other academic disciplines over the last decade or so? Individual specialisms alone are insufficient and a collection of specialists an effective and efficient decision-making organisation does not make. A generalist is required to bring together and integrate the multifarious specialist perspectives. Specialisation as an approach works only if the knowledge boundaries of the specialism are well-drawn and there is no ‘specialism’ in executive management because it is an integrative discipline – drawing on lots of different knowledge areas. Like Enterprise Architecture.
Regards,
Ian.
Hi Ian – nothing more I can add to that, really 🙂 – good points all. Many thanks!