At the interface

enterprise-modelingLeave a comment

… between people, between systems, between people and systems …

Background

When asked about my work and what I do, I sometimes answer …

I work at the interface between business people and IT people because business people don’t understand IT people, and IT people don’t understand business people

I usually follow that with the quip “and I don’t expect to be out of a job in my lifetime!”

Now, I am one of the leaders of Interface Associates where we seek to cultivate the capability within organisations to more effectively manage a range of interfaces without having a reliance on organisations and people like Interface and our Associates.

Interfaces

There are, of course, a range of external interfaces that any organisation needs to manage (even a sole-trader organisation). Some of these are shown in the following diagram.

No alt text provided for this image

There are also internal interfaces the organisations need to establish and manage, including those shown in the following diagram.

No alt text provided for this image

Role

In this role, there are a number of different approaches that have proven helpful, including acting as:

  • Babelfish
  • Conceptualiser
  • Simplifier
  • Animator

Babelfish

In this role, picking up the concept from Hitchhiker’s Guide to the Galaxy, the babelfish acts as interpreter and translator, helping people understand the different language and terminologies in use, often the different languages and dialects used by different professional backgrounds. The most significant role entails identifying and resolving situations where the same word is being used, but different meanings are intended (but usually not conveyed).

Conceptualiser

Organisations and the ecosystems in which they operate are often quite complicated, making them difficult to understand. In the role of conceptualiser, we develop conceptual models that provide a simpler and clearer representation that is easier to understand. There is also a much lower cost in changing a conceptual model to better reflect shared understanding or to explore future options, whether that be the business model or operating model for an organisation or organisational entity.

Simplifier

The role of simplifier extends beyond developing conceptual models to providing other models or abstractions of the system being considered. This may involve four different modes:

  • composition / decomposition
  • inclusion / exclusion
  • generalisation / specialisation
  • ideation / realisation

These different modes are chosen to assist stakeholders to focus on the area requiring greater (or lesser) attention and presenting some challenges in developing shared understanding.

Animator

Last, and certainly not least, is the role in helping stakeholders to distinguish between the animate and inanimate elements of the entity being considered, enabling stakeholders to form views as to where:

  • consistency and efficiency is best supported by inanimate systems
  • flexibility, creativity and variability is best supported by animate systems (people and teams)
  • the interface between the animate and inanimate to establish the most effective outcomes

Value provided

Some of the underlying capabilities that we bring to these roles derive from:

  • the wide range of patterns and experiences gleaned across different industries and organisations
  • appreciation for the balancing and shifting of the interface (boundary) between social systems and technology systems
  • our experience in evaluating relative merits of different positions / options
  • the discipline, integrity and assurance that are brought through governance processes

Offer

We offer our service through a variety of different engagement models, based on the preferences, convenience and suitability as determined by our clients. The models and associated service offerings include:

  • Learning through webinars, masterclasses, self-paced learning resources
  • Coaching and mentoring associated with a variety of executive, management, project and change roles
  • On-demand demand services where there is a more significant capability gap or insufficient need to warrant an internal position, offering roles such as on-demand COO, CIO, IT Manager, Program Manager, Project Manager, Business Analyst, Change Manager
  • Research activities where clients and Associate jointly contribute to gathering of evidence to better inform evaluation of efficacy of approaches to transformation, change, capability cultivation and leadership mastery.

Pain points experienced by SMEs

enterprise-modelingLeave a comment

Background

As outlined in the article on architecting small enterprises, the opportunity exists to:

  • Establish stronger foundations through well-architected small enterprises that enable them to scale and respond to emerging opportunities more readily
  • Gain experience in cultivating and managing the organisational capability portfolio
  • Harness enterprise potential earlier in the life of an enterprise, at lower cost and with greater value being realised

Motivation

This article is aimed at identifying:

  • Those points in the life of an enterprise where leaders experience pain arising from the difficulty of key “structural” decisions or from the legacy of failing to make appropriate “structural” decisions
  • The means by which they seek advice and support in resolving these difficulties
  • The search terms that they use in seeking to find appropriate advisory or assurance services

