#eavoices

Rhizome: On Dilemmas in Enterprise Architecture Planning

by

In the field of IS and management we often put forward a certain conception of the organisation, the social. In contemporary business consulting and management academia, the organisation is often conceptualised as a hierarchical open system with a certain body of knowledge supplying the management system with rational decision making. Other alternative, academic approaches are influenced by literature studies and Gadamer’s hermeneutics (Gadamer, 1975), promoting the need for understanding and context, the particular, rather than the universal and manageable. Emerging from these two spectra, each fighting for their own conception of subjectivity and objectivity, Anglo-Saxon and continental philosophy, each defining the criteria for truth and meaning, one uncovers systems theory and cybernetics which proposes a model for generalising structures and properties between different phenomena in the world: Bertalanffy (Bertalanffy, 1969) suggests a unified cybernetic model for living, mechanic, and social systems, whereas von Foerster (Von Foerster, 2003) and Luhmann (Luhmann, 1995) suggest a second order model based on constructed observation and interpretation. In organisation studies, first and second order systems theory each postulate their own conception or construction of social reality: Parsons defines the social as actions or events referring to each other within a structural organising of social functions, whereas Luhmann flips the tin can with a functional organisation of social structures based on communication, reproducing and sustaining itself through Maturana and Varela’s concept of autopoiesis (Maturana & Varela, 1980).

Amidst IS management’s–and thus EA’s–attempt to establish a common, trans-disciplinary foundation for research, there appears to be an ontological schism of what the social is and organisations really are. Is it a collective intelligence or logic of rational decision making? Is it a reactive, intersubjective collective attempting to make sense of the world in hindsight through history and culture? Or is it a system or a construction of a system that organises, structures, or communicates through constant adaption and recursive reproduction only by reference to its own recursion and reproductivity? The latter approach dissolves the former two boundaries by creating a boundary of distinction even more important than the understanding subject itself at the edge of every possible system. It is the distinction between system and environment that generates or fabricates meaning and truth, but it comes at the cost of reducing our very own processes of cognition and sensemaking to a set of vibrating antennas or satellites mounted at the fragile surface of every human system.  

An ontology of the social is thus far from complete. Enterprise Architecture (EA) seeks to address this by building layers of abstraction and control, thereby assuming that static systems models of socio-technical relations yield manageability and transparency. Accountability is achieved by linking formal role descriptions to process models and system landscapes, often positioned in a well-defined hierarchy and stored in a database repository for later reference and reuse. In order to reuse ‘best practices’ and assure a certain level of maturity in framework and methodology, enterprises often implement their architecture practice against existing reference frameworks and enterprise meta models. Frameworks such as FEAF even include a CMMI-like maturity model for EA, which assesses the success of architecture program by measures such as completeness and integration. OMB, the US Federal Office of Management and Budget, has furthermore published a set of measures of architectural completeness for evaluating US Federal Agencies. The highest achievement, level 5, is the architectural utopia in which the organisation practicing EA corrects its own business failures by architectural inspection. Architecture is here synonymous with optimising an organisation.


Given the above reflections on what the social really is, is it really philosophically reasonable to suggest that a stable, decomposable, hierarchical model, which most enterprise meta-models really are, is capable of building a comprehensive model of the social? Is it really meaningful to stretch virtually any organisation, be it government or private, along a five-level diagram and measure it by how well-described architectural elements are? And what happens when the Federal agency hits the ceiling after 5? Those are clever and important questions that information and organisation science ought to ask. Unfortunately, that is seldom the case. Maturity models, in the classic form of a five-step ladder, are an inherent part of any contemporary management/IS theory: process maturity, architecture maturity, service maturity, integration maturity. The five-step Capability Maturity Model (Paulk, 1995) has its roots in systems engineering carried out by engineers building space shuttles for NASA. As universal as it may be, the problems, issues, and solutions faced by modern organisations are far more muddy, messy, an ill-defined than those originally faced by defence contractors and DoD bureaucrats. Such fast-paced, deep problems are also characterised as wicked problems (Rittel & Webber, 1973):
  1. Wicked problems have no definitive formulation. One can infer that the problem exists, but will never be able to fully document the problem.
  2. The solution to a wicked problem is “good or bad” not “true or false”.
  3. Every possible solution is a one-shut operation as every solution attempt will leave a trace which cannot be undone.
  4. Each wicked problem is unique and may eventually be the symptom of another, underlying wicked problem.
