#eavoices

We Ought to Know the Difference

by

Is systems thinking really possible? Here’s one reason why it might not be.

One of the concerns of systems thinking is the need to avoid the so-called environmental fallacy – the blunder of ignoring or not understanding the effects of the environment of a system. This is why, when systems thinkers are asked to tackle a concrete situation in detail, they often hesitate, insisting that it is wrong to look at the detail before understanding the context.

The trouble with this is that there is always a larger context, so this hesitation leads to an infinite regress and inability to formulate practical inroads into a complex situation. Many years ago, I read a brilliant essay by J.P. Eberhard called “We Ought to Know the Difference”, which contains a widely quoted example of a doorknob. As I recall, Eberhard’s central question is a practical one – how do we know when to expand the scope of the problem, and how do we know when to stop.

C West Churchman went more deeply into this question. In his book The Systems Approach and its Enemies (1979), he presents an ironic picture of the systems thinker as hero.

If the intellect is to engage in the heroic adventure of securing improvement in the human condition, it cannot rely on “approaches,” like politics and morality, which attempt to tackle problems head-on, within the narrow scope. Attempts to address problems in such a manner simply lead to other problems, to an amplification of difficulty away from real improvement. Thus the key to success in the hero’s attempt seems to be comprehensiveness. Never allow the temptation to be clear, or to use reliable data, or to “come up to the standards of excellence,” divert you from the relevant, even though the relevant may be elusive, weakly supported by data, and requiring loose methods.

Like Eberhard, Churchman seeks to reconcile the heroic stance of the systems thinker with the practical stance of other approaches. But we ought to know the difference.

This is an extract from my eBook on Next Practice Enterprise Architecture. Draft available from LeanPub.

John P. Eberhard, “We Ought to Know the Difference,” Emerging Methods in Environmental Design and Planning, Gary T. Moore, ed. (MIT Press, 1970) pp 364-365

See extract here – The Warning of the Doorknob. The same extract can be found in many places, including Ed Yourdon’s Modern Structured Analysis (first published 1989).

See also

Nicholas Berente, C West Churchman: Champion of the Systems Approach

Jeff Lindsay, Avoiding environmental fallacy with systems thinking (December 2012)

Updated May 14 2013

Power, Process, Project, People – The Effect

by

Finally I find the time to write another post and continue my series about Power, Project, Process and People. As a small summary here a oneliner about each of the three forces:

  • Power is about control and authority which limits people.
  • Process is about faster, higher and stronger which spins people faster. 
  • Project is about moving which changes people.

All three forces together can have a quite severe impact on on people. Literally they force people to change faster and faster while limiting them.

 


So what is the chances to escape? Actually there is three typical ways to escape for each individual person:

  • Increase the power by climbing the hierarchy.
  • Forcing others to spin faster, higher and stronger by becoming process owner.
  • Forcing others to change by executing projects.

The easiest way to escape lies in executing projects, be it as internal or as external. Being good at project execution protects people against being forced to change themselves, because the methodology on how the project was executed can be used again and again and again without adapting much. Furthermore if implementing a specific solution that very same solution with small adaptions can also be implemented many times in a row allowing to not change while those who are affected by the project must change.

Being really strong in one methodology sometimes opens up for the chance to become process owner, which is great, because it allows to let other people spin faster (and higher and stronger), while the own speed more or less remains the same (except if the process owner of process management really makes process managers spin faster).

Rising in the hierarchy is the option in which typically the people are interested most. First of all it is the option which has the highest chance to increase income significant. And it is (and makes) attractive, because it gives direct power over others.

The interesting (and potentially relevant) observation I make in most cases is that one who is advancing either in Project, Process or Power terms is normally picking up the behaviour of who was leading him in respect to that particular force. It takes some time to free up and leave the old approaches behind and actually many who are in the position to control one of the forces never advance.

Launching an Enterprise Architecture Program within State, Local, Municipal Organizations

by

By Gloria Chou

When launching a formal EA program, Government organizations often begin by socializing the overall benefits of EA and developing an EA Charter and Plan.  However, while both of these are valuable, they are more useful as part of after-the-fact documentation and communication plans.  Having worked with a broad spectrum of government organizations across the US and Canada, our team, Oracle’s Public Sector Enterprise Strategy Team (EST), has found that the first and primary focus in launching an EA program should be on how to meaningfully engage top business leaders and other stakeholders to discover their needs, identify what would bring the most value to the organization, and obtain their buy-in and support for EA as a key enabler in helping the organization achieve its mission objectives. 