Ideas

Based on our experience in managing growth:

  • from soletrader to small enterprise
  • through the stages of small to medium enterprises
  • new divisions being formed in larger enterprises

it is evident to us that pain points emerge in the following general circumstances:

  • responding to significant market changes, requiring a change in business or operating models
  • seeking to “find efficiencies” to enable products / services to be “more competitive”
  • restructuring the organisation
  • formalising support arrangements (eg. establishing a Business Manager, or a Chief Operating Officer, or a Corporate Services function)
  • moving from informal (undocumented) to more formal (documented) business processes
  • addressing the “manual processes” that surround “IT systems” or the siloes that “IT systems” seem to have become

In larger organisations, advice and support for transformation and change will be sought from:

  • Management consultants
  • IT consultants
  • Organisational development specialists
  • Organisational and business change specialists
  • Business transformation specialists

In smaller organisations, the advice may be sought from:

  • existing relationships with accounting firms or IT service providers
  • middle-tier consulting firms
  • sole-trading business advisors
  • government funded business advisory services
  • university operated business growth researchers and academics

Questions

In light of the above:

    • What other pain points have you observed?
    • What other sources of advice have small to medium enterprises used?
    • What means have these organisations used to provide appropriate advice and support?

Enterprise babelfish

enterprise-modelingLeave a comment

Enterprise babelfish?

For those who have not read or heard of the babelfish – you can find it in Douglas Adam’s “Hitchhiker’s Guide to the Galaxy”.  Placed in your ear, the babelfish provides instant translation of any language being spoken by any alien you might encounter.

In thinking of my role as enterprise architect, business architect, business analyst, business synthesist in the many different enterprises with whom I have engaged, I realised that one of the important capabilities that I bring to bear is the capacity to understand an enterprise and the various ways in which each organisation or organisational entity thinks and communicates about themselves.

This article explores the need, nature and value of the role of enterprise babelfish and offers a different way of thinking about the role that various enterprise change professionals fulfill within the enterprises with whom they engage.

Business context and need

In any enterprise, there are special words and expressions that form part of the way in which the enterprise speaks of itself, encompassing:

  • vision and mission
  • culture and values
  • products and services
  • value propositions and differentiators
  • processes and ways of doing things

Understanding the intended meanings of these words and expressions is an important element in being part of the organisation and contributing to its operation, development, management and governance.

The larger the organisation, the more likely it is, that there are differences in understanding and articulation which result in different attitudes and behaviours, with the potential to limit the development and performance of the organisation.

Two influencing factors relate to how we use language and how we use models in our thinking and communication.  In these respects, it is helpful to appreciate aspects of:

  • denotation and connotation
  • perception and conception

The first of these was drawn to my attention by Len Fehskens.  The latter is more of a hypothesis of my own!

Denotation and connotation

For many words, but particularly for those words and expressions that reflect the essence of the identity and operation of an enterprise, there are two facets to their meaning:

  • the particular meaning that is denoted by the word or expression
  • the related concepts and expressions that are connoted by the word or expression

A simple example – wheel:

  • denotes a circular object fixed to another to enable movement
  • connotes an ability to rotate and having an axle

It is important that the appropriate denotation and connotations are formed – otherwise, a different meaning or interpretation may be made by others.

I have encountered numerous situations where different people in an enterprise use the same word or expression, but where the connotations associated with the expression they are using are quite different – to the point that the difference prompts use of completely different business processes.  In one client setting, the term “Work Pack” meant a Work Order in one Division and a Scheduled Operation (part of a Work Order) in another Division.  This difference was sufficient to mean that common systems, processes and practices were not feasible across Divisions until consistent definitions and processes were established.

As enterprises give attention to consistency in denotation and connotation of key terms and language, they are developing greater self-awareness and greater capacity to effect change and operate in a more integrated and consistent manner across the enterprise.

Perception and conception

