Big EA, Little EA and Personal EA

Listening to a podcast with Patti Anklam on the InMagic social-knowledge website – ‘Today’s collaboration imperative: a podcast with Patti Anklam‘ – reminded me of her previous posts some months back on the ‘Three KMs’, three distinct layers of knowledge-management within the enterprise:

  • Big KM is about top-down, structured and organizationally distinct “knowledge management”
  • Little KM is about safe-fail experiments embedded in the organizational structure
  • Personal KM is about access to tools and methods to ensure that knowledge, context, bits, fragments, thoughts, ideas are harvestable

It seems to me that much the same distinctions could usefully be applied to enterprise-architecture (EA), especially if we start from Patti’s definition of ‘knowledge-management’:

I have always defined KM as a “collection of disciplines, methods and tools embedded in an information infrastructure that supports creation and sharing of knowledge assets to achieve business goals.” The KM community within an organization is responsible for developing and constantly renewing a repertoire of KM tools and methods that are ready-to-hand to support emerging business needs. A small number of annual conferences [and other events] bring practitioners together to see and share experiences and practices and to keep raising the bar.

In effect, EA is a special category of knowledge-management: the EA community within an enterprise develops and maintains a body of knowledge about enterprise structure and purpose, and assists others in putting that knowledge to practical use, to enhance enterprise effectiveness. To do this, the EA community is responsible for developing and constantly renewing a repertoire of EA tools, methods, disciplines and skillsets that are ready-to-hand to support emerging business needs. And we use a conferences and a wide range of other real-world and online venues to see and share experiences and practices and to keep raising the bar. (The slowly-increasing awareness and acceptance of the fact that, to be effective, EA needs to be much wider in scope than just IT, is one such example of ‘raising the bar’.)

Like Big KM, Big EA is the formal representation of enterprise-architecture within the organisational structure. This is perhaps the most visible aspect of EA – indeed, what many people in IT, ‘the business’ and elsewhere would think of as ‘enterprise-architecture’. Big-EA is enterprise-wide, though as yet still usually constrained to enterprise-wide implementation and applications of IT-systems.  Big-EA is characterised by:

  • formal structure – an explicit business-unit of some kind with ‘enterprise-architecture’ as or in its title
  • formal roles with ‘enterprise-architect’ either as or in the job-title
  • formal reporting-relationships at or to executive-level (typically the CIO, at present)
  • formal business-processes and services to link architecture with implementation-design and change-management
  • formal deliverables and ‘products’ of architecture effort
  • use of formal frameworks such as TOGAF, FEAF and Zachman

Much like Big-KM, the services delivered by Big-EA would typically include:

  • consulting to business units and business-partners on system-wide integration themes and practices methodologies, embedding architectural expertise into projects and business change-processes
  • providing programme/project materials such as change-roadmaps and models
  • supporting ‘top-down’ strategy, ‘bottom-up’ innovation and ‘horizontal’ whole-of-system optimisation
  • architecture-content management, including publishing of models and support for online EA portals, typically via the use of large, sophisticated (and often horrendously-expensive) purpose-built ‘enterprise-architecture toolsets
  • architecture advocacy and thought leadership on the application of EA enterprise structures, especially IT infrastructure applications and services
  • supporting the development of  communities of practice on architectural themes
  • providing learning and knowledge transfer on architecture through best practices, experiential learning practices for teams, and direct person-to-person engagement