Why is launching (or re-launching) and EA Program relevant in the government space today?  Although state and local agencies may have had an EA team for years, many are just getting started on formalizing their practice and creating awareness of the team’s capabilities and purpose within the organization as a whole – though some are in fact successfully delivering Agency-wide Enterprise Architecture value.  Additionally, while a majority of Federal agencies have necessarily had established EA programs for over a decade in response to Clinger Cohen mandates, some are beginning to reshape their programs as they perceive the need to go beyond checkmark/compliance-based EA and demonstrate additional value to their respective organizations.  Governmental budget pressures are increasing the scrutiny on all resource allocation and deployment such that EA programs must stay relevant and drive acknowledged and desired benefits or else risk being cut.

I believe discovery and dialogue with executive leadership about their goals, objectives, strategies, and current planning processes has to come first as, only after this is known, can the team understand what is particularly valuable to the specific organization.  Too many Government EA programs seek to provide generic value and benefits, such as standardization and integration, that, while good aims in and of themselves, are not necessarily prioritized by the organization nor sometimes even compatible with their operating model and culture.  As a case in point, when working with a very large municipality in the West, the EST began discussing EA with a new, forward-thinking CIO who had been three months into establishing an EA program to change the way IT was viewed across the organization.  We had an initial meeting with the lead EA and found that the new EA team had been doing the expected: technology architecture current state analysis and building IT standards documents.  After three months, the team was well on their way to spending another year or more on documentation!  The question we posed was, how does this change the way IT is viewed across the organization? The answer was clear, it didn’t.  Understanding specific needs, gaps, and opportunities that the executives care about is essential to ensure EA is relevant and focuses on what the business needs to successfully execute on its strategies.   

Based on this understanding of the organization’s priorities and what would bring the most value, the EA team should analyze what needs to be done and propose how they can be a part of the solution.  In the example of the large municipality mentioned above, the EST helped the organization’s EA team identify areas of opportunity to engage with business leaders across the organization and facilitate meetings to better understand strategies, goals, capabilities and high-level value streams.  By starting here, we were able to get the EA team on a path to make better decisions on where they would invest their time to provide the most value to the enterprise.  As a part of this, the team needs to assess their own capabilities and competencies as well as that of other teams within the organization against what is needed and propose options as to how they might best help the organization and what other changes might be needed to achieve the organization’s goals.  In actuality, an EA approach would help facilitate this analysis and assessment of how EA itself could benefit the organization.  The team should consider developing the vision for change as well as current state and future state views of operations, analyzing the gaps, and developing recommendations and a roadmap for the successful introduction of EA into the organization.

Only after the recommendations have been presented, vetted, and selected by leadership should the team document the EA purpose, application, and approach.  While this information can be captured in the EA Charter and Plan, it only represents a part of the needed content.  The rest, especially the plan, can only be developed after seeking input from other stakeholders in the organization.  Even though the executives have weighed in with their input, direction, and approval, it is still often difficult to get an EA initiative started because so many other stakeholders also need to be convinced of the value.  For example, LOB leaders, business managers, and functional SMEs all have to be convinced of the value of EA or else they will not allocate the time and resource required to participate in facilitated sessions and verify/validate the architecture.  Executives and LOB leaders are critical in setting the vision for the future and describing the general goals for operations as well as communicating their overall investment and technology strategies.  However, even if the executives and leaders buy-in, the lower levels also have to perceive value/benefit or else they will put in minimum effort when you really need them to be fully engaged to provide detail as to the reality of operations, challenge the status quo of how things are done today, and ultimately take ownership of the architecture and support the transition to the future state.  Without the business fully on board, the EA recommendations and transition look good on paper but will never be executed. 

Similarly, other stakeholders including Corporate Strategy, Portfolio Management, Project Management, Lean/Six Sigma, and IT also need to fully support EA as they are also critical in the development, execution, and enforcement of EA.  The stakeholders in these other disciplines sometimes feel that EA encroaches on what they do and do not understand why it is necessary.  For example, Lean/Six Sigma practitioners and some business analysts already have great relationships with the business and have already documented and analyzed processes such that they believe they have already “modeled the business” such that EA business architecture development and analysis is extraneous.  IT organizations often point to their UML diagrams, systems engineering drawings, and infrastructure server drawings and say that they are already doing EA.  In seeking buy-in from these other groups, it is very important to first seek to understand and acknowledge the current state of operations – existing skills, processes, and assets – before proposing a future state of how EA enhances/complements.  Formal stakeholder analysis and RASCIs can be helpful, but I believe an attitude of respect for what others do and a collaborative approach is also critical as there are many organizational change issues and related sensitivities associated with introducing EA as a discipline as with any other transformation.  Once general buy-in and support for EA is established, the disciplines need to work out details around overall processes, governance, timing, inputs and outputs to understand synergies, cooperation, etc.  Again, this is something that can be documented via EA, further decomposing views that were used in the overall analysis for the introduction of EA.