As we encounter and interact with the enterprises of which we are part, we build mental models of the enterprise, based on our perception of how the enterprise operates.  Inevitably, we have very limited exposure to the full operation of the enterprise, so our perceptions lead to widely varying mental models of the enterprise.  This is reflected well in the story of the blind men who encounter an elephant, each describing what they have encountered based on the limited point of contact that they have.

Our perception is influenced, not only by the limited parts of the enterprise to which we have exposure, but also by the nature of the interactions we have – by what we observe about the thinking, attitude and behaviour of leaders, managers, peers and others.

Another element to our understanding of any enterprise relates to our conception of the enterprise – the model that we build of the entire enterprise, based on inputs such as:

  • corporate documents espousing vision, mission, purpose, objectives and strategies
  • organisational structure, policies and other elements describing how the enterprise is organised
  • similar materials available for each of the organisational units of which the enterprise is comprised

This enables us to develop a “high level” model or “conceptual” representation of the enterprise.  Not surprisingly, there can be significant gaps between our conception and our perception of the enterprise.

Barriers to understanding

There are a number of barriers to shared understanding, including how we deal with and think of our enterprises.

Systems

Organisations and enterprises can be conceived as systems-of-systems. This, in its own right, leads to numerous views of interwoven systems.  One only needs to consider a generic, high level operating model (see related article – Operating models) to appreciate how many systems might exist in any enterprise.

The vast majority of organisations entail human activity in combination with supporting technology, introducing considerations in relation to:

  • Human activity systems (HAS)
  • Information systems used by these HAS
  • IT systems and other technology based systems also used by these HAS

with a long history of difficulties in designing and implementing an effective combination of HAS / IS / ITS / TBS which effectively enhance enterprise performance.

Add to this that systems can be conceived of through conceptual models, designed through logical models and implemented in accord with physical models, and we have further added dimensions of complexity.

Beyond these factors, there are others which become evident as one explores the disciplines encompassed within the broad realm of “systems thinking”.

Models

There are various types of models at play within enterprises, including but not limited to:

  • Each of us have mental models of the world and the enterprise with which we engage and interact
  • Our information systems (whether paper based or digital) are a model of how the enterprise sees the environment in which it operates, its interactions with this environment, and its internal activities.
  • Our planning, designing and managing activities often develop models as a means of communicating intentions or exploring options

Our engagement in the development and operation of our enterprises requires us to better understand these different types of models, and to deal with the range of inherent conflicts which inevitably arise between the various models we use, whether individual or shared models.

Complexity

As we start to explore organisations and the enterprises they pursue, it does not take long to realise that, like human beings, organisations are complex entities. This leads to a number of different issues as no individual can hold within their mind all elements that go to make up the structure and behaviour of an organisation.  The implications of this include:

  • Each individual may have a different perception and conception of the organisation
  • A complete conception of the organisation requires multiple individuals to create and sustain
  • Common models and a common language and narrative will be required to deal with these implications

Role of enterprise babelfish

And so it is, that I see an invaluable role for those within an enterprise that have the capability of the babelfish to:

  • recognise the different languages and models being used within our enterprises
  • enable the enterprise to develop a more consistent expression of its aspirations, intentions and mode of operation
  • facilitate processes whereby business transformation can be more effectively planned and executed

In so doing, those fulfilling this role will contribute to developing greater self-awareness as an enterprise, to more effective development, and hence to enhanced performance, viability and sustainability of the enterprises of which they are part.

Project success?

enterprise-modelingLeave a comment


The following questions are some of the questions that prompted this article:

  • How do we determine whether a project has been successful or not?
  • Is coming in on-time and on-budget a reasonable measure of success?
  • Do 70% of change projects fail?
  • Do 70% of IT projects fail?
  • Is there any relationship between project failure rates and business strategy failure rates (where the latter is purportedly anywhere between 80% and 98%)?

Let’s explore some of these questions, noting that:

  • we have not conducted any form of extensive survey
  • any such survey may have dubious results and be of little value

What is being measured?

It is important to explore and establish clarity about what we are seeking to measure.  Is success about:

  • the project activity?
  • the project deliverables (or output)?
  • the project outcomes?

