Bringing it all together

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

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

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?