Why I won’t be going to Open Group London

by

Today’s the last day for the ‘Early Bird’ for the Open Group London conference (Twitter hashtag #oglon) on enterprise-architecture and the like. It’s being held in my ‘home-city’ – just over fifty miles away. In principle, it’s one of the flagship conferences for my profession. And there’s a fair number of people listed there who I’d really […]

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.

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.

Categories Uncategorized

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

by

In a previous article, “Cloud Computing requires Enterprise Architecture and TOGAF 9 can show the way,” I described the need to define a strategy as an additional step in the TOGAF 9 Preliminary Phase. This article describes in more detail what could b…

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

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

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

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

Using Data Analysis to Predict the Future

by

Print PDF Guest post by Zach Sachen Your ability to predict the future is relative to the knowledge you have and what you do with it when compared to your competitors. If competitors do not have access to the same knowledge at the same time as you, to them you are essentially predicting the future. For example, if you know before your competitors that a consumer trend is emerging, and you act on it, you […]

If you liked this, you might also like:

  1. How to Make Decision Making More Adaptable with Layers
  2. Laying the Pavement for the Future-State CIO Journey
  3. Social Media Monitoring and Analysis