Many articles and organisations seem to focus on measures such as project cost and timeframe (on-budget and on-schedule).  These are simply measures of project activity, and such measures prompt some interesting questions:

  • If a project exceeds budget, is that a good or a bad thing?
  • If a project exceeds budget, does this indicate poor project execution or poor project planning?
  • Is it worth making the effort to “deliver on budget”?
  • If a project was under-estimated and is delivered on budget, what quantity or quality of output has been forgone?

Project Model

The following model can be used to help understand the different measurements that can be used to assess programs and projects.

Project-model

A project takes inputs and delivers outputs which are used by the customer to achieve outcomes.  The project will proceed within an environment and be subject to appropriate governance.

Project measures fall into three broad categories:

  • Inputs
  • Outputs
  • Outcomes

When we measure costs and time, we are measuring inputs.  This tells us nothing about the quantity, quality, utility or value of the outputs.

When we measure products and deliverables, we are measuring outputs.  This tells us nothing about the utility or value of the outputs ie. the benefits and outcomes realised from using the outputs.

Implications

So, when we report that a project has failed because it exceeded budget and/or schedule, this is simply reporting on the quality of our estimates and on our management of inputs and use of resources.

Projects are undertaken to achieve outcomes.  Project success needs to be measured in terms of expected and unexpected outcomes that are realised.

When we start projects, we identify outputs and outcomes, and explore:

  • what constitutes success?
  • how would we recognise success?

These are the measures that we need to use, not at project completion, but some time after completion to allow time for the customer to start making effective use of what we have delivered.  Then we can evaluate the degree to which we have been successful.

Next time

… you hear about a project failure, take a closer look at what is being measured and decide whether the “real success” of the project is being measured or not

… you hear someone challenging myths about project failure, take a closer look at what is being measured and what they are proposing as alternate measures

… you are commencing a project, take the time to explore how you will determine whether:

  • you have adequately defined your targets
  • how realistic your targets are
  • you have a clear baseline against which to measure progress towards your targets

Then you will have a better basis for measuring project success.

 

Business model maturity

enterprise-modelingLeave a comment

desel_051

The core model that most people use to explore and articulate the motivation, offerings and capabilities required to pursue an enterprise is the business model. This article explores our perceptions of the evolution of the business model artefact through four phases which we have named as versions (1.0, 2.0, 3.0 and 4.0).

Business model 1.0

This “version” encompasses the origins of business models, which were financial models reflecting the expected revenues for products and services being offered, the expected costs of producing, distributing or providing, and maintaining the products and services, and the resultant profits realised as a return on the investment made in establishing and operating the proposed business.

business-graph-with-arrow-showing-profits-and-gains_MyZdKgKd_L

This model would be reviewed and revised as:

  • opportunities or threats emerged in the market
  • product / service offerings could be extended, refreshed or reduce
  • improved efficiency and effectiveness needed to be or could be pursued

Business model 2.0

The next version emerged in the dot.com era and was formalised by Alex Osterwalder in his work and articulation of Business Model Canvas. This work established an ontology for the business model, in terms of the domains of information that required attention and articulation, covering:

  • Customer segments
  • Channels
  • Relationships
  • Key capabilities
  • Partners
  • Cost structure
  • Revenue streams
BMC

This ontology and associated tools have seen widespread adoption, with consulting services available to support startups through to large corporates in developing an expression of their business model(s).

Business model 3.0

This version takes the concepts in Business Model Canvas and extends them further based on a systems view of an enterprise and the environment in which it operates.

This encourages greater attention to the enterprise-as-a-system and the enterprise-as-a-part-of-broader-systems. In doing so, attention is given to:

  • the broader value chain of which an enterprise is part
  • the potential for enterprise suppliers to provide services directly to enterprise-customers (circumventing the value proposition of the enterprise)
  • the creation of new market dynamics through adoption of market platforms, shared economies and other market disruptions

This evolution explores these dimensions as they apply to the dynamic relationships which exist in the market environment, as shown in the following figure.