Like Little KM, Little EA is “the quiet application of [architecture] methods to business problems in a way that just makes sense”. In effect, this is the informal collaborative practice of EA that – from sheer necessity – will always exist in some form in any enterprise, especially in the absence of any formal structures: as soon as two more projects or layers need to collaborate to each other, there’s an implied need for some kind of architecture. To paraphrase Patti Anklam, the identified need for architecture can then be mapped to appropriate EA methods, tools, or approaches; any part of an organization may apply an EA practice to design and intervention in support of an immediate opportunity or problem. To again paraphrase Patti Anklam, EA people connect ‘relentlessly‘. Since EA depends on its body of knowledge about enterprise structure and purpose, many of these methods resemble those used in Little-KM, including:

  • learning before, during and after – such as the review-process in TOGAF Phase H
  • support for communities of practice
  • support for social-networks to link between organisational silos, projects, communities of practice etc
  • knowledge-mapping, structure-mapping and interface-mapping
  • knowledge-continuity and retention – the need for some kind of indexed reference-repository, even if only in paper form
  • informal processes for collaboration, problem-identification and solution, and conflict-resolution, both within and beyond the organisation

Like Personal KM, Personal EA is something we all do all from time to time, and probably should all learn to get better at doing it. In essence, it comes down to the use and and implementation of a single idea: that we gain greater overall effectiveness (‘efficient on purpose’, and the like) when we put in the extra effort to ensure that the various of a system work together well. So there has always been some kind of ‘architecture’ going on even in the most ‘unplanned’ of enterprises; the aim in Personal-EA is to bring those processes and ideas to the foreground, to make their use more intentional and their value more explicit.

To paraphrase Patti Anklam, Personal-EA is also about “the tools and strategies that we employ that make it easier for us to identify, locate and process knowledge” – specifically, for architecture, knowledge about the dynamic interplay of structures and purpose. The tools don’t have to be sophisticated: Visio and Powerpoint are still the most commonly-used ‘enterprise architecture’ tools, and every time we do a whiteboard-diagram or scribbled sketch of the relationships and interfaces between two or more systems, we’re doing Personal-EA. Every time we start a conversation with colleagues about how to link information or processes or ideas or systems together, we’re doing Personal-EA.

To paraphrase Steve Barth, the various EA-tools – which in practice may as simple as pen and paper – will help an project-manager, designer, architect or the like “to automate, accelerate, augment, articulate and activate the information and the ideas that he or she works with every day to perform their job”. It’s essential, though, to note Patti Anklam’s warning that “tools are only as good as the skills that exist or evolve to make the best use of them”. Steve Barth quotes a useful skills-toolkit – a set of skills for Personal-KM, which are equally important for Personal-EA:

  • Accessing information and ideas: for EA, this includes sources of information about content, context and connections, and ideas on innovations and other options for the enterprise
  • Evaluating information and ideas: for EA, this includes architectural review to assess quality and relevance to the current tasks
  • Organizing information and ideas: for EA, this includes structuring the information for re-use, particularly in relation to a standardized descriptive framework or ‘hologram’ of the overall enterprise – “information and ideas become actionable knowledge by being internalized and integrated with what we already know and believe … to find patterns, trends and relationships”
  • Analysing information and ideas: in EA, as in KM, this is much broader than analysis – it is more about ‘sensemaking’ in a generic sense, using analysis, hypothesis, synthesis, telesis (“the study of design, purpose and intent”), deduction, induction, abduction and any other appropriate tools
  • Conveying information and ideas: for EA, the emphasis here is on communication and sharing of architectural models, schemas and the like, either on-line or in person
  • Collaboration around information and ideas: for EA, much of this too will be both in-person and on-line – and crucially, will often need to bridge across boundaries both within and beyond the organisation, to enhance and optimise overall effectiveness
  • Securing information and ideas: for EA, this is not only about security from an ‘intellectual property’ perspective, but much more about ensuring that architectural information is managed, maintained, kept up-to-date, and used in appropriate ways within the enterprise.