Through my previous research, I have suggested a systems theoretical approach towards understanding and explaining EA. Systems theory is helpful towards describing the messy complexity of social and communicative structures. Second order systems theory adds a rich, dynamic theory for understanding communication in- and outside organisation by describing the exchange of utterances between human actors in search of meaning (Jensen, 2010). I believe, however, that these two key conceptions of enterprise planning and governance can furthermore be extended into a general theory of EA by including Deleuze’s theory of the rhizome.

Deleuze (Deleuze & Guattari, 1988) describes the rhizome structure (Deleuze & Guattari, 1976) as a meaningful alternative to uncovering complex structures, be they social or biological. Western society, Deleuze explains, has built its historicity and philosophy on the basis of binary structures: true-false, yes-no, top-bottom, maturity-immaturity. Contemporary EA frameworks are, in fact, highly binary: layers separated by clear boundaries, processes with a start and end, structured organisation charts and capability maps with a top and bottom. The rhizome is a viable alternative since it assumes an inherent complexity of what it is intended to describe. The rhizome is constantly transforming and morphing itself, making it virtually impossible to map out its structure completely at any point in time. This is exactly how wicked problems occur. Wicked, messy problems could, in fact, be described as rhizomatic structures. The rhizome structure applies well to the socio-technical nature of organisations as well, as the dissipative relationships between humans, technology, and organisation structures form a complex, dynamic, and transforming entity with no clear, formal, or necessarily logical order. This rhizomatic relationship is probably best explained in the field of technology adoption and diffusion in private enterprises where traditional positivist approaches to management and innovation struggle to explain how and why technology trends emerge and behave. This reflection on Deleuze leads to the following important claim:

Organisations are complex, dissipative structures constantly transforming complex, human knowledge and social relationships. A rhizomatic systems model satisfies such conception of organisational reality. Hence, Enterprise Architecture, in its search for whole-of-enterprise views, should adopt rhizomatic theory for uncovering and understanding the true messiness of organisations as socio-political habitats.


Understanding Enterprise Architecture as a rhizomatic systems practice, however, must come at the cost of killing certain darlings. The first darling is the idea of organisations as stable structures operating on explicit, verifiable knowledge, which in turn can be divided into clear architectural layers and segments. The second darling is the conception of a universal maturity model explaining the natural progression towards “EA nirvana”. There is no such one.
  1. Layers, segments, and hierarchical models depart from a Westernised, binary view of the world. Layering suggests decomposability and abstraction of organisational complexity. A rhizome does not have such properties. The messy, social facets of organisational life cannot be decomposed or functionally abstracted. The social does not have a single function and thus cannot be functional. Wicked problems, as they emerge from social interactions and organisational problems, are rhizomatic and cannot be explained fully through rationalist models.
  2. Maturity models are inherently binary. They suggest a natural progression towards the optimal stage 5 somewhat similar to a tree as it stretches its branches towards the rising sun. The rhizome is the exact opposite of a tree structure as its roots and shoots grow and form in any direction, shrouding and shifting its original structure. Social structures, apart from the general statistical patterns uncovered by social psychology, do not follow universal laws of transformation or branching—and hence it is impossible and meaningless to suggest a generic, universalistic maturity model of social behaviour in EA adoption and planning. There is no such nirvana of Enterprise Architecture—and if there ever were, it would be constantly shifting and transforming depending on the current managerial climate, problems of planning, and struggle for control inside the organisation. Exactly this relationship of management, planning, and control is rhizomatic as well.