Systemic-business-model

Business model 4.0

The fractal application of business model might entail development of the business model for:

  • an organisation
  • a marketing capability
  • a production capability
  • a supplier chain capability
  • a corporate wide capability (eg. people management)

exploring the dynamics arising from the application of business models to enterprise-subsystems, enterprises-as-organisations, and multi-organisational enterprises.

Fractal-business-model

In practice, this requires an iterative approach:

  • to the application of business models and operating models
  • each component of the operating model being considered an enterprise-in-focus to which the next level of business model and operating model is applied

which effectively constitutes an objective – strategy cascade where:

  • business model establishes the objective(s)
  • operating model establishes the strategies

Maturity

Use of these models can be considered in terms of maturity, starting with a simple financial model (level 1) and eventually maturing to integrated application from individuals to the Board (level 4).

At what level of modeling maturity:

  • do you operate as a leader for your role and your team?
  • does your organisation operate?
  • does your industry or region operate?
  • does your nation operate?

This outlines the essential elements of the manner in which business model development is applied in any circumstance that we encounter.

 

Architectural sufficiency

enterprise-modelingLeave a comment

This article is a republishing and updating to reflect some thinking which emerged in the comments when the original article we published in early 2016 – here is a link to the original article

One of the questions that I posed in the opening posting of the series that I started at that time was:

How would we go about describing the current or intended architecture of our enterprise?

Common models and views

In another posting about conventional practices, I indicated that the development of organisational charts and position descriptions were one of the current practices undertaken in many enterprises.  What other models and views do we develop to describe the current or intended architecture of an enterprise?

The next most common model and associated views is the process model.  This can be prompted by a range of motivations, including:

  • A continuous improvement program which encompasses the progressive development of process models for various subsystems within the enterprise
  • A quality management program, potentially in conjunction with adoption of standards within the ISO 9000 series, where the Corporate Management System or the Business Management System provides shared access to the processes developed to ensure a consistent approach to deliver of quality products and services
  • An information systems or IT system program which is establishing improved processes and/or IT enabled processes which need to be described to support the design and realisation of the proposed system

In the latter case, it is likely the information models and views will also be developed to reflect the way in which the shared information is to be organised, managed and accessed.

Key dimensions

What other dimensions of an enterprise are part of its architecture description? Various models suggest the following dimensions are encompassed:

  • People / roles / organisation units
  • Process
  • Information
  • Assets (offices, plant, equipment)
  • Finance
  • Information and communication technology (ICT)

These seem to be the primary:

  • resources
  • integration points

which can be encompassed within an architecture which has a focus on elements and relationships which are fundamental to the enterprise-as-system.

Other elements

There are other elements which are not owned and controlled and hence not designed and architected which feature in architecture descriptions, as there is a need to understand relationships, flows and interactions, both internal and external.  Hence, architecture descriptions will reference external entities, including:

  • Customers and consumers
  • Suppliers
  • Partners
  • Competitors
  • Regulators

This is an important feature of architecture descriptions and enterprises.

An architecture description includes reference to entities and relationships beyond the bounds of the enterprise

This has proven to be a point of considerable debate and confusion surrounding what I perceive to be the failure to appreciate the distinction between the scope of the enterprise and the scope of the architecture description.  The latter must convey information about the enterprise-as-system “in its environment” and necessarily includes entities beyond the scope of the enterprise.

Sufficiency

Do we have a sufficient coverage of entities and relationships to encompass the description of the architecture of our current and intended enterprise?  Are these sufficient?

The ultimate test, based on ISO 42010, is whether these provide all the necessary elements to address stakeholder concerns arising in considering the current or intended architecture of an enterprise.  In my experience, these have been sufficient.  I leave the question open as others may find my list incomplete.

With these foundations, we can now explore the models and views which seem to prove most useful across the range of architectural engagements in which I have been involved.  This draws me back to elaborating further on a number of the models that I listed in the posting about the elements of architecture descriptions, including:

Postlude

A key message in this posting on current practices is exactly what Doug McDavid said in a comment.

