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.