For Enterprise Architecture to fully explain these sacrifices, it must adopt a view of the enterprise as a non-linear, interconnected multiplicity, for which structures can only be meaningfully traced and described in hindsight. Traces always remain interpretations. Enterprise modelling involves tracing organisation structures, but as these structures are traced and interpreted, they suddenly shift and transform into a different multiplicity. Enterprise Architecture is thus a semiotic practice of tracing and interpreting organisations as complex signs. The output, the long-term plans, roadmaps, and meta-models, are merely simplified pictures of these dissipative signs. Only by accepting these aspects of enterprise reality, can Enterprise Architecture truly characterise the challenges and solutions in strategic planning and enterprise management.  

References:
Bertalanffy, L. v. (1969). General System Theory; Foundations, Development, Applications. New York,: G. Braziller.
Deleuze, G., & Guattari, F. (1976). Rhizome : Introduction. Paris: Éditions de Minuit.
Deleuze, G., & Guattari, F. (1988). A Thousand Plateaus : Capitalism and Schizophrenia. London: Athlone Press.
Gadamer, H.-G. (1975). Truth and method. London: Sheed & Ward.
Jensen, A. O. (2010) Government Enterprise Architecture Adoption: A Systemic-Discursive Critique and Reconceptualisation. Copenhagen Business School.
Luhmann, N. (1995). Social Systems. Stanford, Calif.: Stanford University Press.
Maturana, H. R., & Varela, F. J. (1980). Autopoiesis and Cognition : the Realization of the Living. Dordrecht, Holland ; Boston: D. Reidel Pub. Co.
Paulk, M. C. (1995). The Capability Maturity Model : Guidelines for Improving the Software Process. Reading, Mass.: Addison-Wesley Pub. Co.
Rittel, H. & Webber, M. (1973), `Dilemmas in a General Theory of Planning’, Policy Sciences 4.
Von Foerster, H. (2003). Understanding Understanding : Essays on Cybernetics and Cognition. New York: Springer.

On the Brink of Structure and Chaos: Framework Prescription and Real-World Flexibility

by
An often returning discussion with my clients is the practical applicability, boundaries, and presumptions of enterprise architecture (EA) frameworks. Following a recent debate on LinkedIn, some EA practitioners suggest that dynamic systems models, such as Stafford Beer’s Viable Systems Model (VSM) (Beer, 1994) , should actually replace existing prescriptive framework practices. In my own thesis (Jensen, 2010), I furthermore discuss the options of integrating cybernetic and second order systemic models in enterprise architecture planning and management on the basis of a thorough analysis of Australian government EA and SOA practice.

However, in this debate, it is important not to frame systems thinking as the silver bullet, which can magically and immediately fix all problems of management practice, be it process management or government architecture planning. Systemic thinking in itself may, actually, be overly prescriptive through reductionist assertions of how organisations function, e.g. through the claim: “organisations are systems” as opposed to “organisations behave as systems in particular situations.” Assuming that the world consists of systems as an ontological pre-given only paves the way for yet another prescriptive theory.

I usually tell my clients that there are two key observations around healthy framework and methodology practice. This basically boils down to admitting the following two claims:
  1. Best practice frameworks and reference models provide a great starting point and rational structure for beginning an architecture endeavour. Obviously, you don’t need to reinvent the wheel, and the frameworks provide a common language and conceptual platform for sharing ideas and implementing projects. Any good framework provides the tools, templates, and management structure for relatively quickly deploying the skeleton of an architecture practice. Prescription gives guidance, direction, and shared understanding of EA purpose and planning.
  2. However, prescription may also heavily limit the creativity and flexibility of rapid transformation projects. EA is often put in place in order to rapidly change the organisation for the better — or what Hjort-Madsen (2008) calls architecting for better outcomes. If the method is too inflexible or does not allow people to make shortcuts and rapid improvements for the better, it is a sign of too heavy prescription. Architecture turns into a handicap as opposed to providing a viable management reporting function. Architecture has transformed into a heavy-weight documentation exercise producing massive stacks of documents that nobody will ever return to again.
Good framework practice comes from finding the right balance between structure and flexibility. The framework must guide, direct, and support the architects at work so they can share and reuse where possible. On the other hand, the framework should promote and highlight the appropriate degree of managerial buffer in order to easily overcome problems and churn out creative solutions as opposed to locking down framework users by applying layers of managerial review and approval bureaucracy for the sake of (often unnecessary) traceability. As my thesis research indicates, an Australian state government agency chose to temporarily ignore their EA modelling and documentation framework whilst transitioning from current to future state.  Technological, political, and managerial changes occurred so often that the existing reference framework was simply too prescriptive. After reaching a point of reasonable stability in terms of business requirements and change in demand, it was then feasible to return to the structural stability and rigour of the framework.

My key message is therefore: be careful when implementing your architecture practice in your organisation. Your people need structure and guidance but also flexibility and buffer for overcoming changes rapidly in an elegant fashion.

Beer, S. (1994). Brain of the Firm (Classic Beer Series). Wiley.

Hjort-Madsen, K. (2009), Architecting Government: Understanding Enterprise Architecture

Adoption in the Public Sector, Phd doctorate.

Enterprise Architecture as Business Capabilities Architecture

by

"Why do enterprise systems like SAP fail in some companies yet succeed in others? Clearly, the interrelationship between technology and process, skills and culture was not taken into account." Dana Bredmeyer in Enterprise Architecture as Business Capabilities Architecture http://www.bredemeyer.com/pdf_files/Presentations/EnterpriseArchitectureAsCapabilitiesArchSlides.PDF

I’ve posted this

Creation of a strategy for the consumption and management of Cloud Services in the TOGAF Preliminary Phase

by

In a previous article I described the need to define a strategy as an additional step in the TOGAF 9 Preliminary Phase. This article describes in more details what could be the content of such a document, what are the governance activities related to the Consumption and Management of Cloud Services.

image

Before deciding to switch over to Cloud Computing, companies should first fully understand the concepts and implications of an internal IT investment or buying this as a service. There are different approaches which may have to be considered from an enterprise level when Cloud computing is considered: Public Cloud vs Private Clouds vs Hybrid Clouds. Despite the fact that many people already know what the differences are, below some summary of the various models

· A public Cloud is one in which the consumer of Cloud services and the provider of cloud services exist in separate enterprises. The ownership of the assets used to deliver cloud services remains with the provider

· A private Cloud is one in which both the consumer of Cloud services and the provider of those services exist within the same enterprise. The ownership of the Cloud assets resides within the same enterprise providing and consuming cloud services. It is really a description of a highly virtualized, on-premise data center that is behaving as if it were that of a public cloud provider

· A hybrid Cloud combines multiple elements of public and private cloud, including any combination of providers and consumers

image

Once the major Business stakeholders understand the concepts, some initial decisions may have to be documented and included in that document. The same may also apply to the various Cloud Computing categorisations such as diagrammed below:

image

The categories the enterprise may be interested in related to existing problems can already be included as a section in that document.

Quality Management

There is need of a system for evaluating performance, whether in the delivery of Cloud services or the quality of products provided to consumers, or customers. This may include:

· A test planning and a test asset management from Business requirements to defects

· A Project governance and release decisions based on some standards such as Prince 2/PMI and ITIL

· A Data quality control (all data uploaded to a Cloud computing service provider must ensure it fits the requirements of the provider). This should be detailed and provided by the provider

· Detailed and documented Business Processes as defined in ISO 9001:

o Systematically defining the activities necessary to obtain a desired result

o Establishing clear responsibility and accountability for managing key activities

o Analyzing and measuring of the capability of key activities

o Identifying the interfaces of key activities within and between the functions of the organization

o Focusing on the factors such as resources, methods, and materials that will improve key activities of the organization

o Evaluating risks, consequences and impacts of activities on customers, suppliers and other interested parties

Security Management

This would address and document specific topics such as:

· Eliminating the need to constantly reconfigure static security infrastructure for a dynamic computing environment

· Define how services are able to securely connect and reliably communicate with internal IT services and other public services

· Penetration security checks

· How a Security Management/System Management/Network Management teams monitor that security and the availability

Semantic Management

The amount of unstructured electronic information in enterprise environments is growing rapidly. Business people have to collaboratively realise the reconciliation of their heterogeneous metadata and consequently the application of the derived business semantic patterns to establish alignment between the underlying data structures. The way this will be handled may also be included.

IT Service Management (ITIL)

IT Service Management or IT Operations teams will have to address many new challenges due to the Cloud. This will need to be addressed for some specific processes such as:

· Incident Management

o The Cloud provider must ensure that all outages or exceptions to normal operations are resolved as quickly as possible while capturing all of the details for the actions that were taken and are communicated to the customer.

· Change Management

o Strict change management practices must be adhered to and all changes implemented during approved maintenance windows must be tracked, monitored, and validated.

· Configuration Management (Service Asset and…)

o Companies who have a CMDB must provide this to the Cloud providers with detailed descriptions of the relationships between configuration items (CI)

o CI relationships empowers change and incident managers need to determine that a modification to one service may impact several other related services and the components of those services

o This provides more visibility into the Cloud environment, allowing consumers and providers to make more informed decisions not only when preparing for a change but also when diagnosing incidents and problems

· Problem Management

o The Cloud provider needs to identify the root cause analysis in case or problems

image

· Service Level Management

o Service Level Agreements (or Underpinning contracts) must be transparent and accessible to the end users. The business representatives should be negotiating these agreements. They will need to effectively negotiate commercial, technical, and legal terms. It will be important to establish these concrete, measurable Service Level Agreements (SLAs) without these and an effective means for verifying compliance, the damage from poor service levels will only be exacerbated

· Vendors Management

o Relationship between a vendor and their customers changes

o Contractual arrangements

· Capacity Management and Availability Management

o Reporting on performance

Other activities must be documented such as:

Monitoring

· Monitoring will be a very important activity and should be described in the Strategy document. The assets and infrastructure that make up the Cloud service is not within the enterprise. They are owned by the Cloud providers, which will most likely have a focus on maximizing their revenue, not necessarily optimizing the performance and availability of the enterprise’s services. Establishing sound monitoring practices for the cloud services from the outset will bring significant benefits in the long term. Outsourcing delivery of service does not necessarily imply that we can outsource the monitoring of that service. Besides, today very few cloud providers are offering any form of service level monitoring to their customers. Quite often, they are providing the Cloud service but not proving that they are providing that service.

· The resource usage and consumption must be monitored and managed in order to support strategic decision making

· Whenever possible, the Cloud providers should furnish the relevant tools for management and reporting and take away the onerous tasks of patch management, version upgrades, high availability, disaster recovery and the like. This obviously will impact IT Service Continuity for the enterprise.

· Service Measurement, Service Reporting and Service Improvement processes must be considered.

Consumption and costs

· Service usage (when and how) to determine the intrinsic value that the service is providing to the Business, and IT can also use this information to compute the Return On Investment for their Cloud computing initiatives and related services. This would be related to the process IT Financial Management.

image

Risk Management

The TOGAF 9 risk management method should be considered to address the various risks associated such as:

· Ownership, Cost, Scope, Provider relationship, Complexity, Contractual, Client acceptance, etc

· Other risks should also be considered such as : Usability, Security (obviously…) and Interoperability

Asset Management and License Management

When various cloud approaches are considered (services on-premise via the Cloud), hardware and software license management to be defined to ensure companies can meet their governance and contractual requirements

Transactions

Ensuring the safety of confidential data is a mission critical aspect of the business. Cloud computing gives them concerns over the lack of control that they will have over company data, and does not enable them to monitor the processes used to organize the information.

Being able to manage the transactions in the Cloud is vital and Business transaction safety should be considered (recording, tracking, alerts, electronic signatures, etc…).

There may be other aspects which should be integrated in this Strategy document that may vary according to the level of maturity of the enterprise or existing best practices in use.

When considering Cloud computing, the Preliminary phase will include in the definition of the Architecture Governance Framework most of the touch points with other processes as described above. At completion, touch-points and impacts should be clearly understood and agreed by all relevant stakeholders.

Observations on Capability Driven Management

by

I’m finalizing my presentation for Business Ecology Initiative’s Optimization for Innovation conference slated for March 22nd in Washington DC.  Initially, I was approaching it as a humorous rejoinder on how to cope with taking the reigns of an or…

Stories That Move Mountains

by

In mid-2010 I held a series of training courses to cover many of the key techniques I’ve previously discussed on this blog. One attendee, Nick Malik, was in for his second time, the first being three years earlier. Another, Mark West, had been working with me as a contractor on a project. After the sessions Nick and I talked for a while and he suggested that I should write a book about the way I put the techniques together.

I’ve known various people over the years that have written books and it seemed like a lot of hard work, which with a day job I was not sure I wanted to take on. Move forward a month, Nick and Mark are now co-authors and we sat down to a few weekends of planning.

By October we had a plan, a chapter structure, even a name. By February we are well behind in the writing. Don’t let anyone tell you that writing a book is easy.

We have moved a long way though and I can certainly see we will be able to pull it all together. To help with the final miles of this marathon we have developed a web site where we can make a lot of the content available and also get feedback.

http://storiesthatmovemountains.com

All of the relevant blog posts from this site have been moved over and a lot more will now start to appear. This blog will now just focus on Enterprise Architect and IT topics.

Enterprise Architecture’s Obsession with Efficiency

by

Jeff Scott recently wrote a great blog "Is the current EA paradigm right for business architecture?"

http://blogs.forrester.com/jeff_scott/11-01-25-is_the_current_ea_paradigm_right_for_business_architecture

The comments section was full of erudite responses from several of the leading thinkers in EA. I’d like to pick up on two of the comments:

Tom Graves

"Most people seem to be obsessed by

Enterprise Architecture is Misplaced and Other News from MIT Research

by

Several interesting points that deserve their own blog posts, so this is just a conversation starter:- EA should not be inside of IT, and it’s usual placement hampers both IT and its effectiveness. – EA maturity is directly related to organizational pe…

Business Capability Naming and Content

by

Bruce Silver, BPMN luminary, has recently posted a piece on BPMN and Business Architecture where, he says, “In the past year the ‘architects’ seem to have discovered BPMN.”  WIth his usual meticulous style he dissects the difference between a process and other notions such as capabilities and functions, terms that architects like to throw around in their paperwork.

He clearly distinguishes process as the “how,” which is what we, at SenseAgility, have been saying as well. Process diagrams, and BPMN diagrams in particular, are the proof behind a particular type of capability, namely the Business Capability. In our work we’ve found that there are specific types of acceptable proofs behind different types of capabilities.

Here’s a statement Bruce makes about typing or perhaps it is even about granularity by implication, “If you’re sorting things into boxes, it doesn’t matter so much if some boxes hold square pegs and others round holes. But when you want to assemble those boxes into a coherent unit, it would be easier if the pegs and holes all had the same shape.” To us this principle is exactly the same one we employ when naming capabilities. As mentioned above, capabilities are different types. You can tell they are different types by looking at the proof behind the capability. That is, what makes the capability a capability in the first place? Business Capabilities have processes behind them, maybe more than one, but at least one.

So what I’m saying here is that if you want to give a name to a capability you need to have something in mind besides appropriate wording. Just getting people to agree on words doesn’t cut it. Why? Because ultimately you need to be talking about something of value. If capabilities can’t be linked to something of value then you might be imagining capabilities in a vacuum.

Anyway, subscribe to Bruce’s excellent blog when you get a chance.

Sample Set: Enterprise Architect Interview Questions

by

I’m interviewing an enterprise architecture candidate today. His CV suggests that he is an enterprise IT solution architect so I am going to probe a bit and see if he understands architecture of the enterprise. Here’s some questions I have jotted down as a framework for my own thinking. I’m sharing it in case it is useful to anyone else out the in the #entarch community.

What does "enterprise