Executives and Managers create various elements of the architecture description already.

They are prescribing and describing the architecture, whether they realise it or not and whether they call it architecture or themselves architects, or not. What I have not said explicitly, but is implicit in this series, is in line with his linked article, is that aspects of the architecture become evident in various enterprise documents, and therefore can be discovered and, if necessary, made more explicit.

For example, principles are often implicit in business language and business documents, but few enterprises make the principles underpinning their enterprise explicit. Similarly, language and key concepts, commonly found in enterprise documents, may well reflect important elements of process and information architectures. A couple of colleagues have experimented with tag clouds as a tool for more rapidly identifying elements of the enterprise ontology.

A number of articles will be written over the next few weeks, expanding on key principles underpinning the practices that I have found most effective in supporting Directors, Executives and Managers to better architect their enterprises.

 

Organisations and enterprises

enterprise-modelingLeave a comment

Many words have been written and many said about organisations and enterprises, and the extent to which they are the same or different.  This article is prompted by a current “debate” over the meaning of “enterprise” and a suggestion that “enterprise” is distinctly different to “organisation”.  I am not so sure about that!

So, this is part of my “normal process” of “thinking out loud” – an approach where I:

  • outline what I currently “think”
  • refine what I think in order to express it in a clear and coherent manner
  • expect to be challenged
  • am offered the opportunity to refine my thinking, based on the questions and challenges arising from articulating my thinking

For me, this is the way I have become better at understanding, articulating and practicing the disciplines of architecting enterprises, governing enterprises, becoming more systems savvy, and of recent times, becoming more brain savvy.

Organisations

In using this term, it is important to distinguish between organisations and legal entities.  Oftentimes, when I think of organisation, I am thinking of:

  • a commercial firm
  • a government department
  • a community entity

This pertains more to the legal status of the entity and to the basis upon which it is constituted, managed and governed.

In this discussion, whilst it includes all of these types of organisations, I am including other forms of organisation, including:

  • an organisational unit
  • a cross-functional team
  • a multi-organisational operation
  • a community
  • a region
  • an industry
  • a profession
  • a project
  • a program

Each of these groups have:

  • membership
  • bounds
  • shared interest and purpose
  • varying degrees of linkage and relationship
  • an existence for some period of time
  • some form of means by which they are “organised”

So to the definition of organisation

an organised group of people with a common purpose

Enterprise

A number of blogs have been written on this topic already, including:

In summary …

an enterprise is most easily understood as an undertaking or an endeavour

Context

Given a systems view of organisations and enterprises, it should not be surprising that there is a need to consider system context, including:

  • the market or environment in which the organisation, enterprise or system exists and operates
  • the economy, community and society within which the market and environment exists

Any organisation, enterprise or system will need to:

  • give attention to entities in these broader contexts
  • understand the relationships that exist or should exist, both
    • across the organisation / enterprise / system boundary, and
    • amongst entities in the external environment
  • adapt the structure and behaviour of the enterprise, both
    • in light of changes in the external environment, or
    • in order to shape and prompt changes in the external environment

These activities are evidenced as an inherent part of organisations through:

  • governance processes (attending to accountability and strategy)
  • intelligence processes (informing the organisation of activity in the external environment)
  • marketing processes (understanding changes and opportunities in the external environment)
  • supplier, partner, customer / consumer, regulator and other stakeholder relationship management processes (providing direct knowledge and understanding of key external relationships)

These represent the means by which organisations attend to life-beyond-the-organisation and about which organisations develop enterprise models to enable them to understand, architect and realise their intended business models and operating models.

In this respect, the business model is the key artefact which prompts understanding and articulation of the balance required between internal and external affairs (so to speak).  Further articles outlining key thinking and practices in this area, include:

Enterprise concept and views

There are a range of benefits that I see arise from taking an enterprise view of an organisation, including:

  • organisation tends to prompt a people / role based view
  • enterprise encourages a purpose and process view
  • enterprise allows the balancing of multiple views including:
    • strategic views
    • process views
    • role / responsibility views
    • information views
    • facilities / location views
    • service views (composite of internal and external sourcing)
    • integration views
  • enterprise provides an abstraction from the connection to organisation and the threat that arises in considering organisational change
  • enterprise enables views that are agnostic to a particular dimension