Practical implications: Big-EA is the visible face of enterprise-architecture, but there are several serious concerns that can arise from that visibility, and from an over-focus on Big-EA itself:

  • Positioning within the organisation: If Big-EA is the visible face of enterprise-architecture, it matters greatly where it’s placed within the organisation. Because EA will often have enterprise-wide impacts, it must have an enterprise-wide scope, with enterprise-wide reach and authority. At the least, it needs to report direct to the overall executive. If instead it is placed within a single domain (usually IT, reporting only to the CIO, or even not to any executive at all), its overall authority and credibility will be reduced, and the team may not have the required whole-of-enterprise awareness and expertise. Placing the EA unit (Big-EA) within a single domain will usually cause more harm than good, perhaps improving that specific domain, but damaging overall enterprise effectiveness.
  • Over-emphasis on ‘control’ and architectural ‘purity’:  Given the real challenges of enterprise-architecture, there’s often a tendency for Big-EA to retreat into an over-focus on theory and ‘purity’ of models, and an over-emphasis on playing the role of ‘architecture police’, to the detriment of usable and actionable advice.  The risk here is that EA may become regarded as an academic-style ‘ivory-tower’ discipline, with little or no relevance to real-world practice, and even a hindrance to getting things done – which, in turn, may well lead to calls for closure of the EA unit. Which would not be not a good outcome.
  • Over-centralisation of responsibility for architecture: The risk here is if architecture is over-professionalised, it is likely to become viewed as a Somebody Else’s Problem, the exclusive responsibility of specialist ‘enterprise architects’ rather than the responsibility of everyone in the enterprise. (Dave Snowden gives a similar warning about the dangers of over-professionalising knowledge-management, such as with the appointment of a ‘Chief Knowledge Officer’.) Professionalising architecture into Big-EA form can thus paradoxically lead to lower effectiveness and architectural integration across the enterprise.

To resolve these concerns, we need to place strong emphasis on the following points:

  • Enterprise-architecture is best understood as a special-case of knowledge-management: it manages a body-of-knowledge about enterprise structure and purpose, and the application of that body of knowledge in business practice.
  • The existence of any Big-EA, such as a formal ‘enterprise-architecture unit’, is merely an organisational convenience: a known place to gather together the appropriate expertise and manage the more sophisticated repositories and tools that will be needed for more advanced EA, especially in large organisations.
  • Big-EA depends on Little-EA: the practices of collaboration, engagement, governance, negotiation and the like.
  • Little-EA depends on Personal-EA: the idea of architecture, as a means to enhance integration and effectiveness, and the understanding awareness that architecture is everyone’s personal responsibility.

Or, to put it the other round, any Big-EA needs to support all possible forms of Little-EA; and Little-EA in turn needs to support and emphasise the importance of Personal-EA. If we ever get this the wrong way round – placing Big-EA as the centre of our attention – our architecture, and the enterprise itself, will be in trouble straight away.

Big-EA is useful; Little-EA is important; but Personal-EA is the core of all enterprise-architecture, and is the responsibility of everyone.

Simple as that, really.

9 Comments on “Big EA, Little EA and Personal EA

  1. Hi Tom,

    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?

    • Hi Stephen – many thanks.

      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.

  2. Hmmm. Interesting

    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.

  3. Many thanks, Peter – it was particularly from you guys at AusPost that I learned the importance of thinking whole-of-enterprise rather than IT-only for enterprise-architecture.

    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… 🙂

  4. LOL a – Will it be 30 degrees centigrade in June/July?

    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.

  5. Tom

    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.

    • Hi Richard – many thanks. The naming of the layers and distinctions between them, or even the idea of layers, is really not that important here: I was just using Patti Anklam’s excellent article-series as a way of reflecting on various themes in enterprise-architecture.

      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.

  6. Thanks Tom and everyone for your additional comments and clarification.

    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!

  7. This is an interesting topic . . . While I agree to a certain extent with each of you, I find it a little disconcerting on two fronts:
    – one, that anyone would consider EA to be about ‘building a system’ — it is much more about understanding, modeling, and analyzing a business, than about its automation . . . although to truly be EA, you really need to look at Business and Technology, the organization, automated support, gaps, etc.

    – 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 . . .

Leave a Reply

Your email address will not be published. Required fields are marked *