- on the other hand, equating it with the totally unstructured, undirected subject of Knowledge Management is a bit like equating the idenitfication of the animals in the zoo to the original herding of animals from the wilds of Africa — one has methods, guidelines, and defined goals and process, while the other is an attempt at identifying some (as yet undetermined) commonality among myriad unknown things — they seem completely different and almost diametrically opposed in process, method, and likelihood of success.

Additionally, the ‘architecture’ part of EA already exists — it is up to the EA to identify it, define it, and document it, then use it for a predictable set of uses. KM may idenitfy commonality among various stuff, but its use remains unknown . . . sort of the root of research and discovery — there may be a diamond in the rough, but there may not. The practice of EA always knows what the results will be . . . and for what benefit they can be used . . .

For the same reasons, I fully agree with your set of ‘layers’ or modes or styles (Authority, Commodity, Network, Authentic) – it’s a useful way to highlight particular skillsets and the contexts in which they come to the fore within the work. Whichever way we slice-and-dice the overall EA skillset, what matters most, as you say, is “how the different styles interact, and what are the implications for governance”. More on that in other posts, as you’ve seen.

Thanks again, anyway – and apologies for slight delay in replying.

I see that I didn’t read your article closely enough. There are still EA actions going on in “Little” and “Personal” spheres, it’s just that they are typically *executed* with the help of many skills and methods from the KM toolkit.

I think I get it now!

Maybe people in the KM world use the word “layers” loosely; however in the EA world, the word typically suggests some kind of geometrical structure, and I guess that’s not what you mean here. I think the division you are talking about is more about different styles, or perhaps different kinds of knowledge claim.

I’ve used a slightly different division in the trust sphere, which might make sense here as well.

Authority EA – this is a kind of top-down command-and-control EA, representing the will-to-power of the enterprise as a whole, and ultimately answerable to the CEO. This is what you are calling Big EA.

Commodity EA – this is where the EA is based on some kind of external product source – such as when the enterprise models are imported wholesale from IBM or SAP. This often resembles Big EA, but has some important differences.

Network EA – this is where EA is based on informal and emergent collaboration between people and organizations. You call it Little EA, but the collaborations can be very extended indeed – just think about some of the mashup ecosystems around Google or Twitter.

Authentic EA – this is a personally engaged practice – what you call Personal EA.

—

However, once we have agreed that there are different styles, the really interesting question is not identifying and naming the styles, nor even saying that one style is somehow “better” than another style”, but talking about how the different styles interact, and what are the implications for governance.

LOL b – Forgive me but I frequently use acronyms.

I mentioned the “SPOT grows (painfully) to become the basis of much decision making” – because ours is still growing, is FAR from perfect, has a few duplicate/replacements within the company BUT is catching on.

I presume ‘SPOT’ is ‘single point of truth’ in this context?

Enjoy your sunshine whilst we shiver – we’ll remember that when June/July comes round…

In support of Tom’s point 2 – What I’ve found is that EA is all KM. i.e. its a cycle of capturing and maintaining information about future, present and past in a common language about systems designed by architects, built by projects and maintained by process and people before being operated by people for the business and its customers.

If we apply that mindset, we can deal with operational corrective action, strategy development and application, project portfolio management AND other non systems based areas with a single point of truth. Of course, the SPOT grows (painfully) to become the basis of much decision making. Imagine Marketing using the SPOT and maintaining it, Premises people using the SPOT and maintaining it, Fleet people using the SPOT etc, etc.

Idealistic, Unreal, Unwieldy? The biggest challenge is making people think, operate and grow in this collaborative way rather than with their ‘not invented here’ mindset. Just think about it such KM systems exist around us now and are expanding faster than we know.

BTW – You northern hemisphere types are snowed in – We are expecting 41 degrees centigrade.

Quick answers: 1) This isn’t about expanding the EA role, just documenting what it already does. Done properly, EA needs to cover the interrelationships between every system in the org and in the enterprise, and ensure that each and every one of those systems is fully ‘on purpose’. Architecture and design are flip-sides of the same coin, respectively facing towards big-picture and fine-detail. Most people do some of both, but architects should emphasise the big-picture issues, leaving the fine-detail to system-developers, process-analysts and the like. (One of the problems we have is that designers often call themselves ‘architects’, which they’re not, other than in the Personal-EA sense.) If an EA unit in a large org is trying to design and construct everything, a) it’ll be trying to usurp everyone else’s role and/or authority (a quick path to major conflict), b) it’ll go crazy trying to do everything for everyone, and c) it won’t have time to do its own architecture-tasks properly. The KM-like notion of ‘Personal-EA’ helps to spread the load, and emphasise that architecture is ultimately everyone’s responsibility.

2) Again, all I’m doing is documenting what already happens. The point of this split is it distinguishes between the formal role (Big-EA), the activities (Little-EA) and the ultimate responsibility (Personal-EA). Conveying the message that architecture is everyone’s responsibility, and that almost everyone needs to be engaged in architecture-type activities in their own specific work-area, is an essential part of any enterprise-architecture communication-plan and engagement process.

I dunno. Why do you want to expand Enterprise Architecture beyond what it needs to do, ie provide a structured approach to designing and constructing a system?

The “Little EA” and “Personal EA” items sound like plain old Knowledge Management and Information Management. Why not use these terms instead of shoehorning them into what is already a complex discipline?