For me, there is incredible value in taking an enterprise view, but none of the value derives from viewing organisation and enterprise as distinctly different.  Perhaps the following is a reasonable way to summarise?

Enterprise is an abstraction that is orthogonal to organisation

 

Bringing it all together

enterprise-modelingLeave a comment

STORYB~1.JPGOver the last two and a half years, I have written and published over 50 articles which relate to architecting and transforming enterprises.  These have been published on LinkedIn and an index of all articles maintained in the article “Architecting Enterprises“.

About twelve months ago, I started copying these articles across to this blog site.  As I did that, I published a post on LinkedIn which proved to receive far greater views than many of my original articles.  In parallel, Interface Consultants started holding public Lunch’n’nLearn events where I was using content from these articles in sessions on:

  • Curious about being more brain and systems savvy
  • Bootstrapping a systems savvy enterprise
  • Cultivating capabilities
  • Diversity, coherence and assurance (for Boards)

Reflecting on the development of these sessions and on feedback from these sessions, it became evident to me that participants in these sessions and readers of this blog need a sense of:

  • the whole story and how the fifty (or more) articles fit together
  • how to find the pieces of the puzzle that are missing without need to read all the pieces that they already know and understand

This is how the process of “bringing it all together” started.  It has led to:

Further content is being developed and will be released.  I hope this becomes an increasingly convenient, easy-to-use, valuable resource for those involved in transforming their enterprises and looking to advance their mastery of this highly rewarding activity.

Feedback on the articles and on this initiative to “bring it all together” is always welcome.  Please feel free to post comments or to contact Interface Consultants or Peter Murchland if you wish to respond privately.  These articles are also used to prompt discussion in the related LinkedIn Group – Enterprise Modeling

 

Enterprise design mantras

enterprise-modelingLeave a comment

mantra-om-mani-padme-hum_zkPVd0Lu_L

What mantras do you find underpin your AE practices? Are there particular principles or guidelines that you remind yourself about or that you share with others in your team and amongst your stakeholder community?

Here are some of the mantras that I find myself repeating …

  • Keep the end in mind
  • Business process not system process
  • Continuum between autonomy and control
  • What is the system-of-interest?
  • What constitutes success?

Keep the end in mind

Many of us are trained to determine our objective and then explore the strategies for achieving the objective – determining the ends and exploring the means. So what is important about this mantra? Isn’t it a natural part of our daily practices?

Many years (actually decades) ago, I read “I’m right, you’re wrong” by Edward de Bono. I gained a number of insights from that book, but the most frequently referenced insight was:

creative ideas are logical in hindsight

This insight is important to solving problems and to learning. Once solved or learned, the problem seems simple. This can also mean that a solution can be more easily understood by working backwards rather than forwards.

This simplicity is often overlooked when we present the problem and solution to stakeholders. It all seems logical to us but can seem puzzling and difficult to our audience. This applies in many different scenarios, including many of the business improvement or business transformation undertakings I have encountered.

It was recently brought to mind and reinforced by a colleague sharing that they read books backwards – last chapter first. Another practice is that of describing what I aim for meeting participants to have gained at the end of the meeting – shared understanding, agreed actions, etc. This often helps construct are more effective sequencing of the agenda.

clarity in relation to goals, deliverables, and outcomes

has proven to be a valuable practice – keeping the output and outcome in mind as we design and plan our way forward.

Business process not system process

I have lost count of the times that I have encountered IT projects where the focus is on the IT system and not on the business objectives which the IT system should be designed to support.

Indicators of an inappropriate focus include:

  • A project scope expressed in system function terms rather than business terms
  • A “process” diagram which is focused on the interactions with the system and the “system processes” without attending to the “business processes and practices”
  • A project with system deliverables and few or no business deliverables
  • A project which regards business change as “out of scope”

Practices which have proven to prompt greater clarity and quality include distinguishing between:

  • business objectives, system objectives and project objectives
  • business scope, system scope and project scope
  • business processes and system processes

The first two areas typically apply in the initiation stages of a project, where as the third arises at various stages in the project, and hence is the distinction that is more frequently made (and needed).

Balancing autonomy and control

For any situation where alternate processes or means are being considered to achieve an agreed objective, consideration often needs to be given to the nature of the circumstances and the type of action or response that might be needed.

For example, if the situation entails lots of variability and unknowns, then it is likely to need a person to determine the nature of the situation as well as the appropriate action. Significant autonomy should be given to a person to determine and take the appropriate action. This is typical of situations that are described as being “knowledge work”.

There are other situations where it is possible or it is necessary to be prescriptive and for specific consistent action to occur. Situations such as ensuring consistent counting rules are applied to an information set, or where financial transactions need to be processed in a consistent manner. These situations call for appropriate control to be applied, with no need for flexibility or autonomy.

Redesign of processes requires careful consideration to the areas where autonomy versus control is required and how to design a process to achieve the appropriate balance and combination of these responses.

Be clear about the system-of-interest

Enterprises are complex. Enterprises can be viewed from the perspective of being a system-of-systems.

If one considers a system-of-systems, we have the situation where:

  • the whole is a system
  • the parts are each systems
  • some parts may be systems-of-systems

In addition, there are human activity systems (social systems or soft systems) and technology based systems (machines, computers, etc or hard systems). Given the pervasive use of IT systems, many times “system” is taken to be a synonym for “IT system”, making it more difficult for some to consider the “system” being a social system or socio-technical system.

If systems based views and techniques are to be applied successfully, it is important that those engaged are considering the same system – that the system-of-interest is clear, as it may be part of a containing system, and it may be composed of parts-as-systems. Oftentimes, I have found that the differing views or confusion being experienced in analysing or diagnosing systems has arisen because different stakeholders are holding a different system as the focal point.

Being clear about the “system-of-interest” or the “system-in-focus” ensures that the differences emerging arise from different perspectives, perceptions and conceptions of the system-of-interest, and not through a difference in the point of focus.

What constitutes success?

This is a valuable question that I learned as a Director on a Board, but is equally applicable in other settings. Similar questions are sometimes asked such as “What does good look like?”

Such questions draw us to being clear about outcomes such that then we can consider the differing outputs that might be required to realise the outcome and the alternate processes (and strategies) which might be pursued to deliver these outputs.

Exploring enterprise lifecycles

enterprise-modelingLeave a comment

Wherever an enterprise engages in architectural activities, there are three key lifecycles which come into play:

  • enterprise operations, managing the entire lifecycle from prospective customer to satisfied customer
  • enterprise development, managing strategy, innovation and change, delivering and embedding new or improved capabilities within enterprise operations
  • enterprise architecture, managing the structures and principles through which enterprise operations and development are effected

Enterprise-development-1

Any engagement needs to assess:

  • the current position within these three key lifecycles
  • the maturity of the organisation with respect to each of these lifecycles

in determining where to direct efforts to deliver the greatest value to the organisation.

EM_journey_v0-15

In this respect, the approach shown above for architecting enterprises provides an effective mechanism for managing each of the lifecycles, prompting an assessment and appreciation of:

  • vision
  • future directions
  • capability gaps
  • initiatives addressing gaps
  • program (roadmap) of activities in train

This could lead to three inter-related capability development cycles for maturing the enterprise architecture capability, enterprise development capability and enterprise operations capability.

Enterprise-development-2

Where is your organisation placed in terms of its architecture, development and operations maturity?

To what extent does your strategy development take account of your maturity in these three domains?

To what extent does your program planning and execution explicitly take account of these differing levels of maturity, including:

  • delivery risks arising from varying maturity levels?
  • adaptive approaches which allow for the necessary enterprise learning required for successful delivery?
  • synergies which can be pursued to leverage investment and effort towards enhancing maturity in all three domains?